一个 AI 指挥
一群 AI 干活

通常，一个人工作的上限，是一个人的速度。 你可以更努力、更聪明、更高效，但一双手只能做一件事。

软件开发里有一种突破上限的方法，叫团队。 你把工作拆解成可以并行的部分，分给不同的人， 然后你的角色从执行者变成协调者—— 你不再做，你分配、追踪、整合结果。

Coordinator Mode（统筹者模式） 把这套逻辑带给了 AI。

开关的背后

激活方式极简：设置环境变量 CLAUDE_CODE_COORDINATOR_MODE=1。 一个环境变量，把 Claude Code 从单兵变成指挥官。

进入 Coordinator（统筹者） 模式后，Claude 的行为发生了根本变化。 它不再亲自写代码，而是负责三件事：

一，拆解任务。把用户给的需求分解成可以独立执行的子任务。 二，派遣 Worker。为每个子任务启动一个独立的 AI 实例去执行。 三，整合结果。收集所有 Worker 的输出，合并成给用户的最终答案。

源码里，这个 Coordinator 的自我定位写得很清楚：

翻译过来："你是协调者。你的职责是帮用户达成目标——指挥 Worker 去调研、 实现和验证代码变更——然后整合结果，向用户汇报。"

五个阶段：一次完整的软件开发任务

Coordinator 的工作流程有五个阶段，这不是简化的概念图， 这是源码里明确标出的工作流：

AI 团队之间如何沟通协作

这里有一个有趣的工程问题：Coordinator 和 Worker 之间，靠什么交流？ 他们没有 Slack 频道，没有邮件，没有共享白板。 他们有三个协作工具：

值得特别说的是 AgentTool 和 SendMessageTool 的区别。

AgentTool 是"召唤新人"——一个空白的 AI，没有任何先前的上下文， 从 Coordinator 给它的任务描述开始理解世界。 适合需要全新视角的任务，比如验证（不想让验证者带着写代码时的思维定势）。

SendMessageTool 是"给老队员发消息"——Worker 还记得之前的对话， Coordinator 可以说"根据你刚刚找到的内容，去修 validate.ts 第 42 行"， 而不需要重新解释整个背景。 适合在同一条任务链上继续推进。

这个设计解决了一个真实的工程效率问题： 什么时候重用上下文（节省解释），什么时候清空上下文（避免偏见）。 两个工具，一个决策框架。

Worker 怎么向 Coordinator 汇报

当 Worker 完成任务，它不能直接"开口说话"—— 这是一个异步系统，Worker 的汇报以一种特殊的格式被投递给 Coordinator：

注意这个汇报的传递方式：它伪装成 user-role 消息， 但以 <task-notification> XML 开头， 让 Coordinator 能识别"这不是用户说的话，这是 Worker 的汇报"。

这是单向的异步回调，不是对话。 Worker 完成任务，把结果打包成这个格式，投递给 Coordinator，然后退出。 它不等 Coordinator 确认，不等 Coordinator 回复，就像寄了一封信，信已发出。

整个 Coordinator ↔ Worker 的通讯模式，更接近消息队列，而不是即时通讯。

理解，永远不能外包

源码里有一段话，是我读整个 Coordinator 系统时印象最深的：

完整的原文是这样的："Never write 'based on your findings' or 'based on the research.' These phrases delegate understanding to the worker instead of doing it yourself."

翻译过来："不要写'基于你的发现'或'基于研究结果'。这些措辞是把理解外包给 Worker， 而不是自己去理解。理解，永远不能外包。"

这是一条关于信息传递的深刻规则。

在人类团队里，这种问题很常见：经理把任务分配下去， 收到下属的报告，然后直接把报告转发给老板，没有任何自己的整合和判断。 这种经理在公司里被称为"邮件转发机器"，他们占据了一个位置，但没有产生价值。

Coordinator 的设计者显然观察过这个问题，并把防止它的规则直接写进了 AI 的提示词里： 你是协调者，不是邮差。读懂结果，才能给出有价值的下一步指令。

并行是超能力，也是风险

Coordinator 系统提示的核心哲学，用了一句很重的话：

翻译过来："并行性是你的超能力。Worker 是异步的。只要有可能就同时启动多个独立 Worker—— 不要把能同时跑的任务排成串行，要主动寻找可以扇形展开的机会。"

但源码里同时也给出了并行的边界：

只读任务（研究、调查）可以自由并行——读文件不会改变文件，多少个 Worker 同时读都没有冲突。 写操作（实现、修改）要一个文件集同时只有一个 Worker 在动——否则两个 Worker 同时修改同一个文件，结果是灾难。 验证可以和不相关区域的实现同时进行。

这个并发控制策略，和数据库里的读写锁逻辑基本一致。 工程师们没有发明新的并发理论，而是把几十年前就成熟的解决方案搬到了这里。 这种"用对的旧工具解决新问题"的工程思维，在整个 Claude Code 源码里随处可见。

共享记忆：Worker 之间的隐形黑板

Coordinator 系统里还有一个值得注意的细节： Scratchpad（暂存目录）。

当 Coordinator 功能开启，系统会给 Worker 们提供一个共享目录： .claude/scratchpad/。 Worker 可以在这里读写文件，这些文件对所有其他 Worker 可见。

这是 AI 团队的共享白板。 研究 Worker 可以把发现的架构图写进 scratchpad， 实现 Worker 可以在这里读到同事的发现，不需要 Coordinator 把所有信息手动传递。 知识在团队内流动，而不是只能通过管理者中转。

这个设计让我想到人类团队里的"Wiki"—— 团队的公共知识库，比任何个人的记忆更完整，比任何经理的转述更准确。 Coordinator 模式也有了自己的 Wiki，只是它活在 AI 会话的生命周期里。

这不只是效率提升

如果 Coordinator Mode 只是"更快地完成任务"，它就只是个效率工具。 但它做的事情超过了这个范畴。

它引入了专业分工——Research Worker 专注调查， Implementation Worker 专注写代码，Verification Worker 专注独立测试。 每个角色都可以针对自己的任务做专门优化。

它引入了相互制衡——写代码的人不验证自己的代码， 验证者不带着写代码时的偏见。 这是人类组织里审计和研发分离的底层逻辑，现在被带进了 AI 协作的设计里。

它引入了规模效应——任务越复杂，并行带来的收益越大。 一个复杂系统的十个子模块，可以同时被十个 Worker 调查， 调查时间不变，但覆盖面扩大了十倍。

Coordinator Mode 是 Anthropic 对"AI 如何扩展到复杂工程任务"这个问题的答案。 不是让单个 AI 更强，而是让 AI 能组成团队。