AI 代理寫程式：token 比 chat 多燒 1000 倍

AI 代理寫程式越來越像真的能幹活，但代價也開始浮現。這篇論文 How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks，直接把焦點放在一個很實際的問題：當 agent 開始讀檔、呼叫工具、反覆嘗試修 code 時，token 到底是怎麼被燒掉的。

這不是單純在比誰答得準，而是把「成本」拉到檯面上。對開發者來說，這件事很重要，因為 agent 的費用常常不是出在最後那段輸出，而是出在前面一輪又一輪的上下文讀取、工具互動與重試。你看到的是一次修 bug，帳單看到的可能是整段流程。

論文的核心訊息很直接：代理式寫程式不是一般的 LLM 工作負載。它的 token 消耗高、波動大，而且 frontier model 目前也還不太會自己準確估算成本。這代表 token 不是後台細節，而是系統設計的一部分。

這篇研究在解什麼痛點

當 AI agent 從 demo 走進真實流程，token 花費就不再只是帳務欄位，而是產品與基礎設施問題。agent 會不會一直讀上下文、一直 retry、一直打工具，直接影響成本。即使最後答案差不多，過程也可能差很多。

這篇研究想回答三個實務問題。第一，token 都花在哪裡。第二，同樣任務下，哪些模型比較省。第三，模型能不能在開始前先估算自己大概要燒多少 token，讓系統可以先做預算、分流或限制。

作者把焦點放在 agentic coding tasks，因為這類任務很適合當壓力測試：上下文長、工具多、推理過程反覆，成本特性會被放大。研究使用的是 SWE-bench Verified 上的軌跡，並分析八個 frontier LLM 的 token 消耗模式，以及模型在執行前自我預測成本的能力。

換句話說，這篇不是在提一個新演算法，而是在拆解現有 agent 工作流的成本結構。這個角度對做產品的人很有用，因為很多時候真正的瓶頸不是模型不會做，而是做一次太貴、太不穩定。

方法怎麼看，白話版

研究方法偏觀察式與比較式。作者收集八個 frontier 模型在同一個 coding benchmark 上的 agent trajectories，再比較每次執行消耗多少 token，以及這些成本跟任務結果之間的關係。

他們不只看「有沒有修好」，還看「修這題花了多少」。這個差別很重要，因為在 agent 系統裡，成功不等於划算。某些模型可能能解題，但要先吃掉大量上下文、反覆試錯，成本就會被拉高。

論文也把 input tokens 和 output tokens 分開看。這點很關鍵，因為 agent 的成本常常不是輸出文字本身，而是前面那些被反覆餵進模型的內容。讀檔、重送上下文、工具回傳結果，這些都會堆高 input tokens。

另一個角度是「可預測性」。作者測試模型能不能在執行前估算自己的 token 消耗。這等於在問：模型是否知道自己這次任務會不會很燒錢？如果答案是否定的，那麼想靠模型自我報價來做路由或預算控管，就會有風險。

論文也拿人類專家對任務難度的評分來對照實際 token 花費。這是在檢查一件很現實的事：人類覺得難的題目，是否真的會讓 agent 燒更多 token？

論文實際證明了什麼

最醒目的結果是：agentic coding 的 token 消耗非常誇張。論文指出，這類任務消耗的 token 比 code reasoning 和 code chat 高出 1000 倍，而且主要是 input tokens 在驅動總成本。也就是說，真正燒錢的不是最後吐出來的答案，而是前面那堆反覆吃進去的上下文。

這個發現對做 agent 的團隊很重要。很多人直覺會盯著模型輸出長不長，但這篇研究提醒你，真正的成本黑洞常常藏在輸入端。只要 agent 一直帶著大量歷史狀態、工具輸出和重試內容跑，費用就會迅速放大。

而且成本不是穩定的。論文指出，同一個任務在不同 run 之間，總 token 最高可差到 30 倍。這代表 token 花費不是單純由 benchmark 任務決定，而是帶有很強的隨機性。對平台來說，這種波動會直接影響預算、延遲和資源配置。

更有意思的是，多花 token 不一定換來更好的結果。作者觀察到，accuracy 往往在中等成本時就達到高點，之後再往上加碼，表現會趨於飽和。這打破了「多花一點就會更準」的直覺。

模型之間也有明顯差異。論文提到，在相同任務下，Kimi-K2 和 Claude-Sonnet-4.5 平均比 GPT-5 多消耗超過 150 萬個 token。這不是小差距，而是會直接影響 production 成本的等級。對要做模型選型的人來說，token efficiency 可能跟解題能力一樣重要。

人類對難度的直覺也不太可靠。研究發現，專家標註的任務難度只和實際 token 花費有弱相關。也就是說，光靠人眼看題目，很難準確預估 agent 會燒多少資源。

最後，模型自己也不太會算。frontier models 對自身 token 使用量的預測只有弱到中等的相關性，最高到 0.39，而且普遍低估真實成本。這表示如果你想把「模型自己報價」當成成本控制機制，目前還不夠穩。

對開發者的實際影響

如果你在做 agentic coding workflow，這篇研究的第一個提醒很簡單：token cost 要當成一級指標。不要只看成功率，還要看每次成功付出了多少代價。兩個看起來差不多的任務，最後帳單可能差很多。

這會影響產品設計，也會影響基礎設施規劃。你可能需要 token budget、重試上限、路由規則，或是在任務開始前先做成本分流。尤其當系統要處理大量使用者請求時，成本波動本身就是風險。

這篇研究也在提醒一件常被忽略的事：benchmark 成績不等於 production 適配度。若兩個模型解題率差不多，但其中一個能用更少 token 完成，後者在真實環境裡可能更划算，也更容易控制延遲。

對平台團隊來說，這篇論文還揭露了人類直覺和 agent 行為之間的落差。既然專家難以準確預測 token 花費，那麼靠人工判斷來做成本預估，效果很可能有限。成本管理可能得更多依賴系統化量測，而不是經驗猜測。

這也意味著，下一波 agent 優化不一定只是追求更高分數，而是把同樣能力做得更便宜、更穩定、更可預算。對實務落地來說，這通常比多拿一點 benchmark 分數更重要。

限制與還沒回答的問題

這裡也要說清楚，這份來源是 abstract 級別的資訊，所以沒有公開完整 benchmark 細節、逐模型成本表或更細的實作設定。也就是說，這篇摘要沒有公開完整 benchmark 細節；如果要深入檢查實驗設計，還是得看全文。

另外，研究聚焦在 SWE-bench Verified 與八個 frontier LLM。這讓結果對 agentic coding 很有代表性，但不代表能直接外推到所有工具型工作流，或所有模型家族。不同任務、不同工具鏈、不同上下文管理方式，成本型態都可能變。

還有一個開放問題是：如果改變 prompting 策略、工具流程，或 context 管理方式，token 消耗會不會明顯下降？這篇研究已經指出 input tokens 是主要成本來源，也指出波動很大，但它沒有宣稱已經解決效率問題。

不過，這個結論本身已經很有價值。它告訴開發者，代理式寫程式的成本不是附帶現象，而是系統行為的一部分。想把 agent 做到能上線、能擴量、能控預算，就不能只看「會不會做」，還要看「做一次要燒多少」。

• 代理式寫程式的 token 成本可能遠高於一般 code chat 或 reasoning。
• input tokens 是主要成本來源，不是 output。
• 同一任務的成本波動很大，最高可差到 30 倍。
• 更多 token 不一定帶來更高 accuracy。
• 模型目前還不擅長預測自己的成本。

對台灣開發者來說，這篇研究的訊號很清楚：如果你正在做 AI coding agent，下一個要優化的，不只是模型準不準，而是它到底有多會燒 token。能解題只是起點，能穩定、可預測、可控成本地解題，才比較接近能上線的系統。