用途：解决多智能体并行开发（fan-out）之后的收束（fan-in）问题。多个代理各自产出 worktree 与 diff 后，由人工在终端逐个对账既繁琐又不可靠；该工具把这一步骤流程化，并让每处改动都带有可追溯的来源信息。
主要能力：在 git 只提供 diff 的基础上补充来源（provenance）。对每一处改动记录：由哪个代理产生、运行在哪个执行框架（harness）上、花费多少（token 或费用）、测试是否通过。资料中给出的示例表包含 path、agent、harness、cost、tests 五列，例如 src/a.ts 来自 mechanic/codex、12480 tok、测试通过。
使用方式与合并流程：显式声明式合并计划，分三步：1）将选中的改动应用到集成 worktree；2）运行仓库门禁（gate）；3）快进目标分支并写入 provenance manifest。冲突顺序与测试门禁都需明确声明，manifest 作为合并的一部分写出，以便日后追溯某行代码的来源。收束结束后归档落选分支（以可检查的 bundle 形式保留，而非直接删除），并回收已合并的 worktree。
限制与取舍：当某处改动的代理或执行框架未知、测试结果未知，或测试失败时，该改动不可被选中，工具会拒绝匿名或无测试结果的改动。资料同时给出不应 fan-out 的情形：同一功能、同一代码库内并行会在路由表、schema、manifest、lockfile、barrel index、共享 fixture、迁移文件等关键文件上冲突；可分离的工作才适合先 fan-out 再 fan-in；单功能多阶段应用 pipeline；一个代理需要另一个代理的细节用 peer relay；不可逆设计决策只做一次 deliberate fan-out；有廉价客观评分器时可 race with a judge；其余情况用一个代理即可。此外资料指出多代理设计若不能降低人工审阅 diff 的时间，就只是额外增加成本。相关工具有 army-agent-contract（为每个代理提供互不重叠的写入白名单）、army-run（运行产生分支的代理集群）、army-join（引入外部评审处理有争议的改动）。具体安装命令与平台支持暂未提供。