前沿编程 Agent 在 SWE-bench Verified 上的分数已经逼近 97%。但代码修复成绩，能否代表生产故障诊断能力，需要另行测试。
一篇 7 月 31 日上传 arXiv 的论文给出了另一组结果：在 ORCA-bench 构建的生产系统值班故障根因分析（RCA）测试中，五个前沿 Agent——Claude Opus 4.7、Sonnet 4.6、GPT-5.5、GLM-5 和 DeepSeek-V4-Pro——在中等难度任务上的最佳准确率仅为 25.3%。当用户报告只剩下"users are reporting site issues"时，这个数字跌至 10.0%。GLM-5 在 40% 的事故报告中幻觉出根本不存在的根因。即便是 Claude Fable 5，在 ORCA-bench Verified 子集上也只有 40.6% 的准确率。
理解这些结果，还需看测试环境：其中仅包含 50GB 数据、6 天监控、一个代码完全公开的微服务系统。真实生产系统比这大几个数量级，且动态得多。论文作者明确指出：他们测出的差距，是生产部署所需工程投入的下界。
故障诊断需要结合日志、指标和源代码
要理解这组数字的分量，需要先看清 SWE-bench 与 ORCA-bench 之间的本质差异。
SWE-bench 测试的是"给一个精确描述的 bug 和一个冻结的代码仓库，agent 能否生成正确的补丁"。它提供 issue 描述或相关失败信息，但并不总是直接告诉 Agent 故障代码的位置。评判标准是二元的：测试通过，或未通过。
oncall RCA 把所有这些前提都替换掉了。调查对象是一个运行的分布式系统（ORCA-bench 使用的 OpenTelemetry Astronomy Shop 包含 19 个微服务、13 种编程语言），需要通过链路追踪观察依赖关系，通过指标了解行为随时间的变化。输入是一句模糊的自然语言投诉——"用户说网站有问题""结账好像坏了"——而且往往在事故发生后数小时才到达工程师手中。评判标准不是测试通过，而是诊断是否与人类专家标注的根因集合匹配。
论文用一张对比表把差距说得清楚：论文对比的此前 SRE benchmark——AIOpsLab、ITBench、OpenRCA、SREGym——都至少缺失了 oncall 工程师依赖的三种信号之一。作者将 ORCA-bench 的特点概括为同时提供真实 telemetry 接口（Prometheus/OpenSearch/Jaeger，通过 Grafana API 暴露）、原始监控数据和完整源代码访问。它还系统性地改变用户报告的精确度和探测延迟——从 15 分钟到 24 小时，从精确时间戳到"昨天下午"。
报告信息减少时，最佳准确率从 58.7% 降至 10%
ORCA-bench 的 1,079 个任务（含 195 个对照任务）按照用户报告的信息量分为三个难度等级：
Easy：报告包含具体的错误信息或症状描述，比如"National Park Foundation Explorascope 产品页面不显示产品信息"。这类报告接近于配置了良好告警规则的团队实际收到的 ticket。最佳 Agent（Claude Sonnet 4.6）准确率 58.7%。
Medium：报告指向受影响的组件但缺少细节，比如"推荐系统不工作""结账页面报错"。这是多数一线 oncall 实际面对的输入质量。最佳准确率 25.3%。
Hard：报告只有一句"users are reporting site issues"。平均每个任务有 4.41 个候选根因需要同时排除。最佳准确率 10.0%。
各难度下的最佳准确率从 58.7% 到 25.3% 再到 10.0%，说明报告提供的信息量显著影响诊断表现。这些最佳值不一定来自同一个模型；结果提示排除候选根因是难点，不能单凭分数确定所有 Agent 都存在相同的架构缺陷。
这一判断在第六天"FAFO Friday"混沌场景中得到验证。当天有 6 个 feature flag 同时激活，形成级联故障。三个 Agent 各自找到了一个根因——且互不相同——然后漏掉了另外五个。GPT-5.5 表现最好，找到了 6 个中的 4 个。DeepSeek-V4-Pro 一个都没找到。
有些诊断报告给出了实际不存在的根因
除漏掉根因外，论文还统计了报告中出现不存在根因的情况。
GLM-5 在 40% 的事故报告中报告了不存在的根因。表现最好的 DeepSeek-V4-Pro 也有 7%。论文的人工评分发现两个反复出现的失败模式：Agent 倾向锁定在"声音最大"的症状上而忽略其他信号；Agent 无法在多个并发故障中持续量化严重程度变化并归因到具体事件。
这与 SWE-bench 的失败模式本质不同。SWE-bench 上一个补丁通不过测试就是通不过——评判是机械的。但在 RCA 场景中，Agent 可以生成一段看起来合理、引用了一串指标和日志、但实际上完全错误的诊断。一个值班工程师在凌晨三点面对这样一份报告时，会面临额外的核查负担。
移除源代码访问后，准确率下降 9–16 个百分点
测试中，Agent 用于读取源码的命令占比并不高。Claude Opus 4.7 只有 16% 的命令花在源码读取上，GLM-5 是 20%，其余命令用于查询 telemetry。但移除源代码访问后，所有模型的 RCA 准确率下降了 9-16 个百分点，幻觉率同步上升。
论文的分析表明，Agent 用源代码做两件事：在任务开始时探索系统拓扑以建立心智模型，在查询 telemetry 后验证假设。它们不怎么读源代码，但读的那一点对推理质量产生了不成比例的影响。这暗示了一种"锚定效应"：即使少量代码阅读也能帮助 Agent 区分因果和相关性——而纯粹依靠 telemetry 信号时，它们倾向于把相关性当作因果。
另一个与部署有关的数据是：Agent 发出的 telemetry 命令中有 26-40% 要么报错，要么返回空结果。GPT-5.5 在这方面表现最好（成功率最高且命令数最少），但仍无法回避根本问题：Prometheus、Jaeger 和 OpenSearch 的查询语言是 Agent 的另一个绊脚石。
上线前还需测试查询、证据核对和不确定性报告
ORCA-bench 提醒工程团队：代码生成分数不足以覆盖生产诊断所需的全部能力。
SWE-bench、Terminal-Bench、Aider Polyglot 测量的都是 agent 在结构良好的任务上生成代码的能力。但生产可靠性工作需要的是一个不同的技能栈：处理模糊输入、在多源异构信号间交叉验证、在不确定性中做出可辩护的判断、以及——最关键的一点——在找不到明确答案时如实报告"我不知道"。
Google SRE 团队的 AI Engineering for Reliable Operations 指南提出分阶段增加 Agent 自主权限：从只读调查开始，再到经人工审批执行建议，最后是在预定影响范围内自动修复。ORCA-bench 的结果表明，即使是最前沿的 Agent，在只读调查阶段也需要按具体任务验证可靠性。
论文作者列出的约束条件进一步放大了这个差距：ORCA-bench 的代码库和 OpenTelemetry 文档几乎肯定存在于模型的预训练数据中；生产系统是私有的、特化的；50GB 的测试环境在真实 TB 级日增量面前微不足道；Agent 每次调查都是"冷启动"——没有人类 SRE 积累数月的系统直觉。这些简化提示，真实值班任务可能更复杂；实际差异还取决于生产环境提供的告警、文档和工具。
对于一个正在考虑在生产中部署 coding agent 的工程团队，这一 benchmark 提供了一份可用于补充评估的能力清单：排除策略、跨信号关联、幻觉检测、查询语言掌握，以及最重要的——在缺乏证据时拒绝给出虚假诊断的能力。
ORCA-bench 的公共数据集和评分框架已在 Harbor 平台发布，LLM-as-judge 与人类评分的加权 Cohen's κ 达到 0.90。这是一个工程团队可以用来建立自己团队 RCA 评估的方法论参考，并据此检查自身系统与测试环境的差异。
