fan-out

name	fan-out
description	把当前任务派发给多个 subagent——但先检查这次拆分到底值不值。适用于 /fan-out，触发语：「用多智能体做」「派发出去」「拆给多个 agent 并行」，或任务能拆成真正独立的子任务时。按上下文耦合度拆解，spawn prompt 用 handoff 的纪律写成任务契约。
metadata	{"short-description":"按耦合度拆解的多智能体调度"}

fan-out

把当前任务变成一次有编排的多智能体执行——但只在拆分真正划算时才拆。你始终是编排者：拆解、派发、整合。不要自己做子任务。

语言：跟随用户的语言。

关卡：这次拆分值得吗？

多智能体的代价是真金白银：agent 比普通聊天多烧数倍 token，多智能体系统再多一个量级；而且每次交接都要交「通信税」——subagent 返回的摘要会藏掉它行动背后的隐式决策，编排者下发的指令也会在传递中丢失微妙之处。

1. 先榨干单上下文：把指令写清楚、压缩上下文、收窄工具集。很多「需要多智能体」的问题，其实是单 agent 的上下文管理没做好。
2. 只在真实信号出现时才拆：当前上下文在退化（失败探索的噪声污染后续决策）、信息空间大到一个 agent 覆盖不过来、或工具集大到选择准确率下降且能按专业领域切开。
3. 拿不准就不拆。拆错的代价（信息损耗加决策不一致）通常大于不拆的代价（上下文略显臃肿）。从能用的最简单方案开始，有证据支持时再加 agent。

步骤

1. **沿上下文耦合度拆，不沿功能拆。**agent 之间的边界必须画在共享上下文最少的地方。永远不要按工作阶段拆（一个实现、一个测试、一个审查）——那恰好切在耦合度最高的地方，整个执行变成传话游戏。低耦合的切片适合拆：互不依赖的搜索路径、文档消化、黑盒验证、独立的研究角度。高耦合的工作留在一个 agent 里（通常是你自己）：核心实现、架构决策、任何其选择会悄悄约束别人的工作。
2. 按任务类型选模式。前三种各有一篇打法——在派发之前读对应的那篇，不是派完再读：
   • 调研 / 排查 → 不同角度的并行 explorer（按来源、按子系统、按时间窗）；告诉每个先广后精。读 references/research.md。
   • 多处实现 → 先摸清完整工作清单，再一处一个 agent；会并行改同一仓库时用 worktree 隔离。读 references/implement.md。
   • review / 审计 → 按维度并行找问题，每个发现再配一个对抗式验证者。读 references/review.md。
   • 设计决策 → 2–3 个不同侧重的独立方案 agent（MVP 优先、风险优先、用户优先），再加一轮评审
   • debug → 并行假设检验者，每人负责证伪一个假设
   • 以上任何一种 → 黑盒验证 subagent 默认开启——它只需要验收标准和产出物——只有用户明确表示不要时才跳过，绝不悄悄省掉。
3. spawn prompt 写成任务契约（handoff 纪律）：明确的目标、按引用给的输入（路径 / issue / URL，不粘贴正文）、期望的输出形状、边界（不许碰什么），agent 可能选错工具时给一句工具提示。模糊的委派只会产出重复或跑偏的工作。 引用还是内联，是一个能力上的 tradeoff。引用只在接收方能解引用时成立——它得有读取/搜索工具和访问权限；引用的收益在内容大、持久、或只需要一部分时最明显：subagent 只拉自己要的那部分、按需拉取、读到的还是最新版。反过来这四种情况用内联：接收方没工具、片段比一次读取还便宜、必须钉死精确版本、信息只存在于这段对话里——没落盘的上下文引用不到，要么内联要么先落盘（/to-ctx）。一句话：持久的用引用，增量的用内联。 投入和复杂度挂钩并写进契约：简单查证就一个 agent 几次工具调用；对比类 2–4 个 agent；只有真正复杂的工作才配得上十个以上。 契约不是完整的 /handoff，大多数派发也不需要 handoff——handoff 交接的是「任务连同它积累的状态」的所有权，契约委派的是一个切片，所有权还在你手上。只有当子任务的状态多到可能活得比这次执行长时，才把契约升级成真正的 /handoff：它在某个 branch / worktree 上干活、可能被另一个 session 接着做；它需要在中断后可恢复；或者它的结果要继续传给下一个 agent。
4. 派发：互相独立的 agent 并行出发；有依赖的阶段做流水线，不设人为的等待关卡。两个层面同时并行：多个 agent 同时跑，每个 agent 内部多个工具调用同时发。优先用平台原生编排（Claude Code 用 Agent 工具或 Workflow；其他平台就顺序调 subagent）。
5. 整合：自己读结果，先专门排查跨 agent 的不一致——subagent 看不到彼此的隐式决策，各自正确的产出组合起来照样可能冲突（不兼容的结构、重复的工作、相互矛盾的假设）。裁决冲突、验证合并后的结论（重跑测试、抽查断言），汇报一个整合过的结论，不是一堆 agent 输出的堆叠。

规则

• 会约束多个子任务的决策（数据结构、接口、命名、方案取向）由你在派发之前定好，并写进每一份受影响的契约——永不留给 subagent 各自发挥。
• 每次派发都写明覆盖范围：包含了什么、丢掉了什么。不许静默截断。
• subagent 的结果是主张，不是事实。整合前先验证：重跑测试、重开文件、重查引文。
• 依赖方向单向：本 skill 可以用 /handoff；永不调用面向用户的 skill。