协调器模式：主进程只负责指挥

本章摘要：
协调器模式是 Subagent 系统的一种"极端分工"——剥夺主 Agent 的全部动手能力，迫使它只做综合与编排。Subagent (Worker) 执行具体任务，并互相共享研究发现。

普通模式下，Main Agent 既能思考又能动手——读文件、写代码、跑测试、做决策，一身多职。大多数场景够用，但项目规模一旦膨胀，单个 Agent 同时承担研究、架构、编码、验证，注意力被严重稀释。

协调器模式给出一个极端解法：让主 Agent 彻底放弃动手能力，只保留指挥权，变成协调器（Coordinator）。它不能读文件、不能写代码、不能执行命令——唯一能做的是拆任务给 Subagent (也即 Worker)，综合结果、向用户汇报。

关于分工：本章讲的是"协调器模式"——它是 Subagent 系统的一种特定运行模式。Subagent 通用机制在上一章讲过。Agent Teams（水平协作）在通往 AGI 之路章节单独介绍。

协调器与普通 Subagent 的区别

Agent 的能力由两件事决定：系统提示词 + 工具集。截断其中任何一个，就改变了 Agent 的行为边界。协调器模式正是同时改了这二者。

系统提示词

系统提示词被完全替换为协调器专用提示词——不是追加，是从头到尾换成协调器专用版本。提示词的核心编排逻辑是：定义角色 → 介绍工具 → Worker 能力 → 规定工作流 → 实操规范 → 示例。

角色：定义协调器身份、消息发送规则（仅给用户看）、Worker 结果处理方式
工具：列出 4 个工具 + Worker 调用约束 + Worker 结果格式
Worker：定义 Worker 的能力（标准工具 + MCP + 技能）
任务工作流：四阶段（研究 / 综合 / 实现 / 验证）+ 并发规则 + 失败处理
Worker Prompt：综合原则、目的声明、继续 vs 新建选择、正反面示例
示例：完整的"用户提问 → 并行研究 → 综合 → 实现 → 用户追问"流程

工具集

协调器（Main Agent）被"截肢"为 4 个工具——创建 Worker、给 Worker 发消息、停止 Worker、输出结构化结果。没有 Read、没有 Write、没有 Edit、没有 Bash，无法执行具体任务。

这种"截肢"是有意为之。如果协调器保留读写能力，它会忍不住自己动手——一旦动手，就不再是协调器，而是回到了"一个 Agent 做所有事"的老路。剥夺能力是最强的行为约束。

Worker：被召唤的执行者

协调器创建 Worker 来执行具体任务。Worker 拥有独立的上下文窗口和完整的执行能力——和协调器截然相反。

Worker 的角色由协调器赋予

Worker 没有多种内置角色，只有一个统一的通用 Worker。它在四阶段工作流中承担什么职能，完全取决于协调器在任务描述中写的内容。

这里需要区分两层信息：

系统提示词：Worker 自身的 Agent 定义生成，包含通用的行为准则，并追加行为备注和环境信息（与普通 Subagent 的系统提示词拼接路径一致，详见上下文：Agent 的记忆与视野）
用户消息：协调器在 Agent 工具调用中传入的 prompt 参数——具体任务描述、相关上下文、期望输出格式

Worker 的 API 请求结构：
┌────────────────────────────────────────────┐
│  系统提示词                                │
│  ├─ Worker 的 Agent 定义（行为准则）       │
│  ├─ 行为备注（绝对路径、禁用 emoji 等）    │
│  └─ <env> 环境信息块                       │
├────────────────────────────────────────────┤
│  用户消息                                  │
│  └─ [0] user: "协调器传的 prompt"          │
│     （任务描述、上下文、输出格式要求）     │
└────────────────────────────────────────────┘

协调器写"研究认证模块的代码结构"，Worker 就承担研究职能；写"按照以下规范修改认证代码"，Worker 就承担实现职能。角色不是 Worker 内置的，而是协调器通过任务描述临时赋予的。

Worker 看不到对话历史

这是协调器模式的关键约束：Worker 没有对话历史。协调器发给 Worker 的任务描述必须完全自包含——任务、相关上下文、期望输出格式，所有信息都要在一条消息里说清楚。

协调器不能写"继续上次的工作"或"基于之前的分析"——Worker 根本不知道"上次"和"之前"是什么。如果需要延续工作，协调器有两个选择：

继续：给同一个 Worker 发后续消息，保留它的上下文
重建：创建新 Worker，在任务描述中把所有必要信息重新交代一遍

这种"Worker 看不到历史"的设计不是缺陷，是有意为之的隔离——避免无关上下文污染子任务。

默认权限模式

Worker 默认使用 acceptEdits 权限模式——文件编辑自动批准，不需要人工确认。这避免了 Worker 的权限请求全部冒泡到协调器终端造成交互风暴。但如果任务涉及高风险操作（如删除文件、执行未知脚本），协调器可以在 prompt 中提醒 Worker 谨慎行事。

四阶段工作流

协调器按四阶段推进任务，这是协调器模式的核心节奏：

text

Research（研究）
  多个 Worker 并行探索代码库
  发现文件、理解结构、定位问题
  结果写入共享空间

Synthesis（综合）
  协调器读取所有 Worker 的研究发现
  消化、提炼、形成自己的理解
  写出具体的实施规范

Implementation（实现）
  Worker 按照实施规范执行代码修改
  每个 Worker 操作不同的文件集，避免冲突

Verification（验证）
  Worker 测试修改是否正确
  运行测试、类型检查、甚至操作浏览器确认 UI

四个阶段对并行的支持程度不同：

研究：自由并行——只读操作，互不干扰
综合：仅协调器——综合是协调器的核心职责，不能委托
实现：受限并行——写操作不能并发编辑同一文件，需按文件集分配
验证：可与实现并行——只要操作不同文件区域

协调器被鼓励"扇出"——在一条消息中同时启动多个 Worker。

Synthesis 是协调器最重要的工作

协调器提示词对综合阶段有一段严厉的警告：

"You must synthesize — this is your most important job."

综合不是把 Worker 的输出拼接起来。协调器必须：

阅读所有 Worker 的研究发现
形成自己的理解——哪些路径是确认的、哪些是推测的、哪些还没调查
写出具体的实施规范——不是"修改认证模块"，而是"在 src/auth/login.ts 第 42 行，将 validateToken 的返回值从 boolean 改为 AuthResult 对象"

这种严格要求防止信息丢失。如果协调器只是转发 Worker 的发现，每个后续 Worker 只能看到前一个 Worker 的输出，而不是协调器的全局理解。综合让协调器成为信息枢纽——所有知识经过它的消化后，以更高密度、更准确的形式传递给下一个 Worker。

共享空间：Worker 之间的唯一桥梁

Worker 之间不能直接通信。所有信息流必须经过协调器——这是一个星型拓扑，协调器是中心节点。

但有一个例外：共享文件空间（通常称为 Scratchpad）。这是一个文件系统目录，所有 Worker 都可以自由读写，不需要权限确认。它的设计目标是成为 Worker 之间的持久化共享知识空间。

Scratchpad 的典型用法：

text

Research 阶段
  Worker A → 写入 scratchpad/xx-分析报告.md
  Worker B → 写入 scratchpad/yy-分析报告.md
  Worker C → 写入 scratchpad/zz-分析报告.md

Synthesis 阶段
  协调器 → 读取所有分析文件 → 写入 scratchpad/实现规范.md

Implementation 阶段
  Worker D → 读取 规范 → 实现其负责的部分
  Worker E → 读取 规范 → 实现其负责的部分

Verification 阶段
  Worker F → 读取 scratchpad/ 中的变更日志 → 验证正确性

为什么不用消息传递代替文件共享？因为 Worker 的上下文是隔离的——Worker A 不知道 Worker B 的存在，也无法给它发消息。文件共享绕过了这个限制：不需要知道"谁"在读，只需要把信息放在一个约定的位置。

程序之间通过文件协作，而不是通过 API 互相调用。这让 Worker 保持松耦合。选择依据：

协调器模式：任务需要多步骤协调，Worker 之间需要共享研究发现，且需要严格分离"思考"和"执行"
Fork 模式：独立的并行搜索/调研任务，缓存命中率是关键考量

代价与限制

协调器不能直接行动。想读一个文件？必须派 Worker。想改一行代码？必须派 Worker。对于简单任务（"这个函数在哪里？"），协调器模式的开销远大于收益。

Worker 之间不能直接通信。所有信息必须经过协调器中转或通过共享文件空间。

不能嵌套。Worker 不能再创建 Worker。协调器是唯一的指挥层级。

与 Fork 模式互斥。当协调器模式激活时，Fork 模式自动禁用。两套机制不能同时运行。

本章要点

协调器模式是 Subagent 系统的特定运行模式，不是独立概念
剥夺能力是最强的行为约束——协调器只保留 4 个编排工具
角色由协调器赋予——Worker 自身没有角色，只有统一的通用执行能力
Synthesis 是协调器最重要的职责——综合质量决定后续 Worker 的执行质量
共享文件空间让 Worker 保持松耦合
协调器模式适合多步骤、需要共享研究发现的复杂任务

协调器模式：主进程只负责指挥 ​

协调器与普通 Subagent 的区别 ​

系统提示词 ​

工具集 ​

Worker：被召唤的执行者 ​

Worker 的角色由协调器赋予 ​

Worker 看不到对话历史 ​

默认权限模式 ​

四阶段工作流 ​

Synthesis 是协调器最重要的工作 ​

共享空间：Worker 之间的唯一桥梁 ​

代价与限制 ​

本章要点 ​