Khi bạn debug một AI agent (tác tử AI) chạy sai — trả lời lệch chủ đề, quên mất quy tắc đã dặn từ đầu, hoặc đơn giản là "đốt" quá nhiều token cho một task nhỏ — nguyên nhân gốc rễ gần như luôn nằm ở cách bạn tổ chức context (ngữ cảnh) đưa vào context window (cửa sổ ngữ cảnh), không phải ở model. Rất nhiều kỹ sư coi context là một khối văn bản duy nhất, nhồi mọi thứ vào một prompt lớn, rồi bất lực khi agent "quên" hoặc tốn tiền vô lý.
Cách nhìn đúng hơn — và cũng là cách các hệ thống agent production-grade (chất lượng sản xuất thực tế) đang vận hành — là coi context như một hệ thống phân tầng có cấu trúc, giống hệt cách một tổ chức phân quyền thông tin: có tài liệu chính sách công ty (ít thay đổi), có hồ sơ dự án đang chạy (cập nhật định kỳ), và có ghi chú họp hôm nay (dùng xong là bỏ). Bài này sẽ trình bày ba tầng context — system prompt, persistent context (context bền vững) và ephemeral context (context tạm thời) — cách model đọc và xử lý chúng, chi phí token thực tế của từng tầng qua vòng đời một session, và các pattern thiết kế để bạn kiểm soát được ngân sách token mà không hy sinh chất lượng output.
The Three Layers of Context
Hãy tưởng tượng context window của một agent như một căn nhà ba tầng. Tầng trệt là nền móng — gần như không đổi, ai bước vào nhà cũng thấy giống nhau. Tầng hai là khu vực sinh hoạt chung — thay đổi theo mùa, theo nhu cầu, nhưng vẫn giữ lại lâu dài. Tầng ba là bàn làm việc — mỗi ngày bày ra một đống giấy tờ khác nhau, dùng xong là dọn sạch. Ba tầng context trong một AI agent hoạt động đúng như vậy.
Tầng 1 — System prompt. Đây là bộ chỉ dẫn nền tảng: vai trò của agent, các quy tắc bất biến, ràng buộc về hành vi, format output mong muốn, danh sách tool available và cách dùng chúng. System prompt được thiết lập một lần khi khởi tạo agent (hoặc khi khởi tạo session) và về lý thuyết không thay đổi trong suốt phiên làm việc. Ví dụ: "Bạn là trợ lý code review, chỉ trả lời bằng tiếng Việt, luôn trích dẫn số dòng khi chỉ ra lỗi, không bao giờ tự ý sửa file mà không hỏi trước." Đây là tầng có tính ổn định cao nhất và — quan trọng với chủ đề khóa học này — là tầng dễ được model provider cache lại nhất để tiết kiệm token.
Tầng 2 — Persistent context. Đây là thông tin cần tồn tại xuyên suốt session, đôi khi xuyên suốt nhiều session, nhưng không cố định như system prompt. Ví dụ: file CLAUDE.md hoặc AGENTS.md mô tả cấu trúc project, coding convention của team, memory file ghi lại quyết định kiến trúc đã chốt, tóm tắt cuộc trò chuyện trước đó, hoặc profile người dùng (sở thích, quy tắc riêng). Persistent context thay đổi chậm — có thể được cập nhật giữa các turn, nhưng không bị xóa sau mỗi lượt như ephemeral context.
Tầng 3 — Ephemeral context. Đây là dữ liệu "dùng một lần": kết quả gọi tool (tool output), nội dung file vừa đọc để trả lời một câu hỏi cụ thể, kết quả tìm kiếm web, log lỗi vừa fetch về để debug. Ephemeral context có giá trị cực cao trong turn hiện tại nhưng giá trị giảm rất nhanh sau đó — nếu bạn giữ nguyên toàn bộ nội dung file 2.000 dòng trong context chỉ vì agent đã đọc nó ở turn 3, đến turn 20 nó chỉ còn là "rác" chiếm chỗ và chiếm tiền.
Điểm mấu chốt cần nắm: ba tầng này không phải là ba loại nội dung tách biệt về ý nghĩa, mà là ba loại nội dung có vòng đời (lifecycle) khác nhau. Việc phân loại đúng một đoạn thông tin vào tầng nào quyết định trực tiếp bạn có bị tính phí lặp lại cho nó hay không, và agent có "nhớ" nó đúng lúc cần hay không.
Mẹo
Khi không chắc một đoạn thông tin thuộc tầng nào, tự hỏi: "Nếu tôi xóa nó ngay sau turn này, agent có trả lời sai ở turn kế tiếp không?" Nếu có — nó thuộc persistent context hoặc system prompt. Nếu không — nó là ephemeral, hãy chủ động dọn nó đi, đừng chờ nó tự "trôi" ra khỏi context window.
How the Model Processes the Context Hierarchy
Một hiểu lầm phổ biến là nghĩ model "đọc" toàn bộ context window như một chuỗi ký tự phẳng, không phân biệt phần nào quan trọng hơn phần nào. Thực tế phức tạp hơn một chút, và hiểu đúng cơ chế này giúp bạn thiết kế context hiệu quả hơn rất nhiều.
Về mặt kỹ thuật, hầu hết các API của LLM (kể cả Claude) xử lý request theo thứ tự tuyến tính: system prompt được đặt ở vị trí cố định (thường là đầu request, tách biệt khỏi message list), sau đó là lịch sử hội thoại (message history) theo thứ tự thời gian, và ephemeral context (tool result, file content mới) thường được chèn vào gần cuối — càng gần với câu hỏi/yêu cầu hiện tại của người dùng. Đây không phải ngẫu nhiên: nghiên cứu và thực nghiệm về attention (cơ chế "chú ý" của transformer) cho thấy model có xu hướng ưu tiên thông tin ở đầu và ở cuối context hơn thông tin bị "chôn" ở giữa — hiện tượng này thường được gọi là "lost in the middle" (lạc mất ở giữa). Điều này lý giải vì sao đặt các chỉ dẫn quan trọng nhất ở system prompt (đầu) hoặc ngay trước câu hỏi cuối cùng (cuối) thường hiệu quả hơn nhồi chúng vào giữa một đống tool output.
Thứ tự xử lý thực tế trong một vòng lặp agent điển hình thường như sau:
- System prompt (vai trò, quy tắc, tool schema) — cố định, đọc đầu tiên.
- Persistent context (project docs, memory) — thường được nhúng ngay sau system prompt hoặc ở đầu message đầu tiên.
- Lịch sử hội thoại đã qua (bao gồm cả ephemeral context của các turn trước, nếu chưa bị dọn).
- Ephemeral context của turn hiện tại (tool result mới nhất) — thường ở gần cuối, sát với yêu cầu hiện tại.
- Yêu cầu/câu hỏi hiện tại của người dùng — luôn ở cuối.
Một hệ quả trực tiếp cho việc tối ưu token: các API hiện đại (ví dụ Claude API với prompt caching — cơ chế cache prompt) cho phép đánh dấu các đoạn context ổn định (thường là system prompt và phần đầu persistent context) là "cache breakpoint". Nếu nội dung trước breakpoint không đổi giữa các request, provider tính phí đọc cache (rẻ hơn nhiều, thường chỉ khoảng 10% giá input token thông thường) thay vì tính phí input token đầy đủ. Đây là lý do vì sao việc giữ system prompt và phần đầu persistent context ổn định, không chèn nội dung động vào đó, có ảnh hưởng tài chính trực tiếp — nếu bạn nhúng timestamp hiện tại hoặc một biến động vào ngay đầu system prompt, bạn vô tình phá cache của toàn bộ phần phía sau nó.
Một điểm nữa cần lưu ý: model không "biết" một đoạn text là system prompt hay ephemeral context trừ khi bạn đánh dấu rõ bằng cấu trúc (role: system, hoặc thẻ XML như <persistent_context>, <tool_result>). Nếu bạn nhồi tất cả vào một block text lớn không phân tầng rõ ràng, model phải tự suy luận mức độ quan trọng — kết quả thường kém tin cậy hơn.
Mẹo
Dùng thẻ cấu trúc rõ ràng (XML tag hoặc heading Markdown) để đánh dấu ranh giới giữa các tầng context, ví dụ <system_rules>, <project_memory>, <tool_output turn="12">. Việc này không chỉ giúp model phân biệt tầng, mà còn giúp bạn (hoặc một agent khác) dễ viết logic tự động dọn ephemeral context theo tag, thay vì phải đoán ranh giới bằng mắt.
The Token Cost of Each Layer Over a Session Lifetime
Đây là phần mà nhiều kỹ sư bỏ qua khi thiết kế agent, và cũng là phần tác động trực tiếp đến hóa đơn API cuối tháng. Ba tầng context không chỉ khác nhau về nội dung, mà khác nhau hoàn toàn về cách chi phí tích lũy qua thời gian.
System prompt: chi phí cố định, lặp lại mỗi request — trừ khi được cache. Với hầu hết API dạng "stateless" (không lưu trạng thái phía server, mỗi request phải gửi lại toàn bộ context), system prompt bị gửi lại và tính phí ở MỌI request, dù nội dung không đổi. Giả sử system prompt của bạn dài 1.500 token, và agent thực hiện 30 turn trong một session — nếu không có caching, bạn trả phí input token cho 1.500 token này 30 lần, tổng cộng 45.000 token chỉ để "nhắc lại" cùng một nội dung. Với prompt caching, từ request thứ 2 trở đi, phần này chỉ tính phí ở mức cache-read (thường ~10% giá gốc), giảm chi phí xuống còn xấp xỉ 1.500 + 29 × 150 ≈ 5.850 token-tương-đương — tiết kiệm khoảng 87%.
Persistent context: tích lũy dần, và đây là "quả bom nổ chậm" token. Khác với system prompt (kích thước ổn định), persistent context có xu hướng phình to theo thời gian nếu không kiểm soát — mỗi khi agent học được một fact mới, ghi thêm một dòng vào memory file, tóm tắt thêm một đoạn hội thoại. Một memory file khởi đầu 500 token có thể phình lên 5.000 token sau vài chục session nếu không ai dọn dẹp. Vì persistent context cũng bị gửi lại mỗi request (giống system prompt), chi phí của nó nhân với số turn giống hệt cách tính ở trên — nghĩa là một persistent context phình to không kiểm soát sẽ khiến chi phí toàn session tăng tuyến tính theo cấp số nhân với chính tốc độ phình to của nó, chứ không phải hằng số như system prompt.
Ephemeral context: chi phí bùng nổ trong turn, nhưng có thể "xả" sau đó. Đây là tầng có potential tốn kém nhất trong một turn đơn lẻ — một tool call đọc file 3.000 dòng code có thể bơm 10.000-15.000 token vào context chỉ trong một lần. Nhưng khác với hai tầng trên, ephemeral context KHÔNG bắt buộc phải tồn tại vĩnh viễn: nếu bạn (hoặc framework agent bạn dùng) chủ động xóa/tóm tắt tool output cũ sau khi nó đã hoàn thành mục đích, chi phí của nó không tích lũy qua các turn sau. Vấn đề là: rất nhiều framework agent mặc định KHÔNG dọn ephemeral context — chúng để toàn bộ lịch sử tool call nằm nguyên trong context, khiến turn thứ 20 phải "trả tiền lại" cho tool output của turn thứ 3.
Để minh họa cụ thể, hãy hình dung một agent code review chạy 20 turn, mỗi turn đọc thêm 1 file trung bình 800 token:
- Nếu KHÔNG dọn ephemeral context: turn 20 phải gửi lại toàn bộ 20 file đã đọc = 16.000 token ephemeral + system prompt + persistent context, và tổng token tích lũy toàn session tăng theo cấp số nhân tam giác (khoảng n×(n+1)/2 × 800 ≈ 168.000 token ephemeral tích lũy qua toàn session).
- Nếu CÓ dọn (chỉ giữ lại tóm tắt 100 token/file sau khi xử lý xong): turn 20 chỉ mang theo ~1.900 token ephemeral tóm tắt (19 file × 100 token) + nội dung file đang xử lý (800 token), và tổng tích lũy toàn session giảm xuống còn khoảng 1/8.
Sự khác biệt này — giữa "dọn dẹp có chủ đích" và "để mặc context phình to" — thường là nguyên nhân số 1 khiến chi phí vận hành agent trong production vượt dự toán 3-5 lần so với ước tính ban đầu của team.
Mẹo
Khi ước tính chi phí một agent trước khi đưa vào production, đừng chỉ tính "chi phí trung bình mỗi turn" — hãy mô hình hóa chi phí tích lũy qua N turn cho cả ba tầng riêng biệt. Một agent có vẻ rẻ ở turn 1 (vài trăm token) có thể tốn gấp 20-30 lần ở turn 20 nếu ephemeral context không được dọn — mô hình hóa sớm giúp bạn phát hiện vấn đề trước khi nhận hóa đơn.
Persistent Context Design Patterns
Persistent context là tầng khó thiết kế nhất trong ba tầng, vì nó nằm ở điểm giao giữa hai yêu cầu đối nghịch: cần đủ thông tin để agent "nhớ" đúng, nhưng không được phình to đến mức nuốt hết ngân sách token. Dưới đây là các pattern đã được kiểm chứng trong thực tế xây dựng agent, đặc biệt là các coding agent như Claude Code — nơi file CLAUDE.md/AGENTS.md chính là một dạng persistent context điển hình.
Pattern 1 — Phân lớp theo mức độ liên quan (relevance tiering). Không phải mọi thông tin persistent đều cần nằm trong context ở MỌI turn. Ví dụ một project lớn có thể có CLAUDE.md gốc (luôn load) và các file con theo module như product-english/system/AGENTS.md, product-finant/CLAUDE.md (chỉ load khi agent làm việc trong thư mục tương ứng). Đây chính là cách repo bạn đang thao tác được tổ chức — một root CLAUDE.md ngắn, gọn, chỉ chứa "bản đồ định tuyến" (repo map) trỏ đến các file con chi tiết hơn, thay vì nhồi tất cả quy tắc của mọi sub-project vào một file khổng lồ luôn được load.
Pattern 2 — Tóm tắt định kỳ thay vì lưu trữ nguyên văn (rolling summarization). Với memory ghi lại lịch sử hội thoại hoặc quyết định đã chốt, đừng append (nối thêm) nguyên văn mãi. Thiết kế một cơ chế: sau mỗi N turn hoặc mỗi khi memory vượt ngưỡng M token, agent (hoặc một tiến trình riêng) tóm tắt lại nội dung cũ thành dạng cô đặc, giữ lại kết luận/quyết định, bỏ đi quá trình suy luận trung gian. Ví dụ: thay vì lưu "Ở turn 5 user hỏi nên dùng REST hay GraphQL, agent phân tích ưu nhược điểm... [800 token]... cuối cùng chốt dùng REST vì team đã quen", nén lại thành một dòng: "Quyết định kiến trúc: dùng REST (không dùng GraphQL) — lý do: team đã có kinh nghiệm REST."
Pattern 3 — Cấu trúc theo schema cố định, không phải văn xuôi tự do. Persistent context dạng danh sách có cấu trúc (bullet, bảng, key-value) thường token-hiệu-quả hơn văn xuôi kể chuyện, và cũng dễ cho model parse chính xác hơn. So sánh:
<!-- Kém hiệu quả: văn xuôi, khó parse, tốn token diễn giải -->
Trong project này chúng tôi thường dùng TypeScript và team đã quyết định
là sẽ không dùng bất kỳ thư viện state management nào ngoài Zustand,
lý do là vì Redux quá phức tạp cho quy mô hiện tại...
<!-- Hiệu quả hơn: structured, ngắn, rõ ràng -->
## Tech Stack Rules
- Language: TypeScript (strict mode)
- State management: Zustand only (Redux rejected — overkill for current scale)
- Testing: Vitest + React Testing Library
Pattern 4 — Tách "quy tắc" khỏi "tham chiếu". Quy tắc (rule) — thứ agent PHẢI tuân theo mọi lúc — nên nằm trong persistent context luôn load. Tham chiếu (reference) — thứ chỉ cần khi làm một task cụ thể (ví dụ schema API đầy đủ, danh sách toàn bộ endpoint) — nên để agent chủ động tra cứu qua tool (đọc file khi cần) thay vì nhúng cứng vào persistent context. Đây chính là khác biệt giữa "agent cần biết luôn" và "agent cần biết khi được hỏi".
Pattern 5 — Versioning và audit định kỳ. Coi persistent context như code — nó cần được review định kỳ. Đặt lịch (hàng tháng, hoặc sau mỗi N session) để rà lại memory file: phần nào đã lỗi thời (ví dụ quyết định kiến trúc cũ đã bị thay thế), phần nào trùng lặp, phần nào chưa từng được agent dùng tới. Một memory file 3.000 token nhưng chỉ 30% nội dung còn hữu ích là một memory file cần "refactor".
Mẹo
Thêm một dòng comment "ngày cập nhật gần nhất" và "lý do thêm vào" cho mỗi mục quan trọng trong persistent context (ví dụ dạng <!-- added 2026-06: fix bug X, remove if migration Y completes -->). Việc này biến audit định kỳ từ "đọc lại toàn bộ và đoán" thành "lọc theo ngày và lý do" — nhanh hơn rất nhiều khi persistent context đã lớn.
Ephemeral Context: Keeping It Sharp
Nếu persistent context là vấn đề "phình to chậm", ephemeral context là vấn đề "phình to nhanh" — mỗi tool call, mỗi lần đọc file, mỗi kết quả search đều là một cú bơm token trực tiếp vào context window. Giữ ephemeral context "sắc" (sharp) nghĩa là: nó chỉ chứa đúng thứ cần cho quyết định NGAY LÚC NÀY, không hơn.
Kỹ thuật 1 — Xóa ngay sau khi dùng xong (immediate discard). Nguyên tắc đơn giản nhất: nếu một tool output đã được agent "tiêu hóa" thành một kết luận hoặc hành động, nội dung thô của nó không cần tồn tại nữa. Ví dụ agent đọc một file log 5.000 token để tìm dòng lỗi, sau khi tìm ra dòng lỗi và đưa ra kết luận, giữ lại 5.000 token log gốc trong context không mang lại giá trị gì cho các turn sau — chỉ nên giữ lại kết luận: "Lỗi tại payment_service.go:142, nguyên nhân: nil pointer khi order.Customer chưa được load."
Kỹ thuật 2 — Tóm tắt tool output ngay tại nguồn (compression at the edge). Với các tool trả về dữ liệu lớn (kết quả search, list file, response API), thiết kế tool wrapper để tóm tắt/cắt gọt TRƯỚC KHI đưa vào context, thay vì đưa nguyên văn rồi để model tự lọc. Ví dụ một tool search_codebase trả về 50 kết quả — thay vì bơm nguyên 50 kết quả (có thể 8.000 token) vào context, wrapper chỉ trả về top 5 kết quả liên quan nhất kèm 2 dòng context quanh mỗi match (khoảng 600 token), và cung cấp thêm tham số để agent chủ động yêu cầu "xem thêm" nếu cần.
Kỹ thuật 3 — Đặt TTL (time-to-live) rõ ràng cho ephemeral context. Một số framework agent hiện đại cho phép đánh dấu một block context với "thời hạn sống" — ví dụ chỉ giữ trong N turn tiếp theo, sau đó tự động bị prune (cắt bỏ) hoặc thay bằng bản tóm tắt. Nếu framework bạn dùng không hỗ trợ sẵn, bạn có thể tự implement bằng cách gắn turn-index vào mỗi ephemeral block và viết logic dọn dẹp trước khi build request tiếp theo: if current_turn - block.created_turn > 3: replace_with_summary(block).
Kỹ thuật 4 — Không lặp lại ephemeral context đã có trong persistent context. Một lỗi thường gặp: agent đọc file CLAUDE.md (đã là persistent context, luôn load), nhưng vì nó đi qua đường tool call (dùng tool read_file), toàn bộ nội dung lại bị đối xử như ephemeral và bị lưu thêm một lần trong lịch sử tool result — dẫn đến trùng lặp thông tin, tốn token hai lần cho cùng một nội dung. Cần có logic hoặc quy tắc rõ ràng: nội dung nào đã nằm ở persistent context thì không cần agent "đọc lại" qua tool, hoặc nếu đọc lại (để đảm bảo tính mới), phải loại bỏ bản ephemeral trùng lặp trước khi gửi request kế tiếp.
Kỹ thuật 5 — Biết khi nào ephemeral context nên "thăng cấp" thành persistent. Đôi khi một thông tin xuất hiện trong ephemeral context (ví dụ kết quả một API call) hóa ra sẽ cần dùng lại nhiều lần trong suốt session — trường hợp này, đừng để nó tự trôi và bị dọn theo TTL, hãy chủ động "thăng cấp" nó lên persistent context (dạng đã tóm tắt) một lần, rồi dọn bản ephemeral gốc. Đây là ranh giới động giữa hai tầng, và một agent thiết kế tốt cần có quy tắc rõ ràng để quyết định việc thăng cấp này — không nên để nó xảy ra ngẫu nhiên.
Mẹo
Đặt một quy tắc cứng trong system prompt hoặc trong logic điều phối (orchestration logic) của agent: "Sau khi hoàn thành một sub-task và đưa ra kết luận, tóm tắt tool output liên quan thành 1-2 câu và loại bỏ nội dung thô." Quy tắc này biến việc dọn ephemeral context từ một việc "nhớ thì làm" thành một bước bắt buộc trong vòng lặp agent — hiệu quả tiết kiệm token thường thấy rõ nhất ở các session dài trên 15-20 turn.
Practical Hierarchy Mapping Exercise
Lý thuyết ba tầng chỉ có giá trị khi bạn áp dụng được lên một agent thật. Bài tập sau đây giúp bạn map (ánh xạ) toàn bộ context hiện có của một agent bạn đang vận hành (hoặc đang xây) vào ba tầng, phát hiện điểm lãng phí, và đề xuất hành động cụ thể.
Bước 1 — Thu thập toàn bộ nguồn context. Liệt kê tất cả nguồn context mà agent của bạn đang dùng: system prompt hiện tại, các file được load tự động (kiểu CLAUDE.md/AGENTS.md), memory/session state, và danh sách các loại tool call thường được gọi (kèm ước tính kích thước output trung bình mỗi loại).
Bước 2 — Phân loại từng nguồn vào một trong ba tầng. Dùng bảng sau làm mẫu, điền cho agent thật của bạn:
| Nguồn context | Tầng | Kích thước ước tính | Tần suất gửi lại |
|-----------------------------------|-------------|----------------------|------------------------|
| System prompt (vai trò, quy tắc) | System | 1.200 token | Mỗi request (cache?) |
| CLAUDE.md gốc | Persistent | 400 token | Mỗi request |
| AGENTS.md sub-project | Persistent | 300-800 token | Khi vào sub-project |
| Memory file (quyết định đã chốt) | Persistent | 600 token (tăng dần) | Mỗi request |
| Tool: read_file | Ephemeral | 200-5.000 token/lần | Mỗi lần gọi, tích lũy? |
| Tool: search_codebase | Ephemeral | 500-8.000 token/lần | Mỗi lần gọi, tích lũy? |
| Tool: run_tests output | Ephemeral | 100-3.000 token/lần | Mỗi lần gọi, tích lũy? |
Bước 3 — Đánh dấu "cờ đỏ" (red flag). Với mỗi dòng, tự hỏi 3 câu:
- System prompt: có nội dung động (timestamp, ID session) chèn ở đầu làm hỏng cache không?
- Persistent context: kích thước có đang tăng theo thời gian mà không ai chủ động dọn/tóm tắt không?
- Ephemeral context: tool output cũ có bị giữ nguyên trong lịch sử, tích lũy qua nhiều turn không?
Bước 4 — Ước tính chi phí tích lũy cho một session điển hình (ví dụ 20 turn). Áp dụng công thức đã học ở phần "Token Cost": với hạng mục nào bị tích lũy (thường là ephemeral không được dọn), tính tổng theo dạng tam giác (n×(n+1)/2 × kích-thước-trung-bình) để thấy rõ mức độ nghiêm trọng thực tế, không chỉ nhìn chi phí một turn đơn lẻ.
Bước 5 — Viết 3 hành động cải thiện cụ thể, xếp theo ROI (return on investment). Ví dụ kết quả điển hình sau khi làm bài tập này với một coding agent thực tế:
1. Thêm prompt caching cho system prompt + CLAUDE.md gốc (giảm ~85% chi phí hai phần này sau turn đầu).
2. Thêm bước tóm tắt tool output của read_file sau khi agent đã dùng xong nội dung file cho quyết định hiện tại (giảm tích lũy ephemeral theo cấp số nhân tam giác).
3. Audit memory file hàng tháng, xóa các quyết định đã lỗi thời (giữ persistent context ổn định ở mức ~500-800 token thay vì phình không kiểm soát).
Làm bài tập này định kỳ (gợi ý: mỗi khi thêm một loại tool mới, hoặc mỗi quý với agent production) giúp bạn phát hiện context bị "rò" (leak) trước khi nó biến thành một dòng chi phí bất ngờ trong báo cáo sử dụng API.
Mẹo
Nếu agent của bạn dùng framework có sẵn (ví dụ Claude Agent SDK, LangGraph, hoặc tương tự), hầu hết đều có cách log lại toàn bộ request thực tế gửi đến model (bao gồm system prompt, message history, tool result). Trước khi đoán, hãy lấy log của MỘT session thật, đếm token thực tế theo từng tầng (không phải ước tính) — con số thật thường gây bất ngờ hơn bạn nghĩ, đặc biệt ở tầng ephemeral context.