2026 年 10 月的软件工程论文里，生产事故响应方向有两篇工作值得关注。Meta 公开了 RCA Agent 在生产环境中的运营结果，Incident-Arena 让 Agent 在临时搭建的 Kubernetes 集群上修复注入的故障，并用确定性的验证器打分。围绕 Harness 的几篇工作测了它交给模型的信息在哪一步失真，同一个模型换一个 Harness 之后的成绩、失败形态和成本差多少，以及运行到一半出了问题该干预还是等它自己恢复。本月还有一组工作把 Agent 的自我改进做成了完整回环，Harness 和策略交替更新，并检查这样得到的增益有多少经得起独立验证。
本文收录 2026 年 10 月 1—31 日的 19 篇新工作。
一、生产事故中的诊断与修复
生产环境里，同一个症状往往对应好几种可能的原因，值班人员要在指标、变更记录和依赖状态之间逐一排查。Diviner 是 Meta 在推荐与排序基础设施上运行的 RCA Agent，累计支持了数千起事故的调查，其中数百起属于高严重度。它的定位是顾问，只给诊断建议，缓解操作由响应人员执行。
这套系统对证据的要求很严。历史事故的复盘被提炼成紧凑的 failure signature，检索出来的先例只用来提出假设，要用当前的指标、变更、配置或依赖状态验证之后才能写进结论。工具返回的结果里，返回数据和有效的空结果算作证据，空结果的效力限于查询覆盖的范围，被拒绝、超时或后端出错的查询被排除在证据之外。
论文分开报告了诊断质量和对事故处理的影响。在有评分的调查里，Diviner 命中已复盘因果机制的比例是 45%，把范围收窄到正确子系统或机制的比例是 60%，最终结论的中位耗时约 15 分钟。在已经接入定制 skill 和 workflow 的队列中，有 Diviner 协助的事故从检测到缓解的时间低约 52%（95% CI 45.7–57.9%），这组数字来自观察性比较，作者列出的影响因素包括采用情况、事故构成和人员配置。受控回放使用相同的告警输入，Diviner 加 Claude 相比单独使用 Claude，命中率高 11 个百分点（95% CI 3–20），平均墙钟时间少 52%。
Incident-Arena 评测的是 Agent 自己动手修复生产故障，这时修好的标准需要定得很具体。它的 20 个任务把真实应用部署到临时的 Kubernetes 集群上，注入故障并持续施加负载。验证器是确定性的，设了两道门。第一道在 Agent 提交之后继续用新流量测一段时间的 goodput、延迟和错误率；第二道重启受影响的服务或再次触发故障，确认修复仍然生效，并检查改动是否留在任务允许的范围内。清空队列、放宽授权、关掉流量这类捷径会被第二道门拦下。
10 个 Agent 配置共跑了 3,000 次试验，最好的配置 Pass@1 是 64.3%。Agent 找到正确动作的速度很快，首个正确动作的中位时间是开始后 3.3 分钟。在有动作记录的试验里，55% 下发了完整的参考修复，这部分的通过率是 59%，余下 672 次方案齐全却仍然失败，其中 340 次是 Agent 在系统恢复之前就停了下来，329 次是 Agent 把已经修好的地方又改坏了。完整修复之后停手的试验通过率是 69.6%，继续改动的是 53.0%。作者据此把这批任务上的主要瓶颈概括为知道何时停止。
二、Harness 输出的有效性
Agent 看不到系统本身，它看到的材料来自 Harness。评价一个 Agent 时常看的两个数字是上下文窗口的大小和最终答案的正确率，这一节的三篇工作测的是中间的环节，工具输出在送达模型之前丢掉了什么，仓库里的旧文档和代码打架时模型听谁的，工具带着错误返回或者悄悄返回错值时模型能不能察觉。
Context Is a Pipeline, Not a Window 测的是工具输出被裁剪的比例。作者的 Agent 通过读取 Linux 内核 trace 诊断注入的故障，720 次运行里最大的一个 prompt 只用了窗口的 5.75%，11,189 个工具结果中却有三分之一在送达模型之前被裁剪，每一个被裁的结果都成了损坏的 JSON。
损失很有规律。Harness 按固定长度切 JSON 文本，被切掉的总是排在后面的字段，同一批结果里一个字段的到达率只有 4.7%，相邻的另一个字段是 99.3%。故障证据落在哪个字段，取决于出故障的进程是在 trace 期间启动的还是此前就在运行，诊断准确率也沿着这条线分成了两档。随后的受控实验推翻了作者事先写下的预测，把键的顺序反过来以后，故障进程所在的列表每次都被切掉，Agent 仍然全部答对，因为这个进程是 trace 里最吵的一个，会出现在 Agent 自己构造的排序表前几行。裁剪的代价先体现在工作量上，工具调用多出 43%，计算次数翻倍。修正后的结论是，裁剪只在 Agent 缺少第二条通往答案的路径时才损害准确率。在一条生产规模的 trace 上重复回放，修复裁剪规则后 6 次运行里有 3 次说对了被限流的服务，保留缺陷时 5 次全错。作者还检查了七个 Agent 框架的裁剪代码，langchain-core 和 smolagents 同样按位置裁剪工具输出。
Stale Instruction Files Override the Code in Coding Agents 研究另一种失真的输入，CLAUDE.md、AGENTS.md 这类指令文件通常写一次就很少再改，代码却一直在变。作者构造了 40 个 Python 小项目，每个项目的指令文件要求一种约定，现有代码一致地使用另一种，例如文件要求用 print 输出信息，所有模块用的都是 logging。Claude Code 和 Codex CLI 分别给每个项目添加一个功能，共 320 次运行。
不加干预时，90.1% 的选择跟随了过期的文件，跟随现有代码的占 4.2%。Claude Code 在 80 次运行里有 79 次在最终回复中指出了文件与代码的冲突，随后仍然照文件写。Codex CLI 有 20 次改写了既有模块去迁就文件，恢复项目原来的测试之后，其中 17 次测试失败。
修复办法是在用户级指令文件里加一句话，内容是仓库的文档与现有代码不一致时遵循现有代码的约定，并在最终回复里指出每一处不一致。加上之后，跟随代码的选择升到 91.4%，160 次运行的测试全部通过。作者把原因归到 instruction hierarchy 上，指令文件以指令的身份进入上下文，代码以工具输出的身份到达，模型被训练成指令优先于工具输出，这个排序原本用来防御提示注入。
工具出问题还有第三种样子，正常返回、内容却是错的。Loud Failures, Quiet Failures 在 BFCL 的可执行环境上注入了四种故障，超时、工具缺失和参数结构变更会返回错误字符串，第四种让调用成功、返回内容被改动的值。实验覆盖六个模型，共 1,920 次试验。Agent 对带报错的故障检测率是 91.3%，对内容被改动的返回值是 58.8%。在系统提示里加一句要求每次调用后检查结果，后一类的检测率从 60.6% 变成 59.6%。
这篇论文测量恢复的方法值得关注。恢复的判定标准是环境终态与同一模型无故障运行到达的终态一致，而同一任务两次无故障运行的终态一致率本身只有 63.3%。以这个波动为参照，四种故障里只有工具缺失明显拉低了恢复率，其余三种落在运行间波动的范围内。作者给部署方的建议是把校验放在工具返回值进入 Agent 上下文的位置，并用多次无故障运行作参照来评估故障的影响。
MCP-Injector 要解决的是故障注入的配比问题，各类故障按什么比例混合才接近实际。作者对 1,774 个 MCP server 仓库的 57,240 条 issue 和 PR 线程做分类，用故障报告的分布来校准注入画像，其中显式错误占 71.2%，静默的内容类错误占 19.1%。按这个画像注入后，两个 gpt-oss 模型的任务完成分（10 分制）从 8.08 降到 3.23，运行完成率仍在 88%–97% 之间。20B 和 120B 两个模型注入前后任务完成分的比值几乎相同（p=0.96），这项比较的范围是同一家族的两个模型。
三、模型与 Harness 的配对
排行榜上的一个成绩对应一组固定的模型与 Harness。本月有两篇工作把两者交叉组合起来评测，一篇面向可以自托管的轻量模型，另一篇面向前沿模型。
Pairing Matters 的出发点是自托管，团队要把代码留在自己的基础设施里，就得为轻量的开源模型挑一个 Harness。作者让 6 个开源 Harness 和 3 个轻量编码模型在 100 个 SWE-bench Verified 任务上两两组合，统一 serving、计量和评分条件。同一个模型在不同 Harness 下的解决率相差 28–44 个百分点，Harness 的排名也随模型变化。成本的差距更大，在五个迭代式 Harness 之间，同一个模型每解决一个任务的计费 token 相差 9–18 倍。
失败的形态同样随配对变化，循环或预算耗尽这一类失败在 Qwen3-Coder 的各个配对里占比从 3% 到 95%。作者建议选模型时保留几个 Harness 备选，最终按目标工作负载上的实际组合来评估。实验里每个组合在每个任务上保留一次最终尝试。
Finding the Right Fit 评测的是前沿模型，四个可配置的 Harness 与五个模型在三个基准上交叉组合，加上两组原生配对，共 66 个配置。在 Terminal-Bench 4 上，Claude Opus 5 在 OpenHands 里领先 GPT-6 Astra 7.94 个百分点，换到 PI 里落后 30.16 个百分点。原生配对的表现也随基准变化，Codex 在三个基准上都被另一个 Harness 超过。
作者读了成对的轨迹之后给出的解释是，差别通常取决于 Harness 是否把失败作为可用的反馈交还给模型。同样是一个让 GIMP 无限等待输入的脚本错误，PI 的 shell 默认不设超时，运行一直挂到 40 分钟的截止时间；openJiuwen 的 shell 有 300 秒上限，错误作为超时返回之后，模型自己诊断出原因并完成了任务。这项研究每题计一次运行，各 Harness 沿用自己的默认设置。
四、失败归因与位置基线
失败归因要在一条失败的轨迹里指出导致失败的那一步。定位这一步的难度有两头，一头在评测本身，标签的分布让不看内容的规则也能拿到高分；另一头在轨迹内部，模型在思考过程里写下的论断可能本身就是错的。本月两篇工作分别从这两侧做了检查。
Structural Baselines Matter for Agent Failure Detection and Attribution 检查的是这类评测的成绩里有多少靠位置规律就能拿到。作者在 τ-bench 上构建了 SILENT-Bench，用反事实回放确定 decisive step，即最早一个让目标状态无法达到的写操作。
实验里排在最前面的是一条完全忽略内容的规则。它永远报最后一步，在三个划分上的准确率是 0.88、0.96 和 0.67，高于论文测试的每一个学习式定位器。原因出在标签的分布上，596 次失败里只有 11.1% 存在回放可以验证的 decisive step，其余是 Agent 直接停下的失败，标签按约定取在放弃的那一步，位置自然落在运行末尾。作者把同样的校正用到已有基准上，审计了 30 组方法与基线的比较，在 5% FDR 下有 6 组超过位置基线，全部是 ProcessBench 上的数学 judge。论文建议归因方法报告 positional lift，也就是方法的准确率减去最佳位置规则的准确率，同时说明若干已发表的系统在扣除位置基线之后仍有明显增益。
From Faulty Claims to Incorrect Patches 顺着轨迹往里看。推理模型在动手之前会写下大段思考，其中关于任务的论断可以拿仓库和文档来核对。作者在 SWE-bench Pro 的 100 个实例上收集了四个开源推理模型的 400 条轨迹，把思考过程拆成可核验的原子论断，再让一个评估 Agent 在只含原始仓库的容器里逐条查证。每条轨迹平均有 191 条这样的论断，其中 11.2% 被反驳。
错误论断几乎每条轨迹都有，成功解决任务的 212 条轨迹里也有 205 条含有错误论断。Agent 之后会从仓库或执行结果里拿到证据自行纠正，最终的补丁也可能用不到那条论断。与补丁缺陷直接相关的只是少数，在未解决的轨迹里大约每 26 条错误论断中有一条。为了确认因果关系，作者把轨迹回放到提交之前，用一条用户消息纠正对应的论断，让 Agent 修改补丁后重新提交。89.0% 的修订补丁包含了针对性的修复，最终解决任务的占 11.5%。针对性修复平均占完整纠正补丁改动行数的 40.1%，其余缺陷有一部分出现在编辑代码的环节。
五、错误恢复与重启决策
Agent 执行到一半出了错，旁边的人或监控器要判断是马上介入，还是让它自己处理。When to Intervene? 为这个判断提供了基础数据。作者在 1,259 条 computer-use 和网页任务的轨迹里标注了 1,403 个错误事件，OSWorld 任务里 54.8% 的错误由 Agent 自己恢复，恢复用时的中位数是 2 步，网页任务里这个比例是 32.8%。标注到的错误全部恢复的轨迹，任务完成率是 60.0%，只恢复一部分或完全没有恢复的在 20% 左右。作者据此训练了一个在错误出现时预测能否自行恢复的模型，建议把干预优先留给预计难以自行恢复的错误。
Continue or Restart? 研究的是编码 Agent 的重启决策。设想 Agent 已经花了 20k token 调查一个 issue，监控器给当前这次尝试打了很低的成功概率，这时中止重来，之前的仓库探索全部作废。作者用 147,002 条公开执行轨迹检验这个决策，并把两种预测能力分开衡量，一种是在所有运行之间排序，另一种是在同一个任务的成功与失败尝试之间做区分。
任务本身的难度差别很大，一个只估计任务难度的预测器在前一种指标上也能拿到高分。实测正是这种情况，四个预测器的 pooled AUC 在 0.58–0.97 之间，同一任务内的 within-task AUC 都在 0.50 附近。回放实验里，按预测重启比随机重启最多高 1.98 个百分点，一直运行下去的策略在 224 个预算与阈值的组合里有 216 个同时做到解决率更高、平均 token 成本更低。这组结论对应的是冷重启，数据来自公开轨迹。
六、Harness 的自动优化与自我改进
把前面几节的条件接起来，就是自我改进在做的事。一个 Agent 跑任务、失败，失败被写成可以核对的东西，某个部件随之被改掉，下一轮再跑。这一类工作统称 recursive self-improvement，简称 RSI，改动的对象分三层。最轻的一层是提示、skills、tools、hooks 这些不动权重的外围部件，skill 自进化就落在这一层，优化器读执行轨迹改写技能库，按开发集上的表现决定留哪个版本。中间一层是模型权重，用自己产出的轨迹做后训练。最重的一层是负责提出改动的优化器本身。Harness 自动优化处在第一层，本月三篇工作分别把改动往上推了一步。
VERSE 往前推的是优化器。以往 Harness evolution 里优化器是固定的，只有被优化的 Harness 在变，VERSE 让优化器也修改自己的 Harness，并配上执行级的验证工具，用来检查草稿是否修好了它瞄准的任务、记录下来的失败能否复现。论文用了不少篇幅审计优化过程本身，在 18 次运行的日志里，优化器写明预期修好的任务在下一轮训练运行中只有十分之一通过；提交的修改累计修好 148 个验证任务，同时弄坏了 134 个，全部验证结果的变化里还有一半在重跑时无法复现。有了自我演化，优化器学会了在提交前做回归检查，81 次草稿评估里有 34 次带上了当前已经解决的训练任务，固定的优化器是 89 次里 2 次。最终成绩上，带自我演化的 VERSE 装到四个已有的优化器上，16 组比较全部高于原版，幅度在 0.6–10.3 个百分点；关掉自我演化、只保留工具时，16 组比较里有 8 组低于原版。实验中每个配置做一次演化运行。
Self-HPO 把 Harness 和权重放进同一个回环，两步交替。H-step 冻结当前策略，让它读自己的失败轨迹提出 6 个 Harness 候选，在困难任务集上选出一个；P-step 冻结选中的 Harness，用强化学习更新策略。上一轮从未解决的任务构成下一轮的搜索集，搜索目标跟着策略一起往前走。这套交替跑两轮后，Qwen3.5-35B-A3B 在 SWE-Bench Verified 上的解决率从 61.0% 升到 69.5%，比只更新权重的 RLVR 高 2.0 个点，比只改 Harness 的 Self-Harness 高 4.3 个点，平均分从 57.8% 升到 64.8%。交叉评测说明了两个部件各自的作用，把最终 Harness 套到初始权重上提高 3.5 个点，把最终权重放在初始 Harness 下提高 3.4 个点，两者一起是 8.5 个点，超过各自增益之和 6.9 个点。pass@8 从 80.0% 升到 84.8%，能力的上限也随之抬高。
MASS 把三层一起交给同一个 Qwen3.6-27B，执行者、评分者和优化者是同一个模型，回环在演化工作流和在自己生成的轨迹上做 SFT 之间轮换。12 个合成研究任务留下 8 个用于后训练，119 条教师轨迹展开成 2,435 个窗口、1,720 万个监督 token。两轮之后，学生相对基线的胜率从 53.9% 升到 69.9%，自评与外部评审的一致率从 0.73 升到 0.93，四个研究类基准上每个输出 token 的得分是基线的 1.2–1.6 倍。同一批权重搬到软件工程基准上则是另一回事，Terminal-Bench 2.0 从 37.5 依次降到 35.3 和 35.2，SWE-bench Verified 从 62.6 降到 61.8 和 61.1。消融把速度上的瓶颈指到优化器这一环，只把评分换成 GPT-5.5 带来的改善小于评分和优化器一起换，全部用初始模型的循环最终也在 12 个任务中的 11 个上取得一致胜利，差距落在改进的快慢上。
三篇工作沿 RSI 的三个位置排开。VERSE 改的是提出改动的那个器件，Self-HPO 让提出者和被改进者共用一个策略并让它随训练更新，MASS 把三层压进同一个模型。它们报出的增益都来自自建的回环，回环内的分数由被改进的系统自己产生，这正是下一节要检查的地方。
七、自我改进的增益验证
第六节三篇论文的增益都记在自己运行的回环里，验证集、评分器和轨迹由这套系统自己产出。要让这些增益成为证据，得有人从外面查一遍，本月四篇工作各查一项。
BiPA 检验 skill 自进化的增益里有多少来自真改进。它只看不改，把 skill optimizer 的接受规则重放在与 seed 完全相同的候选上，看单靠选择能报出多大的增益。三个 optimizer、三个基准、两个模型共产生 16 个学到的 skill，平均测试成功率比手写 seed 只高 0.1 个点，DeepSeek 的 9 个平均低 1.4 个点。报告出来的 dev 增益有 0.25–0.94 的概率由未改动的候选达到，只要在一次 dev 运行中胜过父代就接受的 gate 会接受 24%–41% 的未改动候选。成本也跟着上涨，输入 token 平均多 16%，其中 73% 来自多出来的轮次，只有 21% 来自 skill 文本变长。学到的 skill 覆盖了 seed 没覆盖的 57 个任务，同时丢掉 seed 覆盖的 62 个。
The Skill–Policy Co-evolution Trap 检查的是技能库的评测条件。这类方法交付一对策略和最终技能库，成绩只在这个库上报告，而部署后技能会被改写、增删。作者发现交付的库处在候选库的一个峰上，六个设置里十八个轴—设置对中没有一个内容级改写超过评测噪声，仅仅保持含义的改写就会掉点，ReSkill-ScienceWorld 上损失 10.9 个点。按最坏漂移计算，成功率比交付时的峰值低 5–13 个点，抹掉交付库相对无技能基线增益的 52%–93%。
Safety Must Survive Self-Improvement 处理的是另一种失效，验证通过了，但验证的依据过期了。它在有状态授权任务上让固定的 LLM 编辑器反复改进可执行的 Agent 部件，并用配对干预把哪次修订通过验证、哪个程序继续运行、编辑器下一次改哪一版分开记录。一次新的授权依赖让此前测过的优化全部失效之后，48 条框架历史里有 22 条仍然让同一个不安全的程序继续跑，而每一份受影响的归档里都存在正确版本。刷新分数能修好原测试集，在独立组合的测试上仍有残留失败；从共享的失败出发改初始实现，比改那一版失败的程序更容易恢复。整套验证加可验证的回滚，最终程序全部正确，同时保留 43% 以上的部署节省。
Who Verifies the Builder? 把这个问题推到最外面一层。同一个 Agent 系统既产出软件又产出正确性证据时，测试全绿的证明力要打折扣，作者提出把构建和验证分成两个平面，builder 自己的测试只算开发工件，verifier 的工件对 builder 保密，只向它提供可复现的反例，发布前必须证明什么由人来批准。预注册实验用三个有状态的小型服务和 46 个植入故障，builder 交出的程序在所有条件下都通过了可见测试和隐藏测试，比较的是各种验证方式对植入故障的检出率。builder 自己的测试检出 85.1%，同一模型在全新上下文里做独立验证检出 95.4%（Holm 校正后 p=0.006）。有两个故障把幂等键和分页游标错误地绑定到了 session，builder 每次都按规格实现对了，它的测试里却缺少对这个绑定的检查。实验里还有一段插曲，一部分 verifier 测试被计为无效，追查后发现多数出自作者自己的评测 Harness，它调用测试函数时不传参数，参数化测试因此全部静默失败，这个问题是在 builder 拒收这些反例时暴露出来的。
这四道检查分别对应一件事。选择噪声让报告的增益偏大，改写和漂移让评测条件失效，过期的验证分数让不该上线的程序继续跑，自测和独立验证之间隔着十几个百分点的检出率。VERSE 从回环内部发现了同类的现象，18 次运行的日志里，提交的修改修好 148 个验证任务，同时弄坏 134 个。回环越自主，这些检查越要放在回环外面做。
八、本月重点一览
| 方向 | 本月关注的问题 | 代表工作 |
|---|---|---|
| 生产事故响应 | RCA Agent 在生产中的诊断质量与耗时，Agent 修复故障时在哪里丢分 | Diviner、Incident-Arena |
| Harness 的输入 | 工具输出被裁掉多少，旧文档和代码打架时模型听谁的，静默错值能否察觉 | Context Is a Pipeline、Stale Instruction Files、Loud Failures, Quiet Failures、MCP-Injector |
| 模型与 Harness 配对 | 同一个模型换 Harness 之后，成绩、失败形态和成本怎样变化 | Pairing Matters、Finding the Right Fit |
| 失败定位 | 归因准确率里有多少来自位置规律，思考中的错误论断与错误补丁隔多远 | Structural Baselines、From Faulty Claims to Incorrect Patches |
| 运行时干预 | 错误能否自行恢复，提前重启是否划算 | When to Intervene?、Continue or Restart? |
| 自我改进的机制 | 改的是外围部件、权重还是优化器本身，增益怎样叠加 | VERSE、Self-HPO、MASS |
| 自我改进的验证 | 报告出来的增益有多少是选择噪声、过期分数或评测条件本身给的 | BiPA、Co-evolution Trap、Safety Must Survive Self-Improvement、Who Verifies the Builder? |
对正在使用编码 Agent 的团队，本月有三项结论可以马上用上。在用户级指令文件里写明文档与代码冲突时以现有代码为准；检查自己的 Harness 怎样裁剪工具结果；把模型和 Harness 当作一个组合来测，同一个模型在不同 Harness 下的解决率差距可以达到几十个百分点。打算让 Agent 自己改 Harness 或自己攒 skill 的团队，先把验证预算留出来，报告增益之前用重跑和未改动候选各测一遍，这两项成本都不高。