一个 SRE 事故诊断基准里，最强模型只拿到 47%。
这不是小模型翻车，也不是玩具题。Artificial Analysis 与 IBM Software Innovation Lab 发布的 ITBench-AA，基于 IBM ITBench 数据集，首批测的是 Kubernetes 场景下的 SRE 事故诊断。
59 个任务里，有 40 个公开任务，19 个全新的 held-out 任务。Claude Opus 4.7 得分 47%，GPT-5.5 为 46%，Qwen3.7 Max 为 42%。所有前沿模型都没过 50%。
我更在意的不是谁排第一，而是这个结果给企业提了个醒：AI Agent 可以进运维流程，但现在还不适合被当成无人值守的 SRE。
它测的不是会不会聊天，而是能不能找准根因
ITBench-AA 的首批任务很具体：Kubernetes 事故诊断。
模型拿到的不是一道文字问答题，而是一组事故快照。里面包括告警、事件、链路追踪、指标、日志和应用拓扑。它们被放在沙箱文件系统里。
模型通过统一的开源 Stirrup harness 执行 shell 命令，最多跑 100 轮。最后，它要提交一组 Kubernetes 根因实体，比如 Deployment、Service、Pod 或 NetworkPolicy。
这里有一个关键限制：本次评测尽量固定了智能体运行框架。所有模型用同一套 Stirrup harness。也就是说，结果更偏向比较模型在这个任务里的诊断能力，而不是比较不同 Agent 框架谁写得更好。
评分也很硬。
ITBench-AA 采用 recall-gated precision。只要漏掉任何真实根因，该任务得分就是 0。只有找全真实根因后，才按误报多少计算精度。
| 维度 | 具体设置 | 读者该怎么理解 |
|---|---|---|
| 任务范围 | 59 个 SRE 任务，40 个公开、19 个 held-out | 目前只能代表 Kubernetes SRE，不代表所有企业 IT 场景 |
| 输入材料 | 告警、事件、日志、指标、链路追踪、拓扑 | 更接近事故排查，不是普通问答 |
| 运行方式 | 统一 Stirrup harness，最多 100 轮 | 尽量减少 Agent 框架差异的干扰 |
| 输出目标 | Kubernetes 根因实体 | 要找根因，不是列症状 |
| 评分规则 | 漏掉真实根因得 0；找全后再看误报 | 对漏报和误报都很不宽容 |
这也是为什么不能把低于 50% 简单翻译成“大模型不能做 SRE”。更准确的说法是：在这个基准、这个评分规则、这类 Kubernetes 诊断任务里，当前模型还不够可靠。
企业现场最怕的不是 Agent 没想法，而是它把症状说成根因。排障里一字之差，后面可能就是错误回滚、误删配置，或者把值班工程师带进岔路。
长推理不等于更会排障
这次结果里，一个很有用的对比是推理轮数。
GPT-5.5 平均每个任务跑 31 轮，得分 46%。Gemini 3.1 Pro Preview 平均跑 83 轮，得分只有 30%。
这说明一件事：多查日志、多跑命令、多给解释，不一定更接近根因。
| 模型 | 得分 | 平均任务轮数 | 单任务成本 |
|---|---|---|---|
| Claude Opus 4.7 | 47% | 未给出 | 约 5.38 美元 |
| GPT-5.5 | 46% | 31 轮 | 未给出 |
| Qwen3.7 Max | 42% | 未给出 | 未给出 |
| GLM-5.1 | 40% | 未给出 | 未给出 |
| Gemma 4 31B | 37% | 未给出 | 约 0.14 美元 |
| Gemini 3.1 Pro Preview | 30% | 83 轮 | 约 2.23 美元 |
SRE 排障的难点，常常不是没有线索，而是要把根因、诱因、伴随症状分开。
模型如果把 chaos-mesh 控制器、上游注入机制，或者并发出现的异常都列成根因，就会被评分系统当作误报。找得多，未必占便宜。
这对企业很现实。
如果一个 Agent 每次都能产出十几个“可能原因”，它也许能加速初筛。但值班工程师要逐条复核。复核成本上来后，自动化的收益会被吃掉一部分。
所以，SRE 负责人不应该只问“模型会不会查日志”。更该问三件事：它漏不漏真实根因，误报多不多，误报会不会诱导人做危险操作。
企业落地要看边界，也要看成本
这次评测里，开源权重模型给出了一条更现实的路线。
GLM-5.1 得分 40%。Gemma 4 31B 得分 37%，单任务成本约 0.14 美元。它们没有拿第一，但成本曲线更友好。
对照一下，Claude Opus 4.7 以 47% 领先，单任务成本约 5.38 美元。Gemma 4 31B 的分数还高于 Gemini 3.1 Pro Preview 的 30%，而后者单任务成本约 2.23 美元。
这会影响企业试点方式。
对企业 IT 或 SRE 负责人来说，更稳的路线不是让 Agent 自动关停服务、回滚发布、改生产配置。更合理的是让它做三类辅助工作：日志聚合、拓扑定位、候选根因排序。
最终确认，还是应留给人。
预算有限的团队，可以把开源权重模型放进离线事故复盘和内部知识库适配里试。比如先让它跑历史事故，看它能不能稳定找出根因实体，再决定要不要进入线上值班流程。
采购动作也会变得更保守。看到低于 50% 的结果后，企业不必立刻否定 Agent 项目，但应该延后“无人值守 SRE”的承诺，把验收指标改成可复核的辅助能力。
接下来更该看两个变量。
一个是 held-out 任务继续增加后，分数会不会稳定。19 个全新 held-out 任务已经比只刷公开题更有意义，但样本规模仍然有限。基准要继续扩，才更能看出模型是不是在泛化。
另一个是任务范围。ITBench-AA 后续方向包括 FinOps 和 CISO，但当前首批只评估 SRE。现在不能把这组结果外推成“模型已经能处理所有企业 IT 决策”。
边界要画清楚。
ITBench-AA 的价值，不是给模型排座次。它更像一把尺，提醒企业把 AI 运维从演示环境拉回生产约束：成本、误报、漏报、复核责任，一个都绕不开。