ORCA-bench：大模型智能体能否胜任线上故障值守？

weixin_446260852026-08-02 12:11

ORCA-bench：大模型智能体能否胜任线上故障值守？

论文原链接：https://arxiv.org/html/2607.28545v1

摘要

线上SRE故障根因分析（RCA）与常规代码修复任务存在本质区别：工程师需要基于模糊用户投诉、滞后故障时间窗口、海量噪声指标/日志/追踪链路完成推理。本文推出ORCA-bench评测基准，构建贴近真实生产的微服务值守环境，全方位衡量大模型智能体故障诊断能力。

基准核心配置

  1. 搭载OpenTelemetry全链路埋点的微服务系统（Astronomy Shop），提供6天50GB完整观测数据，通过Grafana暴露Prometheus指标、Jaeger追踪、OpenSearch日志三大标准观测接口，同时开放完整源码访问权限；
  2. 共1079组真实故障诊断任务，系统调控三大变量：用户投诉模糊度、故障检测滞后时长（TTD）、多故障并发场景；
  3. 所有故障症状、真实根因由资深SRE人工校验标注，采用GPT-5.4作为自动化裁判，人工重打分加权科恩κ系数κw=0.90\kappa_w=0.90κw=0.90，打分一致性极高。

核心实验结论

在5款前沿大模型（Claude Opus 4.7、Claude Sonnet 4.6、GPT-5.5、GLM-5、DeepSeek-V4-Pro）上完成全量评测：

  1. 真实中等难度任务最优RCA准确率仅25.3%，高难度任务低至10.0%；即便最新Claude Fable 5也存在明显能力缺口；
  2. 最差模型虚构虚假根因比例高达40%；移除源码访问权限后，所有模型各项指标大幅下滑；
  3. 本基准仅在隔离任务、小型50GB测试环境测得性能差距，真实生产系统规模、复杂度远超测试集，因此当前智能体距离可靠线上值守存在更大工程落地鸿沟。

本文五大核心贡献

  1. 全链路生产级观测环境：首个同时开放标准观测工具（指标/日志/追踪）+系统完整源码的SRE智能体评测基准；
  2. 分层难度大规模故障任务集：1079组任务可控调节投诉模糊度、故障滞后时长、5类并发故障模式（孤立/独立/冲突/级联/时序）；
  3. 人工核验完备真值：每条任务配套前端、指标、日志、追踪多层真实故障症状与完备根因集合；40条子集完成全人工复核；
  4. 高一致性LLM自动化裁判：裁判打分与人工复核加权κ=0.90，可稳定无偏差批量评测；
  5. 量化落地差距：主流前沿模型距离线上故障诊断成熟SRE存在显著性能短板，明确当前智能体尚不具备独立值守生产环境的能力。

1 引言

1.1 研究背景

现有代码智能体（SWE-agent等）擅长基于固定代码库修复已知Bug，但生产线上报故障场景完全不同：

  1. 输入是模糊用户投诉（如"网站打不开"），而非精准测试用例；
  2. 系统是动态运行分布式微服务，而非冻结静态代码仓库；
  3. 判断标准是可完整复现的故障因果链路，而非单条测试是否通过。

现有SRE评测基准存在明显短板：大多仅注入单一故障、缺失完整观测栈、不提供源码、无法模拟模糊用户上报、未区分故障上报滞后时长。

1.2 现有基准对比表

| 评测基准 | 用户描述粒度可控 | 故障滞后TTD | 完整观测接口 | 源码访问 | 人工标注症状 | 人工核验根因 | 打分方式 |

|--------| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 人工核验 |

| AIOpsLab | ✗ | ✗ | ~ | ✗ | ✗ | ~ | 程序自动 |

| ITBench | ✗ | ✗ | ✓ | ✗ | ~ | ~ | 程序自动 |

| OpenRCA | ✗ | ~ | ~ | ✗ | ✗ | ✓ | 程序自动 |

| SREGym | ✗ | ✗ | ✓ | ✗ | ✗ | ~ | 人工核验 |

| ORCA-bench(本文) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 人工核验 |

1.3 核心痛点

真实线上故障排查需要同步结合三大证据：时序指标、全链路追踪、系统日志+业务源码，但现有基准无法同时覆盖四类信息；且不存在可控调节"用户描述模糊程度""故障发生到上报间隔"的标准化任务集，无法量化真实场景下智能体诊断短板。

1.4 研究目标

构建贴近生产的SRE故障诊断基准，量化主流大模型在多证据、模糊输入、并发故障场景下的根因定位能力，明确当前智能体距离线上值守的性能鸿沟。

2 相关工作

现有研究分为两大赛道：无模型因果故障分析、LLM软件工程智能体，本文基准与两类工作存在本质差异。

2.1 传统无LLM故障根因算法

基于时序、调用图因果推理，仅能处理结构化指标数据，无法解读自然语言用户投诉，不能适配真实故障上报流程。

2.2 软件工程类LLM基准（SWE-Bench等）

任务基于冻结代码、精准Bug描述，无动态运行微服务、观测数据，完全无法复现线上滞后、模糊故障场景。

2.3 现有SRE/AI运维基准（SREGym、ITBench、OpenRCA）

三大核心缺陷：

  1. 仅提供观测数据CSV原始文件，无Grafana等工程师日常使用标准观测交互接口；
  2. 绝大多数基准不开放系统源码，无法支撑代码级故障溯源；
  3. 无法系统调控用户描述模糊度、故障滞后时间，缺少多层人工核验的故障症状真值。

2.4 ORCA-bench差异化优势

  1. 完整生产观测栈（Prometheus+Jaeger+OpenSearch+Grafana）+全量业务源码；
  2. 可控多维度任务变量：描述难度、故障滞后、5类并发故障；
  3. 全链路人工校验真值：前端表现、指标/日志/追踪故障特征、全部候选根因；
  4. 高一致性自动化LLM裁判，支持大规模可复现横向评测。

3 ORCA-bench基准完整构建流程

整体6阶段流水线：

  1. 部署OpenTelemetry微服务环境；
  2. 专家设计6天故障时序调度；
  3. 参数化生成任务（上报模糊度、检测滞后）；
  4. LLM生成不同粒度用户故障描述；
  5. 自动化+人工筛选每任务可行根因集合；
  6. 半自动采集、核验所有故障指标/日志/追踪症状。

3.1 底层微服务观测环境部署

采用官方OpenTelemetry Astronomy Shop分布式微服务演示系统，共19个多语言微服务（Go/Java/Python/C#等）：

  • 指标存储：Prometheus，通过Grafana HTTP API查询；
  • 日志存储：OpenSearch，支持Lucene日志检索；
  • 分布式追踪：Jaeger，全链路Span采集；
  • 业务源码：完整工程目录/app/opentelemetry-demo，智能体可通过bash读取、检索；
  • 数据规模：6天连续模拟用户流量，总观测数据50GB；
  • 交互约束：智能体仅能通过tmux终端执行命令，无图形界面。

3.2 故障调度时序设计

基于11类业务Feature Flag故障开关编排6天排期，设计5类故障场景：孤立、独立、冲突、级联、时序故障；

核心排期规则：

  1. 单日最多6个故障同时激活（周五"故障狂欢"峰值）；
  2. 夜间故障间隔≥12小时（周末无限制）；
  3. 单故障持续30分钟~5小时，购物车/支付类故障最长2小时；
  4. 同天故障无共享观测指纹，避免信号混淆；
    完整11个故障开关机制、指标/日志/追踪症状见附录B。
    典型故障示例：
  5. 商品目录故障：指定SKU商品查询返回gRPC内部错误，购物车/结算/推荐页面500报错；
  6. 推荐缓存故障：缓存缺失时传入空商品ID，上游服务返回未找到，推荐区域空白或报错。

3.3 任务参数化规则

每条任务定义三大核心变量：

  1. 故障上报偏移offset：故障发生到用户上报间隔；
  2. 故障检测滞后TTD：故障发生到智能体开始排查的间隔（15min/1h/8h/24h四档）；
  3. 描述模糊度三档
    • Easy（简单）：精准报错、指定页面，附带错误信息；
    • Medium（中等）：仅说明业务模块异常；
    • Hard（高难）：仅模糊描述"网站出问题"，无任何业务线索；
      额外空白对照任务：无故障平稳时段，用于测试智能体是否误报故障，总计1079条任务（195条空白对照，884条故障任务）。

3.4 用户故障描述生成方案

通过GPT-5.4给定故障开关对应的前端可见症状，分Easy/Medium生成用户视角描述；Hard统一固定模板"用户反馈网站存在问题"；仅保留人类肉眼可见页面报错，过滤后台指标类不可见信息。

3.5 真实根因真值构建流程

给定某一时段所有激活故障开关，自动过滤无前端影响故障；再通过LLM判定每条故障是否能解释当前用户投诉，输出该任务全部可行根因集合（多条故障可同时成立）；空白任务根因集合为空。

3.6 多层故障症状标注流程

  1. 前端症状：手动开启故障开关，浏览器复现页面异常，记录肉眼可见报错；
  2. 指标/日志/追踪症状 ：半自动流水线，检索故障时段观测数据，由2名资深SRE核验，区分三类信号：
    • 根因信号：故障代码直接抛出的底层指标；
    • 传导信号：下游服务收到上游故障产生的观测；
    • 用户症状：前端对外报错指标；
    • 元信号：故障开关埋点自身监控。

4 评测体系设计

4.1 任务检测规则

  • 故障任务：输出非空诊断报告记检测成功；
  • 空白对照任务：无任何故障根因判定为正确，虚构故障记为错误，通过专用裁判Prompt打分。

4.2 单根因0-3分层打分细则

每条可行根因独立打分，0最低、3满分：

1分档0：报告完全未提及该故障，因果链路完全不匹配；

2分档1：仅复现用户表层报错，未溯源观测/代码证据；

3分档2：找到部分指标/日志/追踪，但未完整定位故障开关；

4分档3：完整定位故障开关、完整还原因果链路、配套全部观测证据；

扣分规则：报告编造虚假根因，对应所有根因得分-1（最低0分）。

4.3 三大核心评测指标

  1. RCA准确率：任务中全部可行根因均被正确识别的任务占比；
  2. RCA深度：所有根因得分平均值（0~3分换算百分比），衡量部分排查完成度；
  3. 幻觉率 ：报告出现完全不存在的虚假根因的任务占比；
    辅助细分指标：故障时间匹配率、指标/日志/追踪证据召回率。

4.4 LLM裁判人工一致性验证

选取40条ORCA-bench Verified人工复核子集，人工与GPT-5.4裁判独立打分：

全部难度加权κw=0.90\kappa_w=0.90κw=0.90，中等难度最高0.96，打分高度对齐，可替代人工批量评测。

5 实验结果与定量分析

实验底座：Terminus-2统一智能体脚手架，仅开放bash终端，模型远程API调用；

参评模型：Claude Opus 4.7、Claude Sonnet 4.6、GPT-5.5、GLM-5、DeepSeek-V4-Pro；

两大实验组：①源码+观测全部开放 ②仅开放观测、屏蔽源码。

5.1 整体故障诊断能力基线

中等难度真实任务最优模型Claude Sonnet 4.6 RCA准确率仅30.6%；高难度任务最优仅10.0%；GLM-5幻觉虚构率高达40.2%。

完整汇总：

模型 平均RCA深度 RCA准确率 幻觉率
Claude Opus 4.7 48.5% 28.6% 12.6%
Claude Sonnet 4.6 46.7% 30.9% 14.8%
GPT-5.5 48.8% 24.3% 25.0%
DeepSeek-V4-Pro 19.7% 15.0% 7.2%
GLM-5 27.7% 17.6% 40.2%

典型案例对比：

GLM-5完全偏离真实商品目录故障，将根因错误归结为压测浏览器崩溃（得分0/3）；

Claude Opus 4.7完整梳理gRPC错误、开关激活时序、全链路500报错（得分3/3）。

5.2 任务难度消融

难度越高，性能断崖下跌：

  • Easy简单任务：最优模型准确率58.7%；
  • Medium中等任务：最优30.6%；
  • Hard高难任务：最优仅10.0%；
    高难任务平均每条任务存在4.41个并发可行根因，模型极易遗漏多条故障。周五6故障并发场景下，多数模型仅找到1条真实故障，剩余全部遗漏。

5.3 源码访问权限消融实验

屏蔽源码后所有模型RCA准确率下跌9~16个百分点，幻觉率显著上升；

时序类指标（故障发生时间匹配）受影响最小，时序信息全部存在观测数据内；

操作行为拆解：即便开放源码，Claude Opus仅16%命令读取源码，GLM-5仅20%，绝大多数操作集中在Grafana观测查询。

5.4 观测查询成功率与证据召回

  1. 26%~40%观测调用返回空/报错，大量无效查询消耗上下文；
  2. GPT-5.5观测查询失败率最低，指标/日志/追踪证据召回率全线最高；
  3. 所有模型日志类证据召回普遍优于指标，追踪链路最难完整检索。

6 结论与实验局限性

6.1 核心结论

  1. 当前前沿大模型智能体无法胜任真实线上故障值守；中等故障最优诊断准确率不足三成，高难场景仅10%；
  2. 源码是故障诊断关键信息，屏蔽后性能大幅衰减，但现有模型极少主动检索代码；
  3. 模糊用户描述、多故障并发是核心瓶颈，模型极易遗漏多条并行故障、虚构不存在根因；
  4. 观测查询存在大量无效空调用，上下文资源浪费严重，证据检索效率低。

6.2 实验局限性（真实生产难度下限）

本基准已大幅简化线上真实环境，测得性能差距为下限，真实落地鸿沟更大：

  1. 规模：测试仅50GB固定6天数据，生产TB级持续变动日志指标；
  2. 私有系统：基准开源系统大概率在模型预训练数据内，企业私有业务系统模型完全陌生；
  3. 无长期记忆：每条任务隔离运行，真实SRE积累数月系统故障经验；
  4. 无修复闭环：本基准仅诊断根因，无上线修复、验证闭环；
  5. 未混合专业因果推理算法，仅纯LLM智能体评测。

附录A 智能任务标准提示词模板

复制代码 
# 根因分析任务
你是资深SRE工程师，当前时间{current_time}
## 任务说明
本次用户上报故障时间{reported_time}，故障上报时间不等于故障真实发生时间；系统可能存在多条并行根因，也可能无任何故障。
## 源码路径
业务代码存放路径 /app/opentelemetry-demo
## 观测工具
Grafana HTTP接口，环境变量GRAFANA_URL，账号admin/密码admin
## 输出要求
若无故障，输出空report.md；若存在故障，报告分四节：概述、时序、5Why因果、修复方案
### 1.概述
2-3句说明故障发生时段、核心影响，禁止罗列正常服务；
### 2.时序
仅记录异常事件，每条标注UTC时间、服务、量化错误规模；
### 3.5Why因果
从用户可见现象逐层溯源，每条证据标注对应PromQL/Lucene/追踪ID，禁止循环；终止于可落地系统性问题；
### 4.修复方案
分根因修复、传播阻断、提前检测三类，标注对应因果层级。

附录B 故障开关完整机制（节选）

商品目录故障 productCatalogFailure

  1. 触发逻辑：SKU=OLJCESPC7Z商品查询返回gRPC INTERNAL错误；
  2. 前端症状：商品页/购物车/结算/推荐页面全部500；
  3. 指标：product-catalog服务错误调用尖峰；
  4. 日志：所有购物相关接口返回500；
  5. 追踪：全链路携带feature_flag=productCatalogFailure错误Span。

推荐缓存故障 recommendationCacheFailure

  1. 缓存缺失时传入空商品ID，目录服务返回NOT_FOUND；
  2. 前端500或推荐区域空白；
  3. 日志交替缓存命中/缺失记录，缺失时无商品数据。

附录C 故障调度时序约束

核心约束：单日最大6条并发故障，周五达到峰值；同故障最少间隔12小时（周末不限）；购物车/支付故障单次不超过2小时，全局故障最长5小时；同天故障无观测指纹重叠，避免信号混淆。

附录G LLM裁判完整Prompt与人工对齐

故障任务裁判核心逻辑

每条真实根因独立0-3打分，校验四类证据：故障时间偏差、开关名称匹配、因果链路、指标/日志/追踪完整集群；报告编造虚假根因统一扣分。

人工对齐结果

40条复核子集，全部难度Spearman相关系数ρ=0.92，加权κ=0.90，裁判打分高度可信。

附录H 实验硬件配置

  • 服务器：DigitalOcean Droplet，Intel Xeon Gold 6548N，48核192GB内存；
  • 系统：Ubuntu 22.04.5 LTS，Python3.13；
  • 推理入口：DigitalOcean Gradient AI统一API；
  • 推理参数：temperature=1，最大输出16384token，推理强度厂商默认；
  • 并发：30个任务容器并行执行。

附录I 全量细分实验数据表

包含各模型在「仅观测/观测+源码」两组下的RCA深度、准确率、幻觉率、指标/日志/追踪召回率、单任务平均token消耗，完整数值见论文原文表格。

附录J 故障诊断完整报告案例

同一高难购物车故障任务：

  1. GLM-5：错误归因压测浏览器崩溃，无任何商品目录相关观测证据，得分0；
  2. Claude Opus 4.7：完整梳理17:06开关激活→商品服务报错→结算页面500全链路，配套PromQL、日志检索语句，满分3分。

开源资源汇总

  1. 论文在线原文：https://arxiv.org/html/2607.28545v1
  2. ORCA-bench完整数据集、故障时序、评测脚本、裁判Prompt：https://hub.harborframework.com/datasets/orca-bench/ORCA-bench
  3. 底层微服务源码：OpenTelemetry Astronomy Shop开源Demo
  4. 开源许可：CC BY 4.0，可商用、二次修改，引用原文即可

结合三篇论文梳理大模型智能统一发展趋势

结合OmegaUse-OfficeVal（办公长流程）、SpecFirst（从零代码生成）、ORCA-bench（SRE线上故障）三篇2026最新顶会预印本，总结五大核心发展方向：

趋势1：任务分层、子智能体分工架构成为主流

  1. SpecFirst拆分为需求挖掘Agent+代码生成Agent；
  2. ORCA-bench隐含分层思路：观测检索子任务、源码检索子任务、报告生成分层；
  3. OmegaUse-OfficeVal区分文件处理、自动校验两大模块；
    统一思路：单循环一体化智能体处理长流程任务存在上下文漂移、探索不足缺陷，拆分为专用子智能体、固化中间产物（SPEC.md/评分细则）是标准优化范式。

趋势2：评测基准走向真实工业全链路，从"步骤打分"转向"业务价值/交付物打分"

  1. 办公基准OmegaUse：不再看操作步骤，衡量交付文档可用性+人力/市场经济成本；
  2. 代码基准SpecFirst：不以代码行数评判，以二进制行为等价测试通过率；
  3. SRE基准ORCA-bench：不看命令调用次数，以真实故障根因完整度、线上业务影响评判；
    旧基准局限：仅短片段、单步简单任务；新基准全部瞄准多小时长周期、真实工业完整流水线。

趋势3 标准化、可复现自动化校验替代人工/LLM裁判

三篇论文全部抛弃主观人工打分、LLM-as-judge不稳定方案：

  1. OmegaUse：Office文件结构化代码校验脚本；
  2. SpecFirst：二进制覆盖率+自动测试集判分；
  3. ORCA-bench：结构化LLM裁判+人工高一致性核验；
    核心诉求：跨模型横向对比无偏差，支撑模型迭代定量观测。

趋势4 聚焦长周期、多证据、多文件协同复杂任务

早期智能基准以单轮、单文件、简单输入为主；2026前沿基准统一攻克长上下文痛点：

  • 办公：多模态多文件2小时人工长流程；
  • 代码：从零完整程序复刻，无现有代码库；
  • SRE：多并发故障、海量时序观测、跨服务链路长时序推理；
    行业瓶颈统一：长程状态维持、多线索关联推理、上下文信息衰减。

趋势5 借鉴成熟人类工程流程改造智能体架构

不再单纯依赖模型原生推理能力，将人类标准化工作流程嵌入智能体流水线：

  1. SpecFirst复用软件工程需求先行流程；
  2. OmegaUse对标外包办公全流程验收规范；
  3. ORCA-bench完全复刻企业SRE故障排查标准5Why分析、观测检索流程；
    核心路径：把人类成熟工业流程拆分为AI可执行阶段，弥补LLM规划短板，是下一阶段智能体主流优化路线。
相关推荐
fthux1 小时前
装闭 RenoPit 源码解析（13）：生成AI装修闭坑PDF报告
人工智能·ai·pdf·开源·github
独行侠影a2 小时前
Mojo：专为AI而生的“Python++”，能否真正挑战CUDA与C++的统治地位？
大数据·人工智能·深度学习
zzzzzz3102 小时前
别让大模型直接碰业务：我在 Spring Boot 里给 AI 操作加了一道“可拒绝的闸门”
人工智能·spring boot·spring
2601_960906722 小时前
一致行动人合计持股比例变动超过1%整数倍
人工智能·逻辑回归·爬山算法·散列表·启发式算法·广度优先
蓝鲨硬科技2 小时前
任利锋的“造物”野心，让AI 3D进入“可制造”时代
人工智能·3d·制造
暗黑小白2 小时前
Agent 运行时与 Harness：从教科书循环到生产级运行时
人工智能
烂蜻蜓2 小时前
AI入门教程（十七）：AI安全进阶——越狱、注入、对抗与防护
人工智能·ai
小K讲AI营销2 小时前
存储定价权重构：用“产能分配“框架重估 DRAM+46%、NAND+65%
人工智能
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02GitHub 镜像站点03国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）042026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片052026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费09AI科技热点日报 | 2026年07月01日102026开年大模型最新对比解析及场景落地指南