任意 Agent、任意位置的可观测性：基于 OpenTelemetry 与 Unity Catalog 的生产级追踪方案

为何 AI 追踪颠覆了传统可观测性

随着人工智能应用逐步投入生产环境，追踪（traces）已成为理解智能体（agents）实际行为的最直观方式之一——通过记录提示词（prompts）、工具调用（tool calls）、响应内容、延迟（latency）及执行路径等关键信息。缺乏强有力的追踪能力，将难以深入理解智能体的行为逻辑，从而显著增加调试、评估与治理的难度。

AI 追踪数据的价值远超传统调试与可观测性范畴，已广泛应用于分析、评估与监控工作流。团队希望长期保存这些数据，使用 SQL 进行分析，将其与业务数据及模型数据进行关联，并复用于评估与监控场景。然而，若追踪数据仅局限于可观测性系统内部，则灵活性受限、治理分散，且将数据迁移至分析工作流时往往需额外构建数据管道并造成重复存储——尤其当涉及敏感提示词数据时，问题更为突出。

OTel 追踪数据接入

Databricks 现已支持以 OpenTelemetry（OTel）标准格式将追踪数据直接写入 Unity Catalog。实践中，这意味着追踪数据可实时接入并存储于 Delta 表中，从而继承与企业其余数据相同的可扩展性、治理能力及工具链支持。

这一能力彻底改变了团队使用追踪数据的方式：

• 实时接入与灵活保留策略：追踪数据可在生成时即以高吞吐量写入，并支持长期保留，摆脱了传统可观测性平台因存储成本带来的限制。
• 基于湖仓一体（Lakehouse）进行分析与治理：一旦追踪数据进入表结构，即可像其他数据集一样处理：通过 SQL 查询、构建仪表盘、运行 ETL 流水线、使用 Genie 等工具，并应用 PII（个人身份信息）脱敏等治理策略。
• 全面启用 MLflow 评估体系：MLflow 可便捷地对追踪数据进行搜索、过滤与下钻分析，助力调试。将追踪数据持久化至 Unity Catalog 后，可解除传统实验中的限制（如追踪条目上限），更轻松地开展大规模离线评估、监控生产系统，并在负载增长过程中持续优化系统质量。

SaaS 方案 vs. 湖仓一体（Lakehouse）

既然已有成熟的 SaaS 可观测性工具，为何还需转向湖仓一体架构？

1. 保留成本优势：智能体通常生成大量文本负载。将数据存储于基于对象存储的 Delta Lake 中，其成本通常远低于 SaaS 平台的保留模式。
2. 规避 PII 风险僵局：将原始提示词发送至第三方平台可能引发信息安全（InfoSec）阻力。将追踪数据保留在 Unity Catalog 内，有助于保障数据主权并简化合规治理。
3. 不止于遥测，更重分析：SaaS 工具虽擅长处理延迟等运维指标，但湖仓一体提供了强大的分析引擎。您可将追踪数据与业务数据（如收入、转化率）关联，深入洞察真实业务影响，超越系统健康度监控的范畴。此外，湖仓一体还支持直接对追踪数据应用 AI 技术，并构建评估框架，持续提升系统质量。

架构：无服务器 OpenTelemetry 数据接入

Databricks 现已支持将 OpenTelemetry（OTel）追踪、日志与指标数据直接写入 Unity Catalog 表中，通过 OTel 标准实现观测 instrumentation 与存储的解耦。

Databricks 通过提供托管式接入层，消除了传统多跳遥测管道的运维复杂性——该接入层由 Zerobus Ingest 无感驱动。Zerobus Ingest 是一个完全托管的无服务器接入引擎，原生支持标准 OTel 协议（OTLP），可通过 gRPC 与开源采集器（collector）对接；其 REST API 则无缝集成 MLflow 等应用框架。应用程序可轻松将 span、日志与指标直接导出至 Unity Catalog 表中，并以 Delta 格式存储。借助“单接入点（single-sink）”架构，Zerobus Ingest 将数据流直送湖仓，大幅简化可观测性体系。现有兼容 OLTP 的采集器可通过 gRPC 直接指向该端点，完全绕过 Kafka 等中间消息总线。Zerobus Ingest 作为高吞吐遥测管道，以零基础设施开销完成数据接入与持久化。任何兼容 OTel 的客户端（包括多种编程语言下的主流 AI 智能体框架）均可向该端点导出追踪数据。

自此，追踪、日志与指标成为湖仓中的第一类数据，支撑即席 SQL 分析、仪表盘、下游分析及 MLflow 的评估与监控工作流。统一遥测体系构建起持续改进的正向飞轮：生产环境行为驱动评估与分析，而分析结果又反哺更快迭代与更优智能体性能。

教程：将追踪数据接入湖仓

示例智能体：客服经理助手

本文将构建一个简易的客服经理助手，用于端到端演示追踪功能。该智能体可部署于 Databricks 外部（如本文所示），凸显追踪数据接入与智能体运行环境的解耦特性。

我们构建了一个由 Databricks 托管的 Claude Sonnet 4.6 模型驱动的 LangGraph Agent，用于推理与响应生成。该 Agent 调用 Genie Space 作为工具，您可参考此处部署 Genie Space。

当用户提出一个数据驱动的问题时，Agent 会通过 MCP 工具 API 调用 Genie。Genie 将请求翻译为 SQL 查询，在支持数据集上执行该查询，并返回结果。随后，Agent 对结果进行汇总，并为支持经理提供可操作的结论。

使用 Unity Catalog 配置 OTel 追踪

在对 Agent 进行观测（instrumentation）之前，我们首先配置 Unity Catalog 中用于存储 OpenTelemetry 追踪数据的表。在本示例中，我们使用 MLflow 在 Unity Catalog 中创建底层的 OpenTelemetry 表，并将其与一个 MLflow 实验关联，以便可通过 UI 对追踪数据进行搜索、分析与标注。首先，请确定（或创建）一个 SQL Warehouse 和一个 MLflow 实验，然后使用 MLflow Python 库来创建 Unity Catalog 表，并将该 schema 与实验关联。完整步骤请参考此处文档。

该配置会为 OpenTelemetry 的 spans（跨度）、logs（日志）和 metrics（指标）创建 Unity Catalog 表。底层数据以符合 OpenTelemetry 标准的表格式存储，同时 MLflow 服务会自动创建对应的 Databricks SQL 视图，将 OpenTelemetry 数据转换为更便于查询与分析的 MLflow 友好格式。这些视图包括：

• <table_prefix>_otel_spans：每个请求的详细跨度级执行数据
• <table_prefix>_otel_logs：执行过程中捕获的结构化日志/事件数据
• <table_prefix>_otel_metrics：执行过程中捕获的数值型遥测数据
• <table_prefix>_otel_annotations：MLflow 特有的追踪数据（非标准 OTel 信号），包括元数据、标签、评估/反馈、预期结果及运行链接
• <table_prefix>_trace_unified：统一视图，将每个追踪记录整合为单条记录，包含原始跨度数据与追踪元数据
• <table_prefix>_trace_metadata：按追踪 ID 分组的 MLflow 标签、元数据与评估；当仅需 MLflow 追踪元数据时，其性能优于统一视图

完成实验配置后，Agent 的观测方式保持不变。任何兼容 OTel 的观测库均可将追踪数据导出至已配置的端点。您可采用自动或手动方式实现追踪，具体方法请参见此处文档。在本示例中，我们使用 mlflow.langchain.autolog() 捕获详细的 LangGraph 执行过程（包括模型调用与工具调用）。同时，我们通过 @MLflow.trace 装饰器包装入口函数，以建立请求级别的根跨度（root span），使每次调用均可作为端到端的单一执行过程进行观测。

查看示例追踪数据

在 Agent 完成观测配置且追踪数据开始流入 Unity Catalog 后，我们来看一个实际执行示例。

本例中，我们向“支持经理助手”提出以下问题：

“我该推荐哪位支持工程师晋升？”

该 Agent 对请求进行评估，多次调用 Genie Space 以收集支持性数据，并基于性能指标返回推荐结果。

尽管响应内容看似简洁，但追踪数据揭示了生成该结果的底层执行路径。在 MLflow 实验中，我们可以看到每一次工具调用以及 Claude Sonnet 模型的推理逻辑。可见其共调用了 Genie Space 工具三次，最终整合生成答案。

我们可逐个点击各步骤，深入研究其输入与输出。

由于追踪数据以 Delta 表形式存储，可像其他数据集一样进行 SQL 查询。我们可从 mlflow_experiment_trace_unified 视图入手，找到一条记录，其中包含请求内容、响应内容、追踪元数据以及跨度数组。

超越调试：追踪数据的分析应用

当追踪数据存储于 Unity Catalog 后，即可立即支持批处理与流式分析。

Unity Catalog 中的数据治理

然而，提示（prompts）与响应内容往往包含敏感信息，因此将追踪数据视为受治理数据至关重要。通过将其存储于 Unity Catalog 中，追踪数据可继承细粒度访问控制策略，包括目录与 Schema 权限、列级掩码及行级过滤，从而在保障安全的前提下，实现生产级分析，同时不牺牲灵活性。

在完成权限配置后，团队即可安全地通过 SQL 查询底层表与视图，开展即席分析（如上文所示）。此外，我们还可构建 ETL 流水线，并结合仪表板与 Genie Space，生成可驱动业务决策的洞察。

仪表板

MLflow 实验 UI 现已内置 Unity Catalog 中对追踪（traces）的原生可观测性仪表板，涵盖追踪量、错误率、延迟、Token 使用量及成本等视图。对大多数团队而言，这些功能已足以日常监控智能体（agent）的健康状态。

当您需要超越原生可视化图表的更深入视图时，追踪表（trace tables）本质上仍是 Unity Catalog 中的 Delta 表。您可以基于这些表构建自定义的 AI/BI 仪表板，并借助 AI 辅助编写标准 SQL，灵活建模您团队关注的各类指标。

为展示自定义仪表板相较于原生视图所能增强的能力，我们基于追踪表构建了一个 AI 运营中心（AI Operations Center）。以下列举其中两项值得重点关注的功能：

基于合同定价的自定义成本分析

原生成本指标依赖于标准公开报价，而对已签订优惠合同或使用微调模型（其定价不同）的团队而言，这些数据可能存在偏差。由于我们完全掌控 SQL 查询逻辑，因此可将自身定价规则直接嵌入查询语句中。该仪表板按模型类型（例如 GPT 5.5 与 Claude 4.6 Sonnet）追踪 Token 使用量，并应用我们的合同费率，生成反映实际支出的“单次追踪估算成本”。这使得识别高成本异常值变得非常容易——例如，某次因检索循环导致的复杂查询耗资 $0.50。

组件级性能分析

原生延迟视图仅提供追踪级别的 P50/P99 指标。为更进一步，深入查看具体是哪个工具拖慢了整体性能，我们构建了一个 工具性能（Tool Performance） 组件，按智能体中各独立工具（例如 retrieve_docs 与 generate_response）分别展示延迟（P50、P99）及错误率。这使我们能精准定位瓶颈所在——是 LLM 响应慢、Genie 工具调用延迟，还是其他步骤造成延迟，从而明确用户体感下降的具体环节。

Genie 空间

业务与技术相关方往往希望在不编写 SQL 的前提下探索智能体行为。通过 Genie 公开追踪表，团队可实现对遥测数据的自然语言分析，使用户能直接就性能、工具使用、延迟及模型行为等维度提出问题。例如：

• 哪类请求需要升级处理？
• 工具重试频率是否在上升？
• 哪些查询触发了最复杂的执行路径？

ETL 管道

由于追踪数据以 Delta 表形式存储，可像其他数据集一样接入下游 ETL 管道。通过启用 变更数据馈送（CDF），团队可对追踪数据进行增量处理（支持批处理或流处理），避免重复扫描整张表。

这使得可观测性真正具备可操作性。例如，管道可监控追踪模式，并在延迟超出预设阈值、工具失败率激增或 Token 使用量显著偏离基线时触发告警。这些信号可进一步驱动仪表板更新、通知系统推送，或触发自动化修复工作流。

重要的是，这与实时防护机制（如 AI 防护栏）形成互补：防护栏在请求阶段强制执行策略，而 ETL 管道则构建反馈闭环，助力团队分析趋势、优化策略，并持续提升智能体性能。

凝闭环：从生产追踪到评估

一旦追踪数据就绪，即可驱动完整的 MLflow 评估体系，使团队能在整个 GenAI 应用生命周期中衡量、优化并保障其质量。评估与监控均以追踪为基础，复用开发、测试及生产阶段捕获的同一套遥测数据，借助 LLM 评判器与自定义指标进行打分。

开发阶段评估

MLflow 支持对评估数据集运行评估任务，应用内置或自定义评判器对响应质量打分。一种高效实践是：从真实追踪中引导式构建评估数据集。由于这些提示（prompt）源自真实用户交互，相较纯合成测试用例，更能代表智能体需应对的实际场景。

下例中，我们从近期捕获的追踪中构建评估数据集。MLflow 使用 SQL Warehouse 搜索并物化数据集记录，请确保已在环境中配置好 Warehouse ID。

数据集就绪后，即可定义用于评分的评判器。MLflow 提供一组内置评判器，也支持根据智能体预期行为自定义评判准则。

随后，评估结果将直接呈现在 MLflow 实验中。


生产环境监控

开发阶段的评估有助于发布前验证行为正确性，而生产监控则揭示应用在真实用户场景下的表现。MLflow 可自动对线上追踪应用相同评判器，帮助团队快速识别性能回退、数据漂移及新型故障模式。这使评估从一次性任务转变为持续实践，伴随应用演进不断迭代优化。

在 Databricks 上运行 AI 可观测性的客户案例

Experian

将 Eva 虚拟助手和 Latte 自动化邮件系统迁移至 MLflow 追踪功能的过程非常顺畅。借助 Unity Catalog 中的 Traces 功能，我们的数据科学团队可在不离开 Databricks 的前提下，对数十万条追踪数据进行治理型 Delta 表处理，并大规模评估智能体（agent）质量。随着更多严肃的评估工作流逐步上线，将追踪与评估统一纳入一个受治理的平台，意味着我们无需为智能体生命周期的各个阶段分别维护独立工具。

— James Lin，Experian AI/ML 创新负责人

Superhuman（Grammarly）

在 Superhuman，我们正将 MLflow 追踪作为所有 AI 智能体的统一可观测性层。相比构建和维护自定义或点对点解决方案，我们更倾向于选择 MLflow 所提供的广泛平台集成能力——后者带来的运维负担曾是我们团队的痛点。借助 Unity Catalog 中的 MLflow Traces，我们每天可处理数十万条追踪数据；研究人员也能无需工程支持，直接在 MLflow UI 中自助式探索智能体行为。将追踪、评估与监控整合于一个受治理平台，正是我们推动智能体顺利上线生产环境所亟需的解决方案。

— Martin Jewell，Superhuman 首席 MLE（AI 基础设施负责人）

Smartsheet

我们选择 Databricks 作为 GenAI 的核心平台，而 MLflow 则是我们团队构建与评估 AI 智能体的工具。在与 Databricks 联合开展的为期三天的共建中，我们基于 MLflow 追踪、评估、自定义评判器（custom judges）及标注功能，快速上线了两个生产级智能体；得益于 Unity Catalog 中的追踪数据存储，我们可在扩展过程中自信地执行数万次评估并持续优化质量。

— Kapil Ashar，Smartsheet 工程副总裁

The Standard

The Standard 致力于帮助客户实现财务健康与安心生活，而数据与 AI 是实现规模化交付该体验的关键。通过将 AI 智能体功能（例如从承保文档和理赔提交材料中自动提取关键信息）嵌入关键业务流程，我们得以为客户及合作伙伴提供卓越服务。借助生产环境中的追踪与监控能力，我们的团队能快速理解系统行为并安全可靠地进行更新迭代。通过在 Databricks 数据智能平台中将追踪数据与其余数据一并纳入 Unity Catalog 统一治理，我们可安全地查询、监控并迭代优化，同时避免引入额外复杂性。

— Porter Orr，The Standard AI 与自动化高级副总裁

常见问题（FAQ）

Q：我能否用该方案追踪运行于 Databricks 外部的智能体？ A：可以。智能体可部署于任意位置。事实上，本文所用的支持助手智能体示例即为本地部署。

Q：该方案的吞吐量与存储上限是多少？ A：数据摄入吞吐量下限为 200 QPS（每秒查询数），存储无上限。此前关于每实验追踪数的限制已不再适用。若您需要更高吞吐能力，请联系您的 Databricks 客户经理。

Q：如何确保搜索查询、MLflow 实验体验及下游分析的性能？ A：最新产品更新中，相关表已自动采用 Liquid Clustering 技术，以保持数据组织最优。但针对大规模追踪数据，建议在派生视图之上创建物化视图（materialized view），并定期增量刷新，以维持查询性能。

Q：用户提示中若包含个人身份信息（PII），系统如何处理？ A：本功能本身不提供 PII 特殊处理机制。但数据存储于 Unity Catalog 中，您可利用其治理能力（如细粒度访问控制、列级掩码、行级过滤等），对下游访问权限进行管理与限制。

快速开始

请参考以下文档开始使用：文档链接