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）控制工具细节，是否打开以团队的数据规定为准。
