当AI能批量发现漏洞后，安全团队最先迎来的可能不是修复提速，而是更长的验证队列。微软FORGE Lab披露，2026年5月至9月，其工作参与发现的Windows漏洞中有140个获得CVE，其中52个进入9月安全更新；同时，团队在三个月内向23个开源项目提交155份内部验证报告。规模上去了，真正稀缺的却变成可运行构建、可信复现、组件负责人和工程师的修复时间。

发现量翻上去，验证队列可能先被压垮

FORGE使用代号MDASH的多模型Agent扫描框架，把前沿模型、蒸馏模型、专用审计器和代码分析工具分配给不同步骤。它的核心教训不是“模型已经能替代安全研究员”，而是候选数量不等于有效吞吐。重复、证据不足或无法触达的报告会消耗PoC生成器与人工评审，让更强的发现反而在队列中等待。

微软一个内部项目用确定性的抽象语法树方法，在同一代码的多次扫描之间减少约45%的重复发现。这个细节很重要：能用索引、规则和执行器确定的事实，不应继续让大模型反复推理。只有当问题涉及复杂生命周期、跨回调条件或因果解释时，才值得把更强模型和更多预算投入进去。

3.61美元不是单漏洞总成本，而是成功验证的一小段

在Linux内核实验中，MDASH先产生大量可疑位置，验证Agent为627个发现生成支持证据。对其中182个确认的崩溃案例，生成PoC平均花费3.61美元模型成本和21.5分钟；六个选定的本地提权成功案例，自动利用生成平均为8.56美元和25.4分钟。实验使用GPT-5.5，并计入成功案例相关的全部尝试。

这些数字没有包含初筛、被过滤或失败的候选，也没有包含人工调查、补丁准备、兼容性评审和发布验证，因此不能当作端到端“修一个漏洞”的价格。真正有意义的经济指标应把模型成本、环境搭建、队列等待、人类工时与最终进入版本的比例放在一起，计算每个已验证并修复缺陷的总成本。

155份报告只是一条流水线，不是155个已修漏洞

FORGE向Linux、curl、FFmpeg、Node.js、SQLite、Rust、llama.cpp、vLLM、PyRIT以及Apple容器项目等提交155份内部验证报告。发布时，93份在14个项目或项目家族留下维护者确认或接受记录，但各自仍处于不同阶段，只有一部分已经公开披露。内部验证、维护者确认、补丁合并和正式版本发布是四个不同门槛。

一个Linux报告成为Linux Foundation Akrites计划首个最终合入内核补丁的提交，说明Agent结果确实能进入真实修复链路，也说明协调责任不能甩给维护者。不同项目有不同构建、提交流程、披露渠道和安全边界，研究团队必须提供可复现触发、因果解释、严重度判断与回归证据，才能让报告继续向前移动。

小编判断：AI安全交付要优化修复吞吐，而非扫描声量

FORGE给企业最可复用的提醒，是把漏洞Agent视为带状态的工程流水线。候选发现、去重、环境准备、自动复现、人工影响判断、补丁、回归测试与发布必须共享证据；失败复现也要记录原因，反哺下一轮路由和训练。否则，更多模型只会制造更大的待办列表。

安全负责人应把指标从“发现多少”改成验证通过率、重复率、维护者确认率、修复周期、补丁返工、人工介入和进入正式版本的比例。每一轮推理都应回答一个尚未解决的问题，而不是生成更多相似分析。自动化最适合承担触达确认、复现与证据保存，人仍要负责安全影响、修复策略和发布责任。

140个CVE证明AI安全研究已经跨过单次演示，但也把组织瓶颈照得更清楚。模型能力还会继续提高，能否建立足够快、足够可信的验证与修复系统，才决定这些发现最终是安全价值，还是另一支越来越难清空的队列。