很多人談 AI agent 成本，第一反應還是「換便宜模型」。
這個方向沒有錯，但常常不是最先該處理的地方。真正容易讓帳單爆掉的，不是某一次模型呼叫貴了幾毛錢，而是一個 agent 在同一個任務裡反覆規劃、重試、查工具、改寫 prompt、再查一次，最後花掉遠超過任務價值的 token。
所以比較反直覺的判斷是：AI agent 的預算上限，不應該只是財務報表上的控制項，而應該是產品規格。
English TL;DR
Agent cost control is becoming a product requirement, not just a finance concern. The key is not only cheaper models, but run-level budgets, stop conditions, escalation rules, and visibility into which task consumed the money.
傳統 SaaS 的成本比較容易估。一次 API request、一筆資料庫查詢、一個使用者座位，大致都能換算。agent 不一樣。它面對的不是固定流程，而是不確定任務。只要你允許它自己拆解問題、呼叫工具和驗證結果，成本就會變成一條路徑，而不是一個點。
這也是為什麼近期開始有人談 TokenOps、run-scoped budget、model routing。這些詞看起來像 infra 團隊的煩惱，但其實會直接影響產品體驗。當 agent 跑到一半超出預算時，它應該停止、降級模型、縮小任務、請人確認，還是默默繼續燒錢？這不是帳務問題，是使用者承諾問題。
最常見的誤解，是把預算上限想成「限制創新」。但對 agent 產品來說，沒有上限才是壞體驗。使用者不是想買一個永遠努力的黑盒子，而是想知道：這件事值得花多少 AI 成本？超過之後會發生什麼？結果不夠好時，是再跑一次，還是把問題交還給人？
比較務實的做法，是把每個 agent workflow 都加上三個欄位。
第一是任務價值。客服回覆、程式碼修 bug、競品研究、法務初稿，能承受的成本不一樣，不該共用同一條 token 水管。
第二是停止條件。不要只設每日總額，要設單次任務的最大步數、最大工具呼叫數、最大重試次數，以及失敗時的回報格式。
第三是升級規則。低風險任務可以自動降級到便宜模型；高風險任務寧可少跑一步，也要保留人工批准點。模型 routing 的重點不是炫技，而是讓不同價值的任務走不同成本結構。
對小團隊來說，現在不必一開始就買完整 AI FinOps 平台。先在產品裡留下 cost log、run id、任務類型、模型選擇和工具呼叫紀錄，就已經比月底看總帳好很多。等流量真的起來，這些資料會變成你調 pricing、限額、套餐和自動化邊界的依據。
結論是，agent 越像員工，就越不能只用「每月 API 帳單」管理。真正該設計的是：它每接一個任務時，最多能花多少資源，什麼時候該停，什麼時候該問人。沒有這些規格，AI agent 的自動化能力越強，財務和產品風險反而越不可控。