Agent 的成本結構跟傳統應用不同

傳統應用的成本大致跟請求數成正比，相對可預測。Agent 不是：同樣一個請求，可能因為 Agent 決定多繞幾輪、或是因為上下文累積變長，成本差好幾倍。這讓成本監控從「財務部門月底看帳單」變成需要即時監控的營運指標。

三種典型的成本異常

類型一：單次執行成本暴衝。 某次任務因為 Agent 陷入迴圈、或是上下文異常膨脹，單次消耗了遠超正常值的 Token。這類異常如果不即時攔截，一個 bug 可能在幾小時內燒掉大筆預算。

類型二：整體用量緩慢爬升。 每次執行的成本都在正常範圍，但整體用量持續上升。這可能是正常的業務成長，也可能是某個 Prompt 改動導致平均上下文變長——需要區分。

類型三：特定路徑的成本異常。 某一類任務、或某一個 Agent 的成本佔比異常高。這通常指向設計問題，例如某個 Agent 的 Prompt 塞了過多不必要的上下文。

告警設計：三個層次

即時攔截層（單次執行）：設定單次執行的 Token 上限，超過就中止並告警。這是防止類型一的最後防線，而且應該是硬性中止而非只告警——因為告警發出時，錢已經花了。

短期趨勢層（小時／日）：監控每小時或每日的總用量，跟過去同期比較，異常時告警。這處理類型二。

分群分析層（週）：定期檢視依 Agent、依任務類型分群的成本分布，找出佔比異常的群組。這處理類型三，通常不需要即時告警，週期性檢視即可。

一個實務建議：先建立基準線

告警閾值不該憑感覺設定。建議上線初期先觀察一到兩週，建立各項成本指標的正常分布（平均、P95、P99），再依此設定閾值。太早設定閾值的結果通常是：不是告警一直響（閾值太低），就是出事了也沒響（閾值太高）。

跟 FinOps 的關係

這篇處理的是即時的異常偵測，而更全面的成本治理——包括預算分配、成本歸屬、優化策略——會在 Day 27 展開。

這篇的檢查清單

• [ ] 是否有單次執行的 Token 硬性上限，而非只靠告警？
• [ ] 告警閾值是否基於實際觀察的基準線，而非憑感覺設定？
• [ ] 是否有定期檢視依 Agent／任務類型分群的成本分布？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。