角色专业化

11 minIntermediate

2026 年最常见的多 Agent 分解：一个 Agent 规划，一个执行，一个批评或验证。MetaGPT (arXiv:2308.00352) 将此形式化为编码到角色提示中的 SOP——产品经理、架构师、项目经理、工程师、QA 工程师——遵循 Code = SOP(Team)。ChatDev...

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

2026 年最常见的多 Agent 分解：一个 Agent 规划，一个执行，一个批评或验证。MetaGPT (arXiv:2308.00352) 将此形式化为编码到角色提示中的 SOP——产品经理、架构师、项目经理、工程师、QA 工程师——遵循 Code = SOP(Team)。ChatDev (arXiv:2307.07924) 通过”聊天链”链接设计师、程序员、审查员、测试员，带有”交流去幻觉”（Agent 显式请求缺失细节）。验证者是承重的：Cemri 等人 (MAST, arXiv:2503.13657) 显示每个多 Agent 失败都可以追溯到缺失或损坏的验证。PwC 报告了在 CrewAI 中通过结构化验证循环获得 7 倍准确率提升 (10% → 70%)。

类型： 学习 + 构建 语言： Python (stdlib) 前置条件： Phase 16 · 04 (原语模型), Phase 16 · 05 (监督者) 时间： ~60 分钟

问题

通用多 Agent 系统产生通用输出。群聊中的三个编码者写出三种风味的相同平庸代码。你可以添加更多 Agent、更多轮次，仍然无法跨越质量门槛。

修复不是更多 Agent——而是不同的 Agent。分配不同的角色。给批评者规划者没有的工具。给验证者一个客观的测试套件。现在系统有了内部分歧和有根据的纠正，而不仅仅是并行猜测。

概念

四个规范角色

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

执行者。 一次读取一个计划步骤，产生制品。工具：实际工作工具（代码编译器、Shell、API 客户端）。输出：制品。

批评者。 针对规划者的意图读取执行者的输出。工具：制品的只读访问、静态分析。输出：接受/拒绝及原因。

验证者。 读取制品并运行确定性检查。工具：测试运行器、类型检查器、Schema 验证器。输出：通过/失败及证据。

批评者是主观的、有主见的，通常基于 LLM。验证者是客观的、确定性的，通常基于代码。它们不是同一角色。

MetaGPT 的 SOP 模式

MetaGPT (arXiv:2308.00352) 将软件工程 SOP 编码为角色提示：

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

每个角色有严格的输入/输出 Schema。角色提示说明角色是什么和必须产生什么。Code = SOP(Team) 公式——确定性 SOP 将 LLM 团队变成可预测的流水线。

ChatDev 的交流去幻觉

ChatDev 添加了一个关键动作：当执行者需要一个计划中没有的具体细节时，它在继续之前显式询问设计师。这防止了 LLM 经典的合理编造细节的失败。

实现：角色提示包含”当你需要未给出的具体信息时，在产生输出之前按名称询问相关角色。“

为什么验证者最重要

Cemri 等人 (MAST) 追踪了 1642 个多 Agent 执行失败。21.3% 是验证缺口——系统发布了没有人检查过的答案。剩余的 79% 通常可追溯到”有一个检查静默失败或从未运行”。验证是承重角色。

PwC 报告 (CrewAI 部署, 2025) 添加结构化验证循环将准确率从 10% 提升到 70%。一个角色带来 7 倍增益。

批评者 vs 验证者

批评者是审查制品质量的 LLM。主观。可以被看似合理的散文欺骗。
验证者是在制品上运行的确定性程序。客观。给出带证据的通过/失败。

两者都用。批评者捕获验证者无法表达的品质问题。验证者捕获批评者无法看到的 bug，因为它们只在运行时出现。

反模式

你系统中的每个角色都是 LLM，每个角色的输出都是”看起来不错”。经典的 MAST 失败模式。至少添加一个验证者，其通过/失败由代码决定，而不是 LLM。

框架映射

CrewAI — Agent(role, goal, backstory) 是教科书式的专业化表面。
LangGraph — 节点可以有专门的提示；边强制流水线。
AutoGen — 在 GroupChat 中具有单字名称的角色特定 ConversableAgent。
OpenAI Agents SDK — 角色专业化 Agent 之间的切换工具。

构建它

code/main.py 实现了一个构建简单 Python 函数的 4 角色流水线：

规划者 产生规格。
执行者 生成代码字符串。
批评者 (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 Figure 3)。识别交流去幻觉在哪里打破了一个否则会无限的循环。
PwC 的 7 倍准确率提升来自验证循环。假设三个添加验证者不会有帮助的任务——在这些任务中确定性检查正确性是不可能的或代价过高的。

关键术语

术语	人们怎么说	实际含义
角色专业化	”不同 Agent，不同工作”	为规划者/执行者/批评者/验证者角色调优的不同系统提示。
SOP 模式	”编码的标准操作程序”	MetaGPT 的框架：每个角色的严格 I/O Schema 将团队变成流水线。
交流去幻觉	”先问再编”	ChatDev 模式：执行者在细节缺失时询问规划者，而不是编造。
批评者	”LLM 审查者”	主观、有主见的审查者。捕获品质问题。可被看似合理的散文欺骗。
验证者	”确定性检查”	基于代码的通过/失败。测试运行器、类型检查器、Schema 验证器。不可欺骗。
验证缺口	”没人检查”	21.3% 的 MAST 失败。答案发布时没有能捕获 bug 的检查。
修订循环	”批评者打回”	批评者拒绝触发带反馈的执行者重新运行。需要预算。
全 LLM 反模式	”看起来不错”	每个角色都是 LLM，没有确定性检查。经典 MAST 失败。