為任何智能體、任何地點提供可觀測性：基於 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 延遲和錯誤率）。

通過將生產追蹤數據與分析工作流統一，團隊可以建立持續改進的飛輪：生產行為驅動評估和分析，進而加速迭代並提升智能體性能。