认识 Mantis
先说个让人有点下不来台的数字。
Google 在官方博客里白纸黑字写着：草率的 AI 代码扫描，真阳性率可以低于 7%。翻译一下就是——你让大模型把仓库扫一遍，它兴冲冲给你列出 100 个"高危漏洞"，其中 93 个是它自己脑补出来的。
我有过亲身体验。某次让 AI 审一个内部服务，它信誓旦旦指出某处 SQL 拼接存在注入，还附上了大段分析。我照着路径翻过去，那个函数压根没接收任何外部输入，参数全是内部枚举。那一刻的心情，就像被人拉去看了一场 VIP 专场演出，结果发现是放映员在放空胶片。
所以当 Google 在 2026 年 6 月把这个叫 Mantis 的东西丢到 GitHub 上、又在 9 月初补了一篇官方入门博客时，我的第一反应是：终于有人肯承认"AI 扫出来的漏洞不一定是真的"这件事了。
Mantis 真正的设计哲学不是"让 AI 更会找 bug"，而是"不信任 AI 说的每一个 bug"。它把整条流水线建在对模型第一直觉的不信任之上——层层 critic、强制沙箱取证、默认人工审批。这跟市面上那些卖"AI 帮你找漏洞"的自信话术，是两种完全不同的姿态。
什么是 Mantis
Mantis 是 Google 开源的一套模块化、与语言栈无关的安全审计技能集（skills），给 AI 编码 Agent 用，让它们能自主地**发现（find）、复现（reproduce）、修补（patch）**软件漏洞。
仓库地址：github.com/google/mantis，协议是 Apache 2.0，截至 2026 年 9 月中旬 star 数已经冲到 1500 左右。
它不是传统意义上的扫描器。你不会找到一个 mantis scan 然后吐 PDF 报告的东西。Mantis 的本体是一堆目录——每个目录是一个 skill，本质上是一份结构化的 Markdown 指令。任何支持斜杠命令（slash command）的编码 Agent 都能把这些目录加载进去，然后 Agent 就知道该怎么一步步干活了。
官方管这个叫 harness（驭具），我觉得"驯兽师的缰绳"这个意象挺准：模型是那头力气很大但方向感堪忧的野兽，Mantis 是套在它身上的流程。
它解决的核心矛盾是：AI 已经能把攻击做得很快了，而防御还停在"扫完一堆告警让人肉筛"的原始阶段。Mantis 想做的是把防御侧也拉到机器速度。
Mantis 的特点
- 全生命周期自动化，不止是"扫描"：从翻仓库历史、建语义索引、生成威胁模型，到找漏洞、去重、批判、沙箱复现、打补丁、复现验证、风险定级、沉淀经验，一条龙走完
- 会自己写威胁模型：这点很反常识。你的项目没有架构文档、没有威胁模型？Mantis 读代码和提交历史，自己给你生成一份 Markdown 知识库和
THREAT_MODEL.md，连信任边界和攻击者画像都推导出来 - 分层安全摘要树，token 开销降 85%+：把单个文件浓缩成目录级摘要、再聚合成仓库级摘要，AI 先看全局再按需下钻细节。官方数据是 token 开销降低超过 85%，同时保留关键结构上下文——这是它敢啃大仓库的经济学前提
- critic + review 双 Agent 过滤幻觉：
mantis-review用规则化负向过滤掉明显误报，mantis-critic干掉"技术上成立但生产环境不成立"的发现（比如只有 debug 模式才走得到的路径） - 沙箱复现才算数：
mantis-reproduce会真的写一个 crash PoC，丢进 gVisor（runsc）容器或者禁用网络的虚拟机里跑起来。跑不崩，这个 finding 就不算数——信任边界是证据，不是模型的置信度 - 补丁要过对抗性回归：
mantis-patch打完补丁不算完，它会换个变体 payload 重新攻击一次，确认补丁不是"绕过型修复"，而是真把崩溃路径堵死了 - 风险定级对抗 LLM 通货膨胀：
mantis-calibrate按固定 rubric 从影响面、证据强度、可利用性三个维度打 1–10 分，避免模型把所有东西都标成"critical"——毕竟一万个 critical 等于零个 critical mantis-chain能串漏洞链：把几个各自确认过的小问题，静态拼装成一条多步利用链。注意是"静态确认"，不会真跑端到端mantis-advise反向用：这是最有意思的一个。别的 skill 是"审已写的代码"，它是"写代码前先查一遍历史漏洞谱系和威胁模型"，防止同一个坑踩第二次——把安全左移到了代码诞生之前- 模型可以分阶段换：官方明确建议"flash/lite 类小模型干快速分类和聚类，前沿大模型留给写 PoC 和打补丁"。不是为了省钱，是为了速度和质量的平衡
- 与框架解耦：官方给了 ADK 参考实现，但兼容 Gemini CLI、Antigravity CLI、Google ADK、Antigravity SDK，任何支持 slash command 的 Agent 都能改过去
- 能往专业领域长：官方文档点名了硬件/RTL、基础设施即代码（IaC）、ML 流水线、编译固件这些方向都能适配
谁在用、用在哪
Google 自己。 这是最关键的一条。Mantis 不是实验室玩具，它是 Google 内部"以机器速度找漏洞、修漏洞"方法论的一部分，官方博客的原话是：这个 prompt 在 Google 内部已经用它在自家仓库里找到了真实漏洞。
除了 Mantis 这个发现与修复内核，Google 内部还有更大的一盘棋：用 200+ 项控制清单卡产品发布的 Agent、能自己写并修复测试脚手架的自愈式模糊测试循环、盯着生产环境配置漂移的自主姿态管理系统。Google 给这套终局起了个名字，叫**"immune software"（免疫式软件）**——应用能持续地自己发现、验证、修补弱点。
要泼一盆冷水：这个"免疫系统"的大叙事是 Google 的内部路线图，不是你今晚 clone 下来就能跑的东西。开源出来的只是发现与修补的核心。
具体怎么落地，几个典型姿势：
- 安全工程师 / DevSecOps：手上有个几十万行的老仓库，人工审计排期排到明年。先跑
mantis-plan生成一份审计路线图，再针对性 sweep，比"每个文件都过一遍"省的不止一点半点。 - 开源项目维护者：这是我最想安利的场景。以前你得在 issue 区跟 AI 生成的垃圾漏洞报告搏斗；现在你可以自己先跑一遍 Mantis，把沙箱复现过的真问题先修掉。顺带说一句，Google 在仓库里明确写了：别把未经人工验证的 AI 报告批量砸给开源维护者——这条约束本身就很值得某些"安全创业公司"抄进自家行为准则。
- 日常开发：
mantis-advise挂在 Agent 会话里，写高风险模块（鉴权、反序列化、文件上传、SSRF 高发区）之前先问一句，比事后修便宜太多。 - 做 Agent 的人：就算你完全不关心安全，
reference/workflow.json也值得读一遍。它演示了怎么用 ADK 编排一个长会话、多阶段、带共享磁盘状态的 Agent 工作流——这是目前公开的、少见的、能直接抄的复杂 Agent 编排范例。
横向对比：Semgrep 这类传统 SAST 靠规则，漏报多但不会瞎编；纯 LLM 扫描覆盖面广但幻觉严重（真阳性率 <7%）；Mantis 走第三条路——用 LLM 做假设，用沙箱做裁判。代价是慢、贵、要隔离环境，收益是那份 findings 列表终于能看了。
Mantis 初体验
先说最重要的一句：别在有生产系统访问权限、敏感数据或内网可达的机器上跑它。 这不是免责声明式的客套，是 Google 在 README 顶部用 CAUTION 大字写的。
最省事的跑法，照抄官方 quickstart：
git clone https://github.com/google/mantis.git然后打开你常用的编码 Agent，直接说：
我想用
path/to/mantis里的 Mantis 框架来审查path/to/your/code里的代码，能帮我开始吗？
就这一句。Agent 会自己去读那些 skill 目录，然后一步步带你走。
如果你更想要开箱即用的参考实现（基于 Google ADK），仓库里带了完整的 harness：
# 先确保有 venv
sudo apt install python3-venv
cd reference && ./install.sh
# 用 Vertex AI 的话先登录
gcloud auth application-default login
# 1. 自动配置 + 能力探测（也可以 --interactive 走向导）
python3 scripts/configure.py --auto
# 2. 预检（约 1 秒）+ 连通性探测
python3 scripts/configure.py --test --probe
# 3. 发起一次漏洞审查（文件或整个目录）
./run.sh path/to/code
# 4. 或者针对特定目标做研究图合成
./run.sh path/to/code --objective "审计 webhook handler 里的 SSRF 问题"想手动控制节奏，就一个个敲 slash 命令，每个阶段自己审一遍再放行：
| 阶段 | 命令 | 产出 |
|---|---|---|
| 学习 | /mantis-history、/mantis-structural-index、/mantis-summarize、/mantis-architecture、/mantis-threat-model、/mantis-plan | 历史漏洞知识、代码摘要树、Markdown 知识库、威胁模型、审计路线图 |
| 发现 | /mantis-researcher、/mantis-dedupe、/mantis-review、/mantis-critic | 结构化 finding 记录，去重并过滤误报 |
| 证明 | /mantis-reproduce、/mantis-chain | 沙箱执行结果、多步利用链 |
| 修复 | /mantis-patch、/mantis-calibrate、/mantis-reflect、/mantis-report | 补丁 + 再攻击结果、1–10 风险分、经验沉淀、可读报告 |
跑全链路的话，用 /mantis-meta-agent 这个编排 skill，它会在一个长会话里把上面这些串起来。
几个我踩过（或者说看别人踩过）的坑：
- 别开自动批准。
--auto-approve之类的开关先别碰，交互式一步步确认，尤其在/mantis-reproduce和/mantis-patch要写文件、要执行代码之前。 - 沙箱要真隔离。 官方建议跑 AI 生成的 PoC 时禁用网络，比如用 Docker 的 runsc（gVisor）运行时配
--network=none。用前沿大模型的话，Google 说还得再加一层带逃逸监控的沙箱。 - 第一次别全仓库扫。 先挑一个窄范围跑，把
/mantis-review里的负向过滤规则按你的代码库调过一遍，噪声率下来再说。 - 复现失败 ≠ 误报，复现成功 ≠ 可利用。 这句话官方原文写得很清楚，值得贴在显示器上。
关于成熟度，说点不好听的
Google 在仓库的免责声明里写得毫不含糊：
这不是 Google 官方支持的产品。本项目不参与 Google 开源软件漏洞奖励计划。本项目仅用于演示目的，不建议用于生产环境。
翻译：它是个能跑、有真东西、思路非常领先的 demo，不是你可以塞进 CI 流水线然后放心睡觉的成品。所有 finding 都必须由安全专家人工复核——这是官方要求，不是建议。
但我倒觉得这种"诚实"是它最值钱的地方。一个安全工具敢在 README 第一屏写"别信我，去沙箱里证明给我看"，比一百个"准确率 99%"的宣传页都让人踏实。
进阶
想继续往深了挖，这几条路：
- 把
reference/workflow.json拆开读，理解多阶段 Agent 之间怎么靠磁盘共享状态通信 - 用
./run.sh target --objective "..."玩研究图合成，动态生成自定义拓扑，这东西的上限远不止安全审计 - 把
mantis-advise接进日常开发流，把安全真的左移 - 按官方建议，用你自己的编码规范、内部文档、构建系统去增强威胁模型，再按你的风险偏好重调
mantis-calibrate的评分标准
更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。