鐵人檔案
當 AI Agent 真正上線後，「跑得動」跟「看得懂它在幹嘛」是兩回事。Agent 一旦具備自主決策與工具呼叫能力，傳統的日誌監控往往看不出「為什麼做這個決策」，只看得到「呼叫了哪個 API」。
這 30 天會用 Google Cloud 的可觀測性工具鏈——Cloud Trace 追蹤 Agent 決策鏈路、Cloud Logging 建立結構化決策日誌、Cloud Monitoring 設計異常告警、搭配成本與延遲的 SLA 監控——把「Agent 內部到底發生了什麼」變成看得見、可追溯、可稽核的資訊。
這是個沒有標準答案的取捨 Day 8 設計結構化日誌時提到「不建議把完整 Prompt 與回應塞進日誌」，但實務上團隊經常會問：可是不記錄的話，出問題時要怎麼重...
這週把「看不懂」變成「查得到」 Week 2 的五篇構成一條完整的日誌設計流程：Day7 鋪管線（Router／Sink／Log-based Metrics）→...
日誌看得到「什麼」，Trace 看得到「順序與結構」 Week 2 建立的結構化日誌，能回答「發生了什麼、為什麼」。但如果你想知道「這次任務執行，時間花在哪、哪...
GenAI 語意慣例定義好的 Span 結構 Day 5 提過 OpenTelemetry GenAI 語意慣例定義的階層結構，這篇把它展開成實際的 Trace...
單一 Agent 的樹好畫，跨 Agent 就容易斷 Day 14 畫的那棵 Span 樹是單一 Agent 場景。當任務跨越多個 Agent——Agent A...
Agent 的延遲問題跟傳統應用不一樣 傳統應用的延遲優化，多半是找出最慢的那個資料庫查詢或 API 呼叫。Agent 系統多了一個維度：有時候問題不是「某一步...
兩個系統之間的最後一哩 Week 2 建立了結構化日誌，Week 3 建立了 Trace。但如果這兩者是兩個獨立的系統，實際除錯時你還是要在兩個介面之間手動比對...
這週把扁平的日誌變成立體的執行圖 Week 3 的五篇：Day13 建立 Trace 基礎概念 → Day14 設計三層 Span 結構 → Day15 處理跨...
從被動查詢到主動通知 Week 2 的日誌與 Week 3 的 Trace，都是「你先知道有問題，才去查」的工具。這週要處理的是另一個方向：怎麼在問題發生時就主...
統 APM 沒有這些欄位 Day 2 提過，Agent 系統需要「任務品質層級」的指標，而這些傳統 APM 工具沒有現成欄位，需要自己定義。這篇提供一組實用的起...
