PatchHolmes：让智能体从候选列表中找出真正的漏洞修复提交

导语

一条漏洞公告如果没有对应的修复提交，就很难进一步确认补丁内容、追踪受影响版本，也会增加供应链扫描和安全运营的工作量。然而，GitHub Advisory Database 与 National Vulnerability Database 中，约有 60% 至 63% 的 CVE 缺少补丁链接。PatchHolmes 试图解决的，正是“已知漏洞究竟由哪个提交修复”这一基础但困难的问题。

为什么补丁检索并不简单

检索空间首先非常庞大。单个代码仓库可能包含最多约 140 万个提交，且相当一部分漏洞来自拥有超过 5000 个提交的仓库。其次，提交差异往往很长，平均规模约为 1.5 万个 token，传统文本编码器如果只读取开头部分，可能错过真正关键的修改。最后，漏洞报告与修复提交使用的术语并不总是一致：报告可能描述“缓冲区溢出”，而提交信息则使用“越界读取”等不同表述。

PatchHolmes 的方法

PatchHolmes 采用两阶段架构：

• 第一阶段：候选召回。 系统使用混合检索，从整个本地 Git 仓库中筛出前 100 个候选提交。
• 第二阶段：列表式智能体选择。 智能体一次看到完整候选列表，而不是分别为每个提交进行独立判断。随后，它通过四类受预算约束的工具，选择性打开约 3 至 10 个提交，最后只提交一个最可能正确的修复提交。

这种设计针对的是点式分类器的一个常见问题：当多个候选都修改了相近代码路径时，模型可能给出大量相同的“是”判断，最终只能依赖候选原有顺序选出第一名。列表式阅读则允许智能体直接比较提交之间的修改目标、上下文和关联性。

实验结果

在 GitHubAD 上，PatchHolmes 的 Recall@1 达到 59.95%，高于点式系统 Favia 的 34.61% 和 retrieve-and-reason 基线 IRCoT 的 28.55%。在候选集合完全相同的情况下，加入智能体后，结果也比直接采用检索器第一名高出 27.32 个百分点。迁移到 PatchFinder_top10 的候选池后，同一个智能体将 Recall@1 从该系统原本的 24.28% 提升到 39.86%。

研究还显示，替换 Qwen 系列中的语言模型后，Recall@1 的变化不到 1%；换用另一模型家族 gpt-oss，性能仍明显高于不使用智能体的结果。这说明收益更可能来自列表式检查和选择流程，而非某个特定模型。系统每个漏洞约使用 9.6 万个输入 token、8 次工具调用，并检查约 5 个提交；同时，它运行在冻结的开源模型和本地 Git 仓库上，不依赖微调或外部搜索 API。

意义与局限

PatchHolmes 的价值不只是提高一个检索指标，更在于展示了智能体如何把“召回很多候选”转化为“在有限预算下做比较”。对于补丁链接缺失的漏洞数据库，这种流程有望减少人工排查成本，并为版本追踪、漏洞响应和软件供应链分析提供更可靠的基础。

不过，Recall@1 仍未达到完全准确，说明候选召回质量、长提交理解和漏洞描述与代码变化之间的语义差距仍是后续重点。该方法也需要在更多仓库类型、语言和真实安全运营场景中验证其稳定性。

来源：Hugging Face Daily Papers