Claude OpenTelemetry 可觀測性接入 Databricks MLflow，讓 Agent 失敗情況無所遁形

Claude OpenTelemetry 可觀測性現已原生連接至 Databricks MLflow，揭示那些看似有說服力的最終答案可能掩蓋的執行細節。OpenTelemetry 是一套用於記錄及交換應用程式活動的開放標準。這項整合為開發人員提供另一種方式，調查遺漏證據、重複工作或以不完整回應結束的 Agent。

Databricks 於 2026 年 11 月 3 日宣布支援此目的地。Anthropic 則於 10 月 14 日，以公開測試形式推出更廣泛的原生追蹤功能。兩者的分別很重要：這是 Databricks 在更廣泛匯出系統中的整合，而非獨家監察安排。

核心張力在於團隊如何評估 Agent 的表現。一個經修飾的答案展示 Agent 交付了甚麼；執行記錄則有助解釋它如何得出該結果。Langfuse、Grafana 及其他可觀測性平台早已涉足這個領域。Databricks 正將其開發及評估平台 MLflow 定位為一個可把相關證據與調查及後續測試連結起來的地方。

Claude OpenTelemetry 可觀測性新增原生 Databricks 目的地

據 Databricks 表示，開發人員可從 Anthropic 開發函式庫、Messages API 及 Claude Managed Agents，將原生 Claude 執行記錄傳送至 MLflow。API 是應用程式用來請求服務的介面。Managed Agents 是由 Anthropic 託管、負責執行任務的 Agent。

這項原生追蹤整合採用 Databricks 的資料擷取服務 Zerobus Ingest 接收記錄。其資料管治系統 Unity Catalog 會將記錄儲存在與 MLflow 實驗相關聯的資料表中。

這項改變為 Claude 活動提供直接途徑，進入既有的企業調查環境。

Trace 記錄一次執行，而 span 則代表該記錄中的個別操作。模型請求和工具活動可以呈現為獨立 span。兩者之間的關係讓調查人員可追溯回應背後的先後次序。

對開發團隊而言，這個次序改變了除錯對話的起點。團隊不必要求某人憑記憶重組一次失敗的互動，而可檢視已記錄的活動。這並不會自動確立正確診斷，但可讓診斷有具體對象可處理。

當答案看來合理時，這種分別尤其有用。明顯錯誤會立即引來調查；但即使 Agent 忽略了決定性來源，或花費不必要的精力蒐集資料，看似可信的回應仍可能不受注意。

假設一個內部研究助理正準備產品更新。其最終摘要包含準確的背景資料，但遺漏了一則近期發佈說明。單靠閱讀摘要，仍有數種可能解釋：助理可能從未找到該文件、誤解了其內容，或在撰寫答案時遺漏了該發現。

執行記錄有助區分這些可能性。每種解釋都指向不同的介入方式。若檢索步驟從未呈現相關文件，修改寫作指示的作用便很有限。

這正是此公告的營運意義。原生匯出縮短了 Agent 互動與用作調查的工具之間的距離。團隊仍須決定哪些行為算作失敗。

這項整合也清楚界定了新聞的範圍。它並非宣布新的 Claude 模型、更高的基準測試分數，或經獨立量度的可靠性提升。其即時貢獻在於蒐集及存取證據。

這比「智能有所改善」是更狹窄的主張，但它處理了 Agent 部署中的實際弱點：團隊難以持續改善那些難以檢視的行為。

Agent 負責人面對解釋看似可接受答案的壓力

直接壓力落在批准 Agent 用於實際工作流程的開發人員及產品負責人身上。他們的責任不止於答案聽來是否有用，還必須解釋遺漏的發現、浪費的工作，以及部署後才出現的失敗。

原生追蹤提高了這些決策可取得的證據標準。

示範通常呈現一段經挑選的互動；生產環境則帶來各式問題、不完整文件、變動中的工具及含糊請求。一個能妥善處理熟悉範例的 Agent，仍可能在周邊條件改變時遇到困難。

這既是管理問題，也是工程問題。產品負責人需要分辨可容忍的限制與反覆出現的缺陷。開發人員需要足夠證據來重現缺陷。領域專家則需要指出答案本應包含甚麼。

沒有共享記錄時，這些群組可能各說各話。審閱者認為答案似乎不完整；工程師看到的是一個成功請求；產品經理看到的是完成了工作流程的用戶。每項觀察都可能準確，卻仍未解決根本問題。

Claude Agent 追蹤為這類對話提供共同對象。團隊可檢視特定執行過程，並將意見連結到實際發生的事情。其價值在於令分歧變得足夠具體，從而可供調查。

Anthropic 的Agent 可觀測性發布列舉了使用不同監察平台的客戶案例。Foxglove 描述如何在 PostHog 中將 Agent 互動與產品活動一併分析。FloQast 則描述如何在 Grafana Cloud 中把模型活動與會計工作流程連結。

這些案例說明不同優先事項。機械人產品團隊希望了解協助在哪些地方不足；財務工作流程團隊則需要一份可辯護的 Agent 行為記錄。兩種需要都不止於檢查最終文字。

不過，這些仍是由 Anthropic 呈現的客戶陳述，並非對 Databricks 整合的獨立評估。它們說明了相關使用情境，卻未能證明普遍的商業成果。

對知識工作者而言，同一問題會在摘要成為另一項決策依據時出現。遺漏的限定條件可能會流入規劃文件、客戶回覆或工程討論。流暢的文字可能令這種遺漏難以察覺。

正在建立可搜尋知識庫的團隊，也面對相關問題：哪些文件支撐這個答案？Agent 營運人員同樣必須調查系統是否恰當地存取及使用這些文件。

因此，壓力是具體的。任何擴大 Agent 責任範圍的人，都需要可信的方法來檢視失敗情況並排定修正優先次序。原生匯出令這種檢視更容易展開，但並不會消除判斷 Agent 是否值得承擔更多責任所涉及的取捨。

此機制將執行證據與評估連結起來

重要的機制，是將記錄下來的行為連結至可重複的開發決策。若證據從未改變團隊調查或測試 Agent 的方式，蒐集活動的價值便有限。

當一項發現轉化為可測試的解釋時，MLflow 追蹤分析才會變得有用。

設想一個假設的研究 Agent，在產生不完整摘要前反覆開啟某份文件。這種重複存取是可見行為，但其成因仍是疑問。Agent 可能缺乏停止規則、收到不一致的工具結果，或有合理理由重新檢視變動中的資訊。

若將每次重複閱讀都視為浪費，便會把這些解釋壓縮成誤導性的捷徑。調查人員需要了解重複操作是否帶來有用證據；理想的修正方法取決於這項分別。

因此，有用的調查會將觀察到的行為與預期結果連結。團隊應能說明出了甚麼問題、為何建議的改變可處理問題，以及哪些證據會推翻該解釋。

Databricks 文件說明了透過 MLflow Issues 進行重複問題偵測。MLflow Issues 是由其編碼助理 Genie Code 驅動的測試版功能。該系統會分析記錄的活動，並將證據歸類為供調查的問題。

文件亦描述了監測器，能根據近期 traces 建立基準線，並為傳入活動的樣本評分。Scorer 是用來評估指定行為或結果的函數。

這些功能支援開發迴圈，但不應被誤解為自動保證。問題偵測器提出有用的觀察分組方式；scorer 則把定義轉化為可執行規則。兩者均不能取代檢查該定義是否符合實際任務的需要。

例如，獎勵較少工具呼叫的評估，可能鼓勵過早作答。較佳的評估應同時考慮不必要的工作和完整性，否則表面上的效率改善，可能只反映調查有所減少。

同樣道理適用於回應速度。當答案仍能滿足請求時，更快完成才有價值。若 Agent 跳過重要來源，較短的執行時間可能掩蓋品質倒退。

固定任務及評估準則，有助令比較具可解釋性。團隊可提出問題：修訂後的指示是否改善了問題行為，同時沒有削弱無關的要求？這比比較不同版本中互不相關的範例更具資訊價值。

凡正確性取決於情境，仍需要人類專業知識。領域專家可指出遺漏的例外情況，或解釋為何看似多餘的行動其實合理。這些判斷有助避免自動評估獎勵錯誤的行為。

產品層面的含意是，可觀測性與評估應屬於同一場開發對話。執行證據解釋結果；評估則測試建議的修正是否能在具代表性的任務中成立。

因此，買家相關的問題不止於平台是否展示吸引的 traces，而是團隊能否從一次失敗互動走向有理據的改變，然後檢視其後果。

開放標準令比較焦點轉向工作流程與管治

Anthropic 的匯出設計為此公告帶來競爭背景。Claude 活動可到達多個可觀測性目的地，因此 Databricks 必須就記錄抵達後會發生甚麼競爭。

共享匯出標準令調查工作流程成為更有意義的比較點。

MLflow 的 OpenTelemetry 整合 文件說明如何使用該標準進行資料擷取及匯出。它亦支援用於描述生成式 AI 活動的共用慣例。這些慣例為相容系統提供相關資訊的通用名稱及結構。

這提供另一種選擇，不必將每項模型整合視為獨立的監察項目。團隊可以思考模型活動如何與其餘應用程式證據並列。

然而，協定相容性並不代表競爭產品可以互換使用。執行紀錄仍需要實用的介面、合適的存取控制、易於理解的評估，以及融入團隊日常工作的方式。這些要求的重要性，可能超過初次匯出的便利程度。

Langfuse、Grafana Cloud 及 PostHog 均透過客戶案例出現在 Anthropic 的發布材料中。它們的出現顯示，團隊從不同起點處理代理可觀測性。有些先從 AI 評估開始，另一些則從基礎設施監察或產品分析入手。

Databricks 的特定論點在於其與企業資料及管治的接近性。對已在其中研究營運資訊的機構而言，代理紀錄可成為熟悉流程中的另一個資料集。

其 Unity Catalog 儲存 文件指出，追蹤存取權會遵循 schema 與資料表權限。可存取這些資料表的使用者，可檢視相關實驗中的追蹤紀錄。此細節值得在存取權審查時留意。

文件亦支援透過 SQL 查詢已儲存的紀錄；SQL 是用於擷取及分析結構化資料的語言。這讓資料團隊可透過另一種途徑，連同已管理的資訊一併檢視代理活動。

其分析吸引力顯而易見。產品團隊或會希望將故障模式與特定工作流程或應用程式版本連結起來。較困難的組織問題是，相關中繼資料是否有一致地被記錄及理解。

開放格式本身無法提供這種紀律。團隊仍需要具意義的識別碼、清晰的責任歸屬，以及對哪些比較有效達成共識。否則，規模更大的紀錄集合只會重現零散日誌所造成的混亂。

傳輸彈性與組織可攜性之間亦有差異。在相容系統之間移動 spans 是一回事；重建審查習慣、評估準則及管治安排則是另一回事。

這限制了對擺脫供應商依賴的廣泛說法。開放協定減少了一項特定整合障礙。買方仍應檢視其調查流程有多大程度依賴平台專屬功能。

競爭層面的結論務實而非戲劇化。原生 Claude 匯出降低了專有收集本身的重要性。更有力的比較在於，各個目的地如何有效協助使用者作出並驗證開發決策。

Beta 狀態及不完整紀錄限制追蹤可證明的內容

最重要的保留在於，收集證據與證實改進之間仍有距離。公告記錄了功能及範例，但沒有提供獨立研究證明 Databricks 整合如何改變代理的可靠性。

追蹤可支持調查；但不能證明調查已經完成。

Databricks 的文章包含一項特別有用的披露。其重複出現問題的示範由人手編寫，而自動化 Issue Detection 並未在該範例中運行。因此，這個示例應被理解為工作流程示範。

這項披露並不會令底層功能失效，但限制了該範例能證明的內容。讀者可看見相關故障的預期呈現方式，而不應將圖像視為自動偵測準確度的證據。

相近的區別亦適用於機器生成的診斷。對失敗執行作出看似令人信服的解釋，仍然只是一項需要評估的解釋。調查人員應檢查已記錄的證據是否支持該解釋，以及其他解釋是否仍然合理。

覆蓋範圍是另一項限制。Anthropic 區分由其服務記錄的活動，以及在開發者應用程式內記錄的活動。一個代理可同時涉及兩種環境，令執行過程的不同部分透過不同儀表化方式可見。

對買方而言，相關問題是紀錄是否涵蓋任務所重視的操作。對模型活動的詳細描述，仍可能令本地工具或上游資訊來源留下不確定性。

Anthropic 的 API 追蹤文件 亦區分僅中繼資料匯出與完整內容匯出。中繼資料描述活動，但未必包括進行深入診斷所需的提示、回應或工具內容。

完整內容收集會帶來相應的資料管理決策。文件說明，已傳送的資訊會存放於所選目的地，並受該服務的保留及存取控制規範。因此，匯出值得獲得與其他敏感應用程式資訊傳輸同等的重視。

傳送本身並非絕對可靠的歷史紀錄。Anthropic 文件說明採用盡力而為的傳送方式，並可能出現重複 spans。文件亦指出，遺失的 spans 無法重新傳送。

這對負面發現有重要含意。某項操作缺失，並不會自動證明代理從未執行該操作。調查人員在作出此結論前，必須考慮覆蓋範圍及傳送情況。

這些限制顯示，除錯證據與更強的保證主張之間可作有用區分。追蹤可協助解釋特定互動；但對完整可稽核性、一致偵測或改善業務成果的主張，則需要額外證據。

買方亦應將原生可用性與營運準備程度分開看待。支援某個目的地，並不表示每個團隊已就保留期限、審查者存取權、調查責任或升級處理達成共識。這些決定將影響該功能是否能成為日常實踐。

合適的懷疑應具體而明確。詢問記錄了甚麼、遺漏了甚麼、如何識別問題，以及如何測試建議的修正。這些問題可評估其承諾，而不否定實際價值。

關注覆蓋範圍、已驗證的修正，以及超越示範的採用情況

未來數月最具參考價值的訊號，將涉及覆蓋範圍、已驗證的改進及持續使用。每項訊號均針對「原生匯出讓代理更易營運」這一主張的不同部分。

最有力的證據，會把可見的故障與能在具代表性的工作負載下持續有效的修正連結起來。

首先，觀察團隊是否展示涵蓋服務託管模型活動及其自身應用程式工具的一致紀錄。當調查可追溯產生答案的操作，而非孤立片段時，會更有用。

這種連貫性的證據將強化 Claude OpenTelemetry 可觀測性的實際價值。若出現紀錄中斷或無法解釋的遺漏報告，則會縮窄團隊可依賴它的範圍。

此訊號應透過真實工作流程案例評估。成功匯出只證實資訊已抵達目的地；有用的調查則顯示，該資訊回答了團隊此前難以解決的營運問題。

其次，留意是否有具穩定評估準則的修正文件。可信的說明應解釋原始故障、介入措施及其後觀察到的行為，亦應處理目標症狀以外的後果。

一個研究代理若不再重複讀取，卻開始遺漏重要發現，便是以一項缺陷交換另一項缺陷。有用的報告會檢視兩種結果。這類證據將支持 Databricks 所描述的開發迴圈。

獨立重現會進一步強化主張。供應商示範可證明預期行為，而外部案例則可揭示工作流程如何應對較少經整理的情況。只要其範圍保持清晰，兩種證據形式皆有價值。

第三，觀察機構是否把調查及審查納入日常營運。持續使用比最初決定啟用匯出更重要。團隊需要有人負責審查發現，並決定何時某項變更值得發布。

具體採用證據會描述問題如何經過該流程處理，識別相關審查者、解釋開發回應，並展示團隊如何檢查後續行為。

這將強化 MLflow 追蹤分析有助持續維護代理的論點。若只有一系列令人印象深刻的截圖而沒有後續行動，營運效益便較難確立。

對開發者而言，公告提供一個有用時機，重新思考何謂成功的代理運行。看起來正確的答案是一項觀察；對代理如何運作作出有理據的說明，則支持另一層次的信心。

對企業買方而言，相應決策關乎工作流程契合度。現有管治、審查者專業知識及調查習慣，應與原生連接能力一同影響目的地選擇。最好的證據，是你的團隊所熟悉且已解決的問題。

從一項故障影響重大、而領域專家能說明預期結果的代理任務開始。檢視 Claude OpenTelemetry 可觀測性是否足以揭示執行過程，以區分擷取問題、推理問題或工具問題。然後詢問建議的修正能否改善具代表性的案例，同時不捨棄必要工作。證據應與原始任務保持連結，而非依賴其後準備得更整潔的示範。這種做法會為原生追蹤賦予具體目的，亦令平台比較更有用。當代理產生一個聽起來正確的答案時，你的團隊能否解釋它考慮過哪些證據、其流程在哪裡失敗，以及為何下一個版本值得獲得更高信任？