Claude OpenTelemetry 可观测性接入 Databricks MLflow，让智能体故障无所遁形

Claude OpenTelemetry 可观测性现已原生连接至 Databricks MLflow，揭示那些看似令人信服的最终回答可能掩盖的执行细节。OpenTelemetry 是用于记录和交换应用程序活动的开放标准。该集成为开发者提供了另一种调查智能体问题的方式，包括遗漏证据、重复工作或最终给出不完整回答等情况。

Databricks 于 2026 年 11 月 3 日宣布支持这一目标平台。Anthropic 则于 10 月 14 日以公开测试形式推出了更广泛的原生追踪能力。这一区别很重要：这是更广泛导出系统中的 Databricks 集成，而非一项独占监控合作安排。

核心矛盾在于团队如何评判智能体表现。一份润色完善的回答展示了智能体交付了什么；执行记录则有助于解释它是如何得出结果的。Langfuse、Grafana 及其他可观测性平台已覆盖这一领域。Databricks 正将其开发与评估平台 MLflow 定位为一个场所，用于把这些证据与调查和后续测试关联起来。

Claude OpenTelemetry 可观测性新增原生 Databricks 目标平台

据 Databricks 介绍，开发者可通过 Anthropic 开发库、Messages API 和 Claude Managed Agents，将原生 Claude 执行记录发送至 MLflow。API 是应用程序用来请求服务的接口。Managed Agents 是由 Anthropic 托管并执行任务的智能体。

这一原生追踪集成使用 Databricks 的摄取服务 Zerobus Ingest 接收记录。其数据治理系统 Unity Catalog 会将这些记录存储在与 MLflow 实验相关联的表中。

这一变化为 Claude 活动提供了直接进入现有企业调查环境的路径。

追踪记录一次执行，而 span 则表示该记录中的单项操作。模型请求和工具活动可以显示为独立的 span。它们之间的关系让调查人员能够跟踪一条回答背后的操作序列。

对于开发团队而言，这一序列改变了调试讨论的起点。团队不必要求某人凭记忆还原一次失败的交互，而可以检查已记录的活动。这并不会自动确定正确的诊断结论，却能为诊断提供具体的依据。

当一个回答看似合理时，这一区别尤其有用。明显的错误会立刻引发调查；而即使智能体忽略了决定性来源，或为收集信息付出了不必要的努力，一份貌似可信的回答仍可能逃过注意。

设想一个假设性的内部研究助手正在准备产品更新。其最终摘要包含准确的背景信息，却遗漏了一份最近的发布说明。仅阅读摘要会留下多种可能解释：该助手可能从未找到该文档、误解了其中内容，或是在撰写回答时遗漏了这项发现。

执行记录有助于区分这些可能性。每种解释都指向不同的干预措施。如果检索步骤从未呈现相关文档，修改写作指令几乎不会起作用。

这正是该公告的运营意义。原生导出缩短了智能体交互与用于调查该交互的工具之间的距离。团队仍需自行界定何种行为构成失败。

该集成也为这则消息划出了明确边界。它并未宣布新的 Claude 模型、更高的基准测试分数，或经独立测量的可靠性提升。其直接贡献是收集并访问证据。

这比“智能水平提升”是更狭窄的主张，但它解决了智能体部署中的一个实际弱点：团队难以持续改进自己难以检查的行为。

智能体负责人面临解释“可接受回答”的压力

直接压力落在那些批准智能体进入实际工作流的开发者和产品负责人身上。他们的责任不止于判断一个回答听起来是否有用，还必须解释遗漏的发现、浪费的工作，以及只有在部署后才会显现的故障。

原生追踪提高了这些决策可获得证据的标准。

演示通常展示一次经过挑选的交互。生产环境则会引入多样的问题、不完整的文档、不断变化的工具和含糊的请求。一个能妥善处理熟悉示例的智能体，在周边条件变化时仍可能陷入困境。

这既是管理问题，也是工程问题。产品负责人需要区分可容忍的限制与反复出现的缺陷；开发者需要足够的证据来复现缺陷；领域专家需要判断回答本应包含什么。

如果没有共享记录，这些群体可能各说各话。审查者认为某个回答不完整；工程师看到的是一次成功请求；产品经理看到的则是完成了工作流的用户。每项观察都可能准确，却仍无法解决根本问题。

Claude 智能体追踪为这场讨论提供了共同对象。团队可以审查一次具体执行，并将反馈与实际发生的情况关联起来。其价值在于让分歧变得足够具体，从而能够展开调查。

Anthropic 的智能体可观测性发布公告包含了采用不同监控平台的客户案例。Foxglove 描述了如何在 PostHog 中结合产品活动分析智能体交互；FloQast 描述了如何在 Grafana Cloud 中将模型活动与会计工作流关联起来。

这些案例说明了不同的优先事项。机器人产品团队希望了解辅助功能在哪些环节未能达到预期；金融工作流团队则希望获得一份可辩护的智能体行为说明。这两种需求都不止于检查最终文本。

这些仍是由 Anthropic 展示的客户陈述，而非对 Databricks 集成的独立评估。它们证明了相关使用场景的存在，却无法证明一种普遍适用的业务结果。

对于知识工作者而言，当摘要成为另一项决策的依据时，同样的问题也会出现。遗漏的限定条件可能被带入规划文档、客户回复或工程讨论中。流畅的语言会令这种遗漏更难察觉。

正在构建可搜索知识库的团队会面临相关问题：哪些文档支撑了这份回答？智能体运营者还必须调查系统是否以恰当方式访问并使用了这些文档。

因此，压力是具体存在的。任何扩大智能体职责范围的人，都需要一种可信的方法来审查故障并确定修复优先级。原生导出让这种审查更容易启动，但并不能免除判断智能体是否应承担更多责任的工作。

该机制将执行证据与评估连接起来

重要的机制，是将记录下来的行为与可重复的开发决策联系起来。如果证据从未改变团队调查或测试智能体的方式，收集活动的价值就会十分有限。

当一项发现转化为可测试的解释时，MLflow 追踪分析才会发挥作用。

设想一个假设性的研究智能体，在生成一份不完整摘要前反复打开某个文档。反复访问是可见行为，原因却仍有待确定。该智能体可能缺少停止规则、收到不一致的工具结果，或有合理理由重新查阅不断变化的信息。

若将每一次重复读取都视为浪费，便会把这些解释压缩成一个误导性的捷径。调查人员需要理解，重复操作是否贡献了有用证据。理想的修复方式取决于这一区别。

因此，一项有效调查应将观察到的行为与预期结果关联起来。团队应能说明出了什么问题、为何拟议的改动能够解决问题，以及什么证据会推翻这一解释。

Databricks 文档介绍了通过 MLflow Issues 进行的重复问题检测。MLflow Issues 是一项由其编码助手 Genie Code 驱动的测试版功能。该系统会分析记录的活动，并将证据归类为待调查的问题。

文档还介绍了监控器：它们根据近期追踪建立基线，并对传入活动的样本进行评分。评分器是用于评估指定行为或结果的函数。

这些能力支持一个开发循环，但不应被误认为自动保证。问题检测器提出了一种有用的观察分组方式；评分器则将某种定义操作化。二者都无法替代核查该定义是否符合实际任务的需要。

例如，奖励更少工具调用次数的评估，可能会鼓励过早作答。更好的评估应在完整性之外兼顾不必要的工作。否则，看似提升的效率可能仅仅反映了调查得更少。

同样的推理也适用于回答速度。当答案仍能满足请求时，更快完成是有价值的；如果智能体跳过了重要来源，较短的执行过程反而可能掩盖质量回退。

保持任务和评估标准不变，有助于使比较结果更易解释。团队可以询问：修订后的指令是否改善了问题行为，同时又不削弱无关的要求？这比比较不同版本中互不相关的示例更有信息价值。

凡是正确性取决于语境之处，人类专业知识仍不可或缺。领域专家可以识别缺失的例外情况，或解释某项看似冗余的操作为何合理。这些判断有助于避免自动化评估奖励错误的行为。

产品层面的含义是，可观测性与评估应属于同一场开发对话。执行证据解释结果；评估则测试拟议修复能否在具有代表性的任务中成立。

因此，对买家而言，相关问题不止于平台是否展示出美观的追踪记录，而在于团队能否从一次失败交互出发，形成有依据的改动，并进一步审查其后果。

开放标准将比较重点转向工作流与治理

Anthropic 的导出设计为这项公告提供了竞争背景。Claude 活动可以抵达多个可观测性目标平台。因此，Databricks 必须在记录抵达后的处理能力上展开竞争。

共享导出标准使调查工作流成为更有意义的比较维度。

MLflow 的 OpenTelemetry 集成文档涵盖了使用该标准进行数据接收和导出。它还支持用于描述生成式 AI 活动的共享约定。这些约定为兼容系统提供了相关信息的通用名称和结构。

这为将每个模型集成都视为独立监控项目提供了替代方案。团队可以思考模型活动如何与应用程序的其他证据整合在一起。

然而，协议兼容性并不意味着竞争产品可以互换。执行记录仍然需要有用的界面、适当的访问控制、可理解的评估方式，以及融入团队日常工作的场景。这些要求的重要性可能超过初始导出的便利性。

Langfuse、Grafana Cloud 和 PostHog 通过客户案例出现在 Anthropic 的发布材料中。它们的出现表明，团队从不同起点着手解决智能体可观测性问题。有些从 AI 评估开始，另一些则从基础设施监控或产品分析入手。

Databricks 的核心论点在于其与企业数据和治理体系的接近性。对于已经在那里分析运营信息的组织而言，智能体记录可以成为熟悉流程中的另一类数据集。

其 Unity Catalog 存储文档表示，追踪记录访问遵循 schema 和表权限。拥有这些表访问权限的用户可以查看关联实验中的追踪记录。该细节值得在访问权限审查中重点关注。

文档还支持通过 SQL 查询存储记录；SQL 是一种用于检索和分析结构化数据的语言。这为数据团队提供了另一条途径，可将智能体活动与已管理的信息一并分析。

其分析价值显而易见。产品团队可能希望将某种失败模式与特定工作流或应用程序发布版本关联起来。更棘手的组织问题在于，相关元数据是否得到一致记录和理解。

开放格式本身无法带来这种规范。团队仍需要有意义的标识符、清晰的责任归属，以及对哪些比较有效达成共识。否则，更大规模的记录集合也可能重现分散日志带来的混乱。

传输灵活性与组织可移植性之间也存在差别。在兼容系统之间移动 span 是一个问题；重建审查习惯、评估标准和治理安排则是另一个问题。

这限制了关于摆脱供应商依赖的宽泛主张。开放协议降低了一项特定的集成障碍。买方仍应审视其调查流程在多大程度上依赖平台特有功能。

竞争层面的结论更务实，而非戏剧化。Claude 原生导出降低了仅凭专有采集能力的重要性。更有力的比较在于，每个目标平台如何有效帮助用户形成并验证开发决策。

Beta 状态和不完整记录限制了追踪能够证明的内容

最重要的保留意见在于：收集证据与证明改进之间仍有距离。该公告记录了功能与案例，但未提供独立研究来说明 Databricks 集成如何改变智能体可靠性。

追踪记录可以支持调查；但不能证明调查已经完成。

Databricks 的文章包含一项尤其有用的披露。其反复出现问题的演示由人工编写，自动化 Issue Detection 并未针对该案例运行。因此，该图示应被理解为工作流演示。

这一披露并不会否定底层功能。它限制了该示例所能证明的内容。读者可以看到相关失败的预期呈现方式，但不应将图像视为自动检测准确性的证据。

类似的区分也适用于机器生成的诊断。对失败执行过程作出的、看似令人信服的解释，仍然只是需要评估的解释。调查人员应检查记录的证据是否支持该解释，以及其他解释是否仍然合理。

覆盖范围是另一项限制。Anthropic 区分了由其服务记录的活动与开发者应用程序内部记录的活动。一个智能体可能同时涉及两种环境，使执行过程的不同部分通过不同的埋点呈现出来。

对于买方而言，关键问题是记录是否覆盖了任务中真正重要的操作。对模型活动的详细说明，仍可能无法消除对本地工具或上游信息源的疑问。

Anthropic 的 API 追踪文档还区分了仅元数据导出与完整内容导出。元数据描述活动，但未必包含深入诊断所需的提示词、响应或工具内容。

完整内容采集会带来相应的数据管理决策。文档解释称，交付的信息将存放在所选目标平台中，并受该服务的保留和访问控制规则约束。因此，导出应当像其他敏感应用程序信息传输一样受到重视。

交付本身也不是绝对可靠的历史记录。Anthropic 说明，交付采用尽力而为的方式，并且可能出现重复 span。它还解释了丢失的 span 无法重新发送。

这一含义对于负面结论很重要。缺少某项操作，并不能自动证明智能体从未执行该操作。调查人员在得出这一结论前必须考虑覆盖范围和交付情况。

这些限制提示我们，应在调试证据与更强的保证主张之间作出有用区分。追踪可以帮助解释一次具体交互。关于完整可审计性、一致检测能力或业务成果改善的主张，则需要额外证据。

买方还应区分原生可用性与运营就绪度。支持某个目标平台，并不意味着每个团队都已就保留策略、审查者访问权限、调查责任归属或升级机制达成一致。这些决定决定了该能力是否会成为日常实践。

恰当的怀疑应当具体明确。应询问：记录了什么，遗漏了什么，如何识别问题，以及如何测试拟议的修正。这些问题既能评估承诺，也不会否定其实用价值。

关注覆盖范围、已验证的修复，以及超越演示的采用情况

未来数月中，最有参考价值的信号将涉及覆盖范围、经过验证的改进和持续使用。它们分别对应“原生导出让智能体更易运营”这一主张的不同部分。

最有力的证据，将把可见的失败与能经受代表性工作负载考验的修正联系起来。

首先，关注团队是否能够展示覆盖服务托管模型活动及其自有应用程序工具的连贯记录。当调查能够追随产生答案的操作，而不是停留在孤立片段时，它会更有价值。

这类连续性的证据会强化 Claude OpenTelemetry 可观测性的实际价值。有关记录断裂或无法解释的遗漏的报告，则会缩小团队可以依赖它的范围。

应通过真实工作流案例评估这一信号。成功导出只能确认信息已抵达目标平台。有价值的调查则表明，这些信息回答了团队此前难以解决的运营问题。

其次，关注是否出现采用稳定评估标准的修复记录。可信的说明应解释原始失败、采取的干预措施以及后续观察到的行为。它还应讨论目标症状之外的影响。

如果一个研究型智能体不再重复读取信息，却开始遗漏重要发现，那么它只是用一种缺陷换来了另一种缺陷。有价值的报告会同时审视这两种结果。这类证据将支持 Databricks 所描述的开发闭环。

独立复现会进一步强化这一主张。供应商演示可以证明预期行为，而外部案例可以揭示该工作流如何应对较少经过筛选的条件。只要各自的适用范围保持清晰，两类证据都具有价值。

第三，关注组织是否将调查和审查纳入日常运营。持续使用比首次决定启用导出更重要。团队需要有人负责审查发现，并决定何时某项变更值得发布。

具体的采用证据应描述问题如何经过这一流程。它应识别相关审查者，解释开发响应，并展示团队如何检查后续行为。

这将强化这样一种论点：MLflow 追踪分析有助于持续维护智能体。若只有一组令人印象深刻的截图而缺乏后续行动，其运营收益仍难以充分确立。

对于开发者而言，这一公告提供了重新思考何为成功智能体运行的有用契机。一个看起来正确的答案只是一项观察。对智能体工作方式作出有依据的说明，则能支持不同层次的信心。

对于企业买方而言，相应的决策关乎工作流适配性。除了原生连接能力，现有治理机制、审查者专业知识和调查习惯也应影响目标平台的选择。最好的证据是团队能够识别的、已得到解决的问题。

从一个失败会造成重要影响、且领域专家能够解释预期结果的智能体任务开始。考察 Claude OpenTelemetry 可观测性是否揭示了足够的执行过程，以区分检索问题与推理或工具问题。然后询问，拟议的修正是否改善了代表性案例，同时没有舍弃必要工作。让证据始终围绕原始任务，而非事后准备得更整洁的演示。这样做能赋予原生追踪具体目的，也使平台比较更有价值。当智能体给出一个听起来正确的答案时，团队能否解释它考虑了哪些证据、其过程在哪里失败，以及为什么下一版本值得获得更高信任？