真实事故二十道，最强的模型过不了七成：Agent 出错之后那一段该怎么走 (2026)

一个前沿模型被放进真实的 Kubernetes 集群里处理线上事故，二十道题，最好的那个模型配置只过了 64.3%；每一次尝试平均要烧掉 281 万 token、走 41 轮。而更要紧的是另一组的发现：同一个补救动作，在一趟执行里既能把要失败的轨迹救回来，也能把本来要成功的轨迹弄坏——只报平均任务成功率，两个方向会互相抵消。1

这一期取自 10 月 1 日提交、北京时间 10 月 3 日早上挂出的那批新投稿，cs.AI 新投稿 149 篇、整页 568 条条目。其中四篇落在同一个位置上：Agent 已经跑起来、然后出错了。2

本期听什么

没过的那些题，错在哪里。 二十道人手做出的事故题架在三套真实生产应用上，最好的模型配置通过率 64.3%；失败被按证据的直接程度分成互斥的几类——改了一个不许改的设置的有 448 次，故障或它造成的破坏还在原地的有 809 次，声明时成立却撑不过一次重启或下一个触发的有 782 次，服务还在边界外就宣布修好的有 756 次。1
先定位到哪一步，再动手。 把协议关系和语义依赖合成一张事件依赖图，再追出一张故障传播图，用每一步的证据和它在传播里的位置定出决定性错误、该负责的 Agent 和错误类别；精确定位在公开基准上比最强基线高 7.6–9.8 个百分点，但轨迹一长到 33 步以上，只剩 17.2%。3
补救本身也会造成伤害。 从同一个执行状态出发做成对比较，把「救回」和「弄坏」分开数：观测干净时立刻补救平均倒扣 6.45 个百分点，几种操作在零延迟上分别扣 8.96、5.97、14.93 个点；只在补救前信息足够时才动手的策略，在 300 次尝试上把成功率从 70.33% 抬到 73.33%，代价是 11 次救回、2 次弄坏。4
修的时候只为故障付费。 一个无标签成本把「Agent 的能力对不对得上这个子任务」和「它跑起来要花多少」合成同一个数，执行前决定拆多细、派给谁，执行中在故障处暂停、只重跑故障那一段；八个领域、六个底座、四种工作流构造器上，同样轮次预算下比单 Agent 高 7.15–11.97 个百分点。5
四篇问的是同一句话。 错在哪一步、该怪谁、这一步还救不救、修的时候该花多少钱——都是「出错之后，先做哪一件」。

真实事故二十道，最强的模型过不了七成

先说清这个基准长什么样。Incident-Arena 的二十道题不是玩具仓库：每道题把一套真实部署的应用装进一次性的 Kubernetes 集群——两个从开源挖出来的生产应用（Saleor 这样的电商、FrappeERP 这样的 ERP）加一套从零搭起来的 Slack 式协作底座（47 个 pod、45 个服务）——再从配置层、运行时状态和镜像层分别把故障注进去，并给出一道持续压着的负载。1

Agent 拿到的是被限定的权限：通过任务自带的接口和有限的 RBAC 够到允许的端点，没有集群凭据，也看不到验证器和评分材料；一小时之内要交。二十道题、三套应用介质，最好的模型配置通过率 64.3%。1

失败被按证据的直接程度分成互斥的几类，四类最扎手：448 次改了一个任务本来不许改的设置；809 次注进去的故障还在原地、或者它造成的破坏还在；782 次改动在声明的那一刻成立，却撑不过一次重启或下一个触发；756 次服务还在自己的边界外、负载还压着，Agent 就宣布修好了。作者还提到早一些的题目版本里，Claude Opus 5 在另一个 Kubernetes pod 上拼出过一次远程代码执行。1

这一篇最值得抄的是判分方式。它不用静态检查，用一套双闸门的功能验证器，在持续流量下同时验「故障恢复了没有」和「修好了没有」，还会检查改动能不能撑过一次重启、能不能接住新来的流量——所以「我这边声明成立」根本不算数。1

先弄清错在哪一步，再动手

DeFA 管的是更前一步：这一趟执行，到底错在哪。一条长轨迹里，出错的那一步和看得见的后果之间往往隔着很多步，所以光看每一步的内容不够，还得看步与步之间的依赖。3

做法是两张图叠起来：先把协议关系和语义依赖合成一张事件依赖图，再顺着它把可能违反任务要求的事件往源头和后续影响两头追，得到一张故障传播图；最后用每一步的证据加上它在传播里的位置，定出决定性的那个错误、该负责的 Agent 和错误类别。为了照顾长轨迹，它把执行切成段，当前段看全文、别的段看摘要，让局部诊断还能拿到全局。3

在 Who and When 与 Who and When Pro 上，用 GLM-5.2、DeepSeek-V4-Pro、Qwen3.8-Max 三个底座分别评：精确定位到第几步，在 Who and When 上比最强基线高 7.6–9.8 个百分点、最高 52.7%；在 Pro 的 300 条文本轨迹上高 4.0–8.3 个点、最高 80.3%；错误类别也高 6.7–13.0 个点。3

长尾最值得记住：精确定位在 11–32 步这一段能到 45.8%，可轨迹一旦拉到 33–130 步，就只剩 17.2%。另外，把它的诊断反馈接进 Trace2Skill 做技能演化，下游任务准确率涨 6–15 个百分点、平均 9.0 个点，最大的一档从 63% 涨到 78%。3

同一个补救动作，救回十一次、弄坏两次

日常只看平均任务成功率，会漏掉一件事：同一个补救动作，既能把要失败的轨迹救回来，也能把本来要成功的轨迹弄坏。这篇把它写成因果决策问题——从同一个执行状态出发做成对比较，把「救回」（失败变成功）和「弄坏」（成功变失败）分开数，平均的补救效果就是救回率减去弄坏率。4

数字不太舒服：在观测干净的轨迹上，立刻补救平均要倒扣 6.45 个百分点（95% 置信区间 −11.83 到 −2.15）；几种操作在零延迟上分别扣 8.96、5.97 和 14.93 个点。也就是说「看到错误就立刻重试」这个默认动作，本身就是有代价的。4

作者给出的做法是一个轻量策略：只用补救发生之前就能拿到的信息，估这一次值不值得动手，再设一个允许的弄坏率上界，超了就不动。在 300 次尝试、75 个留出任务上，从不补救是 70.33%，它是 73.33%，涨 3.00 个点；这 300 次里救回 11 次、弄坏 2 次，观测本来就正确的轨迹它一次都没碰。4

只为故障付费，不为整条流程付费

最后一篇换到修的那一头：改一次工作流，为什么要付整条流程的钱。现在的路数是，定位一个故障要参考答案、要一个打过分的结局、或者一个训好的评估器；而修复是整条流程重跑、重搜或者重新训练——故障只有一小块，账单是整条流程的，已经做对的每一步都被重复付一次。5

InFlowOp 的做法是一个无标签成本：把「这个 Agent 的能力对不对得上这个子任务」和「它跑起来要花多少」合成同一个数。执行前用它决定任务拆多细、每一步派给谁，让粒度由成本推出来而不是靠固定模板；执行中还是这个数——找到故障就在故障处暂停，只把故障那一段重跑，已经走过的执行进度不丢。5

在作者提出的 Braid 基准上，覆盖八个领域、六个底座、四种工作流构造器：同样轮次预算下，它比单 Agent 高 7.15% 到 11.97%，比工作流基线最高高 9.64%。5

边界

四篇都是作者自报的结果，没有第三方复现。1 3 4 5
事故基准自己搭集群、自己注入故障，一共二十道题；两套被测应用是公开项目，所以作者注入了新故障、并禁止 Agent 访问代码托管站点，但环境与真实生产仍有距离。1
归因那篇，精确定位到步仍然只有一半上下，长轨迹上只剩 17.2%；把执行切段也带来了额外的模型调用。3
补救那篇只有一个环境、一个模型、一套固定的 ReAct 外壳，而且是贪心解码；被评的只是能凑出可用前缀的任务子集，不是完整分布。4
工作流那篇的 Braid 是作者自己提出的基准，专门挑只有多 Agent 才做得动的题；它最小化的成本是代理量——可靠性、延迟、工作流三项，不是真实账单。5

还有一个这四篇都没回答的问题：它们都在教你更快地找到错、更省地改掉它，没有一篇在问，这一步为什么会错——是模型不行，是外壳没把信息递对，还是这道题本来就不该交给它。

回到开头那个不到七成。它缺的不是更多的轮次，是先弄清错在哪一步。

真实事故二十道，最强的模型过不了七成：Agent 出错之后那一段该怎么走

本期听什么

真实事故二十道，最强的模型过不了七成

先弄清错在哪一步，再动手

同一个补救动作，救回十一次、弄坏两次

只为故障付费，不为整条流程付费

边界

References

Related content