Planner-Coder-Reviewer 模式
系列入口：如何使用 Agent。前置：Orchestrator-Worker 模式。
一、这是把「团队分工」搬进 Agent
一个靠谱的软件团队不会让同一个人闷头规划、写完、还自己宣布没问题，而是有分工：有人定方案、有人实现、有人审查。Planner-Coder-Reviewer 模式就是把这三个角色交给不同 Agent，让成果在角色间交接，每一步都被下一角色校验：
- Planner（规划者）：理解需求、调研代码、产出可执行的方案（步骤、范围、验收标准、风险）。
- Coder（执行者）：严格按确认的方案实现，不自行改方向。
- Reviewer（审查者）：对照方案和需求检查改动，挑逻辑、边界、质量问题，不合格打回 Coder。
核心价值：用一个 Agent 的独立视角去制约另一个 Agent，避免「自己写自己觉得对」的盲区。
二、每个角色交什么、接什么
交接物明确，角色之间才不会错位：
| 交接 | 内容 |
|---|---|
| Planner → Coder | 确认的方案：目标、分步任务、影响范围、验收标准 |
| Coder → Reviewer | 实现的改动 + 自测/测试结果 |
| Reviewer → Coder | 分级问题清单（通过则放行） |
| Reviewer → Planner | 若发现根因在方案，则退回重新规划 |
注意 Reviewer 是独立视角：它不应只是复述 Coder 的说法，而要对照需求和方案独立判断，最好默认上下文隔离、重新读代码，而不是建立在 Coder 的自述上。
三、为什么比「一个 Agent 干到底」更可靠
单个 Agent 从头做到尾，容易在早期埋一个理解偏差，后面一路自我合理化；自己审查自己时，也很难跳出原思路。三角色模式用两道独立关卡切断这种错误累积：方案在动手前先被确认，实现完成后再被一双「没参与写、不护短」的眼睛审一遍。这其实就是把你作为驾驶员的部分把关，自动化成 Agent 之间的制约。
四、什么时候值得用这套更重的流程
它比 Orchestrator-Worker 多了严格的交接和独立审查，成本更高，适合：
- 重要、复杂、错了代价大的任务：核心业务功能、涉及资金或安全的改动；
- 质量要求高于速度、希望产出经过独立把关的场景；
- 你希望减少自己逐行审查负担，让 Reviewer 先过滤一遍。
反过来，简单、低风险的小改动没必要走全套，直接交给单个 Agent 更利落。模式选择本质是在「流程成本」和「质量保障」间权衡。
| Orchestrator-Worker | Planner-Coder-Reviewer | |
|---|---|---|
| 结构 | 主从扇出 | 顺序交接 + 独立审查 |
| 强项 | 并行、快速铺开 | 质量把关、防错误累积 |
| 成本 | 较低 | 较高 |
五、一次完整实战：一个错不起的结算功能
来看一个适合走全套流程的例子。任务是：「给支付系统增加一个新的结算规则，涉及金额计算和资金，绝不能算错。」这种场景用一个 Agent 从头写到尾风险太高，适合三角色协作。
- Planner 出方案：它调研现有结算代码，产出方案——新规则的计算逻辑、要改动哪些文件、边界情况（零金额、退款、跨币种）、验收标准、风险点。方案先交给你确认，这一步能在动手前拦住理解偏差。
- Coder 按方案实现：严格依据确认的方案写代码并自测，不自行改变规则方向，完成后连同测试结果一起交审。
- Reviewer 独立审查：它默认上下文隔离、重新读代码，对照需求和方案逐项检查——计算逻辑是否与方案一致、边界有没有遗漏、测试是否真正覆盖关键路径。发现问题就打回 Coder；如果发现根因在方案，则退回 Planner 重新规划。
- 通过才交付：只有 Reviewer 放行，改动才算完成，最后仍由你签收。
这里最关键的是 Reviewer 的独立性：它没有参与写代码，不会替 Coder 护短，因此能发现「当局者迷」的错。配合两道关卡（方案先确认、成品再独立审），一个早期理解偏差很难一路溜到交付。
六、用好该模式的要点
- 方案必须先确认再实现：否则 Coder 可能在错误方向上一路狂奔。
- Reviewer 务必独立读、独立判：只复述 Coder 的话，这一层就形同虚设。
- 打回要带具体问题清单：让 Coder 知道改什么；根因在方案就退回规划，而不是在实现层硬补。
- 别对小改动滥用全套：流程成本高，简单低风险任务用单 Agent 更利落。
七、常见问题
Q：Reviewer 和单独再开一个 Agent 看代码一样吗？ 关键不在「几个」，而在独立视角和明确判据。Reviewer 默认隔离、对照方案和需求独立核对，并要求给出证据，这才有效。
Q：如果 Planner 和 Reviewer 意见冲突怎么办？ 通常说明需求或方案存在未澄清之处，这时应交回给你判断，而不是让 Agent 之间无限循环。你的顶层裁决仍是最后的质量保障。
Q：每一层都要我参与吗？ 你主要在方案确认和最终签收处把关，中间实现与首轮审查可自动完成。这样既减少逐行审查负担，又守住关键节点。
七点五、为什么「独立视角」是这套模式的灵魂
整套流程里，规划、实现、审查三个环节缺一不可，但真正让它比「一个 Agent 干到底」更可靠的核心，是审查环节那一双独立的眼睛。如果抽掉独立性，让审查者只看执行者的自述、或让同一个思路贯穿始终，那么再多的环节也只是形式，挡不住真正的错误。
为什么独立视角如此关键？这涉及一个普遍的认知规律——无论是人还是模型，一旦沿着某个假设构建了完整的思路，就很难再跳出这个假设去审视自己。 执行者在实现过程中，会不断用「这样做是对的」来说服自己，早期一个细微的理解偏差，会在这个过程中被反复加固，而不是被发现。此时如果审查者也建立在同样的前提和叙述上，它看到的只会是执行者想让它看到的合理性，盲区被完整继承。
打破这个困局的唯一办法，就是引入一个没有参与构建、不背负辩护责任、直接面对原始事实的视角。它不关心执行者怎么解释自己的代码，只对照需求和方案，重新读、独立判。正因为它「事不关己」，才会去翻执行者觉得理所当然、因而略过的边界，去质疑执行者已经自我说服的假设。人类团队里 code review 的价值也正在于此——有效审查的本质从来不是再走一遍流程，而是换一个没被原思路「污染」的头脑重新看待问题。
理解这一点后，你在实际配置时就会特别守护审查者的独立性：默认让它上下文隔离、直接读代码和需求、要求给出具体证据，而不是让它复述执行者的结论。当这双眼睛真正独立，多一层流程的成本才换得来多一道的可靠；反之，再漂亮的交接图也只是自我安慰。
七点六、把流程重量与任务风险匹配
这套模式比主从扇出更重、更贵，因此什么时候用、用到什么程度，本质上是一道风险与成本的匹配题，值得专门说清楚。
一个朴素的判断依据是「错了的代价有多大」。如果改动涉及资金、安全、核心业务链路，一旦出错可能造成直接损失或难以挽回，那么多走几道独立关卡的成本，相对于潜在损失是完全值得的；反过来，一个内部小工具的文案调整、一次低风险的样式修改，出错代价极小，还要走完整的规划—实现—审查全套，就是在用高射炮打蚊子，拖慢节奏却没换来相称的保障。
还要注意流程重量可以调节，而不是非全即无。比如某些任务你判断质量重要、但风险尚可，就可以让规划和审查更轻量，只保留最关键的独立确认；而真正错不起的改动，才让每一步都严格交接、审查更彻底。让流程的厚度跟随风险的大小，而不是给所有任务套同一个重量级模板，这本身就是成熟工程判断的体现。
最后记住，无论流程多重，你在方案确认和最终签收处的把关都不能省——多 Agent 流程是帮你分层过滤、减少逐行审查负担，而不是替你承担最终责任。把「流程重量匹配风险」和「最终责任在你」这两条合起来，你就能既用好这套重型模式的可靠性，又不会被它的成本和形式绑架。
七点七、方案确认是最便宜的质量投资
三角色流程有两道关键关卡，其中最容易被人省略、却性价比最高的，是动手前的方案确认。很多人急于看到代码，让 Coder 在方案还没经过审视时就直接开写，结果把大量成本押在了一个未经验证的方向上。
为什么方案确认如此划算？因为它处在错误最便宜的阶段。一个需求理解上的偏差，在方案阶段只是文字和思路，发现后改几行字、重新对齐即可；而一旦进入实现，同样的偏差会变成写好的代码、调好的细节，甚至被后续审查当成既定事实继承下来，修正成本成倍上升。越往链路后端，同一个早期错误的代价越大，这是软件工程里反复验证的规律。
更重要的是，方案确认让你在投入实现前，有机会对照几个根本问题：方案理解的目标和真实需求是否一致、步骤是否完整可执行、影响范围有没有漏、验收标准是否清晰可判定、风险有没有被识别。这些问题在纸面上暴露，远比在成品里暴露要轻松。把方案确认当作一次便宜的「前置排雷」，而不是拖慢开工的形式，你就能用很小的代价，拦住那些最昂贵的方向性错误。
七点八、打回机制如何避免无限循环
三角色模式依赖「不合格就打回」来保证质量，但打回如果设计不当，也可能演变成角色之间来回推诿、无限修改的死循环，反而拖垮效率。用好打回机制，有几个关键分寸。
首先，打回必须附带具体、可执行的问题清单，而不是一句「不行，重做」。它要明确指出问题在哪一处、违反了哪条标准、期望改成什么方向，让接收方一次就能对准问题修改。模糊的打回只会换来下一次仍然不合格，循环由此产生。其次，要分清打回的去向：问题出在实现，就退回 Coder；如果根上是方案错了，就应退回 Planner 重新规划，而不是让 Coder 在错误方案上反复打补丁。
再者，必须有「终止规则」。通常当审查者发现问题反复指向需求本身的矛盾或未澄清之处、超出 Agent 能自行解决的范围时，就不应再继续自动循环，而应上升到你来裁决。你作为驾驶员的顶层判断，是打破死循环的最终出口。让打回做到「带清单、找对人、有出口」，它就能真正起到逐层收敛质量的作用，而不是变成一个消耗时间和 token 的拉锯战。把这些分寸和前面讲的独立性、风险匹配合在一起，这套重型流程才算真正可用、可控。
七点九、三个角色各自的「越界」风险
角色分工要真正生效，不仅要明确职责，还要警惕每个角色特有的越界倾向。三个角色各有各的跑偏方式，识别它们，才能在协作中及时纠偏。
Planner 的越界风险是过度设计：在方案里塞入超出本次需求的抽象、扩展和「以防万一」，让一个简单任务背上沉重结构，Coder 被带着实现一堆用不上的东西。对治的关键，是要求方案紧贴当前需求、明确范围边界，把「以后可能需要」的内容排除在外。Coder 的越界风险是擅改方向：实现中觉得方案某处不妥，不回去确认就自行换一种做法，导致成品偏离已确认的方案。对治方式是明确「按方案实现，发现方案问题先上报」，把方案变更收回 Planner 环节。
Reviewer 的越界风险则比较隐蔽——把个人偏好当客观标准，用方案里没规定、自己主观喜欢的风格去打回，让 Coder 无所适从。对治关键是要求审查只对照事先确认的需求与方案判据，而不是审查者临时的口味。三个角色守住各自边界，分工才不会在协作中重新混乱。
七点十、这套重型流程的隐性收益
除了显而易见的质量把关，Planner-Coder-Reviewer 还带来一些容易被忽视的隐性收益，理解它们，你会更清楚为什么重要任务值得走这套流程。
其一是过程天然留下文档。方案、实现说明、审查清单这些交接物，本身就是一份清晰的决策与变更记录：为什么这样做、考虑了哪些边界、发现过什么问题，都沉淀了下来。日后回顾或新人接手，不必靠口头传说或重新读完整代码去拼凑前因后果。其二是责任与判断被显式化。每个角色都要对自己那一环给出结论和依据，模糊地带、未澄清的需求会在交接中被迫暴露，而不是被某个执行者悄悄掩盖。
其三，也是对个人最重要的：它把你从繁琐的逐行审查里适度解放出来，让你专注在真正需要人判断的节点——确认方向、裁决争议、最终签收。重型流程的成本是更多 Agent 协作，回报则是更可靠的产出、更清晰的记录和更聚焦的人力。对那些错了代价大的任务，这笔交易通常相当划算；而对简单任务，这些收益用不上，也就没必要付出相应成本。
七点十一、三角色一定要三个不同模型吗
一个常见的配置疑问是：既然分了三个角色，是不是一定要用三个不同、或都用最强的模型？这里专门澄清，帮你避免不必要的花费和过度设计。
答案是不必。角色的区分首先来自职责、系统提示和上下文立场，而不是模型的数量。 三个角色完全可以根据各自任务难度，灵活选用模型，甚至简单环节共用同一档便宜模型。真正决定 Planner 是否靠谱的，是它有没有被要求产出完整、可执行、带验收标准的方案；决定 Reviewer 是否有效的，是它有没有独立立场和客观判据——这些靠的是配置设计，而不是堆不同模型。
从成本角度，更聪明的做法是按角色实际的推理负担分配：规划和审查通常需要较强理解，可用较强模型；而某些模式化的实现环节，便宜模型往往足够。如果整个任务都很关键，让三角色都用强模型也无可厚非，但那是基于「难度确实需要」，而不是「分了角色就必须如此」。把「角色独立」和「模型分级」这两件事分开看待，你就能既保住多角色互相制约的可靠性，又不被「每角色配一模型」的想象绑架，在质量和成本间取得最合理的平衡。
总结
把规划、实现、审查分给三个独立 Agent，让方案先确认、代码被没参与写的审查者把关、不合格打回——这是用 Agent 之间的独立视角互相制约，专为重要且错不起的任务设计的更可靠、也更重的编排模式。