GPT-5.6 Luna price down 80%, Terra down 20% →

如何在生產環境中降低 AI Agent 的 Token 成本

CometAPI
Mia MarenAug 5, 2026
如何在生產環境中降低 AI Agent 的 Token 成本

TL;DR

當每一步都反覆處理指令、對話歷史、工具結果與中間狀態時,AI agent 的 token 成本會增長。

透過執行層級預算、工具結果過濾、上下文壓縮、重試上限與受控推理來降低 token 量。對於穩定且重複的輸入使用提示快取,但在換更便宜的模型之前,先優化 agent 的迴圈。

最有用的產線指標是整個執行的「每個成功任務的成本」,而不是每次請求的單價或最終一次呼叫的上下文大小。

本指南專注於多步驟 AI agent。說明重覆上下文如何在整個執行中疊加、如何找出最大的浪費來源,以及應先實施哪些控制。

Introduction

一個聊天機器人可能對每條使用者訊息只發出一次模型請求。一個 AI agent 在完成一項任務前,可能會呼叫模型 10、20 次以上。

每一步都可能重送指令、對話歷史、工具結果與中間狀態。重試、推理與子代理會帶來更多用量,因此即使最終答案很短,也可能消耗大量 token。

隨著用量規模增加,這些成本更難預測,且會很快壓縮產品毛利。要降低成本,必須優化整個 agent 迴圈,而不是單純換成更便宜的模型。

本文聚焦於 Agent 特有的成本。若需更廣泛的指南(涵蓋提示快取、精確回應快取、語意快取、模型路由與一般 API 成本管理),請參見如何降低 AI API 成本

Why Do AI Agent Token Costs Compound?

在多步驟 agent 中,一個任務的成本是每次模型呼叫的總和—不僅僅是最後一次回應。

Agent token 用量的主要來源包括:

Cost sourceWhat causes itFirst control to test
重複的指令系統提示、工具結構、政策、範例穩定可重用前綴
歷史成長較早的回合在每一步都被重送壓縮或選擇性擷取狀態
工具結果搜尋頁面、檔案、日誌與資料庫紀錄在加入上下文前先過濾
中間輸出規劃、狀態訊息、冗長的工具決策使用精簡的結構化輸出
推理 tokens在例行步驟投入過高的推理讓推理投入匹配任務複雜度
重試無效輸出、逾時、工具錯誤與速率限制分類失敗並為重試設上限
子代理工作者重複上下文、工具與分析僅傳遞與任務相關的狹窄上下文切片

降低費用有兩種截然不同的方式:

  1. 透過過濾、壓縮、輸出上限與迴圈控制「處理更少的 token」。
  2. 透過提示快取或模型選擇「降低必要 token 的有效價格」。

關鍵區別:提示快取降低重複輸入的價格;上下文壓縮則是減少重複輸入本身。

How Can a 12-Step Agent Process 147,000 Tokens?

考慮一個假想的客服 agent,具備:

  • 穩定前綴 4,000 token
  • 每一步新增 1,500 token
  • 每次請求都重送累積的完整歷史
  • 總共 12 次模型呼叫

n 步的輸入為:

Input at step n = 4,000 + 1,500 × (n - 1)

12 次呼叫的累積輸入為:

Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens

最終一次呼叫僅包含「20,500 input tokens」,但整個執行共處理了「147,000 cumulative input tokens」。

現在套用兩個控制:

  1. 在第一次呼叫後快取穩定的 4,000-token 前綴。
  2. 在第六步之後,將歷史壓縮為 2,500-token 的狀態摘要。
ScenarioUncached inputCached inputTotal processed inputChange
每一步都使用完整歷史147,0000147,000基準
穩定前綴已快取103,00044,000147,000量相同、組合更便宜
快取加上壓縮64,00044,000108,000「處理的 token 減少 26.5%」

這是規劃用的試算,非供應商基準。

此假設每次請求都包含累積的完整歷史。若 agent 選擇性建構狀態、摘要舊訊息或只檢索相關資訊,成本曲線可能不同。

成本成長規則:衡量整個執行的累積輸入;最終上下文大小無法代表處理的總 token 數。

img

Which Metrics Reveal Agent Token Waste?

不要一開始就換模型。先找出工作流程在哪裡耗費 token 卻沒有改善結果。

針對每個 agent 步驟記錄以下欄位:

FieldWhy it matters
run_id, step_id, parent_step_id重建 agent 與子代理的樹狀關係
Rendered input tokens顯示每次呼叫之間上下文如何成長
Cached and uncached input區分可重用與新加入的上下文
Output and reasoning tokens辨識代價高的生成步驟
Tool result size and retained tokens顯示有多少原始證據進入後續提示
Retry reason and attempt number辨識反覆失敗
Compaction tokens before and after衡量上下文實際縮減量
Worker ID and returned tokens揭示子代理重工
Accepted, rejected, or escalated result將成本與任務品質相連結

主要指標應為:

cost per successful task
= total workflow cost
/ accepted tasks

若導致更多失敗任務、重複工具呼叫或需要人工修正,單次執行更便宜並不算改善。

四個 agent 特有的指標有助定位問題。

Context Amplification

context amplification
= cumulative input tokens
/ final-step input tokens

數值高表示較早的上下文被反覆處理。

Tool Retention Ratio

tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools

比率高可能表示 agent 在步驟間攜帶過多原始證據。

Retry Tax

retry tax
= retry and repair cost
/ total workflow cost

Reasoning Share

reasoning share
= reasoning-token cost
/ total model cost

請分別衡量各類工作負載。研究、寫程式、瀏覽器、自助客服等 agent 不應共用同一個全域基準。

Six Ways to Reduce AI Agent Token Costs

1. Set a Budget for the Complete Run

單次回應的輸出上限無法控制多步驟 agent。

為下列項目設定執行層級上限:

  • 總模型步數
  • 累積輸入與輸出
  • 工具呼叫次數與工具結果大小
  • 依失敗類型設定的重試次數
  • 子代理
  • 總耗時或預估成本

以下與供應商無關的 Python 範例會在每次模型呼叫前評估執行狀態:

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

在每次模型請求前執行檢查,並用供應商回報的 token 資料更新 Usage

當輸入用量達到預算的 80%,壓縮狀態或縮小下一次的工具查詢;達到 100% 則以結構化原因停止。

Common mistake: 只限制每次回應,卻允許無限制的步驟、工具與重試。

2. Filter Tool Results Before They Enter the Transcript

僅回傳 agent 下一個決策所需的證據。

不要把整個:

  • 網頁
  • 日誌檔
  • 倉庫樹
  • 資料庫回應
  • 終端機工作階段
  • API 載荷

直接附加到提示中,當下一步只需要少數欄位時。

搜尋工具可以回傳:

{
  "source_id": "search_17",
  "title": "Relevant page title",
  "url": "https://example.com/page",
  "relevant_passage": "A short evidence block"
}

將完整素材儲存在提示之外,並在需要時再取用更窄的片段。

工具過濾規則:回傳下一個決策需要的欄位,而非所有未來可能用到的欄位。

Common mistake: 截斷 JSON 載荷前 1,000 個字元。這可能破壞結構,或刪掉 agent 真正需要的紀錄。

請先解析載荷、以結構方式選取欄位、限制陣列大小,再序列化為有效的 JSON。

3. Compact Operational State, Not Just Conversation Text

壓縮應保留繼續任務所需的資訊,同時移除不再影響下一步行動的歷史。

一個有用的壓縮狀態應包含:

  • 使用者目標與成功準則
  • 已作出的決策
  • 經驗證的事實與來源 ID
  • 已變更的檔案或紀錄
  • 失敗過的嘗試
  • 未解決的問題
  • 下一步行動
  • 安全性與輸出限制

它不應重述完整對話。

OpenAI 文件說明了長時間 Responses API 互動的壓縮方式。Anthropic 提供清除或摘要舊內容的上下文管理控制。兩者實作不同,整合前請確認當前的供應商欄位。

壓縮規則:保留決策與未完成的工作;移除可再次檢索的敘述與證據。

Common mistake: 遺漏來源 ID、變更的檔名、被否決的做法或未解決的限制條件。

加入壓縮後,量測 agent 是否重複搜尋或呼叫工具。若必須重建遺失的狀態,提示縮短不見得更省。

4. Keep the Reusable Prefix Stable

Agent 提示常包含大型可重用區塊:

  • 系統指令
  • 工具結構
  • 安全政策
  • 輸出格式
  • 共享參考資料
  • 倉庫或產品說明

將這些穩定元素放在請求特定資料之前:

1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data

避免把時間戳、請求 ID、工作階段資料或經常變動的值放在開頭。

當前綴長、穩定且可重用時,快取最有用。對於短會話或頻繁變動的提示,快取未必省錢。

Common mistake: 只優化快取命中率,卻未衡量快取寫入、讀取或存儲成本。

若需更廣泛比較供應商的提示快取、精確回應快取與語意快取,請參見如何降低 AI API 成本

5. Prevent Retries From Replaying the Same Context

重試是另一個 agent 步驟,且往往帶著同樣龐大的提示。

不要在未改變失敗原因的情況下重試。

FailureBetter response
結構化輸出無效回傳驗證錯誤並重試一次
工具逾時對冪等操作重試一次,之後停止或使用後備方案
上下文溢出壓縮狀態或減少取回的證據
重複的工具呼叫使用操作雜湊值去重
速率限制退避或使用已驗證的後備路由
低信心結果請求缺失資訊或升級處理

對於具副作用的操作(如付款、郵件、部署、資料庫寫入),使用冪等鍵。

Common mistake: 在速率限制下對模型重試多次,且每次都重送整個 agent 上下文。

依失敗類型追蹤重試稅,讓團隊先修補最大的迴圈。

6. Limit Reasoning and Subagents to Steps That Need Them

不是每個 agent 步驟都需要深度推理。

抽取、格式化、分類、驗證與例行的工具選擇,常可使用較低的推理投入與精簡的結構化輸出。

把較高的推理投入留給下列任務:

  • 複雜規劃
  • 難度較高的程式設計
  • 多文件綜整
  • 含糊的決策
  • 從執行失敗中恢復

推理規則:在不降低任務通過率的前提下,使用最低必要的推理投入。

子代理也需要明確邊界。給每位工作者:

  • 狹窄的任務
  • 任務特定的上下文切片
  • 工具允許清單
  • token 預算
  • 精簡的輸出結構

根代理通常需要的是發現、證據 ID、信心與未解決問題,而非工作者的完整對話紀錄。

子代理規則:平行處理相互獨立的工作,而非複製上下文。

Common mistake: 在分派狹窄任務之前,把根代理的完整歷史傳給每個工作者。

Which Optimization Should You Apply First?

使用 agent 遙測來選擇第一個介入點。

以下門檻是調查觸發點,而非通用標準。

Observed signalStart here
上下文放大係數偏高壓縮歷史並選擇性擷取狀態
工具輸出主導了提示過濾欄位並將完整素材儲存在外部
重試稅偏高修正驗證、逾時與重複工具呼叫
推理占比偏高降低例行步驟的推理投入
子代理重覆相同證據縮小工作者範圍與上下文切片
快取輸入仍偏低穩定可重用前綴
迴圈清理後成本仍高比較成本更低的模型路由

安全的實作順序為:

  1. 量測累積輸入、工具保留、重試與推理。
  2. 對步數、工具、重試與總 token 設定硬上限。
  3. 過濾大型工具結果。
  4. 在量測門檻處壓縮較舊的狀態。
  5. 穩定可重用的提示前綴。
  6. 只有在 agent 迴圈乾淨之後,才比較不同模型路由。

一次只改變一個主要變數,並重播相同的評估集。

比較:

  • 任務通過率
  • 每個成功任務的成本
  • 累積輸入
  • 工具呼叫數
  • 重試稅
  • 推理占比
  • p50 與 p95 延遲
  • 人工審核時間

若因節省 token 而降低任務品質或移除必要證據,請回滾變更。

Test Agent Workflows With CometAPI

在進行多模型評估之前,使用 CometAPI 的定價頁成本估算指南來估算輸入、輸出、快取 token 與推理成本。

接著使用模型目錄找出可用路由,並依照快速上手設定相容 OpenAI 的用戶端。

在產線後備方面,請依照 CometAPI 的模型後備指南切換路由,同時避免重做已完成的工具呼叫或丟棄已驗證的狀態。

統一存取能簡化模型比較與後備整合;但 token 預算、壓縮、驗證、工具過濾、重試上限與驗收準則仍應由應用程式層負責。

FAQ

為什麼 AI agents 比聊天機器人使用更多 token?

因為 agent 會多次呼叫模型,且每一步可能重送先前的訊息、工具結果、指令與中間狀態,導致較早的上下文被反覆處理。

提示快取是否會降低上下文視窗用量?

不會。提示快取可降低重複輸入的有效價格或延遲,但被快取的 token 仍是處理上下文的一部分。請用壓縮、過濾或選擇性擷取來縮小提示。

何時應該壓縮 AI agent 的上下文?

在上下文成長開始影響成本、延遲或可用輸出空間之前就壓縮。確認壓縮後仍保留決策、證據 ID、變更的檔案、未解決問題與安全限制。

子代理能降低 token 成本嗎?

不一定。對彼此獨立的工作,它們可能縮短耗時或提升覆蓋,但重複上下文與重疊分析常會增加總 token 用量。

最佳的 AI agent 成本優化指標是什麼?

以「每個成功任務的成本」為主要指標。輔以累積輸入、上下文放大、工具保留、重試稅、推理占比、延遲與人工審核時間進行診斷。

準備好將 AI 開發成本降低 20% 了嗎?

幾分鐘內免費開始。包含免費試用點數。無需信用卡。

閱讀更多