·

Introduction: Bài toán ngân sách Token cho Agentic System

Nếu bạn từng nhìn vào bill API của một AI agent chạy production và tự hỏi "sao con số này lại lớn đến vậy", thì bạn không đơn độc. Khác với một lệnh gọi LLM đơn lẻ (single-turn call) — nơi bạn gửi một prompt, nhận một response, và tính được chi phí gần như ngay lập tức — một agentic loop (chu trình lặp của agent) là một chuỗi các lệnh gọi model nối tiếp nhau, mỗi lệnh gọi lại "kế thừa" toàn bộ lịch sử của các lệnh gọi trước đó dưới dạng context. Đây chính là gốc rễ của bài toán ngân sách token trong agentic system.

Điều làm cho vấn đề này khó nhận ra là: từng bước riêng lẻ trông có vẻ rẻ. Một lần gọi tool để đọc file, một lần suy luận ngắn để quyết định bước tiếp theo — mỗi thứ chỉ tốn vài trăm đến vài nghìn token. Nhưng khi agent phải thực hiện 15-30 vòng lặp để hoàn thành một task thực tế (ví dụ: sửa một bug xuyên suốt nhiều file, hoặc research và tổng hợp thông tin từ nhiều nguồn), thì chi phí không cộng dồn theo kiểu tuyến tính — nó tăng theo cấp số nhân gần đúng, vì context window (cửa sổ ngữ cảnh) của mỗi lượt gọi bao gồm toàn bộ những gì đã xảy ra trước đó.

Đây là lý do tại sao một kỹ sư senior, một QA lead, hay một product manager đang chịu trách nhiệm về chi phí vận hành AI agent trong tổ chức đều cần hiểu rõ "giải phẫu" của agentic loop — không phải để tối ưu vi mô từng token, mà để biết mình nên can thiệp ở đâu để có ROI (tỷ suất lợi nhuận đầu tư) tốt nhất. Có ba câu hỏi cốt lõi mà bài học này sẽ giúp bạn trả lời:

  1. Token bị tiêu thụ ở giai đoạn nào trong vòng lặp — Plan (lập kế hoạch), Execute (thực thi), hay Verify (kiểm chứng)?
  2. Tại sao chi phí token lại tăng "phi tuyến" (non-linear) theo số vòng lặp, chứ không phải tăng đều?
  3. Những chi phí "ẩn" nào (như tool schema — định nghĩa cấu trúc tool) lặp lại ở MỌI vòng lặp mà bạn có thể không nhận ra?

Chúng ta sẽ đi qua từng phần một cách chi tiết, có ví dụ số liệu cụ thể, có code minh họa bằng LangGraph, và có phương pháp đo lường thực tế mà bạn có thể áp dụng ngay trên hệ thống của mình.

Mẹo

  • Trước khi tối ưu bất cứ thứ gì, hãy đo lường trước. Rất nhiều team nhảy vào việc "cắt giảm prompt" hay "giảm số tool" mà không biết chính xác token đang tiêu ở đâu — kết quả là tối ưu sai chỗ, tốn effort mà hiệu quả không đáng kể.
  • Luôn phân biệt rõ giữa token input (những gì gửi lên model, bao gồm toàn bộ lịch sử) và token output (những gì model sinh ra). Trong agentic loop, phần input thường chiếm 80-95% tổng chi phí vì nó tích lũy qua từng vòng, còn output mỗi vòng thường tương đối ổn định.
  • Ghi lại số liệu token theo từng vòng lặp (per-iteration) ngay từ ngày đầu triển khai agent, đừng chờ đến khi bill tăng vọt mới bắt đầu quan tâm.

Ba giai đoạn của Agentic Loop và Chi phí Token tương ứng

Mọi agentic loop, dù được xây bằng framework nào (LangGraph, CrewAI, AutoGen, hay một custom loop tự viết), đều có thể quy về ba giai đoạn logic lặp đi lặp lại: Plan (lập kế hoạch), Execute (thực thi), và Verify (kiểm chứng). Đây không phải là ba bước tách biệt hoàn toàn về thời gian — trong nhiều triển khai thực tế, cả ba được gộp vào một lệnh gọi model duy nhất (model tự quyết định plan, chọn tool để execute, và tự đánh giá kết quả trong cùng một lần suy luận). Nhưng về mặt tiêu thụ token, tách riêng ba giai đoạn này giúp ta nhìn rõ nguồn gốc chi phí.

Phase 1: Plan (Lập kế hoạch)

Giai đoạn Plan là lúc model "suy nghĩ" — phân tích task hiện tại, xem lại trạng thái đã có, và quyết định hành động tiếp theo. Đây là giai đoạn tiêu thụ token input lớn nhất vì nó phải "nạp" lại toàn bộ:

  • System prompt (chỉ dẫn hệ thống) — thường 500-3.000 token tùy độ phức tạp của agent.
  • Tool schema của toàn bộ tool khả dụng — sẽ nói kỹ ở phần sau, nhưng đây là chi phí đáng ngạc nhiên.
  • Lịch sử hội thoại/hành động từ đầu task đến giờ — phần này phình to nhất theo thời gian.
  • Task hiện tại và bất kỳ ràng buộc (constraint) nào.

Với các model hỗ trợ "extended thinking" hoặc chain-of-thought (suy luận từng bước) rõ ràng, giai đoạn Plan còn sinh ra một lượng token output đáng kể — model có thể viết ra vài trăm token lý luận trước khi đưa ra quyết định cuối. Ví dụ thực tế: với một task debug production đơn giản, bước Plan đầu tiên có thể chỉ tốn 1.200 token input / 300 token output. Nhưng đến vòng lặp thứ 10, token input cho riêng bước Plan có thể đã lên tới 18.000-25.000 token, vì toàn bộ lịch sử 9 vòng trước đó đều phải được "nhắc lại" cho model.

Phase 2: Execute (Thực thi)

Giai đoạn Execute là khi agent thực sự gọi tool — đọc file, chạy command, query database, gọi API bên ngoài. Về bản chất, giai đoạn này không tiêu tốn token của LLM một cách trực tiếp (việc chạy tool diễn ra bên ngoài model), NHƯNG kết quả trả về của tool (tool output/tool result) mới là nguồn chi phí thực sự — và đây thường là nguồn tiêu thụ token bị đánh giá thấp nhất.

Hãy tưởng tượng agent chạy lệnh grep -r "TODO" trên một repo lớn và nhận về 400 dòng kết quả, hoặc đọc một file log dài 5.000 dòng để tìm nguyên nhân lỗi. Toàn bộ output đó — có thể lên tới 8.000-15.000 token — sẽ được đưa vào context cho vòng lặp tiếp theo. Nếu agent không có chiến lược tóm tắt hay lọc bớt, mỗi lần gọi tool "nặng" như vậy sẽ cộng thêm một khối token khổng lồ vào ngân sách, và khối đó sẽ tiếp tục được mang theo ở TẤT CẢ các vòng lặp sau.

Phase 3: Verify (Kiểm chứng)

Giai đoạn Verify là khi agent (hoặc một cơ chế riêng, như một "critic model" hay unit test) đánh giá xem hành động vừa thực hiện có đạt được mục tiêu không, có cần thử lại hay không. Trong nhiều hệ thống agentic hiện đại, giai đoạn này lại chính là nơi phát sinh token lặp lại nhiều nhất — vì để kiểm chứng, model cần nhìn lại cả kết quả Execute (có thể rất dài) VÀ kế hoạch ban đầu (Plan) để so sánh.

Một pattern phổ biến: agent verify bằng cách tự hỏi lại chính nó "Kết quả này đã giải quyết được task chưa?" — câu hỏi tưởng đơn giản, nhưng context đưa vào để trả lời câu hỏi đó lại bao gồm toàn bộ lịch sử. Nếu giai đoạn Verify được thực hiện bởi một lệnh gọi model riêng (thay vì gộp vào Plan), bạn đang nhân đôi chi phí "nạp lại lịch sử" cho mỗi vòng lặp.

Mẹo

  • Nếu framework của bạn cho phép, hãy log riêng token input/output cho từng giai đoạn Plan/Execute/Verify. Rất nhiều team chỉ thấy tổng token/request mà không biết giai đoạn nào đang "ăn" nhiều nhất.
  • Với giai đoạn Execute, luôn đặt câu hỏi: "Tool này có cần trả về TOÀN BỘ kết quả không, hay chỉ cần phần liên quan?" — Đây là điểm tối ưu có ROI cao nhất trong toàn bộ vòng lặp, vì tool output thường là phần token dễ cắt giảm nhất mà ít ảnh hưởng đến chất lượng.
  • Nếu bạn tách Verify thành một lệnh gọi model riêng, cân nhắc dùng một model nhỏ hơn/rẻ hơn cho việc kiểm chứng (vì task này thường đơn giản hơn task Plan), hoặc gộp Verify vào ngay trong response của Execute để tránh nạp lại context hai lần.

Tích lũy Token: Bài toán tăng trưởng kiểu Compounding

Đây là phần quan trọng nhất để hiểu tại sao chi phí agentic loop lại "vượt tầm kiểm soát" nhanh đến vậy. Trong một lệnh gọi LLM đơn lẻ, chi phí input là cố định. Nhưng trong agentic loop theo mô hình phổ biến nhất — append-only context (chỉ nối thêm, không xóa) — context của vòng lặp N bao gồm TOÀN BỘ context của vòng lặp N-1, cộng thêm hành động và kết quả mới.

Nói cách khác, nếu vòng lặp 1 tốn X token input, thì token input của vòng lặp N sẽ xấp xỉ:

Token_input(N) ≈ X + (N-1) × ΔT

Trong đó ΔT là lượng token trung bình được thêm vào mỗi vòng (tool schema cố định + tool result mới + phần suy luận mới). Vấn đề là tổng token tiêu thụ cho toàn task lại là tổng của một cấp số cộng:

Tổng_token = Σ Token_input(i)  với i = 1 đến N
           ≈ N × X + ΔT × N(N-1)/2

Nhìn vào công thức, phần N(N-1)/2 chính là "quả bom nổ chậm" — nó tăng theo bình phương của số vòng lặp. Hãy xem một ví dụ số cụ thể để thấy điều này rõ hơn:

Vòng lặp Token input (vòng này) Token input lũy kế (tổng)
1 3.200 3.200
5 9.800 32.400
10 18.600 118.500
15 27.400 260.700
20 36.200 458.000

Chỉ với 20 vòng lặp — một con số hoàn toàn bình thường cho một task coding thực tế có vài lần thử-sai — tổng token input đã tích lũy tới gần 458.000 token, dù mỗi vòng lặp riêng lẻ chỉ tăng thêm khoảng 8.800 token so với vòng trước. Đây chính là lý do tại sao các agent "chạy lâu" (long-running agent) lại có bill cao đột biến so với dự đoán ban đầu — chi phí không tăng tuyến tính theo số vòng, mà tăng theo cấp số tam giác (triangular growth).

Có ba yếu tố chính đẩy nhanh tốc độ tăng trưởng này:

  1. Tool result không được cắt gọt — mỗi lần gọi tool trả về nhiều dữ liệu thô hơn cần thiết.
  2. Không có cơ chế nén/tóm tắt lịch sử (context compaction) — lịch sử cũ không bao giờ được rút gọn, dù nó đã không còn liên quan trực tiếp đến bước hiện tại.
  3. Task decomposition kém (chia nhỏ task không hiệu quả) — task không được chia thành các sub-task (task con) độc lập, nên toàn bộ agent phải "nhớ" mọi thứ trong một vòng lặp duy nhất kéo dài.

Mẹo

  • Vẽ biểu đồ token lũy kế theo số vòng lặp cho một vài task thực tế của hệ thống bạn. Nếu đường cong đó cong lên rõ rệt (không phải đường thẳng), bạn đang gặp đúng vấn đề compounding growth này.
  • Đặt một "ngưỡng cảnh báo" (ví dụ: khi token lũy kế vượt 100.000) để trigger việc tóm tắt lại lịch sử hoặc bắt đầu một sub-agent session mới với context gọn hơn — đừng để agent tự do chạy đến khi hết context window.
  • Nhớ rằng chi phí không chỉ là tiền — context quá dài còn làm tăng latency (độ trễ) của mỗi lệnh gọi và có thể làm giảm chất lượng suy luận của model do hiện tượng "lost in the middle" (model bỏ sót thông tin ở giữa context dài).

Giải phẫu một lệnh gọi Agentic thực tế: Ví dụ với LangGraph

Để không chỉ nói lý thuyết, hãy cùng bóc tách một vòng lặp agentic được xây bằng LangGraph — một trong những framework orchestration (điều phối) phổ biến nhất hiện nay cho việc xây dựng agent có trạng thái (stateful agent).

Trong LangGraph, một agent loop điển hình được mô hình hóa như một graph với các node: agent (nơi model suy luận và quyết định), tools (nơi tool được thực thi), và các cạnh có điều kiện (conditional edge) quyết định khi nào lặp lại hay kết thúc. Điểm quan trọng cần lưu ý: state (trạng thái) của graph — thường là danh sách message — được truyền lại toàn bộ vào node agent ở MỖI vòng lặp.

from langgraph.graph import StateGraph, END
from langchain_core.messages import HumanMessage

def agent_node(state):
    messages = state["messages"]  # entire accumulated history, sent as-is
    # This call re-sends: system prompt + all tool schemas + full message history
    response = llm_with_tools.invoke(messages)

    # Token accounting per call — this is what you should be logging
    usage = response.usage_metadata
    print(f"[Iteration {state['iteration']}] "
          f"input_tokens={usage['input_tokens']}, "
          f"output_tokens={usage['output_tokens']}")

    return {"messages": [response], "iteration": state["iteration"] + 1}

def tool_node(state):
    last_message = state["messages"][-1]
    results = []
    for tool_call in last_message.tool_calls:
        # Tool output gets appended to history — this is the "hidden" cost
        # that compounds in every subsequent call
        result = execute_tool(tool_call)
        results.append(result)
    return {"messages": results}

def should_continue(state):
    last_message = state["messages"][-1]
    if not last_message.tool_calls:
        return END  # Verify implicitly happens here: model decided task is done
    if state["iteration"] > 25:
        return END  # safety cap to avoid runaway loops
    return "tools"

graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", tool_node)
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")  # loop back — full history re-sent next time

Điểm mấu chốt cần rút ra từ đoạn code trên: node tools KHÔNG gọi LLM, nên về mặt cảm quan ta dễ nghĩ nó "miễn phí". Nhưng kết quả result mà nó append vào state["messages"] sẽ được gửi lại — trọn vẹn — cho MỌI lệnh gọi agent_node tiếp theo. Nếu một tool trả về 6.000 token dữ liệu thô, con số đó sẽ xuất hiện lại trong input token của tất cả các vòng lặp còn lại của task, không chỉ vòng mà nó được sinh ra.

Việc log usage_metadata ở mỗi vòng (như ví dụ trên) là bước đầu tiên và quan trọng nhất để hiểu chi phí thực tế của agent bạn — hầu hết framework hiện đại đều expose thông tin này, chỉ là nhiều team không bật log nó lên.

CrewAI và AutoGen khác nhau ở đâu?

Dù cùng giải quyết vấn đề orchestration multi-step, ba framework này có mô hình quản lý context khác nhau, dẫn đến pattern tiêu thụ token khác nhau:

  • LangGraph: Quản lý state một cách rõ ràng (explicit state graph) — bạn có toàn quyền kiểm soát việc gì được đưa vào state["messages"] ở mỗi bước. Đây là ưu điểm lớn cho việc tối ưu token: bạn có thể viết logic để cắt gọt, tóm tắt, hoặc lọc bớt state trước khi nó vào node agent tiếp theo. Nhưng đi kèm với đó là bạn phải TỰ chịu trách nhiệm implement việc tối ưu này — framework không tự làm thay.

  • CrewAI: Được thiết kế xoay quanh khái niệm "crew" — nhiều agent có vai trò (role) riêng, phối hợp qua các task được giao tuần tự hoặc song song. Mỗi agent trong crew thường có context RIÊNG (không dùng chung một lịch sử khổng lồ), nên về lý thuyết, tổng token có thể thấp hơn một agent loop đơn lẻ chạy dài — NHƯNG chi phí lại chuyển sang một dạng khác: token cho việc "bàn giao" (handoff) kết quả giữa các agent, và mỗi agent trong crew đều phải nạp lại system prompt/tool schema riêng của nó khi được gọi.

  • AutoGen: Dùng mô hình hội thoại multi-agent (multi-agent conversation), nơi các agent "nói chuyện" với nhau qua message. Điểm khác biệt lớn nhất về token: trong nhiều thiết lập AutoGen, TẤT CẢ agent tham gia group chat đều nhìn thấy TOÀN BỘ lịch sử hội thoại của group — nghĩa là nếu bạn có 4 agent trong một group chat kéo dài 15 lượt, chi phí input token có thể nhân lên gấp nhiều lần so với một agent loop đơn (vì mỗi agent, ở lượt nói của mình, đều phải "đọc" lại toàn bộ hội thoại của cả nhóm).

Kết luận thực tế: không có framework nào "rẻ hơn" một cách tuyệt đối — mỗi framework đánh đổi độ phức tạp quản lý context để lấy sự tiện lợi trong việc mô hình hóa vai trò/luồng làm việc. Việc bạn chọn framework nào nên dựa trên bản chất task, KHÔNG nên chỉ dựa trên chi phí token, nhưng bạn PHẢI hiểu rõ mô hình context của framework đã chọn để biết mình cần tối ưu ở đâu.

Mẹo

  • Luôn bật (hoặc tự implement) logging usage_metadata/token accounting ở mỗi node hoặc mỗi lệnh gọi model — dù bạn dùng LangGraph, CrewAI hay AutoGen. Không có số liệu, không có cách tối ưu.
  • Nếu dùng AutoGen với group chat nhiều agent, kiểm tra kỹ cấu hình speaker_selection và cân nhắc giới hạn số agent thấy được toàn bộ lịch sử — chuyển sang mô hình broadcast có chọn lọc (selective broadcast) nếu framework hỗ trợ.
  • Nếu dùng CrewAI, đo riêng token cho "task handoff" giữa các agent — đây thường là chi phí ẩn mà đội ngũ ít để ý vì nó không nằm trong "vòng lặp chính".

Chi phí Tool Schema: Thứ thuế ẩn lặp lại ở mọi vòng lặp

Đây có thể là phần gây bất ngờ nhất trong toàn bài học này: tool schema — phần định nghĩa cấu trúc, tên, mô tả, và tham số của mỗi tool mà agent có thể gọi — được gửi lại TOÀN BỘ ở MỌI lệnh gọi model, bất kể vòng lặp đó agent có dùng đến tool nào hay không.

Hãy nghĩ về nó như một loại "thuế cố định" (fixed tax) mà bạn phải trả ở mỗi vòng lặp, không phụ thuộc vào việc bạn có sử dụng "dịch vụ" đó hay không. Với một agent có khoảng 12 tool được đăng ký (một số lượng khá bình thường cho một coding agent hoặc research agent thực tế: đọc file, viết file, chạy shell command, search code, gọi web search, query database, v.v.), mỗi tool schema — bao gồm tên, description, và JSON schema định nghĩa tham số — có thể tốn trung bình 250-450 token, tùy vào độ chi tiết của description và số lượng tham số.

Hãy làm một phép tính minh họa cụ thể:


TOOLS = [
    "read_file", "write_file", "edit_file", "run_shell_command",
    "search_codebase", "web_search", "query_database", "list_directory",
    "run_tests", "git_diff", "create_pull_request", "send_notification"
]  # 12 tools registered on this agent

schema_tokens_per_tool = {
    "read_file": 210, "write_file": 265, "edit_file": 390,
    "run_shell_command": 340, "search_codebase": 480, "web_search": 310,
    "query_database": 520, "list_directory": 180, "run_tests": 295,
    "git_diff": 220, "create_pull_request": 410, "send_notification": 240,
}

total_schema_tokens = sum(schema_tokens_per_tool.values())
print(f"Total tool schema tokens per call: {total_schema_tokens}")

iterations = 20
cumulative_schema_cost = total_schema_tokens * iterations
print(f"Cumulative schema cost across {iterations} iterations: {cumulative_schema_cost}")

Với ví dụ minh họa trên, chỉ riêng tool schema — chưa tính system prompt, chưa tính lịch sử hội thoại, chưa tính tool result — đã tiêu tốn khoảng 3.861 token cho mỗi vòng lặp, và lũy kế tới 77.220 token sau 20 vòng. Đây là chi phí "vô hình" theo nghĩa: nó không xuất hiện rõ trong bất kỳ đoạn hội thoại nào bạn nhìn thấy trên UI, nhưng nó vẫn nằm trong bill, ở MỌI lệnh gọi, kể cả những vòng lặp mà agent chỉ trả lời bằng text mà không gọi tool nào.

Vài quan sát thực tế quan trọng:

  • Chi phí này KHÔNG giảm dù agent chỉ dùng 1-2 trong số 12 tool ở suốt task. Model vẫn cần "nhìn thấy" toàn bộ danh sách tool để biết nó có những lựa chọn nào.
  • Description của tool dài dòng, chứa nhiều ví dụ sử dụng chi tiết trong chính schema, sẽ đẩy chi phí này lên đáng kể. Đây là điểm dễ tối ưu nhất trong toàn bộ agentic loop, vì nó không đòi hỏi thay đổi logic — chỉ cần viết description ngắn gọn hơn.
  • Nếu hệ thống của bạn dùng prompt caching (cơ chế cache phần đầu của prompt để tránh tính lại token cho phần không đổi), tool schema — vì nó thường KHÔNG đổi qua các vòng lặp — là ứng viên lý tưởng nhất để đặt vào phần được cache, giúp giảm đáng kể chi phí thực tế (dù token "logic" vẫn được tính, chi phí billing cho phần cache-hit thường rẻ hơn nhiều).

Mẹo

  • Định kỳ audit (rà soát) danh sách tool đang đăng ký cho agent — rất nhiều hệ thống "tích lũy" tool qua thời gian mà không ai gỡ bớt tool không còn dùng, khiến thuế ẩn này ngày càng nặng.
  • Rút ngắn description của tool xuống mức tối thiểu cần thiết để model hiểu đúng công năng — tránh nhồi ví dụ dài dòng vào chính schema; ví dụ sử dụng nên nằm ở system prompt (nếu cần) chứ không nằm trong định nghĩa tool.
  • Luôn tận dụng prompt caching cho phần tool schema + system prompt nếu nền tảng model bạn dùng hỗ trợ — đây là một trong những tối ưu có ROI cao nhất mà hầu như không tốn effort kỹ thuật.

Đo lường phân bổ Token trong hệ thống của bạn

Lý thuyết chỉ có giá trị khi bạn áp dụng được vào hệ thống thật. Dưới đây là quy trình từng bước để bạn tự đo lường phân bổ token trong agentic loop của mình:

Bước 1 — Bật usage tracking ở mọi lệnh gọi model. Hầu hết SDK (bao gồm Anthropic, OpenAI) đều trả về usage object (chứa input_tokens, output_tokens, và nếu có, cache_read_input_tokens) trong mỗi response. Đảm bảo bạn log đầy đủ thông tin này, kèm timestamp và số thứ tự vòng lặp (iteration index).

Bước 2 — Gắn tag cho từng loại chi phí. Thay vì chỉ log tổng token, hãy phân loại: token cho system prompt, token cho tool schema (có thể đo riêng bằng cách tokenize schema độc lập trước khi gửi), token cho lịch sử hội thoại tích lũy, và token cho tool result mới nhất. Việc này đòi hỏi một chút công cụ đo (instrumentation) thêm, nhưng chỉ cần làm một lần.

Bước 3 — Chạy một tập task đại diện (representative task set) và thu thập số liệu qua nhiều vòng lặp. Đừng chỉ đo một task đơn giản 3 vòng lặp rồi kết luận — hãy đo cả những task phức tạp thực tế kéo dài 15-25 vòng, vì đó là nơi compounding growth thể hiện rõ nhất.

Bước 4 — Vẽ biểu đồ token theo vòng lặp, tách riêng từng loại chi phí. Một biểu đồ dạng stacked area chart (biểu đồ vùng xếp lớp) theo thời gian, với các lớp là "system+schema", "history", "tool result", "output" sẽ cho bạn thấy ngay lớp nào đang phình to nhanh nhất.

Bước 5 — Tính tỷ lệ chi phí cố định (fixed tax) so với chi phí biến động. Chia tổng token cho tool schema + system prompt (chi phí không đổi mỗi vòng) trên tổng token toàn task. Nếu tỷ lệ này vượt 15-20% ở các task ngắn (dưới 5 vòng), bạn đang có một "thuế cố định" quá nặng so với giá trị công việc thực tế đang làm — đây là dấu hiệu cần cắt gọn tool schema hoặc tách agent thành các agent chuyên biệt (specialized agent) với ít tool hơn mỗi agent.

Bước 6 — Thiết lập baseline và theo dõi theo thời gian. Token consumption không phải chỉ số đo một lần — nó thay đổi khi bạn thêm tool mới, đổi model, hay thay đổi logic prompt. Đưa việc theo dõi này vào dashboard vận hành (operational dashboard) thường xuyên, giống như bạn theo dõi latency hay error rate.

Mẹo

  • Nếu team bạn dùng LangSmith, LangFuse, hoặc các nền tảng observability (khả năng quan sát) tương tự cho LLM app, hãy tận dụng tính năng trace theo từng span — chúng thường đã có sẵn breakdown token theo từng bước, tiết kiệm bạn công viết instrumentation từ đầu.
  • Đo lường trên môi trường staging với dữ liệu thực tế (hoặc gần thực tế) trước khi kết luận — task giả lập quá đơn giản trong môi trường dev thường không phản ánh đúng compounding growth mà production task thực sự gặp phải.
  • Chia sẻ số liệu đo lường này với cả team, không chỉ riêng người viết agent — QA, product manager cũng cần hiểu con số này để đưa ra quyết định đúng về việc chấp nhận độ trễ/chi phí nào là hợp lý cho từng use case.

Key Takeaways

  • Agentic loop gồm ba giai đoạn lặp lại — Plan, Execute, Verify — và mỗi giai đoạn có đặc điểm tiêu thụ token khác nhau: Plan tốn token vì phải nạp lại toàn bộ context, Execute tốn token ẩn qua tool result, Verify thường nhân đôi chi phí nạp lại lịch sử nếu tách thành lệnh gọi riêng.
  • Vì mô hình append-only context phổ biến trong hầu hết framework, tổng token tiêu thụ cho một task tăng theo cấp số tam giác (bậc hai theo số vòng lặp), không phải tuyến tính — đây là nguyên nhân chính khiến bill agent "nổ" nhanh hơn dự đoán.
  • LangGraph, CrewAI, AutoGen có mô hình quản lý context khác nhau (state graph rõ ràng, context riêng theo agent, hay group chat chia sẻ toàn bộ lịch sử) — hiểu đúng mô hình framework bạn dùng là điều kiện tiên quyết để biết nên tối ưu ở đâu.
  • Tool schema là một "thuế cố định" lặp lại ở MỌI vòng lặp, bất kể tool có được dùng hay không — với một agent có khoảng 12 tool, chi phí này có thể lên tới vài nghìn token mỗi vòng và hàng chục nghìn token lũy kế qua một task dài; đây cũng là điểm dễ tối ưu nhất (rút ngắn description, dùng prompt caching).
  • Đo lường luôn phải đi trước tối ưu: bật usage tracking, phân loại chi phí theo nguồn (schema, history, tool result, output), và theo dõi liên tục theo thời gian — đừng tối ưu dựa trên cảm tính hay chỉ dựa vào tổng bill cuối tháng.
Tiếp