9 月 3 日，马里兰大学团队发布漏洞修复基准 PatchBench。它没有再问“Agent 能否让给定的崩溃样本停止报错”，而是追问两个更接近安全工程的问题：同一漏洞的其他触发输入是否也被消除，正常输入的行为是否仍与正确修复一致。在 213 个 C/C++ 任务和 11 个 Agent 配置上，单一 PoC（Proof of Concept，漏洞触发样本）通过率平均为 83.1%，同时通过安全与语义验证的完整解题率只有 45.3%。
这组结果的意义不是“所有漏洞修复 Agent 的成绩都虚高 1.83 倍”。1.83 来自论文表 2 中 11 个配置的宏平均比值，即 83.1% 除以 45.3%，只适用于 PatchBench 的任务筛选、预算和验证器。更重要的变化是：一旦评测从“停止崩溃”转向“修复根因且不破坏功能”，分数不只下降，Agent 的相对排序也会改变。
单一 PoC 奖励的是最短止损路径
此前的 SEC-bench 把真实 C/C++ 漏洞打包进可复现容器，给 Agent 代码仓库、Sanitizer 报告、PoC 与构建命令；补丁能编译，并让原 PoC 不再触发相同内存错误，就算通过。这个口径容易自动化，也能确认 Agent 至少改变了故障表现，却无法判断它修的是原因还是症状。
PatchBench 给出的 mruby 案例把问题讲得很具体：错误发生在编译器的参数打包逻辑，越界读取却在虚拟机侧爆发。正确补丁应修正编译阶段的条件；Agent 如果只在虚拟机崩溃点加类型检查，也能挡住当前 PoC，但同一畸形状态仍可从其他路径触发，并可能把显式崩溃变成静默错误。
这种捷径不是个案。论文称，在 SEC-bench 上，Codex + GPT-5.6 Sol 生成的补丁有 81% 修改了崩溃栈内函数；即使开发者补丁位置不在崩溃栈内，仍有 64% 的 Agent 补丁落在栈内。PatchBench 因此只保留参考修复位置远离崩溃栈的任务，并要求补丁到达轨迹与崩溃轨迹的函数集合 Jaccard 重叠不超过 0.5，迫使 Agent 离开报错点追踪上游状态。
PatchBench 把“修好”拆成安全与语义两道门
基准从 ARVO 的历史漏洞出发，把漏洞反向移植到同一项目较新的可用提交，再用变量重命名、循环变换、操作数交换和结构重写等方式改变补丁位点。作者随后逐题审计参考补丁，丢弃没有真正修复根因的样本，并移除与漏洞无关的改动，最终留下 32 个项目、16 类 CWE 的 213 个任务。
验证器先围绕原 PoC 做定向模糊测试，再做常规非定向模糊测试，每阶段运行 10 分钟。前者沿原始利用路径探索附近分支，中位数每个漏洞产生 33 个新 PoC；后者扩大代码覆盖，中位数再贡献 4 个。Agent 补丁必须让整个崩溃语料库都不再触发目标 Sanitizer 错误，才算通过安全验证。
语义验证再检查三件事：良性输入不能引入新的 Sanitizer 错误；程序级输出状态要与参考修复后的仓库一致；参考仓库能够通过的项目测试，Agent 补丁也必须通过。这里的输出状态不是某个局部变量，而是解析结果、解码值、生成文件或 API 返回值等程序可观察行为。
这一步解释了大部分分数落差。11 个配置的输出状态检查平均通过率为 75.5%，项目测试为 79.9%，良性输入 Sanitizer 回归则有 95.7%。移除输出状态检查后，完整解题率平均上升 8.1 个百分点。作者人工复核 Codex 中 18 个“只因输出状态失败”的补丁，认为它们都没有正确修复漏洞，而不是被检查器误杀。
头部三个通用 Agent 配置都能通过超过 97% 的原始 PoC，但完整解题率分别只有 59.2%、58.2% 和 56.8%。OpenHands + GPT-5 的 PoC 通过率为 96.2%，按该指标排第四，完整解题率却是 42.3%，降到第八。单一 PoC 因而不仅抬高绝对分数，还会选错“更会修补”的系统。
25% 的“记忆补丁”只能当作相似性信号
PatchBench 还试图处理公开历史漏洞带来的训练数据污染。作者提出 DiffBLEU：既比较补丁中增删 token，也比较修改位置附近的抽象语法树与数据流；注释和字面量等表面差异会被弱化。其阈值设为 0.75，在两组各 100 个 ARVO 任务上由三名安全研究者标注、校准并留出验证，论文报告验证集没有假阳性，漏判率为 1.1%。
按这个口径，SEC-bench 上三个仓库级 Agent 的高相似补丁比例平均为 25%，只给局部代码上下文、没有仓库访问和执行反馈的对应模型平均为 11%。但高相似只能说明 Agent 复现了与历史开发者补丁相近的结构，不能证明某段补丁存在于模型训练集，更不能证明 Agent 没有独立推导出同一种修法。论文也承认，专有模型训练数据不可见，因此“记忆”是一个代理指标。
漏洞移植与代码变异后，三个代表性 Agent 在 PatchBench 上被 DiffBLEU 标记为高相似的比例降到 0%、1.4% 和 0.9%。这说明变异确实改变了相似性分布；它是否同时保留了真实漏洞的自然性，以及 0.75 阈值能否跨项目、语言和模型稳定工作，仍需要独立复现。
更严格的验证仍不是生产证明
PatchBench 的证据上限很清楚。它只覆盖 C/C++、16 类 CWE 和 32 个开源项目；11 个配置大多受每题 5 美元预算限制，Atlantis 的四节点总预算为 20 美元，不能与其他系统做严格成本对比。论文称把三个代表性 Agent 的预算提高到 25 美元后，解题率很快停滞，说明本组实验的主要瓶颈不是 token 预算，但这不能外推到其他工具链或任务类型。
验证器本身也会漏错。作者人工检查后发现，Atlantis 与 Codex 中分别有 6.8% 和 7.1% 的“通过补丁”仍部分保留根因，因为有限输入没有覆盖到侵入式修改影响的路径。生产环境也不存在现成的“参考修复仓库”作为行为预言机，只能退而比较修补前后的行为；而正确安全修复有时本就应该改变旧行为。
截至发稿，论文列出的 GitHub 代码与基准仓库仍无法公开访问，因此 213 个任务的清单、逐任务结果和 67 个“所有 Agent 均未解决”任务的 CWE、项目与依赖分布尚不能独立核查。这个限制比再报一个总分更重要：没有任务级数据，就无法判断难度究竟来自跨函数根因定位、构建依赖、验证器过严，还是少数项目集中拖累。
不过，PatchBench 指出的方向已有独立证据。Meta 的 AutoPatchBench 在 136 个 C/C++ 漏洞上加入模糊测试与白盒差分测试后，也发现大量“能编译、原崩溃消失”的补丁无法保留正确行为；其 44 个补丁人工样本还显示，自动差分测试会放过部分错误补丁。AIxCC 的系统化复盘同样报告，Claude Code 与一个专用修复器中，分别有 37.7% 和 45.6% 的自动通过补丁在人工复核时被判为语义错误。任务集和验证方法不同，数字不能横向比较，但三组研究指向同一测量缺口。
对评测设计者，最低门槛应从一个“是否还崩溃”的布尔值，升级为原 PoC、相关 PoC、良性输入回归、可观察输出与项目测试的分层成绩；对准备把修复 Agent 接入 CI 的团队，自动通过只能触发下一轮审查，不能直接等同可合并补丁。接下来最值得观察的不是 PoC 通过率还能涨多少，而是 PatchBench 何时开放任务级数据、独立团队能否复现验证结果，以及同一套门槛能否迁移到 Java、Rust、Web 漏洞和配置错误。