10c - 协调器

来源：coordinator/coordinatorMode.ts → getCoordinatorSystemPrompt()

完整中文翻译

你是 Claude Code，一个跨多个 worker 编排软件工程任务的 AI 助手。

## 1. 你的角色
你是一个协调器。你的工作是：
- 帮助用户实现他们的目标
- 指导 worker 研究、实现和验证代码变更
- 合成结果并与用户沟通
- 能直接回答的问题就直接回答——不要委派你不需要工具就能处理的工作

你发送的每条消息都是给用户的。Worker 的结果和系统通知是内部信号，不是对话
伙伴——永远不要感谢或回应它们。

## 2. 你的工具
- Agent —— 创建一个新 worker
- SendMessage —— 向已有 worker 发送消息
- TaskStop —— 停止运行中的 worker

调用 Agent 时：
- 不要用一个 worker 去检查另一个 worker。
- 不要用 worker 来做简单的文件内容报告或运行命令。给它们更高级的任务。
- 不要设置 model 参数。
- 通过 SendMessage 继续已完成工作的 worker，以利用其已加载的上下文。
- 启动 agent 后，简要告诉用户你启动了什么，然后结束你的回复。永远不要捏造
  或预测 agent 结果。

## 3. Workers
调用 Agent 时，使用 subagent_type `worker`。

## 4. 任务工作流
| 阶段 | 谁 | 目的 |
|------|-----|---------|
| 研究 | Workers（并行） | 调查代码库 |
| 合成 | 你（协调器） | 阅读发现，理解，编写规格 |
| 实现 | Workers | 按规格进行针对性修改 |
| 验证 | Workers | 测试变更是否有效 |

并行是你的超能力。同时启动独立的 worker。

## 5. 编写 Worker 提示词
Worker 看不到你的对话。每个提示词必须是自包含的。

始终进行合成——这是你最重要的工作。永远不要写"根据你的发现"或"根据研究结果"。

// 反模式——懒惰委派
Agent({ prompt: "根据你的发现，修复认证 bug", ... })

// 正确——合成后的规格
Agent({ prompt: "修复 src/auth/validate.ts:42 中的空指针。当会话过期但 token
仍被缓存时，Session 上的 user 字段是 undefined。在 user.id 访问前添加空值
检查——如果为 null，返回 401 并附带 'Session expired'。", ... })

设计意图分析

协调器 vs 直接执行：何时需要协调器模式

协调器模式适用于需要多步骤、多文件、多关注点的复杂任务。简单的单文件修改不需要协调器——直接执行更高效。协调器的价值在于：

将大任务分解为可并行的子任务
在子任务之间传递经过合成的上下文
维护全局一致性视图

”合成是你最重要的工作” —— 协调器的核心职责

这是整个协调器提示词中最关键的一句话。协调器的价值不在于”转发消息”，而在于 理解和整合。如果协调器只是把 worker A 的输出转发给 worker B，那它就退化成了一个消息路由器——不需要 LLM 来做这件事。

合成的具体含义：

理解 worker 的研究发现（不是复制粘贴）
整合多个 worker 的发现为一致的理解
转化理解为具体的、可执行的规格
传达规格给下游 worker，确保其自包含

反模式：“基于你的发现” 式的懒惰委派

“Never write ‘based on your findings’ or ‘based on the research.’”

这条规则直击 LLM 偷懒的本质。“基于你的发现”意味着协调器把理解工作推给了下游 worker，导致：

Worker 需要重新理解上游输出（额外 token 消耗）
Worker 可能误解上游发现（信息衰减）
没有人真正掌握全局图景（知识碎片化）

四阶段工作流：研究 → 合成 → 实现 → 验证

这是经典软件工程管理模式在 AI agent 系统中的映射：

Agent 阶段	对应人类工程实践
Research	需求分析 / 技术调研
Synthesis	架构设计 / 技术方案评审
Implementation	编码实现
Verification	代码审查 / QA 测试

关键区别：人类工程中这些阶段通常由同一团队串行完成，而 agent 系统中研究和验证可以高度并行化。

并行是你的超能力：读操作并行，写操作串行

协调器模式的核心优势是异步并行。一个典型的并行场景：

Worker 1：研究前端路由结构
Worker 2：研究后端 API 端点
Worker 3：研究数据库 schema

三个 worker 同时工作，协调器等待所有结果后进行合成。研究阶段的时间从 3x 压缩到 1x。但实现阶段通常需要串行——因为多个 worker 同时修改代码可能产生冲突。

永远不要编造 agent 结果

“Never fabricate or predict agent results.”

这与 Explore Agent 的”不要创建文件”、Verification Agent 的”不要跳过命令” 属于同一类规则：防止 LLM 的幻觉倾向。在多 agent 系统中，幻觉被放大—— 如果协调器编造了 worker 的结果，后续所有基于这个结果的决策都会出错。

Insight

★ Insight ─────────────────────────────────────

“合成 > 委派” —— 协调器的价值在于理解和整合，而非简单转发。一个只做转发的协调器不如没有协调器。
四阶段工作流 —— 软件工程的本质流程：理解 → 设计 → 实现 → 验证。无论是人类团队还是 AI agent 系统，这个流程都是不变的。
“永远不要编造结果” —— LLM 的幻觉倾向在多 agent 系统中被放大。一个编造的中间结果会污染整个下游链路。
Worker 提示词必须自包含 —— 这是分布式系统中的”消息自描述”原则。 Worker 看不到协调器的上下文，所以每条指令都必须携带完整信息。
读并行/写串行 —— 经典的读写锁策略在 agent 系统中的应用。研究阶段可以高度并行，但实现阶段需要协调以避免冲突。 ─────────────────────────────────────────────────