把一个多智能体系统拆成规划者、执行者、评审者，听起来很完整，但完整不等于划算。很多团队一上来就做三层角色，结果最先暴涨的不是质量，而是等待时间、往返沟通和调试成本。
真正值得三层拆分的前提，是任务里本来就存在三种不同的工作：前置规划、局部执行和独立复核。只有当这三步各自有清晰责任、清晰输入输出和可重复的判断标准时，planner-worker-reviewer 才会把复杂度换成稳定性，而不是把系统变成一连串冗长交接。
为什么这个问题重要
真实运行代价
三层拆分的代价非常真实。每增加一个角色，就多一层上下文包装、多一轮回传契约和一次状态同步。如果任务本来只需要清晰的控制器加少量执行者，硬拆出规划者和评审者，只会让系统把大量 token 花在角色之间互相解释，而不是花在完成目标上。
- 规划者会引入额外的任务图与验收标准维护成本。
- 评审者会增加一轮独立判断与结果回写。
- 控制器必须额外处理计划修订、评审退回和重复执行。
如果不处理会怎样
如果团队没有先判断三层拆分是否值得，常见结果是 planner 产出抽象计划，worker 只能不断追问细节，reviewer 又把结果退回去重做，系统陷入高频往返。表面上看架构很“正规”，实际上吞吐下降、失败解释更难，人工接管时还要先理解三层角色到底各自做了什么。
适用场景
谁最需要这套方法
当任务本身需要先制定执行策略，再分发给不同执行单元，最后由独立标准做质量判断时，三层拆分才会开始显出价值。比如研究与取证型工作流、需要多轮验证的内容生产流程，或执行代价较高、返工成本明确的自动化链路。
- 规划步骤可以独立定义成功条件与资源分配。
- 执行步骤可以被拆成多个窄职责子任务。
- 质量判断拥有独立于执行者的验收标准。
什么时候先不要这么做
如果任务流程短、工具顺序固定、质量标准也能由控制器直接判断，就不要为了“更像多智能体”而硬上 reviewer。对许多刚起步的团队来说，先把 controller-worker 跑稳，比一开始就设计 planner-worker-reviewer 更能减少返工。
推荐系统结构
核心角色与状态
值得拆成三层时，三种角色必须承担不同责任。规划者输出的是结构化任务图、约束条件和验收标准；执行者只消费其中一个子任务并返回结果；评审者只基于既定标准判断结果是否可接受、是否需要补充证据或触发回退。控制器负责把这三层串起来，持有全局状态和最终停止条件。
- Planner 负责拆解、排序、设定验收标准，不直接吞掉执行细节。
- Worker 负责完成局部任务，按契约回传证据、结论和置信度。
- Reviewer 负责复核结果是否满足标准，而不是重新接管整个流程。
与 TaskPilots 的映射
在 TaskPilots 的多 Agent 协作编排集群里，这种结构适合放在已有控制面之上，而不是绕开控制器单独搭一套社会化对话。控制面可以把 planner 的产物沉淀成显式状态，把 worker 的回传标准化，再让 reviewer 只处理质量判断和退回理由。这样后续无论是增加人工审批，还是把 reviewer 结果接到运营追踪层，都不会失去主链路可见性。
风险与失效点
常见失控方式
最常见的失败，不是角色不够多，而是角色边界不够窄。planner 容易写出泛泛而谈的大纲，worker 容易把缺失信息补成自己的新计划，reviewer 则容易从“质量检查”滑向“重新设计整个流程”。一旦三层都开始做对方的事，系统就会快速进入高成本低产出的回环。
- Planner 输出抽象计划，worker 无法直接执行。
- Reviewer 没有明确检查表，退回理由变成主观评价。
- 退回与重试没有次数和停止条件，流程无限拉长。
需要人工兜底的地方
当 reviewer 连续两轮退回同一类问题，或者规划者需要在成本、风险、外部副作用之间做权衡时，最好由人工接管，而不是继续让角色彼此拉扯。人工兜底点应挂在控制器层，这样能同时看到计划版本、执行结果和评审依据。
验证指标
上线前怎么验证
上线前要验证的不是“三层都能说话”，而是三层拆分是否真的降低了返工和质量波动。准备一组代表性任务，对比 controller-worker 和 planner-worker-reviewer 两种结构的完成时间、返工次数和错误类型，才能判断这层复杂度是否值得保留。
- 观察 planner 产出的任务图是否稳定且可执行。
- 观察 worker 的首次通过率与补充执行比例。
- 观察 reviewer 的退回理由是否集中且可操作。
上线后怎么持续判断
生产阶段建议长期追踪计划接受率、worker 返工率、reviewer 分歧率、总循环时长和单任务成本。如果新增 reviewer 后质量没有提升，反而只是增加一轮退回，那就说明这个任务还不到需要三层拆分的程度。
下一步 / FAQ
下一步建议
如果你正在评估三层架构，先挑一类高价值、可重复、质量标准清晰的任务试跑，而不是把所有复杂任务都一起迁进去。先验证 planner 的任务图质量和 reviewer 的检查表是否稳定，再决定是否把更多流程迁到这一模式。
FAQ
是不是只要任务复杂就应该拆成三层？ 不是。只有规划、执行、复核本来就是不同工作，三层拆分才有意义。
reviewer 和控制器有什么区别？ reviewer 只负责按标准复核结果，控制器负责全局状态、路由、停止条件和人工升级。
planner 会不会拖慢系统？ 会，所以必须用任务接受率、返工率和总循环时长来验证它是否真的创造了价值。