引言：

上一篇讲的是单个 Agent 怎么想(CoT、ReAct……)。但当任务太大、太杂,单个 Agent 会力不从心:上下文塞不下、角色职责冲突、什么都想干反而什么都干不好。这时就需要多个 Agent 分工协作。这一篇沿用相同结构,梳理五种多智能体协作范式,每个讲简单原理、适用场景、优缺点并配小例子。

五种范式按"耦合度/复杂度"大致排列:

  顺序流水线   ──►   主管调度   ──►    分层     ──►   对等网络   ──►   群聊/辩论
  Sequential      Supervisor    Hierarchical     Network       Group Chat
   最简单、线性     一个总管派活    多层主管嵌套     去中心化协商    多方讨论/投票

注意：先想清楚:什么时候才需要多 Agent? 别一上来就上多 Agent——它会带来通信开销、协调复杂度和成本翻倍。只有当出现以下信号时才考虑:

①任务需要多种差异很大的专业角色(如"研究+写作+审校");

②单个 Agent 的上下文/工具太多导致它选择困难;

③需要多视角对抗以提升质量。否则,一个配好工具的单 Agent(上篇的 ReAct)往往更好。

一、Sequential(顺序流水线)

原理:

把任务拆成固定的几道工序,多个 Agent 像流水线一样依次处理,前一个的输出是后一个的输入。顺序和职责都是预先写死的,没有动态调度。本质上是"多个专业 Agent 串成一条确定的链"。

小例子:

写一篇技术博客:
  [调研 Agent] → 收集资料
        │ 传递资料
        ▼
  [写作 Agent] → 写初稿
        │ 传递初稿
        ▼
  [审校 Agent] → 润色定稿  →  输出

适用场景:

工序清晰、顺序固定的任务,如内容生产流水线、数据 ETL、"翻译→校对→排版"

优缺点:

• 优:结构简单、可预测、好调试,几乎等同于一个确定性工作流。
• 缺:死板,无法应对需要动态决策"下一步交给谁"的任务。也无法处理需要“回头”的任务

关键设计 & 实战经验:

• 定义清晰的"工序交接契约":每个 Agent 的输出格式要固定(如统一用结构化字段),下一个 Agent 才能稳定解析。交接处最容易因格式漂移出错,建议在每步之间加一道轻量校验。
• 别让上下文一路裸传到底:如果每个 Agent 都把前面全部内容原样带上,到最后一步上下文会爆炸。让每个 Agent 只输出"下一步真正需要的东西",而非全量历史。
• 一步错、步步错:流水线没有回头路,前面 Agent 的低质量输出会污染后续所有环节。在关键工序后设质量门(不达标就打回或中止),比让错误一路流到终点更省成本。

二、Role-based / SOP 驱动(角色驱动)

简单原理:

给每个 Agent 一个明确的职业角色(产品经理、架构师、工程师、测试……),并为团队预定义一套标准作业流程(SOP)——谁在什么阶段、产出什么标准格式的交付物、交给谁。Agent 不是被临时调度,而是"入职"到一个固定岗位,按流程手册协作。代表框架有 MetaGPT、CrewAI。与 Sequential 的区别:Sequential 关注"工序顺序",而 Role-based 关注"角色身份 + 标准产物 + SOP 规范",角色带有持久的人设和专业视角,协作更像一个真实团队。

一个"软件公司"团队按 SOP 运转:

[产品经理Agent] → 写 PRD(需求文档)
       ▼
[架构师Agent]   → 出设计文档(含接口定义)
       ▼
[工程师Agent]   → 按设计写代码
       ▼
[测试Agent]     → 写并跑测试用例  →  交付
每个角色产出标准化文档,按 SOP 逐环流转

适用场景:

能映射到成熟人类工作流程(有明确岗位和标准产物)的任务,如软件开发、内容创作团队、咨询报告撰写。

优缺点:

• 优:角色清晰、产出标准化、贴合人类协作直觉,易理解易维护;SOP 保证流程规范。
• 缺:流程相对固定,灵活性不如 Supervisor 的动态调度;角色/SOP 设计不当会僵化,或角色间扯皮。

关键设计 & 实战经验:

• SOP 和产出物格式要显式定义:每个角色的输入、输出、交付标准都写死在提示里(如"架构师必须产出含接口定义的设计文档"),这是 Role-based 稳定的根基,也是它区别于"随便几个 Agent 聊聊"的地方。
• 角色人设要聚焦,别贪多:一个角色只对应一种专业视角,职责越单一越可靠。给一个 Agent 塞多个角色,等于没分工。
• 警惕角色越界与"和稀泥":强约束每个角色只做自己该做的(产品经理别去写代码);同时避免角色间过度客气导致问题被掩盖,必要时专设一个"评审/挑刺"角色。
• 本质仍是结构化工作流:别被"角色"的拟人化迷惑——落地时它就是"带角色标签的 Sequential/Supervisor",该设的质量门、上下文隔离一个都不能少。

三、Supervisor(主管-下属 / Orchestrator-Workers)

简单原理:

设一个主管 Agent(Supervisor),它不亲自干活,而是负责理解任务、决定把哪个子任务派给哪个下属 Agent、并汇总下属的结果。下属都是各有专长的"工人 Agent"。和顺序流水线的关键区别:调用哪个下属、调用几次,是主管动态决定的,不是写死的。

小例子:

用户:帮我分析这家公司值不值得投资

        ┌──────────────┐
        │ 主管 Agent    │  判断需要哪些信息,动态派活
        └──────────────┘
          │      │      │
    ┌─────┘   ┌──┘    └────┐
    ▼         ▼             ▼
[财务Agent] [新闻Agent]  [竞品Agent]
    │         │             │
    └─────────┴─────────────┘
              ▼
        主管汇总 → 给出投资建议

适用场景:

需要按情况调度多种专业能力的任务,是目前最主流、最实用的多 Agent 模式。

优缺点:

• 优:灵活、职责清晰、易扩展(加一个新下属即可);主管提供全局协调。
• 缺:主管是单点瓶颈和风险点(它派错活则全错);多了一层调度开销。

关键设计 & 实战经验:

• 主管的系统提示是成败关键:它必须清楚知道"每个下属能干什么、不能干什么"。给主管的工具/下属描述要像招聘 JD 一样精确,否则会派错活、或反复纠结派给谁。
• 下属之间要隔离上下文:每个下属只拿到它那份子任务所需的信息,而不是全局对话。这既降本、又避免下属被无关信息干扰——这是 Supervisor 相比"什么都塞给一个大 Agent"的核心优势。
• 给主管设"派活预算":限制最大派活轮数,防止主管在"再查一个信息吧"的冲动下无限调度。汇总阶段也要明确"信息够了就出结论"。
• 下属失败要能上报:某个下属搞不定时,应如实把失败信息返回给主管重新决策(换个下属/换个策略),而不是让主管拿着空结果硬编。

四、Hierarchical(分层)

简单原理:

当下属团队也很庞大时,把 Supervisor 模式递归嵌套——顶层主管管几个"中层主管",每个中层主管再各自带一个下属团队。像公司的科层制:CEO → 总监 → 员工。任务逐层分解、结果逐层上报。

小例子:

              [CEO Agent]
             /            \
     [研发主管]           [市场主管]
      /      \             /      \
 [前端]   [后端]      [文案]   [投放]

适用场景:

超大型、可层层分解的复杂任务,如"用多 Agent 团队做一个完整软件项目"。

优缺点:

• 优:能组织大规模 Agent 团队,分而治之,单层复杂度可控。
• 缺:层级越多,延迟和成本越高,信息在逐层传递中易失真;工程复杂度陡增。

关键设计 & 实战经验:

• 层级越少越好,能两层别三层:每加一层,延迟、成本、信息失真都成倍放大。现实中绝大多数任务两层(主管+下属)足够,三层以上要有极强理由。
• 警惕"传话失真":结果逐层上报时,中层主管的每次总结都会丢信息。关键数据(数字、结论、错误)要设法原样透传到顶层,而不是被层层"提炼"成模糊描述。
• 成本会指数级累积:每层主管都是额外的 LLM 调用,一个三层、每层 3 个下属的结构,单次任务可能就是几十次调用。上线前务必按第 20 篇的方法估算成本。

五、Network(对等网络 / 去中心化)

简单原理:

没有主管,所有 Agent 地位平等,谁需要谁的帮助就直接通信,自行协商推进。控制权是分散的,像一个专家小组自由讨论,而非听命于一个领导。

小例子:

[规划Agent] ⇄ [编码Agent]
     ⇅    ✕     ⇅          任意两个 Agent 可直接对话,
[测试Agent] ⇄ [文档Agent]    无中心调度,自主决定找谁协作

适用场景:

任务边界模糊、需要 Agent 之间频繁灵活交互、难以预先定义调度逻辑的探索性场景。例如：对话路由(客服分流、意图分类后转专家)、职责边界清晰但路径不固定的场景。

优缺点:

• 优:最灵活,无单点瓶颈,适应动态多变的任务。
• 缺:最难控制和调试;容易出现"扯皮"(反复传球不收敛)、死循环、成本失控。工程上最难驾驭,生产环境慎用。

关键设计&实战经验：

• 每个agent的提示词要写清什么时候该交接并交接给谁和退出条件，边界模糊是扯皮的根源。
• 必须要接分布式trace，并务必完整记录"谁在第几轮对谁说了什么",否则线上出问题几乎无法复盘
• 用共享黑板代替点对点乱传:与其让 Agent 两两私聊(消息呈平方级膨胀、状态难追踪),不如引入一块共享的"黑板"(共享状态/消息区),所有 Agent 读写同一处。这样上下文可见、可审计,也更容易发现死循环。
• 设置交接跳数·防止出现A->B->A->B死循环

六、Group Chat / Debate(群聊 / 辩论)

简单原理:

让多个 Agent 就同一问题同台讨论,各自发表观点、互相质疑补充,最后通过辩论收敛、或投票、或由一个裁判 Agent 总结出结论。核心价值是用多视角对抗来减少单个 Agent 的偏见和错误。

小例子:

问题:这段代码有没有安全漏洞?

[乐观Agent] "看起来没问题,逻辑正常"
[挑刺Agent] "第 12 行的用户输入没做校验,有 SQL 注入风险"
[乐观Agent] "确实,这里应该参数化查询"
        ▼
[裁判Agent] 综合结论:存在 SQL 注入,需参数化改造

适用场景:需要严谨性和多视角的任务,如方案评审、代码审查、复杂决策、事实核查。

优缺点:

• 优:多视角对抗能显著提升质量、发现盲点,减少幻觉。
• 缺:成本高(多个 Agent 多轮对话);可能议而不决,需要明确的收敛机制(投票/裁判/轮数上限)。

关键设计 & 实战经验:

• 角色必须真正"异质",否则等于白开会:如果几个 Agent 用同样的提示、同样的视角,它们会迅速互相附和,达不到对抗效果。要刻意给不同角色分配对立立场(乐观/挑刺、正方/反方、性能派/安全派),甚至强制某个 Agent"必须找出至少一个问题"。
• 必须有明确的收敛机制:辩论本身不会自动停。三种常见收敛方式——裁判 Agent 拍板、多数投票、轮数上限触发后强制总结。任选其一但必须有,否则会陷入无限"我觉得/你觉得"。
• 警惕"回音壁":LLM 天然倾向附和前面的发言,容易几轮后集体倒向同一个(可能错误的)结论。可让 Agent 先独立盲写首轮观点再互相看,避免第一个发言者绑架全场。
• 成本要算清楚:N 个 Agent × M 轮 = N×M 次 LLM 调用,再加裁判。质量提升是否值这个成本,取决于任务价值——高价值决策(方案评审、安全审查)值得,日常小问题用单 Agent 即可

七、Evaluator-Optimizer(评估者-优化者)

简单原理:

两个 Agent 结对——一个生成者(Optimizer/Generator)负责产出结果,一个评估者(Evaluator)按标准打分并给出具体改进意见;生成者据此修订,如此循环,直到评估者判定达标或触及轮数上限。像"作者 + 编辑"反复打磨稿件。与上篇单 Agent 的 Reflexion 的区别:Reflexion 是一个 Agent 自我反思,而这里把"评判"独立成另一个 Agent,评判更客观、标准更专一。

小例子:

任务:把一段技术文档翻译得又准又顺

[生成Agent] 产出译文初稿
      ▼
[评估Agent] "第2句语气太生硬;术语 X 译错" (打分 7/10)
      ▼
[生成Agent] 按意见修订
      ▼
[评估Agent] 达标 (9/10) → 输出
        (循环,最多 N 轮)

适用场景:

有明确质量标准、且能通过迭代逐步逼近的任务,如翻译润色、代码优化、文案打磨、有清晰验收标准的生成任务。

优缺点:

• 优:显著提升单项产出质量;职责分离让评估更客观;标准明确时效果稳定。
• 缺:多轮迭代增加成本和延迟;若评估标准模糊,容易空转或反复改却不收敛。

关键设计 & 实战经验:

• 评估者要有可操作的评分标准:别只让它说"好/不好",要给明确维度和阈值(如"准确性/流畅性/术语一致性各打分,均 ≥8 才通过"),否则反馈无法指导修改。
• 反馈必须具体到"改哪、怎么改":评估者的输出要指向具体位置和可执行建议,而非泛泛点评,生成者才能有效改进。
• 硬性轮数上限 + 兜底返回:设最大迭代轮数,到顶就返回当前最佳版本,防止"改了又改还是不达标"的死循环。
• 评估者能力是质量天花板:它看不出的问题永远改不掉。关键任务不妨用更强的模型或更详尽的 rubric 武装评估者。

八、Blackboard(黑板模式)

简单原理:设一块共享的黑板(公共知识区/共享状态),多个各有专长的 Agent 都能读写它。谁发现自己此刻能贡献,就往黑板上补充内容;黑板状态的变化又可能触发别的 Agent 行动。没有固定流程,协作围绕"共享数据的逐步演进"自发进行,通常再配一个"控制器"决定下一步激活谁。这是经典的 AI 架构,适合把零散的专家意见汇聚到一处、逐步拼出答案。

小例子:

疑难故障"会诊":

        ┌─────────────────┐
        │      黑板        │ ←── [监控Agent] 补充指标数据
        │  (共享问题状态)   │ ←── [日志Agent] 补充异常日志
        │                 │ ←── [网络Agent] 补充链路信息
        └─────────────────┘
              ↕ 谁能补充就上,黑板逐步逼近根因
        [控制器] 判断信息是否足够 → 收尾给结论

适用场景:需要多个异构专家增量式拼凑一个复杂解、且贡献顺序难以预定的任务,如故障诊断、复杂推理、多源信息融合。

优缺点:

• 优:高度解耦(Agent 之间不直接依赖,只依赖黑板);易增删专家;贡献顺序灵活。
• 缺:黑板易成争用/一致性焦点;需要控制策略决定"激活谁、何时停",否则会混乱;共享状态膨胀后难维护。

关键设计 & 实战经验:

• 黑板结构要设计好:用结构化分区(如"已知事实/假设/待验证/结论")而非一锅粥的自由文本,Agent 才能精准读写,也便于判断是否收敛。
• 需要一个控制/仲裁机制:决定每步激活哪个 Agent、以及何时判定"黑板已足够完整可收尾"。纯自由争抢会退化成下面 Network 的失控状态。
• 管好并发写入与上下文膨胀:多个 Agent 同时改黑板要处理冲突;黑板会越写越长,要定期精炼/摘要,否则很快撑爆上下文。
• 与 Network 的区别记心里:Blackboard 是"围绕共享数据"协作(有中心数据、常有控制器),比纯 Network 更可控,是去中心化想法的一种更工程化的落地。

九、选型速查

范式	一句话	最适合	复杂度/成本
Sequential	固定流水线依次处理	工序固定的任务	低
Role-based / SOP	固定角色按 SOP 协作	可映射人类岗位流程的任务	中低
Supervisor	一个主管动态派活	多专业能力调度(首选)	中
Hierarchical	主管嵌套、分层管理	超大型可分解任务	中高
Evaluator-Optimizer	生成-评判反复打磨	有明确质量标准的迭代任务	中
Blackboard	共享黑板增量拼答案	多专家融合的诊断/推理	中高
Network	去中心化自由协商	边界模糊的探索任务	高
Group Chat / Debate	多方讨论 / 辩论收敛	需多视角的评审决策	高

三条选型经验:

1. 能单 Agent 就别多 Agent;确需多 Agent 时,默认从 Supervisor 起步,它覆盖了大多数实际需求;若任务天然对应人类岗位流程,则 Role-based 更顺手。
2. 控制通信开销:Agent 间每次"对话"都是一次 LLM 调用,数量和轮次要设上限,否则成本和延迟失控。
3. 务必设收敛机制:尤其 Evaluator-Optimizer、Network 和 Debate,必须有"最多几轮""谁拍板"的硬约束,否则会陷入无限扯皮或空转。

补充:上述范式常靠 Handoff(交接) 机制落地——一个 Agent 把任务连同上下文"移交"给另一个 Agent 接手,是多数框架实现协作的底层动作。

十、范式可以叠加

真实系统极少只用一种。常见组合:

●主管-下属（Supervisor）+ Evaluator-Optimizer:主 Agent 派一个 worker 写、再派一个 worker 审,审不过打回——这正是 Claude Code「executor + code-reviewer」、OMC team pipeline 的做法。

●流水线（Sequential） + Evaluator-Optimizer:每个流水线阶段内部套一个「生成-评估」小回环,阶段产出达标才往下游推。

●Role/SOP 本质是带角色语义的 Sequential,而 MetaGPT 的消息池又给它叠了一层 Blackboard 通信。

●Network + Supervisor） 兜底:平时去中心交接,但保留一个「监督者」在跳数超限或交接成环时强制接管。

选型时先选拓扑（整体控制），再按需局部叠加（决定质量上限）

十一、小结

多智能体的核心不是"越多越好",而是用分工换取单 Agent 给不了的专业性、可扩展性和多视角,代价是通信开销与协调复杂度。八种范式可归为三类:中心化控制(Sequential、Role-based、Supervisor、Hierarchical)结构清晰、最常用,其中 Supervisor 是最实用的起点;生成-评判闭环(Evaluator-Optimizer)专攻质量打磨;去中心化协作(Blackboard、Network、Group Chat/Debate)灵活但难控,务必配好收敛与可观测机制。