核心要点速览

  • Claude 开放遥测追踪是 Anthropic 的 Claude 开发者团队在 2026 年 10 月 14 日宣布进入公测的平台能力，可把 Messages API、Managed Agents 与 SDK 调用导出为 OpenTelemetry 追踪数据。
  • 数据通过 OpenTelemetry 导出器发送到你现有的可观测性后端，不需要更换监控厂商，也不必自建一套私有格式的解析流程。
  • 每个 span 记录耗时、状态与 token 流向，多个 span 组成 trace 后可用于定位延迟瓶颈、统计错误并还原智能体的运行路径。
  • 建议先在暂存环境验证链路，再分阶段放量，并提前规划采样比例与保留周期；公测期间字段定义与支持范围请以官网文档为准。

项目速览

类型/定位面向生产 AI 工作负载的可观测性追踪能力
适用设备可运行 Claude SDK 或调用 API 的服务器与开发机
费用说明公测阶段随平台提供，具体计费以官网为准
语言支持覆盖 Claude SDK 支持的语言，清单见官网
核心亮点API、Managed Agents 与 SDK 调用统一导出为 span
使用门槛需已有 OpenTelemetry 可观测后端与配置能力
分类开发与工具
作者 / 发布方ClaudeDevs
官方网站anthropic.com ↗
热度🔥 热度 97万
最后更新

从黑盒到链路图：Claude 开放遥测追踪要解决的问题

Claude 开放遥测追踪是 Anthropic 旗下 Claude 开发者团队在 2026 年 10 月 14 日宣布进入公测的一项平台能力。它做的事情很直接：把 Claude 平台上的调用过程以 OpenTelemetry 追踪的形式，发送到你已经在用的可观测性系统里。过去团队想知道一次回答为什么慢、哪个环节报错、token 花在哪里，往往只能靠自己在应用层加日志和计时器。现在这些信息由平台侧直接产出，开发者不必再手工拼凑。

OpenTelemetry 是一套跨厂商的遥测数据标准，追踪部分用 span 描述一次操作的开始、结束、耗时与属性，多个 span 串起来就是一条 trace。Claude 平台遵循这套约定，意味着你不需要为它更换监控厂商，也不需要写一套私有格式的解析器。只要你的后端支持接收 OpenTelemetry 数据，就能把 Claude 的调用链路和数据库查询、缓存命中、外部接口调���放在同一张时间轴上对照。

它面向的是已经在生产环境跑 AI 工作负载的团队，而不是只想试玩一次的个人用户。典型场景包括客服机器人、代码助手、批量文档处理流水线，以及由 Managed Agents 驱动的多步骤自动化任务。这些系统的共同点是调用量大、链路长、失败代价高，一旦出现问题，靠零散日志很难定位。公测意味着功能已可实际使用，但接口和行为仍可能调整，正式上线前建议保留回退方案。

  • 覆盖三类调用来源

    Messages API、Claude Managed Agents 与各语言 SDK 的请求都能产出追踪数据，不必分别接入三套方案。

  • 沿用现有可观测栈

    数据通过 OpenTelemetry 导出器发出，你继续用熟悉的监控与追踪平台查看，不需要迁移整套工具链。

  • 面向生产而非演示

    它解决的是线上延迟、错误与 token 流向的定位问题，适合已有稳定调用量的团队。

span 里能看到什么：延迟、错误与 token 流向

开启追踪后，每一次 Messages API 调用都会产生对应的 span，记录这次请求从发出到返回的耗时。多个 span 组合成 trace 后，你可以在瀑布图里看到各段耗时如何叠加，判断瓶颈是在模型推理、网络往返，还是在你自己插入的中间步骤。错误信息同样会体现在 span 上，方便你把失败请求和成功请求分开统计，而不是在一堆日志里翻找。

token 流向是另一个实用维度。追踪数据能帮助你把输入与输出的消耗对应到具体调用，从而发现哪些提示词或哪些功能模块在悄悄放大成本。对于按量计费的生产系统，这类信息往往比总账单更有价值，因为它指向可以优化的具体位置。需要注意的是，追踪记录的是调用元数据与链路结构，具体字段名称和可见范围请以官方文档为准。

Managed Agents 的追踪是这次公测里比较受关注的部分。智能体运行通常包含多轮模型调用、工具调用和中间决策，过程长且分支多，传统日志很难还原完整路径。把智能体运行变成一条可展开的 trace 后，每一步做了什么、在哪一步偏离预期，都能被直接看到。这也是不少开发者认为它比单纯统计延迟更有意思的原因。

  • 瀑布图定位瓶颈

    把一次请求拆成多个 span 后，耗时叠加关系一目了然，能快速区分平台侧耗时与应用侧耗时。

  • 错误按调用归类

    失败请求会带着状态与属性进入追踪系统，便于按接口、按版本、按用户维度聚合分析。

  • token 消耗可追溯

    把用量对应到具体调用，有助于找出成本异常的功能模块和提示词，而不是只看到月度总额。

  • 智能体过程可视化

    Managed Agents 的多步运行会展开成完整链路，工具调用与中间决策不再藏在黑盒里。

接入实操：从暂存环境到生产环境的落地顺序

接入的第一步是在你的 Claude 集成里启用追踪开关，然后配置一个 OpenTelemetry 导出器，把数据指向你现有的可观测性后端。导出器需要知道接收地址和认证方式，这部分与你接入其他服务时的配置逻辑基本一致。建议先在暂存项目里完成这一步，不要直接改生产环境的配置，避免因为导出器写错地址而产生大量无效请求。

配置完成后，发几条 Messages API 调用做验证，确认 span 真的到达了后端。验证时要检查三件事：链路是否完整、字段是否齐全、耗时是否合理。如果数据没到，优先排查导出器地址、认证凭据和网络出口，这三处是最常见的失败点。确认无误后再逐步扩大流量，先覆盖一个非核心功能，再推向全量。

上线之后建议给追踪数据设置采样策略和保留周期。全量采集在高并发场景下会产生可观的存储与传输开销，而按比例采样通常足以发现趋势性问题。同时把追踪数据与现有的告警规则打通，让延迟突增或错误率上升能自动触发通知，而不是等人去翻看面板。具体采样参数和保留上限请查阅官方文档，公测期间这些细节可能变化。

  • 先暂存后生产

    在暂存项目验证导出链路，确认 span 正常到达后再切换生产配置，风险最低。

  • 三条验证清单

    检查链路完整性、字段齐全度和耗时合理性，任何一项异常都说明配置还没到位。

  • 采样与保留要提前规划

    按比例采样通常足够定位问题，同时能控制存储和传输成本，避免账单意外上涨。

  • 接入告警闭环

    把追踪指标接到现有告警规则，让异常自动通知，而不是依赖人工定时巡检。

与自建埋点和纯日志方案相比，它适合谁

在它出现之前，团队通常有两种做法：一是在应用层自己埋点，记录每次调用的开始时间、结束时间和返回状态；二是依赖平台提供的日志和用量报表。自建埋点的好处是字段完全可控，代价是要维护一套与业务代码耦合的计时逻辑，模型或 SDK 升级时容易失效。日志方案成本低，但缺少链路结构，跨服务排查时仍然要靠人工拼接。

Claude 开放遥测追踪的定位介于两者之间：链路结构由平台侧产出，数据格式遵循通用标准，你只需要负责导出和展示。它不能替代业务层的自定义指标，比如用户满意度或任务完成率，这些仍然要自己采集。它也不负责解释模型为什么给出某个答案，追踪看到的是调用过程，不是推理内容本身。把它当作基础设施层的观测手段，预期会更准确。

目前的限制主要来自公测状态。官方还没有为这项能力设立独立页面，相关说明分散在平台文档中，具体支持的 SDK 语言、字段命名和导出协议细节都需要以官网 anthropic.com 上的最新文档为准。如果你的团队还没有可观测性后端，需要先解决这个问题，否则追踪数据无处可去。对于调用量很小、问题靠日志就能定位的项目，接入它的收益也相对有限。

  • 比自建埋点更省维护

    链路由平台侧产出，不必在业务代码里维护计时逻辑，SDK 升级时也不容易失效。

  • 比纯日志更有结构

    span 与 trace 提供跨调用的层级关系，排查长链路问题时不必人工拼接时间戳。

  • 不覆盖业务指标

    用户满意度、任务完成率等仍需自行采集，追踪只回答调用过程发生了什么。

  • 公测期细节会变

    独立页面尚未上线，语言支持与字段定义请以官网文档为准，并保留关闭追踪的回退开关。

分步上手指南

  1. 确认前置条件

    先确认项目已在调用 Messages API、Managed Agents 或官方 SDK，并且团队已有可接收 OpenTelemetry 数据的可观测性后端。若还没有后端，需要先选定并部署一个，否则追踪数据没有落点。

  2. 在集成中启用追踪

    在你的 Claude 集成配置里打开追踪开关，让平台开始为调用产出 span。不同 SDK 的开启方式可能不同，具体参数名和默认值请查阅官方文档，不要凭经验猜测。

  3. 配置导出器指向你的后端

    配置一个 OpenTelemetry 导出器，填入可观测性后端的接收地址与认证凭据，把数据导向你现有的监控平台。建议先在暂存项目完成这一步，确认地址和凭据无误后再动生产配置。

  4. 用少量调用验证链路

    发几条 Messages API 请求，到后端确认 span 是否到达，并检查链路完整性、字段齐全度和耗时是否合理。数据没到就先排查导出器地址、认证凭据和网络出口这三处。

  5. 分阶段放量并设置采样与告警

    确认无误后先覆盖一个非核心功能，再逐步推向全量，同时设置采样比例和保留周期以控制成本。最后把追踪指标接入现有告警规则，让延迟突增或错误率上升能自动通知。

常见问题

Claude 开放遥测追踪要额外付费吗？

官方目前把它作为 Claude 平台公测阶段的一项能力提供，没有公布独立的定价方案。实际是否产生额外费用，取决于你的可观测性后端如何计费，以及追踪数据的存储和传输量。建议以官网 anthropic.com 上的最新说明为准。

它支持哪些编程语言和 SDK？

官方说明覆盖 Messages API、Claude Managed Agents 以及 Claude 的各语言 SDK，但公测期间具体支持清单可能调整。由于这项能力还没有独立页面，最稳妥的做法是查阅官网文档中关于 SDK 与追踪的章节，确认你使用的语言版本是否在列。

追踪数据会不会包含提示词和模型回答的内容？

追踪的重点是调用链路结构、耗时、状态和 token 流向等元数据，用于定位性能与错误问题。至于是否附带请求内容，取决于具体字段配置，官方文档会说明可见范围。如果涉及敏感数据，建议在接入前确认字段清单，必要时在导出环节做过滤。

没有可观测性后端可以用吗？

这项功能的设计前提是把数据导出到你已有的可观测性系统，因此需要先有一个能接收 OpenTelemetry 数据的后端。市面上有多种开源和商业方案可选，选择时主要看是否支持 OpenTelemetry 协议以及团队的运维能力。没有后端的情况下，追踪数据无处接收。

公测阶段接入需要注意什么？

公测意味着功能可用但接口和行为仍可能变化，字段命名、采样参数和支持范围都有调整的可能。建议先在暂存环境验证，保留关闭追踪的开关，并把接入范围控制在一个非核心功能上。等官方发布正式文档和独立页面后再扩大使用。