Planner、Worker、Reviewer怎么分工

上一篇《Plan-and-Execute怎么落地成DAG执行器》讲了怎么把文本计划变成可调度、可恢复的执行图。

但任务图能跑，不代表协作就可靠。

当一个Agent既拆任务、又执行、还负责宣布自己完成时，计划错误、执行错误和验收错误会混在一个上下文里，系统很难发现自己错在哪里。

这也是Multi-Agent真正要解决的问题：不是多开几个模型，而是把不同决策权拆开。

面试官会怎么问

“你们的Multi-Agent为什么要分Planner、Worker、Reviewer？三个角色怎么传递任务，怎么防止Worker越权，Reviewer发现问题后又怎么退回？”

很多录友会回答：

“Planner负责规划，Worker负责执行，Reviewer负责检查。”

这句话方向没错，但还停在角色名字上。

第一，没有定义交接物。 Planner说“调研一下故障”，Worker不知道查多深、交什么、什么算完成，只能继续猜。

第二，没有拆开权限。 三个角色如果共享全部工具，Worker仍然可以改计划，Reviewer也可能一边修改产物、一边给自己判通过。

第三，没有失败退回路径。 Reviewer只说“不够好”，却不指出哪条验收标准没过，任务就会在多个Agent之间反复踢皮球。

面试官真正想听的是：每个角色拥有什么决策权，交接的数据结构是什么，谁能调用哪些工具，以及不通过时退回给谁。

简要回答

• Planner负责定义问题。 它把用户目标拆成任务包，写清依赖、输入、约束、允许使用的工具和验收标准，但不执行高风险动作，也不能给自己的计划判完成。
• Worker负责在边界内执行。 它只接收当前任务需要的上下文和最小工具集，交付Artifact、证据、假设与未解决项，不能私自扩大目标或修改验收标准。
• Reviewer负责根据证据验收。 它不重新做一遍任务，而是逐条检查验收标准，输出PASS、REVISE或BLOCKED，并指出失败证据和退回对象。
• 编排器负责执行硬约束。 任务路由、状态流转、权限校验、最大返工次数和审计必须由代码控制，不能只写在Prompt里。
• 交接靠结构化任务包和Artifact引用。 不靠一句“你接着做”，也不把所有聊天记录复制给下一个Agent。

多Agent的价值不是让三个模型轮流说话，而是让计划、执行、验收互相制约，每一步都能追责和退回。

这张图回答的是：用户目标如何经过Planner的任务包、Worker的产物与证据、Reviewer的验收门禁变成可信结果，以及执行问题为什么必须带着具体原因退回Worker。

为什么不能让一个Agent从头包到尾

先看一个故障分析任务：

“分析昨天支付接口延迟升高的原因，并给出上线前可执行的改进建议。”

如果一个Agent从头做到尾，它会同时做四件事：

1. 理解目标；
2. 决定查什么；
3. 调工具收集证据；
4. 判断自己的结论是否可信。

问题在于，同一个错误会跨阶段传播。

它一开始误判是数据库问题，后面就会优先查数据库；查到一条无关慢查询，又会把它当成支持证据；最后验收时，它仍然沿着自己的原始假设检查，很难主动推翻整条链路。

拆成三个角色，不是为了把调用次数变多，而是为了拆开三类决策：

角色	核心决策	必须交付	明确不能做
Planner	做什么、先后依赖、什么算完成	结构化任务包	直接执行生产写操作、宣布任务通过
Worker	在给定边界内怎么完成	Artifact、证据、假设、未解决项	私自扩大目标、修改验收标准、自我验收
Reviewer	证据是否满足验收标准	结构化判定与失败原因	无标准打分、悄悄替Worker改产物再放行

这三个角色拆开的不是“工作量”，而是定义权、执行权和放行权。

如果三种权力仍然集中在一个Agent里，换成三个名字也没有意义。

Planner不是写一份漂亮计划，而是生成任务契约

Planner最重要的产出不是自然语言步骤，而是能被系统校验的任务包。

一个最小任务包至少要包含：

{
  "task_id": "incident-20260903-01",
  "goal": "定位支付接口P99延迟升高的主要原因",
  "inputs": ["metrics://payment/2026-09-02"],
  "dependencies": [],
  "allowed_tools": ["query_metrics", "search_logs", "read_release_records"],
  "constraints": {
    "time_range": "2026-09-02T20:00:00+08:00/2026-09-02T24:00:00+08:00",
    "environment": "production-readonly"
  },
  "acceptance_criteria": [
    "结论至少由两类独立证据支持",
    "区分事实、推断和未验证假设",
    "每条建议标明影响范围和回滚条件"
  ],
  "expected_outputs": ["incident_report.md", "evidence_index.json"]
}

这里有三个容易被忽略的点。

目标必须能验收

“分析一下为什么变慢”太宽。

Worker不知道是找相关性、根因，还是列出所有可能性；Reviewer也不知道什么叫分析完成。

改成“定位P99延迟升高的主要原因，并要求至少两类独立证据支持”，任务才有收口条件。

工具权限要跟任务一起下发

Planner不能只说“去查数据”，然后让Worker看见系统全部工具。

这次任务只需要读监控、日志和发布记录，就不应该把改配置、重启服务、发送通知等写工具一起暴露。

allowed_tools不是给Worker看的建议，而是编排器实际执行的白名单。

验收标准要在执行前确定

如果Reviewer看完结果才临时决定标准，Worker会陷入无休止返工。

标准也不能只写“内容完整”“结论可靠”。它必须能对应具体证据，例如：

• 时间范围覆盖故障前后各30分钟；
• 结论至少由监控和日志两类证据交叉支持；
• 不确定项必须显式标注；
• 改进建议必须包含风险和回滚条件。

Planner真正做的是把模糊目标压成一份可执行、可限制、可验收的契约。

Worker只执行当前任务，不负责重新定义任务

Worker拿到任务包后，职责是完成它，不是重新规划整个项目。

这意味着Worker的输入应该尽量小：

• 当前任务的目标和验收标准；
• 已完成依赖的Artifact引用；
• 完成本任务必须知道的背景；
• 本任务允许调用的工具；
• 截止时间、成本和权限边界。

不要把根Agent的全部聊天记录、其他Worker的完整轨迹、所有工具说明一起塞进去。

上下文越大，Worker越容易把别人的假设当成自己的事实，也更容易做出任务范围之外的动作。

Worker交付的不是一句“完成了”

Worker的返回值至少要有五部分：

{
  "task_id": "incident-20260903-01",
  "status": "completed",
  "artifact_refs": ["artifact://incident_report/v3"],
  "evidence_refs": ["trace://metrics-1842", "trace://logs-9921"],
  "assumptions": ["第三方支付回调日志时间已统一为UTC+8"],
  "unresolved": ["22:14到22:16的网关日志缺失"]
}

Artifact是可复用的工作产物，例如报告、代码补丁、测试结果或数据表。

证据则回答“你凭什么得出这个结果”，例如查询快照、Trace ID、测试日志和版本号。

Artifact和证据要分开。 报告写得像真的，不代表证据真的支持它。

Worker发现任务包有问题怎么办

Worker不能默默扩大目标，也不应该为了“完成率”硬做。

例如任务要求读取一个没有权限的数据源，正确行为是返回：

{
  "status": "blocked",
  "reason_code": "MISSING_DATA_PERMISSION",
  "missing": "gateway_log_read",
  "partial_artifacts": ["artifact://metrics_analysis/v1"],
  "recommended_action": "request_permission_or_replan"
}

编排器再决定申请权限、退回Planner重拆，还是基于已有结果部分交付。

让Worker自己绕过权限去找替代数据，看似主动，实际上已经改变了任务的证据标准。

Reviewer不是再做一遍，而是守住验收门禁

Reviewer最常见的误用，是拿到Worker结果后说：

“整体不错，再补充一些细节。”

这种评价无法执行。

Worker不知道补什么，系统也不知道什么时候可以停止。

Reviewer应该拿着任务包里的acceptance_criteria，逐条检查Artifact和证据。

判断结果只保留三种：

• PASS：全部硬性标准通过，可以交付；
• REVISE：有明确可修复的问题，退回指定角色；
• BLOCKED：缺权限、缺数据或标准冲突，当前角色无法修复，需要升级。

一个可执行的Reviewer返回值可以是：

{
  "verdict": "REVISE",
  "failed_criteria": [
    {
      "criterion": "结论至少由两类独立证据支持",
      "finding": "数据库连接池结论只有一条监控曲线，没有日志或Trace佐证",
      "evidence_ref": "artifact://incident_report/v3#root-cause"
    }
  ],
  "return_to": "worker-metrics",
  "required_changes": ["补充Trace证据，或把结论降级为待验证假设"]
}

这次退回就不是“我觉得不够好”，而是“第1条标准未通过，缺哪份证据，应该怎么修”。

先过硬规则，再做语义审查

Reviewer也不应该什么都交给大模型判断。

先用确定性规则检查：

• 交付文件是否存在；
• JSON Schema是否有效；
• 测试是否通过；
• 必填证据是否齐全；
• 是否调用了越权工具；
• 产物版本是否与任务包一致。

硬规则通过后，再让Reviewer判断论证是否完整、建议是否可执行、事实和假设是否混淆。

能用代码判断的，不要浪费一次模型主观判断。

Reviewer最好没有生产写权限

Reviewer发现代码有问题，可以生成修改建议或补丁草稿，但不应该一边修改生产状态，一边给自己的修改判通过。

否则执行权和放行权又合并了。

高风险场景下，最终发布、付款、删数据、改权限仍然要进入确定性规则或人工确认，Reviewer不能替代审批人。

最小工具权限必须由系统执行

只在System Prompt里写“你不能调用部署工具”，不叫权限控制。

模型仍然可能输出对应的工具调用，应用代码如果照常执行，边界就不存在。

正确做法是按角色、任务和阶段共同裁剪工具集：

工具能力	Planner	Worker	Reviewer
读取任务元数据	允许	允许当前任务	允许当前任务
查询业务数据	必要时只读	按任务白名单	只读证据
修改Artifact草稿	不允许	允许自己的命名空间	默认不允许
修改生产状态	不允许	默认不允许，单独授权	不允许
运行测试或校验器	可定义要求	允许	允许
修改验收标准	创建任务时允许	不允许	不允许
宣布最终通过	不允许	不允许	满足门禁后允许

这里的“允许”也不是永久权限。

最好同时带上task_id、资源范围、有效期和最大调用次数。任务结束后立刻失效。

例如Worker可以写artifact://incident-20260903/*，但不能写其他任务目录；可以查询9月2日晚上的日志，但不能把时间范围扩大到整个月。

这和《工具设计决定Agent上限》里的读写分离是同一条原则，只是从“一个工具能做什么”进一步收紧到“当前角色在当前任务里能做什么”。

编排器是控制面，不是第四个自由决策Agent

三个角色之间还需要一个编排器。

它负责：

• 保存任务状态；
• 下发任务包；
• 根据角色裁剪工具；
• 校验输入输出Schema；
• 路由PASS、REVISE和BLOCKED；
• 限制返工次数、并发和超时；
• 记录完整审计链。

这些事情应该由确定性代码完成。

如果再放一个“Manager Agent”自由决定所有路由和权限，系统只是把单Agent的风险向上挪了一层。

可以让模型建议“退回Worker还是重新规划”，但最终状态转换必须符合代码里的状态机：

PLANNED -> RUNNING -> REVIEWING -> PASSED
              |           |
              |           +-> REVISING -> RUNNING
              +-> BLOCKED ----------------> ESCALATED

任何角色都不能直接从RUNNING跳到PASSED，也不能绕过REVIEWING。

这类硬约束，才是Multi-Agent从Demo走向生产的分界线。

不通过时到底退回给谁

失败退回不能一律扔给Worker。

先判断问题属于哪一层：

问题	退回对象	处理方式
证据不足、格式错误、测试失败	Worker	按失败标准补证据或修产物
目标拆错、依赖缺失、验收标准冲突	Planner	修改受影响任务包，不推翻已通过产物
权限缺失、关键数据不存在	编排器或人工	授权、降级交付或终止任务
Reviewer意见前后矛盾	人工或第二门禁	固化标准，避免无限主观返工

返工必须有上限，比如同一条标准最多退回两次。

超过上限后，不应该偷偷降低标准，也不能继续烧Token，而是升级给人工，并保留当前Artifact、证据和每次退回原因。

这和《Agent为什么容易翻车》里讲的停止条件一样：失败不可怕，没有明确退出路径才危险。

Multi-Agent什么时候反而不值得用

角色拆分不是越多越好。

下面几类任务，用一个Agent或固定Workflow通常更合适：

任务很短，而且结果能被代码直接验证

例如把CSV字段转换成固定JSON，Schema校验通过就结束。

再加Planner和Reviewer只会增加延迟、成本和故障点。

三个角色拥有完全相同的上下文和工具

如果只是给同一个模型换三段Prompt，却不拆权限、不换交接物、不增加独立证据，错误仍然高度相关。

三个Agent可能一起相信同一个错误假设。

验收标准根本说不清

“写得更有感染力”“方案更高级”这类纯主观目标，可以让多个模型给建议，但很难形成稳定门禁。

先让人确定判断维度，比盲目增加Reviewer更重要。

协作成本超过任务本身

任务包解析、Artifact存储、Review和返工都要时间。

如果单Agent10秒能稳定完成，三角色跑一分钟，完成率只提高一点点，这个架构就不划算。

是否上Multi-Agent，要用可靠性收益覆盖新增的延迟、成本和复杂度。

怎么验证角色拆分真的有效

不要只看最终任务完成率。

至少对比单Agent基线和Multi-Agent方案的六组指标：

• 首次验收通过率：第一次Review就通过的比例；
• 平均返工次数：每个任务被退回多少轮；
• 交接失败率：任务包缺字段、Artifact引用失效、状态错乱的比例；
• 越权调用率：角色请求了白名单外工具的比例；
• Reviewer误放行率：实际不合格却被判PASS的比例；
• 单个成功任务的Token、延迟和工具调用成本。

如果完成率提高了，但Reviewer误放行率没降，说明只是多了一层表面检查。

如果质量提高一点，成本却翻了几倍，就要缩小Reviewer范围，只审高风险节点，而不是每一步都审。

真实项目里常用分级策略：低风险任务由规则自动验收；中风险任务增加模型Reviewer；高风险动作再叠加人工确认。

面试时怎么讲

可以这样回答：

我们把多Agent拆成定义权、执行权和放行权三层。Planner生成结构化任务包，包含目标、依赖、允许工具、约束和验收标准；Worker只拿当前任务需要的上下文和最小工具集，交付Artifact、证据、假设及未解决项；Reviewer不重做任务，而是逐条对照验收标准，输出PASS、REVISE或BLOCKED。

角色之间由确定性编排器控制状态和权限，不靠Prompt自觉。执行问题退回Worker，任务拆分或验收标准问题退回Planner，缺权限和关键数据则升级人工。返工有次数上限，所有结果都带证据引用和审计记录。

最后我们会拿单Agent做基线，对比完成率、误放行率、越权率、返工次数、延迟和单个成功任务成本，确认多Agent带来的可靠性收益是否值得。

这套回答比“Planner规划、Worker执行、Reviewer检查”多出的，正是生产系统需要的契约、权限、门禁和失败路径。

知识拓展

Planner能不能同时当Worker？

低风险、短任务可以合并，否则没必要强行三角色。

但一旦任务涉及生产写操作、长链路或高成本，就应该把定义权和执行权拆开。至少不能让同一个角色改验收标准后立刻给自己判通过。

Reviewer必须换一个更强的模型吗？

不一定。

结构、权限、测试这类硬标准优先用代码检查；语义审查再根据风险选模型。换更强模型可能降低误判，也会增加延迟和成本，必须用误放行率和成功任务成本验证。

Reviewer要不要看Worker的完整思考过程？

通常不需要，也不应该把内部推理当成证据。

Reviewer需要的是任务包、最终Artifact、可核验的证据、关键决策说明和未解决项。这样上下文更小，也能减少Reviewer被Worker原始叙述带偏。

多个Reviewer投票是不是更可靠？

只有评审标准相对独立时才可能更可靠。

三个Reviewer用同一个模型、同一份Prompt和同一批证据，很可能犯同一种错。高风险场景更有效的做法，是让规则校验、模型语义审查和人工审批分别守不同门禁。

Worker要不要允许创建子Agent？

默认不允许。

Worker如果发现任务需要继续拆分，应返回Planner重新生成任务包。否则每个Worker都能继续派生角色，权限、成本和任务树很快失控。

写在最后

Multi-Agent最容易做成“三个聊天框互相转发”。

真正可靠的分工，要让Planner交付契约，让Worker交付证据，让Reviewer守住门禁，再由代码控制权限和退回路径。

角色名字不重要，决策权能不能拆开才重要。