## Planner、Worker 与双 Reviewer

<!-- slot: 目标 -->
`1 planner + 1 worker + 2 reviewers` 是默认阵型。

关注 4 个问题：

- 为什么这样拆
- 4 个角色分别做什么
- 为什么两个 Reviewer 要独立
- 资源不足时怎么降级

<!-- slot: 边界 -->
只讲默认阵型与降级方式。

<!-- slot: 提示词 -->
```text
从今天开始，我们默认按 4 个职责协作：
1. Planner：定义目标、范围、风险和拆分
2. Worker：实现单一子任务并给出验证证据
3. Reviewer A：使用同一 Reviewer 模板独立检查
4. Reviewer B：使用同一 Reviewer 模板独立检查
```

<!-- slot: 流程 -->
1. Planner 先做只读研究和任务拆分
2. Worker 只接一个明确子任务
3. Reviewer A 与 Reviewer B 使用相同的角色模板和相同的上下文骨架
4. 两个 Reviewer 独立执行，不串讲、不共享中间判断
5. Reviewer 的反馈先回流给 Worker，直到结果收敛。

![Planner、Worker 与双 Reviewer 的协作流：Planner 先做研究与拆分，Worker 做最小实现，Reviewer A 与 Reviewer B 使用相同模板独立复核，反馈统一回流给 Worker 持续迭代。](../../media/chapters/fig-10-01-planner-worker-reviewers-agentteam.svg){#fig-10-planner-worker-reviewers-agentteam width=96%}

### 为什么要独立

同一个模型自己写、自己审，更容易沿着自己的思路继续解释自己。
独立 Review 的价值，是拿到另一份证据，并把问题继续压回 Worker 迭代，而不是直接把两份意见都抛给 Human。

### 什么时候只换模型、不换模板

下面几类改动，可以让两个 Reviewer 使用不同模型，但仍然保持相同的角色模板、相同的上下文结构和相同的 review 目标：

- 影响范围跨模块
- 涉及数据、权限、安全、迁移或兼容性
- 改动较大，人工不可能逐行细看
- 同类问题最近发生过回归

<!-- slot: 配置 -->
最小配置按职责分配：

| 角色 | 更需要的能力 |
| --- | --- |
| Planner | 研究、澄清、拆分、风险识别 |
| Worker | 实现、局部验证、证据整理 |
| Reviewer A | 使用统一 Reviewer 模板做独立复核 |
| Reviewer B | 使用统一 Reviewer 模板做独立复核 |

降级顺序：

1. `Planner + Worker + 1 Reviewer`
2. `Planner + Worker + 人类独立 Review`
3. 单 Agent，只用于小而低风险的问题

<!-- slot: 异常 -->
最常见的失败有 3 类：

- 名义上 4 个角色，实际上只有一个 Agent 串行做完全部工作
- Reviewer 先看了 Worker 的完整思路，失去独立性
- Planner 只给一句泛泛计划，导致 Worker 现场补设计

<!-- slot: 审批 -->
`Reviewer` 给的是独立评审意见；这些意见先回流给 Worker 继续修改，不等于最终批准。

<!-- slot: 外部系统 -->
搜索、代码托管或文档能力应由 Runtime 或 Skill 提供，而不是让角色越界代做。

<!-- slot: 验收 -->

<!-- slot: 媒体槽位 -->
<!-- media: fig-10-01-planner-worker-reviewers-agentteam.svg -->