作者：林岚｜OC 开发者生态编辑

据最新发布的 ORCA-bench 论文，研究团队让五种前沿代码 Agent 调查一个接近真实生产环境的微服务系统。表现最好的 Agent 在中等难度故障上的根因分析准确率只有 25.3%，到高难度任务降至 10.0%。

一句话结论：会读代码、修测试的 Agent，不等于能接住凌晨三点的生产事故；真正的值班调查需要在不完整报告、数天遥测数据和不断变化的系统状态之间重建因果链，而当前模型大部分时候还做不到。

ORCA-bench 包含 1079 个根因分析任务。测试系统开放了六天、约 50GB 的指标、日志和调用追踪，并提供 Prometheus、Jaeger、OpenSearch、Grafana 等真实接口及完整源码。任务还会改变用户报告的具体程度、发现故障的延迟，以及是否同时发生多个异常。

这和常见代码基准有根本区别。代码题通常把问题、仓库和通过条件放在同一个上下文里；值班工程师拿到的可能只有一句“结账变慢了”，然后要判断延迟来自数据库、缓存、下游 API、部署变更还是监控本身。日志多不等于证据多，几十条异常里可能只有一条与用户故障有关。

论文给出的失败模式也比总分更值得看。最弱的模型在 40% 的事故报告中编造了不可信的根因；去掉源码访问后，所有模型的各项表现都会下降。这说明遥测并不能独立回答所有问题，Agent 仍要把运行现象和具体实现连起来。

研究团队让 SRE 专家确认标准答案，并用人工复核模型裁判，报告的加权 Cohen's kappa 为 0.90。不过，这仍是一个整理过的公开测试床：每个任务单独调查，代码和监控接口已知，也没有真实公司的权限审批、历史包袱和临时脚本。作者因此认为，测试得到的差距更像生产投入的下限，而不是最坏情况。

这不代表 Agent 对 SRE 没用。它可以先汇总时间线、检索相关部署、生成查询、对照历史事故，并把候选根因交给人。危险的是直接让一个准确率约四分之一的系统决定回滚、扩容或修改数据库。问题不在这里有没有 AI，而在动作权限是否和证据强度绑定。

关键事实

• 来源：ORCA-bench 论文及公开数据集
• 测试规模：1079 个任务、六天遥测数据、约 50GB 测试床
• 关键结果：中等难度最佳准确率 25.3%，高难度 10.0%
• 重要边界：测试环境比真实生产系统更小、更稳定，而且任务被单独调查

OC 判断

先别急着把 Agent 塞进值班表。当前更合理的位置是“调查助手”，不是“事故指挥官”。团队应要求它展示查询、时间线和证据来源，把停止服务、回滚和写操作留给明确审批；只有在长期回放自家事故并测出稳定表现后，才逐步增加自动化权限。

为什么重要

• 对开发者：评估运维 Agent 时，要测试脏日志、迟报、并发故障和缺失上下文，而不只是单一错误栈。
• 对企业：接入生产可观测性会同时扩大数据访问面，准确率评估必须和最小权限一起做。
• 对工具厂商：比“自动修复”更重要的是给出可复核证据，并在不确定时停下来。

参考来源

• ORCA-bench: How Ready Are Language Model Agents for Oncall?
• Harbor dataset documentation
• OpenTelemetry documentation