Claude OpenTelemetry 公開測試：10 月 14 日起 agent 追蹤可匯出，五步區分網路與模型耗時
Claude OpenTelemetry 匯出已經可以用了：Anthropic 在 2026 年 10 月 14 日宣佈，Claude Managed Agents、Messages API 和 Claude SDK 可以把追蹤（trace）匯出到任何接受 OTLP 端點的觀測工具，目前是公開測試（public beta）。每個 agent 回合、模型呼叫、工具呼叫都會變成一條標準 trace，帶延遲、token 數和 ID。排查“agent 為什麼慢”時，可以直接在自己的觀測平臺裡按 span 看每一段耗時。
以下內容截至 2026 年 10 月，來源是 官方公告 和 Claude Code 更新日誌。具體配置項、欄位名以官方文件為準。
這次官方到底放出了什麼？
公告裡寫明的內容：
- 來源：Claude Managed Agents、Messages API、Claude SDK。
- 內容：agent 回合、模型呼叫、工具使用、MCP 伺服器呼叫，資料包含延遲、token 和 ID。
- 格式：標準 OpenTelemetry trace，遵循 OpenTelemetry GenAI 語義約定（GenAI semantic conventions）。
- 目的地：任何接受標準 OTLP 端點的工具。公告點名了 Grafana Cloud、Honeycomb、Sentry、Splunk，以及 Datadog、Langfuse、LangSmith、New Relic、Arize AI、Braintrust、PostHog 等。Databricks Unity Gateway 被列為按團隊統計 token 用量的方式。
- Claude Code 和 Cowork 的追蹤也可以發到同一個觀測工具裡。
公告沒有寫的內容：具體的 span 與屬性名、匯出限額、價格和保留期。這些別自己腦補，去看官方的 OpenTelemetry 文件（platform.claude.com 的 manage-claude 部分）。
怎麼接？
公告給出的入口分兩類：
| 場景 | 做法 |
|---|---|
| Managed Agents、Messages API | 在 Claude Console 裡新增一個追蹤目的地 |
| Claude SDK | 自動匯出 |
Console 裡的具體選單和欄位以官方文件為準，這裡不寫。通用思路是：先在 Grafana、Langfuse、Datadog 等工具裡拿到 OTLP 端點和鑑權頭，再按官方文件填進目的地。端點和金鑰屬於敏感資訊，別貼進工單或截圖。
Claude Code 這邊有什麼變化？
Claude Code 本身早就有 OTel 事件，最近兩個版本補了幾項：
- 2.1.300：
api_request事件新增cache_creation_5m_tokens和cache_creation_1h_tokens，把快取寫入按 5 分鐘、1 小時兩種生命週期拆開；trace span 新增 OpenTelemetry GenAI 語義約定屬性，例如gen_ai.provider.name、gen_ai.conversation.id、gen_ai.tool.name、error.type。 - 2.1.301：
tool_decision事件新增classifier_verdict和permission_mode，可以分清一次放行或攔截來自 auto mode 分類器還是許可權規則；設定OTEL_LOG_TOOL_DETAILS=1時還有classifier_category。
快取拆分對核對賬單有用，可以配合 Claude prompt caching 怎麼用才省錢 一起看。auto mode 欄位則對應 Claude Code 預設進入 auto mode 裡說的“命令被攔”排查。
怎麼用 trace 區分網路延遲和模型生成耗時？
這是這套功能最實用的地方。下面是一個可以照做的流程，數值閾值要按你自己的基線定。
- 先建基線。在觀測工具裡找一批正常時段的模型呼叫 span，記下延遲的中位數和高位分佈，按模型和請求大小分組。
- 看慢請求的構成。把慢 span 的輸出 token 數和耗時放在一起看：輸出 token 多，耗時長，多半是生成本身的時間；輸出很少卻很慢，才值得懷疑網路或服務端排隊。
- 看工具呼叫 span。agent 回合變慢，常常是某個工具或 MCP 呼叫佔了大頭，而不是模型。先把這部分排掉。
- 與客戶端網路資料交叉比對。trace 記錄的是 Anthropic 側與 SDK 側的耗時，你自己的機器到 API 之間的鏈路需要另測。開啟 cdnping 首頁 的線上測速，看瀏覽器到 Claude API 的“首次連線”（含 DNS 與 TLS 握手）和“往返”（連線複用後 3 次請求的中位數）。往返值正常而 trace 裡的呼叫慢，問題更可能不在你的網路。
- 與服務端狀態比對。開啟 /status/anthropic，看 Cloudflare 邊緣對官方入口每 5 分鐘一次的探測。同一時間視窗內探測異常，說明是服務側問題；探測正常而你這邊慢，回頭查本地鏈路和請求本身。
方法上的限制要說清：cdnping 的探測與測速只反映入口連通性和握手時間，不等於模型生成速度。口徑見 /methodology。
和已有的排查文章怎麼配合？
- 本地感覺慢，先讀 Claude Code 慢怎麼辦，那篇講延遲的幾個來源。有了 trace 以後，可以把裡面的判斷落到具體 span 上。
- 官方狀態頁和事件等級怎麼解讀，見 怎麼看 OpenAI 狀態頁和 Claude 狀態頁。
- 新模型上線後想持續觀察可用率和延遲，見 Anthropic 9 至 10 月連發三款新模型。
現在值得開嗎？
公開測試意味著行為可能調整。比較穩妥的做法：先在一個非生產的專案上接入，確認目的地能收到資料、欄位符合預期，再決定是否推到生產。另外 trace 可能包含 prompt、工具引數一類內容，開啟前先確認觀測平臺的訪問許可權和保留策略；Claude Code 裡有專門的開關（如 OTEL_LOG_TOOL_DETAILS）控制工具細節，是否開啟以團隊的資料規定為準。
