單一 Agent 好追，多 Agent 就亂了

Day 8 設計的結構化日誌，在單一 Agent 場景下已經夠用。但當系統裡有多個 Agent 互相協作——Agent A 把任務交給 Agent B，Agent B 又呼叫了 Agent C——如果每個 Agent 各自寫自己的日誌，沒有共同的關聯識別碼，你事後會拿到三份互不相干的日誌，無法還原「這個任務整體是怎麼流轉的」。

三層識別碼的設計

實務上建議設計三個層次的識別碼：

trace_id（追蹤層級）：對應一次完整的任務執行，從使用者發起請求到最終回應，不管中間經過幾個 Agent，這個 ID 都保持不變。這也是跟 Week 3 的 Cloud Trace 串接的關鍵。

session_id（會話層級）：對應一段多輪對話。一個 session 可能包含多次 trace（使用者問了三個問題，就是三次 trace，但屬於同一個 session）。這對分析「多輪滲透」這類跨輪次的行為模式特別重要——如果你也在追團隊的 Agentic AI 攻防系列，那邊 Day 7 談的多輪滲透手法，防禦端就需要這種跨輪次的關聯能力。

span_id / parent_span_id（步驟層級）：對應單一步驟，並記錄它的上層步驟是誰，讓整條鏈路的父子關係可以被還原成樹狀結構。

跨 Agent 邊界的傳遞

關鍵在於：當 Agent A 呼叫 Agent B 時，必須把 trace context 一起傳過去，而不是讓 Agent B 自己產生一個全新的 trace_id。OpenTelemetry 對此有標準的 context propagation 機制（透過 W3C Trace Context 標準的 header 傳遞），Week 3 會從 Trace 的角度再談一次。

如果 Agent 之間是透過 HTTP 或 gRPC 溝通，OpenTelemetry 的自動 instrumentation 通常能處理 context 傳遞；但如果是透過訊息佇列、或是自訂的協作協定，就需要應用層自己確保 context 有被正確帶過去——這是實務上最常漏掉的環節。

一個實用的驗證方法

設計完之後，用一個簡單的方式驗證：隨機挑一次跨多個 Agent 的任務執行，試著只用 trace_id 查詢，看能不能把所有相關日誌完整撈出來、並還原出正確的執行順序。 如果做不到，代表 context 傳遞有斷點。

這篇的檢查清單

• [ ] 是否已設計 trace_id / session_id / span_id 三層識別碼？
• [ ] 跨 Agent 呼叫時，trace context 是否確實被傳遞而非重新產生？
• [ ] 是否已實際驗證過「用單一 trace_id 能撈出完整執行鏈路」？