google/mantis

# Mantis Skills：构建安全审查工具套件的便携式工具包 Mantis Skills 是一套解耦、顺序化且聚焦于安全的 **Skills** 集合，专为 Coding Agents 设计。它旨在提供一个**灵活的基础和起点**，而非一套死板的指令。您应该根据您所在组织的特定软件或硬件技术栈，对这些 skills 进行调整、调优和扩展。 例如，虽然默认的 skills 会查找通用的安全问题、业务逻辑缺陷和授权漏洞，但它们也可以被适配用于： * **硬件 / RTL 审查**：审计寄存器传输级 (RTL) 设计（SystemVerilog、VHDL）的安全属性或逻辑 bug。 * **基础设施即代码**：分析云部署边界、Terraform 状态或 Kubernetes RBAC 配置中的提权路径。 * **数据与 ML Pipelines**：审计训练数据的输入、模型序列化格式（例如 Pickle 漏洞），或数据科学 notebook 与生产环境之间的边界约束。 * **编译型二进制文件与固件（灰盒审计）**：在不提供源代码的情况下，将该套件指向编译好的发布产物（使用诸如 `unblob`、`Ghidra`、`radare2`、`qemu` 或 `unicorn` 等工具）。此模式的意图是模拟第三方安全研究人员，让您确切了解只能访问您发布二进制文件的对手能发现哪些漏洞。 * **自定义测试环境**：将默认的容器复现阶段替换为隔离的 VM、物理硬件测试平台（通过 USB/串口）或自定义模拟器。 我们强烈建议使用 AI 来迭代这些 skills，并使用您的内部文档、编码标准和构建系统来增强威胁模型。我们也强烈建议您根据自身环境和风险承受能力调整风险校准。 有关保护 AI 系统的更多信息，请参阅 Google 的 [Secure AI Framework (SAIF)](https://safety.google/safety/saif/)。 该套件使任何拥有 agentic 编码工具的人都能系统地审查、去重、验证、批判、复现和修补任何规模的代码库。 它还具有一个持续学习循环，允许套件在迭代运行中进行适应，并避免冗余分析。 最重要的是，虽然编排式的漏洞发现极其强大且有用，但在适当隔离的环境中使用它以防止影响生产系统则更为重要。请参阅本指南后面关于无人值守云部署的说明。 ## 架构与顺序流 该 pipeline 由十五个不同的组件组成（一个 supervisor 和十四个执行阶段），通过一个漏洞文件目录（`workspace/findings/*.json`）维护状态。整个过程可以由全局 **`/mantis_meta_agent`** 自主监督。 ``` graph TD Meta["/mantis_meta_agent (Supervisor)"] subgraph "Continuous Review Loop" Hist["/mantis_history (Optional)"] Sum["/mantis_summarize (Optional)"] Arch["/mantis_architecture"] TM["/mantis_threat_model"] Plan["/mantis_plan"] Res["/mantis_researcher"] Ded["/mantis_dedupe"] Rev["/mantis_review"] Cri["/mantis_critic"] Rep["/mantis_reproduce"] Cha["/mantis_chain"] Pat["/mantis_patch"] Cal["/mantis_calibrate"] Ref["/mantis_reflect"] end FileHist[("historical_learnings.jsonl")] FileSum[("mantis_summary.md")] FileKB[/"workspace/kb/ (Markdown KB)"/] FilePlan[("plan.json")] FileFind[("workspace/findings/*.json")] FileLearn[("learnings.jsonl")] Meta --> Hist Hist --> Sum Sum --> Arch Arch --> TM TM --> Plan Plan --> Res Res --> Ded Ded --> Rev Rev --> Cri Cri --> Rep Rep --> Cha Cha --> Pat Pat -.->|Re-attack Bypass Loop| Rep Pat --> Cal Cal --> Ref Ref -.->|Next Loop Iteration| Arch Hist -.->|Generates| FileHist Hist -.->|Reads| FileSum Sum -.->|Reads| FileHist Sum -.->|Generates| FileSum Arch -.->|Reads| FileHist Arch -.->|Generates| FileKB Arch -.->|Reads/Clears| FileLearn TM -.->|Reads/Updates| FileKB Plan -.->|Reads| FileKB Plan -.->|Reads| FileSum Plan -.->|Generates| FilePlan Res -.->|Reads| FilePlan Res -.->|Reads| FileKB Res -.->|Creates| FileFind Ded -.->|Reads| FileLearn Ded -.->|Merges| FileFind Rev -.->|Updates| FileFind Cri -.->|Updates| FileFind Rep -.->|Updates| FileFind Cha -.->|Reads| FileKB Cha -.->|Creates| FileFind Pat -.->|Updates| FileFind Cal -.->|Updates| FileFind Ref -.->|Parses Trajectories & Appends| FileLearn Cri -.->|Appends| FileLearn Pat -.->|Appends| FileLearn ``` 1. **`/mantis_meta_agent` (Supervisor)：** 一个持久的、全局的 agent，负责启动持续循环、监控执行、处理错误、报告结果并在循环间归档 `workspace/findings/` 目录。 2. **`/mantis_history` (历史提取器)：** 一个可选的预处理步骤，通过分析代码库的版本控制系统 (VCS) 历史记录来提取过去的漏洞、安全修复和漏洞模式，并将结果保存到 `historical_learnings.jsonl`。 3. **`/mantis_summarize` (摘要器)：** 一个可选的预处理步骤，为每个目录生成 `mantis_summary.md`，从 `historical_learnings.jsonl` 读取过去的漏洞以丰富摘要，并提供快速的参考映射，从而优化下游的规划和研究。 4. **`/mantis_architecture` (知识库架构师)：** 分析代码库并清空 `learnings.jsonl` 收件箱，以合成一个永久的、互链的 Markdown 知识库 (`workspace/kb/`)，详细记录实体、数据流和历史漏洞类别。 5. **`/mantis_threat_model` (威胁建模器)：** 评估 KB 中定义的实体和架构，以建立或完善动态的 `workspace/kb/THREAT_MODEL.md`，重点关注信任边界和攻击者配置文件。 6. **`/mantis_plan` (策略家)：** 扫描工作区边界并读取 KB 索引，将针对性的审查策略输出到 `plan.json` 中，注入特定的 `kb_references` 文件路径作为上下文。 7. **`/mantis_researcher` (Mantis 研究员)：** 执行逐文件的分类和深度安全缺陷审查，将热点以单独的 JSON 文件形式输出到 `workspace/findings/`。 8. **`/mantis_dedupe` (去重器)：** 对基于索引的重复漏洞进行分组，合并记录并删除 `workspace/findings/` 中的冗余项。 9. **`/mantis_review` (验证器)：** 使用严格的实用约束过滤误报，更新 `workspace/findings/.json` 中的状态。 10. **`/mantis_critic` (批判者)：** 验证发布版本崩溃的可复现性（忽略 debug/assert 检查），更新 `workspace/findings/.json` 中的生产可行性，并将误报/不可行路径追加到 `learnings.jsonl`。 11. **`/mantis_reproduce` (概念验证开发者)：** 编写概念验证复现脚本或原始 payload，在 gVisor 或虚拟机等隔离环境中执行它们，并更新 `workspace/findings/.json` 中的复现状态。 12. **`/mantis_chain` (漏洞链接器)：** 分析单个已验证的漏洞和知识库原语，以识别并构建复杂的多步漏洞利用链，在 `workspace/findings/` 中创建新的“超级漏洞”。 13. **`/mantis_patch` (修补程序)：** 生成并应用代码修复，在 sandbox 内运行补丁后验证测试，更新 `workspace/findings/.json` 中的补丁状态，并将日志追加到 `learnings.jsonl`。 14. **`/mantis_calibrate` (风险校准器)：** 根据影响、证据和可行性，为工作区目录中的每个漏洞计算最终的 Mantis 数值风险评分 (1-10)，并将结果直接追加到每个 `workspace/findings/.json` 文件中。 15. **`/mantis_reflect` (反射器)：** 解析当前循环中 agent 的执行轨迹，提取错误假设、工具失败和成功经验，并将这些结构化的见解追加到 `learnings.jsonl` 收件箱。 ## 前置条件与设置 在执行任何 skills 之前，请确保您的本地 CLI 环境已完全配置： 1. **已安装 Gemini CLI 或 Antigravity CLI。**（其他的应该也可以）。 2. **已安装并正在运行 Docker**（本地“sandboxed”执行所需）。 3. **已安装 gVisor (runsc) 并在 Docker 中注册（推荐）**：为了在执行不受信任的 AI 生成的崩溃复现代码时增强安全性，请在您的 Docker daemon 配置 (`/etc/docker/daemon.json`) 中注册 `runsc` runtime： { "runtimes": { "runsc": { "path": "runsc" } } } 重启 Docker 以应用更改：`sudo systemctl restart docker`。 4. **相关的 Cloud SDK**：如果您运行的是远程云 sandbox 而不是本地容器。 ### 安装 Skills 您可以选择全局安装这些 skills（在所有项目中可用），或者在本地安装到特定的工作区。您也可以向您的 coding agent 寻求帮助。 ## 新手指南与最佳实践 如果您刚接触自动化的 AI 辅助防御性安全审查，请牢记以下建议： ### 1. “交互模式” (Human-in-the-Loop) * **它是什么：** 对于尚未准备好部署完全无人值守、长时间运行 pipeline 的用户或组织，您应该在“交互模式”下运行 pipeline。 * **如何使用它：** 正常启动您的 CLI（例如，在终端中输入 `agy` 或 `gemini`）。然后，在交互式聊天 UI *内部*，逐个输入斜杠命令（例如 `/mantis_plan`）。启动 CLI 时不要使用 `--yolo` 或 `--dangerously-skip-permissions` 标志。 * **为什么这很重要：** 在执行任何敏感命令之前（尤其是当 `/mantis_reproduce` 或 `/mantis_patch` agent 尝试运行 Docker sandbox 执行或写入文件时），CLI 将暂停并提示您进行人工批准。这允许您检查 AI 打算运行的内容。要在没有人工批准的情况下运行，您将需要更强的边界来限制 agent。 ### 2. 强化安全与“禁止主机运行”规则 * **为什么这很重要：** AI 模型有时会生成破坏主机的代码 payload。如果您不仔细阅读它们，请*仅*在 sandbox 内运行脚本。 * **Mantis 保护：** 明确指示 `/mantis_reproduce` 和 `/mantis_patch` skills 在禁用网络（例如 `--network none`）的隔离容器环境中执行 payload。 * **免责声明：** 虽然这些指令旨在维持隔离，但 **AI agent 是非确定性的**。如果本地环境允许，它们偶尔可能会尝试不安全的操作或绕过预期的约束。这些指令并不提供绝对的安全保证。请务必优先在专用的、隔离的 VM 中运行此套件（参见下文的 GCE 部分），以提供一个 AI 无法逃脱的合理安全边界。 ### 3. 模型选择与分层效率 为了最大化您的自动化 pipeline 的速度和效率，您应该战略性地将合适的 AI 模型类别与特定任务相匹配。您不需要在每个阶段都使用最重、最先进的 frontier models： * **第一层 (分类与去重)：** 对于快速分类扫描（例如 `/mantis_researcher` 的第一波）或聚类相似文本模式 (`/mantis_dedupe`)，请选择快速的 "flash" 或 "lite" 层模型。这些任务不需要极深的逻辑，只需快速解析文本，让您能够并行处理大规模文件扫描而不会产生瓶颈。避免使用功能极弱以至于难以执行基本指令的模型，但也不要因为在这里分配了过多的智能而拖慢您的 pipeline。考虑允许 planner 为特定的研究任务指定难度级别，从而将简单问题分配给更快的模型，同时让一些更复杂的漏洞发现任务受益于最先进的 frontier models。 * **第二层 (深度推理)：** 将您最强大、具有重型推理能力的旗舰模型用于需要深度上下文和零样本问题解决的高度复杂阶段：`/mantis_reproduce`（编写功能性崩溃复现器）和 `/mantis_patch`（编写无副作用的代码库修复）。 * **提示：** 对于非常大的代码库，配置您的计划 `/mantis_plan` 以专注于特定的高风险子文件夹（例如 `src/crypto/` 或 `api/`），以保持扫描的专注和高效。 尝试在 pipeline 的不同部分使用不同层级的模型，看看哪种效果好，哪种效果不好。 ### 4. 理解误报（“否定过滤器”规则） * **预期情况：** AI 扫描器可能会过于热衷。为了解决这个问题，`/mantis_review` 阶段运行了一个应用 12 条否定规则的严格验证器。（这 12 条规则绝非一成不变，必须根据您的用例进行调整、重构，甚至拆分到不同的阶段中。） * **低风险/加固风险不是误报：** 有效的风险校准作为漏洞分类的第一阶段至关重要。在调整 pipeline 时，请注意确保误报与当前低于风险容忍度的事物之间的差异，不会对您检测漏洞的能力产生负面影响。 * **实用主义：** 基于的 AI 漏洞扫描，就像过去的 SAST 一样，可能会导致大量令人沮丧的误报。与过去的 SAST 不同，有一些方法可以对其进行调整，而无需创建高度复杂的规则。尝试做一些事情，看看什么有效什么无效，然后进行调整。 * **不要一次打开所有的水龙头：** 与实用主义建议一样，运行一次小扫描，分类几个项目，并用它来反馈构建您的扫描 pipeline，效率要高得多。对所有内容进行扫描并报告所有潜在的漏洞可能会奏效，但根据我们的经验，这不太可能是采用这项新技术的最成功方式。 ## 运行 Pipeline（手动模式） 您可以从活动的 CLI 终端**内部**按顺序执行审查阶段。 1. 从您的终端启动 CLI。 2. 在交互式 UI 提示符内，按顺序输入 skills： # 0. (可选) 分析代码库的版本控制系统 (VCS) 历史记录并提取过去的漏洞 /mantis_history # 1. (可选) 生成 mantis_summary.md 目录映射 /mantis_summarize # 2. 将代码库结构和历史经验合成到 Markdown 知识库中 /mantis_architecture # 3. 基于 KB 迭代开发项目的动态威胁模型 /mantis_threat_model # 4. 映射目标外部边界并构建扫描路线图，注入 KB 引用 /mantis_plan # 5. 使用注入的上下文运行多线程/顺序安全缺陷扫描 /mantis_researcher # 6. 整合重叠的文件和重复的 bug /mantis_dedupe # 7. 验证代码有效性并过滤误报 /mantis_review # 8. 消除生产环境中不可行的问题 /mantis_critic # 9. 生成概念验证崩溃复现器并在 sandbox 中运行它们 /mantis_reproduce # 10.已验证的单个漏洞组合成多步漏洞利用链 /mantis_chain # 11. 应用最小修复并验证它们是否阻止了崩溃复现器 /mantis_patch # 12. 计算最终的矩阵风险评级并追加到单个漏洞中 /mantis_calibrate # 13. 从执行轨迹中提取见解并追加到经验收件箱 /mantis_reflect # 14. (手动步骤) 在开始下一个循环之前，将 workspace/findings/ 移动到归档目录 ## 构建确定性 Pipelines（生产级） 虽然 `/mantis_meta_agent` 为探索性安全研究提供了动态指导，但我们强烈建议将 Mantis Skills 封装在**确定性程序化 pipeline**（例如 Python、Bash、Rust 或 CI/CD 工作流）中，以便在企业或生产环境中使用。 通过将各个 skills（如 `/mantis_researcher`、`/mantis_review` 和 `/mantis_reproduce`）视为在 `workspace/findings/` 目录中读取和写入 JSON 状态的微服务，您可以构建一个提供绝对可靠性和严格安全保证的刚性编排器。更好的是，您应该使用更持久、更有弹性的数据库，而不是单台机器上的 json 文件。 **在构建您的测试工具之前，请严格遵守 [SCHEMA.md](SCHEMA.md) 中定义的阶段间数据契约。** 当然，您也可以根据适合您的方式修改 schema。这里几乎没有硬性规则。 ### Pipeline 适配器 Skill (/mantis_pipeline_adapter) 要开始为高可靠性、token 效率（例如使用基于 UUID 的引用）以及对自定义环境的适应性（通过 MCP）构思您的自定义 pipeline，请参阅 [Pipeline 适配器指南](mantis_pipeline_adapter/SKILL.md)。 ### 为什么要构建程序化测试工具？ * **确定性：** 一些阶段（如复现 agent 或补丁 agent）包含让 subagent 批评复现或补丁的建议。虽然演示整体工作流是合理的，但一个 agent 无法通过“忘记”调用批评 subagent 来绕过的、更确定性的批评阶段，可能会产生更好的结果。 * **减轻 Prompt 注入风险：** 编排 shell 命令的 LLM 如果摄取了恶意代码，很容易受到主机级别的 prompt injection 攻击。将编排移动到强化的确定性 pipeline 中，可以消除 LLM 对主机环境的控制。 * **强制执行严格的 Sandboxing：** 您的确定性测试工具可以以编程方式强制要求不受信任的 AI 生成 payload 完全在锁定的 VM、容器或 gVisor sandbox 内执行，而不是依赖 LLM 记住在执行崩溃复现器时使用 `--network none`。 * **CI/CD 集成：** 执行静态分析和去重阶段的确定性脚本是可预测的，并且很容易集成到标准的自动化工作流（如 GitHub Actions 或 Jenkins）中。 * **扩展性：** 该 pipeline 可以分解为多个部分，允许您在利用率较低的时期在规模合适的集群中水平扩展。 * **确定性报告：** 虽然 pipeline 依赖于机器可读的 JSON 文件 (`workspace/findings/*.json`) 来安全地维护内部状态，但程序化测试工具可以确定性地将这些 JSON 漏洞转换为人类可读的 Markdown 报告，或者自动将它们提交到 bug 跟踪系统中，而不会有 LLM 产生幻觉或状态损坏的风险。仅对此报告过程的确定性子集使用 LLM，例如在需要时提供执行摘要。 ### 混合方法 为了保持套件的动态、自适应特性，同时确保确定性执行，您可以构建一个如下所示的 pipeline： 1. **程序化迭代：** 测试工具遍历工作区，通过 CLI 调用静态和动态 skills。 2. **反馈经验：** 测试工具获取生成的 `learnings.jsonl` 文件并调用 `/mantis_plan` 以生成新更新的 `plan.json`，有效地允许 AI 指导确定性运行程序接下来要分析什么。 3. **硬编码执行 Sandbox：** 您可以选择将 `/mantis_reproduce` 和 `/mantis_patch` 的确定性版本配置为*仅生成*补丁或脚本文件，而将实际执行和评分留给您的测试工具在严格控制的 sandbox 中进行。 ## 非确定性的现实 在使用 AI 进行安全研究时需要理解的一个关键概念是**非确定性**。 * **覆盖率不是绝对的保证：** 即使阶段 2 (`/mantis_plan`) 尝试使用程序化 shell 脚本来映射您的整个代码库，运行这些脚本的 agent 本质上是非确定性的。它偶尔可能无法正确运行脚本、产生参数幻觉或跳过步骤。 * **轨迹/对话分析：** 减轻非确定性缺乏的一种方法是以编程方式审查 agent 进行的所有工具调用，以查看它们做了什么。这可用于计算覆盖率和效率指标，尽管这些数字的确切含义我们将留给您自己去想象。 * **跨循环的推理变化：** 由于 LLM 的分析是非确定性的，它可能在第 1 轮中遗漏了微妙的业务逻辑缺陷或授权绕过，但随着其内部“注意力”的转移或从其他漏洞中获得了上下文，它可能会在第 5 轮中清晰地识别出来。这就是为什么我们通常建议多次运行此扫描 pipeline。 * **边际效益递减：** 您可能期望 pipeline 最终会“完成”并停止报告 bug。实际上，漏洞的发现通常不会完全停止；相反，随着 LLM 开始产生幻觉或纠缠于迁腐的非问题，漏洞的*质量和严重程度*最终会下降。 连续循环旨在利用这种非确定性，让 AI 进行多次检查以捕捉它遗漏的内容。然而，**这取决于每个用户去试验该套件，审查漏洞上的风险校准器评分，并自行确定何时漏洞的质量已下降到足以暂停循环的程度。** 从长远来看，您还必须确定重新扫描的频率，例如当具有更强大功能的新模型可用时，或者当代码库收到足够大的更改时，值得进行完整的重新扫描，而不是仅仅分析特定的 diff 或 changelist。 ## 高级 / 无人值守云部署 (GCE) 在完全自主、无人值守的状态下全天候运行连续审查循环会带来独特的安全风险，特别是**主机级别的 prompt injection**。除此之外，agent 可能会简单地犯错误并执行您未曾预想的操作。 **因此，部署到强化的 VM（例如隔离的 Google Compute Engine (GCE) 实例）是无人值守模式的严格要求。** （或者，您可以构建一个结构更明确、各个风险操作都被 sandbox 隔离的确定性 pipeline，尽管这需要更多的前期投入）。 ### 1. 强化的 GCE 环境 为了提供 AI agent 无法轻易逃脱的安全边界，您必须按如下方式配置您的环境： * **网络隔离：** 为 GCE VM 配置**没有外部互联网访问权限**，或者至少使用一个带有受信任允许列表、良好的速率限制和出站控制的安全 web 代理。 * **VPC Service Controls (VPC-SC)：** 将 VM 放置在 VPC-SC 边界内。如果 agent 被破坏，这是防止数据泄露的重要防御措施。 * **最小权限服务账号：** 将具有严格受限角色的专用 IAM 服务账号附加到 VM。*不要*使用诸如 `roles/aiplatform.user` 或 `roles/storage.objectAdmin` 之类的宽泛角色。相反： * **自定义 AI 角色：** 创建一个*仅*授予 `aiplatform.endpoints.predict` 和 `aiplatform.endpoints.generateContent` 的自定义 IAM 角色。这限制了 agent 仅能查询模型，并防止修改 AI 基础设施。 * **仅追加的 GCS 存储：** 要存储中间结果或备份，请向服务账号授予对特定 GCS bucket 的 `roles/storage.objectCreator` 和 `roles/storage.objectViewer` 权限。**至关重要的是，不要授予删除权限 (`storage.objects.delete`)。** 也可以考虑其他仅追加的存储机制。 * **GCS 版本控制：** 在 GCS bucket 上启用对象版本控制。这提供了一种机制，使得即使 AI 或不受信任的崩溃复现 payload 覆盖了文件（如 `learnings.jsonl`），先前的状态也会作为非当前版本保留下来，从而防止 AI 永久删除历史记录。 ### 2. 绕过交互式提示（无人值守模式） **警告：** 仅在完全实现了（上述）**强化的 GCE 环境**时才使用这些标志。默认情况下，CLI 工具在执行系统命令之前需要手动确认。要完全无人值守地运行 pipeline，您必须在启动 CLI 时传递适当的自动批准标志，例如 `--dangerously-skip-permissions` 或 `--yolo`。 ### 3. 自动化安全缺陷警报 (Cloud Pub/Sub) 在无人值守运行时，您可能希望有一种隔离的方式，在 pipeline 发现高可信度安全缺陷时收到通知。有很多方法可以做到这一点，包括将 pipeline 连接到 **Google Cloud Pub/Sub**。 1. **设置：** 创建一个 Pub/Sub 主题（例如 `mantis-verified-vulns`），并授予您的 GCE VM 的服务账号 `roles/pubsub.publisher` 角色。 2. **连接：** 可以指示 `/mantis_meta_agent` skill 原生触发通知。您可以指示 meta-agent 在成功复现安全缺陷时运行 `gcloud pubsub topics publish mantis-verified-vulns --message="$(cat workspace/findings/.json)"`。 3. **路由：** 将 Google Cloud Function 或 Cloud Run 服务订阅到该 Pub/Sub 主题，以将警报 payload 直接路由到您团队的聊天、问题跟踪或寻呼系统中。这干净地将隔离的扫描环境与您的内部警报基础设施解耦。 ## Meta-Agent 编排模式 为了实现真正自主和持久的安全运营，您可以通过调用 `/mantis_meta_agent` skill 来采用 **Meta-Agent 编排**模式。 在这种设置中，高级的 "Meta-Agent"（一个长期存在的 Gemini 或 Antigravity CLI 会话）负责驱动整个审查 pipeline。 ### Meta-Agent 的角色： * **编排：** Meta-Agent 使用 CLI subagent 委派原生地管理每个阶段的执行。 * **持久性：** 它在一个跨越数天或数周的长期对话中运作，确保即使您在开会、晚上离开或度周末时，审查也能继续朝着发现漏洞、修补和报告的目标进行。 * **监督：** 它密切关注任务，处理轻微的环境故障，阅读日志，并确保 pipeline 保持运行。 * **交互式指导：** 这种模式的一个主要优点是您可以在 subagent 工作时与 Meta-Agent 聊天。您可以请求状态更新、协作调试环境问题，或提供高阶战略指导（例如，“深入研究图像解析器”），以实时或在下一个循环中影响集群的焦点。 * **安全边界：** 虽然您可以使用自动批准标志 (`--dangerously-skip-permissions`) 运行 Meta-Agent，但您必须严格将其限制在前面所述的强化安全边界（VPC-SC、无外部互联网和受限的 IAM 角色）内。 此模式将该套件从一组零散的工具转变为一个连续的、自动化的安全研究运营。 ## 评估与优化 Mantis Skills 评估像 Mantis 这样的自主、多 agent pipeline 是出了名的困难。每次调整 prompt 都运行完整的端到端评估在时间和 API token 方面都是极其昂贵的。为了安全地修改这些 skills 或优化模型成本，您应该采用**分层评估策略**，并衡量代理指标，而不仅仅是二元成功与否。 ### 分层评估策略 除非必要，否则不要评估整个循环。将您的评估分为三个层级： 1. **第一层：静态检查** * **它是什么：** 对 skill 文件进行快速、程序化的 lint 检查。 * **衡量什么：** `SKILL.md` 文件能否解析？YAML frontmatters 是否正确？它们是否定义了所需的工具？系统 prompts 是否在上下文窗口限制内？ 2. **第二层：隔离的“单元”评估** * **它是什么：** 在真空环境中评估单个 skill（例如 `/mantis_patch`），与 pipeline 的其余部分完全解耦。 * **设置：** 向单个 skill 提供静态的、硬编码的输入（模拟的 `findings.json` 和目标文件），并观察其输出。 * **衡量什么：** * **格式：** 它是否输出了预期的 JSON schema 或有效的 diff？ * **工具使用：** 它是否尝试调用正确的工具（`run_command` 还是 `view_file`）？ * **LLM-as-a-Judge：** 使用更便宜、更快的模型，用严格的评分标准（例如，“补丁是否解决了 SQL 注入？是/否。”）对定性输出进行评分。 3. **第三层：“黄金数据集”端到端评估** * **它是什么：** 整个 pipeline 的完整运行。仅在进行重大发布或替换基础模型类别（例如升级到更新的旗舰模型）时才运行此评估。 * **设置：** 策划一个包含 3-5 个真实的、具有代表性的易受攻击代码库的小型数据集。 * **衡量什么：** 二元结果。最终的测试套件是否通过？`/mantis_reproduce` 是否生成了可用的 PoC？您还可以进行人工评估，看看是否发现了新的漏洞。 ### 衡量“不可衡量”的事物 在评估中间阶段（如 `/mantis_researcher`）时，很难定义二元成功。相反，请跟踪这些代理指标来衡量 skill 的退化情况： * **工具错误率：** 计算 agent 的工具调用失败的次数（例如错误的 bash 语法、无效的文件路径）。更改 prompt 后工具错误的激增表明 skill 的指令集已退化，或者 prompts 可能需要适应新的模型或 coding agent 测试工具。 * **轨迹效率 (轮次/Token)：** 如果 `/mantis_reproduce` 过去在 5 轮内编写出 PoC，而在调整 prompt 后需要 150 轮或不断循环，这就是效率的可衡量退化。 * **“放弃”率：** agent 输出诸如“我无法确定”、“我被卡住了”等短语的频率有多高，或者在达到 token 限制之前进入无限循环的频率有多高？ ### “影子评估”方法 不要在第一天就构建庞大的评估测试工具。相反，有机地构建您的数据集： 1. 在手动运行 pipeline 时，等待 agent 在特定任务上失败。 2. 保存那个确切的起始状态（用户 prompt、工作区文件、JSON 状态）。 3. 修复 skill prompts 直到 agent 成功。 4. 将那个特定的、隔离的状态变成您的第一个自动化测试。 通过专门根据现实世界的失败来构建您的评估数据集，您可以确保只花费 token 来测试真正重要的退化情况。 #### 优化并行性与模型选择 在调整 pipeline 或引入诸如并行轨迹搜索等功能时，您应该进行实验以确保您的 token 投资能获得回报： * **尝试不同的模型：** 对于任何给定阶段，尝试将旗舰模型替换为更便宜、更快的模型或专门的编码模型。在推出之前，使用第二层“单元”评估来验证更便宜的模型是否会降低成功率。 * **评估并行轨迹：** 如果您实现了并行轨迹搜索（例如，生成多个 `Researchers` 或 `Patchers`），请测试不同数量的并发 agent（例如 2、3 或 5 个）。如果运行并行研究人员总是导致他们发现完全相同的漏洞，那么并行化并没有产生独特的价值，而只是在白白消耗 token。相反，如果并行的修补程序持续产生比单个 agent 更干净、更地道的修复，那么计算成本就是合理的。 ## 路线图 / 未来工作 * **Skill 自我改进 (元学习)：** 当前的 `learnings.jsonl` 和知识库 (KB) 架构跟踪特定于代码库的经验结果，以调整 `THREAT_MODEL.md` 和上下文指针。未来迭代的 pipeline 可以更进一步，使用这些历史数据来反思并自动重写其自身的 `SKILL.md` prompts。例如，如果某种类型的幻觉被 Critic 反复捕捉到，一个自我改进的 meta-agent 可以更新 Researcher 的 `SKILL.md` 指令，以在它到达 Review 阶段之前明确过滤掉那种特定的模式。**安全提示：** 提交对 `SKILL.md` 文件的自动化更改必须始终经过人工把关，以防止攻击者利用 prompt injection（例如，通过目标文件中的恶意 payload）欺骗 meta-agent 在全局范围内忽略某一类漏洞。 * **软件黑灯工厂：** 将此 pipeline 集成到完全由 AI 驱动的软件开发中。Mantis 将不再是为人类行动而发现漏洞，而是成为黑灯工厂中自主的漏洞研究和发布把关组件。在黑灯工厂能够推向生产环境之前，它必须已经接受了诸如 Mantis 之类的 pipeline 进行的 N 小时的对抗性漏洞研究或“red teaming”。 ## 故障排除指南 ### 1. 循环迭代正在重新评估相同的代码 * **症状：** 循环不断审查相同的文件并报告完全相同的 bug。 * **解决方案：** 确保 `/mantis_architecture` 成功完成并将其合成的知识写入 `workspace/kb/` 目录。`/mantis_plan` 策略家会检查此知识库以动态跳过已分析的区域。检查文件权限是否允许写入 `workspace/kb/`。 ### 2. 其他问题 * **症状：** 某些东西无法正常工作。 * **解决方案：** 让 AI 编码工具审查您的 pipeline 以及导致意外行为的对话或轨迹。它们通常会为您提供有用的见解。 这不是一个官方支持的 Google 产品。本项目不符合 [Google 开源软件漏洞奖励计划](https://bughunters.google.com/open-source-security) 的条件。 本项目仅供演示之用。不建议在生产环境中使用。

标签：AI编程智能体, 代码安全, 子域名突变, 安全技能工具包, 漏洞修复, 漏洞枚举, 网络安全培训, 请求拦截, 身份验证强制, 防御框架