为任何智能体、任何地点提供可观测性：基于 Databricks 的 OpenTelemetry 与 Unity Catalog 实现生产级追踪

随着 AI 应用进入生产环境，追踪（Tracing）成为理解智能体行为的关键手段，它能够捕获提示词、工具调用、响应、延迟和执行路径。然而，传统的可观测性工具在处理 AI 智能体产生的海量追踪数据时面临成本高昂、难以治理和分析灵活性不足的问题。

Databricks 现在通过支持将 OpenTelemetry（OTel）追踪直接写入 Unity Catalog 表来解决这一难题。该方案基于完全托管、无服务器的 Zerobus Ingest 引擎，能够以原生格式摄取 OTel 数据，并将其存储为 Delta 表。这意味着追踪数据可以像其他任何数据集一样，享受 Lakehouse 的可扩展性、治理能力和工具生态。

为什么 AI 追踪打破传统可观测性

AI 追踪数据不仅用于调试，还广泛用于评估、分析和监控。团队希望长期保留这些数据，用 SQL 进行分析，与业务和模型数据关联，并用于评估和监控。然而，当追踪数据仅存在于可观测性系统中时，灵活性受限，治理碎片化，将数据迁移到分析工作流需要额外的管道和复制，尤其是在涉及敏感提示词数据时。

架构：无服务器 OpenTelemetry 摄取

Databricks 的解决方案摒弃了传统的多跳遥测管道，通过 Zerobus Ingest 提供单跳摄入。任何支持 OTel 的客户端（包括流行的 AI 智能体框架）都可以通过 gRPC 或 REST API 将追踪、日志和指标直接发送到 Unity Catalog 表。这种“单接收端”架构消除了对 Kafka 等中间消息总线的需求，降低了运维复杂度。

教程：将追踪接入 Lakehouse

为了演示端到端的追踪，本文使用了一个基于 LangGraph 构建的“支持经理助理”智能体。该智能体调用 Databricks 托管的 Claude Sonnet 模型进行推理，并通过 MCP 工具 API 调用 Genie 空间来查询支持数据集。通过 MLflow 配置 OpenTelemetry 表后，智能体的每次调用都被自动追踪，包括模型调用和工具调用。

在 MLflow 实验中，用户可以观察到智能体的完整执行路径，例如它为回答“我应该推荐哪位支持工程师晋升”而三次调用 Genie 空间来收集数据。追踪数据以 Delta 表的形式存储，支持 SQL 查询，例如通过 mlflow_experiment_trace_unified 视图查看请求、响应和跨度详情。

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

追踪数据存储在 Unity Catalog 后，立即可用于批处理和流分析。Unity Catalog 的细粒度访问控制确保了敏感提示词数据的安全性，同时允许团队使用 SQL 构建仪表盘、ETL 流水线和自定义分析。

MLflow 实验 UI 提供了原生可观测性仪表盘，包括追踪量、错误、延迟、令牌使用量和成本。此外，由于追踪表只是 Delta 表，用户可以使用 AI/BI 仪表盘构建自定义视图，例如嵌入合同定价的实际成本分析，以及组件级性能监控（如单个工具的 P50/P99 延迟和错误率）。

通过将生产追踪数据与分析工作流统一，团队可以建立持续改进的飞轮：生产行为驱动评估和分析，进而加速迭代并提升智能体性能。