漏洞修复智能体

队列不等于工作量。其中大部分根本不该走到智能体面前。

一个修复项目的起点，是承认扫描器积压的大半是噪声，而一个对着整个积压开火的智能体，只是把噪声工业化了。基础比率就是论据：Cyentia 与 FIRST 对利用数据的分析给出的数字是，已公布的 CVE 中曾被观测到在野利用的比例大约是 6%。全都修，那么你评审的每二十个补丁里大约有十九个本来就无关紧要——只不过每一个仍然要占用评审、仍然可能带来回归，也仍然在消耗评审者认真看第二十个的意愿。

先过滤再生成，并且按这个顺序，因为每一级都比它后面那级便宜：

• 看可达性，而不是看存在性。锁文件里有一个带漏洞的依赖，并不等于你的应用有漏洞，除非那个受影响的函数真的会被调到。调用图可达性是可获得的最大一笔削减——卖这项能力的厂商声称能减掉九成以上噪声，你应该把它当营销数字来读，但仍然要认真对待，因为方向本身没有争议。让依赖升级智能体还能忍受的，也是同一套纪律。
• 看被利用的可能性，而不是看严重程度。CVSS 打的是“出事有多糟”，EPSS 估的是“有没有人在做”，而 CISA 的 KEV 目录记录的是“确实有人在做”。可达代码里的一个 KEV 条目，遥遥领先地排在你队列最前面；而一个躲在不可达代码路径背后、EPSS 只有个位数低段的“严重”漏洞并不紧急，无论仪表盘把它涂成什么颜色。
• 看爆炸半径，这要从你自己的架构里读。扫描器不知道一个服务装着客户数据，而另一个只在渲染状态页。这是没有任何工具会替你提供、却最能改变排序的那项输入。

在生成任何东西之前先定义“修好了”，因为那个显而易见的判据是错的。

最自然的校验是：功能测试套件通过，且概念验证利用不再奏效。这条线也被证明不够用。PVBench 那项关于自动化漏洞修复的研究，评估的正是通过了这条线的补丁，结果发现其中超过四成在加强版测试下失败——用的是同一个漏洞利用的各种变体，而不是智能体一直在对着优化的那个特定输入。研究还发现，在大约 28% 的受测漏洞上，产出的每一个补丁都是假阳性：根本没有生成出任何正确的东西，而校验一直在说反话。

这种失败并不神秘。拿到一个利用输入的模型，一定会稳定地产出一个能拒绝那个输入的补丁。它会过滤那个字符串、在 PoC 走过的那条路径上加边界检查、对那个载荷做特判。漏洞是一个类；PoC 是这个类里的一个成员；而循环的每一环——生成、校验、奖励——指向的都是那个成员。

所以，把判据写成测这个类的：

• 把利用变异一下，再跑一遍。改偏移量、改编码、改字段顺序、改抵达那个汇聚点的路径。一个只扛得住原始输入的补丁，等于告诉了你它是在做模式匹配。
• 同时保留一项功能等价性检查。击败安全测试最常见的办法，就是把功能弄坏。
• 拒绝用模型自己的测试来评分。一个既写修复、又写那份为修复背书的测试的智能体，是在给自己的作业打分，而这个陷阱在测试生成智能体里被详细拆解过。

先把复现建起来。那才是交付物，补丁只是副产品。

把直觉顺序倒过来。交给智能体的第一个任务不是“修好它”，而是“让它挂掉”——搭起一个能确凿触发该漏洞的环境，并把它作为测试提交进去。所有好事都从拥有这样一份东西开始，而正是同样的倒置，让调试与分诊智能体从“看起来可信”变成“真的可信”。

• 它让评测标准变得客观。在 CI 里、在一台不属于智能体的机器上，打补丁前失败、打补丁后通过。不需要裁判模型，也不需要“我看着挺对”。
• 它把一条公告转换成一份比补丁活得更久的回归测试。一个修复项目留下的持久产物，是一套能在漏洞卷土重来时抓住它的测试——而它确实会卷土重来。Project Zero 对在野零日的分析发现，其中相当大的一部分是此前已修问题的变体，那正是一个不完整修复在几个月之后从外面看起来的样子。
• 它给了你一个诚实的否定结论。“复现不出来”是一个正当结果，能廉价地结束这次运行。没有它，一个复现不出问题的智能体照样会产出补丁，因为产出补丁正是它被要求做的事。

复现要跑在一个用完即弃、断网的沙箱里——你是在自己的基础设施里执行漏洞利用代码，有时还是攻击者写的代码，其收敛要求就是沙箱与安全执行里那一套。对于源自模糊测试的那一类，公共基础设施是现成的：把真实漏洞打包成可复现容器镜像的语料库，以及在其上构建、同时提供打补丁前与打补丁后代码树的基准——那正是一套“修复证明”编排所需要的形状。

关于生成这一步，证据到底说了什么。

迄今统计效力最好的公开研究，针对特意选在模型训练截止之后披露的 CVE，用两个前沿推理模型在高投入档位生成了约六千个补丁。要照着来做设计的，是这个分布：

• 约 26% 在没有实质改变行为的前提下解决了漏洞——这才是你真正想要的结果。
• 约 20% 修好了，但改变了应用行为——一个拿安全 bug 换可用性 bug 的补丁，也正是你的安全测试会乐呵呵放行的那种。
• 约 54% 没修好、引入了新漏洞，或者两者兼有，其中大约一半的补丁至少留着一条既有的可利用路径没堵上。

比这个头条数字更要紧的是两项二阶发现。第一，引导起决定性作用：当模型拿到关于该漏洞的正确引导时修复成功率约 65%，什么都不给时约 50%，而拿到错误引导时暴跌到约 15%。一个对根因笃定却搞错了的智能体，实质上比一个什么都没被告知的智能体更糟——这意味着你的分诊环节不是摆在生成器前面的锦上添花，它是生成器最大的单项输入，而一份糟糕的自动根因摘要是主动有害的。

第二，同样的落差在竞赛条件下同样出现。在 DARPA AI 网络挑战赛决赛中，各支网络推理系统发现了范围内 86% 的合成漏洞，并为整个范围里的 68% 产出了补丁——相当于它们找到的那些当中的五分之四。面对真实开源代码时，比例更难看：发现十八个漏洞，修好十一个。在任何人测过的每一种设定里，找总是跑在修前面，且相当稳定——所以一条把吞吐假设为“找到即修好”的流水线，从一开始就估错了尺寸。

交付的是证据包，不是 diff。

送到评审者手上的东西，决定了这个项目是在增加产能还是在增加队列。一个只包含两行改动、外加一句“修复 CVE-2026-xxxxx”的 PR，把全部验证负担转嫁给了一个人，而这个人现在得把智能体早已知道的一切重新推导一遍。改成让每次运行都吐出一个固定的证据包：

• 可达性证据。从你的入口点到那个受影响函数的调用路径，让评审者能看见这一条当初凭什么进的队列。
• 复现。提交进去的那份测试，附上 CI 显示它在父提交上是红的、在头提交上是绿的。
• 变体结果。试过哪些利用变异，以及它们同样都失败了。这一节把“修复”和“过滤”区分开来，也是人工手写绝不会写出来的那一节。
• 行为差异。还有什么变了——新的错误路径、原先被接受而现在被拒的输入、热路径上的性能。那 20% 的“修好了但不一样”就住在这里，别处没有。
• 根因陈述，以及它的置信度。两句话，外加一句明确的“低置信度”——当智能体没能把修复与某个机理挂上钩时。鉴于上面那组引导敏感性数据，一个会给自己薄弱诊断打标记的智能体，比一个永远听起来很笃定的更有价值。

在人看到之前先机械地给这个包打分，正如补丁生成与测试驱动循环所规定的：缺少复现，或者变体测试没过，就该把这次运行弹回给智能体，而不是弹进评审。另外，别让智能体自己决定披露路径——在这条路上走得最远的那些系统，包括造模型的实验室自己运营的那些，都会让每一项发现先经过人，再对外报告或向上游提交。那是一项策略，不是能力缺口，而且是正确的那项。

合并队列才是节流阀；而把这套机器对准别人的项目，是完全另一个项目。

上面所有内容都假设补丁落在你自己拥有的代码里。把同一套机器对准你的依赖，你就继承了一个开源生态在 2026 年整整记录了一年的问题：curl 在 1 月关掉了漏洞赏金，此前它的“确认漏洞”比例已从 15% 以上跌到 5% 以下，而在年初的头三周里它收到了二十份提交、真实漏洞为零；HackerOne 在 3 月暂停了 Internet Bug Bounty，明说发现已经不再是瓶颈，而赏金并不为修复买单。维护者们抱怨的不是机器会找 bug，而是机器把发现发过来，却不带那些让一项发现变得可行动的工作。

由此得出向上游贡献的规矩：要么发补丁加复现，要么什么都别发。披露这项工作是机器生成的，并且把报告扣在手里，直到有人验证过那份复现——正如你希望别人在给你发报告时也过一遍同样的闸门。

给这个项目挂两个指标，其余的都别看。带证据合入率——已开 PR 中带着一份通过的复现落地的比例——告诉你这个智能体产出的是已验证的修复还是看起来可信的修复。从“可达且在被利用”的发现到修复合入的时间——告诉你这一切有没有真的抵达生产。生成了多少补丁、分诊了多少发现、关掉了多少 CVE，全是虚荣指标：一个每天开十二个修复 PR、而团队只合得进三个的智能体，增加的是队列，见后台编码智能体。

相关：安全运营智能体，同一支团队工作量里检测与响应的那一半；智能体平台的漏洞管理，讲的是给智能体基础设施本身打补丁；以及代码评审智能体，那条“精确率优先于召回率”的论证统辖着每一个替人类提交发现的机器人。