多智能体系统（Multi-Agent Systems，MAS）由多个在共享环境中交互的智能体组成，各智能体之间既可以协同合作，也可以相互博弈竞争。每个智能体都是具备一定自主性的独立实体，能够感知环境、做出决策并执行动作；通过彼此通信与协作，它们能够解决单个集中式系统难以应对的复杂问题。随着大语言模型（LLM）在推理与自然语言通信能力上的跃升，基于 LLM 的多智能体架构正受到越来越广泛的关注。
本课介绍多智能体系统的核心概念、适用场景与优劣取舍，引入 LangGraph 之外的另一个常用多智能体编排框架 CrewAI，并介绍用于实现跨框架、跨语言智能体互联互通的 Agent-to-Agent（A2A）协议。
多智能体系统的含义
多智能体系统是由多个相互独立、彼此交互的智能体组成的计算机系统。在 AI 领域，这些智能体通常是目标导向、无需人类逐步干预即可自主决策的软件实体。在一个 MAS 中，每个智能体往往只掌握局部知识与自身状态，未必有任何一个单一智能体了解全局完整状态；系统的整体能力源于各智能体之间的信息共享、任务协调与交互（交互所在的共享环境既可以是数据仓库、互联网或仿真环境，也可以是智慧工厂等物理空间）。
形式上，MAS 可以定义为“由多个相互交互的智能体组成的计算机系统”。智能体彼此交互，也与共享环境交互。环境可以是数据仓库、网络或模拟世界，也可以是机器人所在的工厂等物理空间。交互包括为共同目标合作，协调任务依赖与执行顺序，以及在目标不同时进行竞争。
MAS 中智能体的三项主要特征
- 自主性（Autonomy）：每个智能体能够自主管理内部状态并决定自身动作，至少部分行为无需直接的人工干预。
- 局部视角与有限知识（Local Views）：单个智能体通常仅掌握自身状态与局部环境信息，无需了解系统全貌，全局任务依靠跨智能体的信息交换完成。
- 分布式控制（Decentralized Control）：控制权可分散在多个智能体之间，由交互共同决定系统走向；若架构中设置了管理者（Manager / Supervisor）角色，则由其承担协调与集中派发职责。
这些特征使多智能体系统可能出现自组织和复杂的涌现行为。集体行为可能超出各个智能体独立行为的简单相加，因此这种系统适合某些类型的问题，也成为讨论 AI 未来发展的重要方向。
得益于上述特征，多智能体系统能够展现出超越个体简单叠加的自组织与涌现协作能力。例如在自动化立体仓库中，多架配送无人机各自负责提取和运送包裹，只需通过局部避障决策以及与调度智能体或相邻无人机通信，即可协同优化全局物流路线，无需让单架无人机掌握全仓所有包裹的完整计划。而在基于 LLM 的现代系统中，不同智能体更可结合复杂推理、自然语言协商与专业工具各司其职——当单个智能体难以招架任务复杂度或效率低下时，多实体协作便成为自然的架构演进方向。
基于 LLM 的现代智能体还能够在各自角色中使用复杂推理、自然语言和学习策略。例如，一个智能体理解指令、制定计划或归纳资料，再与其他智能体共同完成复杂任务。当单个智能体或程序不足以完成任务，或者效率较低时，多实体协作可以成为适当设计。
为什么以及何时使用多智能体系统
将复杂问题拆解给多智能体系统处理具有多项工程优势：
- 分布式并行问题求解：将大型复杂任务拆分为多个子任务并行交由专门智能体处理（例如旅行规划可拆分为天气查询、航班搜索与酒店预订三个并行子任务，最后汇总为完整行程），既能缩短总耗时，也便于为每个子问题选用最契合的处理策略。
- 专业化分工（Specialization）：每个智能体可针对特定角色定制专属提示词、知识库与工具，并按任务难度匹配不同规模的模型（例如用强推理大模型负责意图理解与全局规划，用轻量模型或确定性算法负责算术计算与数据库查询）。
- 模块化与高可维护性：各智能体职责边界清晰。新增业务能力时只需挂载新智能体，修改局部逻辑时影响范围可控；排障与测试也可直接定位到具体负责的智能体，无需在一段包罗万象的巨型提示词中大海捞针。
- 降低单个智能体的复杂度：过多工具和指令可能增加 LLM 的处理负担，使工具选择错误或幻觉增多。职责明确、只配置两个相关工具的智能体，通常比同时选择十个工具和多类任务更容易保持可靠。较小的提示和上下文也更便于管理，有助于减少信息混淆和误用。
- 稳健性与交叉容错：当某个智能体执行失败或产生偏差时，其他智能体（或监督智能体）可通过交叉核查及时发现问题，重新派发任务或切换备选策略，降低单点故障导致全局崩溃的风险。
- 良好的水平扩展性：随着业务需求增长，可按需向团队中添加新的专家智能体（如在现有电商助手中新增一个独立的“关联商品推荐智能体”），最大限度减少对既有模块的改动。
- 天然契合分布式业务环境：面对跨地域仓库管理、买卖双方自动谈判等天然存在多个独立参与方或分布式数据源的场景，MAS 能够直观映射真实世界的实体及其交互关系。
当任务能够自然划分为由独立参与者处理的子任务或领域，或者单智能体开始遇到复杂度和可靠性限制时，可以考虑 MAS。一个智能体同时回答问题、计算、查询数据库和控制设备，可能意味着划分角色更有帮助。尤其适合以下情况。
- 任务横跨截然不同的数据源与技能域（如个人助手需同时完成网页深度调研、财务核算与邮件起草）。
- 工作流包含复杂的多阶段串行或并行协作（如将“规划、执行、验证”分别交由不同智能体或子团队负责）。
- 运行环境本身就是分布式的或包含多个独立主体（如经济与交通仿真、跨多台服务器的分布式网络监控）。
- 业务对容错与可靠性要求较高，且团队愿意承担额外的多组件编排与运维成本。
- 属于长期演进的大型项目，需要通过拆分多个小型专家智能体来保持系统的可扩展性与可维护性。
反之，若单个智能体或简单的固定工作流已能稳定解决问题，盲目引入多智能体只会徒增通信开销与调试复杂度——工程设计应始终遵循 KISS（保持简单）原则，按需演进。
多智能体系统如何工作：架构与通信
设计 MAS，需要确定智能体如何组织和通信，并使它们能够协调操作以完成整体目标。
1. 组织拓扑：集中式、分布式与混合架构
- 集中式架构（Centralized）：由一个或少数管理者/监督者（Manager / Supervisor）智能体负责全局统筹，承担任务拆解、指令派发、信息中转与结果汇总；其余智能体作为执行者或领域专家（Specialists）向管理者汇报。这种结构协调逻辑直观、便于把控全局决策，也是目前基于 LLM 的系统最常采用的层级监督模式（如众多 Deep Research 系统均由顶层 Supervisor 拆解课题、交由多个 Specialist 智能体分头研究后再汇总成文）；缺点是中央节点一旦故障或达到吞吐瓶颈，就会阻塞整个系统。
- 分布式架构（Decentralized）：各智能体地位平等，无中央控制节点，完全通过点对点通信与预设协商协议开展协作（常见于网络路由、群体机器人及高容错系统）。其扩展性与容错性较好，但缺乏全局协调者时更难保证系统整体行为的一致性。
- 混合架构：结合两者，例如每组智能体有局部负责人，或者中央智能体负责部分决策，其余由成员协商。多层级管理结构也是常见形式，包括管理者、下一级管理者及执行者。
基于 LLM 的系统常使用层级监督模式。顶层 Supervisor Agent 将用户请求或复杂任务划分为若干部分，交给对应 Specialist Agents。每个专家智能体在自己的领域内相对独立地完成任务，监督者再汇集为最终结果。许多 Deep Research 系统也采用类似结构。
2. 通信方式、互操作协议（A2A）与冲突协调
无论采用哪种拓扑，智能体之间都需要交换信息、请求协助与同步状态，主要通过两种方式通信：
- 直接消息传递（Direct Messaging）：一个智能体直接调用另一个智能体的函数、API 或网络接口发送结构化消息（同一进程内可直接传递 Python 字典或对象；跨进程/跨服务则通常通过 HTTP 发送包含任务与上下文的 JSON 请求，类似微服务调用）。这种方式要求通信双方知晓彼此的寻址位置并约定统一的消息格式。
- 通过共享环境间接通信（Indirect Communication）：各智能体不直接点对点通信，而是共同读写同一个持久化数据存储或共享状态（如经典的“黑板模型” Blackboard / Shared Scratchpad）——发送方将阶段性信息或待办任务写入共享记忆，其他关注该状态的智能体监听并读取更新，从而实现发送方与接收方的寻址解耦。
通信设计需要规定消息结构或协议。现代 LLM 智能体常通过 HTTP 等网络协议发送 JSON，例如向服务端点提交包含任务和上下文的消息。同一进程内的智能体，也可以直接调用函数或方法，传递 Python 字典或对象。
在跨框架互操作方面，当系统中同时存在基于 LangGraph、LangChain、CrewAI 或不同编程语言实现的智能体时，需要一套统一的通信标准。A2A（Agent-to-Agent）协议通过标准化的 API 与消息 schema 描述智能体能力与交互格式：只要遵循 A2A 规范，用 Python 和 LangGraph 编写的监督者智能体就可以直接向用 CrewAI 或其他语言编写的专家智能体派发任务并接收结果，让团队能够为不同角色自由选用最趁手的框架。
例如，监督者使用 Python 和 LangGraph 实现，某个专家则使用其他框架或语言。只要双方通过符合 A2A 规范的接口交换结构化消息，监督者就可以提交任务并接收结果。将智能体放在统一 API 后面，有助于为各角色选择适当工具，而无需全部使用同一框架。
MAS 还需要协调和冲突处理机制。存在依赖的任务应按正确顺序执行，目标冲突需要协调，共享资源修改也需要防止碰撞，例如两个智能体同时更新同一数据库记录。这些问题涉及多智能体规划、协商协议和共享记忆管理。在合作型助手中，监督者可以负责安排适当任务及时间；更分散的系统可能需要共识、负责人选举或事务机制。多智能体带来能力与灵活性，也需要仔细设计协作方式。
实战案例：商品研究助手的多智能体实现
可以将课程中的购物助手扩展为多智能体系统：除浏览商品及查询评论外，还支持管理购物车和下单。这涉及不同任务和数据来源，适合研究多智能体设计。
我们可以将课程中的电商购物助手扩展为多智能体系统，使其除了浏览商品与检索评论外，还能管理购物车并处理结账配送。例如，用户可能连续提出复合需求：“帮我找一款 500 美元以内、电池续航长的相机” → “看看其他买家对这款相机续航的评价” → “把它加入购物车” → “下周二之前能送到吗？”。
可以为单个智能体配置库存、评论、购物车和下单工具，但随着职责增加，提示需要说明越来越多的操作和数据，出错概率也可能增加。采用专门智能体协作，可以更清楚地组织这些能力。
购物助手中的智能体角色
- Product Inventory Agent（商品库存智能体）：负责检索商品目录向量库，获取商品名称、价格、规格参数，并通过对接仓库数据的工具核查实时库存余量。
- Reviews Analysis Agent（评论分析智能体）：负责处理买家评分与评论文本。当用户询问某款相机的续航表现时，定向检索相关评论并调用 LLM 提炼优缺点与情感倾向。
- Shopping Cart Management Agent（购物车管理智能体）：负责操作购物车数据库，执行加购、移除商品、修改数量或推荐搭配配件，并向用户返回最新的购物车清单确认。
- Ordering / Checkout Agent（订单与结账智能体）：负责处理结账、配送时效核算与仓库路由（例如当用户询问“周二前能否送达”时，核查收货地配送方式与各仓库库存分布；实际支付环节则交由受保护的外部安全支付流程完成，测试环境下对接专用测试桩）。
- Recommendation Agent（可选，推荐智能体）：根据当前购物车内容或历史查询记录，利用推荐算法或协同过滤实现交叉销售推荐。
Supervisor / Orchestrator Agent（监督/编排智能体）：可直接由面向用户的顶层 Shopping Assistant 担任，负责解析用户请求并委派给对应的专家智能体。面对“找一款评分高且低于 500 美元的相机，有货就加购并告诉我何时送达”这类跨领域请求时，由监督者按序调度“库存检索 → 评论核查 → 加入购物车 → 配送估算”，并维护全局对话状态。
框架选型与互操作小结
在工程框架选择上，LangGraph 提供了细粒度的状态图与条件边控制，适合定制复杂、严谨的工作流；CrewAI 则提供了直观的“角色（Role）”与“团队（Crew）”高层抽象，便于快速搭建角色协作流程。二者亦可结合使用，并通过 A2A 等标准协议实现跨框架互操作。
这一领域持续出现新的流程管理工具、标准接口和实践方法，帮助构建可靠的多智能体 AI 系统。
企业知识助手的多智能体分工
在课程企业知识助手场景中，可按文档读取、权限检查、向量检索与答案审核划分智能体协作角色。各角色之间共享明确的资料 ID（source_id）与语料版本号，而权限校验始终由独立的权限服务强制执行。商品研究类练习可继续使用Sprint 0《Amazon 电子产品类别数据集概览》的公开数据集；若涉及真实库存查询与交易下单，则必须另行接入具备正式业务授权的后端接口。
练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。