Agent Army
一个双层并行执行框架。指挥官是顶级模型——默认 Fable，如果会话模型是 Opus 则使用 Opus——负责思考：侦察、组合、简报、验证。它编排一组下级模型（其层级由用户在部署时选择，参见功率等级）。每个第1层智能体都有其自己的完整上下文窗口（而非切片）。每个智能体在其下生成第2层子智能体。结果是许多独立的“大脑”同时运行——而不是一个大脑被分割。
Commander (你 — Fable 或 Opus，会话模型)
|
|-- Layer 1: 团队 (3 到 50+，每个 = 各自的 1M 上下文，L1 层级由功率等级决定)
| |-- Agent A (1M) -- Sub-agent A1, A2, ... (L2 层级)
| |-- Agent B (1M) -- Sub-agent B1, B2, ... (L2 层级)
| |-- Agent C (1M) -- Sub-agent C1, C2, ... (L2 层级)
| |-- ... (无上限)
Swarm vs. army: Swarm 将一份上下文窗口分割给多个子智能体——一个大脑，被分割。Army 赋予每个第1层成员其自己的窗口。这个区别正是此技能的关键所在。
何时使用
- 跨越多个文件的大型重构
- 多文件颜色/样式/命名/API 迁移
- 广泛的代码库审计（安全性、可访问性、性能、死代码）
- 批量内容生成或转换
- 任何具有 6 个以上独立工作单元 且可以同时运行的任务
何时不使用
- 少于 6 个独立工作单元——直接执行即可
- 存在大量顺序依赖，每个步骤需要上一步的输出
- 单文件更改
- 需要跨所有输出保持单一连贯作者声音的任务（并行智能体会产生偏差）
如果任务明显不适合，请说明原因，并建议内联执行而非启动一个 army。
- 每个第1层智能体必须生成 2 个或更多子智能体。无例外。如果你即将部署一个没有子智能体的 L1 智能体，请停止并重新组织。
- 永远不要静默地缩小 army。匹配用户选择的层级。如果必须偏离，请明确说明并解释原因。
2b. 永远不要静默地降级模型。在每次 Agent 调用时显式传递
model:，使用用户选择的功率等级。省略它会继承会话模型——这是一笔无声的最大功率账单。 - 子智能体部署指令必须放在第1层简报内部。如果缺失，子智能体将永远不会被创建。
- 在智能体完成时报告：
[Agent N/M complete] name: X files modified, Y flags。 - 在部署前展示 army 计划并通过部署门控（完整模式）。快速模式在内部制定计划但仍需通过门控。
- 每一波次之后：运行构建 AND 幻象完成检查（参见验证）。智能体的绿色报告只是一个声明，而非证据。
- “继续”/“不要停止”= 连续模式：一个智能体完成后立即启动一个新智能体。不要等待，不要重新询问。
军队规模
开始前确认一个层级。展示此表格：
| 层级 | L1 智能体 | 包括子智能体总数 | 估计令牌数 |
|--------------|-----------|-----------------|--------------|
| 保守 | 3 | ~9 | ~200-500K |
| 标准 | 5-10 | ~15-30 | ~500K-1.5M |
| 激进 | 10-20 | ~30-60 | ~1.5-4M |
| 最大 | 20-50+ | ~60-100+ | ~4M+ |
| 自定义 | 你选择 | 你选择 | 各不相同 |
在“直接执行”时默认选择 标准。在侦察（第3步）之后，根据你发现的情况推荐具体数量——例如，“跨6个域的35个文件 → 激进：8个 L1 智能体，每个 2-3 个子智能体（总计 ~22，~2M 令牌）。调整？”令牌估算为粗略值，并随任务复杂度变化。
功率等级
规模设置有多少智能体；功率设置使用哪些模型。在一次提问中同时询问两者（AskUserQuestion 效果很好——规模与功率作为同一调用中的两个问题）。如果用户已明确指定功率等级或模型，则跳过询问。
| 功率等级 | 指挥官 | 第1层 | 第2层 | 最适合 |
|-------------------|------------------|---------|---------|-------------------------------------------------|
| 最大功率 | Fable/Opus (会话)| Opus | Opus | 棘手的重构、正确性关键的迁移 |
| 重型 (推荐) | Fable/Opus (会话)| Opus | Sonnet | 大多数大型任务——智能编排，快速执行 |
| 平衡 | Fable/Opus (会话)| Sonnet | Sonnet | 具有清晰模式的机械性迁移 |
| 经济 | Fable/Opus (会话)| Sonnet | Haiku | 高容量、极其简单的查找/替换 |
规则：
- 指挥官始终是会话模型——Fable 或 Opus，用户的选择——并且从不委派。如果会话正在运行 Sonnet 或 Haiku，请在部署前告知用户切换（
/model或claude --model fable）：指挥官的质量是 army 质量的上限。 - 在每次 Agent 调用时显式传递模型：团队成员使用
model: "<L1 tier>"；L1 简报指示子智能体使用model: "<L2 tier>"。 - 在每个功率等级下都允许按智能体升级：一个沉重或复杂的文件（1000+ 行、复杂逻辑）可以将该子智能体提升一级。在 army 计划中注明升级。
- 审计波次始终在 Opus 上运行，无论功率等级如何——用全新的、更强的视角审查执行者的工作。通知波次可以降级到 Haiku。
协议
模式： 如果范围已经具体（文件路径、确切更改、层级），则跳到第3步（快速模式）。否则从第1步开始（完整模式）。
第1步：接收 (完整模式)
如果用户已经提供上下文，用一行确认：“目标：[X]。范围：[Y]。层级：[Z]。功率：P。开始。”否则询问：目标（一句话）、范围（文件/目录/“全部”）、约束（不要接触 X，匹配 Y）、层级和功率等级。
第2步：Git 检查点
git status——警告未提交的更改，提供先暂存/提交的选项。git checkout -b agent-army/checkpoint-{timestamp}然后切换回来。这是回滚点。- 没有 Git 仓库？警告没有安全网，并获取明确确认。
第3步：侦察
- 使用 Grep / Glob / Read 查找所有受影响的文件。
- 统计工作单元数量。
- 对每个文件执行
wc -l。将 500+ 行的文件标记为 沉重 → 单独分配。 - 分类到域中（按目录、导入图、文件类型、命名模式）。
- 识别共享依赖项——基础文件，被多个域导入。首先处理这些（第5步）。
- 识别构建命令（package.json、Makefile 等）。
输出：Files: N | Heavy: [list] | Domains: [list] | Shared deps: [list] | Build cmd: [cmd]
第4步：组合
- 基础智能体 用于共享依赖项——在并行波次之前运行，以便依赖者不会冲突。
- 第1层： 每个域一个智能体；将大域拆分到多个智能体。
- 第2层： 每个 L1 智能体 2+ 个子智能体，根据加权文件负载分配，而非文件数量：
- 小（<200 行）：每个子智能体 2-3 个文件
- 中（200-500）：每个子智能体 1-2 个文件
- 重（500+）：每个子智能体 1 个文件，单独分配
- 命名每个智能体。将每个文件分配给恰好一个子智能体——无重叠，无遗漏。
输出 army 计划。完整模式：暂停等待“是否继续？”快速模式：一行摘要，然后部署。
部署门控
在部署之前，在你的回复中输出此清单。不要在心里确认——写出来。
部署门控：
[ ] 每个 L1 简报包含“你必须生成 N 个子智能体”
[ ] 每个子智能体都被命名并分配了具体文件
[ ] 每个文件由恰好一个子智能体拥有（无重叠，无遗漏）
[ ] L1 简报包含完整的子智能体部署指令
[ ] 层级匹配用户的选择
[ ] 功率等级已设置：每个 L1 调用上设置 model: "<L1 tier>"；每个简报中包含 L2 层级和升级
所有项必须通过。任何失败 → 在部署前修复计划。
第5步：部署
- 首先运行基础智能体（如果有），使用 L1 层级。等待完成。
- 并行启动所有第1层智能体——在单个消息中对每个调用设置
run_in_background: true和model: "<L1 tier>"。 - 每个 L1 智能体根据其简报并行生成其 L2 子智能体。
- 报告每个完成：
[Agent N/M complete] name: results。
第6步：验证
- 重新扫描——重新运行第3步的搜索以查找剩余的违规。
- 幻象完成检查——运行
git diff --stat并与智能体报告交叉比对。任何报告“COMPLETE, N files modified”但没有匹配 diff 的智能体撒谎了或空操作了——重新分派它。相信 diff，而非报告。 - 构建——运行构建命令。记录通过/失败。
- 解决跨团队报告中的标记。
- 输出 army 报告：
Agents: N | Files modified: N (diff-confirmed) | Skipped: N | Build: PASS/FAIL
Flags: [list] | Phantom completions caught: N | Rollback: git checkout agent-army/checkpoint-{timestamp}
波次
每个波次是一个新的、更小的、不同专业化的 army。在每个波次前暂停等待用户批准。最多 4 个波次。
| 波次 | 名称 | 触发条件 | 目的 |
|---|---|---|---|
| 1 | 执行 | 始终 | 进行更改 |
| 2 | 审计 | 构建失败、仍有违规、20+ 个文件、或标记 > 0 | 新的智能体审查波次 1 的正确性/边界情况 |
| 3 | 传播 | 更改影响到 API/类型/接口；测试或文档引用旧模式 | 更新测试、文档、配置、下游调用者 |
| 4 | 通知 | 用户选择加入 | 草拟 PR 描述、变更日志、Slack 总结 |
每个波次的报告是下一个波次的侦察。每次之后，重新运行验证；当重新扫描干净且构建通过时停止，或达到 4 个波次时停止。
恢复 / 暂存区
对于多波次或可中断的运行，在波次1之后写入 .army-state.md：修改的文件（diff 确认）、打开的标记、未解决的问题、决策。如果运行被终止，下次调用将读取此文件并从上次干净的波次恢复，而不是重新开始。单波次任务跳过。
第1层提示模板
这是被生成的智能体实际看到的内容——技能中最重要的部分。
你是 [AGENT_NAME]，[DOMAIN] 领域的专家。
目标：[一句话]
批准的方案：[确切值 — 十六进制代码、类名、API 形状]
禁止的方案：[要移除/避免的内容]
你的文件：[绝对路径，附带行数]
规则：[约束]。跳过已使用批准方案的文件（幂等性）。
将你文件之外的问题标记在“指挥官的标记”中——不要修复它们。
关键：你必须使用 Agent 工具生成下面列出的子智能体。不要
自己做这项工作。不要跳过生成。在单个消息中部署所有子智能体，
使用多次 Agent 工具调用，每次调用传递 model: "[L2_TIER]"
[注意升级：除了“NAME”使用 model: "[更高的层级]"]。
子智能体：
- "[NAME]": [附带有行数的文件列表]
- "[NAME]": [附带有行数的文件列表]
传递给每个子智能体：目标、它们的文件、批准/禁止的模式、规则、
报告格式。当所有完成后，汇总它们的报告并验证（通过重新读取
或 grep）在你的域中不再存在禁止的模式，然后报告回来。
第2层提示模板
你是 [SUB_AGENT_NAME]，在 [TEAM_MEMBER_NAME] 下工作。
目标：[一句话]
你拥有的文件：[绝对路径，附带行数 — 只接触这些]
批准 / 禁止的模式：[要使用的确切值和要移除的确切值]
规则：[约束]。跳过已正确的文件。将你文件之外的问题标记出来 —
不要修复它们。
流程：完整读取每个文件 → 检查幂等性 → 应用批准的，移除禁止的
→ 重新读取以确认没有禁止的模式残留。
报告：修改的文件 (file: N replacements)，跳过的文件 (已正确的)，
指挥官的标记，问题，状态 (COMPLETE/PARTIAL/FAILED)。
报告格式
每个智能体返回：
## 报告: [Name]
修改的文件: [file: N replacements]
跳过的文件: [file: reason]
指挥官的标记: [issue or "None"]
问题: [issue or "None"]
状态: COMPLETE / PARTIAL / FAILED
反模式
这些是此技能旨在防止的失败模式。如果你发现自己正在做其中一种，停止并纠正。
- 幻象发散 — L1 智能体自己工作而不是生成子智能体。整个速度优势都消失了。由强制性规则1和门控强制执行。
- 幻象完成 — 智能体报告 COMPLETE 但没有编辑任何内容。由
git diff --stat交叉检查捕获，而不是相信报告。 - 静默缩小 — 当用户选择激进时，静默地只运行3个智能体。始终明确表明偏差。
- 模型漂移 — 在 Agent 调用中省略
model:，因此每个子智能体静默地继承指挥官的模型。用户选择了经济模式却收到了最大功率账单。由强制性规则2b和门控强制执行。 - 重叠的所有权 — 两个子智能体编辑同一个文件 → 冲突和丢失的编辑。由门控中的“恰好一个所有者”强制执行。
- 跳过基础 — 在共享文件更新之前接触依赖者 → 级联损坏的导入。基础智能体首先运行。
- 小任务使用 Army — 对4个文件使用9个智能体更慢（编排开销）并消耗令牌。参见“何时不使用。”
错误处理
- 子智能体失败 → L1 智能体重试其文件或生成替换。
- L1 智能体失败 → 指挥官使用相同的简报生成替换。
- 构建失败 → 与检查点分支进行 diff 以隔离中断，然后运行修复波次。
- 幻象完成 → 将该智能体的文件重新分派给一个新的智能体。
- 重新运行时的幂等性 → 智能体首先检查是否已应用模式，因此运行 army 两次不会重复应用。
工作示例
用户
…