Agent 的角色分工：规划者、执行者、评审者——各干什么

有一次我让一个所谓的“全能 Agent”帮我写一个数据分析脚本，要求很简单：读取 Excel，清洗数据，画几张图。结果它上来就写代码，写完发现忘了装依赖库，装完依赖库又发现数据格式不对，最后画出来的图坐标轴全是乱码。整个过程来回折腾了七八轮，每次失败它都重新从零开始写。我当时就想——如果它是一个人，早就被开除了。但问题不在它，而在于它没有分工。它既要做规划，又要动手干活，还要自己检查错误，就像一个边写菜谱边炒菜还边尝咸淡的厨师，所有环节都在脑子里搅成一团。

后来我接触了多 Agent 系统，特别是那些把任务拆成“规划者、执行者、评审者”三个角色的框架，才真正理解到：Agent 的能力边界，不是模型大小决定的，而是有没有把“想清楚”和“做出来”以及“检查好”这三件事分开。 这篇文章，我想跟你聊聊这三个角色到底在干什么，它们怎么配合，以及为什么这种分工能把任务成功率翻倍。

单 Agent 困境：为什么一个脑子不够用

先看一个典型场景：你让 AutoGPT 写一篇市场分析报告。它的流程大概是：生成一个计划（比如查资料→整理数据→写报告），然后执行第一步，接着第二步……但问题在于，它执行第二步时可能忘了第一步已经用过什么关键词，或者突然发现第三步需要的某个图像根本不存在，于是整个流程卡死。更糟的是，它自己很难判断“这个结果到底行不行”——它只能继续往下走，直到彻底失败才回头。

这背后的根本原因是单个 Agent 的上下文窗口里塞满了太多信息：任务目标、历史动作、中间结果、观察到的反馈……当模型需要同时扮演“想计划的人”和“干活的人”和“检查的人”时，注意力被稀释，每一步都容易出错。而且，一旦出错，它很难自我纠错，因为纠错需要跳出当前视角，用第三方视角审视自己的输出——这正是单个 Agent 天然缺乏的。

MetaGPT 的论文里有一句话点得很透：“在软件开发中，单程序员编写代码时，往往难以发现自己的错误，而代码审查和测试人员的存在能显著提升质量。” 这个观察挪到 AI Agent 上同样成立。

规划者：把模糊需求变成可执行蓝图

规划者的角色用一句话概括就是：接到一个模糊的大任务，输出一份可执行的分步骤计划，而且每一步都明确依赖关系和预期产出。它不动手干活，只负责“想”。

比如你要求“帮我分析近三年新能源汽车销量趋势”，规划者会拆成：

1. 搜索新能源汽车销量数据来源（需要确定关键词和年份范围）
2. 爬取或调用 API 获取数据
3. 清洗数据，处理缺失值
4. 用 Python 画趋势图并输出
5. 撰写简要分析报告

而且它还会明确：第 2 步依赖第 1 步确定的链接，第 3 步依赖第 2 步的原始数据，等等。这种结构化的计划，让执行者不需要再自己判断“下一步该做什么”，决策疲劳大幅降低。

我最早以为规划者就是一个高级的 prompt，后来发现真正好的规划者需要具备“领域知识库”。比如 MetaGPT 里的产品经理角色，会参考软件需求文档（SRS）标准来制定计划，而不是凭空乱拆。这意味着规划者背后往往挂着 RAG 或预置的 pattern 库，它知道“一个数据分析任务的标准 SOP 是什么”，而不是每次都重新发明轮子。

这里有一个关键设计：计划不能太死板。所以很多框架允许规划者收到执行者或评审者的反馈后，动态修订计划。比如执行者发现数据源 A 不可用，评审者会触发重新规划，规划者就调整到数据源 B。这种“计划-执行-检查-调整”的循环，正是多 Agent 协作的灵魂。

执行者：只管把动作做对，不背决策的锅

执行者拿到规划者输出的具体步骤，要做的就是调用工具、写代码、操作浏览器等等。它的核心能力是工具使用和准确执行。它不需要关心“这个任务整体对不对”，只需要关心“我这一步有没有做对”。

这种职责分离有一个巨大的好处：执行者可以专注于和工具交互的细节，比如函数签名的参数格式、API 限制、错误重试逻辑。如果让规划者同时做这些，很容易顾此失彼。而且执行者如果失败，可以明确地向上汇报“这一步失败了，原因是 XX”，而不是让整个系统陷入混乱。

在 CrewAI 这类框架里，执行者通常被封装为拥有特定工具集的 Agent，比如“代码执行 Agent”可以运行 Python 代码、“搜索 Agent”能调用 SerpAPI。它们的 prompt 很简单：“给你一个任务，用你的工具完成它，并返回结果”。这种单任务的专注，让模型在工具调用上的准确率明显提升。

我踩过一个坑：早期我做 Agent 时，让同一个 Agent 先规划再执行，结果它经常在规划时就把工具调用写进去了，导致执行时发现工具输入格式不对。后来把规划者和执行者分开，规划者只输出伪代码或者自然语言步骤，执行者再自己适配成工具调用，错误率直接降了一半。

评审者：让 Agent 学会“回头看”

评审者是最容易被忽视的角色，但在我看来，它是整个系统里最关键的拼图。它的职责是：检验执行者的输出是否满足预期，如果不满足，给出具体反馈，让规划者调整计划，或者让执行者重试。

评审者可以检查很多维度：

• 事实性：搜索结果是否相关、数据是否最新
• 完整性：代码是否包含了所有必要步骤
• 格式正确性：输出 JSON 格式是否合法、文件是否能正常打开
• 安全性：代码是否执行了危险操作

而且评审者不是简单地输出“通过”或“不通过”，它要给出可操作的反馈。比如“数据清洗遗漏了缺失值填充，请补充”，或者“图表标题是乱码，指定中文字体后再试”。这种反馈就像是一个有经验的程序员 code review 时的评论，而不是编译器报错。

MetaGPT 的架构里，评审者角色由 QA 工程师承担，它会生成测试用例并验证输出。而 Reflexion 这篇论文里提出的反思机制，本质上也是一种评审者：执行失败后，Agent 会生成一段反思，作为下次尝试的上下文，这其实是在内部模拟评审者。

我原来以为评审者就是事后检查，后来发现它也可以在执行过程中实时介入。比如执行者写完代码后，评审者立刻运行静态分析，发现语法错误就马上喊停，不等全部跑完。这种“边执行边检查”的模式，让任务中断率大幅降低。

三个角色怎么协同：一个完整的协作循环

把三个角色串起来，就是一个经典的“认知-执行-反馈”循环：

1. 用户输入任务
2. 规划者生成结构化计划，分解为子任务，并指定每个子任务的预期输出
3. 执行者获取子任务，调用工具执行，产出结果
4. 评审者检查结果，给出通过/不通过，以及具体反馈
5. 如果通过，进入下一个子任务；如果不通过，反馈给规划者（可能调整计划）或执行者（重新执行），回到步骤 2 或 3
6. 所有子任务通过后，整合最终输出给用户

这个循环在 MetaGPT 里体现为软件公司的 SOP：产品经理写 PRD（规划），架构师设计系统（细化规划），工程师写代码（执行），QA 测试（评审），最后整合交付。每个角色只关注自己的 context，减少了 token 消耗和注意力分散。

但这里有一个微妙的问题：评审者如果也是同一个模型，它会不会“放水”？ 确实存在这种风险——模型倾向于给自己生成的内容打高分。所以一些高级实现会使用不同的模型或者不同的温度参数来扮演评审者，甚至用更小但更专注的模型做检查（比如用代码 lint 工具做语法检查，而不是全靠 LLM）。

一张表说清三个角色的差异

常见误解FAQ

这三个角色一定是三个不同的 Agent 吗？

不一定。在资源受限的场景下，可以用同一个模型在不同 prompt 下切换角色。但为了性能，最好让它们有独立的上下文窗口，避免相互干扰。MetaGPT、CrewAI 等框架就为每个角色创建独立的 Agent 实例。

规划者用的是什么模型？

通常还是 GPT-4 或 Claude 等强模型，因为需要复杂推理。但有些方案会用更小的模型微调来专门做规划，比如 PlanBench 里的思路。

评审者能发现所有错误吗？

不能。它受限于模型本身的判断力，以及检查工具的完备性。所以很多系统会结合确定性检查（如代码能否运行）和模型评审，形成多重保障。

这个分工是不是只适用于软件开发？

不是。任何需要复杂多步骤的任务都可以用，比如金融报告生成、旅行规划、科研实验设计等。关键不是领域，而是任务是否有“规划-执行-验证”的结构。

不分工，直接用最长的上下文让一个 Agent 做所有事不行吗？

理论上可以，但实际效果很差。长上下文并没有解决注意力分散和缺乏自我批判的问题，模型仍然容易在同一个错误里循环。分工的本质是让每一步的上下文更干净、目标更单一。

我的判断：分工是 Agent 落地的必修课

经过大量实验，我越来越确信：单 Agent 在复杂任务上的天花板，不是模型能力不够，而是架构设计没有把“认知”和“行动”解耦。规划者-执行者-评审者的分工，不是什么新鲜概念，它其实就是把人类工作中最有效的“计划-执行-检查-改进”（PDCA）循环搬到了 Agent 系统里。

但这也意味着，如果你只是简单地把三个角色拼在一起，很可能得到的是三个互相说废话的 Agent。真正有效的分工，需要精心设计每个角色的 prompt 模板、工具集、检查规则，以及它们之间的通信协议。这就像搭一个团队，不是把人扔在一起就能干活，而是要有明确的职责边界和协作流程。

目前这套机制的挑战在于：当任务过于开放时，规划者可能无法制定合理计划；当执行环境复杂多变时，执行者可能频繁失败；当评审标准模糊时，评审者可能给出矛盾反馈。所以，它最适合的是那些过程相对标准化、但步骤繁多的任务——比如软件开发、数据分析、内容生成流水线。对于完全开放的探索性任务，单 Agent 加上人类在回路可能更灵活。

最后，如果你正在设计自己的 Agent 系统，我的建议是：先从最简单的分工开始，规划者只做最粗粒度的拆解，执行者只做单步工具调用，评审者只检查最明显的错误。然后根据失败案例，逐步细化每个角色的职责。别一上来就追求全自动，那样你只会收获一堆昂贵的 token 账单和一脸懵逼的 Agent。