前沿 coding agent 在 SWE-bench Verified 上的分数已经逼近 97%，但你不会想让它们值夜班。
一篇 7 月 31 日上传 arXiv 的论文给出了一个令工程团队无法忽视的数字：在 ORCA-bench 构建的生产级 oncall 根因分析（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% 的准确率。
这不是 benchmark 恶意刁难。测试环境仅包含 50GB 数据、6 天监控、一个代码完全公开的微服务系统。真实生产系统比这大几个数量级，且动态得多。论文作者明确指出：他们测出的差距，是生产部署所需工程投入的下界。
SWE-bench 的分数为什么在此失效
要理解这组数字的分量，需要先看清 SWE-bench 与 ORCA-bench 之间的本质差异。
SWE-bench 测试的是"给一个精确描述的 bug 和一个冻结的代码仓库，agent 能否生成正确的补丁"。它假设 agent 已经知道哪里出了问题——任务输入是一份明确的 issue 描述或失败测试。评判标准是二元的：测试通过，或未通过。
oncall RCA 把所有这些前提都替换掉了。调查对象是一个运行的分布式系统（ORCA-bench 使用的 OpenTelemetry Astronomy Shop 包含 19 个微服务、13 种编程语言），依赖关系只通过链路追踪可见，行为随时间变化只通过指标展现。输入是一句模糊的自然语言投诉——"用户说网站有问题""结账好像坏了"——而且往往在事故发生后数小时才到达工程师手中。评判标准不是测试通过，而是诊断是否与人类专家标注的根因集合匹配。
论文用一张对比表把差距说得清楚：此前所有 SRE benchmark——AIOpsLab、ITBench、OpenRCA、SREGym——都至少缺失了 oncall 工程师依赖的三种信号之一。ORCA-bench 是第一个同时提供真实 telemetry 接口（Prometheus/OpenSearch/Jaeger，通过 Grafana API 暴露）、原始监控数据和完整源代码访问的 benchmark。它还首次系统性地变化了用户报告的精确度和探测延迟——从 15 分钟到 24 小时，从精确时间戳到"昨天下午"。
三个难度阶梯，一次系统性的崩溃
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 一个都没找到。
40% 幻觉率不是 bug，是架构特征
如果说低准确率反映的是能力不足，那么幻觉率暴露的是更危险的倾向：Agent 在找不到答案时会编造答案。
GLM-5 在 40% 的事故报告中报告了不存在的根因。表现最好的 DeepSeek-V4-Pro 也有 7%。论文的人工评分发现两个反复出现的失败模式：Agent 倾向锁定在"声音最大"的症状上而忽略其他信号；Agent 无法在多个并发故障中持续量化严重程度变化并归因到具体事件。
这与 SWE-bench 的失败模式本质不同。SWE-bench 上一个补丁通不过测试就是通不过——评判是机械的。但在 RCA 场景中，Agent 可以生成一段看起来合理、引用了一串指标和日志、但实际上完全错误的诊断。一个值班工程师在凌晨三点面对这样一份报告时，几乎不可能逐项核查其真假。
源代码比你想象的更重要
一个反直觉的发现：Agents 实际上不怎么读源代码。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 结果最重要的含义不是"Agent 还没准备好 oncall"——这个结论太浅了。真正重要的含义是：当前评估 Agent 能力的主流范式存在一个盲区。
SWE-bench、Terminal-Bench、Aider Polyglot 测量的都是 agent 在结构良好的任务上生成代码的能力。但生产可靠性工作需要的是一个不同的技能栈：处理模糊输入、在多源异构信号间交叉验证、在不确定性中做出可辩护的判断、以及——最关键的一点——在找不到明确答案时如实报告"我不知道"。
Google SRE 团队在其 AI Engineering for Reliable Operations 指南中定义的 Agent 自主性框架要求：在任何 agent 获得生产系统访问权限之前，必须经过读-only 调查 → 人工审批后的建议 → 有限 blast radius 的自动修复这条路径。ORCA-bench 的结果表明，即使是最前沿的 Agent，在读-only 调查这一层级也远未达到可信赖的水平。
论文作者列出的约束条件进一步放大了这个差距：ORCA-bench 的代码库和 OpenTelemetry 文档几乎肯定存在于模型的预训练数据中；生产系统是私有的、特化的；50GB 的测试环境在真实 TB 级日增量面前微不足道；Agent 每次调查都是"冷启动"——没有人类 SRE 积累数月的系统直觉。每个简化都指向同一个方向：真实 oncall 只会更难。
对于一个正在考虑在生产中部署 coding agent 的工程团队，这一 benchmark 给出的不是一个"再等半年"的时间表，而是一份需要逐个补救的能力清单：排除策略、跨信号关联、幻觉检测、查询语言掌握，以及最重要的——在缺乏证据时拒绝给出虚假诊断的能力。
ORCA-bench 的公共数据集和评分框架已在 Harbor 平台发布，LLM-as-judge 与人类评分的加权 Cohen's κ 达到 0.90。这是一个工程团队可以用来建立自己团队 RCA 评估的方法论参考，而不仅仅是一个用来引用分数的排行榜。
