日誌看得到「什麼」，Trace 看得到「順序與結構」

Week 2 建立的結構化日誌，能回答「發生了什麼、為什麼」。但如果你想知道「這次任務執行，時間花在哪、哪一步卡住、整條鏈路的結構長什麼樣」，日誌就不是最好的工具——因為日誌是扁平的一筆一筆，而執行流程是有階層、有時序的樹狀結構。這正是 Trace 要處理的問題。

三個核心概念

Span：代表一個工作單元，有名稱、開始時間、結束時間、以及一組屬性。在 Agent 場景下，一次 LLM 呼叫是一個 Span、一次工具執行也是一個 Span。

Trace：由多個 Span 組成的樹，代表一次完整的執行流程。Span 之間透過 parent-child 關係串起來，還原出完整的呼叫階層。

Context Propagation（上下文傳遞）：讓 Trace 能跨越服務邊界的機制。當一個服務呼叫另一個服務時，把 trace context 透過標準的 header 傳過去，接收端就知道自己該掛在哪棵樹的哪個位置——這正是 Day 9 談過的跨 Agent 關聯，從 Trace 角度看的同一件事。

Cloud Trace 的角色

Cloud Trace 是 Google Cloud 的分散式追蹤後端：接收 Span 資料、儲存、並提供 Trace Explorer 介面讓你視覺化檢視一棵 Span 樹的時間軸分布。

值得注意的是，Cloud Trace 已經支援 OpenTelemetry——你用 OTel SDK 產生的 Span 可以直接匯出到 Cloud Trace，不需要綁定 Google 專屬 SDK。更進一步，Cloud Trace 針對生成式 AI 應用有專門的處理：只要你的 Span 符合 OpenTelemetry 的 GenAI 語意慣例，Cloud Trace 就能辨識並解析這些 Span 裡的 GenAI 相關屬性與事件。

為什麼 Agent 場景特別需要 Trace

傳統應用的執行路徑相對固定——同樣的請求走同樣的流程。Agent 不是：同樣的問題，這次可能呼叫兩次工具就解決，下次可能繞了五輪還轉接人工。執行路徑本身就是變數，這讓「把每次執行的實際路徑完整記下來」變得比傳統應用更有價值。

這篇的檢查清單

• [ ] 是否已理解 Trace 與 Log 解決的是不同層次的問題，而非重複建設？
• [ ] 是否已評估用 OpenTelemetry SDK 產生 Span，而非綁定專屬 SDK？