devgo.cn开发 Agent 应用时最头疼的事是什么？不是模型答错，而是它答得看似合理，实际却漏掉了关键信息，或者反复读同一个数据源。你盯着最终答案，根本看不出问题出在模型调用、工具调用还是上下文拼接上。传统日志只能告诉你发生了什么，不能告诉你为什么。这时候，追踪（trace）就是救命稻草——它把一次 Agent 执行过程拆成一个个 span（即执行中的单个步骤，比如一次模型请求、一次工具调用），让你能沿着调用链逐层排查。
现在 Anthropic 把这条链路直接打通到了 Databricks MLflow。官方宣布 Claude Platform 原生支持向 Databricks MLflow 导出 OpenTelemetry（行业通用的可观测性标准，负责采集和导出服务运行信号）追踪数据，用 Anthropic SDK、Messages API 或 Managed Agents 的开发者，都能把 Claude 的调用痕迹一键送到 Databricks，用 MLflow 的调试和评估能力来定位问题。
这套方案不是简单地把日志导过去。它基于 MLflow Tracing，而 MLflow Tracing 本身就是构建在 OpenTelemetry 之上的。Claude 的本地埋点会生成 span，并通过 OpenTelemetry 协议导出。在 Databricks 这边，数据经过 Zerobus Ingest（Databricks 的高吞吐接入通道）接收，再把 span 存进 Unity Catalog 表（Databricks 的元数据治理和权限管理核心组件），同时关联到一个 MLflow experiment（即实验记录单元，用来组织追踪、指标和评估结果）。Zerobus 保证低延迟、高 QPS（每秒查询数）的写入，Unity Catalog 则让企业能对追踪数据里的敏感内容做细粒度权限控制。这两者组合，既解决性能又解决安全合规，是主打企业级需求的硬卖点。
配置流程也比较直接：在 Databricks 里创建一个 experiment，存储位置选 Unity Catalog，指定一个已有的 catalog 和 schema，就会自动建好存放追踪数据的表。然后拿到 workspace ID（工作区标识）、region（区域）和 spans 表名，再通过 Zerobus 连接指南获取一个表级 OAuth token（即只针对特定表授权的访问令牌），把这些填到 Claude 的配置里就完成对接。当前支持三种方式：Anthropic SDK（装一个额外的包，配置 tracer provider 和 exporter）、Messages API、以及 Managed Agents。Claude Code 和 Claude Agent SDK 也能用——只要设置几个环境变量，启动应用时指向同一个 Databricks 目标即可。
追踪数据进了 MLflow 之后，价值才开始显现。最直接的是调试：打开一个 trace，能看到模型调用、工具活动、耗时、以及捕获的输入输出（注意输入输出默认不记录，需要手动把 content mode 设为 full 才开启）。MLflow 的 Analyze trace 功能会用 Genie Code（Databricks 的智能编程助手）自动分析执行记录，告诉你问题出在上下文缺失、工具调用失败，还是模型没正确使用工具结果。你还可以追问额外问题，比如哪些步骤昂贵、哪些上下文导致误判，然后决定改指令、改进工具，还是调整给 Agent 的上下文。
更有意思的是 MLflow Issues（目前 Beta 版）。它用 Genie Code 自动识别重复出现的质量问题和操作问题，比如重复搜索浪费 token（令牌，模型计费单位）、工具调用缺少参数导致报错、回复格式不符合要求等。它会把相似问题分组，并且链接到对应的追踪样本。你还能定时运行检测，按 metadata（元数据）、标签或关注特定流量，自定义要查的问题类型。修复后，issue monitor（问题监视器）还会持续追踪这个问题是否复发——MLflow 会为问题创建 scorer（评估器），先在近期追踪上建立基线，再抽样打分，量化问题出现频率的变化。
有些质量判断光靠自动规则不够，需要领域知识。MLflow Review Queues 把人拉进流程：选定一批追踪样本，配上针对该 Agent 的提问，让有经验的人审查请求和响应，指出缺失的地方，给出预期答案。反馈既能用来改进指令，也能沉淀为参考答案，供后续自动评估使用。
最后是关键的一环：改了一版 Agent，怎么知道是变好了还是变坏了？用追踪数据可以量化。MLflow Agent Evaluation 支持直接在 Claude 追踪上跑评估，比如用 LLM judge（大模型当裁判，检查 Agent 是否做了冗余工具调用）。原版和改进版跑完同一批测试用例后，在 MLflow UI 里点击 Compare，并排看分数和响应，还能点开底层追踪解释残留的失败。这个思路同样适用于检查 Agent 是否遵守了规定的工作流、用了合适的工具。官方还提供了一个案例，展示如何结合 MLflow 测试和优化 Claude Code 技能（skills）。
对于正在做 Agent 工程化的人来说，这套集成的价值在于：把可观测性、权限治理、自动问题聚类、人工审核和在线评估串成了一条完整闭环。你不再需要自己拼装 Prometheus + Grafana 那套基础设施，也不用手动翻日志找规律。需要注意的坑有两点：一是输入输出默认不记录，排查性能问题可能够，但定位语义错误必须先开启 full content mode；二是分析工具（Issues、Review Queues）依赖 Genie Code 和 MLflow 的 Beta 功能，生产环境要评估稳定性。如果团队已经用 Databricks 存数据，这可能是把 Claude Agent 的可观测性统一起来的最短路径。
内容与图片版权归原作者所有 · 原文: https://www.databricks.com/blog/claude-platform-now-supports-native-opentelemetry-observability-databricks-mlflow