- Trong các sản phẩm agent chạy dài hạn, prompt caching là công nghệ cốt lõi giúp tái sử dụng phép tính từ các vòng roundtrip trước đó để giảm mạnh độ trễ và chi phí, và toàn bộ kiến trúc của Claude Code được thiết kế xoay quanh điều này
- Vì cache hoạt động theo cơ chế khớp tiền tố, nên cách sắp xếp đưa nội dung tĩnh lên trước và nội dung động ra sau sẽ quyết định chi phí và hiệu năng
- Nếu thay đổi công cụ hoặc mô hình giữa chừng trong một session thì cache sẽ bị vô hiệu hóa, vì vậy cần có các thiết kế lách như dùng stub nhẹ và công cụ chuyển trạng thái thay vì loại bỏ công cụ
- Ngay cả tác vụ compaction (rút gọn bằng tóm tắt) khi vượt quá context window cũng phải chia sẻ tiền tố cache của cuộc hội thoại cha để tránh chi phí tăng vọt
- Cần theo dõi tỷ lệ trúng cache như theo dõi uptime, và ngay cả vài phần trăm cache miss cũng có thể gây ảnh hưởng nghiêm trọng đến chi phí và độ trễ nên phải xem như một incident
- “Cache Rules Everything Around Me” cũng đúng nguyên xi với agent
- Chính prompt caching đã giúp cho các sản phẩm agent chạy lâu như Claude Code trở nên khả thi
- Nó mang lại hiệu quả lớn trong việc giảm latency và cost bằng cách tái sử dụng tính toán từ các vòng roundtrip trước đó
Cách prompt caching hoạt động và cách bố trí system prompt
- Prompt caching hoạt động theo cơ chế khớp tiền tố (Prefix), và API sẽ cache toàn bộ nội dung từ đầu request cho tới từng điểm ngắt
cache_control
- Điều cốt lõi là tối đa hóa tiền tố dùng chung giữa các request, và để làm được vậy cần đặt nội dung tĩnh trước, nội dung động sau
- Thứ tự sắp xếp của Claude Code:
- System prompt tĩnh và công cụ (cache toàn cục)
- Claude.MD (cache trong dự án)
- Session context (cache trong session)
- Các message hội thoại
- Thứ tự này mong manh đến mức đáng kinh ngạc, và có thể bị làm mất hiệu lực cache bởi:
chi tiết timestamp được chèn vào system prompt tĩnh,
việc xáo trộn thứ tự công cụ theo kiểu không xác định,
cập nhật tham số công cụ
Chiến lược cập nhật bằng system message
- Có những tình huống thông tin bên trong prompt trở nên lỗi thời, như thay đổi thời gian hoặc người dùng chỉnh sửa file
- Cập nhật trực tiếp prompt sẽ dẫn tới cache miss, làm tăng chi phí cho người dùng
- Thay vào đó, hãy truyền thông tin ở lượt tiếp theo dưới dạng message
- Claude Code chèn thông tin cập nhật vào user message hoặc tool result tiếp theo bằng thẻ
<system-reminder>
- Ví dụ, cung cấp cập nhật thời gian như “bây giờ là Wednesday”
- Dùng system messages theo cách này sẽ giúp giữ được cache
Vì sao không nên đổi model giữa chừng trong session
- Prompt cache là riêng theo từng model, nên cách tính chi phí cache có thể khác với trực giác
- Ví dụ: trong một cuộc hội thoại 100k token với Opus, nếu chuyển sang Haiku cho một câu hỏi đơn giản, thì bạn phải xây lại cache cho Haiku từ đầu, và tổng chi phí có thể còn cao hơn việc cứ để Opus trả lời
- Nếu cần chuyển model, cách tốt nhất là dùng sub-agent, trong đó Opus chuẩn bị một message “handoff” để chuyển cho model khác
- Explore agent của Claude Code dùng cách này khi sử dụng Haiku
Không được thêm hoặc bớt công cụ giữa chừng trong session
- Việc thay đổi tập công cụ là một trong những nguyên nhân phổ biến nhất khiến cache bị vô hiệu hóa
- Vì tập công cụ là một phần của tiền tố đã được cache, chỉ cần thêm hoặc bớt một công cụ là cache của toàn bộ cuộc hội thoại sẽ bị vô hiệu hóa
-
Plan Mode — thiết kế lấy cache làm trung tâm
- Cách tiếp cận trực quan: khi người dùng vào plan mode thì chỉ giữ lại công cụ đọc → phá hỏng cache
- Thiết kế thực tế: luôn đưa tất cả công cụ vào request, và triển khai EnterPlanMode cùng ExitPlanMode dưới dạng công cụ
- Khi vào plan mode, hệ thống gửi chỉ dẫn bằng system message: chỉ khám phá codebase, không chỉnh sửa file, và khi xong thì gọi ExitPlanMode
- Định nghĩa công cụ tuyệt đối không thay đổi
- Lợi ích thêm: vì EnterPlanMode là công cụ mà model có thể tự gọi, nên khi phát hiện bài toán khó, nó có thể tự động vào plan mode mà không phá cache
-
Tool Search — tải chậm thay vì loại bỏ
- Claude Code có thể nạp hàng chục công cụ MCP; nếu đưa hết vào thì tốn kém, còn loại bỏ thì phá cache
- Giải pháp là kiểu defer_loading, tức thay vì bỏ công cụ đi thì gửi một stub nhẹ chỉ chứa tên (
defer_loading: true)
- Khi cần, model sẽ nạp schema đầy đủ thông qua công cụ ToolSearch
- Vì cùng một stub luôn tồn tại theo cùng một thứ tự, tiền tố đã cache được giữ ổn định
- Có thể đơn giản hóa việc này bằng tính năng tool search của API
Fork context — Compaction
- Khi vượt quá context window, hệ thống sẽ thực hiện compaction bằng cách tóm tắt hội thoại rồi bắt đầu một session mới
- Cách triển khai trực quan (gọi API riêng để tạo tóm tắt mà không dùng cùng system prompt và công cụ) sẽ không khớp chút nào với tiền tố cache của hội thoại chính, khiến toàn bộ token đầu vào đều bị tính giá đầy đủ
-
Giải pháp Cache-Safe Forking
- Khi chạy compaction, sử dụng cùng system prompt, user context, system context và định nghĩa công cụ như cuộc hội thoại cha
- Đặt các message hội thoại của cha ở phía trước, rồi thêm prompt compaction ở cuối như một user message mới
- Từ góc nhìn API, request này gần như giống hệt request cuối cùng của cuộc hội thoại cha nên có thể tái sử dụng tiền tố đã cache, và token mới chỉ là prompt compaction
- Cần chừa ra một “compaction buffer” trong context window cho compact message và các token đầu ra của phần tóm tắt
- Dựa trên mẫu này, Anthropic đã tích hợp trực tiếp tính năng compaction vào API để nhà phát triển có thể áp dụng
Tóm tắt các bài học cốt lõi
- Prompt caching là khớp tiền tố, và bất kỳ thay đổi nào ở bất cứ đâu trong tiền tố đều sẽ vô hiệu hóa toàn bộ cache phía sau → cần thiết kế toàn hệ thống xoay quanh ràng buộc này
- Thay vì sửa system prompt, nên chèn system message trong lúc hội thoại để giữ cache tốt hơn
- Không đổi công cụ hay model giữa chừng trong cuộc hội thoại → hãy mô hình hóa chuyển trạng thái bằng công cụ, và dùng tải chậm thay vì loại bỏ công cụ
- Cần theo dõi tỷ lệ trúng cache như theo dõi uptime; chỉ vài phần trăm cache miss cũng có thể tác động rất lớn tới chi phí và độ trễ
- Các tác vụ fork (compaction, tóm tắt, chạy skill) phải chia sẻ tiền tố của cuộc hội thoại cha thì mới đạt được cache hit
- Nếu bạn đang xây agent, hãy thiết kế xoay quanh prompt caching ngay từ ngày đầu tiên
5 bình luận
Điểm cốt lõi là sự chuyển dịch từ prompt engineering sang context engineering, và về mặt thực tiễn thì có vẻ "tách biệt mối quan tâm" là đáp án.
Quản lý persona, quy tắc hành vi và bộ nhớ trong các tệp riêng biệt sẽ giúp giảm context rot hiệu quả. So với prompt đơn khối, chỉ tải những tệp cần thiết có lợi hơn nhiều cho attention budget. Có lẽ vì vậy mà OpenClaw (hoặc các framework tương tự) quản lý riêng persona (
SOUL.md), quy tắc hành vi (AGENTS.md) và bộ nhớ (MEMORY.md).À, ra là vì vậy mà giá token của Opus đắt như thế.
Tôi cũng tò mò không biết có bài đánh giá nào về sự khác biệt trong cách quản lý ngữ cảnh giữa Antigravity và Claude Code không.
Dù cùng là mô hình Opus nhưng chắc chắn sẽ có khác biệt. :)
Đây đúng là một bài viết rất hữu ích.
Độc giả thực sự:
Những người xây dựng “agent chạy trong thời gian dài” như Claude Code
(đặc biệt là kỹ sư sản phẩm/nền tảng, kỹ sư hạ tầng LLM)
Ai sẽ thấy hữu ích nhất?
✅ 1) Các team làm sản phẩm AI agent
✅ 2) Các kỹ sư tối ưu chi phí/độ trễ LLM
✅ 3) Những người gắn rất nhiều công cụ MCP
Ngược lại, người dùng phổ thông gần như sẽ không đọc
Đây không phải bài kiểu “cách viết prompt cho tốt”
Mà là
“nên xử lý prompt ở cấp độ kiến trúc sản phẩm như thế nào”
Tóm gọn trong một câu
Đây là bài viết dành cho những người xây dựng LLM không phải như một “cuộc trò chuyện”, mà như một “hệ thống production”.
Gần như không khác gì tối ưu hóa layer Docker cả