最近看到 Agent 開發框架開始把 LLM 呼叫上限、執行軌跡、護欄與評測做進 runtime，我覺得這是一個很務實的訊號：大家終於不只在問 Agent 能做多少事，也開始認真處理它到底可以做多久。
很多團隊已經會設定模型費用警示，卻仍可能遇到一個任務反覆查詢、換模型、重試工具，最後沒有超出帳單上限，卻把時間、服務配額與人的耐心一起耗光。站在技術主管的位置，我會把執行預算看成任務的停止條件，而不只是月底成本報表上的一條紅線。
金額只是最晚才看見的結果
談 AI 預算時，最直覺的是 token、模型單價與每月額度。這些當然要管，但它們通常是執行過程累積後的結果，不足以描述任務是否健康。
一個 Agent 可能只用了便宜模型，卻在錯誤方向上跑了五十步；也可能沒有花很多 token，卻反覆呼叫昂貴或有速率限制的外部工具。還有一種更麻煩的情況：主模型失敗後切到 fallback，新的模型重新閱讀整份上下文，又從頭嘗試一次。每個局部決策看起來都合理，整體卻逐漸失去終止條件。
因此，若系統只問「這次花了多少錢」，往往太晚。更早該問的是：它已經用了幾次模型呼叫、走了多少步、重試幾次、等待多久、讀了多少資料、觸發多少工具，以及產生了多少不可逆的動作。
執行預算應該是多維度的
我現在會把任務預算至少拆成五類。
第一是模型呼叫預算。它不只限制總次數，也要區分規劃、摘要、驗證與生成等用途。若同一個問題連續呼叫多次仍沒有新增證據，系統應該停下來，而不是期待下一次抽樣突然開悟。
第二是時間與步數預算。背景任務不能因為使用者看不到，就獲得無限生命。牆鐘時間、有效運算時間與狀態轉移次數都值得記錄。任務長時間停在等待、重試或來回規劃，代表它可能需要人工決策，而不是更多耐心。
第三是工具與資料預算。資料庫查詢、搜尋、檔案讀取與外部 API 各有不同成本和風險。限制總工具呼叫數還不夠，還要限制單一工具的重複使用、查詢範圍與回傳量，避免 Agent 用「再查一次」掩蓋自己沒有收斂。
第四是重試與 fallback 預算。重試不能重置整個任務的計數器，切換模型也不能得到一份全新額度。預算必須沿著任務樹繼承，否則主 Agent 每叫一個 sub-agent，就等於偷偷增發新的信用卡。
第五是副作用預算。建立草稿、改檔案、送出通知與更新正式資料，不能只用同一個次數衡量。愈接近不可逆操作，額度應該愈小，甚至預設為零，直到取得明確核准。
用完預算時，不能只回一個錯誤
預算真正有用的地方，不是把 Agent 硬切斷，而是讓系統在額度耗盡時做出可理解的轉移。
低風險任務可以降級，例如縮小搜尋範圍、改用較便宜的模型，或只交付目前已驗證的部分。需要判斷的任務則應進入 decision_required，清楚說明已完成什麼、卡在哪裡、還缺哪些證據，以及增加多少額度可能換到什麼結果。涉及正式資料的任務，預算耗盡時應停止後續副作用，而不是為了「完成」偷偷略過驗證。
這裡有一個很重要的原則：fallback 是故障處理，不是繞過政策。原模型超出呼叫上限後切到另一個模型，仍必須沿用同一份任務預算、權限與審批條件。否則系統看似提高可用性，實際上只是把失控路徑藏進備援鏈。
沒有 execution spans，預算只會變成另一個黑盒
要管理預算，前提是看得見它花在哪裡。只有任務總 token 和總金額，無法回答是規劃太久、工具太慢、context 膨脹，還是重試策略出了問題。
我會要求每個重要階段留下 execution span：它的目的、父任務、使用模型、工具呼叫、等待時間、輸入輸出量、重試原因與結束狀態。這些 span 不只是除錯資料，也讓團隊能比較不同版本的 runtime 行為。
例如模型升級後，最終答案正確率可能提高，但平均工具呼叫增加一倍；新的 fallback chain 可能降低失敗率，卻讓尾端延遲與成本大幅上升。若沒有分階段軌跡，團隊只會看到「大多數任務成功」，卻不知道成功正在變得愈來愈昂貴。
預算要用真實工作負載校準
預算也不是拍腦袋設一個固定數字。太鬆沒有保護作用，太緊則會讓正常任務頻繁中斷。比較可靠的作法，是從真實工作負載建立基線：不同任務類型通常需要幾次模型呼叫、多少工具步驟、多久完成，哪些失敗會因一次重試恢復，哪些重試只是在浪費資源。
接著再按風險與價值分級。讀取型摘要可以給較大的探索空間；會修改資料的流程應有更短步數、更少重試與更早的人工確認；高成本分析可以允許延長時間，但必須定期產生 checkpoint，證明工作確實在前進。
每次改模型、工具描述、prompt、context 壓縮或 fallback 策略，都應用同一批真實任務重跑。評估的不只是最後答案，還要比較完成率、呼叫分布、尾端延遲、人工介入點與預算耗盡原因。這樣預算才會從靜態限制，變成 runtime 的可靠性指標。
能力愈強，愈需要清楚的停止理由
Agent 失控不一定長得像巨額帳單。它可能只是一直很忙：不斷查資料、不斷反省、不斷換模型，產出一長串看似合理的軌跡，卻沒有更接近可驗證結果。這種失控最容易被忽略，因為系統沒有當機，甚至每一步都能解釋。
對我來說，成熟的 Agent runtime 不只要知道如何開始，也要在每一步回答：剩下多少執行空間、目前進展是否值得繼續、耗盡後要降級、交棒還是停止。
成本上限保護帳單；執行預算保護的是整個工作流。當模型呼叫、時間、重試、工具與副作用都有可觀測的邊界，Agent 才不會把「還能再試一次」當成永遠成立的理由。真正可靠的自動化，不是永遠把任務做完，而是在不值得繼續時，能帶著證據停在對的地方。