Agent 上 Oncall，还早。ORCA-bench 给 Frontier 模型打了个 10%

过去半年，圈里一直在说 Agent 要抢 SRE 的饭碗了——代码能写、Patch 能打、日志能查，那 Oncall 是不是也能丢给 Agent 顶班？今天 arXiv 上挂出来的一篇论文，结结实实地给这个说法泼了盆冷水。

几位来自学界和工业界的研究者搞了个基准测试叫 ORCA-bench，专门测前沿语言模型 Agent 在真实 Oncall 场景下的根因分析（RCA）能力。他们把一套完整用 OpenTelemetry 做了埋点的微服务系统跑起来，挂了六天的指标、日志和链路追踪数据，全部通过 Prometheus、Jaeger、OpenSearch 这些生产级接口暴露出来——而且把源代码也给了 Agent。一共 1,079 个 RCA 任务，按报告模糊程度、发现时间早晚、故障是否并发分了难度等级，所有 ground-truth 症状都由资深 SRE 专家签字确认。

结果呢？五个 Frontier 模型里，表现最好的在 Medium 难度下 RCA 准确率是 25.3%，到了 Hard 难度直接掉到 10.0%。Medium 已经是论文定义的「真实输入设定」了——就是那种用户报了个模糊问题、人隔了几小时才摸到机器前面的常态。这个成绩里还包括了 Claude Fable 5。

最弱的那个模型，在 40% 的 incident 报告里直接瞎编了一个根因。

而且这些成绩是有源代码可查的前提下跑出来的。一旦拿走源代码权限，所有模型指标全部下滑。把 Agent 丢到一个连代码都不给看的现网环境里，它可能连怎么死的都不知道。

这篇论文最有价值的点不是它做了个 Benchmark，而是它对结果的态度。论文原文的原话是：这个 50 GB / 六天数据的测试环境是精心挑选的，每个任务是隔离分析的，系统的代码和埋点全是公开的。真实生产系统的规模比这个大一到两个数量级，更动态、更 idiosyncratic。所以我们报出来的这个 gap，只是前沿编码 Agent 被安全地托付生产可靠性之前，所需工程投入的下界。

翻译成人话就是：别急，差得远。

我做 Oncall 很多年，读到这条结论的时候脑子里只有一个画面——半夜三点被 PagerDuty 叫醒，盯着一个用户反馈说「页面加载慢」，然后开始翻 Dashboard、查日志、看 Trace，前后扯一个小时才定位到一个没接超时参数的 Redis 调用。ORCA-bench 模拟的恰恰就是这种场景：模糊的入口、噪音数据、过期指标。

LLM 在其他编码任务上的表现——写代码、修 Bug、解释代码——已经在不少基准测试里接近甚至超过人类平均线了。但 Oncall RCA 这件事的性质完全不同。它不是在干净的问题描述上做 diff，而是在一堆互相矛盾的信号里猜哪个是病因。论文用的 LLM-as-judge 评分机制，人类重评分的一致性达到了 Cohen's κ_w = 0.90，说明这活儿对人也难，但至少人判断的共识很高——模型们的分歧显然大得多。

ORCA-bench 的数据集已经开源了，在 Harbor Framework 上可以拿到。GitHub 上也能找到配套的微服务系统和编排脚本。有条件的团队可以跑一下自己用的模型，看看在自己栈上的差距有没有缩小。

我个人判断，短期内 Agent 在 Oncall 里的角色不会是「替人值班」，更可能是「值班搭子」——帮人把前 20 分钟的重复数据捞活干了，把 Trace 串起来，把时间线理顺，但最终结论还得人来拍。ORCA-bench 给出的 25.3% 和 10.0% 这两个数字，恰好给这个判断提供了一个还算不丢人的下界。

相关链接：
- 论文：https://arxiv.org/abs/2607.28545
- 数据集：https://hub.harborframework.com/datasets/orca-bench/ORCA-bench