TL;DR
Chi phí token của tác nhân AI tăng khi mỗi bước lặp lại việc xử lý hướng dẫn, lịch sử hội thoại, kết quả công cụ và trạng thái trung gian.
Giảm khối lượng token bằng ngân sách cấp lần chạy, lọc kết quả công cụ, nén ngữ cảnh, giới hạn số lần retry và kiểm soát mức lập luận. Dùng prompt caching cho phần đầu vào lặp lại ổn định, nhưng hãy tối ưu vòng lặp tác nhân trước khi chuyển sang mô hình rẻ hơn.
Chỉ số hữu ích nhất trong sản xuất là chi phí trên mỗi tác vụ thành công, được đo trên toàn bộ lần chạy—không phải giá mỗi request hay kích thước ngữ cảnh của cuộc gọi cuối.
Hướng dẫn này tập trung riêng vào tác nhân nhiều bước. Nó giải thích cách ngữ cảnh lặp lại bị cộng dồn qua một lần chạy, cách xác định nguồn lãng phí lớn nhất và nên triển khai những kiểm soát nào trước.
Introduction
Một chatbot có thể thực hiện một yêu cầu mô hình cho mỗi tin nhắn người dùng. Một tác nhân AI có thể thực hiện 10, 20 hoặc nhiều cuộc gọi hơn trước khi hoàn tất một tác vụ.
Mỗi bước có thể gửi lại hướng dẫn, lịch sử hội thoại, kết quả công cụ và trạng thái trung gian. Retry, lập luận và tác nhân con làm tăng mức sử dụng, vì vậy một câu trả lời cuối ngắn vẫn có thể tiêu tốn lượng lớn token.
Khi quy mô tăng, các chi phí này khó dự đoán hơn và có thể nhanh chóng làm giảm biên lợi nhuận. Để giảm, cần tối ưu toàn bộ vòng lặp tác nhân—không chỉ đơn giản chuyển sang mô hình rẻ hơn.
Bài viết này tập trung vào chi phí riêng của tác nhân. Để có hướng dẫn rộng hơn bao gồm prompt caching, cache phản hồi chính xác, cache ngữ nghĩa, định tuyến mô hình và quản lý chi phí API tổng quát, xem Cách giảm chi phí API AI.
Why Do AI Agent Token Costs Compound?
Trong tác nhân nhiều bước, chi phí của một tác vụ là tổng của mọi cuộc gọi mô hình—không chỉ phản hồi cuối.
Nguồn sử dụng token chính của tác nhân:
| Cost source | What causes it | First control to test |
|---|---|---|
| Repeated instructions | System prompts, tool schemas, policies, examples | Stabilize the reusable prefix |
| Growing history | Earlier turns are resent at each step | Compact or selectively retrieve state |
| Tool results | Search pages, files, logs, and database records | Filter before adding them to context |
| Intermediate output | Plans, status messages, and verbose tool decisions | Use compact structured outputs |
| Reasoning tokens | High reasoning effort on routine steps | Match effort to task complexity |
| Retries | Invalid output, timeouts, tool errors, and rate limits | Classify failures and cap retries |
| Subagents | Workers duplicate context, tools, and analysis | Send each worker a narrow context slice |
Có hai cách khác nhau để giảm hóa đơn:
- Xử lý ít token hơn thông qua lọc, nén, giới hạn đầu ra và kiểm soát vòng lặp.
- Giảm giá hiệu dụng của token cần thiết bằng prompt caching hoặc lựa chọn mô hình.
Khác biệt then chốt: Prompt caching làm giảm chi phí của đầu vào lặp lại. Nén ngữ cảnh làm giảm chính phần đầu vào lặp lại đó.
How Can a 12-Step Agent Process 147,000 Tokens?
Xét một tác nhân hỗ trợ giả định với:
- Tiền tố ổn định 4.000 token
- 1.500 token mới được thêm sau mỗi bước
- Lịch sử tích lũy đầy đủ được gửi lại trên mỗi request
- Tổng 12 cuộc gọi mô hình
Đầu vào tại bước n là:
Input at step n = 4,000 + 1,500 × (n - 1)
Tổng đầu vào qua 12 cuộc gọi là:
Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens
Cuộc gọi cuối chỉ chứa 20,500 input tokens, nhưng toàn bộ lần chạy xử lý 147,000 cumulative input tokens.
Giờ áp dụng hai kiểm soát:
- Cache tiền tố ổn định 4.000 token sau cuộc gọi đầu tiên.
- Nén lịch sử sau bước sáu thành một bản tóm tắt trạng thái 2.500 token.
| Scenario | Uncached input | Cached input | Total processed input | Change |
|---|---|---|---|---|
| Full history on every step | 147,000 | 0 | 147,000 | Baseline |
| Stable prefix cached | 103,000 | 44,000 | 147,000 | Same volume, cheaper mix |
| Cache plus compaction | 64,000 | 44,000 | 108,000 | 26.5% fewer processed tokens |
Đây là phép tính lập kế hoạch, không phải benchmark nhà cung cấp.
Giả định rằng mỗi request bao gồm toàn bộ lịch sử tích lũy. Các tác nhân chọn lọc dựng trạng thái, tóm tắt tin nhắn cũ hoặc chỉ truy xuất thông tin liên quan có thể theo một đường cong chi phí khác.
Quy tắc tăng trưởng chi phí: Đo tổng đầu vào trên toàn bộ lần chạy. Kích thước ngữ cảnh của bước cuối không đại diện cho tổng số token đã xử lý.
Which Metrics Reveal Agent Token Waste?
Đừng bắt đầu bằng cách đổi mô hình. Trước hết xác định nơi quy trình đang tiêu tốn token mà không cải thiện kết quả.
Ghi lại các trường cho mỗi bước của tác nhân:
| Field | Why it matters |
|---|---|
run_id, step_id, parent_step_id | Tái tạo cây tác nhân và tác nhân con |
| Rendered input tokens | Cho thấy ngữ cảnh tăng lên giữa các cuộc gọi |
| Cached and uncached input | Tách phần tái sử dụng khỏi ngữ cảnh mới |
| Output and reasoning tokens | Xác định các bước tạo sinh tốn kém |
| Tool result size and retained tokens | Cho thấy bao nhiêu bằng chứng thô đi vào prompt |
| Retry reason and attempt number | Xác định lỗi lặp lại |
| Compaction tokens before and after | Đo mức giảm ngữ cảnh thực tế |
| Worker ID and returned tokens | Bộc lộ công việc lặp lại giữa tác nhân con |
| Accepted, rejected, or escalated result | Kết nối chi phí với chất lượng tác vụ |
Chỉ số chính nên là:
cost per successful task
= total workflow cost
/ accepted tasks
Một lần chạy rẻ hơn không phải là cải tiến nếu nó gây ra nhiều tác vụ thất bại, lặp lại công cụ hoặc cần con người chỉnh sửa.
Bốn chỉ số riêng của tác nhân giúp định vị vấn đề.
Context Amplification
context amplification
= cumulative input tokens
/ final-step input tokens
Giá trị cao cho biết ngữ cảnh ban đầu đã bị xử lý lặp lại nhiều lần.
Tool Retention Ratio
tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools
Tỷ lệ cao có thể cho thấy tác nhân đang mang quá nhiều bằng chứng thô giữa các bước.
Retry Tax
retry tax
= retry and repair cost
/ total workflow cost
Reasoning Share
reasoning share
= reasoning-token cost
/ total model cost
Đo từng khối công việc riêng. Tác nhân nghiên cứu, lập trình, trình duyệt và hỗ trợ khách hàng không nên dùng chung một baseline toàn cục.
Six Ways to Reduce AI Agent Token Costs
1. Set a Budget for the Complete Run
Giới hạn đầu ra mỗi request không kiểm soát được một tác nhân nhiều bước.
Đặt giới hạn cấp lần chạy cho:
- Tổng số bước mô hình
- Tổng đầu vào và đầu ra
- Số lần gọi công cụ và kích thước kết quả công cụ
- Số lần retry theo loại lỗi
- Tác nhân con
- Tổng thời gian trôi qua hoặc chi phí ước tính
Ví dụ Python trung lập với nhà cung cấp sau đây đánh giá lần chạy trước mỗi cuộc gọi mô hình:
from dataclasses import dataclass
from enum import Enum
class Action(str, Enum):
CONTINUE = "continue"
COMPACT = "compact"
STOP = "stop"
@dataclass(frozen=True)
class Budget:
max_steps: int = 12
max_input_tokens: int = 120_000
max_output_tokens: int = 18_000
compact_at: float = 0.80
@dataclass
class Usage:
steps: int = 0
input_tokens: int = 0
output_tokens: int = 0
def evaluate_budget(usage: Usage, budget: Budget) -> Action:
if (
usage.steps >= budget.max_steps
or usage.input_tokens >= budget.max_input_tokens
or usage.output_tokens >= budget.max_output_tokens
):
return Action.STOP
input_ratio = usage.input_tokens / budget.max_input_tokens
if input_ratio >= budget.compact_at:
return Action.COMPACT
return Action.CONTINUE
Chạy kiểm tra trước mỗi yêu cầu mô hình và cập nhật Usage từ dữ liệu token do nhà cung cấp báo cáo.
Ở mức 80% ngân sách đầu vào, nén trạng thái hoặc thu hẹp truy vấn công cụ tiếp theo. Ở mức 100%, dừng với lý do có cấu trúc.
Sai lầm thường gặp: Giới hạn mỗi phản hồi trong khi cho phép số bước, công cụ và retry không giới hạn.
2. Filter Tool Results Before They Enter the Transcript
Chỉ trả về bằng chứng cần thiết cho quyết định tiếp theo của tác nhân.
Đừng nối thêm toàn bộ:
- Trang web
- Tệp log
- Cây mã nguồn
- Phản hồi cơ sở dữ liệu
- Phiên terminal
- Payload API
khi bước tiếp theo chỉ cần vài trường.
Một công cụ tìm kiếm có thể trả về:
{
"source_id": "search_17",
"title": "Relevant page title",
"url": "https://example.com/page",
"relevant_passage": "A short evidence block"
}
Lưu toàn bộ tài liệu ngoài prompt và truy xuất phần hẹp hơn sau đó.
Quy tắc lọc công cụ: Trả về các trường cần cho quyết định tiếp theo—không phải mọi trường có thể hữu ích sau này.
Sai lầm thường gặp: Cắt ngắn 1.000 ký tự đầu của payload JSON. Điều này có thể làm hỏng cấu trúc hoặc loại bỏ bản ghi mà tác nhân thực sự cần.
Hãy parse payload trước, chọn trường theo cấu trúc, giới hạn mảng, rồi serialize JSON hợp lệ.
3. Compact Operational State, Not Just Conversation Text
Nén nên giữ lại thông tin cần thiết để tiếp tục tác vụ đồng thời loại bỏ lịch sử không còn ảnh hưởng đến hành động tiếp theo.
Một trạng thái đã nén hữu ích bao gồm:
- Mục tiêu người dùng và tiêu chí thành công
- Các quyết định đã đưa ra
- Sự kiện đã xác minh và ID nguồn
- Tệp hoặc bản ghi đã thay đổi
- Cách tiếp cận thất bại
- Câu hỏi còn mở
- Hành động tiếp theo
- Ràng buộc an toàn và đầu ra
Nó không nên kể lại toàn bộ hội thoại.
OpenAI có tài liệu về nén cho tương tác dài hạn của Responses API. Anthropic cung cấp các điều khiển quản lý ngữ cảnh để xóa hoặc tóm tắt nội dung cũ hơn. Các triển khai này khác nhau, vì vậy hãy xác minh các trường nhà cung cấp hiện tại trước khi tích hợp.
Quy tắc nén: Giữ các quyết định và công việc chưa giải quyết. Loại bỏ tường thuật và bằng chứng có thể truy xuất lại.
Sai lầm thường gặp: Bỏ ID nguồn, tên tệp đã đổi, cách tiếp cận bị loại, hoặc ràng buộc chưa giải quyết.
Sau khi thêm nén, đo xem tác nhân có lặp lại tìm kiếm hoặc gọi công cụ không. Prompt ngắn hơn không rẻ hơn nếu tác nhân phải xây dựng lại trạng thái bị mất.
4. Keep the Reusable Prefix Stable
Prompt của tác nhân thường chứa các khối tái sử dụng lớn:
- Hướng dẫn hệ thống
- Schema công cụ
- Chính sách an toàn
- Định dạng đầu ra
- Tài liệu tham khảo dùng chung
- Hướng dẫn về repository hoặc sản phẩm
Đặt các thành phần ổn định này trước dữ liệu đặc thù của yêu cầu:
1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data
Tránh đặt timestamp, ID yêu cầu, dữ liệu phiên hoặc các giá trị thay đổi thường xuyên gần phần đầu.
Caching hữu ích nhất khi tiền tố dài, ổn định và được tái sử dụng. Nó có thể không tiết kiệm cho các phiên ngắn hoặc prompt thay đổi thường xuyên.
Sai lầm thường gặp: Tối ưu hóa tỷ lệ trúng cache mà không đo chi phí ghi, đọc hoặc lưu trữ cache.
Để so sánh rộng hơn giữa prompt caching, cache phản hồi chính xác và cache ngữ nghĩa, xem Cách giảm chi phí API AI.
5. Prevent Retries From Replaying the Same Context
Retry là một bước tác nhân khác, thường với cùng prompt lớn.
Đừng lặp lại một yêu cầu thất bại mà không thay đổi nguyên nhân thất bại.
| Failure | Better response |
|---|---|
| Invalid structured output | Trả về lỗi xác thực và retry một lần |
| Tool timeout | Retry thao tác idempotent một lần, sau đó dừng hoặc dùng fallback |
| Context overflow | Nén trạng thái hoặc truy xuất ít bằng chứng hơn |
| Repeated tool call | Khử trùng lặp bằng hash thao tác |
| Rate limit | Backoff hoặc dùng tuyến fallback đã kiểm thử |
| Low-confidence result | Yêu cầu thông tin còn thiếu hoặc leo thang |
Dùng idempotency key cho các thao tác có tác dụng phụ như thanh toán, email, triển khai và ghi cơ sở dữ liệu.
Sai lầm thường gặp: Retry một mô hình bị rate limit nhiều lần trong khi gửi lại toàn bộ ngữ cảnh tác nhân ở mỗi lần thử.
Theo dõi thuế retry theo loại lỗi để nhóm có thể sửa vòng lặp lớn nhất trước.
6. Limit Reasoning and Subagents to Steps That Need Them
Không phải bước nào của tác nhân cũng cần lập luận sâu.
Trích xuất, định dạng, phân loại, xác thực và lựa chọn công cụ thường quy có thể dùng mức lập luận thấp hơn và đầu ra cấu trúc gọn.
Dành mức lập luận cao hơn cho các tác vụ như:
- Lập kế hoạch phức tạp
- Lập trình khó
- Tổng hợp đa tài liệu
- Quyết định mơ hồ
- Khôi phục sau thực thi thất bại
Quy tắc lập luận: Dùng mức lập luận thấp nhất vẫn giữ được tỷ lệ tác vụ được chấp nhận.
Tác nhân con cũng cần ranh giới rõ. Giao cho mỗi worker:
- Nhiệm vụ hẹp
- Lát cắt ngữ cảnh theo nhiệm vụ
- Danh sách công cụ được phép
- Ngân sách token
- Schema đầu ra gọn
Tác nhân gốc thường chỉ cần phát hiện, ID bằng chứng, độ tin cậy và vấn đề chưa giải quyết—không cần toàn bộ bản ghi của worker.
Quy tắc tác nhân con: Song song các công việc độc lập, không phải ngữ cảnh trùng lặp.
Sai lầm thường gặp: Gửi toàn bộ lịch sử của tác nhân gốc cho mọi worker trước khi giao nhiệm vụ hẹp.
Which Optimization Should You Apply First?
Dùng telemetry của tác nhân để chọn can thiệp đầu tiên.
Các ngưỡng dưới đây là tín hiệu điều tra, không phải tiêu chuẩn chung.
| Observed signal | Start here |
|---|---|
| Context amplification is high | Nén lịch sử và truy xuất chọn lọc trạng thái |
| Tool output dominates the prompt | Lọc trường và lưu trữ đầy đủ hiện vật bên ngoài |
| Retry tax is high | Sửa xác thực, timeout và gọi công cụ lặp lại |
| Reasoning share is high | Giảm mức lập luận ở bước thường quy |
| Subagents repeat the same evidence | Thu hẹp phạm vi worker và lát cắt ngữ cảnh |
| Cached input remains low | Ổn định tiền tố tái sử dụng |
| Costs remain high after loop cleanup | So sánh tuyến mô hình chi phí thấp hơn |
Một chuỗi triển khai an toàn là:
- Đo tổng đầu vào, tỷ lệ giữ công cụ, retry và lập luận.
- Thêm giới hạn cứng cho bước, công cụ, retry và tổng token.
- Lọc kết quả công cụ lớn.
- Nén trạng thái cũ ở một ngưỡng đo được.
- Ổn định tiền tố prompt tái sử dụng.
- Chỉ so sánh tuyến mô hình sau khi vòng lặp tác nhân đã sạch.
So sánh một biến lớn mỗi lần và phát lại cùng bộ đánh giá.
So sánh:
- Tỷ lệ tác vụ được chấp nhận
- Chi phí trên mỗi tác vụ thành công
- Tổng đầu vào
- Số lần gọi công cụ
- Thuế retry
- Tỷ trọng lập luận
- p50 và p95 độ trễ
- Thời gian con người rà soát
Hoàn tác thay đổi nào tiết kiệm token bằng cách giảm chất lượng tác vụ hoặc loại bỏ bằng chứng cần thiết.
Test Agent Workflows With CometAPI
Trước khi chạy đánh giá đa mô hình, dùng trang giá và hướng dẫn ước tính chi phí của CometAPI để ước tính chi phí đầu vào, đầu ra, token cache và lập luận.
Sau đó dùng catalog mô hình để xác định tuyến phù hợp và Quickstart để cấu hình client tương thích OpenAI.
Đối với fallback sản xuất, làm theo hướng dẫn fallback mô hình CometAPI để chuyển tuyến mà không lặp lại các lần gọi công cụ đã hoàn tất hoặc loại bỏ trạng thái đã xác thực.
Truy cập hợp nhất giúp đơn giản hóa so sánh mô hình và tích hợp fallback. Ngân sách token, nén, xác thực, lọc công cụ, giới hạn retry và tiêu chí chấp nhận vẫn thuộc tầng ứng dụng.
FAQ
Vì sao tác nhân AI dùng nhiều token hơn chatbot?
Tác nhân thực hiện nhiều cuộc gọi mô hình và có thể gửi lại tin nhắn trước đó, kết quả công cụ, hướng dẫn và trạng thái trung gian ở mỗi bước. Điều này khiến ngữ cảnh trước đó được xử lý lặp lại.
Prompt caching có giảm sử dụng context window không?
Không. Prompt caching có thể giảm giá hiệu dụng hoặc độ trễ của đầu vào lặp lại, nhưng token được cache vẫn là một phần của ngữ cảnh đã xử lý. Dùng nén, lọc hoặc truy xuất chọn lọc để giảm kích thước prompt.
Khi nào tác nhân AI nên nén ngữ cảnh?
Nén trước khi tăng trưởng ngữ cảnh bắt đầu ảnh hưởng đến chi phí, độ trễ hoặc không gian đầu ra còn lại. Xác minh rằng trạng thái đã nén giữ các quyết định, ID bằng chứng, tệp đã thay đổi, câu hỏi còn mở và ràng buộc an toàn.
Tác nhân con có giảm chi phí token không?
Không tự động. Chúng có thể giảm thời gian trôi qua hoặc cải thiện độ bao phủ cho công việc độc lập, nhưng ngữ cảnh trùng lặp và phân tích chồng chéo thường làm tăng tổng số token sử dụng.
Chỉ số tốt nhất để tối ưu chi phí tác nhân AI là gì?
Dùng chi phí trên mỗi tác vụ thành công làm chỉ số chính. Chẩn đoán bằng tổng đầu vào, khuếch đại ngữ cảnh, tỷ lệ giữ công cụ, thuế retry, tỷ trọng lập luận, độ trễ và thời gian con người rà soát.