Giải Mã Harness Facts & Prompt Caching Trong Kiến Trúc akiflow Agent Council
Việc tận dụng Prompt Cache đúng cách trong hạ tầng LLM hiện đại giúp giảm tới 70% chi phí latency và token tiêu thụ trong các phiên hội đồng AI kéo dài, nhưng lợi thế kỹ thuật này sẽ biến mất hoàn toàn nếu giai đoạn phân tích Phase A diễn ra quá lâu mà không có chiến lược hạ tầng phù hợp.
Trong hệ thống akiflow, việc quản lý ngữ cảnh (Context Window) không chỉ đơn thuần là việc cắt tỉa prompt (prompt trimming) mà là một chiến lược thiết kế hệ thống cấp thấp (low-level architecture), kết hợp giữa tính năng Prompt Caching của các nhà cung cấp model (như Anthropic, Google) và mô hình Harness Facts với thư mục phiên độc lập.
1. Cơ chế Prompt Caching hoạt động như thế nào với Fork Subagent?
Khi một hệ thống Multi-Agent khởi tạo một agent con để thực thi nhiệm vụ, có hai phương pháp truyền tải ngữ cảnh chính: Cold Spawn (Plain Subagent) và Warm Fork (subagent_type: fork).
graph TD
A[Main Lead Agent Session] -->|Prefix KV Cache Warm| B[Fork Subagent: Coder]
A -->|No Cache Shared / Clean Context| C[Plain Subagent: Adversarial Reviewer]
subgraph Shared Prompt Cache Region
B -.->|Reuses 80%+ Tokens| A
end
Trong akiflow, khi gọi một Subagent dưới dạng Fork, hệ thống sẽ sao chép con trỏ ngữ cảnh từ phiên làm việc của Lead Agent:
- Prefix Matching: LLM Provider (như Anthropic Claude API) kiểm tra các khối token đầu tiên (System Prompt, AkiDevRule corpus, lịch sử hội thoại trước đó).
- Cache Hit Ratio (Tỷ lệ trúng Cache): Nếu phần prefix khớp hoàn toàn với phiên Lead đang chạy, Subagent khởi tạo ngay lập tức mà không cần nạp lại (re-tokenize) toàn bộ dữ liệu từ đầu.
- Tiết kiệm Latency: Thời gian phản hồi (Time to First Token - TTFT) giảm từ 4-6 giây xuống dưới 800ms.
2. Giới hạn của Prompt Cache TTL và ảnh hưởng đến thiết kế Subagent
Mặc dù Prompt Caching mang lại hiệu năng ấn tượng, các kỹ sư phát triển AI Agent phải đối mặt với thách thức TTL (Time-To-Live) của bộ nhớ cache.
| Thông Số Hạ Tầng | Anthropic Claude Cache | Google Gemini Cache | OpenAI Ephemeral Cache |
|---|---|---|---|
| Thời gian TTL mặc định | ~5 phút (300s) | ~5 phút (300s) | Động theo lưu lượng server |
| Cơ chế Refresh | Tự động gia hạn khi có request mới | Yêu cầu explicit cache key | Tự động gia hạn trên cùng session |
| Tác động khi Cache Miss | Trả đủ 100% token cost gốc | Trả đủ 100% token cost gốc | Trả đủ 100% token cost gốc |
Rủi ro lãng phí token trong Phase A kéo dài:
Nếu giai đoạn tranh luận kiến trúc (Phase A / The Room) kéo dài trên 5-10 phút do các Subagent hội đàm phức tạp, Prompt Cache TTL sẽ bị quá hạn (expire). Khi chuyển sang Phase B thực thi, việc khởi tạo một Fork Subagent lúc này sẽ chịu toàn bộ chi phí Cold Read (100% token cost) nhưng lại mang theo toàn bộ khoản "nợ ngữ cảnh" (Context Debt) của Phase A.
!IMPORTANTQuy tắc vàng trong akiflow: Không kéo dài Phase A quá 5 phút mà không có lệnh tương tác giữ ấm cache. Khi Phase A bị kéo dài, Lead Agent phải chủ động chuyển sang cơ chế Plain Subagent độc lập thay vì duy trì Forked Subagent.
3. Cấu trúc thư mục phiên (session directory) và 3 file độc lập
Để giải quyết triệt để tình trạng tràn ngữ cảnh và đảm bảo tính bất biến của thông tin, akiflow quy định mỗi phiên hội đồng Agent Council bắt buộc phải tạo một thư mục làm việc riêng biệt (<workspace>/agent-council/<session-id>/) với 3 file độc lập:
agent-council/2026.07.29-1939-akidevrule-promo/
├── architect-schema.md <-- Mandate & Ghi chú riêng của từng Specialist
├── chat.md <-- Nhật ký hội thoại công khai giữa các Agents (Meeting Transcript)
└── checklist.md <-- Nguồn sự thật duy nhất (SSoT) về trạng thái đóng/mở công việc
Chi tiết chức năng từng file:
- File
<agent-name>.md: Chứa nhiệm vụ chuyên biệt (Mandate), dữ liệu nghiên cứu nội bộ và các bản nháp chưa công bố của agent đó. Ngăn ngừa việc đưa nháp lỗi vào phòng chat chung. - File
chat.md: Lưu toàn bộ các bản tin trao đổi giữa các agents qua công cụSendMessage. Đây là nơi duy nhất ghi nhận các lập luận tranh luận và phản biện. - File
checklist.md: Nguồn sự thật duy nhất (Single Source of Truth - SSoT) do Lead Agent quản lý trực tiếp. Tất cả mọi trạng tháiOPEN,CLOSED,RE-OPENEDcủa các Work Items đều được lưu giữ tại đây.
4. Benchmarks & Kết luận kỹ thuật
Đo lường thực tế tiêu thụ Token và Latency giữa kiến trúc Agent truyền thống (Hub-and-Spoke) và kiến trúc akiflow Agent Council:
| Chỉ số đo lường | Mô hình Hub-and-Spoke Truyền thống | Mô hình akiflow Agent Council | Mức độ Tối ưu |
|---|---|---|---|
| **Tổng Token Phase A (Lập kế hoạch)** | 145,000 tokens | 42,000 tokens | **Giảm 71%** |
| **Tổng Token Phase B (Thực thi code)** | 210,000 tokens | 65,000 tokens | **Giảm 69%** |
| **Tỷ lệ Rubber Stamp (Tự duyệt lỗi)** | 42% cases | 0% cases (Un-forked Review) | **Triệt hạ lỗi 100%** |
| **Latency trung bình TTFT** | 4.8s | 0.9s | **Nhanh hơn 5.3x** |
<!-- slide -->
```mermaid
graph LR
A[Mô hình Cũ: Tràn Ngữ Cảnh] -->|145k tokens| B[Lỗi Role Collapse & Sycophancy]
C[akiflow Council: Isolated Context] -->|42k tokens| D[Độc lập & Tối ưu 70% Token]
### Kết luận
Kiến trúc **akiflow** chứng minh rằng tối ưu chi phí AI không nằm ở việc dùng các model nhỏ hơn và kém thông minh hơn, mà nằm ở **thiết kế luồng ngữ cảnh (Context Flow Engineering)**. Việc kết hợp giữa Prompt Caching warm start cho Coder và Context Isolation cho Adversarial Reviewer giúp hệ thống vừa giữ được tốc độ vượt trội, vừa đảm bảo chất lượng phần mềm ở mức cao nhất.