一、只读型：安全的观察者

只给读工具（Read、Grep、Glob），只出结论。它不写文件，所以最安全；也不改状态，所以可以随便重跑。 适合评审、审计、找问题、查依赖。这类活的共同点是「产出是一份判断」，不是「一堆改动」。 演示里它读十二个文件、四千八百 token 的输入，主窗口只留一条结论。

只读型的最大好处是可重复：同一个任务跑三遍，结果不会互相污染。 这让它很适合做「先看看，再决定要不要动」的第一道。

二、执行型：高噪声任务处理器

给写工具，让它在自己那边改、自己那边试。噪声（编译输出、测试日志、失败重试）全留在外面。 适合批量改、批量补测试、批量升级依赖。这类活的特点是「过程很长，结论很短」。 演示里它跑三十条命令、三千六百 token 的命令输出，主窗口还是只留一条回执。

执行型要配两样东西：明确的写范围（哪些目录能改），和明确的停止条件（试了几次还不成就返回失败， 别无限重试）。 少了后者，它会一直在那边试——主窗口在等，而你看不见它在干什么。

三、并行型：多专家工作流

几个子智能体同时跑，各管一块。总时间等于最慢的那个，总 token 是几份相加。 适合多目录、多语言、多方案对比。判据是「这几块之间没有依赖」——有依赖就不能并行。 演示里三个各读八个文件，总账是一万二，墙钟是一份。

并行最容易踩的坑是写冲突：两个都改同一个文件，后写的赢，先写的改动无声消失（4.8 节）。 所以并行的边界要按文件划分，不能按「谁先抢到」。这一条比省时间重要得多。

四、流水线型：串行处理链

上一步的产出是下一步的输入。改完必测、测完必审、审完必合并。 墙钟是几份相加，token 也是几份相加——它两头都不省。 它省的是「每一步都能拿到上一步的结论」。这个价值在「下一步必须知道上一步做了什么」时才成立。

演示里四段串行，墙钟四份。 如果把它改成并行，第二步就不知道第一步改了什么——那时候省下来的时间全变成返工。 所以流水线的判据是：后一步的输入，是不是前一步的输出。是，就只能串。

五、团队型：自组织协作

几个子智能体互相发消息，动态分工。谁有空谁接，谁擅长谁做。 演示里三个互相传消息，消息量是三条。真实场景里消息量会随人数平方增长——三个人三条，五个人十条。 适合探索性任务：事先不知道要分成几块、也不知道谁该做什么。

代价是可控性最差：你没法定死谁做了什么，也没法预估成本。 所以它适合「一次性的探索」，不适合「每天要跑的流程」。 团队型还有一个隐性成本：消息本身也是 token。 三个人传三条消息，每条都进各自的窗口，一份消息付三份钱。

六、怎么选

先问「这次要的是干净、是时间、还是前后依赖」——三个答案对应三类形状。 要干净：只读型。它的产出是判断，跑几遍都不污染。 要时间且各块独立：并行型。记住写冲突那条边界。

要前后依赖：流水线型。别为了省时间改成并行，省下来的会变成返工。 事先不知道该怎么分：团队型。但要接受它的不可控，并且只用在一次性探索上。 还有一种情况：活又长又会改东西——执行型。它和只读型的区别只在「给不给写工具」。

七、动手 Demo：五种模式各跑一遍，主窗口和总账各是多少

同一个「给一批模块补测试」的活，用五种分工形状各做一次。 单位统一估：读一个文件四百 token、跑一条命令一百二、一个子智能体的系统提示八百。 三张表：形状长什么样、主窗口峰值多少、总账与墙钟各是多少。

MODES = [
    (u"只读型", u"读十二个文件找问题", 1, 12, 1),
    (u"执行型", u"跑三十条命令改代码", 1, 30, 1),
    (u"并行型", u"三个方向各读八个文件", 3, 8, 1),
    (u"流水线型", u"四段串行：改、测、审、合并", 4, 1, 4),
    (u"团队型", u"三个智能体互相传消息", 3, 1, 3),
]
# 主窗口峰值：只留指令和回执，过程不进主窗口

实跑输出：

--------------------------------------------------------------------
五种模式各跑一遍，主窗口和总账各是多少
--------------------------------------------------------------------

  同一个「给一批模块补测试」的活，用五种分工形状各做一次。
  单位都是估算：读一个文件 400 token、跑一条命令 120 token、一个子智能体的系统提示 800。

  ① 五种形状各自的样子
  --------------------------------------------------------------------
| 模式 | 比喻 | 形状 | 适合 |
|---|---|---|---|
| 只读型 | 安全的观察者 | 只给读工具，只出结论 | 评审、审计、找问题 |
| 执行型 | 高噪声处理器 | 给写工具，噪声留在它那边 | 批量改、批量补测试 |
| 并行型 | 多专家 | 几个同时跑，各管一块 | 多目录、多语言、多方案 |
| 流水线型 | 串行链 | 上一步的产出是下一步的输入 | 改完必测、测完必审 |
| 团队型 | 自组织 | 互相发消息，动态分工 | 探索性任务 |


  ② 主窗口峰值：谁把东西挡在外面
  --------------------------------------------------------------------
| 模式 | 子智能体数 | 各自处理量 | 主窗口峰值 |
|---|---:|---:|---:|
| 只读型 | 1 | 4800 | 1580 |
| 执行型 | 1 | 3600 | 1580 |
| 并行型 | 3 | 3200 | 1900 |
| 流水线型 | 4 | 120 | 1400 |
| 团队型 | 3 | 720 | 1920 |

  只读型和执行型的主窗口几乎一样干净——差别在子智能体那边：只读型读文件，执行型跑命令，
  噪声量不同但都留在外面。

  ③ 总账与耗时：并行省时间不省 token
  --------------------------------------------------------------------
| 模式 | 总 token（含子智能体） | 墙钟 |
|---|---:|---|
| 只读型 | 5600 | 1 份 |
| 执行型 | 4400 | 1 份 |
| 并行型 | 12000 | 1 份 |
| 流水线型 | 17600 | 4 份 |
| 团队型 | 4560 | 3 份 |

  并行型的墙钟是一份——三个同时跑，总时间等于最慢的那个。但 token 是三份，一分不少。
  流水线型的墙钟是四份，因为四段必须串着来；token 也是四份。
  它省的不是钱也不是时间，是每一步都能拿到上一步的结论。
  ! 所以选形的判据不是「哪个便宜」，是「这一次要什么」：要干净选只读型，要时间选并行型，
  要前后依赖选流水线型。

①五种形状各自的比喻、形状和适合场景，这张表可以当选型表用。 ②主窗口峰值那张表里，只读型和执行型差不多——差别在子智能体那边：只读型读文件，执行型跑命令， 噪声量不同但都留在外面。 这才是委派的核心：主窗口这一侧的占用，跟子智能体那边干多脏的活无关。 ③总账那张表要看两个方向：并行型的墙钟是一份（三个同时跑，时间等于最慢的那个），但 token 是三份， 一分不少。 流水线型的墙钟是四份，因为四段必须串着来；token 也是四份。 它省的不是钱也不是时间，是每一步都能拿到上一步的结论。 ④所以选形的判据不是「哪个便宜」，是「这一次要什么」：要干净选只读型，要时间选并行型， 要前后依赖选流水线型。 团队型是唯一一个「消息量随人数平方增长」的形状，也是唯一一个没法定死分工的。 它适合一次性探索，不适合每天跑的流程。

30 秒实验

1. 把并行型从三个改成五个，重跑第 ③ 步。墙钟变了吗？总账涨多少？这说明并行的成本由什么决定？
2. 把流水线型的四段改成两段，重跑一遍。墙钟和总账各降多少？少掉的那两段，风险体现在哪？
3. 给执行型加一条「试三次不成即返回失败」，重跑第 ② 步。 这条限制影响的是主窗口峰值还是子智能体的总账？

常见误区

1. 把五种模式当成五个「档次」，觉得后一种比前一种高级。它们是五种形状，对应不同的活。
2. 为了省时间把有依赖的步骤改成并行。省下来的时间会以返工的形式还回去。
3. 并行时让几个子智能体都改同一个文件。后写的赢，先写的改动无声消失。
4. 给执行型不设停止条件。它会一直在那边试，而主窗口在等，你看不见它在干什么。
5. 用团队型跑每天要跑的流程。它的分工是动态的，成本不可预估，也不可复现。

形状会摆了，下一节把它们和第 3 章的技能拼起来：一个管怎么做，一个管在哪做。

• ☐ （本篇完，下一篇 4.5 子智能体与 Skills 的协作）

相关笔记

• 定义与配置：四个字段定一个
• 与 Skills 协作：技能与子智能体怎么配
• Claude Code 橙皮书 · 索引
• 🐎 Claude Code 实战 · 索引