多智能体协作模式与适用场景

多智能体协作模式，指的是把一项任务拆给多个 Agent，并约定谁先执行、谁可以并行、出现分歧由谁裁决、结果怎样合并的组织方式。它没有唯一的标准分类，不同框架给出的名称也不完全一致。AutoGen 的官方文档分别列出顺序、并行、群聊、交接和辩论等做法，Oracle 则把顺序流水线与主管协调放在同一组对比里。企业落地时，可以直接看这套分工能不能减少等待、减少返工，并让结果可追。

如果任务只有几步，上下文高度耦合，一个 Agent 配好工具往往更省成本。Anthropic 在 2025 年 6 月发布的工程复盘中提到，多智能体系统消耗的 token 约为普通对话的 15 倍，主要用于并行探索和独立上下文。多智能体协作模式适用于子任务边界清楚、结果可以合并、错误能在交付前被拦截的任务。 任务价值不够高，或者所有 Agent 必须盯着同一份实时状态，增加 Agent 数量通常只会放大协调成本。

先判断任务结构，再谈模式

模式选择从任务结构开始。可以用四个问题做初筛，再决定要不要增加 Agent。

任务能不能拆成相对独立的子任务

子任务最好有明确的输入和输出工件，例如一张核查表、一份原因清单、一个待审方案。拆开之后，每个 Agent 能独立完成一段工作，减少来回对话。如果每一步都需要完整的历史记录，拆开反而会让上下文重复传递，增加出错概率。

步骤之间有没有硬依赖

硬依赖指后一步必须等前一步的结果才能开始。顺序流水线适合硬依赖，原因分析和方案复核通常属于这种情况。没有硬依赖却串行执行，会把等待时间一步步叠加。可以并行的部分，应该尽早拆出去。

多个 Agent 需不需要共享同一份状态

共享状态包括同一份客户档案、同一张订单、同一套指标口径。共享越多，交接时越容易丢上下文。可以让统一的知识库或状态服务保存口径，Agent 只传任务编号和引用，不复制整份上下文。这样既减少重复，也方便追查某个结论用了哪一版数据。

出现分歧时谁拍板

讨论型模式会产生多个结论。没有裁决规则，讨论容易变成轮流表态。需要提前指定主管 Agent 或人类负责人，并约定证据优先级，例如一手数据优先于二手摘要，最新版本优先于旧版本。无法消解的分歧要保留，不要为了表面一致删掉少数意见。

先看任务结构，再看模式名称。 四个问题里，如果有两个以上答案指向强依赖、共享状态或无人裁决，先回到单 Agent 或固定工作流。多智能体需要的是可分解、可合并、可验收的任务结构。

五种常见协作模式

下面是五类常见做法。分类来自公开框架文档的归纳，实际系统经常组合使用。

图注：顺序模式按工件逐级传递；并行模式先分叉再统一合并；主管模式在运行时决定分派对象并集中汇总。

顺序流水线

前一个 Agent 的输出是后一个的输入，按固定顺序执行。AutoGen 把这种模式描述为确定性序列，每个 Agent 处理消息、生成结果，再传给下一个。Oracle 的对比文档也指出，顺序模式的运行计划固定，任务依赖会把上游输出传给下游，不支持并行。

它适合步骤清楚、依赖明确的流程，例如数据核查、原因分析、方案复核，或者内容生产里的资料整理、起草、审校。优点是责任清楚、过程容易审计；缺点是前面一步慢了，后面全部等待，上游结论错了，错误会沿着链路放大。

ThinkingAI 内部做过一次交付流程串联实验，把埋点方案、代码埋点、调试验证、知识入库、看板搭建和运营触达串成一条 Agent 链，整条链约 280 秒。这是内部流程实验，不是客户项目基准。这个实验更值得参考的地方，是人在关键节点做判断，例如埋点方案是否合理、看板看哪些指标、这次触达发给谁。执行环节交给 Agent，判断环节留给人，顺序链路才有可控性。

并行分工与汇总

主管或调度器把任务拆成多个互不依赖的子任务，分给多个 Agent 同时处理，最后按统一格式合并。AutoGen 的并发文档展示了同一消息由多个处理器同时处理的用法。Anthropic 的研究系统让主管一次启动 3 到 5 个子 Agent，分别探索不同方向，再汇总结果。

它适合广度优先的任务，例如按渠道、地区、用户分层分别分析，或者同时审阅多份合同、多篇资料。并行缩短等待时间，不减少总工作量。 子任务之间如果边界不清，容易出现重复搜索和结论冲突，所以每个子任务要有独立目标、输出格式和证据要求。

汇总环节要有合并规则。可以按证据强度、数据时间、覆盖范围排序；冲突无法消解时，保留分歧并交给主管或人类判断。并行数量也不是越多越好，每个分支都会消耗 token 和工具调用额度，超出任务价值就不划算。

主管协调

主管 Agent 接收请求，在运行时决定调用哪个或哪些子 Agent，给每个子 Agent 一份自包含的子任务，最后汇总。Oracle 的对比文档把主管模式描述为动态编排，只有需要的步骤才执行，适合分支较多的企业请求。AutoGen 的群聊文档提到，群聊管理器可以用轮询或 LLM 选择下一个发言者，这类机制也能承担部分调度职责。

它适合请求类型变化大、需要条件路由的场景，例如客服工单分流、经营异常诊断、跨部门任务派发。主管可以根据中间结果追加子任务，也可以在证据不足时要求补查。

代价是主管成为瓶颈和单点故障。子任务描述不清，子 Agent 会重复劳动或漏掉范围；主管上下文过长，也会忘记最初的目标。Anthropic 的复盘提到，早期系统曾为简单查询启动 50 个子 Agent，或者让子 Agent 互相干扰。主管模式要同时解决动态分派和集中裁决。 给主管设定任务规模规则、最大轮次和明确的停止条件，比单纯增加子 Agent 数量更重要。

群聊讨论与辩论

多个 Agent 在同一个消息线程里轮流发言，群聊管理器决定下一个发言者；辩论模式则让多个求解 Agent 交换答案，再由聚合 Agent 按多数票或规则汇总。AutoGen 的群聊文档指出，同一时刻只有一个 Agent 在工作，顺序由群聊管理器维护。辩论文档把过程分成若干轮，最后聚合最终答案。

它适合需要多视角的任务，例如方案评审、风险清单、复杂问题的假设检验。讨论要有独立证据，否则容易变成互相附和。 不同角色应该带来不同数据、反例或约束条件，发言次数本身不产生新信息。

使用时要限定轮次、角色和裁决方式。可以要求每个 Agent 先给出证据，再进入讨论；把最终裁决交给主管或人类；保留少数意见，避免为了达成一致而删掉有价值的分歧。高风险任务还要设置人工确认点，不能把最终决定完全交给讨论结果。

层级编排与动态交接

任务规模继续扩大时，可以把多个主管或群聊嵌套成层级。AutoGen 的群聊文档提到，群聊可以嵌套成层级结构，每个参与者本身也可以是一个群聊。交接模式则让一个 Agent 通过工具调用把任务转给另一个 Agent，AutoGen 的交接文档以客服场景为例，由分诊 Agent 把请求转给退款、销售或人工 Agent。

层级协作模式的特点是每一层只处理自己范围内的拆解和汇总，跨层通过工件交接。好处是单个主管不必直接管理所有 Agent，适合跨部门、长流程的任务；代价是链路更长，状态传递和责任边界更容易出问题。层级能扩大管理半径，也会拉长链路。

动态交接适合请求需要专业分工、但入口统一的场景，例如客服、售前咨询、内部 IT 支持。交接时要带上任务目标、已有证据、权限范围和下一步期望，不能只转一句自然语言。接收方无法处理时，要有回到上级或转人工的路径。

五种协作模式的控制方式、并行能力与上下文差异

五种协作模式在控制方式、并行能力、上下文要求和主要风险上各有不同。

先按任务结构初筛，再用试跑结果定稿。 这张表只用于初筛。并行能力和上下文要求会随框架实现变化，选型时要回到具体产品文档和试跑结果，不能把表格当成通用答案。

数据核查、分析、方案复核怎么交接

模式选对只解决一半问题。多智能体最常见的事故发生在交接处，上游给了一段自然语言结论，下游不知道口径、证据和边界，只能重新查一遍。

一份可执行的交接至少写清七件事。

• 任务目标，以及明确不做什么
• 输入工件和版本，例如数据表、指标口径、文档链接
• 输出格式，例如结论、证据、置信度、待确认项
• 证据要求，哪些结论必须有数据或原文支撑
• 权限和工具边界，能否查生产库、能否调用外部系统
• 截止时间、重试次数和超时处理
• 停止条件，什么情况下继续，什么情况下升级给人

以“数据核查、原因分析、方案复核”为例，可以把交接写成下面这样。

主管在这条链路里负责三件事。

• 超时处理。每一步设截止时间，超时后返回已完成部分和当前状态，不能悄悄无限重试。
• 重复执行。给任务唯一编号和输入版本，执行前先在状态账本里认领，输出按任务编号和版本去重。
• 意见冲突。按证据优先级裁决，无法消解时升级给人，并把不同意见记录在案。

状态账本至少记录任务编号、负责 Agent、当前状态、输入版本、输出位置、重试次数和截止时间。没有账本，层级越多，越难判断一个任务到底卡在哪。交接要传工件和边界，不能只传一句结论。

什么时候该用哪种模式

可以用一条简单的判断路径。

• 单 Agent 能完成，先用单 Agent。
• 步骤固定、前后依赖强，用顺序流水线。
• 子任务互不依赖，用并行分工与汇总。
• 请求类型变化大、需要动态分派，用主管协调。
• 需要多视角纠错，用群聊讨论与辩论。
• 规模大、跨部门、需要专业分流，用层级编排与动态交接。

这些选择可以组合。一个经营分析任务，可以先用顺序流水线做数据核查，再按渠道并行分析，最后由主管汇总并交给复核 Agent。模式可以组合，链路越长越要限制轮次和预算。

回到业务场景，多智能体协作模式适用于三类任务。

• 跨源分析。数据分散在多个系统，需要并行取证再汇总，例如同时查看投放、留存、支付和客服记录。
• 专业分流。入口统一，但后续需要不同专家处理，例如客服工单、售前咨询、内部支持。
• 交付前复核。结果风险高，需要独立角色检查证据、边界和回滚条件，例如经营方案、合规材料、对外报告。

不适合的场景也要说清楚。所有 Agent 必须共享同一份实时状态、步骤之间强依赖、错误代价极高且无法回滚的任务，应优先用单 Agent、固定工作流或人工审批。Anthropic 的复盘也提到，多数编码任务的可并行部分比研究少，实时协调和委派仍然是难点。

试跑时可以先拿 20 个左右真实任务，覆盖常见请求、边界请求和失败请求。观察任务成功率、端到端时长、token 与工具调用成本、人工介入率、返工率和重复执行次数。这些指标比 Agent 数量更能说明模式是否有效。

平台需要管住什么

多智能体能否上生产，取决于 Agent 管理能力。选型时要核对任务依赖、状态监控、权限控制、日志审计、成本上限和人工接管。

任务依赖决定顺序和并行；状态监控让主管知道每个子任务卡在哪；权限控制限制 Agent 能查什么、能改什么；日志审计回答结果从哪里来；成本和轮次上限防止任务无限展开；人工接管处理高风险或低置信度的结果。能否上生产，取决于运行管理，不只是 Agent 数量。

ThinkingAI 的 Agentic Engine 支持创建和管理各类 Agent，支持多 Agent 协作和私有化部署。具体某种协作模式能否直接配置、哪些需要自定义编排，要以产品文档和实际验证为准。截至 2026 年 11 月，ThinkingAI 已服务全球超过 1500 家企业、接入产品超过 8000 款，这些跨场景经验可以用于参考，但不能替代企业自己的任务试跑。

常见问题

多智能体一定比单 Agent 好吗

不一定。多智能体的收益来自并行探索和独立上下文，成本是更高的 token、更长的链路和更复杂的协调。任务简单、上下文共享多、步骤强依赖时，单 Agent 配好工具通常更稳。Anthropic 的内部评测中，多智能体在研究任务上比单智能体高 90.2%，同一篇复盘也提到多智能体消耗约 15 倍 token。两个数字要一起看。

多智能体协作模式有标准分类吗

没有统一的行业标准。不同框架会按自己的实现划分，例如 AutoGen 文档列出顺序、并行、群聊、交接和辩论，Oracle 则对比顺序与主管模式。文章里的五类分法用于帮助企业判断任务结构，不应当成唯一标准。

多智能体协作中层次协作模式有什么特点

每一层只负责本层的拆解、分派和汇总，跨层通过工件和状态账本交接。它适合规模大、跨部门的任务，能减少单个主管的管理半径；代价是链路更长，上下文丢失和责任模糊的风险更高。

几个 Agent 比较合适

从能完成任务的最小数量开始。Anthropic 在提示词里给出过规模规则，简单事实查询用 1 个 Agent，直接比较用 2 到 4 个子 Agent，复杂研究才用到 10 个以上。这是他们研究场景的经验，不是通用标准。企业可以先按独立子任务的数量配置，再用任务成功率、时延和成本调整。

如何避免重复执行和无限循环

给每个任务唯一编号和输入版本，执行前先在状态账本里认领；设置单步超时、总时限、最大轮次和预算上限；交接时写清输出格式和停止条件；冲突时按证据优先级裁决，无法消解就升级给人。

多智能体和固定工作流是什么关系

固定工作流把步骤提前写好，适合稳定、可预测的流程。多智能体可以在运行时决定调用谁、是否追加子任务，适合分支多、需要探索的任务。两者可以组合，常见做法是用工作流管住关键节点，把需要判断的环节交给 Agent。

中小企业适合上多智能体吗

可以从两三个角色的小链路开始，例如数据核查、分析、复核，先解决一个高频且结果可验证的任务。不要一开始就搭很大的层级。任务价值、数据基础和人工接管能力，比 Agent 数量更重要。

参考资料

• Anthropic，How we built our multi-agent research system，2025-06-13，https://www.anthropic.com/engineering/multi-agent-research-system
• Microsoft AutoGen，Sequential Workflow，https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/sequential-workflow.html
• Microsoft AutoGen，Concurrent Agents，https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/concurrent-agents.html
• Microsoft AutoGen，Handoffs，https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/handoffs.html
• Microsoft AutoGen，Group Chat，https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/group-chat.html
• Microsoft AutoGen，Multi-Agent Debate，https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/multi-agent-debate.html
• Oracle Help Center，Compare Sequential Workflow and Supervisor Patterns，https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/compare-sequential-workflow-supervisor-patterns.html

以上网页检索于 2026 年 11 月 4 日。