角色专精 —— 规划者、批评者、执行者、验证者

2026 年最常见的多 Agent 分解方式：一个 Agent 规划，一个执行，一个批评或验证。MetaGPT（arXiv:2308.00352）把这一模式形式化为编码进角色 prompt 的 SOP——产品经理、架构师、项目经理、工程师、QA 工程师——遵循 Code = SOP(Team)。ChatDev（arXiv:2307.07924）通过「聊天链」（chat chain）把设计师、程序员、审查者、测试者串联起来，并引入「交流式去幻觉」（communicative dehallucination，Agent 会明确索要缺失的细节）。验证者是承重角色：Cemri 等人（MAST，arXiv:2503.13657）表明，每一种多 Agent 失败都能追溯到缺失或损坏的验证环节。PwC 报告称，在 CrewAI 中加入结构化验证循环后，准确率提升了 7 倍（10% → 70%）。

问题

通用的多 Agent 系统只能产出通用的结果。群聊里的三个程序员写出来的，是同一份平庸代码的三种变体。你可以增加 Agent、增加轮数，却仍然跨不过质量门槛。

解法不是更多 Agent，而是不同的Agent。分配彼此不同的角色。给批评者一些规划者没有的工具。给验证者一套客观的测试套件。这样系统内部就有带事实依据纠偏的分歧，而不只是并行的猜测。

概念

四种经典角色

规划者（Planner）。 读取目标，产出步骤列表或规格说明。工具：知识检索、文档。输出：结构化计划。

执行者（Executor）。 一次读取一个计划步骤，产出交付物。工具：真正干活的工具（代码编译器、shell、API 客户端）。输出：交付物。

批评者（Critic）。 对照规划者的意图审阅执行者的输出。工具：对交付物的只读访问、静态分析。输出：接受/拒绝，并给出理由。

验证者（Verifier）。 读取交付物并运行确定性检查。工具：测试运行器、类型检查器、schema 校验器。输出：通过/失败，并附证据。

批评者是主观的、带立场的，通常由 LLM 担任。验证者是客观的、确定性的，通常由代码担任。二者不是同一个角色。

MetaGPT 的 SOP 模式

MetaGPT（arXiv:2308.00352）把软件工程 SOP 编码成角色 prompt：

产品经理编写 PRD。
架构师产出系统设计。
项目经理拆分任务。
工程师负责实现。
QA 工程师运行测试。

每个角色都有严格的输入/输出 schema。角色 prompt 说明这个角色是什么、必须产出什么。Code = SOP(Team) 这一表述的含义是：确定性的 SOP 把一组 LLM 变成一条可预测的 pipeline。

ChatDev 的交流式去幻觉

ChatDev 增加了一个关键动作：当执行者需要某个计划中没有的具体细节时，它会先明确询问设计师，然后再继续。这避免了 LLM 的典型失败——看似合理地把细节编造出来。

实现方式：角色 prompt 中包含「当你需要未被提供的具体信息时，在产出结果之前点名向相关角色提问」。

为什么验证者最重要

Cemri 等人（MAST）追踪了 1642 次多 Agent 执行失败。其中 21.3% 是验证缺口——系统交付了一个没人检查过的答案。其余 79% 也常常可追溯到「有一项检查静默失败了，或者根本没运行」。验证是承重的角色。

PwC 报告称（2025 年的 CrewAI 部署），加入结构化验证循环后，准确率从 10% 提升到 70%。一个角色带来 7 倍收益。

批评者 vs 验证者

批评者是 LLM 在审阅交付物的质量。主观，会被看似合理的文字骗过。
验证者是对交付物运行的确定性程序。客观，给出带证据的通过/失败结论。

两者都要用。批评者能抓住验证者无法表述的品味问题。验证者能抓住批评者看不到的 bug，因为它们只在运行时才暴露。

反模式

系统中每个角色都是 LLM，而每个角色的输出都是「我看没问题」。这是典型的 MAST 失效模式。至少加入一个验证者，其通过/失败由代码而非 LLM 决定。

框架对应关系

CrewAI —— Agent(role, goal, backstory) 是教科书式的角色专精接口。
LangGraph —— 节点可以带专门的 prompt；边负责强制执行 pipeline。
AutoGen —— 角色化的 ConversableAgent，在 GroupChat 中用单词命名。
OpenAI Agents SDK —— 角色专精的 Agent 之间通过 handoff 工具转交。

swarm-roles静态版本未包含此交互图

构建它

code/main.py 实现一个 4 角色的 pipeline，用于构建一个简单的 Python 函数：

规划者 产出规格说明。
执行者 生成代码字符串。
批评者（由 LLM 模拟）标出明显问题。
验证者 在沙箱（exec）中让生成的代码跑一个测试用例。

演示运行两次：一次执行者产出正确代码（批评者与验证者都通过），一次执行者产出偏离规格的代码（批评者因为代码看起来合理而漏掉 bug，验证者则因为测试失败抓住了它）。

运行：

python3 code/main.py

使用它

outputs/skill-role-designer.md 接收一个任务，产出角色名册（3-5 个角色）、每个角色的输入/输出 schema，以及验证者要执行的检查。在把 Agent 接进框架之前先用它。

交付它

检查清单：

至少一个确定性验证者。 绝不能全是 LLM。
每个角色都有显式的 I/O schema。 规划者返回规格说明而非散文；执行者读取该 schema。
交流式去幻觉。 信息缺失时执行者必须询问规划者，绝不凭空编造。
批评者/验证者的顺序。 先跑批评者（便宜，能抓设计问题），再跑验证者（慢，能抓 bug）。
循环预算。 批评者与执行者之间最多 2 轮修订，之后升级给人类。

练习

运行 code/main.py，观察验证者如何抓住批评者漏掉的 bug。增加一个静态分析检查（统计 return 出现的次数）作为额外的验证者。它能抓到哪些运行时测试漏掉的问题？
增加第 5 个角色：「需求分析师」，把用户愿望翻译成规划者可直接使用的规格说明。哪些交流式去幻觉请求应当向上流到它这里？
阅读 MetaGPT 第 3 节（"Agents"）。列出 MetaGPT 这 5 个角色各自的输入/输出 schema。
阅读 ChatDev 的聊天链示意图（arXiv:2307.07924 图 3）。找出交流式去幻觉在哪里打断了一个否则会无限的循环。
PwC 的 7 倍准确率提升来自验证循环。假设三类加入验证者也无济于事的任务——即正确性的确定性检查不可能做到，或成本高得不可承受。

关键术语

术语	常见说法	实际含义
角色专精（Role specialization）	「不同 Agent，不同工作」	针对规划者/执行者/批评者/验证者分别调校的 system prompt。
SOP 模式	「把标准作业流程编码进去」	MetaGPT 的框架：每个角色严格的 I/O schema 把团队变成 pipeline。
交流式去幻觉（Communicative dehallucination）	「先问，别编」	ChatDev 的模式：细节缺失时执行者询问规划者，而不是自己编一个。
批评者（Critic）	「LLM 审阅人」	主观、带立场的审阅者。能抓品味问题，也会被看似合理的文字骗过。
验证者（Verifier）	「确定性检查」	基于代码的通过/失败判定。测试运行器、类型检查器、schema 校验器。骗不过它。
验证缺口（Verification gap）	「没人检查」	占 MAST 失败案例的 21.3%。答案交付时，本可抓住 bug 的检查没有做。
修订循环（Revision loop）	「批评者打回重做」	批评者拒绝后触发执行者带着反馈重跑。需要有预算。
全 LLM 反模式（All-LLM anti-pattern）	「我看挺好」	每个角色都是 LLM，没有确定性检查。典型的 MAST 失败。

示意图共 1 张

问题

概念