多智能体系统,英文常写作 Multi-Agent System,简称 MAS,是由多个具备一定自主性的智能体,在共享环境中分工、通信并协调行动,以完成单个智能体难以独立完成的任务的系统。
如果你只是想快速知道多智能体系统是什么意思,可以把它理解为一支会自己分工的数字团队。有人负责理解任务,有人负责查资料,有人负责调用业务系统执行,最后有人负责核对结果。
这支团队的基本特征是存在多个具备一定自主性的智能体,并通过交互协调任务。分工可以预先设定,也可以在运行时根据中间结果调整。运行时动态拆分是动态编排的典型做法;单个成员难以独立完成任务,是采用多智能体的常见理由,二者都不是所有 MAS 的必要条件。
放到企业 AI 场景里,本文讨论的多智能体系统,主要指以大模型为推理核心、能调用工具和业务系统的 Agent 系统。学术界的 MAS 范围更广,还包括机器人、仿真和分布式软件系统。企业更关心的是,多个 Agent 如何在同一套业务目标、数据和权限边界下协作,并把结果交付出来。这也是多 Agent 协作落地时最容易被忽略的部分。
多智能体系统由哪些部分组成
IEEE 的软件智能体条目把多智能体系统描述为多个智能体在共享环境中运行的系统。智能体可能合作、竞争或两者兼有,具体取决于目标是否一致;合同网、拍卖和共识协议等机制负责分配任务和解决冲突。软件智能体的研究脉络可以追溯到 20 世纪 80 年代的分布式人工智能,多智能体系统则在这一基础上发展起来。
把定义拆开,有四个要素。
| 要素 | 含义 | 企业场景里的对应物 |
|---|---|---|
| 多个智能体 | 每个 Agent 有自己的角色、上下文、工具和权限 | 客服 Agent、数据分析 Agent、审核 Agent |
| 共享环境 | Agent 能感知并作用于同一组业务对象 | 订单、工单、客户、指标、文档 |
| 交互与协调 | 通过消息、任务板、共享文件或知识库交换信息 | 任务分派、结果汇总、冲突处理 |
| 共同目标 | 整体要完成一个业务结果 | 解决工单、生成报告、完成退款 |
四个要素里,最容易被忽略的是共享环境和共同目标。多个 Agent 各自回答一个问题,没有统一的业务对象和验收标准,很难形成系统能力。比如三个 Agent 都能查客户数据,却对客户状态的理解不一致,最后汇总出来的结论就不可用。
Agent 在这个语境里,指能感知输入、做判断、调用工具并执行动作的软件单元。它通常由模型、提示词、工具、记忆和权限组成。一个 Agent 可以只负责查资料,也可以负责执行退款这类具体动作。
多智能体系统的价值来自分工后的并行、专业化和独立检查。一个系统可以只有两三个 Agent,也可以有几十个。数量本身不说明先进程度,任务是否需要协调才决定它的意义。
和单个 Agent、固定工作流有什么区别
三者解决的是不同复杂度的问题。
| 维度 | 单个 Agent | 固定工作流 | 多智能体系统 |
|---|---|---|---|
| 决策路径 | 在一个推理循环内完成 | 路径由代码预先定义 | 多个自主 Agent 交互,分工与顺序可预设或动态调整 |
| 上下文 | 一个上下文窗口 | 节点之间传递结构化数据 | 多个独立上下文,按需汇总 |
| 擅长任务 | 边界清晰、工具较少 | 步骤稳定、高频、强审计 | 任务开放、可并行、工具多 |
| 成本结构 | 较低 | 较低且可预测 | 较高,推理与协调开销都增加 |
| 主要风险 | 单点能力不足 | 例外处理弱 | 错误放大、状态不一致、调试难 |
用退款场景看差异。单 Agent 适合金额小、规则清楚、风险低的退款,它自己查订单、读政策、调用退款接口。固定工作流适合步骤稳定、需要强审计的标准退款,每一步由代码控制,异常转人工。多智能体适合问题类型多、需要查政策、评估风险、执行退款并复核的场景,分流、知识、风控、执行、审核各自承担一段工作。
三种方式可以组合。一个多智能体系统内部,某个 Agent 完全可以用固定工作流完成自己的子任务。工作流里也可以调用一个具备判断能力的 Agent。
判断是否需要多智能体,可以先问四个问题。
- 任务能不能拆成相对独立、可以并行的子任务?
- 是否需要多种工具、数据源或专业角色?
- 分工是否需要在运行时根据中间结果决定?
- 结果能不能被验证、回滚或人工接管?
前三个问题用于识别多智能体可能带来的价值,不要求全部回答是:预设角色的顺序协作也可以构成 MAS。进入设计前,应说明专业分工、并行或独立复核带来的收益,并为第四个问题明确验收、回滚或接管方式。收益不足以覆盖协调成本时,单 Agent 或工作流通常更稳。
多个 Agent 如何协作
多智能体系统的工程难点通常出现在协作环节,包括重复工作、信息丢失、错误放大,以及出错后停不下来。把几个 Agent 连起来不难,让它们在边界内稳定交接才难。
任务拆解与角色分工
常见做法是设一个主控 Agent,先把目标拆成子任务,再分给专业 Agent。Anthropic 在 2025 年 6 月公开的研究系统复盘中提到,子任务说明要包含目标、输出格式、可用工具、资料来源和任务边界。说明太短,子 Agent 会重复搜索或漏掉关键部分。
角色数量按任务需要设置。研究、执行、审核三类角色已经能覆盖不少场景。为了显得完整而设很多角色,会增加协调成本和上下文传递损耗。
通信、共享状态与结果汇总
Agent 之间通常通过消息、共享任务板、文件或企业知识库交换信息。
这里有一个取舍。每个子 Agent 使用独立上下文,可以并行处理更多信息,减少相互干扰;但结果汇总时容易丢细节。Anthropic 的做法是让子 Agent 把结构化结果写入外部文件,主控 Agent 只接收轻量引用,降低多轮转述造成的信息损失。
共享知识库解决另一类问题。多个 Agent 对同一个指标、同一个客户状态、同一条政策有不同理解,系统就会给出互相矛盾的答案。知识库需要把定义、版本和适用范围管起来,否则 Agent 越多,口径冲突越明显。
四种常见编排方式
| 方式 | 怎么运行 | 适合什么任务 | 主要代价 |
|---|---|---|---|
| 中心编排 | 一个主控 Agent 拆任务、派活、汇总 | 任务可分解,需统一验收 | 主控容易成为瓶颈 |
| 层级编排 | 主控下再设子主控,多层分派 | 任务树大、角色多 | 管理层级多,状态同步难 |
| 流水线 | 多个 Agent 按阶段交接 | 阶段清晰、顺序稳定 | 例外处理弱,容易退化成工作流 |
| 路由分发 | 先判断请求类型,再交给专业 Agent | 客服分流、专家问答 | 只做一次分派,协作深度有限 |
去中心化的点对点协作也存在,Agent 之间直接通信,灵活度高,调试和审计更难。在需要清晰责任边界和追踪路径的企业场景里,中心编排或层级编排更常见。Microsoft Learn 在多智能体编排课程中把中心编排、层级主管、并行分发和部分失败恢复列为需要掌握的模式。
Anthropic 的研究系统怎么协作
Anthropic 的 Research 功能采用编排者加工作者的结构。主控 Agent 分析问题、制定策略,再启动多个子 Agent 并行探索不同方向。子 Agent 各自使用独立上下文和工具,返回结果后由主控汇总;如果信息不够,主控会继续拆分任务或补充搜索。
Anthropic 在复盘中公布的数据显示,在其 2025 年的内部研究评测中,以 Claude Opus 4 为主控、Claude Sonnet 4 为子 Agent 的系统,比单 Agent 的 Claude Opus 4 高 90.2%。同一份复盘显示,多智能体系统的 token 消耗约为普通对话的 15 倍。在其 BrowseComp 分析中,token 使用量单独解释了 80% 的性能差异。并行工具调用还把复杂查询的研究时间最多缩短了 90%。
这些数字有明确边界。90.2% 来自 Anthropic 2025 年的内部研究评测,任务类型偏向广度优先的信息检索,不能直接推导到客服、财务或生产运维。它更适合说明多智能体的收益来源,把信息量超过单个上下文的任务拆开,让多个独立上下文并行处理,再把结果压缩回主控。
Anthropic 在复盘中提到,编码任务可并行的部分通常少于研究任务,Agent 在实时协调和委派方面仍有局限。按这份复盘的经验,任务强依赖、需要所有 Agent 共享同一上下文时,多智能体并不合适。
企业里哪些任务适合多智能体
从任务结构看,以下三类更容易体现价值。
跨来源调研与情报整合
市场变化、竞品动作、客户反馈和政策信息分散在不同系统里。主控 Agent 把问题拆成若干调查方向,子 Agent 并行检索,最后汇总成带来源的结论。适合信息分散、需要交叉验证、错误成本可控的任务。
客服与售后处理
分流 Agent 判断问题类型,知识 Agent 查产品和政策,风控 Agent 检查退款条件,执行 Agent 调用订单系统,审核 Agent 复核结果。高风险或超出权限的工单转人工。适合问题类型多、规则复杂、需要多个系统配合的售后场景。
数据分析与报告
理解问题的 Agent 把自然语言转成分析任务,指标 Agent 确认口径,SQL Agent 生成查询,校验 Agent 检查结果,报告 Agent 组织结论。适合指标多、数据源多、分析请求频繁的团队。前提是指标定义统一,数据权限清楚,结果能被复核。
复杂运营和研发流程也能使用类似结构,例如活动效果诊断、线上故障初筛。共同点是任务可以拆成相对独立的调查或执行单元,每个单元需要不同工具或知识。
哪些情况不适合多智能体
多智能体系统有明显的成本门槛,以下情况要谨慎。
- 步骤稳定、高频、低价值。固定工作流更便宜,也更容易审计。
- 单个 Agent 能完成。增加 Agent 只会增加协调和调试成本。
- 任务强依赖,所有成员需要共享同一上下文。Anthropic 的经验是,这类任务当前并不适合多智能体。
- 动作高风险且不可逆。没有人工审批和回滚机制,多智能体可能放大错误。
- 没有评估和可观测手段。看不到每个 Agent 做了什么,就无法定位问题。
前文提到的 15 倍 token 消耗,意味着单任务价值必须足够高。如果单任务收益不足以覆盖推理、复核和维护成本,多智能体很难算得过账。
落地前要算清五笔账
任务价值账
先算单任务收益,再算推理成本、人工复核成本和维护成本。单任务收益长期低于这三项成本之和,系统很难持续运行。
权限与安全账
每个 Agent 应有最小权限,工具调用要有边界,敏感数据要限制访问范围。涉及资金、客户信息或生产系统的动作,需要审批和审计。数据不能出企业时,私有化部署是前提。
知识与口径账
多 Agent 对同一指标、同一政策给出不同答案,往往源于知识没有治理。统一指标定义、客户状态和政策版本,建立可追溯的更新机制,比增加 Agent 数量更重要。企业可以把统一指标口径作为多智能体协作的基础设施。
评估与可观测账
多智能体的执行路径不固定,只看最终答案容易漏掉过程问题。需要记录任务分派、工具调用、结果汇总和失败重试,建立结果指标和过程约束。Anthropic 的经验是,评估应看结果是否达成,同时检查过程是否合理。
人工兜底账
高风险动作要设审批点,失败要能回滚,异常要能转人工。人工兜底属于系统设计的一部分,需要在上线前准备好。
一个稳妥的推进顺序是,先用单 Agent 加固定工作流跑通一个高价值、低风险场景,把知识、权限、评估和人工兜底做稳,再把可并行的子任务拆给多个 Agent。可以参考企业 Agent 落地路线图安排阶段目标。
ThinkingAI 的实践视角
ThinkingAI 的企业级 AI Agent 平台 Agentic Engine 支持企业创建和管理各类 Agent,支持多 Agent 协作,具备全域感知能力,并支持私有化部署。平台把感知、分析、决策和执行串成闭环,适合需要把 Agent 接入自有数据和业务系统的企业。
多智能体协作的上游是知识一致性。ThinkingAI 的企业知识库把文档、报表等加工成结构化、关联化、版本化的知识,通过统一接口供 Agent 调用。它用 SSOT 机制保证同一概念在全系统只有一处定义,用 ChangeSet 机制支持追溯、对比和回滚。对多 Agent 系统来说,这能减少不同 Agent 对同一指标或政策给出不同答案的情况。
截至 2026 年 11 月,ThinkingAI 已服务全球超 1500 家企业,接入产品超 8000 款。多智能体是否值得上,仍要回到任务价值、协作复杂度和治理成本。平台能提供底座,不能替代企业把业务边界和验收标准想清楚。
常见问题
多智能体系统就是多个大模型一起聊天吗
多个大模型互相聊天,只能说明有多个模型在交互。要成为可用的多智能体系统,还需要明确的角色分工、共享的业务对象、可执行的工具、结果汇总和验收机制。缺少这些,聊天记录很难变成稳定的业务结果。
多智能体一定比单个 Agent 效果好吗
不一定。Anthropic 的内部评测显示,多智能体在广度优先的研究任务上明显优于单 Agent,但 token 消耗约为普通对话的 15 倍。任务简单、步骤稳定或对延迟敏感时,单 Agent 或工作流更合适。
多智能体和 MAS 是同一个概念吗
MAS 是多智能体系统的英文缩写,学术界使用范围更广,涵盖软件智能体、机器人、仿真系统等。企业 AI 语境里的多智能体系统,通常指以大模型为核心、能调用企业工具的一类 MAS。
小团队要不要上多智能体
可以从单 Agent 加固定工作流开始。先把一个高价值、低风险场景跑通,把知识、权限、评估和人工兜底做稳,再判断是否有必要把任务拆给多个 Agent。团队规模小的时候,维护多个 Agent 的协调和调试成本往往先成为负担。
多智能体会取代工作流吗
两类方案解决不同问题。工作流适合步骤稳定、需要强审计和高确定性的流程;多智能体适合任务开放、需要动态分工和并行探索的场景。实际系统里,两者经常组合使用。
参考资料
- IEEE Technology Navigator,Software agents,https://technav.ieee.org/topic/software-agents/,访问日期为 2026 年 11 月 4 日。
- Anthropic,How we built our multi-agent research system,2025 年 6 月,https://www.anthropic.com/engineering/built-multi-agent-research-system
- Microsoft Learn,Implement advanced multi-agent orchestration patterns in Microsoft Foundry,https://learn.microsoft.com/cs-cz/training/modules/aaai-implement-multi-agent-orchestration-azure-ai-foundry/,访问日期为 2026 年 11 月 4 日。






