背景
OpenTelemetry（開放遙測標準，用於收集與匯出服務訊號的開放標準）是 MLflow Tracing 的基礎，能將代理（Agent）的執行過程記錄為稱為 spans（跨度，指模型請求或工具呼叫等單一執行步驟）的個別步驟。當 AI 代理給出看似合理但遺漏關鍵資訊或重複讀取來源的答案時，僅看最終回覆無法解釋原因，而追蹤資料能顯示背後的模型與工具呼叫，協助開發者調查失敗原因並測試改進效果。 Databricks Blog
發生什麼事
Databricks 宣布 Claude Platform 對 OpenTelemetry 的原生支援現已進入 Public Beta（公開測試版）。透過原生 OTel 匯出功能，使用 Anthropic SDKs、Messages API 以及 Claude Managed Agents 的開發者，現在可以將原生追蹤資料直接傳送至 Databricks MLflow。 Databricks Blog
重點內容
Databricks 透過 Zerobus Ingest 接收 spans，並將其儲存在連結至 MLflow 實驗的 Unity Catalog 資料表中。Unity Catalog 負責控制資料存取權限，使用者也可透過 SQL 查詢這些資料。這種結合 Zerobus 與 Unity Catalog 的方式，讓企業能在高 QPS（每秒查詢請求數）下實現低延遲的追蹤資料匯入，同時治理儲存在代理追蹤中的敏感資料。 Databricks Blog
整合過程主要分為三個步驟：首先在 Databricks 建立實驗並選擇 Unity Catalog 作為追蹤儲存位置；接著設定原生匯出，需使用工作區 ID、區域與 spans 資料表，並取得表格範圍的 OAuth token（OAuth 存取權杖，用於驗證存取權限）；最後執行任務並檢查追蹤。輸入與輸出內容僅在使用者將 content mode（內容模式）設定為「full」時才會被捕捉。 原文
在 MLflow 中，開發者可使用「Analyze trace」動作結合 Genie Code 來調查異常答案，例如檢查遺漏的上下文或失敗的工具呼叫。此外，Beta 版的 MLflow Issues 功能利用 Genie Code 識別跨追蹤與工作階段的重複性問題，如浪費 token 的重複搜尋或導致工具失敗的遺漏參數，並可排程偵測以持續監控新進來的追蹤資料。 原文
對使用者的意義
開發者可以利用 MLflow Review Queues 邀請領域專家審查選定的追蹤資料，專家可提供預期答案以協助精煉代理並建立參考標準。透過 MLflow Agent Evaluation，開發者能針對相同的測試案例執行評估，比較修改提示、技能或工具前後的效果，並使用相同的判斷標準（judges）來衡量改進情況，確保變更不會引入新的回歸問題。 Databricks Blog
限制與未定事項
OpenTelemetry for Claude Platform 目前處於 Public Beta 階段。MLflow Issues 功能亦標示為 Beta 版。此外，官方文件指出，用於連結 Claude 至 Databricks MLflow 的專用整合指南 URL 在發布前仍需補充。 Databricks Blog
