EviRepair：面向可靠漏洞修复的证据驱动智能体

如何让修复过程中的证据足以支持准确的漏洞理解与补丁生成。

• 场景：仓库级自动漏洞修复要为软件漏洞生成补丁。作者称模板、程序分析与搜索方法往往难以处理需要程序语义和仓库级上下文的真实漏洞，实践仍大量依赖人工。
• 现有不足：作者称单智能体在同一流程里做分析、生成和验证，诊断证据没有专门审查就进入修复决策。已有多智能体框架直接汇总各智能体输出，生成前不核验证据一致性，也不用已验证证据做补丁验证。
• 作者的设定：成功修复不仅要改代码，还要有证据说明改动针对的是底层漏洞。待重构的证据可能不可用、不完整、有噪声或彼此不一致。
• 本文提出：证据驱动的多智能体框架 EviRepair。诊断阶段采集并审查漏洞证据，合成阶段以审查后的漏洞模型为规格生成并验证补丁。
• 任务输入：漏洞报告 R、目标仓库 P、初始证据 E0。作者称现实设定下 E0 可能只有疑似漏洞的自然语言描述。任务是重构漏洞模型并合成补丁，阻断所报告的不安全行为，同时保留合法行为。

作者按修复范式和数据集两条线讨论前人工作，并把本文放在从稀疏报告重构证据这一问题上。

传统方法与单智能体

• 传统 AVR：用手工规则、测试和历史修复生成并过滤补丁（Le Goues et al., 2012; Huang et al., 2019; Gao et al., 2021; Chen et al., 2023; Fu et al., 2022; Zhou et al., 2024）。作者称其建模能力有限，难以处理大仓库中的程序依赖和运行时行为。
• 单智能体：RepairAgent（Bouzenia et al., 2025）与 PATCHAGENT（Yu et al., 2025）结合检索、工具和执行反馈，做迭代定位与补丁验证。作者称把多种推理放进同一上下文会造成信息缠结和偏差。引言还点名 Liu et al. (2025) 与 Kulsum et al. (2024)，称其没有专门的证据审查阶段。

多智能体修复

• 解释漏洞：AutoPatch（Seo et al., 2025）与 AgenticRepair（Fu et al., 2026）用专家智能体，从代码、轨迹和仓库历史解释漏洞。
• 导出约束：VulnResolver（Zhang et al., 2026a）与 ContraFix（Liu et al., 2026a）用多智能体推理导出安全约束和修复要求。作者称解耦上下文并联合分析证据的结构，对复杂漏洞修复是有前景的。
• 引言中的批评：只针对 Zhang et al. (2026b;a)、Liu et al. (2026b) 与 Fu et al. (2026)。作者称它们直接汇总中间输出，生成前不核验证据一致性，也不用已验证证据做补丁验证。

漏洞修复数据集

• 静态代码对：Big-Vul、CVEfixes、MegaVul 对照漏洞–修复代码对评测。作者称不能确认补丁是否去掉可利用行为并保留正常功能。
• 可执行评测：Vul4J、Vul4C、VulnRepairEval 结合真实项目修订与安全证据，并用容器化差分执行加强验证。
• 信息更少的设定：PatchEval、SE-bench、CyberGym-E2E、CVE-Bench 施加不同信息约束，从纯文本描述到材料很少的 black-box。作者称证据是否可得会强烈影响任务难度和修复表现。相关工作把 Lee et al. (2025) 写作 SE-bench，实验节写作 SEC-bench。

实验基线

• 基线与基准：Codex v0.153.2 与 OpenCode v1.17.7；基准为 PatchEval 与 SEC-bench。

作者称单智能体与多智能体各有互补长短。本文研究从稀疏报告重构证据：用多智能体分工做子任务推理，并用跨证据校验去实现单智能体设计所针对的全局一致性。

EviRepair 把仓库级自动漏洞修复拆成漏洞诊断与补丁合成，中间只传递审查后的漏洞模型 M。各智能体使用独立上下文，只通过固定字段的结构化记录交换结果（Figure 2）。

问题设定

输入是报告 R、仓库 P 和初始证据 E0。作者把修复关键证据写成 E={Ereach, Erepro, Eoracle, Eboundary, Epreserve}，依次对应源到汇可达性、可执行复现、运行时观察与修后期望行为、安全边界、应保留的合法行为。漏洞模型为 M=f(R, P, E0, E)。这些分量可以缺失、不完整、有噪声或互相矛盾。补丁要阻断报告中的不安全行为，并保留合法行为。

漏洞诊断

• 假设：Analysis Coordinator 阅读报告并查看仓库，形成安全假设，每个假设给出疑似入口、汇和漏洞类别，再并行派出三个智能体。每个智能体收到报告、仓库和假设，看不到其他智能体的发现。
• 取证：Reachability Analyzer 检查攻击者可控输入能否从入口传到汇，并报告路径及沿途变换。Vulnerability Reproducer 构造可执行复现器和运行时 oracle，刻画修前漏洞行为与修后期望行为，并在原代码上运行。Boundary Analyzer 从汇附近代码和漏洞类别导出必须阻断的输入，以及必须保留的合法行为。每条发现都附带代码位置、分析结果或执行日志。
• 审查：Evidence Consistency Reviewer 判断发现能否进入 M。它部分通过重跑复现器和 oracle，检查各发现是否指向同一漏洞、是否覆盖报告中的主张、oracle 是否可用。两条规则是：智能体之间一致不算证据；仅由报告支持的主张永不确认。
• 细化：检查失败时，审查者返回指明失败检查、冲突证据和缺失项的定向请求。协调者只重新派出负责的智能体，并保留已验证证据。循环直到全部通过或预算耗尽。方法节未给出轮数。

漏洞模型

审查通过后，Analysis Coordinator 组装 M，这是交给补丁合成的唯一诊断输出。五个字段是 Root Cause、Attack Path、Runtime Oracle、Security Boundary、Preserved Behaviors。后两个字段是接受标准：补丁只有在去除不安全行为且保留既有行为时才被接受。附录 A 给出完整 schema。

补丁合成

• 验证矩阵：Repair Coordinator 把 M 译成验证矩阵。安全边界中的违规输入及变体必须被阻断，保留行为中的合法输入和兼容要求必须与原来一致，并检查补丁能否干净应用、项目能否仍构建。诊断未能确认的主张记为未验证用例。协调者还给出修复指令，定位根因并列出二至四个可行修法，优先选改变合法行为最少的。
• 生成：Patch Synthesizer 按指令实现一个补丁，修根因而不是过滤特定复现输入，以便同一攻击路径上的变体也被阻断。然后在打过补丁的仓库上执行矩阵每一行，并附带运行时证据。此阶段不回改诊断。
• 复核：Patch Reviewer 处于隔离上下文，能看到 M、填好的矩阵和补丁 diff，看不到合成者的推理。它仅在每一行符合期望、且补丁与 M 一致时接受：在根因处修复、去除不安全行为、保留既有行为。作者称仅通过矩阵不够，因为矩阵由系统自己构建；合法输入和变体用来防止补丁只抑制已观察到的触发，或拒绝有效输入。失败时报告失败行和违反的条件，合成者按反馈修改，直到接受或预算耗尽。

附录 C 给出两个审查者的系统提示词和用户提示词；作者称其余提示词在代码仓库中。这里不转述提示词里的检查清单和句式约束。

实验设置

• 系统与骨干：基线为 Codex v0.153.2 与 OpenCode v1.17.7。骨干为 DeepSeek-V4.1-Flash（Table 1 写作 DeepSeek-4.1-Flash）、GLM-5.2、Qwen3.8-27B。引言只点名前两个，第 4.1 节三个都跑了。各系统用同一 LLM、同一沙箱和相同工具。
• 时限：EviRepair 的诊断限 3 小时、合成限 2 小时；两个基线每任务统一 5 小时。
• PatchEval：230 个 CVE 修复任务，Go 83、Python 70、JavaScript 77。只给漏洞描述和目标仓库，不给可执行 PoC，用隐藏测试动态评测。
• SEC-bench：300 个真实安全任务，CVE 200、OSS-Fuzz 100。补丁任务额外提供 sanitizer 输出，按默认 medium 设置评测。论文未解释 medium 相对其他档的差别。摘要写作 SecBench。
• 指标与约束：%Resolved 是生成补丁通过该基准隐藏测试的任务比例。修复时禁用网络，以免从外部取回 ground-truth。判定沿用官方协议。论文未使用 LLM 评审，也未报告重复次数或人工一致性。
• 汇总：RQ2、RQ3 对每个系统在其评测过的骨干上对 resolved rate 取平均。

主结果

下表为 Table 1 的 Overall %Resolved。斜线前是 PatchEval（230），斜线后是 SEC-bench（300）。

表格较宽，可左右滑动

骨干	Codex	OpenCode	EviRepair
DeepSeek-4.1-Flash	78.26% / 73.00%	87.83% / 90.00%	89.13% / 96.33%
GLM-5.2	67.39% / 62.00%	60.87% / 77.33%	73.04% / 94.00%
Qwen3.8-27B	64.35% / 52.67%	66.96% / 82.67%	75.22% / 89.00%

• 均值：作者称按骨干平均后，EviRepair 为 PatchEval 79.13%、SEC-bench 93.11%，Codex 为 70.00% 与 62.56%，OpenCode 为 71.89% 与 83.33%。相对 OpenCode，作者称未解决任务比例约降 26% 与 59%。摘要、引言和结论称平均提升 16.37% 与 40.33%；论文未说明这两个百分比是绝对差值还是相对增幅。
• 分骨干差值：第 4.2 节称，相对同一骨干上更强的基线，PatchEval 高出 1.30、5.65、8.26 个百分点，SEC-bench 高出 6.33、16.67、6.33 个百分点，顺序为 DeepSeek-4.1-Flash、GLM-5.2、Qwen3.8-27B。21 组同骨干、同子集比较中，作者称 18 组结果最高、1 组并列。
• 例外与子集：JavaScript + DeepSeek-4.1-Flash 上 OpenCode 为 87.01%，EviRepair 为 81.82%；OSS-Fuzz + Qwen3.8-27B 上 OpenCode 为 93.00%，EviRepair 为 87.00%。JavaScript + GLM-5.2 上 EviRepair 与 Codex 均为 72.73%。作者称 SEC-bench 的 CVE 子集上 EviRepair 均值为 92.83%，高于 Codex 41.17 个百分点、高于 OpenCode 14.00 个百分点。作者称 OSS-Fuzz 带有指向崩溃位置的 sanitizer 报告，各系统都较高、差值更小。

漏洞类型

• 分组：Figure 4 按类别给出 resolved rate，系统值是三个骨干的平均。多于 10 个任务的类别单独显示，其余并入 Other。PatchEval 用主 CWE；SEC-bench 的 CVE 用 NVD 主弱点，OSS-Fuzz 用官方崩溃报告的根因类别。正文没有各类别的具体百分比。
• 作者对图的描述：PatchEval 上增益最大的是 CWE-863 与 CWE-285，其次是 CWE-73 与 CWE-601；CWE-94 与 CWE-89 上各系统相近；CWE-918 上没有优势。SEC-bench 上每个类别都领先，增益最大为 CWE-416 与 CWE-476，最小为 heap buffer overflow。
• 作者的解释：作者称授权类修复要先决定哪些请求放行或拒绝，这就是 Boundary Analyzer 建立的安全边界。对 CWE-918，作者认为可能因为复现 SSRF 需要出站请求，网络隔离沙箱观察不到，运行时 oracle 更弱。作者称当修复点不同于漏洞显现位置，或修复依赖允许与禁止的明确边界时，帮助更大。

修复难度

• 设置：Figure 5 按 ground-truth 补丁的改动行数、hunk 数和文件数分档。图注称折线是三骨干平均，阴影是 min–max。除一档外，正文没有各档精确读数。
• 作者称：各系统都随补丁变大而下降，EviRepair 下降更慢；行数上每档领先或并列，21–50 行一档约为 72%，基线约为 56%；hunk 上除 4-hunk 档外都领先，六 hunk 及以上领先最大；一个或两个文件的补丁上高于两个基线。
• 多文件例外：三个及以上文件的任务只有 7/230。作者称这些任务上 OpenCode 的结果最高，四个及以上文件的任务 EviRepair 一个也没解决。作者称样本小、估计不稳定，并称这与漏洞模型以单一根因和攻击路径为中心相一致。

阶段消融与骨干规模

• 消融：Table 2 在 GLM-5.2、PatchEval 上，完整系统为 73.04%。诊断改为单智能体后为 69.13%（下降 3.91 个百分点），合成改为单智能体后为 67.83%（下降 5.21 个百分点），两端都改后为 60.87%（下降 12.17 个百分点）。作者称两处单独损失之和为 9.12 个百分点，小于同时替换，并称两阶段互相加强，一阶段漏掉的错误仍可能被另一阶段抓住。Figure 6 与附录 B 是一条两阶段轨迹示例，正文没有该例的 resolved 数字。
• 小骨干：作者称结构化证据在很大程度上弥补更小骨干。Qwen3.8-27B 的 EviRepair 在 PatchEval 为 75.22%，高于该骨干的两个基线，也高于 GLM-5.2 上的 Codex 67.39% 与 OpenCode 60.87%。SEC-bench 为 89.00%，高于 GLM-5.2 上的全部基线；作者称接近 OpenCode+DeepSeek-4.1-Flash 的 90.00%。
• 差值趋势：同一骨干上相对最强基线的 PatchEval 差值，作者称从 DeepSeek-4.1-Flash 的 1.30 个百分点到 GLM-5.2 的 5.65、Qwen3.8-27B 的 8.26。作者称骨干越弱，诊断重构的证据越决定修复是否成功。该趋势在 SEC-bench 上不那么明显，作者称因为 sanitizer 输出已经向所有系统提供了部分证据。

其他消融与分析

• 单智能体诊断，GLM-5.2，PatchEval：Go 67.47%，Python 67.14%，JavaScript 72.73%（Table 2）；JavaScript 与完整系统相同，论文未解释。
• 单智能体合成：Go 69.88%，Python 65.71%，JavaScript 67.53%；Go 与完整系统相同。
• 单智能体端到端：Go 49.40%，Python 64.29%，JavaScript 70.13%，Overall 60.87%。
• 论文未报告迭代轮数、查询次数、重复实验和统计检验。
• Figure 3 图注称柱顶数字是相对每个基线的绝对提升；正文未逐项列出全部柱顶数字。

作者指出的局限与后续方向

• 评测范围：作者称评测限于 PatchEval 与 SEC-bench，可能不能反映漏洞、语言、仓库和部署环境的全部多样性（第 6 节）。
• 安全评估：作者称安全评估限于基准级验证，所报告结果不保证漏洞被完全消除、没有回归或长期可维护（第 6 节）。
• 成本：作者称多智能体设计带来额外的模型调用、延迟和费用（第 6 节）。
• 后续：作者称后续应在更广的真实环境中评测，加强安全与回归评估，并进一步研究修复质量与资源成本的权衡（第 6 节）。

实验覆盖范围

• 骨干为 DeepSeek-V4.1-Flash、GLM-5.2、Qwen3.8-27B 三个；对照框架为 Codex v0.153.2 与 OpenCode v1.17.7，同一沙箱和工具访问（第 4.1 节）。
• 基准为 PatchEval 230 项（Go 83、Python 70、JavaScript 77）和 SEC-bench 300 项（CVE 200、OSS-Fuzz 100，默认 medium）；指标为隐藏测试上的 %Resolved（第 4.1 节、Table 1）。
• 修复期间禁用网络。EviRepair 诊断时限 3 小时、合成时限 2 小时，两个基线每任务 5 小时（第 4.1 节）。
• 消融在 GLM-5.2 与 PatchEval 上比较单智能体诊断、单智能体合成、单智能体端到端和完整流程（Table 2）。类型与难度分析对三个骨干取平均（第 4.3、4.4 节）。
• 论文未报告重复次数、统计检验、迭代轮数、查询次数，也未报告 LLM 评审或人工一致性（第 4 节）。

EviRepair 是面向稀疏漏洞报告的仓库级自动漏洞修复框架，用审查后的漏洞模型把诊断和补丁合成隔开。

• 问题：作者称现有单智能体没有专门审查就把诊断证据用于修复，已有多智能体则直接汇总输出，不一致或不完整的发现会进入补丁。
• 做法：独立智能体分别收集可达性、可执行复现与 oracle、安全边界和应保留行为；一致性审查通过后才形成漏洞模型。合成阶段把模型变成验证矩阵，隔离的审查者对照矩阵和模型决定接受或退回补丁，且不回改诊断。两条审查规则是：智能体之间一致不算证据，仅有报告支持的主张不予确认。
• 主结果：Table 1 里，EviRepair 配 DeepSeek-4.1-Flash 的总 %Resolved 为 PatchEval 89.13%、SEC-bench 96.33%；配 Qwen3.8-27B 为 75.22% 与 89.00%。作者称三个骨干的均值为 79.13% 与 93.11%，高于 Codex 与 OpenCode 的对应均值。同表中 OpenCode 在 JavaScript+DeepSeek（87.01% 对 81.82%）和 OSS-Fuzz+Qwen3.8-27B（93.00% 对 87.00%）更高。
• 其他结果：GLM-5.2、PatchEval 上，完整系统 73.04%，两端都改为单智能体后为 60.87%（Table 2）。作者称骨干越弱，诊断重构的证据越影响能否修好。四个及以上文件的任务 EviRepair 一个也没解决，这类任务属于 7/230 中跨三个及以上文件的部分。
• 作者结论：作者称阶段分解和独立证据审查有助于有证据依据的漏洞修复，同时在第 6 节写明基准通过并不保证漏洞被完全消除。