Anthropic 源码里藏着一张决策表:什么任务让 AI 并行,什么任务必须它亲自做

系列：比别人多看一层（第五篇）

多 Agent 听起来很美——一群 AI 同时干活，效率翻倍，甚至翻十倍。

于是很多人开始用，然后发现一个尴尬的现实：结果比单个 AI 还乱。任务重复，代码冲突，最后 Coordinator 拿着一堆碎片不知道怎么拼在一起。

问题出在哪？

大多数人用多 Agent 的方式是错的——他们把 Coordinator 当成一个”派单员”，任务来了就往外扔，扔完等结果。但 Anthropic 的源码说得很清楚：

Coordinator 不是外卖平台，它是项目经理。

这篇文章拆解 coordinatorMode.ts 里的核心逻辑——一张精确的并行/串行决策表，一套 Worker 复用决策树，还有一件 Coordinator 永远不能外包出去的事。

Coordinator 到底是谁？

getCoordinatorSystemPrompt() 函数的第一句话是这样定义 Coordinator 的身份的：

// coordinatorMode.ts - 系统提示词开头"You are Claude Code, an AI assistant that orchestrates software engineering tasks across multiple workers."// 你是 Claude Code，一个跨多个 Worker 协调软件工程任务的 AI 助手

四个职责，一个比一个微妙：

1. 帮用户实现目标
2. 指挥 Workers 研究、实现、验证代码变更
3. 综合结果，与用户沟通
4. 直接回答能直接回答的问题——不要把不需要工具的工作委派出去

第四条很容易被忽略。它在说：能自己搞定的事，别装作很忙去派单。

这就好比一个项目经理，你问他”这个函数叫什么名字？“，他如果说”好的，我去安排一个研究员帮你查”——这不是高效，这是失智。

多 Agent 不是用来显摆自己在管一支团队的，是用来解决真正需要并行的问题的。

官方决策表：这才是核心

好，现在说说那张藏在源码里的决策表。

coordinatorMode.ts 的提示词里有一个完整的 Phase 表格，明确规定了每个阶段的执行者和并行策略：

看起来只是一张表，但每一行都有讲究。

Research 阶段：撒网越大越好。

五个 Worker 同时去读文档、查接口、分析依赖——这是多 Agent 真正省时间的地方。没有顺序依赖，没有共享写入，纯读取任务，并行跑起来零风险。

Synthesis 阶段：只有一个人能做。

Coordinator 自己。不可外包，不可委托。

后面会详细说为什么，但先记住这个结论：如果你让一个 Worker 去”基于研究结果做决策”，你已经在犯一个被源码明确列为反模式的错误。

Implementation 阶段：有条件的并行。

同一批文件，必须串行——否则两个 Worker 同时改 auth.ts，git 冲突是小事，逻辑互相覆盖才是大事。不同文件域，可以并行——前端组件和后端接口不打架，尽管跑。

Verification 阶段：大胆并行。

验证是读行为，不是写行为。不同文件域的验证完全可以同时跑，甚至可以和 Implementation 并行（只要验证的是另一批文件）。

源码原文对并行的态度是这样写的：

“Parallelism is your superpower. Workers are async. Launch independent workers concurrently whenever possible — don’t serialize work that can run simultaneously and look for opportunities to fan out.”

翻译过来：并行是你的超能力。主动找机会扇出，不要把能同时跑的事排队串行。

这句话藏着一个反直觉：很多人以为 Coordinator 的工作是”谨慎地一步步分配任务”，而 Anthropic 的设计意图恰恰相反——鼓励激进地并发，只在真正有依赖关系的地方收手。

Worker 要不要复用？一个被低估的问题

多 Agent 里有一个问题很少被讨论：当一个 Worker 刚做完研究，下一步要实现，这个 Worker 该继续用，还是新开一个？

这不是小问题。用错了，要么带着一堆无关上下文污染新任务，要么白白丢掉宝贵的文件知识。

源码里有一套完整的决策树：

源码里的判断标准是一句很朴素的话：

“There is no universal default. Think about how much of the worker’s context overlaps with the next task. High overlap -> continue. Low overlap -> spawn fresh.”

没有通用默认值。想想 Worker 的上下文和下一个任务的重叠程度——高重叠，继续用；低重叠，新建。

这个逻辑和人类团队其实是一样的。

一个工程师刚刚深入研究了某个模块的每一行代码，现在要修这个模块的 bug——当然让他继续做，他脑子里全是上下文。但如果你让同一个工程师去验证另一个人写的代码，他带着”这代码应该这么实现”的预设，验证的独立性就打了折扣。

所谓新鲜眼睛，就是没有先入之见。

这一件事，Coordinator 永远不能外包

现在说 Synthesis——多 Agent 里最被忽视、也最容易出错的环节。

Research 阶段结束了，五个 Worker 返回了各自的发现。Coordinator 下一步怎么做？

错误示范（被源码明确列为反模式）：

// 反模式：把理解工作转包给 WorkerAgent({ prompt: "Based on your findings, fix the auth bug"// "基于你的发现，修复 auth bug"// ← 这句话把"搞清楚要改哪里"的工作甩给了 Worker})

正确示范（Coordinator 先消化，再下达精确指令）：

// 正确模式：综合完研究结果，派发具体规格Agent({ prompt: `Fix the null pointer in src/auth/validate.ts:42.   The user field on Session (src/auth/types.ts:15) is undefined   when sessions expire but the token remains cached.   Add a null check before user.id access — if null,   return 401 with 'Session expired'.   Commit and report the hash.`// 具体到：文件路径、行号、根本原因、修复方案、预期输出})

源码里明确列出了两个”禁语”："based on your findings" 和 "based on the research"。

这两个短语出现在 Worker 提示词里，意味着一件事：Coordinator 没有做好自己的工作，把理解的责任推给了执行者。

这不只是技术问题，这是一个管理原则：

拍板是 Coordinator 的责任，Worker 只负责执行清晰的指令。

如果你把”想清楚”的工作也外包出去，你会得到什么？每个 Worker 凭自己的理解去诠释”auth bug”，结果五花八门，你最后还是得自己捋清楚——等于多绕了一圈。

Synthesis 是多 Agent 系统的核心价值所在，也是 Coordinator 和”派单员”的本质区别。

验证不是”跑通测试”——Anthropic 的标准比你想的严

最后说验证。

很多人理解的 Verification 是：测试绿了，完成。

源码里的定义截然不同：

“Verification means proving the code works, not confirming it exists.”

验证意味着证明代码能工作，不是确认代码存在。

具体来说，Anthropic 定义了四个要求：

用功能开启状态跑测试——不只是”测试通过”，要确认是在真实配置下通过的，不是因为功能被 mock 掉了所以没报错。

跑 typecheck 并调查每一个错误——不能以”不相关”为由忽略类型错误。如果改完一个函数之后出现了新的类型报错，那个报错很可能正是问题所在。

保持怀疑——如果有任何疑点，继续深挖，不要过早宣布完成。

独立测试——验证者要证明变更有效，不是替 Worker 的工作背书。

这就是为什么验证任务要用 Spawn Fresh（新建 Worker）而不是让实现者自验证。

实现者太了解自己写的东西了——他们会下意识地跳过某些测试路径，因为”那里我知道没问题”。但新建一个没有任何先入之见的 Worker，它看到的代码和用户看到的代码是一样的，它会踩进实现者没注意到的坑。

自审很难，旁观者才能看出盲区——这不是 AI 特有的问题，代码 review 存在的理由也是这个。

并行写入的最后一道保险：git worktree 隔离

决策表解决了”哪些任务可以并行”的问题，但没解决另一个问题：两个 Worker 同时在同一个 git 仓库里工作，文件系统层面怎么隔离？

光靠”不分配同一批文件”是不够的。假设 Worker A 在改 src/auth/，Worker B 在改 src/api/，它们操作的文件不重叠——但如果它们都在同一个工作目录里，一个 Worker 的未提交暂存变更会干扰另一个的 git status，更别说两个 Worker 同时执行 git add 时的竞态问题。

teamHelpers.ts 里的 TeamFile 结构给了解法：

// teamHelpers.ts - 团队成员结构interfaceTeamMember {agentId: string// Worker 唯一标识name: string// Worker 名称worktreePath?: string// 专属 git worktree 路径（可选）}

每个 Worker 可以有独立的 worktreePath——指向同一 git 仓库的不同 worktree。

git worktree 是 git 的一个功能：同一个仓库可以同时 checkout 到多个目录，每个目录有独立的工作区和暂存区，但共享同一个 .git 对象数据库。

# 主仓库在 /project，给两个 Worker 各开一个 worktreegit worktree add /project-worker-a feature/auth-refactor# Worker A 在 /project-worker-a 工作，独立暂存区git worktree add /project-worker-b feature/api-update  # Worker B 在 /project-worker-b 工作，独立暂存区

效果是：Worker A 和 Worker B 各自在自己的目录里读写文件、暂存变更、提交——互不干扰。Coordinator 最后把各分支 merge 回主线。

这是两层保护：决策表在逻辑层面划定文件域，worktree 在文件系统层面物理隔离工作区。

只有逻辑层的约束，依赖 Worker 自觉；加上物理层的隔离，才算真正的并行安全。

多 Agent 的本质不是”越多越快”

梳理下来，Anthropic 对多 Agent 的设计有一条贯穿始终的判断：

并行的边界，由依赖关系决定，不由任务数量决定。

Research 能并行，是因为读操作之间没有依赖。Synthesis 不能并行，是因为它的输入是所有 Worker 的结果，只有拿到全部信息才能做决策。Implementation 能条件并行，是因为不同文件域之间通常没有即时依赖。Verification 能大胆并行，是因为验证是只读的。

Worker 复用的判断也是同一个逻辑：上下文重叠度高，就是有依赖，继续用；上下文低重叠，就是没依赖，新建隔离。

“基于你的发现来做”这个反模式，本质上是 Coordinator 把自己的依赖关系（我需要先理解研究结果，才能给出精确指令）也一并甩给了 Worker——于是整条链上没有人真正做了 Synthesis，决策就消失了。

那些用了多 Agent 之后反而更乱的团队，往往就是这里出了问题：Coordinator 变成了自动转发机器，Worker 收到的是模糊的大方向，各自理解，各自发挥，最后 Coordinator 面对的是一堆无法拼合的碎片。

多 Agent 的核心，是让 Coordinator 的判断力成为系统的瓶颈——而不是消除它。

下一篇：Claude Code 是怎么读懂一个它从没见过的代码库的——从陌生目录到精准定位，源码级拆解”代码理解”的全过程。