自主任務連跑三夜，帳單翻了一倍：我們為 Token 開銷立了一本帳

這個月初，我們的自主交付任務連續跑了三個通宵。早上查看帳單時發現，本月日均 Token 消耗量幾乎是上個月的兩倍。

事故經過並不複雜：一個子任務在給定的介面合約（Interface Contract）上反覆失敗，模型自行重試了一小時，共發起二十一次呼叫，每次呼叫還帶著四萬多 Token 的上下文——前幾次失敗的備註被塞回 Prompt 中，導致重試次數越多，上下文堆疊得越厚。結果任務狀態依然是紅色（失敗），Token 卻已燒盡。

複盤結論非常直接：模型並沒有跑偏，問題出在循環機制中根本沒有「帳本」。成本僅在專案層面進行過粗略估算，單一任務想花多少就花多少；重試邏輯沒有上限；過程中的消耗也沒有任何警報。最麻煩的是「單次失敗很便宜」這種錯覺——一次四萬 Token 的呼叫單看不過幾十塊錢，但一天累積數百次後，凌晨時分就很難被任何人攔截。任何一個通宵運行的任務，都只是在等待一張難看的帳單。

隨後我們建立了一套「三道防線」護欄，這三道防線對應著三筆學費。

**第一道防線：每個任務領取飯票，消耗按 API 回傳值計算，而非自行估算。**

自主任務啟動前必須申請單一任務預算：即允許消耗多少 Token。排程器另外設定全天的總開關。採用兩層帳本機制：任務帳與日帳，哪一層先觸限就以哪一層為準。日總開關並非任務預算的簡單倍數——我們將其設定為當天所有預算總和的 1.5 倍。超出此範圍說明排程本身出現混亂，這時需要叫醒的是人員，而不僅僅是關注帳單。

在自行估算這一點上，我們曾吃過虧。第一版依據字元數估算成本，還試圖自動壓縮 Prompt 以節省費用，結果 API 實際計費標準與我們的估算相差高達兩成。後來我們乾脆只依賴 API 回應中的 `usage` 欄位數值。估算僅用於啟動前申請預算的步驟，任務一旦開始運行，記帳依據便是 API 回傳數據。

**第二道防線：觸限即停，而非觸限僅通知。**

第一版的做法較為溫和：預算達到八成時發送警報，任務繼續運行。心想既然發了通知，自然會有人來處理。結果是晚上十一點發出警報，無人檢視，任務又自行運行到隔天早上七點，預算超支三成。改進後改為：八成時發送警報，達到百分之百則拒絕呼叫、終止任務，並將失敗原因記錄入帳。

這是最嚴厲的一條，也是最容易被內部人員妥協的一條：護欄必須擁有讓任務失敗的權力。只通知不剎車的不叫護欄，叫告示牌。一個不能允許自己失敗的任務，不具備過夜運行的資格。

**第三道防線：重試視為同一實體，帳務按任務記錄，不按 Attempt 記錄。**

我們過去還有一個舊習慣：上次 Attempt 超支，重試一次就清零。失控的任務靠著反覆重新啟動就能繞過流量控制。現在帳本的唯一鍵是任務 ID，Attempt 複用同一張飯票，不會重新撥款；另外增加單次 Attempt 上限，約為任務預算的三分之一，確保一次嘗試不會在短時間內燒完大量預算。超預算的任務進入審核佇列，經人工核驗後重新發放預算再啟動，無法繞過此機制。

數據顯示：護欄機制在八月十五日前後定型。之後兩週內，沒有任何任務在達到八成警報點之前發生單次超支情況；警報共觸發四次，每次均在十分鐘內完成閉環處理。日均消耗回落至事前水準的七成左右。我更看重的是另一件小事：「這個任務該不該花這麼多錢」這個問題，以前需要在凌晨兩點靠人力思考，現在在任務啟動的那一刻就有答案，答案寫在帳本裡。

預算不是節約工具，它是自主任務被允許自治的入場券。