简介：本文系统梳理多Agent系统的四种核心架构模式——Orchestrator/Worker、Supervisor、Peer-to-Peer与Pipeline，回答“它是什么、为什么需要、如何选型”三个问题，帮助开发者理解各模式的决策归属、质量把控、横向协调与阶段划分能力，并给出组合使用与避坑建议。
当一个 Agent 学会调用工具、维护上下文之后，下一步自然会遇到的问题就是：多个 Agent 之间如何协作？很多团队的第一反应是“把大 Agent 拆成小 Agent，再连起来”。但工程实践反复证明，拆分方式本身决定了系统的复杂度天花板。拆得好，系统可观测、可扩展、可容错；拆得随意，最终得到的是一团互相等待、难以定位问题的分布式泥潭。
因此，引入“多 Agent 架构模式”这一层抽象就非常必要。它不是具体的框架或库，而是一组关于“职责如何分配、控制流如何流动、结果如何汇聚”的可复用设计范式。本文围绕四种最常用的模式展开：Orchestrator/Worker（主从）、Supervisor（督导）、Peer-to-Peer（对等）、Pipeline（流水线），逐一说明其定义、原理、适用边界与典型取舍。
多 Agent 架构模式，是指在由多个具备一定自主能力的 Agent 组成的系统中，对任务分解方式、控制权归属、通信拓扑和结果聚合路径所做的结构化约定。
它和“单 Agent 加更多工具”有本质区别。单 Agent 的复杂度主要来自提示词与工具集；而多 Agent 系统的复杂度主要来自协作关系：谁来决定下一步？谁来判断质量是否达标？多个 Agent 之间能否直接对话？任务是否必须按顺序流过若干阶段？这四个问题恰好对应四种模式要解决的核心问题：
| 模式 | 核心问题 | 常见类比 |
|---|---|---|
| Orchestrator/Worker | 谁做决策？ | 管理层 + 执行部门 |
| Supervisor | 谁把控质量？ | 编辑 + 撰稿人 |
| Peer-to-Peer | 怎么横向协调？ | 同事协作 |
| Pipeline | 怎么分阶段？ | 工厂流水线 |
需要强调的是：没有银弹。真实的大系统往往是复合结构——外层用 Orchestrator 做统一调度，某个 Worker 内部用 Pipeline 处理多阶段流程，而在需要多方会诊的环节再引入 Peer-to-Peer。理解每种模式的边界，比记住某一种“最佳实践”更重要。
系统中存在一个主 Agent（Orchestrator），负责接收外部任务、理解意图、把任务拆解为子任务，并按需分派给一个或多个 Worker Agent；Worker 只负责执行被分派的子任务并返回结果，彼此之间不直接通信；最后由 Orchestrator 汇总、校验并输出。
一种示意性的控制流可以表示为：
task -> Orchestrator├─ 拆解为 [subtask_a, subtask_b, subtask_c]├─ dispatch(subtask_a) -> WorkerA -> result_a├─ dispatch(subtask_b) -> WorkerB -> result_b└─ dispatch(subtask_c) -> WorkerC -> result_c-> aggregate(results) -> final output
该模式把“决策”和“执行”彻底分离。决策路径集中在一处，意味着上下文管理、权限控制、日志记录都可以围绕单一入口设计。对于需要统一审计或统一注入系统提示词的场景，这种集中性非常有价值。
优点方面：逻辑清晰，一个入口一个出口，便于理解和维护；可调试性强，所有决策路径都经过 Orchestrator，日志链路完整；容错容易实现，Orchestrator 可以识别失败 Worker 并重试或降级。
代价方面：Orchestrator 容易成为性能与决策的单点瓶颈，任务量增大时其调度开销不可忽视；灵活性偏低，Worker 之间任何协作意图都必须绕道 Orchestrator 中转，增加了往返延迟；此外，Orchestrator 的拆解质量直接决定整体效果，一旦拆解不合理，Worker 再强也难以补救。
Supervisor 模式在结构上与主从模式相似，但关注点不同：它不以“拆解分派”为核心，而以质量把控与迭代审查为核心。Supervisor Agent 负责任务分配，同时负责对 Worker 产出进行评估、打回、要求修改，形成“生成—审查—再生成”的闭环。
主从模式的目标是“把活分出去并收回来”，Supervisor 模式的目标是“确保收回来的活达标”。前者偏重任务分解，后者偏重质量约束。在实现上，Supervisor 通常需要具备明确的评价标准、可量化的验收条件以及重试上限策略，否则容易陷入无限返工的循环。
适合输出质量要求较高、且质量可被规则或模型判断的任务，例如内容生成后的合规与风格审查、代码生成后的静态检查与修复建议、结构化数据抽取后的字段校验等。
必须设置最大迭代轮次与超时预算，避免审查循环失控；同时应把审查意见结构化为可执行的修改指令，而非模糊评价，否则 Worker 的改进方向不明确，收敛速度会很慢。
没有中心调度者，多个 Agent 处于对等地位，通过消息传递直接协商、分工与共享中间结果。每个 Agent 既可能是请求发起方，也可能是响应方，控制权在会话过程中动态转移。
有些问题天然需要多方视角的碰撞与协商，例如方案评审、多角色讨论、需要互相补全信息的探索性任务。这类场景下，中心化调度反而会成为信息流动的阻碍——所有信息都要经过一个节点中转，既不自然也低效。
优点是横向协调灵活，Agent 可以根据局部信息快速响应，适合开放式、探索式任务；缺点是全局可观测性差、收敛性难保证。没有统一调度者意味着容易出现对话轮次膨胀、观点僵持、责任边界模糊等问题。因此实践中通常需要附加约束：限定最大轮次、设定议题边界、指定某一 Agent 承担收敛职责（例如在讨论结束时汇总共识）。
把任务划分为若干固定阶段，每个阶段由专门的 Agent 负责，上游产出作为下游输入，按序流动。其本质是把复杂任务转化为一条阶段明确、接口清晰的处理链。
Pipeline 模式天然支持并行，但前提是阶段之间设置缓冲区（队列或任务池）。有了缓冲，多个 Agent 可以同时工作在不同任务上——写作 Agent 在处理文章 A 的同时，审核 Agent 可以审核已经完成 stage 的文章 B，两者互不干扰。这种“流水线化”的并行，使系统吞吐量不再取决于最慢单环节的串行叠加，而取决于各阶段的处理能力配比。
incoming -> [Stage1 队列] -> Agent1↓[Stage2 队列] -> Agent2↓[Stage3 队列] -> Agent3
适合流程固定、阶段边界清晰、每阶段输入输出格式可定义的任务，例如文档处理流水线（解析—抽取—校验—入库）、内容生产流水线（撰写—审核—润色—发布）。代价是灵活性较差：阶段顺序一旦固化，遇到需要回退或跳步的异常情况处理起来比较别扭；同时需要关注背压问题，当下游处理速度跟不上时，缓冲区会持续堆积，必须有容量上限与降级策略。
选型不必从“哪个模式更先进”出发，而应从任务结构出发，依次回答四个问题：
若四个问题的答案兼而有之，那就采用组合架构：外层 Orchestrator 负责入口与调度，内部某个 Worker 用 Pipeline 处理多阶段流程，需要会诊的环节嵌入 Peer-to-Peer，关键产出节点挂一个 Supervisor 做质量闸门。
多 Agent 架构模式的本质，是对“决策权、质量权、协调权、阶段划分权”这四种权力的结构化分配。Orchestrator/Worker 解决决策集中问题，Supervisor 解决质量闭环问题，Peer-to-Peer 解决横向协商问题，Pipeline 解决阶段化与并行吞吐问题。理解每种模式的适用边界与代价，比执着于某一种“标准答案”更有价值。真正健壮的多 Agent 系统，往往是多种模式在清晰边界下的有机组合，而非单一范式的机械套用。