AI 原生开放教材

外观

AI 工程从零到一（中文）源码研读·中文原文 ↗原件 ↓仓库 ↗

角色专精 —— Planner、Critic、Executor、Verifier ​

2026 年最常见的多 agent 拆解：一个 agent 做规划、一个执行、一个批判或验证。MetaGPT（arXiv:2308.00352）把它形式化为编码进角色 prompt 的 SOP——产品经理、架构师、项目经理、工程师、QA 工程师——遵循 Code = SOP(Team)。ChatDev（arXiv:2307.07924）用一条「聊天链」把设计师、程序员、评审、测试串起来，并带「沟通式去幻觉」（communicative dehallucination，agent 显式索取缺失的细节）。verifier 是承重的：Cemri 等人（MAST，arXiv:2503.13657）表明每一次多 agent 失败都能追溯到验证缺失或损坏。PwC 报告称 CrewAI 里结构化的校验循环带来 7 倍准确率提升（10% → 70%）。

类型： Learn + Build 语言： Python（标准库） 前置要求： Phase 16 · 04（原语模型）、Phase 16 · 05（Supervisor） 预计时间： ~60 分钟

问题背景 ​

泛用的多 agent 系统产出泛用的输出。一个群聊里的三个 coder 会写出同一份平庸代码的三种风味。你可以加更多 agent、加更多轮，照样跨不过质量门槛。

修法不是更多 agent，而是不同的 agent。分配清晰的角色。给 critic 一些 planner 没有的工具。给 verifier 一套客观的测试集。这样系统就有了带扎实纠错的内部分歧，而不只是并行瞎猜。

核心概念 ​

四个标准角色 ​

Planner（规划者）。 读目标，产出一份步骤清单或一份 spec。工具：知识检索、文档。输出：结构化计划。

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

Critic（批评者）。 对照 planner 的意图来读 executor 的输出。工具：对产物的只读访问、静态分析。输出：接受/拒绝并附理由。

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

critic 是主观的、有立场的、常基于 LLM。verifier 是客观的、确定性的、常基于代码。它们不是同一个角色。

MetaGPT 的 SOP 模式 ​

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

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

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

ChatDev 的沟通式去幻觉 ​

ChatDev 加了一个关键动作：当 executor 需要一个计划里没有的具体细节时，它会在继续之前显式去问设计师。这防住了 LLM 经典的失败——煞有介事地把细节编出来。

实现：角色 prompt 里包含「当你需要没被告知的具体信息时，在产出之前点名去问相关角色」。

为什么 verifier 最重要 ​

Cemri 等人（MAST）追踪了 1642 次多 agent 执行失败。21.3% 是验证缺口——系统交付了一个没人检查过的答案。剩下的 79% 往往也能追溯到「有一个检查悄悄失败了、或者压根没跑过」。验证是那个承重的角色。

PwC 报告（CrewAI 部署，2025）称，加上一个结构化校验循环把准确率从 10% 拉到 70%。一个角色带来 7 倍提升。

Critic 对 Verifier ​

  • critic 是一个 LLM，为质量审查产物。主观。会被像样的措辞骗到。
  • verifier 是一个跑在产物上的确定性程序。客观。给出带证据的通过/失败。

两个都用。critic 抓 verifier 说不清的品味问题。verifier 抓 critic 看不见的 bug——因为它们只在运行时才暴露。

反模式 ​

你系统里每个角色都是 LLM，每个角色的输出都是「我看着挺好」。经典的 MAST 故障模式。至少加一个 verifier，它的通过/失败由代码决定，而不是由 LLM 决定。

框架映射 ​

  • CrewAI —— Agent(role, goal, backstory) 是教科书式的专精接口。
  • LangGraph —— 节点可以有专精的 prompt；边强制流水线。
  • AutoGen —— 在 GroupChat 里用单词命名的角色专属 ConversableAgent。
  • OpenAI Agents SDK —— 角色专精 Agent 之间的 handoff 工具。
figure
swarm-roles

动手构建 ​

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

  • Planner 产出一份 spec。
  • Executor 生成一段代码字符串。
  • Critic（LLM 模拟）标出明显问题。
  • Verifier 在沙箱里（exec）针对一个测试用例运行生成的代码。

演示跑两遍：一遍 executor 产出正确代码（critic + verifier 都通过），一遍 executor 产出偏离 spec 的代码（critic 因为看着像样而漏掉 bug，verifier 因为测试失败而抓住它）。

运行：

python3 code/main.py

实际使用 ​

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

拿去用 ​

检查清单：

  • 至少一个确定性 verifier。 绝不全是 LLM。
  • 每个角色显式的 I/O schema。 planner 返回一份 spec，不是散文；executor 读那份 schema。
  • 沟通式去幻觉。 executor 缺信息时必须去问 planner；绝不自己编。
  • critic/verifier 的顺序。 先跑 critic（便宜，抓设计问题），后跑 verifier（慢，抓 bug）。
  • 循环预算。 critic-executor 修订最多 2 轮，再不行就上报给人。

练习 ​

  1. 跑 code/main.py，观察 verifier 如何抓住 critic 漏掉的 bug。加一个静态分析检查（数 return 出现的次数）当作额外的 verifier。它抓到了什么运行时测试漏掉的东西？
  2. 加第 5 个角色：「需求分析师」，把用户的愿望翻译成 planner 可用的 spec。哪些沟通式去幻觉请求该往上流到它这里？
  3. 读 MetaGPT 第 3 节（「Agents」）。列出 MetaGPT 5 个角色各自的输入/输出 schema。
  4. 读 ChatDev 的聊天链图（arXiv:2307.07924 图 3）。指出沟通式去幻觉在哪里打破了一个本会无限的循环。
  5. PwC 的 7 倍准确率提升来自验证循环。假设三个加 verifier 也帮不上忙的任务——那些确定性地检查正确性不可能、或贵到离谱的任务。

关键术语 ​

术语大家嘴上怎么说它实际是什么意思
Role specialization「不同 agent，不同活儿」为 planner/executor/critic/verifier 角色调好的不同 system prompt。
SOP pattern「编码进去的标准操作流程」MetaGPT 的提法：每个角色严格的 I/O schema 把团队变成流水线。
Communicative dehallucination「编之前先问」ChatDev 模式：executor 缺细节时去问 planner，而不是瞎编一个。
Critic「LLM 评审」主观、有立场的评审。抓品味问题。会被像样的措辞骗到。
Verifier「确定性检查」基于代码的通过/失败。测试运行器、类型检查器、schema 校验器。骗不了。
Verification gap「没人检查」MAST 失败的 21.3%。答案在没有一个本会抓住 bug 的检查的情况下交付了。
Revision loop「critic 给打回来」critic 拒绝触发 executor 带反馈重跑。需要一个预算。
All-LLM anti-pattern「我看着挺好」每个角色都是 LLM，没有确定性检查。经典 MAST 故障。

延伸阅读 ​