Agent 多輪調用 API 的成本結構是什麼樣的？

作者注：從一個 30 分鐘的軟件開發 Agent 任務出發，拆解 Agent 多輪調用中普通輸入、緩存寫入、緩存讀取、輸出與工具往返的費用構成，對比三家服務商的緩存計費，並用 12 次調用的示例說明緩存在什麼條件下才真正省錢。

2026 年 11 月 9 日，Google Cloud 發佈 TPU 8tx 與 TPU 8i Max 兩套第八代 TPU 系統，同時開源了用於 KV Cache 傳輸的 TPU Sync。“Agent 時代的內存牆”再次成爲話題，很多開發者自然會問：底層 KV Cache 越來越快，我的 Agent API 賬單會不會隨之變便宜？

核心價值：讀完本文，你將拿到一個完整的 Agent 成本公式、三家服務商的緩存計費對照，以及一套可以馬上落地的成本優化清單。

Agent 多輪調用 API 成本：核心信息速覽

Agent 多輪調用的 30 分鐘任務長什麼樣

設想一個軟件開發 Agent 接到需求：修復某個模塊的測試失敗。它先讀取項目結構和相關源碼，生成修改方案，調用工具寫文件、跑測試，等待測試結果，再根據報錯繼續推理。30 分鐘裏，這樣的“推理—工具—等待—推理”循環可能發生十幾次。

問題在於，大模型 API 本質上是無狀態的。每一次請求，Agent 都要把系統提示詞、工具定義、項目背景以及之前的對話和工具輸出重新發給模型。第 12 次請求攜帶的內容，往往包含了前 11 輪幾乎全部的歷史，這就是“上下文重複計算”的來源。

Agent 多輪調用 API 成本由哪些部分組成

把一次 Agent 任務拆開看，費用至少包含五類。前四類是模型 Token 費用，第五類則發生在模型之外，卻常常被忽略。

據此可以寫出一個單任務成本公式：

任務總成本 = Σ（普通輸入 × 輸入單價 + 緩存寫入 × 寫入單價 + 緩存讀取 × 讀取單價 + 輸出 × 輸出單價）+ 工具與外部執行費用

公式中的 Σ 是對任務內每一次模型調用求和。這意味着調用次數本身就是乘數：工具往返越多，模型調用越多，固定前綴被重複計費的次數也越多。工具調用並不只花工具自己的錢，它還會把一次推理拆成多次，每次都要重新攜帶上下文。

Agent 多輪調用中 KV Cache、Prompt Cache 與上下文壓縮的區別

討論 Agent 成本時，三個概念最容易混用。它們分屬不同層面，對賬單的影響也完全不同。

值得注意的是，OpenAI 官方文檔說明 Prompt Cache 實際保存的是 KV Tensor，而不是原始 Token 文本。因此 Prompt Caching 可以理解爲底層 KV 狀態複用能力的服務化與計費化，它與 KV Cache 並非毫無關係，但用戶能感知到的只有計費規則。

上下文壓縮則是另一回事。它改變的是後續請求“攜帶什麼”，而不是“如何複用”。壓縮得越激進，Token 越少，但 Agent 遺忘關鍵細節的風險也越高。

Agent 多輪調用的底層優化爲什麼不等於賬單下降

Google 這次發佈的 TPU 8i Max 將 HBM 帶寬和片上 SRAM 翻倍，TPU Sync 在 Ironwood 平臺的內部測試中將 KV Cache 傳輸延遲降低超過 90%，Agent Compute Engine 則在 Agent 空閒時暫停會話、把工作內存移出芯片。這些優化作用於服務商的資源利用率和推理延遲（例如 TTFT），對用戶可能體現爲更快的響應。

但 API 價格是服務商的商業定價，用戶賬單仍按 Token 計量。硬件效率提升可能在長期內影響定價，卻不存在自動、等比例的傳導關係。另外，TPU 8tx 與 TPU 8i Max 截至 2026-11-10 仍標記爲 Coming soon，尚未公佈價格。對開發者而言，能立刻控制的是自己的 Token 結構，而不是上游的硬件。

Agent 多輪調用 API 成本：三家服務商緩存計費對比

三家主流服務商都提供緩存機制，但觸發方式、TTL 和計費口徑差異明顯。下表依據各家官方文檔整理，具體以對應模型和接口的說明爲準。

以 Claude Sonnet 5.5 的官方價格爲例：普通輸入每百萬 Token $2.00，5 分鐘緩存寫入 $2.50，1 小時緩存寫入 $4.00，緩存讀取 $0.10。緩存讀取只有普通輸入的 5%，這正是重複前綴能被大幅壓縮成本的原因。

需要提醒的是，OpenAI 官方明確說明緩存命中並非每次都能保證；Gemini 的顯式緩存也不是“免費存儲”，存儲時長本身會計費。緩存是一種有條件的折扣，而不是默認生效的降價。

🎯 技術建議：不同上游模型的緩存能力、計費規則和返回字段並不統一，統一網關不會自動讓所有模型獲得相同的緩存優惠。建議通過 API易 apiyi.com 用同一套 OpenAI 兼容代碼分別測試候選模型，以實際返回的 usage 字段和賬單爲準。

Agent 多輪調用緩存成本實算：12 次調用示例

沿用前文的 30 分鐘開發任務，並使用 Claude Sonnet 5.5 官方價格構造示例。假設條件如下：

• 任務共調用模型 12 次，每次輸入 22,000 Token；
• 其中 20,000 Token 是重複的系統提示詞、工具定義和項目背景；
• 每次新增 2,000 Token；
• 採用 1 小時緩存，後續請求均成功複用。

不使用緩存：12 × 22,000 × $2 / 1,000,000 = $0.528。

使用 1 小時緩存：首次寫入 20,000 Token 爲 $0.080，首次普通輸入 2,000 Token 爲 $0.004，後續 11 次緩存讀取爲 $0.022，後續 11 次新增輸入爲 $0.044，合計 $0.150，輸入費用節省約 71.6%。

這個示例只計算輸入 Token，不包含輸出 Token、工具調用和外部服務費用。真實 Agent 的歷史還會逐輪增長，但結論方向不變：重複上下文是 Agent 多輪調用中最容易被放大的成本。

緩存失效、前綴變化與 TTL 對 Agent 成本的影響

上面是理想情況。下面用同一組價格，對三種常見“走樣”做補充推演（以下爲本文按官方單價自行計算的示意場景）。

幾點解讀可以直接用於決策：

• TTL 要覆蓋工具等待：5 分鐘緩存寫入更便宜，但只要測試運行或人工確認超過 5 分鐘，緩存就會過期重寫，節省幅度明顯縮水。
• 前綴穩定比 TTL 更關鍵：把時間戳、隨機 ID 放在提示詞最前面，會讓每次請求都無法命中，在需要付寫入溢價的模式下，緩存反而讓賬單變貴。
• 長 TTL 不是越長越好：1 小時寫入單價是 5 分鐘的 1.6 倍，只有當調用間隔確實可能超過 5 分鐘時才划算。

如何降低 Agent 多輪調用的 API 成本

極簡示例：記錄每次調用的緩存命中

優化的第一步是“看見”成本。下面的代碼通過 OpenAI 兼容接口發起請求，並打印 usage 中的緩存相關字段：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

resp = client.chat.completions.create(
    model="your-model-name",  # 替換爲要測試的模型
    messages=[
        {"role": "system", "content": "固定的系統提示詞與工具說明……"},
        {"role": "user", "content": "本輪新增的任務內容"}
    ]
)
usage = resp.usage
details = getattr(usage, "prompt_tokens_details", None)
print("輸入:", usage.prompt_tokens, "輸出:", usage.completion_tokens,
      "緩存命中:", getattr(details, "cached_tokens", None))

import openai
from dataclasses import dataclass, field

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# 固定前綴：系統指令、工具定義、公共項目背景，放在最前且保持字節級不變
STABLE_PREFIX = [
    {"role": "system", "content": "你是代碼修復 Agent。工具定義與項目規範如下……"},
]

@dataclass
class TaskCost:
    # 單價：美元 / 百萬 Token，按所用模型官方價格填寫
    input_price: float
    cache_read_price: float
    output_price: float
    records: list = field(default_factory=list)

    def add(self, usage):
        details = getattr(usage, "prompt_tokens_details", None)
        cached = getattr(details, "cached_tokens", 0) or 0
        uncached = usage.prompt_tokens - cached
        cost = (uncached * self.input_price
                + cached * self.cache_read_price
                + usage.completion_tokens * self.output_price) / 1_000_000
        self.records.append({"cached": cached, "uncached": uncached,
                             "output": usage.completion_tokens, "cost": cost})

    def summary(self):
        total_in = sum(r["cached"] + r["uncached"] for r in self.records)
        hit = sum(r["cached"] for r in self.records) / max(total_in, 1)
        return {"calls": len(self.records), "cache_hit_rate": round(hit, 3),
                "total_cost": round(sum(r["cost"] for r in self.records), 4)}

def run_turn(history, new_msg, tracker, model="your-model-name"):
    # 只追加新消息，不重排歷史；動態信息（時間戳等）放在最後
    history.append({"role": "user", "content": new_msg})
    resp = client.chat.completions.create(
        model=model, messages=STABLE_PREFIX + history)
    tracker.add(resp.usage)
    history.append({"role": "assistant",
                    "content": resp.choices[0].message.content})
    return resp

tracker = TaskCost(input_price=2.0, cache_read_price=0.1, output_price=0.0)
history = []
run_turn(history, "測試 test_auth 失敗，報錯如下……", tracker)
print(tracker.summary())

注意，上面的估算只覆蓋讀取折扣；若所用模型對緩存寫入單獨計費，需要按其返回字段補充寫入項。不同模型的 usage 字段名稱和含義可能不同，應以實際返回爲準。

🚀 快速開始：推薦先在 API易 apiyi.com 用免費測試額度跑通上面的追蹤腳本，拿到同一任務在不同模型下的緩存命中率與單任務成本，再決定生產環境用哪個模型、哪種 TTL。

Agent 多輪調用成本優化的五個動作

1. 穩定提示詞前綴：系統指令、工具定義、公共參考資料放在最前面，時間戳、用戶動態信息放在最後，工具定義的順序和字段也不要隨意變動。
2. 合理選擇 TTL：調用密集、間隔短的任務用短 TTL；存在長時間測試、構建或人工審批的 Agent，評估更長 TTL 的寫入溢價是否能被避免的重寫抵消。
3. 控制歷史上下文：只追加、不重排，避免破壞緩存前綴；對冗長的工具輸出做摘要，保留關鍵結論、任務狀態和必要證據。
4. 減少不必要的模型調用：能批量執行的工具合併成一次調用，確定性步驟交給代碼而不是交給模型判斷，從源頭減少往返輪數。
5. 監控真實指標：按任務記錄普通輸入、緩存寫入、緩存讀取、輸出 Token、緩存命中率、TTFT 和總成本，用任務級成本而非單次請求成本做評估。

Agent 多輪調用 API 成本影響分析

對開發者的影響

• 成本模型要從“單次請求”升級爲“單個任務”：Agent 的費用取決於整條調用鏈，只看單價會嚴重低估實際賬單。
• 提示詞工程開始兼顧計費結構：前綴的穩定性直接決定緩存能否生效，提示詞結構設計成爲成本工程的一部分。
• 多模型選型需要實測：緩存摺扣比例、TTL 和寫入溢價因模型而異，同樣的任務換模型後成本差異可能很大。

對行業的影響

• 基礎設施競爭聚焦 Agent 負載：Google 將內存帶寬、KV Cache 傳輸和 Agent 暫停恢復作爲重點，說明多輪、長上下文已成爲主流負載形態。
• 用戶收益更先體現在延遲上：底層優化首先改善 TTFT 和吞吐，Token 價格是否下調取決於服務商定價策略，開發者不宜提前計入預算。

常見問題 FAQ

Agent 多輪調用 API 成本核心要點 Key Takeaways

• 成本單位是任務：Agent 賬單是整條調用鏈的累加，而非單次請求。
• 重複上下文是大頭：12 次調用示例中，1 小時緩存可讓輸入費用節省約 71.6%。
• 緩存是有條件折扣：前綴不穩定或 TTL 過短時，節省縮水甚至反向增加費用。
• 三家計費口徑不同：寫入倍率、讀取折扣、存儲費用需按具體模型確認。
• 硬件優化≠賬單下降：底層 KV 優化先改善延遲，價格取決於服務商定價。
• 先度量再優化：藉助 API易 apiyi.com 用統一接口實測各模型緩存命中率與任務成本。

總結

Agent 多輪調用的 API 成本由上下文重複計算、緩存命中與工具往返共同決定，三者缺一不可：

1. 上下文重複計算決定了成本的基數，調用越多，重複越多；
2. 緩存命中決定了重複部分能打幾折，前綴穩定性和 TTL 是關鍵；
3. 工具往返既帶來外部費用，又放大模型調用次數。

Google 在基礎設施層對 KV Cache 和內存牆的投入，會讓 Agent 運行得更快，但開發者能立刻掌控的是自己的 Token 結構。建議從穩定前綴、合理 TTL、精簡歷史、減少調用和任務級監控五個方面着手，並通過 API易 apiyi.com 用真實數據驗證每一項優化的效果。

📚 參考資料

1. Google Cloud Blog – Introducing TPU 8tx and TPU 8i Max：第八代 TPU 新系統發佈公告
2. 鏈接：cloud.google.com/blog/topics/ai-infrastructure/tpu-8tx-and-tpu-8i-max

3. 說明：瞭解 Agent 內存牆與 KV Cache 背景

4. Google Cloud Blog – Introducing TPU Sync：KV Cache 與權重傳輸開源庫

5. 鏈接：cloud.google.com/blog/topics/ai-infrastructure/introducing-tpu-sync-fast-kv-cache-and-weight-transfer-on-tpu

6. 說明：底層 KV Cache 傳輸優化及測試口徑

7. OpenAI API 文檔 – Prompt Caching：緩存機制與最佳實踐

8. 鏈接：platform.openai.com/docs/guides/prompt-caching

9. 說明：前綴緩存規則、保留時間與監控建議

10. Anthropic 文檔 – Prompt Caching：緩存 TTL 與計費說明

11. 鏈接：docs.anthropic.com/en/docs/build-with-claude/prompt-caching

12. 說明：5 分鐘與 1 小時緩存的寫入、讀取價格

13. Google AI for Developers – Context Caching：Gemini 隱式與顯式緩存

14. 鏈接：ai.google.dev/gemini-api/docs/caching
15. 說明：顯式緩存 TTL 與存儲費用說明

作者：APIYI 技術團隊
技術交流：歡迎訪問 API易 apiyi.com 首頁聯繫我們，更多接入資料可查閱 docs.apiyi.com 文檔中心

延伸閱讀

• 用 API易 調用日誌查看 Codex 每輪 token 消耗：5 步算清長對話成本:Codex 輸入框看不到上下文用量？入口在 /status。本文用 API易 調用日誌 5 步算出 Codex 每輪 token 消耗和金額，並給出“該壓縮還是該新開”的判斷表。
• Claude 緩存命中率掉到 0？3 步用 diagnostics 查出是哪一段變了:Claude 提示詞緩存命中率突然掉到 0 或賬單降不下來？用 diagnostics 三步定位前綴分叉點，結合 usage 判斷真實命中，並說明走 API易 中轉時的自檢方法與成本賬。
• GPT-6.1 Terra 價格多少？官方定價與 API 計費詳解：4 項計費 + 3 個算賬例子:拆解 GPT-6.1 Terra 官方定價：輸入、輸出、緩存讀取、緩存寫入四項計費，272K 長上下文階梯、Batch/Flex 五折與 Fast 雙倍價，並用 3 個真實場景算清每百萬 tokens 的成本。
• DeepSeek API 峯谷定價與工具收費後：5 步重新計算應用調用成本:DeepSeek API 引入峯谷定價和工具收費後，用 5 個步驟拆解 Token、時段、緩存與工具調用，重新測算應用的真實調用成本
• OpenAI 新增 12 小時 Prompt Cache：GPT-6 API 緩存省錢的 5 個判斷標準:解讀 OpenAI 12 小時 Prompt Cache 對 GPT-6 API 成本的影響，用回本公式和 5 個判斷標準說明哪些場景開緩存能省錢、哪些場景收益有限。
• Agent 上下文自動壓縮怎麼做：3 種觸發時機與 5 步摘要策略詳解:系統講解 Agent 上下文自動壓縮的 3 種觸發時機、摘要保留策略與可運行代碼，幫你在長對話中控制 Token 消耗，同時不丟失關鍵任務信息。