67K tokens，在你問第一個問題之前就燒掉了
agent 成本優化這件事，很多 team 的第一反應是換便宜一點的模型。我的 take 是：這個方向通常錯了。
最近在 Reddit r/openclaw 看到一份整理，有人把幾個真實 agent deployment 的成本案例拆出來對比。讓我印象最深的是兩個數字：一個系統有 508 個 MCP tool schema，光是 prune 掉沒用的工具定義，每次 run 的成本就從大概 377 美元壓到 29 美元，差快 13 倍。另一個 case 是在第一個問題還沒問之前，就先燒掉了大約 67K tokens，全是系統初始化塞進去的 context。
把這兩個數字放在一起看，我的反應不是「AI 好貴」，而是「這個 system 根本沒人 own」。
在外商做 PM 這幾年，這種問題見過太多次了。不是工程沒能力，是 ownership 的邊界沒畫清楚。agent infra 通常橫跨好幾個 team，有人負責 model integration，有人管 tool catalog，有人看 infra cost，但很少有人是端到端負責「每一次 run 到底燒了什麼，為什麼燒了」的那個人。
更麻煩的是這種問題在 demo 階段幾乎看不出來。你 pilot 10 個 query 的時候，context 有沒有塞滿成本差距不明顯。一旦到 production scale，每個 run 多燒 50K tokens，乘上 request volume，就是預算洞。
這也是為什麼我覺得 enterprise 評估 agent solution 的時候，可預測性比便宜重要得多。
很多 stakeholder 一開始問的是「這個模型比 X 便宜多少？」但這個問題問錯了層次。model unit cost 是你整個 cost structure 裡最好預測的那塊，因為它是 per token 線性的。真正難控制的是 execution surface，包括 tool schema 的量、shell output 有沒有截斷、browser snapshot 吃了多少、每次 run 初始化塞了什麼、compaction 的 policy 是什麼、caching 的命中率。這些問題，換個便宜模型完全幫不上忙。
所以做 agent business case 的時候，成本 model 我通常分三層來想。第一層是模型費用，最好算，也最好 benchmark。第二層是 execution overhead，tool definitions、system prompt、context management，這層最容易失控，也是工程端和 PM 端最需要 aligned 的地方。第三層是 failure cost，agent 走錯路、重試、fallback，都是隱形的 token 成本，而且很難事前估。
enterprise 客戶最怕的不是「這個 AI 服務要多少錢」，是「我不知道下個月帳單會是多少」。scalability 也是同樣的邏輯，你沒辦法 scale 一個你不理解成本結構的東西。
compaction 和 caching 不是萬靈丹，我完全同意。它們是優化工具，不是成本管控機制。508 tool schema 那個 case 最值得記的地方不是省了多少錢，而是：這個問題存在多久了，是誰去發現的？如果要靠外部人做事後分析才發現，代表你的 system 缺乏 cost visibility，這在 enterprise 是很嚴重的 governance 問題。
如果你的 team 現在在做 agent deployment 的 business case，建議先問自己三個問題：這個 system 的 cost observability 在哪裡？誰 owns execution surface 的 governance？我對 scale 到 10x request volume 之後的成本有沒有 reasonable estimate？
答不出來的話，先暫停換模型的計畫，把這三個問題 align 清楚再說。
作者：Vivian L