IBM 與加州大學柏克萊分校利用 IT-Bench 和 MAST 診斷企業級代理（Agents）失敗的原因

IBM 與加州大學柏克萊分校利用 IT-Bench 和 MAST 診斷企業級代理失敗的原因

ITBench HF Space
ITBench HF Dataset
MAST HF Dataset
ITBench Github
MAST Github

IBM 研究院與加州大學柏克萊分校合作研究了代理式 LLM 系統在現實 IT 自動化中如何崩潰，這些任務涉及事件分類、日誌/指標查詢，以及長跨度工具循環中的 Kubernetes 操作。

基準測試通常將性能簡化為單一數字，告訴你代理是否失敗，但從不解釋原因。為了縮小這個黑盒問題，我們應用了 MAST（多代理系統失敗分類法），這是一種用於診斷代理可靠性的新興實踐。透過利用 MAST 分析 ITBench（SRE、安全和 FinOps 自動化的行業基準），我們將原始執行軌跡轉化為結構化的失敗特徵，揭示了具體哪裡出錯以及如何修復。我們對三種不同模型類別的 310 個 ITBench SRE 軌跡進行了標註：Gemini-3-Flash、Kimi-K2 和 GPT-OSS-120B。

關鍵發現：

構建代理時的分析心得：

如果您正在為企業 IT 工作流構建代理，這就是您需要的評估方式：不僅僅是「它通過了嗎？」，而是「什麼地方壞了、在哪裡壞的，以及哪種干預手段最具槓桿作用？」

代理基準測試的「黑盒」問題

像 ITBench 這樣的基準測試正成為衡量高風險 IT 自動化任務中代理性能的標準。在 ITBench 中，代理扮演網站可靠性工程師 (SRE) 或安全分析師的角色，負責診斷 Kubernetes 停機、修補漏洞或管理生產環境中的雲端成本。

這些基準測試使用成功率作為評估代理的主要指標。然而，對於工程化魯棒系統來說，這個指標是不夠的。知道一個代理系統在 ITBench 上達到 14% 的成功率只能告訴我們它失敗了，但不能告訴我們原因：是因為它忘記了上下文？是因為它幻覺了一個指令？還是因為它根本沒有終止？

如果沒有全面的診斷方法，開發者只能靠猜測，通常訴諸於盲目的提示詞（prompt）微調，解決了一個問題卻產生了另一個問題。

作為分析複雜代理系統失敗模式的新標準，我們開發了 MAST（多代理系統失敗分類法）。MAST 帶來了更多洞察，並揭開了這些基準測試不透明的評估過程。MAST 源於對七個不同框架中超過 1,600 個軌跡的嚴格分析，為代理失敗提供了標準化的分類法。

MAST 根據三個關鍵類別中的 14 種不同模式，將非結構化的執行日誌轉換為結構化的「失敗向量」：

實驗：診斷 ITBench 代理

我們通過將 MAST 應用於 ITBench（一個涵蓋 SRE、安全/合規和 FinOps 的熱門 IT 自動化評估套件），來壓力測試使用 MAST 使代理評估具備可操作性並獲取失敗模式洞察的想法。

我們標註了 310 個由基於 Codex 構建的 SRE 代理在現實環境中產生的 ITBench SRE 執行軌跡。這些軌跡捕捉了代理與其工具之間在三種代表不同能力梯隊的模型（Gemini-3-Flash、Kimi-K2 和 GPT-OSS-120B）下的自然語言交互。這讓我們能夠超越簡單的成功指標，調查驅動這些結果的獨特失敗特徵。為此我們使用了召回率分數，因為模型設計上最多只輸出 3-5 個結果，且 SRE 相比 F-1 分數更偏好召回率分數。

以下我們詳細說明診斷分析的發現。

發現 1：強大的模型（如 Gemini-3-Flash）在每個軌跡中表現出精確的（孤立的失敗模式），而開源的 Kimi-K2 和 GPT-oss-120b 則表現出複合失敗模式

當我們檢查失敗的軌跡時，三種模型之間呈現出明顯的複雜度等級。這是通過每次失敗運行中觀察到的不同失敗模式數量來衡量的。

失敗模式密度的這種差異揭示了這些系統崩潰方式的根本區別。Gemini-3-Flash 表現出精確的失敗特徵。即使在不成功的運行中，它也保持了高度的內部連貫性，通常是因為單個孤立的失敗（例如錯誤的驗證步驟）而失敗。這些失敗是精確的，且更容易診斷。

在光譜的另一端，GPT-OSS-120B 遭受著連鎖式崩潰。在這些軌跡中，我們觀察到錯誤往往會隨時間複合。過程早期的一個微小推理失配通常會導致偏離任務規範，進而引發代理的全面失控。Kimi-K2 則處於中間地帶，其失敗比前沿模型更頻繁且複雜，但尚未達到 120B 開源權重模型那樣的系統性不穩定。

這一發現的意義在於，較高的成功率通常伴隨著孤立的失敗。同時發生的問題較少的系統更具可預測性，且更容易通過有針對性的工程干預來改進。

發現 2：「非致命」與「致命」失敗

MAST 最關鍵的洞察或許是區分系統可以容忍的失敗與對下游任務成功致命的失敗。通過比較成功軌跡與失敗軌跡中的失敗模式分佈，我們可以將其分為三類。

「非致命」（良性）缺陷

在所有三種模型中，某些失敗模式即使在最終成功的運行中也頻繁出現。這些通常是結構性摩擦而非終端錯誤。

這種區分正是 MAST 價值所在。它讓我們能夠忽略像故障排除中經常出現的重複（repetition）這類良性失敗，而專注於導致運行失敗的致命錯誤。

「致命」缺陷

某些行為強烈地將成功與失敗區分開來。當這些模式出現時，成功結果的概率會急劇下降。最顯著的例子是 FM-3.3（錯誤驗證）。與成功軌跡相比，該模式在失敗的 Gemini-3-Flash 軌跡中增加了 52%。其他顯著的失敗模式包括 1.5（未意識到終止條件）和 2.6（推理與行動失配）。

如果這些情況發生，運行很可能就失敗了；這引導從業者在系統中的代理之間以及多輪交互中開發魯棒的上下文管理策略。

個案研究：Gemini-3-Flash（果斷但過度自信）

Gemini-3-Flash 非常高效，但其主要瓶頸是傾向於在沒有嚴格證明的情況下假設成功。其失敗特徵主要由驗證錯誤的巨大差異主導。它經常識別出正確的信號，但在根據事實真相進行交叉引用之前就終止了。為了修復這個問題，開發者應該實施外部驗證門。通過在允許代理退出之前要求提供基於工具的證據（如已清除的警報或健康的指標閾值），我們可以減輕該模型固有的過度自信。

個案研究：Kimi-K2（終止危機）

雖然終止混淆（FM-3.1 和 FM-1.5）是 Kimi-K2 普遍的失敗模式，但其失敗軌跡的特徵是普遍存在的行動-推理失配（FM-2.6），這出現在驚人的 92% 失敗案例中。

Kimi-K2 是「過度思考」模型的一個典型例子，其推理鏈通常太長，但在執行時可能會失敗。

個案研究：GPT-OSS-120B

GPT-OSS-120B 表現出該群體中最不穩定的失敗特徵。該模型在每個失敗軌跡中平均表現出 5.3 個不同的失敗模式，表明其根本無法維持內部狀態。

解讀圖表的另一種（且更有用的）方式：「致命」與「非致命」

總結來說，MAST 讓你將失敗模式分為兩個桶：

可恢復 / 結構性（即使在成功軌跡中也會出現）

這些失敗不是致命的，系統可以從中恢復並成功完成任務。

致命 / 決定性（與失敗軌跡強烈相關）

這些是系統通常無法從中恢復的失敗。

這就是「更豐富的理解」所在：兩個模型在小部分樣本上可能具有相同的成功率，但失敗的原因卻完全不同——需要不同的修復方案。

結論

MAST 是一個檢查代理系統軌跡的工具，用於識別細粒度的失敗類型，以支持系統開發和調試。在本部落格中，我們展示了通過將 MAST 應用於 ITBench，我們從通用的觀察（「開源模型表現不佳」）轉向具體的工程路線圖，幫助提高依賴這些模型的代理系統的性能，例如：

社群

·
註冊或
登入以發表評論