一个仅65行的小需求让Claude Code跑25个Agent耗时整整两小时的深度解析

一个仅65行代码的小需求，却触发了Claude Code启动25个agent，耗时整整两小时。从效率角度看，这笔投入显然不划算——这么小的改动量，为何需要如此长的处理时间？

确实，正常情况下半小时内即可完成。

不过，别急着否定多agent并行的价值。在大型项目中，它是缩短开发周期的核心手段，没有之一。本文聚焦两个核心问题：如何正确应用多agent并行，以及那次失误的根源。

在大型遗留Kotlin/Akka SLG游戏服务端上，使用Claude Code已有数月之久。之前的讨论聚焦在“知识”层面——CLAUDE.md红线设定和memory积累。这次换个维度，专门聊聊“时间”。

大型项目最大的时间黑洞是编译。一次模块编译动不动三五分钟，几个任务串着做，光等编译就能让人熬不住。多agent并行正是为了折叠这段等待时间。下面先说如何折叠，再说那套三层review流水线——以及用错地方时，是怎样酿成两小时灾难的。

四、Subagent 并行与三层 review：让主对话只当裁判

并行的核心优势其实很直接：几个互不相干的任务一起跑，等待时间是叠在一起的，而不是一个接一个地累加。三个任务各自等三五分钟编译，串行就是三段等待累加；并行派出去，三段等待折叠成一段。

并发数固定为3

触发条件直接写进CLAUDE.md，当成唯一标准，省得每次临时判断：

## Subagent Defaults
- ≥2 个独立写代码任务 且 单个预计 > 30s → 默认并行派 Agent,
  先一句话报备不询问:「准备派 N 个 agent 并行跑 X / Y / Z」
- 写代码 Agent 默认 isolation: "worktree",回来报
  路径 + 分支 + 改动文件数 + 测试结果,主对话只做裁判
- 单条回复并发上限 3 个 Agent,超出先报预算
- 共享配置冲突 → prompt 里预分号段(序列化注册 ID / 协议 tag /
  各种全局注册项),各 agent 取互不重叠区间避免撞号
- 不派:需求含糊(先问)/ 子任务有隐式依赖 / 改动 < 30s / 单文件单点改

这些数字并非随意确定。并发上限定在3，是因为编译堆内存按6g配置，超过3个agent同时编译就开始互相抢资源、互相干扰。预分号段是另一个关键点：多个agent同时去改同一份全局注册文件（序列化ID、协议tag等），如果不在分配前划定互不重叠的区间，必然会撞号。

“worktree隔离 + 主对话只当裁判”是这套玩法的骨架。每个写代码的agent在自己的git worktree中独立操作，回来只汇报四样内容：路径、分支、改动文件数、测试结果。它在探索中的偏差、试错、半成品，全都留在自己的上下文里，一点都不会污染主对话。主对话只负责一件事：看结果，决定是否合并。

两个 reviewer 一定要并行派

对于高风险改动，采用三层架构：一个agent负责写（implementer），两个agent负责审。一个对着spec查实现完整性（spec reviewer），另一个专门找出bug、edge case、跨模块耦合（code-quality reviewer）。

这两个reviewer必须在同一条消息里并行派出。它们读的是同一个commit，彼此无依赖，一个接一个派纯属浪费时间。实测显示，单个Task串行下来需要15到25分钟，spec和quality并行之后压缩到10到15分钟，十个Task攒下来能省50到100分钟。

配套的监控也写死了：

implementer 交付 commit 后:
  spec reviewer 和 code-quality reviewer 在【同一条消息】里并行派
  → 收回两份结论汇总:任一 FAIL 则 fixup,都 PASS 进下一 Task

监控阈值:
  超 6 分钟无产出  → 查是不是 API 529(限流)
  超 12 分钟无产出 → 主对话直接接管,不再干等
  接管前先 git log --oneline + git show HEAD 读已有 commit 再续做

那次两小时是怎样炼成的

三层review用起来确实高效。但场景一选错，它就从提速器变成了绞肉机。

有一次处理一个小需求——一处资源豁免逻辑，设计上拢共65行代码加100行测试，涉及5个文件。当时选择了“subagent-driven”这个执行模式，然后脑子一根筋，严格按流程把它拆成6个Task，每个Task都老老实实跑implementer加两个reviewer加fix loop。一圈下来，agent调用了大约25次，时钟走了整整两个小时。事后汗颜——这玩意儿inline直接写、最后整体review一次，半小时就该收尾了。

事后复盘，发现三个错误交织在一起：

一是把skill里面那句“持续执行不要停”当成了不可违抗的流程。二是把“最高effort”理解歪了，以为effort拉满就等于必须上最重的流程——其实effort说的是质量目标，跟用什么流程是两码事。三是忘了一件最朴素的事：简单任务要快，靠的是inline快速迭代，不是把它拆给一堆agent。

后来流程层数固定为一棵决策树

这件事最后沉淀成CLAUDE.md里的一棵决策树，按改动规模先定层数再开工：

用户选了 subagent-driven 后,先评估改动规模再决定层数:

  < 100 行 + 单/双模块 + 无序列化/DB schema/集群消息
      → inline 实施,不派 implementer

  100-300 行 / 多模块 / 单一服务类
      → 派 implementer,单层 review(一个 reviewer 兼顾 spec+quality)

  > 300 行 / 序列化 schema / 集群消息 / 跨节点协议 / DB migration
      → 完整三层 review

fix loop 强阈值:单 Task review 找到 ≥3 个 nit 或任意 critical 才派 fix agent;
               1-2 个 nit 主对话 inline 直接修

跑超 30 分钟主动停:报「按当前速度估剩余 X 小时,要不要降级」

一句话：三层review只服务于真正高风险的改动——DB schema、序列化注册、集群消息、跨节点协议、外部协议验签这些。纯函数、data class、改个配置这种，单层够了，很多时候inline就完事。

别一上来就用最强模型

派subagent的时候，除了“并行几个”和“review几层”，还有第三个旋钮，和前两个是正交的：模型档位。

早期图省事，不管什么活全派最强模型，纯属杀鸡用牛刀。spec reviewer来来回回干的就是“对着spec查实现齐没齐”这种比对活，中档模型绰绰有余，却用顶配单价烧着它。

后来固化成一张表：

派最低档模型有个前提：它跨文件推理弱，所以prompt里得把具体类名、行号、要改成什么全喂进去，别指望它自己去翻代码。

effort（推理强度）也是同一个道理，要钉在“干一件事”这个粒度上，而不是每条消息上。机械型skill（lint、看板同步、文本改写）的frontmatter直接标成低effort，激活时覆盖整个会话，干完自动恢复；高风险编码则在开工前手动拉满，跟三层review一起触发。说到底，一次风险判断，同时把“并行度 × review层数 × 模型档 × effort”四个旋钮拨到位。

为什么每次 review 同一段代码结论都不同

很多人一开始也会困惑：同一段代码，让Claude review几遍，每次挑出来的毛病都不一样，这正常吗？

正常，而且这恰好是LLM review最值钱的地方。LLM的输出本来就有随机性，注意力走的路每次都会偏移一点。所以多跑几次轻量review，攒下来的覆盖面，反而比一次性拿一张大checklist死磕要广。

review方法论也是顺着这个来的：轻量加发散，不搞穷举。特化的checklist最多5个维度封顶，扫完之后特意留出三成的上下文，去发散checklist以外的直觉——这部分才是最值钱的。哪个维度连着两次在checklist外冒出同类问题，才把它升级成永久红线。从不追求覆盖率那个数字，因为bug藏在你没列到的第N+1个维度上的概率，永远大于零。

nit 当场就修，不要积攒

最后一条，小但吃过亏。review挑出来的nit——KDoc漏了、typo、多余的空行、命名前后不一致这种——要当场让implementer在同一个commit里顺手修掉，绝对别记进什么“follow-up清单”。

以前偷懒，把8条nit全攒到progress文档末尾。结果下次接着干之前，光是重读那张五十来行的清单、一条条重新评估优先级、把上下文捡回来，花的功夫早就超过当场五分钟修完的成本。清单这东西只会越滚越长，攒到最后基本就是永远不修。真正该进follow-up的，只有那种需要外部拍板、要跨任务重构、影响面大的任务。

说到底，并行的核心，就是把“等待”从一段接一段地累加，变成叠在一起一次过；然后用review层数、模型档、effort这几个旋钮，照着风险高低去配火力。但所有这些的前提，是先看清这次改动到底多大——别拿一套两小时的重型流程，去砸一个65行的小活儿。