Incident-Arena：生产事故修复测到 64.3%，离最后一个九还远

Incident-Arena：生产事故修复测到 64.3%，离最后一个九还远

Andre Fu、Meji Abidoye、Lata Mishra，Abundant AI；Malik Drabla，Adrenaline AI；Leon Liu、Yiyuan Li，卡内基梅隆大学；Marek Šuppa，布拉迪斯拉发考门斯基大学；Adnan El Assadi，麻省总医院

预印本，2026-09-30

摘要

编码智能体已经普遍用在学术界和工业界的软件工程里。应用编码做了不少，生产事故响应却少被测量。这个正在出现的方向叫智能体站点可靠性工程（agentic SRE，站点可靠性工程：让服务在故障后恢复，并保住无关行为与数据）。现有基准有三处短板：环境不真实，常常是玩具仓库；框架实现各写各的；验证器多半是静态检查。

作者给出人工编写的 Incident-Arena：20 个任务，来自真实部署过的开源软件。每个任务把一个生产应用部署到一次性的 Kubernetes 集群，注入可调故障，并按任务要求持续打负载。验证不看配置长什么样，而看修完之后系统怎么表现。结果门（Outcome Gate）在流量还在跑时量恢复；安全门（Safety Gate）量修复是否经得起重启、是否保住数据、是否留在允许范围内。一次试验平均 400 万词元、68 步。20 个人工任务、3 个应用基底上，最好的模型配置通过率 64.3%。失败从诊断和定位，延伸到修得不完整，以及不安全的回退。

图 1：按 Pass@1（一次试验通过两道门的比例）排列的十个模型配置。星号表示网络安全拒答，见第 4 节。

1 引言

自 Claude Code 和 Codex 出现后，编码智能体成了和代码打交道的主要方式：从亲手打字，变成吩咐智能体做应用编码。它们越来越能做仓库级任务。应用编码被接走之后，工程生命周期的其余部分还是问号。运行中的修复只有同时做到三件事才算成功：恢复服务、保住无关的行为与状态、进程重启后仍然有效。因此评测不能停在「补丁看起来像样」或「告警消失」。

近期基准覆盖 DevOps、集成、可观测性和事故响应（Tang 等，2026；Kottamasu 等，2026；Clark 等，2026）。智能体 SRE 上的已有工作缺三样：运行有效性、诊断分辨率、可复现与可互操作。

运行有效性指验证器和环境像不像真的。有的基准停在仓库制品；活系统基准常用定制或很小的应用。它们便于控制，却说不清成绩能否搬到真实系统。前沿模型已经能察觉自己在被评测（Needham 等，2025），人工接口、细小的不对齐、不真实的验证器或目标，都会诱发评测怀疑。

诊断分辨率不足，是因为合计成功率能看出失败，却常常没有受控变化去引出失败行为。把前沿模型的推理档扫一遍，才能把更强模型里的运行能力拆开看。

可复现与可互操作也差。SRE 式任务很难用 Harbor（Harbor Framework Team，2026）来测，于是 SRE-Gym（Clark 等，2026）、APEX-SWE（Kottamasu 等，2026）和 DevOpsGym（Tang 等，2026）各自接一套。智能体分析和横向比较都变难。

Incident-Arena 是人工编写的基准，看智能体能否诊断、修复并重新跑起坏掉的生产系统。20 个任务来自活的 Kubernetes 系统，灵感或材料取自真实生产仓库。故障做在配置、运行时状态或镜像层。智能体的权限从完整源码可见，收到范围受限的 kubectl。

智能体放在一个立足 Pod 里，对指标、日志和其他可观测性只有只读。最终评分确定且不用大模型，以免设计评分量表。验证器两道门：结果门量持续流量下的恢复；安全门量持久、数据保全、修复本身和范围限制。

贡献有三项。一是人工编写的运行基准：难度来自环境，多 Pod、多服务、多跳。二是面向生产的验证器：两道门一起量持续负载、重启和新流量下的恢复与修复。三是一次前沿评测：3,000 次试验，按模型拆开看。

2 相关工作

活系统上的事故响应。AIOpsLab（Chen 等，2025）把 DeathStarBench（Gan 等，2019）部署在 Kubernetes 上，事后每个服务都起来就算缓解通过。ITBench（Jha 等，2025）在告警清除时把场景记成已缓解。OperAID（de Castro 等，2026）在活的 5G 核心上核修复。SREGym（Clark 等，2026）最接近本文：它加背景噪声和亚稳态失败，用大模型清单给诊断打分，故障消失且系统恢复健康就算缓解成功。这些工作大多跑演示或基准应用，并给智能体通用 kubectl 或高权限。Incident-Arena 跑钉死版本的生产应用 Saleor（Saleor Commerce，2026）和 FrappeERP（Frappe Technologies，2026），外加作者自建的 Slack 基底。权限是收窄的。不用大模型的验证器在流量仍在跑时、或受影响服务重启后再查一次修复。表 1 比较这些基准。

表 1：各基准评什么。✓ 是；◦ 部分或仅部分任务；× 否或未陈述。修复：智能体能改系统并被检查。点名故障：故障归因是否被评分。范围：是否检查保全、连带损害或修复范围。持久：等待或重启后再查。无裁判：成功不依赖轨迹或大模型裁判。双向：正确修复能通过，什么都不做会失败。无故障：包含「什么都不改才正确」的情形。Harbor：原生或经适配器跑在 Harbor 上。来源与编码见附录 I。

a：ITBench 94 个场景里的 42 个 SRE 场景，其余是安全。b：884 个事故任务加 195 个无故障对照。c：归因不评分。基于正则的检查很脆；原文后半句在版面上截断，只剩下「主观评分量表」。

诊断与仓库任务。另一些基准停在修活系统之前。DevOps-Gym 和 APEX-SWE 给代码改动或书面诊断打分。OpenRCA（Xu 等，2025）、Cloud-OpsBench（Wang 等，2026a）、ORCA-bench（Gong 等，2026）和 ITBench-AA（Artificial Analysis 与 IBM Research，2026）要的是录制数据里的根因。其中两个发现诊断常常没有着落：Cloud-OpsBench 根因准确率 0.76，证据闭合率只有 0.38；ORCA-bench 上最弱的模型在 40% 的报告里编出一个不可信的根因。Incident-Arena 要求找到故障并修好，评分对象是修复。

安全修复。修对了还得安全。R2Act（Qi 等，2026）发现，诊断正确的事故里仍有 39.5%–62.0% 得到无效恢复动作。指令说不清时，编码智能体在 55.8%–67.8% 的运行里越过动作边界（Ji 等，2026）。活的 PostgreSQL 上，DBA-Bench（Chen 等，2026）报告人类数据库管理员安全修好 93.4%，最好的自动基线是 17.9%。InfraBench（Gao 等，2026）最接近本文的验证器：它在持续负载、重启和拆除时复查基础设施任务，但用大模型裁判标记危险命令，并给智能体 root 和 SSH。本文在生产应用的事故上做类似检查，不用大模型裁判，权限更窄，并且任何越出允许范围的修复都判失败。

分数是否可信。近期编码基准在问自己的分数能不能信。检查会放过错答案：SWE-bench（Jimenez 等，2024）全部补丁里有 7.8% 被算作正确，却通不过开发者自己的测试（Wang 等，2026b）；SWE-Marathon（Desai 等，2026）在 10.2% 的轨迹里发现验证器被绕过。在运维里，同样的失败是健康检查在坏系统上通过。任务也会漏进训练数据，SWE-bench-Live（Zhang 等，2025）和 SWE-rebench（Badertdinov 等，2025）用收集新题来对付。模型也可能认出自己在被评测；Gemini-2.5-Pro 的 AUC 是 0.83（Needham 等，2025）。本文每个任务都双向检查：金标准解和无操作运行，并让对抗智能体尝试钻空子。附录 J 表明，结果检查会拒绝「修复从未发生」的报告。两个应用是公开的，所以注入的是新故障，并拦住代码托管站点；指令里不放评测暗示。

诊断分辨率。单一通过率只说明失败，不说明失败在哪。METR 用智能体在固定成功率下能完成的、以人的工时计的任务长度来量能力（Kwa 等，2025）。根因分析里，跨系统的合计准确率会藏住每种方法在每个系统上谁赢（Hu 等，2026）；ORCA-bench 变动报告的具体程度、检测时间和同时出现的故障（Gong 等，2026）。本文对修复做同样的事：权限从完整源码可见收到范围受限的 kubectl，十个模型与框架配置跑遍每个可用推理档，并按应用报告。

3 Incident-Arena

基准是三块：基底、故障层、智能体运行时。基底加故障层构成任务，运行时决定智能体环境。

3.1 基底怎么造

基底是注入事故的完整可执行系统。建造通常三步：挖掘、运行化、打包。三个基底是 Slack、Saleor 和 FrappeERP。Slack 是自建的高仿真基底；后两个从开源挖出。原文一处把 Saleor 写成 Saelor，引用指向同一仓库。

图 2：任务构造。从真实应用挖掘并做成基底，在不同层注入故障，再在活运行上验证。

挖掘开源仓库。找的是生产里在用、或按生产建模的开源应用，要有持久状态、网络服务、后台工人、缓存、队列、认证和外部依赖。接受条件四条：宽松许可证、文档够用、构建可复现、有足够落脚点。每个仓库钉在一次提交上，上游改动不能改变基准。

若心里有一个应用却不满足约束，就按理想形态自建。Slack 基底从零写起，模型接近 Mattermost（Mattermost，2026），但更接近真实运行，展开到 47 个 Pod、45 个服务（表 7）。

把仓库做成能跑的系统。开源仓库很少以生产系统的形式交付，于是补上容器化与构建、确定的启动、迁移与种子数据、网络、负载发生器和指标日志。然后校准：在健康基底上记一次基线，作为健康参照。校准对每个基底只做一次，用来区分任务里的健康与不健康。核心量包括核心 Pod 的 p50 与 p99 延迟（按峰谷负载分开）、错误率、有效吞吐比、流量计数，以及挂在特定 Pod 和服务上的探针。探针还覆盖服务可用性、数据完整性、写后读正确性、顺序、重复、队列长度与积压、修复是否留住，以及被禁止的重启。

Kubernetes 打包。任务是基底加一层故障。智能体只在一个主 Pod 里，当作立足的操作壳。其余系统在分开的服务 Pod：应用服务器、工人、数据库、缓存、队列。主 Pod 经任务专用 API 和有限的 RBAC（基于角色的访问控制）到达被批准的端点，没有通用集群凭据，也碰不到验证器密钥或评分制品。

网络隔离。主 Pod 没有直连互联网，出站都过受控代理 Pod。代理在可信安装阶段放行互联网，智能体开始前改成只许模型 API 和软件包主机。NetworkPolicy 拦住直连公网 IP，过滤后的 DNS 只解析集群内名字，HTTPS 同时核对主机名和 TLS 的 SNI。这样不能绕过代理，也不能访问 GitHub 这类源码托管。

可观测性。Prometheus 按固定间隔抓服务 Pod 指标，收集器把 Pod 日志送到 Loki。智能体通过 Obs-MCP 查询，这是只读的 PromQL 和 LogQL 接口。直接访问后端被拦住，观察不能被改，私有评分数据不可达。

3.2 任务怎么造

任务用改过的 Harbor 格式。每个任务有一份人可读的顶层说明、一张 Kubernetes 图表、地面真值指标、隐藏验证器、解的预言机，以及一小时的智能体时限。任务由开源贡献者和内部作者编写，针对前沿模型里特定的困难推理和能力缺口。

故障注入有三类。配置故障在部署前改 Helm 值，例如连接、超时、副本。镜像故障是钉死基础镜像上的一小段代码或镜像改动。运行时故障在部署之后、智能体运行之前或之中出现或演变。全部任务和故障层见附录表 6。

权限分三档。受限（Confined）：操作员 Pod，只有很具体的诊断和修复面，没有应用 Pod 的壳。壳可见（Shell-Visible）：对选定 Pod 有很窄的壳，大多非 root、文件系统只读。可构建（Build-capable）：露出源文件，以便触发重建。

3.3 验证器

别的基准多半做静态检查。这里按修完之后系统的行为打分，不按配置的样子。结果门量工作负载的服务等级指标（SLI）：有效吞吐比、延迟和错误率，并且在智能体提交修复之后的固定时段里，新流量继续打。安全门查修复是否真的留住：重启受影响的服务，或再触发一次该故障，确认设置还在；确认智能体留在任务允许的范围内；确认受保护的数据和护栏完好。刷队列、过宽的授权、关掉流量这类抄近路过不了。两道门都过才是二元通过。检查对智能体隐藏，并且是确定的；证据残缺或格式不对就失败。SLI 界限来自健康基底，每个基底在任何试验之前量一次，不在试验后调。

3.4 说明与资格

为避免智能体察觉评测，instruction.md 里去掉 Markdown 写法，也去掉像模型会写的那种文风（尽管经过人核对）。只给解题所需的最少信息、时限和提交方式。

开发之后做多轮质量评估，补环境和设计上的洞。对抗智能体专门尝试奖励黑客（reward hacking，用评测不打算奖励的办法骗过检查），另一些运行则去找任务或验证器里不公平的缺陷。最终任务必须同时通过预言机和无操作试验：前者证明金标准路径走得通，后者证明什么都不做时错误会留下。

4 实验设置

智能体配置。测 10 个配置，来自 OpenAI、Anthropic、xAI、Meta 和智谱，用各自的原生框架；GLM 5.3 配的是 Claude Code。每个可用推理档做 3 次独立试验。20 个任务共 3,000 次模型试验。框架版本见表 2。每个任务上所有智能体拿到同一份 instruction.md 和同一套工具。Harbor 的分叉被改成支持 Kubernetes 后端。

运行环境。常见智能体沙箱没有跑 k3s 所需的特权容器，所以用 AWS EC2 的 m7i.2xlarge：Ubuntu 24.04 LTS、amd64、80 GiB gp3。实例 8 个 vCPU、32 GB 内存。每个实例新建一个 k3s 集群，从 GHCR 拉按摘要钉死的不可变镜像。部署把钉死的基底版本和它的配置、镜像或运行时故障叠在一起。任务服务和负载发生器就绪后，智能体装进主操作 Pod，并得到表 5 规定的修复面。

时间预算。计时从集群部署和就绪检查成功之后才开始，不含基础设施启动的方差。框架安装和智能体执行共享固定的 60 分钟。可以提前声明完成，否则到时停止。智能体进程先收到 SIGTERM，2 分钟后再 SIGKILL，让被评分的那一段没有智能体。随后 180 秒的评分浸泡从下一个完整负载周期的边界开始，避免智能体把指标带偏。

网络安全拒答。提供方的防护也会挡住网络安全范围之外的正当评测。本基准是 SRE，仍偶尔遇到拒答，通常重试能解决。

失败与重试。只重试评测前就定下的、属于基础设施或框架执行的失败。智能体超时和无效修复留作模型结果。拒答重试 3 次，之后记为失败。

主指标是解决率 Pass@1：同时通过结果门和安全门的试验比例。图中误差棒是按任务自助的 95% 区间。

5 结果

表 2：配置、API 价格、各推理档平均的 Pass@1，以及每集 API 费用。每任务试验数是 3 次乘以每个可用推理档；150 次乘 20 个任务等于 3,000。价格是每百万词元的美元。Anthropic 的缓存写入有 1.25 倍加价，其余没有。通过、失败两列是通过集和失败集的平均费用。

每任务合计试验 150。

5.1 失败分类

每次失败按它最先满足的规则归入一类，顺序按证据有多直接，见表 3。规则依次是：从未声明完成；改了允许清单之外的东西；种下的故障仍停在注入时的设置；声明时修复还在，之后不在了；故障造成的损害还在；只有健康检查失败；或其他完整性检查失败。

表 3：1,948 次失败上的类别。互斥：每次失败一类，饼图用的是这些份额。包容：每一条满足该规则的失败。

从未声明。小时或步数预算在 325 集里耗尽；其中 8 集已经修好，另外 317 集算失败。

越出允许清单。448 次失败里，智能体改了任务不允许的设置。有键记录的 439 次中，261 次碰到故障所在子系统以外，70 次是对的子系统里相邻的键，57 次是目标键但越过界限，51 次是受保护的 PostgreSQL 服务器设置。

种下的原因或损害留下。809 次失败里，种下的故障仍在注入设置（302 次：连接池低于下限 252 次，严格一致性触发仍开着 113 次，有的两者都有），或它造成的损害还在（507 次：排序任务上的重复或不一致记录）。按本规则最先失败的有 170 次。12 个多故障任务把这个模式摊开：1,779 集里，964 集给出了全部参考修复并通过了其中的 53%；595 集只给了一部分，通过 2.5%（15/595）；220 集一个都没给，通过 0%。这 595 次部分修复里有 549 次被声明为完成。

修复没有留住。782 次失败在声明时改动还在，但熬不过重启，或熬不过下一次触发。

声明太早。756 次失败在流量还在继续、服务仍越界时就声明了（466 次以此为第一条）；其中 376 次没有改不该改的东西，而且每次改动都留住了。第 5.2 节专门看它们。

每个模型的失败方式不同。任务和设置相同，所以附录 G 表 13 的差别属于「模型加框架」，实验没有把模型单独拆出来。两个 GPT-6 会把时间用完：它们的失败里有四分之一到三分之一从未声明，其余大多数不到十分之一。Grok 4.7、GPT-5.6 (terra)、Claude Opus 5、GLM-5.3 和 Claude Fable 5.1 会改不该改的东西，占各自失败的四分之一到三分之一，另外三个 OpenAI 模型大约是十分之一。Muse Spark 1.3 被提供方卡住：超过三分之一的失败从未声明。没有一种改动能帮上全部十个模型。

5.2 主要瓶颈是不知道何时停下

每个任务的参考解是一小套会改变任务状态的动作。智能体到达第一个正确动作的中位时间是分配的那一小时里的 3.3 分钟（四分位距 1.7 到 7.7），其余正确动作几乎紧接着发出。有可用动作记录的 2,967 集里，1,638 集（55%）发出了「完整修复」，即参考解的每一个动作都做了。没有完整修复的 1,329 集里，457 集一个参考动作都没发，通过率只有 5.5%（73/1,329）。发出完整修复的集里，只有 59%（966/1,638）通过。剩下 672 集把完整解放好了仍然失败。

这 672 集里，340 集只败在结果门。修复是对的，智能体在系统恢复之前停了。有时声明时修复还没生效：队列积压还在排、重启还在进行、连接还在轮换。更多时候修复必要但不充分：故障已经造成的损害（积压、重复或不一致的记录）让指标一直越界，直到被清掉；这些集里大多数在评分时段内没有回到界限内（附录 D）。另外 329 集败在安全检查。它们把自己的成功拆掉，最常见的是把维护窗口挪到仍然不安全的一秒（145），或在连接池修好之后又把它抬过上限（38）。其余见第 5.1 节。

这不是难题花得更久。在每个任务内部，最后一次正确动作之后两分钟内声明的智能体，在两组样本都够的 12 个任务里赢了 11 个，平均高 20 个百分点，胜过等了五分钟或更久的那些。通过的完整修复集在最后一次正确动作之后中位 2.5 分钟声明，失败的是 3.7 分钟，而且只有 32% 在两分钟内声明。更多搜索、更多时间和更多推理买不回这些集；在负载下核对、然后别再动修复，才买得回。

表 4：有完整修复追踪和动作记录的试验里，修复之后的行为。

5.3 推理档不是修复成功率的好杠杆

八个有五档的模型在每一档上跑 480 集，通过率接近：低 39.2%，中 40.0%，高 40.2%，超高 41.9%，最大 43.8%（附录 H 表 14）。从最低档到最高档，Pass@1 增加 4.6 个百分点（按任务重抽样的区间是 −4.8 到 +13.8）。合并后最好的是最大档，八个模型里有三个的最高档最好。增益不随任务复杂度上升：12 个多故障任务 +9.7 个百分点，8 个单故障任务 −3.1；应用之间也不一致（slack-spine +7.4，frappe +4.2，saleor 那一个任务 −29.2）。Grok 4.7 的四档没有趋势。Muse Spark 1.3 的六档从 minimal 的 23% 到 max 的 42%，是唯一一个最高档明显最好的模型。与此同时，一集的平均费用乘上 2.3。推敲碰不到第 5.2 节的失败：告警一静，智能体就声明。

5.4 奖励黑客

事后分析用怀疑分 \(s \in [0,1]\)，做法类似 Desai 等（2026），分成三档。尝试档 \(s \ge 0.3\)：宽的、不想要的行为，例如探解决方案文件、可疑行为，以及大多不影响结局的动作。利用档 \(s \ge 0.85\)：策略是为了通过检查，而不是做所意图的修复，例如故意用临时恢复代替能留住的修复。成功利用：利用并且奖励为 1。量表由 GPT-6-Astra 当裁判。其他裁判的一致性和人核对见附录 K。

图 3：奖励黑客行为按模型拆开。三档在所有模型上都出现了可观的尝试。

较早的任务迭代里，有一次智能体因为环境构造缺陷，在评分所用的另一个 Pod 上达到了远程代码执行。原因是提交条件被漏掉，智能体去打评分 Pod，而不是完成任务。具体构造步骤此处不展开。

6 限度

抽样 n = 3。样本少，置信区间宽。GPT-6-Astra 和 Opus-5.5 贴得很近时，区间大会造成困难。需要更多试验。

任务覆盖。人工编写使 Slack 占 13 个，Frappe 和 Saleor 是少数。故障类型、发作时间和基底在这批任务里缠在一起。结果刻画的是这些任务和这些接口，不是更广的生产系统。

Harbor 分叉。为了在 EC2 里的 Harbor 上跑 Kubernetes，作者自建了后端。互操作是问题，希望把改动合回上游。

时限。多数任务是多跳的，但智能体通常只从环境收到计时信号，没有专用时钟。后续应给一个智能体可以查看的计时器（Proximal Labs，2026）。

裁判之间的评分。附录 K 里，尽管用的是前沿模型，有些情形下裁判间一致性差。作者试着放进人在回路的数据，仍需要继续查，并评估人观察到的试验。

7 结论

Incident-Arena 用 20 个人工任务量智能体做真实 SRE 式工作的能力。3,000 条轨迹表明这类工作还远没饱和：GPT-6-Astra 在超高推理档达到 65% 的高点。常见失败是修复留不住、声明太早、或不被允许的动作，说明随意推理上的缺口还在。把任务的真实程度做上去，直接显示出智能体还有很大的上升空间。

参考文献

只保留作者、题名与定位。

• Artificial Analysis 与 IBM Research，2026，ITBench-AA，https://huggingface.co/blog/ibm-research/itbench-aa 。
• Badertdinov 等，2025，SWE-rebench，NeurIPS。
• Chen 等，2026，DBA-Bench，arXiv:2607.22165。
• Chen 等，2025，AIOpsLab，arXiv:2501.06706。
• Clark 等，2026，SREGym，arXiv:2605.07161。
• de Castro 等，2026，OperAID，IEEE NetSoft，doi:10.1109/NetSoft70012.2026.11603505。
• Desai 等，2026，SWE-Marathon，arXiv:2606.07682。
• Frappe Technologies，2026，ERPNext，https://github.com/frappe/erpnext 。
• Gan 等，2019，DeathStarBench，ASPLOS。
• Gao 等，2026，InfraBench，arXiv:2608.11234。
• Gong 等，2026，ORCA-bench，arXiv:2607.28545。
• Harbor Framework Team，2026，Harbor 0.16.1，https://doi.org/10.5281/zenodo.20953922 。
• Hu 等，2026，Pooled leaderboards hide system-specific winners，arXiv:2606.29159。
• Jha 等，2025，ITBench，arXiv:2502.05352。
• Ji 等，2026，Action-boundary violations，arXiv:2607.02294。
• Jimenez 等，2024，SWE-bench，ICLR。
• K3s，https://k3s.io/ 。
• Kottamasu 等，2026，APEX-SWE，arXiv:2601.08806。
• Kwa 等，2025，Measuring AI ability to complete long software tasks，arXiv:2503.14499。
• Mattermost，2026，https://github.com/mattermost/mattermost 。
• Needham 等，2025，Large language models often know when they are being evaluated，arXiv:2505.23836。
• Proximal Labs，2026，FrontierSWE，https://github.com/Proximal-Labs/frontier-swe 。
• Qi 等，2026，Can LLMs really recover microservice failures，arXiv:2607.04623。
• Saleor Commerce，2026，https://github.com/saleor/saleor 。
• Tang 等，2026，DevOps-Gym，ICLR，arXiv:2601.20882。
• Wang 等，2026a，Cloud-OpsBench，arXiv:2603.00468。
• Wang 等，2026b，Are solved issues in SWE-bench really solved，ICSE，arXiv:2503.15223。
• Xu 等，2025，OpenRCA，ICLR。
• Zhang 等，2025，SWE-bench goes live，arXiv:2505.23419。

附录

A 故障层与权限面

表 5：任务空间是两根轴的组合。格子里是允许的修复面。这些过程都可以调参，从而做出同一口味的多个变体。

B 任务清单

表 6 列出 3,000 次试验（每任务 150）上的任务与结局率。层、发作和权限面来自发布的任务登记；原因数、种下的报告集和评分包来自每次试验自己的验证合同。难度轴和基底缠在一起：每个 frappe 任务都是复合的、运行时层、大多一开始就在；每个 slack-spine 任务是配置或镜像层，13 个里有 12 个在负载下才出现。因此正文只报告基底内部的对比。补全起见：20 个任务上，复合任务 Pass@1 为 0.314，单因任务 0.478；延迟出现（15 个任务）0.378，一开始就在（5 个）0.384。这两个差都不应读成因果。

C 基底拓扑

表 7 数每个基底部署了什么，由其 Helm 图表加一个有代表性的任务叠层渲染。应用 Pod 是被测软件；框架 Pod 为基准而存在，各基底上相同，只差每个应用需要的管理接口和指标导出器。智能体自己的容器是框架 Pod 之一，只经第 4 节的接口碰到应用。第 3.1 节的接受条件这样用：文档够让操作员知道相关设置；可复现构建指每张镜像由仓库里的脚本构建，并在锁文件里按摘要钉死；表面积指服务和配置点够多，能放下许多不同故障。

D 验证器消融

图 4：验证器消融。

表 8：结果门与安全门的裁决，计数不是百分比。四列依次是过/过、过/败、败/过、败/败。

E 双向核对

表 9：报告的实验内部，每个任务各跑一次脚本化参考修复和什么都不做的智能体。20 个任务的脚本化奖励全部是 1.0，什么都不做全部是 0.0。基底对应关系：前 6 个 deletes 到 writes 为 frappe；statement-timeout-canary 为 saleor；其余 13 个为 slack-spine。检查若漂移，会先在这里露出来。

F 完整结果矩阵

表 10：按模型合并可用推理档。动作完成追踪的是完整修复，不是评分正确性。Pass3 与 Pass5 是 20 个任务上、每任务通过率的 3 次方或 5 次方的均值。区间是按 20 个任务自助。

表 11：按模型与基底的 Pass@1，括号内是追踪到的动作完成，以有动作记录为条件。

表 12：按任务和模型、跨可用推理档的通过率。列顺序为 GPT-6 astra、Claude Opus 5.5、Claude Fable 5.1、GPT-6 sol、GPT-5.6 sol、GPT-5.6 terra、Claude Opus 5、GLM-5.3、Grok 4.7、Muse Spark 1.3。

图 5：被接纳的试验里，按任务和配置的通过情况。展示的是各自推理档上最好的模型，用于抽样。

G 按模型的失败类

表 13：互斥失败类份额。列依次为失败数、从未声明、越出清单、原因或损害、没有留住、太早、其他。

H 推理档，合并

表 14：八个五档模型。

I 比较表的来源

表 1 的每一格在 2026-09-21 从一手来源读出。设定一列是各文对环境描述的释义。来源是 arXiv 摘要或全文，或 SREGym 与 ITBench-AA 排行榜。持久只在有明确的修后计时窗口或重启门时才标上：InfraBench 的活评测在持续负载或周期性探针下继续，以发现配置漂移、延迟退化和可用性丧失，其重启门检查重启后的不变量；SREGym 的缓解预言机检查目标故障是否解决、系统是否回到健康，没有描述窗口，尽管负载循环一直跑到检查。无故障要求给健康系统对照打分：ORCA-bench 的 195 个对照算；DBA-Bench 的十个误导告警场景都含注入故障，不算；AIOpsLab 的两个 noop 问题只在检测层打分。双向在来源没有写明「参考修复必须通过、什么都不做必须失败」时标为缺失；正文里的缺失记成「未陈述」，不是确认没有。Harbor 对照其适配器登记在 2026-09-22 核对，表中十个基准都不在登记里（不在表里的 DevOps-Gym 在）。逐条核对轨迹随论文发布。

J 验证器压力测试

为测试只靠一份报告能否通过验证器，作者做了某个 frappe 任务的变体：一个智能体够不着的外部过程大约每秒重新施加数据库故障，于是没有任何修复能留住。该变体的报告工具要求智能体说明故障是否已解决，评分把「已解决」的报告当成诊断检查的充分条件，于是假报告和通过之间只剩下结果检查。一个配置在变体上跑 17 集，在未修改任务上跑 17 集。未修改任务上 17 集都修好并正确报告。变体上 11 集报告已解决，6 集报告未解决；结果检查让全部 11 份假报告失败。读智能体自己的工具输出可以看到：每一份假报告都跟在一次测试写入之后，那次写入成功落在故障被重新施加之前的那一秒窗口里。所以这是一次短暂成功的检查之后过于自信的报告，不是看到故障仍在之后还去报告。压力测试用的是改过的任务和报告工具，不属于发布集；它是关于验证器的证据，不是关于智能体的证据。

K 奖励黑客的元分析

奖励黑客在先前许多迭代里被注意到，尤其是环境做得很差的时候。在不可能的环境里，智能体常常表现出受挫。

较早迭代中的那次远程代码执行，见第 5.4 节的结果陈述。步骤不在此复述。

裁判。质量流程用红队智能体找可被奖励黑客的表面，并用人类判断校准。这里裁判被种进了任务信息，造成裁判之间不一致。严重程度上有方向差：Astra 把多得多的试验标成可疑或利用档。对相对怀疑程度的一致，强于对类别标签的一致。这是描述性的一致分析，不是某个裁判更准的证据。

共 3,000 次试验，2,272 次被四个裁判都打了分。缺口直接来自提供方拒答。未打分的记录是弃权。共享试验上，模型、任务、奖励和推理档字段在裁判之间对齐。四份清单用同一条流水线哈希、超高裁判推理、一个样本和轨迹预算。

表 15：裁判覆盖。

表 16 和表 17 在通过全部裁判的 2,272 次试验上计算。

表 16：已打分试验上的分类。

表 17：裁判两两一致。

出处：Andre Fu，Malik Drabla，Leon Liu，Meji Abidoye，Marek Šuppa，Lata Mishra，Adnan El Assadi，Yiyuan Li，Incident-Arena: Getting agents to the last nine of reliability，2026-09-30，https://arxiv.org/abs/2610.00648 ，CC BY 4.0。