ORCA-bench: How Ready Are Language Model Agents for Oncall?
Albert Gong, Kyuseong Choi, Abhineet Agarwal, Jason Schechner, Ryan Huang, Raj Agrawal, Anish Agarwal, Raaz Dwivedi
cs.CL, cs.AI, cs.SE
2026-07-31
ORCA-bench 把五个前沿编程智能体放进带真实遥测和源码的微服务系统做值班根因分析,中等难度准确率仅 25%,最弱模型 40% 的报告在编根因。
LLM 写代码、补代码、搜代码已经很能打,SWE-bench 这类榜单上的分数越刷越高。但生产环境的值班运维(oncall)是另一码事。凌晨告警来了,用户报一句「结账用不了」,你得在一片噪声里翻指标、日志、链路追踪(trace),读源码,推出到底是哪个微服务挂了、为什么挂。这套诊断叫根因分析(RCA),它的证据是一个还在跑、还在变的活系统,不是一份冻结的代码或一个失败的测试用例;起点是一句模糊的用户报告,往往离故障发生已经过了几小时。
此前评测 LLM 智能体的 RCA 能力,要么只注入一个故障让模型猜根因,要么只给遥测不给源码。ORCA-bench 想把这件事做得更接近真实值班:同时给齐指标、日志、trace 三件套和完整源码,在一个跑着真实负载的系统上,用模糊度递增的用户报告来考模型。
底座是 Astronomy Shop,一个 OpenTelemetry 插桩的微服务演示系统,19 个服务用 Go、Java、Python、Node.js、C等 13 种语言写成,跑了六天模拟用户流量,攒下 50 GB 的指标、日志和 trace。模型拿到的是三件套:Prometheus 查指标、Jaeger 查 trace、Grafana 里的 OpenSearch 查日志,外加终端里的完整源码。它通过 Terminus-2 这个 agent 框架操作,能用的就是一个交互式 tmux 终端,上下文满了自动压缩,没有花哨工具,就是工程师 SSH 上去那一下。
任务一共 1,079 条(884 条真故障 + 195 条没有故障的对照),故障不是来自一个合成故障库,而是去拨系统里真实的 feature flag 制造的。三条轴拉满难度:
打分按每个故障的细则 0 到 3 分,既看 RCA Depth(部分得分,走到哪算哪),也看 RCA Accuracy(必须把所有根因都点中)。判定对错用一个 LLM 裁判(GPT-5.4),再请人独立重判 40 条来校准,加权 kappa 到 0.90,这个一致性可以信。
跑下来结论很统一:再强的模型,在真实值班设定下也远谈不上能顶一个 SRE。
| 设定 | 指标 | 最强成绩 |
| 中等难度(贴近真实报告) | RCA Accuracy | 25.3% |
| 硬题(只说「网站有问题」) | RCA Accuracy | 10.0%(Opus 4.7) |
| 全部 884 条故障(部分得分) | RCA Depth | 48.8%(GPT-5.5) |
| 最易一档(给具体报错) | RCA Accuracy | 30.6%(Sonnet 4.6) |
五个被测模型是 Claude Opus 4.7、Sonnet 4.6、GPT-5.5、GLM-5、DeepSeek-V4-Pro。把源码权限拿掉,所有模型的 RCA Accuracy 掉 9 到 16 个百分点,幻觉率反而涨。没了源码可核对,模型更爱编。最弱的 GLM-5 有 40% 的故障报告直接编出一个站不住脚的根因,最稳的 DeepSeek-V4-Pro 也有 7%。还有一个被忽视的难点:模型发出的遥测查询里,26% 到 40% 要么报错、要么返回空,它得在一堆空结果里接着推理。
作者还把 Claude Fable 5 放到一个 32 条人工核验过的小子集上,它的 RCA Depth 升到 58.2%、Accuracy 升到 40.6%,比同子集上的 GPT-5.5(21.9%)和 Opus 4.7(25.0%)都高。但作者强调,即便如此,Medium 和 Hard 上的 gap 依然没合上。
对从业者的信号很直接:别拿 SWE-bench 上的高分去推断智能体能接管生产可靠性。在静态仓库里修一个有测试用例兜底的 bug,和在活系统里从一句模糊工单推根因,是两种能力。短期内更现实的是把这类智能体当值班副驾,帮人查日志、拉指标、提假设,而不是当自动 SRE,而且得盯住它会不会一本正经地编根因。
更该记住的是作者的下限论证。这 50 GB、六天、代码和插桩全公开的测试床,已经是为模型量身的好条件。真实生产系统大它几个数量级、代码天天变、还全是私有 idiom。所以 25% 不是天花板,是地板。真实差距只会更大。
作者自己把局限摆得很清楚。第一,系统先验被吃进模型了:Astronomy Shop 和 OpenTelemetry 都是公开项目,很可能在预训练里见过,真实系统的代码模型从没看过。第二,每条任务都是冷启,模型没有人类 SRE 攒了几个月的系统直觉,也没有跨事件记忆。第三,只读:模型只能查不能修,没有「打了补丁、症状消失」这条最强的反馈信号。第四,只用了一套 prompt 模板和一个 agent 框架,换工作流可能不同。
此外还有两点存疑。1,079 条任务全来自同一个系统拨 flag,故障类型被这个演示系统的设计框住,泛化到别的技术栈存疑。另外 LLM 裁判评 LLM,即便 kappa 到 0.90,对「编造根因」这种本身就是模型强项的行为,可能有系统性宽容。