ORCA-bench: How Ready Are Language Model Agents for Oncall?

一句话概括

ORCA-bench 是一个面向「值班（Oncall）根因分析」场景的高保真基准测试，它把通用编码智能体放进一个带完整可观测性数据（指标、日志、追踪）和源码访问权限的真实微服务系统中，用 1,079 个由资深 SRE 专家把关的任务来检验智能体能否像人类值班工程师一样，从模糊的用户报告出发定位故障根因——结果显示，最先进的智能体在中等难度任务上准确率仅 25.3%，在困难任务上只有 10.0%。

问题背景

大语言模型在代码生成、补丁修复和代码搜索上已经表现出色，但「值班根因分析」是另一回事。Oncall 工程师面对的不是一个清晰的编程问题，而是一堆噪声信号：凌晨两点收到一条含糊的用户投诉「支付变慢了」，需要在几分钟内判断是数据库连接池耗尽、某个服务实例内存泄漏，还是上游依赖抖动。这要求智能体在时间压力下，跨指标、日志、追踪和源码做多跳推理，而不是简单地「写一段代码」。

现有编码基准（如 SWE-bench）通常给一个明确的 issue 描述和代码仓库，任务边界清晰；但生产环境中的 incident 报告往往模糊、不完整，且故障可能由多个因素叠加导致。ORCA-bench 的动机正是填补这个空白：它要回答「通用编码智能体在多大程度上能胜任真实生产环境的 oncall 工作」，而不是「能不能修好一个 GitHub issue」。

方法要点

ORCA-bench 的核心设计有三层：

第一层：真实系统与真实遥测。 它构建了一个由 OpenTelemetry 插桩的微服务系统，运行六天，产生约 50GB 的指标、日志和追踪数据。这些数据通过真实接口暴露——Prometheus 存指标、Jaeger 存追踪、OpenSearch（经 Grafana）存日志，智能体需要像人类工程师一样用这些工具去查询，而不是直接读一个打包好的 JSON 文件。系统源码完全开放，智能体可以读代码、查调用链。

第二层：任务设计的系统化变化。 1,079 个 RCA 任务在三个维度上系统变化：报告具体程度（从「用户说登录失败」到「某个 API 返回 503」）、故障检测延迟（从故障发生后几分钟到几小时）、以及共现故障场景（多个故障同时发生，需要区分主因和次因）。任务按难度分为 Medium（现实输入设定）和 Hard（更模糊、更延迟、更多共现故障）。

第三层：评估的严谨性。 每个任务的 ground-truth 症状由专家 SRE 人工整理并签字确认；LLM-as-judge 的评分结果由人类独立复核，加权 Cohen's κ 达到 0.90，说明机器评分与人类判断高度一致。评估指标是「RCA Accuracy」——智能体能否在合理时间内定位到正确的根因组件和症状。

关键结论

五个前沿智能体（包括 Claude Fable 5 等）在 Medium 难度任务上的最佳 RCA 准确率为 25.3%，在 Hard 难度上仅 10.0%。这意味着即使是最强的模型，在「真实输入」设定下也有约四分之三的任务无法正确定位根因。
最弱的模型在 40% 的 incident 报告中会幻觉出一个不合理的根因——这不是「没找到」，而是「编造了一个看起来合理但实际错误的原因」，这对生产环境是危险的。
移除源码访问权限后，所有指标都下降。这证实了源码阅读是 RCA 的关键能力，但同时也说明「能读代码」不等于「会做根因分析」。
作者强调，这些数字是在一个「精心策划的、代码和插桩公开的、任务隔离研究」的测试床上得到的。真实生产系统比这个测试床大几个数量级、更动态、更特化，因此这个性能差距是「下界」——实际部署时需要的工程投入只会更大。

读后思考 / 适用场景

ORCA-bench 的价值在于它把「智能体能力评估」从代码仓库拉到了「可观测性工作台」。对研究者和工程团队来说，它的适用场景很明确：

智能体研发的靶场：如果你想开发一个 oncall 助手，ORCA-bench 提供了一个可复现的、有专家标注的测试环境，能精确衡量「加一个工具调用」「改进提示词」「引入记忆机制」带来的增益。
能力边界研究：25.3% 的准确率说明当前模型在「多源异构信号融合推理」上存在系统性短板。这为研究社区指明了方向——不是继续堆代码能力，而是需要发展「在噪声中做假设生成与验证」的推理框架。
工程风险评估：对平台团队而言，这个基准给出了一个量化标尺：在把智能体接入生产告警链路之前，先看看它在 ORCA-bench 上的表现，能避免「上线即翻车」。

一个值得注意的细节是：任务难度从 Medium 到 Hard 的准确率断崖（25.3% → 10.0%）说明，当报告更模糊、时间延迟更长、故障更复杂时，智能体的推理能力衰减极快。这提示我们，短期内智能体更适合做「辅助排查」而非「独立值班」——它可以快速缩小范围、生成假设，但最终决策仍需人类把关。

局限与开放问题

摘要中明确提到的局限是：测试床是「策划的、公开的、隔离的」，与真实生产环境有数量级差距。但还有几个摘要未直接讨论、但值得追问的问题：

「RCA Accuracy」的定义粒度：摘要未给出「正确」的判定标准——是定位到具体服务？具体代码行？还是具体故障类型？不同粒度的难度差异很大，这会影响对 25.3% 这个数字的解读。
时间维度的评估：Oncall 的核心约束是「快」，但摘要未提及智能体的平均排查耗时。一个 30 分钟才答对的智能体和一个 5 分钟答对的智能体，即使准确率相同，实际价值也完全不同。
任务隔离的简化：真实 oncall 中，工程师往往同时处理多个 incident，且系统状态是动态变化的。ORCA-bench 的任务「隔离研究」意味着智能体不需要处理「排查过程中故障还在演化」的挑战。
幻觉的深层机制：40% 的幻觉率是一个惊人的数字，但摘要未分析幻觉集中在哪类任务——是报告太模糊？还是遥测数据本身有歧义？理解幻觉的触发条件，可能比单纯提升准确率更有价值。

总体而言，ORCA-bench 是一个设计严谨、执行扎实的基准，它用数据说话：当前前沿智能体离「安全值班」还有很长的路。这个「下界」不是坏消息，而是一个清晰的路线图——它告诉我们该往哪个方向努力。