非正式商单。本稿为冷启动深度，依据公开文档改写，非客户委托，无赞助。
开篇
演示视频里，Agent 往往一次跑完：检索、调用、作答，时间线很干净。生产验收问的是另一组问题：卡在第几步、这一步的 latency 是多少、烧掉多少 token、碰了哪个工具或哪台 MCP server。2026 年 10 月 14 日，Claude Platform 把这些步骤收成 OpenTelemetry trace。观测开始向微服务世界的 span / trace 靠拢。这比再发一张参数表更接近「能排障」。
发生了什么
Anthropic 当日在资源站发文，宣布 Claude Managed Agents、Messages API 与 Claude SDKs 可以向外部发送 OpenTelemetry（OTel）traces，并写明功能处于 public beta（公测）。1 痕迹可送到任意 OTel 工具。公告列出的负载是 latency、tokens 与 IDs，用来跟着 Agent 的每一步走。1
配置在公告里分成两支。Managed Agents 与 Messages API 需要在 Claude Console 添加 destination；Claude SDKs 按原文 export traces automatically。1 公告所链的平台文档把操作写得更细，两支可以同时开。2
- SDK tracing：在应用里安装 SDK 并注册 tracer provider，trace 从你的进程流出。文档写明这条路径不另要 Console 权限，覆盖面是「使用该 SDK 的客户端」，云平台支持栏为 Any。2
- API tracing：在 Console 配置 destination。文档写明需要组织 Admin，覆盖面是任意客户端；云平台支持栏列出的是 Claude Platform，以及 Claude Platform on AWS。2
- 两条一起开：同一次请求的 SDK span 与 API span 可以出现在同一条 trace 里。2
「自动导出」在公告里是相对 Console destination 说的。落到工程上，SDK 仍要注册 tracer provider，并接到你自己的导出管线。本稿不把这句话写成零配置。
语义约定是这篇公告里较硬的一句：Claude traces 遵循 OpenTelemetry GenAI semantic conventions，因此 Claude 与其他供应商的数据可以进同一套工具和看板。1 文档复述了同一点：API 与 SDK 使用这套约定里的属性，支持该约定的平台不必为这些 span 再做一层专有解析。2
粒度上，公告的说法是：配好 destination 之后，每一次 agent turn、每一次 model call、每一次 tool use，都以标准 OTel trace 到达观测工具，并带上 latency、tokens 与 IDs。1 文档中的示例把父子关系写出来了，下面这些名字出自示例，不是一份冻结的字段全集：2
- Messages API：服务端为「创建消息」的请求建立 span；其下再为每次 model request 建 span；API 自己执行的 server tool、MCP connector tool 各有 tool span。应用若使用 tool runner，SDK 侧会出现
anthropic.messages.tool_runner、anthropic.custom_tool_use，以及每次请求的 client span。 - Managed Agents：session 上有 Sessions API 请求 span，每个 agent turn 有 turn span（示例中的名字包括
anthropic.session.turn）。一次由请求拉起的 turn 挂在该请求 span 之下。turn 内再含 model request、API 执行的 tool（文档注明有例外，以 tool span 参考页为准），以及 outcome evaluation 的 span。
同一请求的 token 用量会出现在它的多个 span 上。文档要求按「Counting tokens」一节去重后再计数，避免把同一次消耗加好几遍。2
默认导出的不是整段对话。每个 destination、每个 SDK 客户端各有 content mode：2
- Metadata only（SDK 里的
metadata_only）为默认。Span 包含标识、耗时、状态、token 计数，以及你选择附上的文本，例如 agent 与 tool 的名称和描述、MCP server 的名称。 - Full content（SDK 里的
content）在此之上加入模型的 prompt 与 response。文档示例把 system prompt、请求消息和回复分别放在gen_ai.system_instructions、gen_ai.input.messages、gen_ai.output.messages。
组织若与 Anthropic 存在 HIPAA、FERPA 或 K-12 数据处理限制，destination 不论模式如何都只导出 metadata；文档写明这条限制不作用于 SDK span。2 Full content 下，单个 span 默认最多容纳 0.75 MB，文档说明这大致盖得住 20 万 token 的英文上下文，并低于许多观测平台和代理 1 MB 的请求上限。超出则截断，并把 anthropic.content.truncated 设为 true：请求 span 先去掉 system prompt 和最早的消息，tool span 从结果末尾丢块；图片和文档只保留类型。2 SDK 用 traces.max_content_bytes 调整；Console 在 Full content 的 Advanced 里设置 Maximum content size（MB）。选合作方作为 Provider 时，Console 会设成该平台能接受的上限。2
公告还写了一句衔接：若你已经把 Claude Code 或 Cowork 的 traces 送进现有观测工具，在 Claude Platform 上构建的 Agent 也可以出现在同一处。1 Claude Code、Agent SDK、Cowork 各自另有监控文档，不在本稿展开。2
下游工具方面，公告点名 Grafana Cloud、Honeycomb、Sentry、Splunk，用于把 Agent trace 放在日志和指标旁边；点名 Arize AI、Braintrust、Datadog、Langfuse、LangSmith by LangChain、New Relic、PostHog，用于把真实 trace 变成 eval；点名 Databricks Unity Gateway，用于按团队看 token、标记异常活动。1 同一页写明：任何接受标准 OTLP endpoint 的 OpenTelemetry 工具都可以接。1 这份名单是原链的互操作说明。本稿没有逐家复现部署，也不把它当成已核实的客户案例。
公测不是一般可用声明。采样率、账单是否以 trace 为准、span 名是否在 beta 期间改名，公告正文都没有给出。上架前应以脚注两页的当时文本为准。
为什么重要
已发快讯只确认三件事：三条产品线可以导出、负载里有时长和 token 以及工具调用、排障开始可以向查 span 靠拢。下面三节是本稿相对那条短讯新增的判断。
少维持一套只属于 LLM 的私有日志。 GenAI semantic conventions 的用处，是让现有后端认出「这是一次模型调用、这是一次工具调用」，而不必为 Claude 再写一种日志方言。值班打开的仍是团队已经在用的 trace 界面。约定只有在 OTLP 真的进了 Collector 或 APM 之后才成立；停在公告摘要里，就还是另一份参数说明。
值班手册可以对齐微服务的排障路径。 一次用户请求对应一条 trace。模型往返、服务端工具、客户端工具、MCP 调用是其中的 span。慢，看 latency 落在哪一个子 span；错，看 status 停在 tool 还是 model request；贵，看 token，但必须先按文档去重。这三句可以写进 runbook。验收口径从此有地方落笔：不是「这段录屏流畅」，而是「失败请求能在 trace 里指出停在哪一个 span」。
「可观测」会比参数表更接近生产验收，前提是真接得上。 参数表回答模型名称和上下文长度。Trace 回答这一次调用是否留下了可检索的步骤、工具有没有被调用、权限是否放得比证据更宽。公告自己把顺序写成：先 trace 模型调用、工具使用和 MCP server 调用，看过痕迹、确认可靠，再放宽访问。1 平台方可以把验收写成这个顺序。没有 destination、也没有 tracer provider 的环境，不进入扩大工具权限的阶段。公测阶段的验收句应是「导出可用，且字段与当时文档一致」，而不是「观测已经完备」。
影响谁
平台与编排方。 客户侧的验收项会从一段演示，加一条「能否交出 OTel trace」。编排层如果把 Claude 包在自有网关后面，需要同时想清楚两支导出：应用进程里的 SDK span，以及 Console 里、覆盖 Managed Agents 与 Messages API 的服务端 span。只开其中一支，排障图会缺半边。文档把 API tracing 的云平台支持写为 Claude Platform 与 Claude Platform on AWS。2 文档未列入的托管渠道，本稿不外推。
落地团队。 调试动作从回放对话，变成在已有 trace 后端里按 span 下钻。已有 OTel Collector、Jaeger、Grafana Tempo 或某家 APM 的团队，增量主要是 destination、tracer provider 和字段约定。还没有观测栈的团队，验收清单里应把 trace 放在演示视频之前：没有 trace，就无法按公告所说的方式核对工具与 MCP 调用，再决定是否放宽权限。1
云与模型侧叙事。 对外讲「企业可用」时，可观测会比再贴一张参数表更硬，因为它能被买方的值班系统收下。硬的条件是：OTLP 进得了对方的 Collector，GenAI 属性能被对方的看板认出，Full content 的合规开关有人签字。合作方名单证明的是「有人写了对接文档」，不证明采用规模，也不证明任何成交。
落地 checklist
以下顺序依据公开文档和通用 OTel 接法整理，供值班手册起草。它不是 Anthropic 内部架构说明，也不包含官方未写的采样率或配额。
- 先定导出路径。 只看应用内工具运行：注册 SDK tracer provider。2 要看 Managed Agents 的 turn、Messages API 的服务端 model run 与 server tool：由组织 Admin 在 Claude Console 添加 destination。12 需要一张图上同时有客户端和服务端：两条都开。2 SDK 的「自动」指不必再为 SDK 单独配一条 Console destination，不指跳过 tracer provider。
- 接到 Collector。 公告承诺的是标准 OTLP，以及一批已写对接说明的平台。1 团队若已有 OpenTelemetry Collector，优先让导出进入这条管道，再由 Collector 转发。这样后端更换时不必改 Claude 侧的目的地。Console 的 destination 是在 Claude 控制台配置的；SDK 的导出走应用进程。两条管道是否在 Collector 汇合，由你们的拓扑决定，文档没有规定必须汇合。
- 选定后端。 自建 trace 查询，常见是 Jaeger 或 Grafana Tempo，二者都吃 OTLP，但是团队自己的选择，不是原链点名的产品。已有 APM 则沿用值班已经会打开的那一个。公告点名的 Grafana Cloud、Honeycomb、Sentry、Splunk、Datadog 等，只说明原链认为这些工具能接收这类 trace。1 写入环境清单之前，用一条真实的 Messages 请求或一次 Managed Agents turn 走通，确认 span 出现在该后端。
- 约定关键字段。 先保持默认
metadata_only，把标识、耗时、状态、token、工具名和 MCP server 名对齐到看板上。2 Runbook 可以暂时锚定文档示例里的 span 名：anthropic.messages.create、anthropic.model_request、anthropic.tool_use、anthropic.custom_tool_use、anthropic.session.turn、anthropic.messages.tool_runner。2 Token 图表必须按文档的 counting tokens 去重。2 打开 Full content 之前单独评审：prompt 与 response 会离开进程；HIPAA / FERPA / K-12 限制下，destination 仍只会收到 metadata；单 span 默认 0.75 MB，超限看anthropic.content.truncated。2 零数据保留（zero data retention）与 Full content 的关系以文档为准：Messages API 的导出内容在送达前只留在内存；Claude Managed Agents 不适用零数据保留，开启 OpenTelemetry 不改变它原有的保留策略。2 - 挂到现有告警路由。 不要为 LLM 再造一条独立的值班通道。慢的
model_request或超阈值 latency，进现有延迟告警；span status 表示失败的 tool 或请求，进现有错误告警；token 在去重后异常抬升，进现有用量或成本通道。公告把「按团队看 token、标记异常活动」写在 Databricks Unity Gateway 那一条，那是原链给出的一个去处，不是唯一做法。1 告警阈值由你们的 SLO 决定，官方文章没有给数字。Trace 用来定位步骤。用量对账仍以团队现有账单口径为准，本稿不把 trace 加成计费接口。
做完这五步，再按公告的顺序放宽 Agent 的工具与 MCP 权限：痕迹里能指出失败步骤，才扩大访问。1
边界与披露
本稿是冷启动深度。结构按正式深稿来写，事实限于 2026-10-14 公告及其所链的公开文档，在 2026-10-16 可复核的文本范围内改写。非客户委托，无已签约案例，不写经营结果。页内赞助状态为非正式商单。若日后改成付费或置换稿，须另加赞助披露句，并经授权定稿。
公测期间 span 名、属性与 Console 表单项都可能改。本稿只把该功能写成 public beta，不把它写成稳定提供或普遍可开通。原链页脚的相关文章是独立篇目，不构成对本项导出功能的客户证明，本稿不引用。合作方链接只说明互操作文档存在。
同页互链
短讯已经挂在快讯区，本文挂深度区，两篇不互相复读。
- 快讯：Claude Platform 公测 OpenTelemetry：Agent 可观测性入栈（同页锚点 /#flash）
- 本文入口：同页深度区 /#depth
信源脚注
- Anthropic / Claude：《Agent observability on the Claude Platform》（页题亦作 Trace agents with OpenTelemetry on the Claude Platform）。日期 October 14, 2026。原链：https://claude.com/resources/articles/agent-observability-on-the-claude-platform
- Claude Platform Docs：《OpenTelemetry for the Claude API》。公告「Get started」所链文档：https://platform.claude.com/docs/en/manage-claude/opentelemetry。Span 名与属性详见该页所链的 OpenTelemetry span reference。GenAI 语义约定仓库：https://github.com/open-telemetry/semantic-conventions-genai/