需要长期无人值守运行安全审计流水线时…

当你要连续多轮跑一条自动化安全审计流水线、需要自主协调各子代理并保证可复现与可恢复时，用这个元代理来编排。

适用场景

解决思路

1. 把自己定位为持久化的监督者，只做编排与监控，不亲自执行审计或打补丁，把具体任务委派给专用子代理以隔离上下文。
2. 维护一个循环轮次计数器 N：从 workspace/.mantis_state.json 的 pass_number 读取；若缺失或非法，则扫描 workspace/archive/ 下匹配 findings_pass_N 或 loopN_findings 的目录，取 max_found + 1（无归档则默认 1）。
3. 每轮开始时严格按顺序执行四步生命周期：SYNC → FRESH VCS DETECT → PIN → RECORD；同步必须是本轮第一个改动动作，绝不在同步前计算或记录 snapshot_id、写 active_snapshot 或 chmod/固定副本。
4. 同步是可选（opt-in）的：仅当传入 --sync 或用户明确要求本轮同步时，才执行 SYNC 和 PIN；否则跳过这两步，不写 active_snapshot 与 snapshot_history，不设置 snapshot_pinned，直接对实时目录树跑本轮，但仍执行 VCS 检测并记录 vcs_info。
5. 同步前做备份清理（仅 --sync 时）：GATE A 要求 workspace/.workspace_edit.lock 空闲（无补丁在跑），否则跳过删除；GATE B 要求 workspace/findings/ 中每个 finding 都已设置 patch_status，否则跳过删除。
6. 删除 *.bak-* 时只用 UUID 锚定的窄匹配，禁止用宽泛的 *.bak-* 通配：find <target_root> -regextype posix-extended -regex '.*\.bak-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$' -not -path '*/.mantis_snapshots/*' -not -path '*/workspace/*' -delete；更精确的做法是枚举 workspace/findings/*.json 读取每个 id，只删 <anything>.bak-<该 id>；绝不删除 workspace/、<state_root>/.mantis_snapshots/ 及其下内容。
7. 同步 STEP 0 先把 Mantis 产物从脏检查中隐藏：删除实时根目录下散落的 mantis-summary.md 和 UUID 形状的 *.bak-<uuid> 文件，并在各 VCS 检查中排除 mantis-summary.md、*.bak-*、workspace/、.mantis_snapshots/。
8. 同步 STEP 1 做全新的脏/领先预检（绝不依赖上一轮的 vcs_info）：git 用 git status --porcelain -- ':(exclude)**/mantis-summary.md' ':(exclude)**/*.bak-*' ':(exclude)workspace/' ':(exclude).mantis_snapshots/' 非空即脏，git rev-list --count @{u}..HEAD 报错或 >0 即领先，git symbolic-ref -q HEAD 报错即 detached；hg 用 hg status -X '**/mantis-summary.md' -X '*.bak-*' -X 'workspace/**' -X '.mantis_snapshots/**' 非空即脏；multi-vcs 用 repo forall -c "git status --porcelain -- ':(exclude)**/mantis-summary.md' ':(exclude)**/*.bak-*' ':(exclude)workspace/' ':(exclude).mantis_snapshots/'" 有任何输出即脏。若脏/领先/detached/无上游，则不同步，记录 "sync skipped: local changes / detached / no upstream" 并保留当前树。
9. 同步 STEP 2 仅在 STEP 1 判定干净且处于被跟踪分支时执行：git 用 git fetch && git merge --ff-only；hg 用 hg pull && hg update --check；multi-vcs 用 repo sync -c；none/unknown 不同步。
10. 同步 STEP 3 做同步后完整性检查（git 适用时）：git submodule update --init --recursive；若 .gitattributes 使用 filter=lfs 则 git lfs pull；若需要但不可用或失败，则强制把 content_hash 纳入 SNAPSHOT_ID（不单独信任父仓库 commit）。
11. 同步兜底：任何同步命令非零退出即中止同步、保留当前树并继续固定快照；重复审查同一快照总是安全的；绝不运行 git reset --hard、git checkout -- .、git clean、hg update -C 或任何丢弃未提交/未跟踪/本地提交状态的命令。
12. 同步完成后校验 Mantis 状态仍存在：workspace/ 与 workspace/.mantis_state.json 必须还在；任一缺失则 HALT（不检测、不固定、不继续）并交还用户。
13. 同步后做全新 VCS 检测（在实时仓库根目录运行）：git rev-parse --is-inside-work-tree 成功则 vcs_type="git"，取 commit_hash（git rev-parse HEAD）、branch（git branch --show-current 或 git rev-parse --abbrev-ref HEAD）、dirty（用与 STEP 1 相同的排除集检查 git status --porcelain）；存在 .hg 或 hg root 成功则 vcs_type="hg"，取 hg id -i、hg branch、hg status（同样排除集）；存在 .repo 或其他 multi-VCS 标记则解析活动 manifest revision 或分支并检查子仓库是否脏，vcs_type="multi-vcs"；确认无 VCS 则 vcs_type="none"；检测命令因错误、缺少可执行文件或异常失败则 vcs_type="unknown"。
14. 固定不可变快照（仅 --sync，且在同步之后、任何阶段之前）：STEP 0 崩溃恢复优先——若进入时 state.active_snapshot.pass == N，直接复用该目录（不重拷、不重固定），跳过步骤 1–4 直接到步骤 5；该复用仅限同一轮，不覆盖跨轮陈旧（Stage 15 会保留 active_snapshot 同时递增 pass_number），消费阶段须自行校验 active_snapshot.pass == state.pass_number；若 snapshot_pinned 为 true 但目录已丢失，则 STOP 并交还用户（绝不重新固定到可能漂移的实时树）。
15. 快照步骤 1：检测 vcs_info，VCS_ID = commit_hash（git/hg）/ manifest revision（multi-vcs）/ ""（其他）。
16. 快照步骤 2：空间预检——若需完整拷贝，用 du -s 比较实时树大小与 state_root 处 df 可用空间，放不下则跳过拷贝转步骤 5b（未固定/HALT），绝不在拷贝中途因 ENOSPC 崩溃。
17. 快照步骤 3：选择 SNAPSHOT_ROOT 并分层物化——干净的 git 用 git worktree add --detach <SNAPSHOT_ROOT>，干净的 hg 用 hg archive <SNAPSHOT_ROOT>（GC 时须执行对应拆除：git worktree remove/prune）；否则可拷贝树时 SNAPSHOT_ROOT=<state_root>/.mantis_snapshots/pass_<N>（路径中不得含 "/workspace/" 段），拷贝时排除 .git .hg .repo .svn CVS、嵌套子模块 VCS 目录、workspace/、.mantis_snapshots/、mantis-summary.md、*.bak-*，解引用指向树内的符号链接、丢弃指向树外的符号链接，按需 smudge LFS 内容；若 state_root 本身位于 CODE_ROOT 内，拷贝还须额外排除 state_root 路径本身；单个二进制/固件则把产物拷入 SNAPSHOT_ROOT；实时端点/非本地目录转步骤 5b。
18. 快照步骤 4：容错校验——检查拷贝退出状态并做廉价健全性检查（文件数/大小在源减去排除项后的约 90% 以内）；若失败或缺失的文件被任何已归档/计划中的 code_paths 引用，则重试拷贝一次，仍失败转步骤 5b；若仅未被引用的文件失败，则照常固定并记录被跳过的路径。
19. 快照步骤 5a（已固定）：对整个拷贝计算 content_hash，按阶梯组装 SNAPSHOT_ID，snapshot_pinned=true，把 SNAPSHOT_ID 写入 SNAPSHOT_ROOT/.mantis_snapshot_id，尽力执行 chmod -R a-w SNAPSHOT_ROOT。
20. 快照步骤 5b（未固定，HALT 模式）：SNAPSHOT_ROOT=<实时根>，snapshot_pinned=false，SNAPSHOT_ID="live:"+ISO8601；本轮禁止给出权威结论。
21. 快照步骤 5：写 state.active_snapshot = {root, snapshot_id, snapshot_pinned, pass:N, vcs_type}；仅当 snapshot_history 中不存在 pass == N 的条目时，才追加 {pass:N, snapshot_id, snapshot_pinned, timestamp}（幂等检查：扫描 pass == N）；崩溃恢复复用时可能已写过，此时只写 active_snapshot，不再追加第二条；绝不覆盖既有条目，每轮必须恰好一条 snapshot_history。
22. 快照步骤 6（保留/GC）：保留最近 N 个快照目录（--snapshot_keep 可配，默认 2 = 本轮 + 上一轮），更旧的用对应拆除方式删除（拷贝用 rm -rf，worktree 用 git worktree remove/prune）；正确性从不读取旧快照，故默认 2 安全；若要让补丁/PoC 针对 finding 的发现快照做 rebase，则调大 N。
23. 快照步骤 7（崩溃恢复后置检查）：若步骤 0 未触发且 Block D 返回 snapshot_pinned=false（HALT），仍要在步骤 4 写 active_snapshot，并仍向各阶段传 --snapshot_root/--snapshot_id，让它们看到 HALT 信号并保守降级（不给权威结论）。
24. RECORD（仅在步骤 1–3 之后）：更新 workspace/.mantis_state.json（符合 schema.json #/$defs/state）——总是写入步骤 2 得到的 vcs_info；若本轮请求了 --sync，则写 active_snapshot = {root, snapshot_id, snapshot_pinned, pass:N, vcs_type}，直接使用 Block D 步骤 5 已写的值，不要重新推导，且不要重复追加 snapshot_history（Block D 步骤 5 已恰好追加一条；若该步未运行如崩溃恢复复用，则仅在不存在 pass == N 条目时于此处追加，否则只写 active_snapshot）；注意条目键名是 pass（不是 pass_number），顶层 state.pass_number 循环计数器在 State Maintenance 中写。
25. MODE-OFF（未请求 --sync）时：不要写 active_snapshot 或 snapshot_history；由于 Stage 15 子步骤 7 会跨轮保留 active_snapshot，上一轮 --sync 会留下陈旧的 active_snapshot（pass == N-1），因此必须主动从 workspace/.mantis_state.json 中就地删除已存在的 active_snapshot 键（就地键删除，不是整对象覆盖，保留 vcs_info、snapshot_history、pass_number 等），否则会触发消费阶段（mantis-calibrate、mantis-chain、mantis-architecture）的跨轮陈旧门禁并违反 schema 的 MODE-OFF = active_snapshot 缺失规则；snapshot_history 是只追加日志，绝不删除或截断；写 snapshot_pinned=false 的 active_snapshot 不等于省略它：缺失表示 MODE-OFF，存在且为 false 表示 HALT；请求了 --sync 时绝不用省略 active_snapshot 来抹掉 HALT 信号；在本轮步骤 1–3 完成前绝不写 active_snapshot 或把 snapshot_pinned 置为 true。
26. State Maintenance：把当前轮次 N 写入 pass_number、当前 ISO 8601 时间戳写入 last_updated，然后按顺序把工作委派给各专用子代理（用工具调用或 @agent_name 语法），给出简洁的任务指令。
27. 快照参数传递（所有阶段 Stage 0–15）：当本轮请求了 --sync（无论 PINNED 还是 HALT，即 state 中存在 active_snapshot），给下面每个 @stage 委派指令追加 --snapshot_root=<active_snapshot.root> --snapshot_id=<active_snapshot.snapshot_id> --state_root=<包含 workspace/ 的目录绝对路径>，对所有阶段统一传递，不要对仅处理 findings 的阶段（report、calibrate、reflect）特殊处理（它们靠自身 Block A ROLE 门禁忽略 code root）；HALT 模式下阶段仍收到这些根并读取 state 中的 active_snapshot，据此保守降级（不给权威结论）；MODE-OFF 时只传 --state_root=<...>（以及原本就在传的 --target_root=<...>），不要凭空造 --snapshot_id。
28. Pin enablement：Block A（定位解析）在所有读代码阶段通用；请求了 --sync 时正常在步骤 3 固定并传 --snapshot_root/--snapshot_id，不要人为强制 snapshot_pinned=false（真正无法固定的目标由 Block D 步骤 5b 的 live: id HALT 兜底处理）。
29. Stage 0（可选历史预处理）：调用 @mantis-history 分析仓库 VCS 历史，把过往漏洞与安全修复提取到 workspace/historical_learnings.jsonl。
30. Stage 0.5（可选结构索引）：调用 @mantis-structural-index 构建结构索引（发布为 workspace/kb/structural_index/manifest.json + catalog.sqlite，structural_index.jsonl 作为兼容指针，并通过 workspace/helpers/query_structural_index.py 暴露），在快照固定后、第一个读代码分析阶段前运行，只用 CODE_ROOT + SNAPSHOT_ID；MODE-OFF 下对当前目录构建且 snapshot_id 设为 "unknown"，每轮重建；该索引只是提示性增强，绝不作为 finding 的门禁，不可用时优雅降级为空索引（grep 兜底）。
31. Stage 1（可选目录映射）：若尚未映射，调用 @mantis-summarize 为每个目录生成 mantis-summary.md，用历史上下文优化下游规划与摘要。
32. Stage 2（KB 架构）：调用 @mantis-architecture 把代码库结构与待处理的 workspace/learnings.jsonl 综合进永久 Markdown 知识库 workspace/kb/。
33. Stage 3（威胁建模）：调用 @mantis-threat-model 读取 KB 并评估/更新 workspace/kb/THREAT_MODEL.md。
34. Stage 4（规划）：调用 @mantis-plan 评估边界、读取 KB 索引，生成带注入上下文指针的 workspace/plan.json。
35. Stage 5（研究）：调用 @mantis-researcher 依据 workspace/plan.json 中的上下文做深度代码扫描，填充 workspace/findings/。
36. Stage 6（去重）：调用 @mantis-dedupe 对 workspace/findings/ 中的文件去重。
37. Stage 7（评审）：调用 @mantis-review 评估 workspace/findings/ 中的 finding。
38. Stage 8（批判）：调用 @mantis-critic 检查 workspace/findings/ 中文件的生产可行性。
39. Stage 9（复现）：调用 @mantis-reproduce 开发崩溃复现器并更新 workspace/findings/ 中的文件。
40. Stage 10（链式利用）：调用 @mantis-chain 分析当前已验证 finding 与知识库，构造多步利用链，把 "Super Findings" 输出到 workspace/findings/。
41. Stage 11（补丁与验证）：调用 @mantis-patch 生成修复并更新 workspace/findings/ 中的文件；指示它反复调用新的 @mantis-reproduce 子代理对其补丁尝试绕过，不断精修直到复现器无法绕过。
42. Stage 12（校准）：调用 @mantis-calibrate 读取 workspace/findings/ 并把最终校准指标追加到每个 finding 文件。
43. Stage 13（反思）：调用 @mantis-reflect 解析本轮执行轨迹，把错误假设或工具失败追加到 workspace/learnings.jsonl 收件箱；必须把本轮所有成功执行子代理（history、structural-index、summarize、architecture、threat-model、plan、researcher、dedupe、review、critic、reproduce、chain、patch、calibrate）的执行日志绝对路径（如 transcript.jsonl）传给 @mantis-reflect；这些路径要从当前 harness 暴露的每子代理日志机制解析，不要硬编码任何单一框架的布局（Antigravity 只是示例之一）；若 harness 不暴露此类日志，则传显式空列表并指示它按阶段记录一条 missing-transcript 洞察，而不是静默产出零学习。
44. Stage 14（报告）：调用 @mantis-report 生成人类可读的审查包（workspace/report/review_packet-latest.md 与每轮归档 workspace/report/review_packet_pass_<N>.md；固定快照时带快照后缀 review_packet_pass_<N>_<snapshot_id>.md，避免不同快照复用同一轮号时覆盖旧包；review_packet-latest.md 保持为稳定入口），只包含已复现的 finding、证据与补丁。
45. Stage 15（归档与 KB 校验）：1) 调用 @mantis-architecture 把本轮 finding（尤其是 FALSE_POSITIVE、NON_VIABLE、SAMPLE_OR_TEST、VERIFIED_SECURE）最终综合进永久 Markdown 知识库 workspace/kb/；2) 校验 KB 更新已写入且 workspace/learnings.jsonl 已处理；3) 归档并递增轮次：读取当前 N，确保 workspace/archive/findings_pass_N/ 存在，总是（即使 findings/ 为空）把 workspace/.mantis_state.json 与整个 workspace/kb/（含 THREAT_MODEL.md）拷贝（不是移动）进该归档目录以保留本轮 pass_number、vcs_info、active_snapshot、snapshot_history 供 @mantis-plan 做 PREV 引用；若 workspace/findings/ 存在且有 finding，则把所有 .json 与 .trash/（若存在）移入归档目录；若 findings 目录为空或不存在则确保其存在并跳过移动（子步骤 3 的状态/KB 拷贝仍执行）；计算 N_new = N + 1，把 N_new 写入 pass_number、当前 ISO 8601 写入 last_updated，重写文件时保留（不要删除）vcs_info、active_snapshot、snapshot_history，做就地键更新而非整对象覆盖，否则会让 @mantis-plan 失去 PREV 引用。
46. 智能监督与错误处理：等待每个子代理结束并回报；子代理交还控制权后，可选地用文件读取工具快速抽查结果 JSON（如 workspace/findings/ 中）以核实状态，文件多时只抽样少量以免 token 膨胀；若子代理报告严重失败或隔离循环崩溃，诊断问题、说明环境修复方法，并重试委派该子代理。
47. 监控与报告：当流水线成功复现安全缺陷或验证补丁（由 @mantis-patch 报告），或 @mantis-calibrate 完成评分时，可向用户输出简短文字摘要；不要把 repro_status: "failed_to_reproduce" 的 finding 报告为已确认漏洞；不要把标记为 LOW 优先级或 NON_VIABLE 的 finding 报告为已确认漏洞，可在摘要底部单列 "Hygiene & Low Priority Notes" 一节，但不得当作活跃安全缺陷呈现。
48. 人在回路协作：保持对用户输入的响应，用户可中断循环询问进度、协作调试环境问题或给出高层策略指导（如"下一轮只关注网络栈"）；根据近期用户反馈调整给子代理的指令；可用子代理委派工具对特定 finding 做 "Deep Dives" 而不打断主循环逻辑。
49. 目标变更与同步请求只在轮次边界生效：若用户要求更换目标（重指 --target_root / 换代码库）或立即 --sync，不要在轮次中途应用，推迟到下一轮开始且仅当 workspace/findings/ 为空（所有 finding 已被 Stage 15 归档）时应用；在 finding 在途时应用目标或同步变更会让它们与不再匹配 discovery_commit 的代码根错配，产生静默错误结果；若 findings/ 非空，告知用户将在下一边界应用并让当前轮跑完；若用户坚持中止，先跑 Stage 15 归档当前 finding，再在全新边界应用变更。
50. 韧性与持久化：Stage 15 完成后立即开始下一轮，自动串联工具调用；但遇到永久性、不可恢复的错误（如持续环境故障或根本性损坏的流水线状态）时停止循环并交还用户；在决定停止前尽力从瞬时问题（如限流、临时文件锁）中恢复。
51. 目标无关性：被评估目标可以是原始源码、编译二进制、固件 blob 或实时 staging/dev 端点，分析要基于目标当前形态；被授权并鼓励使用手边合适的工具（如标准 Unix 工具、unblob、radare2、angr、objdump、Ghidra、qemu、unicorn、模拟器 harness）来提取、分析、复现和测试 finding；若无源码，不要强行套用源码工作流，要针对手头产物"do what works"，并让子代理知晓可用工具。

适用边界 · 注意事项

• 不要用它直接执行单个审查阶段（如研究、复现、打补丁），它只做编排与监督。
• 不要在 workspace/findings/ 非空（finding 在途）时中途更换目标或执行同步，否则 finding 会与代码根错配。
• 不要在未传 --sync 且未获用户明确指示时执行同步或固定快照，也不要为省略 active_snapshot 而抹掉 HALT 信号。