IBM与加州大学伯克利分校合作，利用IT-Bench和MAST框架深入分析企业级AI代理在实际IT自动化任务中失败的根本原因。研究聚焦于故障排查、日志与指标查询、Kubernetes操作等长期工具调用场景，揭示了当前主流评估基准“黑箱化”问题的深层缺陷。 传统基准如IT-Bench仅以成功率作为单一指标，虽能判断代理是否完成任务，却无法说明“为何失败”。为破解这一难题，研究团队引入MAST（多代理系统故障分类法），将1600多条执行日志进行结构化分析，提炼出14种典型故障模式，涵盖三类核心问题：任务理解偏差、推理与动作错配、终止条件误判。 研究团队对310条IT-Bench SRE任务的执行轨迹进行了标注，涵盖三种不同能力层级的模型：Gemini-3-Flash、Kimi-K2和GPT-OSS-120B。结果显示，性能更强的Gemini-3-Flash虽成功率较高，但失败时往往表现为单一、精准的“手术式”故障，如验证步骤错误，易于定位修复。而GPT-OSS-120B则表现出严重的“连锁崩溃”现象，一个早期推理偏差即可引发系统性失控，平均每条失败轨迹涉及5.3种故障模式，稳定性最差。Kimi-K2则介于两者之间，虽失败频率较高，但尚未达到全面崩溃。 更关键的发现是区分“非致命”与“致命”故障。研究发现，某些错误（如重复输出）在成功与失败轨迹中均常见，属于可容忍的结构性摩擦；而FM-3.3（错误验证）、FM-1.5（未识别终止条件）、FM-2.6（推理与动作不匹配）等则与失败强相关，一旦出现，任务几乎必然失败。 以Gemini-3-Flash为例，其问题在于“过度自信”——能正确识别问题但过早终止，缺乏工具证据支持。建议引入外部验证机制，如必须确认告警清除或K8s状态正常后才允许结束任务。Kimi-K2则存在“过度思考”问题，推理链过长且难以判断何时终止，建议采用确定性状态机控制流程。GPT-OSS-120B则需加强上下文管理与早期错误检测，防止微小偏差演变为系统性崩溃。 该研究证明，MAST能将模糊的“成功/失败”判断转化为可操作的工程改进路线图，推动AI代理从“试错式开发”迈向“可诊断、可修复”的可靠系统。