目录

前段时间我盯着 AI 干活，心里琢磨：一个挺大的任务，它一个模块写完再写下一个，我就在旁边干等，等它跑完这个再轮到那个。活儿其实没问题，就是慢——慢在它一直在排队。

后来我想明白一件事：很多模块之间本来就不相干，凭什么要它们一个接一个来？拆开，让几个 agent 同时干，不就完了。

我想要的，和它的边界

我要的很简单：同样一件活、花同样的 token，把完成时间大幅缩短。

但得先把边界说在前头——不是所有任务都能这么拆。这篇讲的是我自己摸索出来的一套做法，仅供参考。

拆得动的前提：架构先得干净

要让几个 agent 互不打架地同时干活，前提不在 AI，在你的架构。

我那个任务能拆，是因为它本身就是好几个模块，彼此通过接口通信，内部实现互不影响——只要照着接口契约来，每一块都能独立完成。说白了就是松耦合、高内聚。这套东西，是我在动手前就和 opus 一起把设计敲定下来的：opus 帮我理、出方案，拍板的人是我。

这一步偷不得懒。架构没拆干净就硬上并行，等于把一团乱麻剪成好几段，每段还连着，结果只会更乱。

分工：谁主控、谁规划、谁动手

设计定了，接下来是排兵布阵。我习惯的分工是这样：

  • opus 当主控，统揽全局、派活、最后把关；
  • sonnet 做 TDD 规划，按设计把每个模块要怎么测、怎么实现的路子先铺好；
  • haiku 负责写代码和跑测试，粗活累活交给它，便宜又够用。

这套分工其实是上一篇”模型分层”的延续——好钢用在刀刃上。只不过上一篇讲的是省钱，这一篇讲的是这几个角色怎么配合着一起干。

编排结构：opus 主控在上，往下把独立模块派给 sonnet 规划、haiku 实现，模块内还能再分工；活干完回到 opus 手里复核

怎么把它们撒出去

具体落地，我做了三件事：

  1. 全局 CLAUDE.md 里写死一句：”能并行就并行。”这是给所有项目定的默认规矩。
  2. 在 Claude 的设置里调最大并行 subagent 数——这是那个真正管用的”上限阀门”。
  3. 每次发指令时再多嘱咐一句：”尽可能并行。”虽然 opus 作为主控自己也会并行派活，但你点一句，它心里更有数。

主控把模块派下去，模块内部它还能再分一层工。一层套一层，整个任务就铺开了。

复核这道，不能省

并行跑得快，质量怎么保证？我的做法是——让主控自己来复核。

道理很直接：活是它派出去的，每个 subagent 该交什么它一清二楚，由它来检查最顺手。我试过另设一个专门的复核 agent，反而要它从头把任务再理解一遍，多烧一遍 token、还更慢。主控自己复核，省了这道重新理解的开销，又快又准。

复核出问题之后还有个小细节：主控通常会问我一句”这个我直接改掉，还是另起一个 agent 来改？”我一般都回”你直接改”。因为它就是刚才挑出毛病的人，最清楚问题在哪，改起来最直接。

我踩过的两个坑

第一个是内存。一开始我贪心，把最大并行设成了 10 个。结果那会儿手头还并行着别的项目，机器内存一下就被吃干净了。后来我老老实实降到 5 个，反倒清爽——单看这一个任务，5 个并行差不多就是串行的 5 倍效率；再叠上同时在跑的其他任务，整体提速能到 10 倍以上。机器和额度够，这个数还能往上加；不够，就别硬撑。

第二个是别为了拆而拆。有的模块之间耦合很重，本来就该顺着来，你非要把它掰开并行，几个 agent 互相影响，质量根本兜不住。所以交给 AI 之前我会专门嘱咐一句：”这些模块相互有耦合，不要强行拆分。”好在不少 AI 自己也能识别出来，不会硬拆。真碰上拆不动的，就老老实实交给一个 agent 串行做，或者干脆主控自己一条线做完。

一个反直觉的账

很多人一听”并行 5 个 agent 同时烧 token”，第一反应是：那 token 不得翻几倍？

我自己算下来不是这么回事。同样这堆活，你串行做，token 也得消耗差不多的量——该读的还得读，该写的还得写，并行并没有凭空多干什么。并行真正改变的不是花费，是周期：本来要排着队跑完的几段，现在压在同一段时间里一起跑完了。多烧的那一点点 token，换来的是时间成本大幅下降，这买卖太划算。

串行 vs 并行：同样四段活，串行排着队一段段跑完，周期很长；并行压在同一段时间里齐发，周期砍到约 1/5——但两边读写的 token 总量其实差不多。并行省的是时间，不是花费

所以除了那些实在拆不动的，我现在基本是能并行的全并行。

复盘：三条照着做

一，架构先拆干净，才谈得上并行。松耦合、高内聚、按接口契约通信——没有这个底子，拆了也是灾难。设计阶段就和 AI 把它定下来。

二，能并行就全并行，但记得设上限。这个数不是越大越好，盯着你机器的内存和 AI 的额度来定。我从 10 退到 5，就是被内存教育过的。

三，高速并行，必须配复核。而且复核的那个得真懂任务——让派活的主控自己来查，最省也最准；查出问题，就让它直接改。

今天读完就能做的一件事：打开你的全局 CLAUDE.md，加一句”能并行就并行”，再去设置里把最大并行 subagent 数调到一个你机器扛得住的值。下次再丢给它一个能拆的大任务，你会发现它不再排队了。

下一篇我想接着聊一个紧跟着冒出来的问题：几个 agent 同时改代码，凭什么互不打架？这背后靠的是 git worktree——给每个 agent 一块独立的工作区，各改各的，谁也别碍着谁。感兴趣的话评论区告诉我。