9 月 3 日，马里兰大学团队发布漏洞修复基准 PatchBench。这项测试要求 AI 智能体（Agent）既要挡住给定的崩溃样本，也要防住触发同一漏洞的其他输入，并让程序在正常输入下保持正确行为。在 213 个 C/C++ 任务和 11 个 Agent 配置上，单一 PoC（Proof of Concept，漏洞触发样本）通过率平均为 83.1%，同时通过安全与语义验证的完整解题率只有 45.3%。
将 83.1% 除以 45.3%，得到的 1.83 是论文表 2 中 11 个配置的宏平均比值。这一差距只适用于 PatchBench 的任务、预算和验证方法，不能推广到所有漏洞修复 Agent。测试还发现，加上根因修复和正常功能检查后，成绩下降的幅度各不相同，Agent 的排名也随之改变。
挡住当前崩溃样本，可能只是绕开了症状
此前的 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 离开报错点追踪上游状态。
补丁要防住相关漏洞，也要保留正常功能
基准从 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 评分，不仅会得到更高的成绩，还可能对哪种系统更擅长修复漏洞作出不同判断。
补丁与历史代码相似，能否说明模型记住了答案
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% 的自动通过补丁在人工复核时被判为语义错误。任务集和验证方法不同，数字不能横向比较，但三组研究都发现，自动测试通过后，补丁仍可能保留错误行为。
评测设计者可以分别报告原始样本、相关漏洞样本、正常输入回归、程序输出和项目测试的成绩，让读者看清补丁通过了哪些检查。准备把修复 Agent 接入持续集成流程的团队，也应在自动测试通过后继续审查补丁，再决定能否合并。接下来需要关注 PatchBench 何时开放任务级数据、独立团队能否复现验证结果，以及这套验证方法能否用于 Java、Rust、Web 漏洞和配置错误。
