Week 1 五篇的角色是建立地圖：Day2 重新定義三支柱，Day3 建立 Google Cloud Observability 的服務地圖，Day4 提出三層次框架，Day5 深入 OpenTelemetry GenAI 標準與 ADK 的橋接。這週結束時，你應該已經能判斷「我的 Agent 系統，目前的可觀測性大概站在哪個成熟度」。
| 面向 | Level 0（無） | Level 1（基礎） | Level 2（進階） |
|---|---|---|---|
| 基礎設施層 | 無系統化監控 | 標準 CPU/延遲/錯誤率監控 | 加上容量預測與自動擴縮告警 |
| 模型呼叫層 | 無 Token/成本追蹤 | 有基本 Token 用量記錄 | 用 gen_ai.* 標準屬性，可跨模型比較 |
| 決策邏輯層 | 只有動作記錄，無決策理由 | 部分關鍵節點有記錄決策摘要 | 完整決策鏈可追溯，可回答「為什麼」 |
| 追蹤鏈路 | 無 Trace | 單一 Agent 呼叫有 Trace | 跨 Agent 協作的分散式追蹤 |
| 告警機制 | 無告警或僅基礎設施告警 | 有任務失敗告警 | 有行為異常與成本異常告警 |
| 稽核轉化 | 監控資料無法轉化為稽核證據 | 監控資料可手動整理成報告 | 監控資料自動對應合規要求 |
建議團隊誠實地在每一列標出目前所在的等級，不要急著追求全部 Level 2——多數企業在導入初期，Level 1 已經是務實的目標。這張表的價值在於找出落差最大的那一兩列，作為接下來四週投入的優先順序，而不是要求每個面向同步推進。
有了共同語言與自評基準，Week 2 開始動手：從 Cloud Logging 的基礎設定，到怎麼設計一份真正能回答「Agent 為什麼這樣做」的結構化決策日誌。
💡 關於作者
我是 Fngi，專注在 AI 安全與雲端資安領域。如果這系列對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。
iThome鐵人賽
看影片追技術