Agent 成本工程：讓 Agent 跑得起的實作課
前言
Agent 的 demo 總是便宜的：一個漂亮的迴圈、幾次 tool call，就解決了一個看起來很難的任務。但一旦上線、跑成千上萬個任務，帳單就會開始說話。史丹佛、柏克萊、CMU 與微軟研究院今年三月的一份聯合研究揭露了「價格反轉現象」：在 32% 的 head-to-head 比較中，單價比較低的模型，最後完成同一個任務反而花更多錢——極端案例中，實際成本是單價暗示的 28 倍。另一份由密西根大學、史丹佛、OpenHands AI、Google DeepMind、MIT 等團隊合作的論文更直接給出數字：agentic coding 任務平均消耗 417 萬 tokens、成本 1.86 美元，而同樣的程式碼問答在 chat 模式下只要 0.023 美元。這不是貴一點點，而是兩個數量級的差距。
成本工程不是「選便宜的模型」這麼簡單。如圖一所示，Agent 的帳單結構和聊天完全不同：每一圈迴圈，Agent 都把 system prompt、工具定義、專案上下文這些「穩定前綴」重新送一次；再加上不斷累積的工具回傳與歷史對話，input token 才是真正的大戶。想讓 Agent 跑得起，要從帳單結構下手。
槓桿一：Prompt Caching——最高 ROI 的一招
如圖二所示，五個槓桿裡，prompt caching 通常是第一個該開的。原理很單純：把每圈重複送的穩定前綴交給服務商暫存，後續請求直接讀取預先算好的 KV cache，跳過重複計算。
三家的做法略有不同：Anthropic 是顯式標記，在請求裡用 cache_control 設斷點（一個請求最多四個），快取寫入收 1.25 倍輸入單價、讀取只收 0.1 倍，TTL 預設五分鐘、也可選一小時；OpenAI 是自動前綴比對，命中直接打五折；Google 則提供隱式快取加上 CachedContent API。一份 2026 年一月的論文《Don't Break the Cache》在 500 多個長程 agent 任務上實測：正確使用 prompt caching，API 成本下降 41%–80%，首 token 延遲也降了 13%–31%。
實作上有三個要點。第一，請求的內容順序要是「靜態在前、動態在後」：工具定義、system prompt、穩定的專案上下文放前面，快取斷點就設在穩定區的結尾。第二，絕對不要把 timestamp、request ID 之類的動態值放在前綴裡——它會讓每一次請求的字首都不一樣，快取永遠命中不了，這是實務上最常見的坑。第三，用量化的方式確認快取真的有在動：Anthropic 的回應裡有 cache_read_input_tokens 與 cache_creation_input_tokens，命中率就是讀取量除以總量，不要用感覺猜。
response = client.messages.create(
model="claude-sonnet-4-7",
system=[{
"type": "text",
"text": SYSTEM_PROMPT, # 大又穩定的前綴
"cache_control": {"type": "ephemeral"},
}],
messages=[{"role": "user", "content": user_query}],
)
槓桿二：模型路由與級聯——好鋼用在刀口上
Agent 的每一步難度不一樣：判斷要不要呼叫工具很簡單，寫出正確的修補程式很難。全部用旗艦模型等於拿牛刀切菜。實務做法有兩種：前分類器（用便宜模型或規則先判難度再選模型）和級聯（先讓小模型試，失敗再升級到大模型）。級聯的關鍵是「失敗要能被便宜地偵測」——結構化任務可以用 schema 驗證當免費的驗證器，這時小模型先試、大模型兜底，實務上常見 30%–50% 的成本下降。
這裡要接回前言的警語：路由的前提是知道每個模型的「真實任務成本」，而不只是單價。便宜模型如果需要多走好幾圈、或推理 token 暴增（研究發現同一個問題不同模型的 thinking token 可差到九倍），總帳可能更貴。先量測，再路由。
槓桿三：Batch API——不趕時間的工作就別付急件費
很多 agent 的工作根本不趕時間：夜間的程式碼審查、批次文件分析、定期的合規稽核。服務商的 batch API 用非同步換折扣——結果 24 小時內回傳、品質完全一樣，輸入輸出都約五折。這是架構決策：把 fleet 工作分成「要即時」和「可批次」兩條管線，後者天生就是 batch 的形狀。快取和批次還可以疊加，符合條件的工作兩個折扣一起吃。
槓桿四：Context 精簡——刪掉比快取更便宜
快取是把重複的東西變便宜，但「砍掉沒人讀的 token」是連錢都不用花。Anthropic 的 context engineering 指南把這件事講得很白：context 是預算，要刻意花。實務手法包括定期把舊對話壓縮成摘要（compaction）、把工具回傳提煉成精簡的紀錄後丟掉原文、以及服務端的 context editing——例如自動清除已經被消化的舊 tool use 區塊，官方 cookbook 實測峰值 token 下降 48%–67%，而且不花推理成本。
一個好記的原則：刪掉四千個沒人讀的 token，永遠勝過用一折快取它們。
槓桿五：成本可觀測——先能量化才能優化
前面四個槓桿都需要一個前提：你知道錢花去哪了。幫每個任務記帳——用了多少 input/output token、cache hit rate 多少、這個任務花了幾美元。當你能畫出「每任務成本」的分佈，優化就有了方向：hit rate 低的去修前綴順序，長尾任務去看是不是該換路由策略。沒有可觀測性的成本優化，都是在憑感覺省錢。
結論
Agent 的成本工程有一個固定順序：先量化（每任務記帳，知道錢去哪），再快取（穩定前綴 0.1 倍讀取），再路由（便宜先試、失敗升級），再精簡（砍掉沒人讀的 context），最後把不趕時間的工作丟進 batch。單價只是價目表，任務成本才是帳單——當你的 agent 從 demo 走向每天上萬次呼叫，這五個槓桿就是它能不能活下去的差別。
參考來源
沒有留言:
張貼留言