Agent đang đốt token vì context dài? Runtime mới là phần chìm

TL;DR

Context dài đúng là một nguyên nhân làm Agent AI tốn token. Nhưng nó chưa trả lời câu hỏi quan trọng hơn: vì sao Agent lại cần lượng context đó?

Trong một workflow nhiều tool, Agent Runtime quyết định khi nào phải đọc thêm file, tìm kiếm, gọi tool, xác minh, retry hoặc lập kế hoạch lại. Vì thế, tổng token chỉ là hóa đơn cuối kỳ; execution trace mới cho biết mỗi quyết định đã tạo ra chi phí gì.

Hai lập trình viên cùng sửa một lỗi

Hãy tưởng tượng bạn giao việc: Sửa lỗi đăng nhập.

Một lập trình viên mở đúng file Login, tìm nguyên nhân, sửa, chạy test và hoàn thành. Một người khác đọc cả Authentication, UserRepository, SessionManager, TokenService, OAuth và config. Sau đó người này search thêm vài nơi cho chắc, refactor vài class vì tiện thể, rollback, sửa lại rồi chạy test nhiều lần.

Cả hai đều có thể sửa được bug. Nhưng chi phí để đi tới kết quả hoàn toàn khác nhau.

Agent AI cũng vậy. Khi một Agent nhận task nhỏ mà đọc lan sang nhiều module, mở rộng tìm kiếm, gọi tool lặp lại hoặc kiểm tra quá nhiều vòng, chi phí token tăng không chỉ vì file dài. Nó tăng vì hệ thống đã chọn một chuỗi hành động đắt hơn cần thiết.

Hóa đơn token chưa phải là bản giải trình

Phần lớn dashboard hiện nay hiển thị theo dạng: Input: 12k tokens | Reasoning: 35k tokens | Output: 3k tokens.

Con số này hữu ích, nhưng nó giống đồng hồ điện: bạn biết đã dùng bao nhiêu, không biết thiết bị nào đang ngốn điện.

Liệu reasoning token đến từ việc lập kế hoạch tốt hơn, hay đến từ ba lần retry? Agent có đọc thêm mười file vì dependency thực sự cần thiết, hay chỉ vì search quá rộng? Tool call nào làm phát sinh context lớn? Verification nào đang lặp lại một kiểm tra cũ?

Nếu không trả lời được những câu hỏi này, tối ưu prompt hay tăng context window chỉ giống giảm hóa đơn khi chưa biết điểm rò rỉ ở đâu.

LLM suy luận, Runtime hành động

Planner chỉ là một phần của Agent Runtime. Runtime là tầng quyết định Agent sẽ làm gì tiếp theo:

• Có nên đọc thêm file không?
• Có cần tìm kiếm trong codebase không?
• Có nên gọi tool hay mở rộng phạm vi task?
• Kết quả đã đủ tin cậy hay cần verifier kiểm tra?
• Có cần retry, rollback hoặc lập kế hoạch lại không?

LLM quyết định cách suy luận. Runtime quyết định cách suy luận đó biến thành hành động ngoài đời thực. Chính các hành động này tạo ra file được đọc, context được nạp, tool được gọi và token được tiêu.

Đó không có nghĩa Runtime luôn là nguồn chi phí lớn nhất trong mọi Agent. Nhưng trong workflow nhiều công cụ, nhiều nhánh và nhiều vòng xác minh, Runtime là nơi nên được đo đạc đầu tiên. Langfuse mô tả tracing là cách ghi lại toàn bộ vòng đời request, bao gồm LLM calls, retrieval, tool execution, timing, input, output và metadata via Langfuse.

Agent cần observability như hệ thống phần mềm

Khi một service chậm, đội kỹ thuật không đoán CPU đang nghĩ gì. Họ dùng log, trace, metrics, profiler và APM để biết request đi qua đâu, hàm nào chậm, query nào nghẽn và service nào tạo bottleneck.

Agent cũng cần một cách nhìn tương tự. Phoenix khuyến nghị ghi lại mọi LLM call, tool execution, retrieval operation và generation, cùng input, output, latency và token usage via Arize Phoenix. Đây là observability ở cấp độ hệ thống, không phải yêu cầu xem Chain of Thought.

Để audit Agent, chúng ta không cần nội dung suy luận nội bộ. Chúng ta cần sự kiện thực thi có thể kiểm chứng: bước nào chạy, dùng công cụ nào, phạm vi nào được mở rộng, mất bao lâu, tốn bao nhiêu và kết quả là gì.

OpenTelemetry cũng đang chuẩn hóa telemetry cho GenAI, bao gồm model, input/output token count; khi được opt-in, telemetry có thể lưu prompt, completion, tool call và tool result via OpenTelemetry. Cơ chế opt-in là lời nhắc cần thiết: minh bạch phải đi cùng chính sách dữ liệu và quyền riêng tư.

Dashboard mà chúng ta cần

Thay vì chỉ nhìn tổng token, hãy tưởng tượng một dashboard quy chiếu chi phí theo loại hành động:

Dashboard cũng nên có một working set: danh sách file, dữ liệu, tool và dependency mà Agent đang thực sự dùng. Khi scope thay đổi, runtime phải để lại dấu vết: dependency expansion, concept expansion, retry, rollback và re-planning.

Token là chi phí của một quyết định

Khi có trace tốt, đội ngũ có thể chuyển từ tối ưu cảm tính sang tối ưu có bằng chứng. Thay vì nói Agent tốn token, ta có thể nói: Agent đã tiêu nhiều ở verification vì verifier chạy bốn lần; chi phí đọc file tăng vì search mở sang module không liên quan; latency tăng vì một tool call retry ba lần.

Những dữ liệu này biến việc tối ưu orchestration thành một bài toán kỹ thuật rõ ràng: đặt budget cho từng phase, giới hạn số file được mở rộng, cache kết quả tool, dừng verification khi confidence đủ cao hoặc buộc runtime giải thích lý do scope thay đổi.

IBM mô tả một ví dụ observability có thể theo dõi trace theo session, tool invocation, structured tool output và latency từng bước để phân tích hành vi Agent via IBM. Đây là dấu hiệu cho thấy Agent Runtime đang dần trở thành một hệ thống cần vận hành và kiểm toán, không chỉ là một prompt dài hơn.

Cuộc đua tiếp theo: observability, auditability và execution transparency

Trong vài năm qua, ngành AI chủ yếu chạy đua model lớn hơn, context dài hơn, reasoning tốt hơn và tool nhiều hơn. Nhưng khi Agent làm việc hàng giờ, xử lý quy trình nhiều bước hoặc tác động đến cả dự án, câu hỏi quan trọng sẽ là: Agent đang làm gì với thời gian, dữ liệu và token của tôi?

OpenTelemetry đang hướng tới semantic conventions cho AI Agent để các framework có thể xuất traces, metrics và logs chuẩn hóa, dễ tích hợp và dễ so sánh hơn via OpenTelemetry. Đây chưa phải một tiêu chuẩn hoàn tất, nhưng hướng đi đã rõ.

Lợi thế cạnh tranh của Agent tương lai sẽ không chỉ là dùng model nào. Nó còn là Runtime có minh bạch không, có kiểm toán được không và có thể chỉ ra chi phí của từng quyết định hay không.

Bởi vì trong kỷ nguyên Agent AI, thứ lãng phí nhất có thể không còn là token. Mà là những token bị tiêu đi mà chúng ta không hề biết vì sao.