Agent Army 是一个两层并行执行框架，用于处理大型且可并行拆分的工作。
用途：当任务包含 6 个以上可同时推进的独立工作单元时，可组建“智能体军团”。典型场景包括跨多文件的大型重构、颜色/样式/命名/API 的多文件迁移、覆盖安全、可访问性、性能与死代码的代码库审计，以及批量内容生成或转换。少于 6 个独立单元、步骤间强顺序依赖、单文件改动，或需要统一作者文风的任务不建议使用。
结构与主要能力：顶层 Commander 由会话模型担任（默认 Fable，或 Opus），负责侦察、编排、撰写任务简报与最终核验，不可下放。Layer 1 由 3 至 50+ 个智能体组成，每个都拥有完整 1M 上下文窗口，而非切分后的片段；每个 Layer 1 智能体必须再派生 2 个以上 Layer 2 子智能体。与把单一上下文拆给多个子智能体的 swarm 不同，army 让每个 Layer 1 成员拥有独立窗口。
使用方式：先确认规模档位与算力档位。规模分为 Conservative（3 个 L1，约 9 个总数，约 200-500K tokens）、Standard（5-10 个 L1，约 15-30 个总数，约 500K-1.5M）、Aggressive（10-20 个 L1，约 30-60 个总数，约 1.5-4M）、Maximum（20-50+ 个 L1，约 60-100+ 个总数，约 4M+）与 Custom。算力档位决定各层模型：Max Power 为 Opus/Opus，Heavy 为 Opus/Sonnet，Balanced 为 Sonnet/Sonnet，Economy 为 Sonnet/Haiku；Commander 始终为会话模型。协议分为快速模式与完整模式：完整模式经历任务受理、git 检查点、侦察、编排、部署门禁、部署与核验；快速模式在范围已明确时直接进入侦察。部署前需输出检查清单，确认每个 L1 简报包含派生要求、每个文件恰好归属一个子智能体、模型显式指定等。共享依赖由 Foundation Agent 先行处理，随后并行启动全部 L1 智能体。
核验与波次：每波完成后需重新扫描、执行 phantom-completion 检查（用 git diff --stat 对照智能体报告）、运行构建并处理跨组标记。波次最多 4 个：执行、审计（构建失败或问题较多时）、传播（改动触及 API/类型/接口时更新测试、文档与调用方）与通知（用户选择时起草 PR 描述、变更日志等）。多波或可中断任务可写 .army-state.md 以便恢复。
限制与规则：必须显式传入模型，避免静默继承会话模型导致成本上升；不得静默缩减军团规模或降低模型档位；不得出现多个子智能体编辑同一文件；不得为小任务组建大军团。git 检查点用于回滚，无 git 仓库时需用户明确确认。费用、平台与具体定价信息暂未提供。