一次代码提交留给安全检查的时间，通常只有开发者愿意等待的几分钟。Google 选择把漏洞扫描塞进这个窗口：9 月 19 日，公司披露其安全 Agent 会检查部署到基础设施的每一次代码变更，覆盖数亿行代码，并称这套流程每月阻止数百个漏洞进入代码库或生产环境。
真正决定这套流程能否常驻提交链路的，不是让一个模型包办审查，而是让模型先提出漏洞，再交给另一套结构化分诊程序证明攻击路径确实可达。Google 给出的“超过 92% 精度”只属于这个分诊环节，不是系统找到全部漏洞的比例，也不是端到端自动修复成功率。
把全库扫描拆成每次提交，先缩小模型要看的上下文
传统的一次性全库扫描往往在代码合入后才发现问题，扫描范围大，也缺少某次变更的局部上下文。Google 的预提交 Agent 改为逐次检查代码变更，并接入开发者原有的提交工具。它读取随代码更新的局部威胁模型，再沿跨包和依赖库的调用图扩展上下文；扫描目标从“理解整个代码库”缩小为“这次变更是否打开了一条可利用路径”。
Google 称，局部威胁模型在部分场景把误报率降到 3%。这个数字与后面的 92% 并非同一口径：前者描述部分场景中的误报率，后者描述专用分诊 Agent 的 precision。官方没有公布两组测试使用了多少样本、覆盖哪些漏洞类型，也没有给出同一批代码上的静态规则扫描或人工审查基线。
预提交并非唯一防线。代码合入后，夜间集成测试会再扫描一次，用低峰算力寻找由多次变更共同引入、单次提交难以看出的漏洞。这种分工承认了一个现实：低延迟检查只能处理有限上下文，跨变更分析需要更长时间。
第二层用代码结构证明路径可达，92% 衡量的是留下来的告警
轻量扫描发现问题后，专用分诊 Agent 会解析抽象语法树，遍历调用图，并查询预先建立的领域安全规则，尝试证明攻击者能够到达疑似漏洞路径。Google 称这一环节在一分钟内完成，precision 超过 92%。
按 precision 的标准含义，这表示被分诊层判为有效的告警中，超过 92% 被认定为真阳性。它回答“交给开发者的告警有多少是真的”，不回答“代码里所有真实漏洞找到了多少”。后者需要召回率。一个系统可以通过只保留最有把握的告警获得很高 precision，同时漏掉更多漏洞；Google 没有披露召回率、置信区间、人工标注方法或不同严重度的表现。
“每月阻止数百个漏洞”同样是整套内部流程的公司口径。公开文章没有说明是否去重、严重度如何分布、其中多少来自预提交扫描、夜间复扫或其他检查，也没有给出进入生产前被拦截与已部署后被修复的拆分。因此，这个数字能证明流程已经进入生产规模，不能用来比较它与其他安全工具的发现能力。
自动修复仍停在人类合并之前
当扫描和分诊生成了漏洞证明后，修复 Agent 会按内部编码规范提出补丁，并把修改放回原变更请求，交给人类审查。Google 称建议被广泛采用，却没有披露补丁采纳率、人工修改比例、回归失败率或从发现到合并的时间分布。
这条边界很重要。公开流程自动化的是发现、可达性验证和补丁建议，最终合并权仍在人类工程师手中。Google 6 月披露的更完整安全流水线也采用相同关口：复现、映射执行路径、生成修复并运行回归检查后，只有通过验证的补丁才提交给人类。
Google 将其中一部分能力以 Mantis 开放出来。Google 6 月列出的流程包括威胁建模、研究、发现去重、复现和修复，并明确开源的是核心技能示例，内部运行的是功能更完整的版本。外部团队可以研究这套编排方式，却无法用公开 Mantis 复现数亿行内部代码上的 92% 和“每月数百个漏洞”。
可复制的是分层约束，不能直接复制 Google 的效果数字
这套设计给安全团队的可操作启示，是把生成式能力放在候选发现层，再用代码结构、调用关系和领域规则压缩误报；同时把开发、扫描和分诊的上下文与规则分开，避免同一个 Agent 自己提出结论、再用同一套推理为自己背书。局部威胁模型还需要随代码和依赖持续更新，否则确定性验证只会精确地执行过期假设。
是否值得把它接入每次提交，最终取决于 Google 尚未公开的四组数据：端到端召回率、不同严重度下的误报与漏报、延迟和算力成本分布，以及工程师对修复建议的实际采纳率。92% 说明结构化分诊可能把告警质量推到开发者愿意处理的水平；只有这些缺失指标补齐，才能判断它是否也提高了整体漏洞覆盖率。
Google 这次披露的关键，不是安全 Agent 已经替代人工，而是模型要进入高频生产链路，必须先接受另一层可检查程序的约束。真正的考验将发生在那层约束之外：系统遗漏了什么，以及人类最终愿意合并多少修复。
