# Fan Out

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

- Skill: `keli-wen/fan-out-2` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add keli-wen/fan-out-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/keli-wen/fan-out-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: keli-wen (https://skillmd.com/u/keli-wen)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/keli-wen/fan-out-2

---


# 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。