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

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

本节摘要:2026 年最常见的多智能体分解:一个规划、一个执行、一个批判或验证。MetaGPT(arXiv:2308.00352)把它形式化为编码进角色提示的标准作业流程(SOP)——产品经理写 PRD、架构师出设计、项目经理拆任务、工程师实现、QA 跑测试,遵循 Code = SOP(Team)。ChatDev(arXiv:2307.07924)用「对话链」串起设计师、程序员、评审、测试员,并引入「交流式去幻觉」(执行者缺细节时显式追问而非编造)。本节强调验证者是承重角色:Cemri 等的 MAST 研究显示,21.3% 的多智能体失败源于验证缺口——系统输出了没人检查过的答案;PwC 报告结构化验证回路把准确率从 10% 拉到 70%(7 倍)。解法不是「更多 Agent」,而是「不同角色 + 至少一个确定性验证者」。

学习目标

阅读完本节,你应当能够:

1. 说清四个标准角色(规划者、执行者、批判者、验证者)的输入输出与工具边界。
2. 区分批判者(主观 LLM)与验证者(客观代码),说明为何必须两者并用。
3. 应用 MetaGPT 的 SOP 模式与 ChatDev 的交流式去幻觉。
4. 解释验证者为何是承重角色(MAST 21.3% 验证缺口、PwC 7 倍增益)。
5. 识别「全 LLM 反模式」并加至少一个确定性验证者。

一、问题与直觉

通用的多智能体系统产出通用的输出。群聊里三个程序员写出三种口味的同一平庸代码。你可以加更多 Agent、更多轮,仍跨不过质量门槛。

解法不是更多 Agent——是不同的 Agent。分派不同角色:给批判者规划者没有的工具;给验证者一套客观测试套件。这样系统才有「基于事实纠正的内部异议」,而非并行猜测。

四个标准角色

• 规划者:读目标,产出步骤列表或规范。输出结构化计划。
• 执行者:一次读一个计划步骤,产出产物。工具是真正干活的(编译器、shell、API 客户端)。
• 批判者:对照规划者意图读执行者输出。工具:产物的只读访问、静态分析。输出:接受/拒绝 + 理由。
• 验证者:读产物并跑确定性检查。工具:测试运行器、类型检查器、schema 校验器。输出:通过/失败 + 证据。

批判者主观、有意见、常是 LLM;验证者客观、确定、常是代码。它们不是同一个角色。

MetaGPT 的 SOP 模式

MetaGPT 把软件工程 SOP 编码为角色提示:产品经理写 PRD → 架构师出系统设计 → 项目经理拆任务 → 工程师实现 → QA 工程师跑测试。每个角色有严格的输入输出 schema;角色提示说清这个角色「是什么」「必须产出什么」。Code = SOP(Team) 公式——确定性 SOP 把一个 LLM 团队变成可预测的流水线。

ChatDev 的交流式去幻觉

ChatDev 加了关键一招:执行者需要计划里没有的具体细节时,先显式问设计师再继续,而非把细节「合理地」编出来。实现:角色提示里写「当你需要没被给定的具体信息时,先按名字问相关角色,再产出。」

⚠️ 交流式去幻觉直击 LLM 最经典的失败——用流畅措辞把缺的细节编圆。把它写进每个执行者角色提示,几乎零成本就能挡掉一大类幻觉。

为什么验证者最重要

Cemri 等(MAST)追踪了 1642 次多智能体执行失败。21.3% 是验证缺口——系统输出了没人检查过的答案。剩下 79% 里,很大一部分可回溯到「有个检查默默失败或根本没跑」。验证是承重角色。

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

批判者 vs 验证者

• 批判者是审查产物的 LLM,主观,会被流畅措辞骗过。
• 验证者是在产物上运行的确定性程序,客观,给带证据的通过/失败。

两者都用。 批判者抓验证者讲不出的「品味问题」;验证者抓批判者看不见的、只在运行时显现的 bug。

反模式

系统里每个角色都是 LLM,每个角色的输出都是「我觉得行」。经典 MAST 失败。至少加一个其通过/失败由代码(而非 LLM)决定的验证者。

二、从零实现

code/main.py 实现一个构建简单 Python 函数的四角色流水线:规划者出规范,执行者生成代码字符串,批判者(LLM 模拟)标明显见问题,验证者在沙箱(exec)里跑生成的代码对测试用例。

骨架

class Planner:
    def run(self, goal): return {"fn_name": "add", "params": ["a","b"], "spec": "返回 a+b"}

class Executor:
    def run(self, spec):
        return f"def {spec['fn_name']}({','.join(spec['params'])}):\n    return {spec['params'][0]}+{spec['params'][1]}"

class Critic:
    def run(self, code, spec):
        # 主观检查:有 def? 有 return? 参数对?
        issues = []
        if "return" not in code: issues.append("缺 return")
        return {"accept": not issues, "issues": issues}

class Verifier:
    def run(self, code, test_cases):
        # 客观检查:真正跑代码
        ns = {}; exec(code, ns)
        for args, expected in test_cases:
            fn = ns[list(ns)[-1]]   # 取最后定义的函数
            if fn(*args) != expected:
                return {"pass": False, "evidence": f"{args} 期望 {expected}"}
        return {"pass": True}
​

两次对比演示

# happy:执行者产出正确代码 → 批判者+验证者都过
# 扰动:执行者产出 off-spec 但看起来合理的代码
#       → 批判者miss(措辞流畅),验证者catch(测试失败)
​

设计要点:扰动路径里,批判者因为代码看起来合理而 miss,验证者因为测试失败而 catch。这正是「主观/客观并用」的价值——两者覆盖的失败空间不重叠。

三、框架对比

💡 心法:框架差异在「角色怎么表达」,共识在「必须有验证者」。 任何框架落地这四个角色,关键都是别让所有角色都是 LLM——至少一个的 pass/fail 由代码决定。

四、可复用产物

outputs/skill-role-designer.md:输入任务,产出角色花名册(3~5 个角色)、每角色的输入输出 schema、验证者检查。在把 Agent 接进框架前先用它过一遍。

五、练习

1. 观察验证者价值:跑 code/main.py,看验证者如何抓批判者漏的 bug。再加一个静态分析检查(数 return 出现次数)作为额外验证者。它抓到了运行时测试漏的什么?
2. 加第五角色:加「需求分析师」,把用户愿望翻成规划者可用的 spec。该向上流向它的交流式去幻觉请求有哪些?
3. 读 MetaGPT:读 MetaGPT 第 3 节,列出其 5 角色各自的输入输出 schema。
4. 读 ChatDev 对话链:读 ChatDev(arXiv:2307.07924 图 3),识别交流式去幻觉在哪里打断了一个本会无限的循环。
5. 验证无效的场景:PwC 的 7 倍增益来自验证回路。假设三个加验证者也无济于事的任务——确定性正确性检查不可能或代价过高的场景。

本节要点回顾

1. 解法是不同角色而非更多 Agent:规划者、执行者、批判者、验证者,各有专精提示与工具边界。
2. MetaGPT 的 SOP 模式:角色提示编码标准作业流程,Code = SOP(Team),严格 I/O schema 把团队变流水线。
3. ChatDev 的交流式去幻觉:执行者缺细节时显式问而非编造——几乎零成本挡一大类幻觉。
4. 验证者是承重角色:MAST 21.3% 失败是验证缺口;PwC 加验证回路获 7 倍准确率增益。
5. 批判者(主观 LLM)≠ 验证者(客观代码):两者覆盖的失败空间不重叠,必须并用。
6. 反模式:全 LLM、所有输出都是「我觉得行」——至少加一个 pass/fail 由代码决定的验证者。
7. 回路要有预算:批判者-执行者修订最多 2 轮,超了升级到人类。
8. 框架共识:无论 CrewAI/LangGraph/MetaGPT/ChatDev/AutoGen,差异在角色表达,共识在必须有验证者。

下一节,我们从线性流水线转向并行/集群/网络化架构,看当多个对等 Agent 通过共享状态协作、无固定编排者时,系统如何扩展与涌现行为。