Day 21 處理異常，這篇處理常態

Day 21 談的是成本異常的即時偵測——那是防止意外的機制。這篇處理的是另一件事：當 Agent 部署規模擴大到數十、上百個之後，怎麼系統性地管理成本。這是 FinOps（財務營運）的範疇。

成本歸屬：先知道錢花在哪

大規模部署後最常見的困境是：帳單上有一筆很大的 AI 相關支出，但沒人說得清楚是哪些 Agent、哪些團隊、哪些業務場景花的。沒有歸屬能力，就沒有優化的著力點。

實務做法是用標籤（labels）在資源層級做標記，並確保 Week 2 的日誌與 Week 3 的 Span 都帶有能識別歸屬的欄位（Agent ID、團隊、業務線）。這樣才能把成本拆解到有意義的維度。

三個常見的成本優化方向

方向一：模型分層。 不是每一步都需要最強的模型。Agent 執行過程中有許多簡單判斷（例如意圖分類、格式驗證），用較小的模型甚至規則就能處理。Week 3 的 Trace 資料能幫你找出哪些 chat span 其實在做很簡單的事。

方向二：上下文管理。 Token 成本跟上下文長度直接相關。實務上常見的浪費是每一輪都把完整歷史帶進去，即使大部分內容跟當前判斷無關。這需要在 Agent 設計層面處理，但可觀測性資料能告訴你上下文長度的分布，找出膨脹最嚴重的場景。

方向三：減少不必要的步數。 呼應 Day 16 與 Day 20 的平均步數指標——每減少一步就少一次 LLM 呼叫。

成本歸屬到業務價值

成熟的成本治理不只問「花了多少」，還會問「值不值得」。這需要把成本指標跟業務指標放在一起看，例如：每次成功完成的任務成本是多少？某個 Agent 每月的成本，對應到它節省的人力工時是多少？

這類分析通常需要把可觀測性資料跟業務資料結合（例如匯出到 BigQuery 後跟業務資料表 join），這也是 Day 7 建議把日誌送進 BigQuery 的價值之一。

這篇的檢查清單

• [ ] 成本是否能歸屬到 Agent／團隊／業務線層級？
• [ ] 是否已檢視哪些 LLM 呼叫其實可以用更小的模型或規則取代？
• [ ] 是否有把成本跟業務價值放在一起評估，而非只看絕對金額？

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