Microsoft 表示，Frontier Offensive Research & Generative Exploitation 实验室（简称 FORGE）已从测试人工智能发现复杂漏洞的能力，转向研究如何将这些发现转化为可发布的修复方案。2026 年 5 月至 9 月期间，该实验室帮助发现了 Windows 中的漏洞，并为其分配了 140 个 CVE 标识，其中 52 个已纳入 2026 年 9 月安全更新。
相关工作还扩展到了开源软件领域；FORGE 团队提交了约 155 份报告，这些报告已在包括 Linux 内核在内的 23 个项目中完成内部验证。据 Microsoft 称，在材料编写时，涉及 14 个项目或项目系列的 93 份报告已获得维护者确认或有记录的接受。其中一份通过 Linux 基金会旗下 Akrites 计划提交的 Linux 报告，成为该计划首份最终促成修复合并到 Linux 内核的报告。
从最大化能力到大规模运行
第一个启示是，模型成功发现复杂缺陷，并不意味着它能够以同样的速度产出修复方案。增加验证器数量可能会提高候选结果的数量，但未必会相应增加已确认结果或已发布修复的数量。如果报告到达 Microsoft 安全响应中心（Microsoft Security Response Center）的速度超过其审查能力，待处理队列就会不断积累并消耗专家时间，尤其是在报告重复或缺乏可复现证据的情况下。
因此，FORGE 关注的是可复现的结果，而不只是扫描次数或报告数量。该实验室使用多模型平台 MDASH 来组织工作，同时使用可利用性证明或概念验证生成器、测试工具构建工具，以及寻找能够触发错误行为的输入。Microsoft 提到，一个采用确定性算法（例如抽象语法树分析）的内部项目，使同一代码多次扫描产生的重复报告减少了约 45%。
将投入用于消除不确定性，而不是增加文本
Microsoft 认为，仅以模型生成的令牌数量衡量效率，会导致误导性标准。简短报告可能含糊不清，并使调查成本高昂；而较长的分析如果能够说明执行路径，反而可以降低总体成本。实际的决策是确定调查人员缺少什么：调用该函数的代码、构建配置、可运行的复现程序，还是因果解释；然后让下一步专门弥补这一具体缺口。
MDASH 将先进模型、蒸馏模型、专业验证器和代码分析工具结合起来，并能够将例行任务分配给成本较低的模型，再将尚未解决的问题升级给更强的模型。不过，Microsoft 强调，这一策略仍是假设，需要通过测量加以验证，因为过早筛选可能会排除真实漏洞。
将验证和修复作为持续学习闭环
根据这一观点，不应将验证和修复视为漏洞发现之后的后续阶段。每个结果都应经过自动验证、人工审查、补丁开发和回归测试，并将每个阶段的证据反馈给系统。即使验证失败也可能有价值，只要记录失败原因，例如无法访问相关路径、构建配置不正确、攻击者无法控制输入，或报告重复。
在一次 Linux 内核实验中，验证代理为 627 个结果生成了佐证；对于 182 个已确认崩溃结果，生成概念验证的平均成本为 3.61 美元的模型成本，每个成功案例平均耗时 21.5 分钟。在测试通过自动化利用生成来验证本地权限提升可能性的 6 个案例中，平均成本为 8.56 美元，平均耗时为 25.4 分钟。这些评估使用了 GPT-5.5，但不包括初步扫描成本、失败案例成本、人工调查成本以及补丁准备成本。
这对安全团队意味着什么？
这些结果最重要的启示是，代理式漏洞发现系统的成功指标不应止步于结果数量。Microsoft 建议跟踪已确认缺陷数量、重复和被拒报告数量、待处理队列的存在时间、从发现到修复的过渡时间，以及模型成本和人工审查时间。此外，在开源项目中开展工作还需要尊重每个项目的披露、审查和修复流程，而不是单纯发送更多报告。
从实践角度看，来源材料指出瓶颈正在转移：发现缺陷的能力已成为问题的一部分，而将研究与构建环境、二进制文件、配置、测试工具及 CI/CD 系统连接起来的重要性正在上升。研究结果的局限性也很明确；关于验证成本的数据不包括重要的人工阶段，而且将研究结果转化为项目接受的修复方案，取决于维护者以及每个项目的具体背景。因此，文章并未证明自动化可以取代工程审查，而是将其视为减少重复工作的手段，同时继续由人类承担安全判断和修复责任。