單一 Agent 的樹好畫，跨 Agent 就容易斷

Day 14 畫的那棵 Span 樹是單一 Agent 場景。當任務跨越多個 Agent——Agent A 判斷這件事該交給 Agent B——如果 context 沒有正確傳遞，你會得到兩棵各自獨立的樹，而不是一棵完整的樹。事後看起來就像兩件不相干的事，完全無法還原「這個任務整體怎麼流轉」。

W3C Trace Context：跨邊界傳遞的標準

OpenTelemetry 採用 W3C Trace Context 標準來處理跨服務的 context 傳遞。核心機制是透過 HTTP header（traceparent）攜帶 trace ID 與 parent span ID，接收端解析後就知道自己該掛在哪棵樹的哪個節點下。

如果 Agent 之間是透過 HTTP 或 gRPC 溝通，且使用了 OpenTelemetry 的自動 instrumentation，這個傳遞通常會自動處理。真正容易出問題的是非 HTTP 的溝通路徑：

透過訊息佇列（Pub/Sub）：需要把 trace context 放進訊息的 attributes，接收端再取出還原。

透過共享狀態或資料庫：如果 Agent B 是被排程觸發、從資料庫讀取待處理任務，那 trace context 必須跟著任務資料一起存進去。

透過自訂協定：完全需要應用層自己處理。

多 Agent 場景的 Span 樹

正確傳遞之後，跨 Agent 的樹會長這樣：

invoke_agent (orchestrator)                    [5,200ms]
├── chat (規劃任務分派)                        [580ms]
├── invoke_agent (research_agent)              [2,100ms]
│   ├── chat                                   [640ms]
│   └── execute_tool (web_search)              [1,320ms]
├── invoke_agent (analysis_agent)              [1,890ms]
│   ├── chat                                   [720ms]
│   └── execute_tool (run_calculation)         [1,050ms]
└── chat (整合結果產生回應)                     [610ms]

這棵樹讓你一眼看出：orchestrator 分派給兩個子 Agent、各自花了多久、瓶頸在 research_agent 的 web_search。

一個實用的驗證方法

跟 Day 9 提過的日誌驗證同理：挑一次跨多個 Agent 的執行，在 Trace Explorer 裡用 trace ID 查詢，看能不能看到完整的一棵樹。如果看到的是斷開的多棵樹，代表某個邊界的 context 傳遞漏了——通常就是前面提到的非 HTTP 路徑。

這篇的檢查清單

• [ ] 跨 Agent 的溝通路徑是否都確認過 trace context 有被傳遞？
• [ ] 非 HTTP 的路徑（訊息佇列、資料庫、自訂協定）是否有特別處理？
• [ ] 是否已實際在 Trace Explorer 驗證過能看到完整的跨 Agent 樹？