Mantis Skills：AI 编码代理安全审计工具包

想象一下：你的团队正在开发一个关键业务系统，代码每天都在迭代更新。传统的人工代码审计费时费力，而且容易遗漏。但如果有一个 AI 助手，能够像资深安全研究员一样，自动遍历代码、发现漏洞、生成 PoC、甚至写出补丁——那会是什么体验？ 这就是 Google 推出的 Mantis Skills 想要实现的目标。这是一个模块化的安全审计技能库，专为 AI 编码代理设计，让 AI 能够自主完成从漏洞发现到修复验证的全流程。

背景：从"人工审计"到"AI 自主审计"

代码安全审计一直是软件工程中最耗时的环节之一。根据行业报告，一个中等规模的代码库进行全面审计往往需要数周时间。而随着 AI 编码助手（如 GitHub Copilot、Cursor）的普及，开发者越来越依赖 AI 生成代码——但谁来审计这些 AI 生成的代码呢？ Google 的安全 AI 团队注意到了这个趋势。Mantis 最初是内部工具，用于对 AI 生成的代码进行自动化安全审查。2024 年底，Google 将其开源，希望推动 AI 安全生态的发展。 项目的核心设计理念是：安全审计不应该是一次性的静态活动，而应该是持续、自动化的过程。Mantis 的名字来自昆虫界的"祈祷螳螂"——精准、专注、致命（针对漏洞而言）。

架构设计：15 个 Stage 的接力审计流水线

Mantis 采用顺序流水线架构，将安全审计拆解为 15 个独立的 Skill 模块，每个模块专注完成一个特定任务，通过文件系统共享状态串联起来。这种设计有几个关键优势： 模块化 — 每个 Skill 独立运行，不依赖其他模块的具体实现，可以单独调试、替换或扩展。 可观测性 — 每个 Stage 的输出都写入磁盘（workspace/ 目录），用户可以随时检查中间结果，而不是面对黑盒输出。 可组合 — 支持选择性运行。用户可以只跑前几个 Stage 做快速扫描，也可以跑完整流水线做深度审计。 整个流水线分为三个阶段： 准备阶段（Snapshot Model）：/mantis-history（从 Git 历史提取历史漏洞）、/mantis-summarize（生成代码摘要）、/mantis-architecture（构建 Markdown 知识库）、/mantis-threat-model（威胁建模） 扫描阶段：/mantis-plan（制定扫描路线图）、/mantis-researcher（多线程漏洞扫描）、/mantis-dedupe（去重合并）、/mantis-review（假阳性过滤）、/mantis-critic（可行性评估） 验证阶段：/mantis-reproduce（在沙箱中运行 PoC 验证）、/mantis-chain（将单个漏洞串联成攻击链）、/mantis-patch（生成补丁并验证）、/mantis-calibrate（风险评级）、/mantis-reflect（从执行轨迹中学习）、/mantis-report（生成人类可读报告） 特别值得强调的是 Snapshot Model（快照模型）：这是 Mantis 针对"活代码库持续审计"这一场景设计的机制。每个 Pass 对代码库生成一个不可变的快照，所有 Stage 都在该快照上运行，避免审计过程中代码被修改导致的不一致。发现的所有漏洞都会标记对应的 discovery_commit，后续代码变更后可以精准判断哪些漏洞被修复、哪些需要重新验证。

核心技术：SKILL.md 作为 AI Agent 的"操作手册"

Mantis 最有意思的地方在于它的实现方式：整个项目几乎没有代码。所有 Skill 都是纯 Markdown 的 SKILL.md 文件，通过自然语言指令告诉 AI 代理该做什么、如何做、以及如何与相邻 Stage 协作。 安装方式也非常极简：npx skills add google/mantis。安装后，AI 代理通过 /mantis-xxx 命令调用对应的 Skill，类似于加载一个专用的"安全审计插件"。 这种设计的精妙之处在于： 零平台依赖 — SKILL.md 是纯文本，任何支持 Agent 的框架都可以加载（官方测试过 Gemini CLI、Antigravity CLI、Google ADK）。不绑定特定供应商。 指令即代码 — 传统的安全扫描工具（如 Semgrep、CodeQL）需要用户编写规则；Mantis 则反过来，让 AI 自己理解和生成扫描策略，SKILL.md 负责定义约束和质量门禁。 可自进化 — /mantis-reflect 会将执行轨迹中的经验写入 workspace/learnings.jsonl，/mantis-meta-agent 可以据此自动改进 SKILL.md 的指令（需人工审核）。未来甚至可以实现 Skill 的自我优化。

安全性设计：多层隔离防护

AI 自主执行代码的安全风险是显而易见的。Mantis 在设计上做了多层防护： 沙箱优先 — /mantis-reproduce 和 /mantis-patch 强制要求在隔离环境中运行生成的代码，默认使用 Docker 容器 + --network none，甚至推荐 gVisor（runsc）运行时提供更强的系统调用隔离。 人类在环 — 官方推荐的初始使用方式是 Interactive Mode（交互模式），每个敏感操作都需要人工确认后才执行。README 明确警告：永远不要在无法控制的网络环境或生产系统中运行此工具。 No Host-Run 规则 — AI 生成的代码必须进沙箱，不允许直接在宿主机执行。即使用户误操作，Agent 也会被指令拒绝执行。 Snapshot 隔离 — 审计过程在代码快照上运行，不会意外修改工作目录中的真实代码。 但 Mantis 也坦诚地指出局限性：AI 的非确定性意味着 Agent 可能偶尔绕过约束指令。工具提供的是"合理的安全保障"而非"绝对安全保证"。

适用场景与局限性

Mantis 最适合的场景：

• CI/CD 安全门禁：将 Mantis 集成到代码提交流水线，自动扫描新 PR 中的安全漏洞
• 开源依赖审计：对第三方库或 AI 生成的代码进行黑盒安全评估
• 固件/二进制审计：通过 Gray-Box 模式，无需源码即可进行安全分析
• 硬件安全审计：扩展到 RTL 设计、硬件描述语言的安全属性检查 Mantis 的局限性：
• 假阳性不可避免：AI 会产生误报，需要人工复核。/mantis-critic 和 /mantis-review 阶段专门负责过滤，但无法完全消除。
• 不适用于快速开发阶段：完整流水线执行时间较长，不适合每次代码变更都跑全程。
• 依赖强模型：简单模型可能无法正确执行复杂的多 Stage 推理，建议使用 Gemini Flash 2.0 及以上级别。
• 非生产级保证：README 明确标注"这不是 Google 官方支持的产品"，不适合直接用于高安全合规要求的生产系统。

技术规格一览

总结

Mantis 是 AI 安全领域的一个创新实验：它不是又一个代码扫描工具，而是一个让 AI 来审计 AI 代码的框架。通过 15 个精心设计的 Stage，它把安全审计从专家专属的能力，变成可以被自动化编排的工作流程。 尽管存在假阳性和非确定性风险，但其 Snapshot Model、多层沙箱隔离、以及对人类在环的强调，都体现了对安全性的认真态度。对于希望在开发流程中加入自动化安全审计的团队，Mantis 是一个值得关注和实验的方向。 图1：Google Mantis 项目由 Google 安全 AI 团队维护