30 天，一句話回顧

如果只留一句話：Agent 上線後最大的風險不是它會出錯，而是它出錯時你不知道為什麼。 這 30 天做的所有事——結構化決策日誌、三層 Span 樹、任務品質指標、行為異常告警——本質上都在回答同一個問題：怎麼讓一個會自主決策的系統，變成可以解釋的系統。

五週回顧

貫穿 30 篇的三個原則

原則一：從動作到決策。 這是整個系列最核心的主張。傳統監控記錄 Agent 做了什麼，Agent 可觀測性必須記錄它為什麼這樣做。Day 26 的真實案例就是這個原則的驗證——所有技術指標正常，靠 decision_summary 才找到根因。

原則二：三支柱各司其職。 Log 記內容與理由、Trace 記結構與時序、Metrics 記趨勢與告警。三者用 trace_id 串起來，而不是試圖用單一工具做完所有事。

原則三：先想問題，再設計欄位。 Day 8 提過的方法——先列出未來想回答的問題（包含稽核單位會問的），再反推需要哪些欄位。這比先設計欄位、事後發現查不到答案有效率得多。

三部曲的完整拼圖

這個系列是團隊三個主題的最後一塊：

Build（ADK 系列）——怎麼把 AI Agent 建出來。

Attack／Defense（Agentic AI 攻防系列）——建好的 Agent 面對真實攻擊手法撐不撐得住。

Observe（本系列）——上線之後，怎麼知道它在做什麼、做得好不好、出事時怎麼查。

三者合起來，才是一個 AI Agent 從開發到生產的完整生命週期。單看任何一個系列都有價值，但三個一起看，會發現它們反覆指向同一件事：Agent 的自主性是它的價值來源，也是所有困難的來源——它讓你不能用寫死的邏輯保證行為、不能用固定的測試案例窮舉路徑、也不能用傳統監控看懂它的決定。三個系列各自從建構、防護、觀測的角度，處理同一個根本問題。

所有可複用資產索引

Week1 成熟度自評表、Week2 結構化日誌 Checklist、Week3 決策鏈路追蹤範本、Week4 告警規則與 Dashboard 範本、Week5 稽核對應框架。建議收攏成一份團隊內部的 Agent 可觀測性導入手冊。

最後

謝謝跟著看完 30 天的每一位。這個領域還在快速成形——OpenTelemetry 的 GenAI 規格仍在演進，Google Cloud 的相關功能也持續更新。技術細節會過時，但「先想清楚要回答什麼問題」這個原則不會。

參考資料來源

• Google Cloud，《Cloud Logging／Cloud Trace／Cloud Monitoring 官方文件》
• Google Cloud，《Instrument generative AI applications》
• OpenTelemetry，《GenAI Semantic Conventions》，opentelemetry.io
• 數位發展部，《人工智慧風險分類框架》

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