---
title: "Claude OpenTelemetry 公开测试：10 月 14 日起 agent 追踪可导出，五步区分网络与模型耗时"
description: "10 月 14 日 Claude Platform 开放 OpenTelemetry 追踪导出（公开测试）。本文说明支持范围、接入入口，以及怎样用 trace 判断慢在网络还是模型生成。"
url: https://cdnping.org/blog/claude-agent-observability-otel
language: zh-CN
published: 2026-10-19
category: "开发工具"
tags: ["Claude","OpenTelemetry","可观测性","Claude Code","Managed Agents"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# 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 月，来源是 [官方公告](https://claude.com/resources/articles/agent-observability-on-the-claude-platform) 和 [Claude Code 更新日志](https://code.claude.com/docs/en/changelog)。具体配置项、字段名以官方文档为准。

## 这次官方到底放出了什么？

公告里写明的内容：

- 来源：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 怎么用才省钱](/blog/claude-prompt-caching-save-cost) 一起看。auto mode 字段则对应 [Claude Code 默认进入 auto mode](/blog/claude-code-auto-mode-default) 里说的“命令被拦”排查。

## 怎么用 trace 区分网络延迟和模型生成耗时？

这是这套功能最实用的地方。下面是一个可以照做的流程，数值阈值要按你自己的基线定。

1. 先建基线。在观测工具里找一批正常时段的模型调用 span，记下延迟的中位数和高位分布，按模型和请求大小分组。
2. 看慢请求的构成。把慢 span 的输出 token 数和耗时放在一起看：输出 token 多，耗时长，多半是生成本身的时间；输出很少却很慢，才值得怀疑网络或服务端排队。
3. 看工具调用 span。agent 回合变慢，常常是某个工具或 MCP 调用占了大头，而不是模型。先把这部分排掉。
4. 与客户端网络数据交叉比对。trace 记录的是 Anthropic 侧与 SDK 侧的耗时，你自己的机器到 API 之间的链路需要另测。打开 [cdnping 首页](/) 的在线测速，看浏览器到 Claude API 的“首次连接”（含 DNS 与 TLS 握手）和“往返”（连接复用后 3 次请求的中位数）。往返值正常而 trace 里的调用慢，问题更可能不在你的网络。
5. 与服务端状态比对。打开 [/status/anthropic](/status/anthropic)，看 Cloudflare 边缘对官方入口每 5 分钟一次的探测。同一时间窗口内探测异常，说明是服务侧问题；探测正常而你这边慢，回头查本地链路和请求本身。

方法上的限制要说清：cdnping 的探测与测速只反映入口连通性和握手时间，不等于模型生成速度。口径见 [/methodology](/methodology)。

## 和已有的排查文章怎么配合？

- 本地感觉慢，先读 [Claude Code 慢怎么办](/blog/claude-code-slow-response-fix)，那篇讲延迟的几个来源。有了 trace 以后，可以把里面的判断落到具体 span 上。
- 官方状态页和事件等级怎么解读，见 [怎么看 OpenAI 状态页和 Claude 状态页](/blog/how-to-read-ai-status-pages)。
- 新模型上线后想持续观察可用率和延迟，见 [Anthropic 9 至 10 月连发三款新模型](/blog/claude-new-models-sep-oct-2026-api-watch)。

## 现在值得开吗？

公开测试意味着行为可能调整。比较稳妥的做法：先在一个非生产的项目上接入，确认目的地能收到数据、字段符合预期，再决定是否推到生产。另外 trace 可能包含 prompt、工具参数一类内容，开启前先确认观测平台的访问权限和保留策略；Claude Code 里有专门的开关（如 `OTEL_LOG_TOOL_DETAILS`）控制工具细节，是否打开以团队的数据规定为准。

## 参考来源

- [Agent observability on the Claude Platform（Anthropic，2026-10-14）](https://claude.com/resources/articles/agent-observability-on-the-claude-platform)
- [Claude Code Changelog：2.1.300、2.1.301](https://code.claude.com/docs/en/changelog)