当写代码的速度超过读代码的速度
过去一年，AI 编程工具把「产出代码」这一步压缩得很厉害。一个需求从描述到拿到可运行实现，时间从几天变成几十分钟。但代码写完之后的环节并没有同步提速：谁来判断这段代码有没有安全问题、谁来判断某个可疑写法到底是不是真漏洞、谁来验证修好了没有。
传统做法是三条腿：写更多测试、跑静态扫描、请同事做代码评审。这三条路都有效，但它们共享同一个特征——属于「检查」。检查会告诉你哪里可能有问题，不会证明问题确实存在。当代码产出量上升一个量级，检查环节的成本会跟着线性上升，而它给出的信号质量并没有变好。
Google 近期在 GitHub 上开源了 Mantis，切入的正是这个错位。它不是一款独立的扫描器，而是一套由现有编码智能体加载的模块化技能工具包，让智能体跑完一条完整的漏洞生命周期：先了解代码库，再找可疑缺陷，然后在隔离环境里把漏洞真正复现出来，再写补丁，并对补丁发起二次攻击验证。按公开说明，项目采用 Apache 2.0 许可，当前定位为本地与内部评估用途，不建议直接用于生产环境。
那组被反复引用的数字
理解 Mantis 的设计动机，需要先看它要解决的那个问题有多具体。Google 在公开说明中提到，简单式的 AI 代码扫描真实正例率低于 7%。换句话说，模型报出的大量问题属于「声称有漏洞、实际并不存在」，而排查这些误报本身需要投入人力，整体效率可能低于人工审查。
这组数字的含义值得展开。低正例率并不主要说明模型不够聪明，而是说明任务定义有问题：判断「这段代码有没有漏洞」需要跨越大量上下文——这个函数被谁调用、输入从哪来、运行时权限是什么、依赖的库有没有已知问题。让模型在有限上下文里给出结论，结果自然偏向猜测。
Mantis 的应对方式不是让模型看得更多，而是把判断拆成一系列可验证的小步骤，并让其中最关键的一步落在沙箱里完成。这一步是整个设计的重心：不再依赖模型对自身判断的置信度，而是要求给出可运行的证据。
四类角色，各管一件事
按公开材料，Mantis 在多角色协作上的分工比较清晰。
策略师角色负责看全局。它评估代码库的高层结构、威胁模型与依赖关系图，产出后续阶段的路线图。它回答的是「这套系统里哪些地方值得花力气看」，而不是「这里有没有 bug」。
研究者角色负责深挖。它通过内部代码搜索对源文件做深入检查，追踪数据流、控制流与数据净化逻辑，把可疑点找出来。这一阶段的取向是宁可多报——漏掉一个真问题的代价，通常高于排查一个假问题。
审查者与批评者角色负责收口。两者是相互独立的智能体，一个找问题，一个专门论证问题不存在。这种对抗性审查的作用是压低误报：当结论需要同时经受住「找」与「驳」两种压力时，留下来的问题质量会明显提高。
沙箱负责给证据。可疑发现会被放进网络禁用的隔离环境里尝试复现，能跑通才保留，跑不通就标记为不成立。Google 同时提到会用到基于 gVisor 的沙箱或虚拟机方案。这一阶段是整条流水线里最硬的部分，因为它把「模型认为」换成了「实际发生」。
十五个阶段与技能目录
Mantis 把每个阶段发布成独立的技能目录，通过斜杠命令调用，再按顺序串起来。此外还有一个监督型技能用于在长会话中驱动整个闭环。按公开说明，可用的工具超过 15 种。
早期阶段用于建立认知：挖掘版本控制历史中的过往安全修复、生成目录图谱、构建 Markdown 知识库、推导信任边界、产出有针对性的排查计划。中期阶段用于查找与过滤：按计划扫描文件，然后合并重复项、应用排除规则、剔除那些在生产构建中根本不可能出现的问题。后期阶段用于验证与修复：在隔离环境里执行载荷、从已单独确认的发现中组装多步利用链、应用并验证修复、给出风险评分、把学习结果回写供下一轮使用、生成人类可读的审查资料包。
其中有一个阶段的设计值得单独提出来：它反向了整个流程。这个技能会在写代码之前查询积累下来的威胁模型、历史缺陷谱系与已验证的补丁模式，用来避免同类缺陷再次出现。也就是说，整套系统不只是事后审查，也尝试把历史结论前置到编码环节。
分层摘要树：把上下文成本压下来
大型代码库有一个绕不过去的问题：把仓库完整塞进上下文，代价高到不可行。Google 的做法是先把分析过的文件汇总成一棵包含目录级与代码库级上下文的分层树，再让后续阶段读这棵树而不是逐个读文件。按公开说明，这种方式在保留关键结构信息的同时，把令牌开销降低了 85% 以上。
这个设计的意义不止于省钱。当上下文预算被压缩之后，智能体可以处理的仓库规模上限随之提高——原本因为装不下而放弃的中大型仓库，变得可以进入分析范围。对企业而言，这决定了工具是只能用在单个服务上，还是能覆盖整个代码库。
阶段间契约：一个容易被忽略的细节
这套工具包里有一个设计取向值得留意：它公开了阶段之间的契约，使团队可以围绕这些技能构建确定性的执行框架，而不是直接让一个大模型去编排 shell 命令。
这个区别在工程上很重要。让模型自由决定下一步执行什么命令，灵活度高，但可复现性差——同样的输入两次运行可能走不同路径，出问题也难以归因。把每个阶段的输入输出固定下来，等于把「模型判断」限制在阶段内部，阶段之间的流转是确定性的。这样做牺牲了一部分灵活性，换来了可测试与可审计。
同时，工具包强调用严格规则限定智能体允许在哪里执行代码，并把复现与再攻击步骤当作信任边界来对待。这两点是配套的：既然复现阶段要真的跑起攻击载荷，那么执行位置的约束就必须是硬性的。
中立思辨
需要辩证看待几件事。其一，真实正例率低于 7% 这个数字来自 Google 自身的口径，未说明统计的样本、扫描器与判定标准。把它当成「所有 AI 代码扫描都不行」的结论并不严谨，但它确实指出了问题定义层面的缺陷，这一点有参考价值。
其二，15 个阶段的流水线提高了结论质量，也提高了单次分析的资源消耗。对小型仓库而言，跑完整条流水线的成本可能高于收益。更现实的用法是分层使用：日常提交只跑轻量的可疑点扫描，重要版本发布前才走完整闭环。
其三，多角色对抗审查能压低误报，但不消除误报。批评者与审查者本身也是模型驱动的，它们会各自带上自己的偏差。行业已有的经验是，对抗式设计在明显错误上效果好，在边界模糊的问题上仍需要人工兜底。
其四，沙箱复现是最有价值的一步，也是适用范围最窄的一步。逻辑缺陷、权限设计错误、业务规则冲突这类问题，很难用一段可运行的攻击载荷证明。工具在「可利用的漏洞」上表现最好，在「设计层面的隐患」上帮助有限。
其五，项目当前定位为内部评估工具，尚不建议用于生产。这意味着它更适合作为团队安全流程里的一环，而不是替代既有扫描与评审。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给安全团队的四条做法
把 Mantis 背后的思路拆出来，有四条不依赖该工具也能用。
把「有没有漏洞」改写成「能不能复现」。在提交缺陷之前先要求一段可运行的证明，哪怕只是一段最小化脚本。这条规则本身就能过滤掉相当比例的误报。
让审查者与提出者分开。同一个人或同一个提示词既找问题又论证问题，很容易陷入自我确认。把这两个角色拆给不同的会话或不同的模型，结论质量会明显不同。
给上下文定预算。不要指望把整个仓库塞进一次分析。先做目录级与模块级的摘要，再按需下钻，是更可持续的做法。
把结论写回流程。每一次确认过的缺陷与验证过的补丁，都应该变成下次编码前可查询的资料。审查的价值不只在拦下这一次问题，更在于减少下一次同类问题的发生。