鐵人檔案
當 AI Agent 真正上線後，「跑得動」跟「看得懂它在幹嘛」是兩回事。Agent 一旦具備自主決策與工具呼叫能力，傳統的日誌監控往往看不出「為什麼做這個決策」，只看得到「呼叫了哪個 API」。
這 30 天會用 Google Cloud 的可觀測性工具鏈——Cloud Trace 追蹤 Agent 決策鏈路、Cloud Logging 建立結構化決策日誌、Cloud Monitoring 設計異常告警、搭配成本與延遲的 SLA 監控——把「Agent 內部到底發生了什麼」變成看得見、可追溯、可稽核的資訊。
「跑得動」跟「看得懂」是兩件事 團隊裡另外兩個系列，一個講怎麼用 Google ADK 把 AI Agent 建出來，一個講怎麼用 GCP Security 視...
三支柱本身沒變，但內容物完全不同 可觀測性的經典三支柱——Logs、Metrics、Traces——這個框架沒有過時，但套用到 Agent 系統時，每一支柱該記...
三個服務，一個共同的資料底層 Google Cloud Observability（原 Google Cloud 的 Operations Suite）由幾個核...
為什麼要分層次思考 企業導入 Agent 可觀測性時，常見的誤區是「先裝一套監控工具再說」，卻沒有先想清楚要監控的到底是哪個層次的問題。這篇提出一個三層次框架，...
先說清楚這套標準目前的成熟度 在深入細節之前，有件事要老實講：OpenTelemetry 的 GenAI 語意慣例，截至目前仍處於 Development／Ex...
這週建立的是共同語言，還沒動手做 Week 1 五篇的角色是建立地圖：Day2 重新定義三支柱，Day3 建立 Google Cloud Observabili...
先把管線鋪好，再談內容怎麼設計 Week 1 建立了概念地圖，這週開始動手。第一步不是急著設計 Agent 日誌的欄位，而是先理解 Cloud Logging...
這篇是整個系列最核心的一篇 Day 4 提過三層次框架，其中最難、也最容易被忽略的是決策邏輯層——因為沒有現成模板，需要團隊自己設計。這篇要處理的正是這件事：怎...
單一 Agent 好追，多 Agent 就亂了 Day 8 設計的結構化日誌，在單一 Agent 場景下已經夠用。但當系統裡有多個 Agent 互相協作——Ag...
日誌成本是會失控的 Agent 系統的日誌量可能比傳統應用大上一個量級——每一次任務執行都可能產生數十筆決策日誌，如果又把 Prompt 與回應內容一起記錄，體...
