IBM 與加州大學柏克萊分校使用 IT-Bench 與 MAST 診斷企業代理失敗

IBM 研究院與加州大學柏克萊分校開發了一種方法，透過結合 IT-Bench——針對 SRE、資安與 FinOps 自動化的基準——以及 MAST（多代理系統失敗分類法），超越僅以成功率評估代理式 LLM 的簡單方式。此方法讓開發者能夠辨識具體的失敗特徵，區分良性的結構摩擦與導致任務崩潰的致命錯誤。

代理基準的「黑盒」問題

傳統基準通常只報告單一成功率，無法說明為何代理失敗。為了解決此問題，研究人員引入了 MAST，一套標準化的分類法，將非結構化的執行日誌轉換為跨 14 種不同模式的結構化「失敗向量」。這些模式被分為三大類別：

FC1：系統設計問題（骨架）： 架構失敗，例如 FM-1.3 步驟重複（迴圈）、FM-1.4 失去對話歷史（記憶體洩漏）以及 FM-1.5 未察覺終止。
FC2：代理間不對齊（溝通）： 執行時的溝通失敗，包括 FM-2.2 未提出澄清請求 與 FM-2.3 任務脫軌。
FC3：任務驗證（品質管控）： 輸出品質失敗，例如 FM-3.1 過早終止 與 FM-3.3 驗證錯誤（虛構成功）。

診斷實驗：IT-Bench SRE 追蹤

研究人員對 310 筆 SRE 執行追蹤進行了標註，涵蓋三種模型類別，以分析其不同的失敗特徵。根據平均召回率，模型的表現差異極大：

Gemini-3-Flash： 75.5% 平均召回率
Kimi-K2： 28.6% 平均召回率
GPT-OSS-120B： 12.4% 平均召回率

失敗密度與複雜度

研究發現模型強度與其失敗的「外科手術」性質之間存在直接相關性。較強的模型在每條追蹤中呈現較少且更為孤立的失敗模式，使其更易於除錯：

Gemini-3-Flash： 每條失敗追蹤 2.6 個失敗模式（外科手術式失敗）。
Kimi-K2： 每條失敗追蹤 4.7 個失敗模式。
GPT-OSS-120B： 每條失敗追蹤 5.3 個失敗模式（連鎖崩潰）。

雖然 Gemini-3-Flash 通常因單一孤立瓶頸而失敗，GPT-OSS-120B 則受到錯誤疊加的影響，早期的推理不匹配會污染上下文，最終導致徹底脫軌。

區分致命與非致命失敗

MAST 使得根據系統是否能從失敗中恢復，將失敗分類為兩大類：

可恢復 / 結構性失敗

即使在成功執行中，這些缺陷也常常出現，且往往是任務所必需的。例如，FM-1.3 步驟重複在超過 90% 成功的 Kimi-K2 執行中出現，因為 SRE 任務常需多次查詢相同指標以驗證穩定性。

致命 / 決定性失敗

這些錯誤與失敗高度相關，且通常無法恢復：

FM-3.3 驗證錯誤： 在所有模型中是最強的失敗預測指標。Gemini-3-Flash 在失敗追蹤中此模式較成功追蹤提升了 52%。
FM-1.5 未察覺終止條件 與 FM-2.6 推理行動不匹配 也是主要的失敗驅動因素。

模型特定案例研究與介入措施

Gemini-3-Flash：過度自信

Gemini-3-Flash 效率高，但傾向在缺乏嚴謹證據的情況下假設成功。其失敗特徵以驗證錯誤為主。

建議修正： 實作外部驗證門檻。要求硬性的工具證據（例如，健康的指標閾值）才能允許代理退出，而不是讓 LLM 自行評分作業。

Kimi-K2：終止危機

Kimi-K2 難以辨識任務何時完成。它在 過早終止 (+46%) 與 未察覺終止條件 (+43%) 上出現大幅上升。此外，**FM-2.6（行動-推理不匹配）**在其 92% 的失敗中出現，模型雖然找出正確步驟，卻執行了無關的指令。

建議修正： 使用確定性的狀態機，在模型外部強制執行終止與迴圈控制。

GPT-OSS-120B：系統性不穩定

此模型根本無法維持內部狀態。它在 24% 的追蹤中失去對話歷史（FM-1.4），而 Gemini-3-Flash 為 0%，導致它「忘記」原本正在分流的警報。

建議修正： 實作積極的上下文清理與早期錯誤偵測，以防止小規模的推理不匹配累積成完全脫軌。

企業代理的工程路線圖

根據 MAST 分析，研究人員建議三項主要的架構介入，以提升代理的可靠性：

外部化驗證： 在退出前要求硬性證據，以減輕前沿模型的過度自信。
外部化迴圈控制： 使用有限狀態機將終止與迴圈偵測移至模型外，以防止無限迴圈或過早退出。
強制澄清： 將模糊性設為代理圖中的第一級分支，避免較小模型在輸入含糊時假設錯誤路徑。