google/mantis：把安全审计拆成可编排的 AI 技能链，代价是隔离环境
A modular, stack-agnostic toolkit of security review skills for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.
秒懂
- 它是什么？
- Mantis 是 Google 开源的一套面向编码代理的安全审计技能集，用顺序执行的斜杠命令串起威胁建模、复现与打补丁。它不绑定具体代理框架，但 README 反复强调一件事：必须跑在隔离环境里。
- 适合谁用？
- 适合已经在用编码代理、并且手上有一台可以随便跑坏的一次性虚拟机或云沙箱的安全团队与平台工程团队。不适合把生产机器当实验台的人，也不适合希望拿到确定性扫描结果、直接批量提交给开源维护者的人。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 3 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是代理缺流程，而不是缺模型
让编码代理去读代码找漏洞，难点从来不在模型看不看得懂，而在它看完之后干什么。单轮对话里，代理往往给出几条泛泛的可疑点就结束了，既没有复现步骤，也没有补丁，人还得从头接手。Mantis 把这件事拆成一条顺序流水线：先做威胁建模和规划，再定位、复现、复核，最后生成补丁。每个阶段是一个独立的技能，README 把它们称为 skills，并明确说这是一套起点而不是固定指令，使用者应当按自己组织的软件或硬件栈去改写。目标读者因此很具体：已经在用 Gemini CLI、Antigravity CLI 或别的编码代理框架，并且愿意花时间调提示词和规则的安全工程师。仓库 topics 里同时列了 sast、threat-modeling 和 multi-agent-systems，说明它想覆盖的是从建模到静态分析的整段流程，而不是替代某个现成的 SAST 引擎。
顺序流水线与阶段之间的契约
README 把架构细节放进了 README_AGENTS.md，正文只给了一句概括：解耦、顺序、面向安全。可确认的机制是阶段之间通过契约传递结果，每个技能有明确的输入输出边界，因此可以单独替换某一环而不动其他环。这种设计的好处是调试粒度细，你可以只跑规划阶段看威胁模型是否靠谱，也可以跳过复现直接进复核。代价是上下文要在阶段之间显式传递，代理不会自动记住上一阶段的推理，任何契约写得不清楚，后一阶段就会拿到残缺的输入。README 建议用 AI 来迭代这些技能本身，并把自己的内部文档、编码规范和构建系统塞进威胁模型里，这实际上承认了默认技能对具体代码库的了解是有限的，需要外部材料补足。
安装与第一次运行：从 npx 到斜杠命令
安装方式在 README 里只有一行命令：npx skills add google/mantis，可以全局装，也可以只装到某个工作区。装完之后，代理里会多出若干斜杠命令，README 举例的是 /mantis-plan。官方推荐的第一步是交互模式：在平常的开发流程里启动编码代理，然后一条一条手动输入这些命令，而不是一次性放开。README 明确点名不要使用 --yolo 或 --dangerously-skip-permissions，也不要配置任何形式的自动批准，原因是 /mantis-reproduce 和 /mantis-patch 这两个阶段会写文件、会执行代码，人需要在执行前看到代理打算跑什么。除 Docker 之外，README 建议注册 gVisor 的 runsc 运行时，给出的命令是 sudo runsc install -- --network=none && sudo systemctl restart docker，或者写进 /etc/docker/daemon.json，在 runtimes 下加一个 runsc 条目，runtimeArgs 设为 --network=none。这两个阶段的技能被要求把载荷放进禁网容器里执行，但 README 同时提醒，代理是非确定性的，可能跳过这一步，所以边界还得靠外部环境兜住。
模型分级与负向过滤：省钱的两种办法
README 里有两条务实的效率建议。一条是模型分级：不需要每个阶段都用最强的前沿模型，应该按任务把模型档次和阶段配对，具体对应关系放在 README_AGENTS.md 的模型选择章节。另一条针对误报。AI 扫描必然产生误报，Mantis 的处理方式是在复核阶段用负向规则过滤，README 称之为 negative filter，并建议把 /mantis-review 里的负向验证规则改成贴合自己代码库的版本。这两条建议放在一起看，指向同一个现实：流水线跑得动不难，跑得准要靠人调。README 还给了节奏上的建议，先用小范围扫描把流水线调顺，不要第一天就做全仓库扫描。这等于承认默认配置下的信噪比不足以支撑大规模扫描。
README 自己划出的边界：非确定性、误报与不可外推的结论
这份 README 在免责声明上的措辞比多数开源项目重。它写明模型是非确定性的，会幻觉出发现，也会生成错误的补丁；所有发现必须由安全专家人工核实后才能上报；不要把未经核实的 AI 报告批量提交给开源维护者。更关键的一句是：自动复现失败不能断定是误报，复现成功也不代表该漏洞在所有场景下都可利用。这句话实际上否定了把 Mantis 当成判定器的用法，它产出的是线索而不是结论。另一个硬约束来自开头的警告：只能在隔离、受限的环境里使用，绝不要在能访问生产系统、敏感数据或内部网络的机器上运行，无人值守的云部署另有强制加固要求。换句话说，如果团队没有现成的一次性沙箱，Mantis 的前置成本不在安装，而在环境。
和传统 SAST 的分工，不是替代关系
把 Mantis 和 Semgrep、CodeQL 这类规则驱动或查询驱动的静态分析放在一起比较，差别在输出形态。传统 SAST 给出的是确定性的匹配结果，同一条规则在同一个提交上跑两次结果一致，误报靠规则调优来压，代价是发现不了规则没写过的问题类型。Mantis 走的是另一端：代理读代码、推理、尝试复现，能碰到规则覆盖不到的逻辑漏洞，代价是结果不可重复，且必须人工复核。仓库 topics 里同时挂着 sast 和 llm，但 README 没有任何地方声称要取代 SAST 工具，它把自己定位成起点和可改编的技能集。实际用法更接近互补：让规则引擎守住已知模式，让 Mantis 去啃需要跨文件推理的部分，再把它的输出丢回人工验证流程。
维护成本、许可与适配工作量
Mantis 采用 Apache-2.0，商用和修改都可以，但具体条款以仓库中的 LICENSE 文件为准，这里不做法律判断。真正影响长期成本的是它的可改编定位。README 说这套技能应当按组织的技术栈调整，还专门提到可以适配硬件/RTL、基础设施即代码、ML 流水线、编译固件等专门领域。这意味着默认技能不是拿来即用的成品，而是一份需要持续维护的提示词与规则集合：代码库变了，威胁模型要跟着改；负向过滤规则松了，噪声上升，紧了，真问题被挡掉。仓库在 2026 年 9 月仍有提交，但没有检索到正式 release，所以升级方式是跟随主分支，改动可能随时到来，团队需要自己决定固定在哪个提交上。对只想装一个工具然后忘记它的人来说，这套东西的维护负担会超出预期。
编辑结论
适合已经在用编码代理、并且手上有一台可以随便跑坏的一次性虚拟机或云沙箱的安全团队与平台工程团队。不适合把生产机器当实验台的人，也不适合希望拿到确定性扫描结果、直接批量提交给开源维护者的人。上手前先确认三件事：你的代理框架能否识别 /mantis-plan 这类斜杠命令；Docker 是否已经按 README 的示例注册了带 --network=none 的 runsc 运行时；以及 /mantis-review 里的负向过滤规则是否改成了你代码库的形态，否则第一轮扫描的噪声会盖过信号。
社区笔记