Claude Platform 原生支持 OpenTelemetry，追踪数据可导出至 Databricks MLflow

智能体可能返回一个看似合理的答案，却遗漏了重要发现，或反复读取同一来源。仅凭答案无法解释原因。追踪记录展示了其背后的模型调用和工具调用，因此你可以调查失败原因、查找相关案例，并测试某项改动是否有帮助。

Databricks MLflow 现已成为 Claude Platform 原生 OpenTelemetry 导出的受支持目标。借助向 Databricks MLflow 的原生导出，使用 Anthropic SDK、Messages API 和 Managed Agents 的开发者可以将原生追踪数据发送到 Databricks，并使用 MLflow 调试其智能体并评估改动。

原生 OpenTelemetry，统一于 Databricks

MLflow Tracing 构建于 OpenTelemetry 之上，后者是用于收集和导出服务信号的开放标准。追踪记录将智能体的执行过程记录为一个个独立步骤，称为 span，例如模型请求和工具调用。Claude 的原生插桩会生成这些 span，并使用 OpenTelemetry Protocol 将其导出。

Databricks 通过 Zerobus Ingest 接收这些 span，并将其存储在关联到 MLflow 实验的 Unity Catalog 表中。你可以使用相同的调试和评估工具，将 Claude 追踪记录与其他已插桩服务的追踪记录一并检查。Unity Catalog 控制对数据的访问，你还可以使用 SQL 查询这些数据。借助 Zerobus 与 Unity Catalog 的结合，企业可以获得两项关键优势：在高 QPS 下实现低延迟的追踪数据摄取，以及对存储在智能体追踪记录中的敏感数据进行访问治理的能力。

Unity Catalog and Databricks MLflow — *Claude 的原生 OpenTelemetry 追踪数据流入 Unity Catalog 和 Databricks MLflow。*

3 步连接 Claude

1. 创建实验

在 Databricks 中，打开 Experiments 标签页并点击 Create Experiment。在 Trace storage location 下，保持选中 Unity Catalog。选择一个现有的 catalog 和 schema。这会创建新的 MLflow 实验，并关联到存储 OpenTelemetry 追踪数据的 Unity Catalog 表。
详细设置指南涵盖了权限和 SQL 仓库要求。

2. 配置原生导出

使用你的工作区 ID、区域和 span 表设置 Databricks 目标。Zerobus 连接指南说明了如何获取表级 OAuth 令牌。

新的原生 OTel 集成涵盖 Anthropic SDK、Messages API 和 Managed Agents。对于 Anthropic SDK，请安装以下软件包，并配置 OTel tracer provider 和 exporter，以便为 Anthropic SDK 调用创建 span。按照 Claude Platform OpenTelemetry 指南，将来自 Messages API 和 Claude Managed Agent 的追踪数据发送到你的 Databricks 目标。

Claude Code 和 Claude Agent SDK 也支持 OpenTelemetry。要将它们的追踪数据发送到同一目标，请在启动应用程序前设置以下额外变量：

3. 运行任务并检查追踪记录

运行你的 Claude 智能体，然后在实验中打开 Traces。打开一条追踪记录，检查其模型调用、工具活动、时序以及捕获的输入和输出。请注意，只有当你通过将内容模式设置为“full”来选择加入时，才会捕获输入和输出。

OTel trace in Databricks MLflow — *Databricks MLflow 中的原生 OTel 追踪记录，包含模型和工具 span。*

使用追踪记录调试和改进你的 Claude 智能体

一旦 Claude 的 trace 进入 MLflow，你就可以在整个开发过程中使用它们。一条 trace 既提供了用于调试的记录，也提供了供专家评审的案例，还为评估下一版 agent 提供了证据。

借助 trace 调试某个回答

意外的回答可能源于上下文缺失、工具调用失败，或模型使用工具结果的方式。MLflow 的 Analyze trace 操作会将 Genie Code 引入调查过程。它会检查记录的执行过程，帮助解释问题出在哪里。

针对缺失的上下文、失败的工具调用或开销较大的步骤提出后续问题，以检查解释背后的相关上下文。这有助于你决定是修改指令、改进工具，还是更改 agent 可用的上下文。

claude analyze gif — 点击 Analyze trace，用 Genie Code 调查选中的 Claude 执行过程。分析结果指出了缺失的发布说明和重复读取。

在 trace 和会话中发现反复出现的问题

MLflow Issues（Beta 版）使用 Genie Code 来识别反复出现的质量和运维问题。它会检查响应、工具调用、时序、错误和评估结果，然后将相关发现分组，并附上指向支持性 trace 的链接。示例包括浪费 token 的重复搜索、导致工具失败的缺失参数，以及不符合所需格式的响应。

你可以安排检测任务，让这项分析在新 trace 到达时持续运行。团队可以选择运行频率，使用元数据或标签聚焦特定流量，并自定义它查找的问题类型。修复之后，问题监控器可以跟踪该问题是否再次出现。MLflow 会为该问题创建一个评分器，评估最近的 trace 以建立基线，并对新 trace 的样本进行评分，以衡量其随时间出现的频率。

Three Affected Claude Traces — *一个手动编写的演示问题描述了重复的文档读取，并链接到三条受影响的 Claude trace。本演示未运行 Issue Detection。*

让领域专家评审 trace

有些质量判断需要领域知识。MLflow Review Queues 通过选定的 trace 和针对该 agent 定制的问题，将这种专业知识引入开发过程。

评审者可以评估记录的请求和响应，说明缺失了什么，并提供预期答案。他们的反馈有助于开发者改进 agent，并为后续评估建立参考答案。

用相同的案例评估变更

对指令、工具或技能的变更可能修复一个失败，同时引入另一个失败。trace 还让 agent 行为变得可衡量。在 Claude trace 上运行 MLflow Agent Evaluation，以测试对提示、技能、工具的变更究竟是改进了 agent 还是使其退化。

例如，以下代码执行一个 LLM 评判器，检查 agent 是否进行了冗余的工具调用。

当原始 agent 和修订后的 agent 针对相同案例运行过后，可以使用相同的评判器比较它们的评估运行。在 MLflow UI 中点击 Compare，即可并排查看分数和响应，并可借助底层 trace 解释仍然存在的失败。

Completed evaluations of the same three cases, comparing baseline and revised instructions. — 对相同三个案例完成的评估，比较基线指令和修订后的指令。

同样的方法也适用于检查智能体是否遵循了规定的工作流程或使用了合适的工具。使用 MLflow 测试和优化 Claude Code 技能展示了这些检查及其理由如何指导技能的改进。

了解更多并开始使用

以下资源涵盖将 Claude 连接到 Databricks MLflow 以及在开发过程中使用其追踪记录：

Claude OpenTelemetry 追踪指南：适用于 Anthropic SDK、Messages API 和 Claude Managed Agents 的原生 OpenTelemetry 导出配置。
在 Databricks 中使用 Unity Catalog 进行追踪：如果您刚接触 Databricks 中的追踪，本指南涵盖实验设置、追踪存储和访问。
检测并监控 MLflow 追踪中的问题：重复出现的故障模式、支撑性追踪证据以及持续监控。
使用 MLflow 评估 Claude Code 技能：行为评判器以及用于测试和优化技能的可重复流程。

第一个 CTA 条目在发布前仍需要专用的 Claude 集成指南 URL。