PatchHolmes 让智能体一次读完 100 个候选提交，把漏洞补丁检索的 Recall@1 从 32.63% 提到 59.95%
核心概要
PatchHolmes 是一个两阶段补丁检索系统，第一阶段用 BM25 加时间衰减与 Qwen3-Embedding-8B 稠密检索经 RRF 融合出 top-100 候选，第二阶段让一个冻结的开源权重 LLM 智能体通过 list_candidates、read_commit、read_file_diff、submit_answer 四个工具以列表式方式查看全部 100 个候选并只提交一个最佳提交；在 GitHubAD 的 809 个 CVE 上 Recall@1 达 59.95%，比逐点分类器 Favia 高 25.34%、比 IRCoT 高 31.40%，在候选集完全相同的条件下智能体本身比直接取检索器首位高 27.32%，同一智能体不加改动迁移到
深度剖析
把补丁检索的第二阶段从逐点打分改成列表式选择：智能体一次看到 top-100 候选清单，再按需打开 3 到 10 个提交，最后只提交一个答案。 此前的 Favia 对 10 个候选各发一次独立调用、输出 yes/no 加置信度，候选之间没有联合信号；PatchHolmes 用一次对话取代十次调用，让候选互相比较。 在 GitHubAD 809 个 CVE 上 Recall@1 为 59.95%，Favia 为 34.61%，IRCoT 为 28.55%，SPFinder 为 27.32%；McNemar 精确检验在各截断点均显著，Recall@1 的 95% 自助置信区间 [56.7, 63.5] 与 Favia 的 [31.3, 37.9] 不重叠。
增益来自智能体循环而非检索器或模型规模：在候选集完全相同的条件下，智能体把 Recall@1 从 32.63% 提升到 59.95%。 把检索器从变量中移除后，Favia 在同一候选上只从 34.61% 升到 39.80%，IRCoT 从 28.55% 升到 37.58%，剩余 20.15% 与 22.37% 的差距归因于选择方法。 同一候选集上智能体单独贡献 27.32% Recall@1；Qwen 家族内换骨干（Qwen3-235B 到 Qwen3-Coder-30B）Recall@1 变化 0.86%，第二家族 gpt-oss-120B 为 56.98%、gpt-oss-20B 为 49.81%，均远高于 32.63% 的无智能体下限。
四个工具构成最小充分集，其中列表式查看候选清单是单步增益最大的一环。 消融显示只给智能体 list_candidates 与 submit_answer 就从 32.63% 升到 48.21%（+15.58%），加入 read_commit 概览再升 9.27%，读到真实 diff 再升 2.47%。 同一 Phase 1 候选上的能力阶梯（表 3 行 G、F、E、MAIN）；Phase 1 消融中稠密路径单独达 57.11%，距完整融合仅 2.84%，而 RRF 融合仍带来 +2.84% Recall@1 与 +5.32% Recall@10。
系统可在冻结开源权重模型与本地 Git 仓库上运行，无需微调与付费搜索 API，成本约为 Favia 的七分之一。 Favia 每个 CVE 需十次约 67,000 token 的逐点对话，PatchHolmes 每个 CVE 一次对话、平均约 96,118 输入 token、8 次工具调用、读 5 个提交。 按附录费率约每 CVE 0.007 美元、全量 8,401 个 CVE 约 58 美元，对比 Favia 约 400 美元；Qwen3-Coder-30B 以 0.86% Recall@1 换取约一半墙钟时间（39 秒对 86 秒）。
启示与展望
该结果面向在本地 Git 仓库上、以冻结开源权重模型运行的补丁检索场景，适用于安全公告、CVSS 评分、受影响版本追踪与 SBOM 扫描等下游消费者；作者已在 https://github.com/Aizhouym/PatchHolmes 开源代码。方法本身不修改代码，候选集由 Phase 1 固定，因此工具面只需调查、两种粒度的提交阅读与一次提交。跨语料迁移在 PatchFinder_top10 的 1,252 个 CVE 上验证，真实场景检查覆盖 11 个仓库、2013 至 2025 年披露的 35 个 CVE。作者明确建议把输出当作供人工复核的候选，而不是自动写入漏洞数据库。
评测只能覆盖补丁已被找到的 CVE，即 60% 到 63% 缺失补丁链接之外的 37% 到 40%，从未被定位过修复的困难样本不在任何基准中；作者用 35 个真实 CVE 做了补充检查，但仍需已知修复才能计分。PatchFinder_top10 的可达上限为 46.10%，因为 1,252 个 CVE 中只有 577 个的候选池含真实修复。GitHubAD 抽样在 9 项拟合检验中通过 6 项，未通过的三项集中在提交数与 diff token 的尾部，源于 143 个超大仓库的提交计数与补丁 diff 长度被中位数替代。多修复 CVE 占 7.28%，只记录其中一部分，若智能体选中同样有效但未被记录的修复会计为未命中。此外，提示中的排名频率提示是粗略聚合统计，与最终检索器在测试子集上的表现并不一致，作者未用去掉数字的版本重跑实验。