三支柱本身沒變，但內容物完全不同

可觀測性的經典三支柱——Logs、Metrics、Traces——這個框架沒有過時，但套用到 Agent 系統時，每一支柱該記錄的內容跟傳統微服務差異很大。這篇先把三支柱在 Agent 場景下重新定義一次，作為後面三週（Week2 Logs、Week3 Traces、Week4 Metrics）的共同起點。

Logs：從「發生了什麼事件」到「做了什麼決策」

傳統應用的日誌記的是離散事件：「使用者登入」「訂單建立」「支付失敗」。Agent 的日誌需要多一層：不只記錄「呼叫了工具 X」，還要記錄「為什麼選擇呼叫工具 X，而不是工具 Y」。這代表日誌的結構要能承載推理過程的摘要，而不只是動作本身——Week 2 會深入怎麼設計這種結構化日誌。

Metrics：從「系統健康度」到「任務品質」

傳統 Metrics 關心的是延遲、錯誤率、吞吐量——這些對 Agent 系統依然重要，但不夠。Agent 系統還需要任務品質層級的指標：任務成功率、需要人工介入的比例、幻覺發生的代理指標（例如輸出跟檢索內容的一致性分數）。這些指標傳統 APM 工具沒有現成欄位，需要應用層自己定義——Week 4 會展開。

Traces：從「一次請求」到「一條推理鏈」

傳統 Trace 追蹤的是一次 HTTP 請求經過幾個微服務。Agent 的 Trace 要追蹤的是一條推理鏈：Planner 做了什麼決策、呼叫了哪個 Executor、Executor 呼叫了哪個工具、工具回傳什麼、Planner 根據回傳結果又做了什麼決策——這條鏈可能有分支、可能迴圈、可能因為多輪對話而拉得很長。Week 3 會詳細講怎麼用 Span 把這條鏈完整記下來。

一張對照表先建立直覺

這篇的檢查清單

• [ ] 團隊對「可觀測性」的理解，是否還停留在傳統應用監控的框架？
• [ ] 是否已意識到 Agent 場景需要額外記錄「決策理由」而非只記錄「動作」？