日誌成本是會失控的

Agent 系統的日誌量可能比傳統應用大上一個量級——每一次任務執行都可能產生數十筆決策日誌，如果又把 Prompt 與回應內容一起記錄，體積會迅速膨脹。實務上常見的狀況是：導入初期什麼都記，三個月後收到帳單才發現日誌成本佔了整體雲端支出的可觀比例。

分級保存策略

不是所有日誌都值得用同樣的成本保存。建議依用途分成幾級：

抽樣：不是所有執行都要完整記錄

對高流量的 Agent 服務，一個務實做法是分層抽樣：所有執行都記錄基本的結果欄位（成功/失敗、延遲、成本），但完整的決策鏈路只對一定比例的執行做完整記錄，加上「所有失敗案例一律完整記錄」的規則——因為失敗案例才是最需要除錯的。

成本控制的幾個具體手段

用 Log Router 的排除規則：把明確不需要的日誌（例如健康檢查、正常的心跳訊號）在進入儲存前就排除掉，而不是存進去之後再想辦法刪。

降低高頻低價值日誌的 severity 或直接不寫：不是每個內部步驟都值得留下一筆日誌。

定期檢視日誌用量分布：找出佔用最多容量的日誌來源，通常會發現有一兩個來源佔了大部分成本，優先處理這幾個的效益最高。

待實測提醒：Cloud Logging 的計價方式（攝取量計費、保存期計費）與免費額度會調整，且各類 Sink 的目的地（BigQuery、Cloud Storage）本身也有各自的儲存與查詢成本，發布前請對照官方計價文件確認，並用自己的實際用量試算過再下結論。

這篇的檢查清單

• [ ] 是否已依用途對日誌分級，套用不同保存策略？
• [ ] 高流量場景是否已設計抽樣規則，並確保失敗案例一律完整記錄？
• [ ] 是否定期檢視日誌用量分布，找出成本大戶？