AI生成代码越快，季度做一次大扫描就越像在洪水过后数沙袋。Google公开的新做法，是对每次代码提交做Agent扫描，再用程序分析验证漏洞路径，夜间复查跨提交问题，并把修复送回原评审。开发者最该抄的不是“全自动”四个字，而是这条证据链：发现、证明、复核、修复，任何一步都不能只靠模型自信。

发生了什么

Google在9月18日披露，其内部安全Agent持续扫描部署到基础设施中的数亿行代码，官方称每月阻止数百个漏洞进入代码库或生产环境。流程基于开源多Agent评审框架Mantis演进而来，重点是把传统的大型一次性扫描，改成每次提交时运行的局部预提交扫描。

官方还给出两个值得注意的数据：局部威胁模型在部分场景把误报率降到3%；专用分诊Agent结合抽象语法树、调用图和预索引安全规则验证攻击路径，精度超过92%，且通常在一分钟内完成。随后还有夜间集成扫描，修复Agent则根据漏洞证明生成补丁，交回人类评审。

一手来源：Google Cloud技术文章。这些数字来自Google内部系统，适用代码类型、召回率和完整样本量并未公开，不能直接套用到其他团队。

技术原理：先缩小问题，再让模型判断

传统扫描常把整个仓库和一份静态威胁文档交给工具，结果上下文大、噪声多、反馈晚。增量方案只围绕本次变更建立局部威胁模型：改了哪个入口，影响哪些依赖，外部输入能否沿调用图到达危险操作。Agent负责提出假设，程序分析负责检查路径是否真实存在。

这里的AST是抽象语法树（Abstract Syntax Tree），它把代码解析为结构；调用图描述函数之间可能的调用关系。二者不是万能证明器，但能过滤“模型觉得像漏洞、实际路径走不到”的常见误报。漏洞证明最好是最小触发样例、调用链或可复现测试，而不是一段自然语言解释。

对开发团队意味着什么

最直接的场景是一个新增HTTP接口把用户输入传给内部命令。模型可能发现命令注入风险，但只有继续确认净化函数、参数类型、权限边界和真实调用路径，告警才值得阻断合并。反过来，如果只追求低误报而不断收紧规则，又可能漏掉跨服务或多步利用。

普通团队不必复制Google的规模。可以先选一个高风险目录，例如鉴权、中间件、支付或基础设施脚本，只扫描变更差异及其一到两层依赖。把高置信发现变成必须处理的评审项，把中低置信发现放进异步队列，记录开发者接受、驳回和原因，逐步校准规则。

我的判断

AI安全扫描最重要的产品不是告警，而是可审查的攻击路径。 模型能够快速拓展假设空间，却不擅长独自给出确定性结论。Google方案真正有价值的地方，是让生成式Agent和确定性程序分析互相约束，再把最后责任留在人类评审。

这也解释了为什么“精度92%”不能单独代表系统好用。安全扫描至少还要看召回率、严重漏洞分层、平均处理时间、被开发者推翻的原因，以及漏报如何被后续层捕获。一个只报三条且全对的系统，可能仍漏掉最危险的第四条。

适用边界与风险

增量扫描适合反馈要快、变更可定位的代码库；对配置漂移、运行时权限、供应链依赖和多个提交共同形成的漏洞，必须靠夜间或周期性全局扫描补位。自动修复也可能改变行为或只堵住表面路径，因此补丁需要单元测试、攻击回归测试和所有者审批。

Google披露的是内部经验，不等于开源Mantis开箱即可达到相同指标。团队还要防范源码发送范围、模型日志留存、第三方依赖许可，以及攻击者用注释或测试数据对扫描Agent做提示注入。

评估试点时别只统计告警数量。至少同时记录高危问题召回线索、每百次提交的误报、开发者确认一条告警所需时间、补丁一次通过率，以及同类漏洞是否再次出现。若误报下降却人工核验时间上升，系统仍可能拖慢交付。

一周内可执行的试点

选择一个高风险仓库；定义三类漏洞与阻断阈值；只给Agent只读权限；要求每条告警附文件位置、入口、危险点和可达路径；用现有测试验证补丁；最后统计误报、漏报线索和评审耗时。先证明证据链可靠，再讨论自动合并。

你的团队会让AI安全扫描阻断合并，还是只先作为评审提示？

关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。