1. 项目概述：为什么我们需要关注多智能体架构模式？

在软件架构的演进长河中，我们经历了从单体到微服务的转变，核心驱动力是解耦与扩展。但当我们将视角从“服务”提升到“智能体”时，问题变得更加复杂和有趣。一个智能体（Agent）通常被定义为一个能够感知环境、自主决策并执行行动以达成目标的软件实体。当多个这样的智能体需要协同工作，共同完成一个更宏大、更复杂的任务时，如何设计它们之间的交互与协作结构，就成了决定系统成败的关键。这就是“多智能体架构模式”要解决的核心问题。

我见过不少团队在初次尝试构建多智能体系统时，容易陷入两个极端：要么将所有逻辑塞进一个“超级智能体”，导致其臃肿不堪、难以维护；要么随意创建多个智能体，让它们像无头苍蝇一样互相调用，最终陷入通信混乱和死锁的泥潭。这两种情况都源于对协作模式缺乏系统性的认知。实际上，经过学术界和工业界多年的实践，已经沉淀出几种经典、可复用的架构模式。理解这些模式，就像拥有了一张导航地图，能帮助我们在设计之初就避开深坑，构建出高效、稳定且易于演进的智能体系统。

本文将深入拆解五种最经典、应用最广泛的多智能体架构模式。我们不会停留在理论描述，而是结合具体的应用场景、技术选型考量以及我在实际项目中踩过的坑，为你呈现每种模式的“实战图景”。无论你是正在设计一个复杂的自动化业务流程，一个游戏中的NPC群体AI，还是一个分布式决策系统，这些模式都能为你提供坚实的理论基础和实用的设计蓝图。

2. 模式一：管理者-工作者模式

2.1 模式核心与运作机制

管理者-工作者模式，有时也被称为主从模式或领导-追随者模式，是最直观、最易于理解的一种分布式协作模式。在这个模式中，系统被清晰地划分为两类角色：一个或多个管理者，以及一群工作者。

管理者的核心职责是任务分解与调度。它接收外部的总任务，将其拆解成多个独立的、粒度更小的子任务。接着，它扮演着“调度中心”的角色，根据工作者的状态（空闲、忙碌、能力专长）和负载情况，将这些子任务分派给合适的工作者。此外，管理者还负责协调与监控，收集工作者的执行结果，处理可能出现的异常（如工作者失败），并在所有子任务完成后，汇总生成最终结果。

工作者则是纯粹的任务执行单元。它们从管理者那里领取任务，专注于执行具体的计算、推理或操作，并将执行结果（成功或失败）反馈给管理者。工作者之间通常没有直接的通信，它们只与管理者交互，这极大地简化了系统的通信拓扑。

一个生动的类比是“建筑工地的项目经理与工人”。项目经理（管理者）拿到设计蓝图（总任务），将其分解为砌墙、布线、装修等具体工序（子任务），然后指派给不同的工人团队（工作者）。工人团队只负责完成自己被指派的那部分工作，并向项目经理汇报进度。项目经理协调各团队进度，解决交叉作业冲突，最终交付完整的建筑。

2.2 典型应用场景与实战解析

这种模式在任务可并行化程度高、子任务间耦合度低的场景下威力巨大。

场景一：大规模数据处理与批量计算这是最经典的应用。例如，你需要处理TB级的日志文件，进行数据清洗、特征提取或模型推理。一个管理者智能体可以负责扫描文件目录、创建任务队列（每个文件或每个数据块为一个任务），然后将任务分发给部署在计算集群上的多个工作者智能体。每个工作者加载模型、处理数据，并将结果写回共享存储或直接返回给管理者。Apache Spark的Driver-Executor架构就是这一思想在大数据领域的成功实践。

场景二：并行仿真与测试在游戏开发或自动驾驶仿真中，需要同时运行成千上万个测试用例来评估AI策略。管理者智能体生成不同的测试场景（天气、交通密度、障碍物位置），并分发给大量工作者智能体并行运行仿真。工作者执行完毕后，将性能指标（如通过率、平均速度）反馈给管理者进行统计分析。

实战心得与工具选型：在实现时，消息队列（如RabbitMQ, Kafka, Redis Streams）是连接管理者与工作者的绝佳桥梁。管理者将任务作为消息发布到任务队列，工作者作为消费者订阅并处理。这种方式天然实现了解耦、异步和负载均衡。对于需要结果汇总的场景，可以设立一个专门的“结果队列”。

注意：管理者很容易成为系统的单点故障和性能瓶颈。务必为管理者设计高可用方案（如主备切换），并确保其逻辑足够轻量，主要承担调度而非重型计算。我曾在一个项目中，让管理者也参与了部分数据预处理，导致其CPU飙升，任务分发速度成为整个流程的瓶颈。后来将预处理逻辑下放到工作者，管理者只做纯调度，系统吞吐量立刻提升了数倍。

2.3 优势、局限与演进思考

优势：

1. 结构清晰，易于实现：角色分工明确，通信模式简单（星型拓扑），降低了开发复杂度。
2. 集中控制，全局可控：管理者拥有全局视图，便于实现统一的负载均衡、容错和优先级调度。
3. 动态扩展性强：可以随时增加或减少工作者数量来应对负载变化，对管理者透明。

局限：

1. 管理者单点瓶颈与故障风险：这是该模式最致命的弱点。管理者一旦宕机，整个系统将瘫痪。
2. 可扩展性受限于管理者：当任务数量爆炸式增长时，管理者的调度能力和网络带宽可能成为瓶颈。
3. 灵活性不足：所有协调逻辑都集中在管理者，工作者缺乏自主协同能力，难以应对需要复杂交互的突发情况。

演进方向：为了克服单点瓶颈，该模式可以自然演进为“多层管理者-工作者”或“管理者集群”。例如，引入一个顶层的“元管理者”，负责管理多个下层管理者，每个下层管理者管理一个工作者子集。这实际上是一种分治思想，将单点压力分散到多个节点上。另一种思路是让工作者在空闲时具备一定的任务窃取能力，从其他工作者的队列中“偷”任务来执行，这可以在一定程度上弥补管理者调度不均衡的问题。

3. 模式二：黑板模式

3.1 模式核心与协作哲学

如果说管理者-工作者模式是“中央集权制”，那么黑板模式就更像“圆桌会议”或“共享工作空间”。它的核心是一个共享的、结构化的数据存储——黑板。所有智能体（在这里通常称为“知识源”）都围绕这个黑板展开工作。它们不直接相互调用，而是通过读写黑板上的信息来进行间接的、异步的协作。

黑板中存储的是解决问题的中间状态、部分解或假设。整个系统的目标是通过知识源们的共同努力，逐步演化、精化黑板上的内容，最终得到问题的完整解。每个知识源都是某个领域的“专家”，它持续监控黑板上的内容。当黑板上出现符合其“专业领域”或“触发条件”的数据时，该知识源就会被激活，然后读取相关信息，进行处理，并将其推理结果或新的数据写回黑板。这个过程会激发其他知识源，从而形成一种链式反应或协作流。

一个经典的类比是“一群侦探破案”。案发现场（初始数据）和收集到的线索（中间数据）都贴在一个公共的白板（黑板）上。指纹专家、法医、心理侧写师、监控分析员（知识源）各自独立工作。当指纹专家在白板上贴出一枚指纹时，这可能触发了数据库比对员去查询嫌疑人档案；当档案被贴上白板，又可能触发心理侧写师进行行为分析。破案的过程，就是白板上信息不断丰富、交叉验证、最终指向真凶的过程。

3.2 典型应用场景与实战解析

黑板模式特别适用于那些问题域复杂、解决方案需要多领域知识融合、且解决路径不唯一的场景。

场景一：复杂信号处理与态势感知在军事或安防领域，需要融合雷达信号、红外影像、无线电侦听、开源情报等多种异构数据源，来构建战场或安防区域的综合态势图。每个数据源对应一个知识源智能体，负责处理原始数据并提取特征（如“雷达发现东北方向高速移动目标”、“无线电截获加密通信”）。这些特征被发布到黑板（共享态势库）。一个融合推理智能体监控黑板，当多种特征在时空上关联时，它可能推断出“疑似敌方无人机编队正在执行侦察任务”，并将这个高阶假设写回黑板，进而可能触发预警或反制系统的知识源。

场景二：自动规划与调度系统例如，物流公司的智能调度系统。黑板上的信息包括实时订单、车辆位置、路况、天气、仓库库存等。车辆路径规划知识源、负载优化知识源、风险预测知识源、客户优先级分析知识源等，都会根据黑板信息的变化而触发。它们各自贡献优化建议（如“为A车重新规划避堵路线”、“建议将B订单合并到C车的配送中”），写回黑板。最终，一个仲裁知识源综合所有建议，生成全局较优的调度指令。

实战心得与工具选型：实现黑板模式，技术核心在于“黑板”本身。它需要支持高效的并发读写、丰富的数据结构以及灵活的事件通知机制。

• 存储层：Redis因其丰富的数据结构（String, Hash, List, Set, Sorted Set）、高性能和Pub/Sub功能，成为实现黑板的绝佳选择。你可以用不同的Key来代表黑板上的不同信息区域。
• 事件驱动：知识源需要订阅其关心的数据变化事件。Redis Pub/Sub或更强大的消息中间件（如Kafka）可以用于实现“数据写入即通知”的机制。知识源作为消费者，监听特定主题（Topic），一旦有相关数据更新，就会被唤醒工作。
• 数据版本与冲突：在高并发下，多个知识源可能同时读写同一块数据区域，需要引入乐观锁（如Redis的WATCH/MULTI/EXEC）或数据版本号来避免更新丢失。

注意：黑板模式的设计难点在于“控制流”的隐式化。系统的行为不再由明确的调用链决定，而是由数据流和事件触发。这带来了巨大的灵活性，但也使得调试和追踪问题变得异常困难。你必须为黑板上的每一次关键数据变更和知识源的每一次激活做好详尽的日志记录，并构建可视化的数据流图，否则当系统行为异常时，你会像在迷宫里找路一样无助。

3.3 优势、局限与设计考量

优势：

1. 高度解耦与可扩展性：知识源之间互不知晓，仅通过黑板交互。新增一个知识源只需让其订阅感兴趣的数据，无需修改现有系统。
2. 支持不确定性推理与渐进求解：非常适合解决没有固定算法、需要试探和积累的问题。
3. 知识复用性好：每个知识源是独立的专家模块，可以在不同系统中复用。

局限：

1. 控制逻辑模糊，调试困难：系统的整体行为是涌现出来的，而非设计出来的，理解和控制复杂度高。
2. 全局一致性挑战：黑板作为共享状态，在分布式环境下维护强一致性成本很高，通常需要妥协为最终一致性。
3. 可能产生冗余计算：多个知识源可能对同一数据变化做出反应，产生不必要的计算，需要设计精巧的触发条件和控制策略来避免。

设计考量：在设计黑板系统时，必须精心设计黑板的数据模型（即“词汇表”），这是所有知识源协作的基础契约。同时，需要考虑知识源的激活策略：是持续监控还是事件触发？是并行执行还是需要仲裁序列？引入一个轻量级的“控制知识源”来管理协作流程、抑制无效触发，有时是必要的，但这又会让模式向“管理者”方向有所靠拢，需要在纯黑板和控制流之间找到平衡点。

4. 模式三：合同网协议

4.1 模式核心与竞标流程

合同网协议是一种模拟市场经济中招标-投标-中标过程的协作模式。它适用于动态、开放的环境中，任务需要分配给最合适的执行者。其核心流程是一个标准化的通信协议，包含以下几个关键阶段：

1. 任务公告：当一个智能体（称为管理者或招标者）产生了一个自己无法或不愿独立完成的任务时，它会向其他智能体广播一个“任务公告”。这个公告类似于招标书，包含了任务描述、截止时间、验收标准等。
2. 投标：接收到公告的智能体（称为投标者）评估自身的能力、当前负载和资源状况，决定是否投标。如果决定投标，它会向招标者发送一份“投标书”，其中包含它承诺的执行条件，如预计完成时间、所需成本、置信度等。
3. 中标与授予：招标者在截止时间后，评估所有收到的投标书，根据某种评标策略（如最快完成、最低成本、最高质量）选择一个或多个最优的投标者。然后，它向选中的投标者发送“中标通知”，正式将任务授予它。
4. 任务执行与结果汇报：中标者执行任务，完成后将结果汇报给招标者。招标者根据结果进行验收，可能涉及支付（在虚拟货币或信誉度体系中）或确认。

这个协议的精妙之处在于，它将资源分配和任务匹配从集中式调度转变为分布式协商。每个投标者都基于本地信息做出自私而理性的决策，整个系统通过这种市场机制达到一种高效的资源分配状态。

4.2 典型应用场景与实战解析

合同网协议在资源异构、环境动态、且追求整体效率最优的场景下表现出色。

场景一：云计算与边缘计算中的资源调度在混合云或边缘计算环境中，计算任务（如AI推理、视频渲染）需要被动态分配到不同的计算节点（本地服务器、公有云实例、边缘设备）。任务发布者（招标者）将任务需求（算力要求、内存、延迟敏感度、预算）广播出去。各个计算节点（投标者）根据自身的实时负载、资源空闲情况、网络状况和计价策略进行投标。调度中心（也可以是任务发布者自身）根据综合成本（经济成本+时间成本）选择中标节点。这比静态的资源分配策略更能适应负载波动和价格变化。

场景二：多机器人任务分配在一个仓库中，有多个搬运机器人。当一批新的货物到达需要分拣时，中央系统（或某个机器人）可以发布一系列搬运任务。每个机器人根据自己当前的位置、电量、载重能力以及到货架和目的地的距离，计算出一个“代价”，并向系统投标。系统选择总代价最低的一组投标方案，将任务分配给相应的机器人。这种方式实现了动态、自组织的任务分配。

实战心得与通信设计：实现合同网协议，通信的可靠性和时序是关键。通常需要借助一个可靠的发布-订阅消息系统（如MQTT with QoS， Kafka）来广播任务公告。投标和中标通知则通常使用直接的点对点通信（如gRPC, HTTP）。

评标策略是核心逻辑。最简单的策略是“最低代价”或“最早完成”。更复杂的策略可能考虑多个目标的权衡，甚至引入博弈论。例如，你可以设计一个“信誉度”系统，过去任务完成质量高的投标者会在评标中获得加分，以鼓励可靠的行为。

注意：合同网协议存在“通信开销大”和“决策延迟”的问题。每一次任务分配都需要经过多轮广播和响应，在智能体数量众多或任务发布频繁时，网络可能会被管理消息淹没。在实践中，通常不会为每一个微任务都走完整流程。可以采用“框架合同”的方式：招标者先通过一轮合同网选择一个合适的合作伙伴，然后在接下来的一段时间内，将一系列相关任务直接授予它，从而摊销通信成本。此外，设置合理的投标截止时间至关重要，太短可能错过优质投标者，太长则影响系统响应速度。

4.3 优势、局限与变体

优势：

1. 高度灵活与自适应：能动态适应节点加入、离开或能力变化，系统鲁棒性强。
2. 分布式决策：无需全局中心，每个节点基于本地信息决策，减轻了中心压力。
3. 支持异构资源：天然适合将不同能力、不同成本的节点统一纳入调度框架。

局限：

1. 通信与计算开销：协商过程产生大量消息，且每个投标者都需要进行任务评估计算。
2. 协商延迟：从公告到中标存在时间差，不适用于实时性要求极高的任务。
3. 可能陷入局部最优：基于当前信息的分布式决策，不一定能保证全局最优，可能存在“拜占庭将军”问题（恶意投标者提供虚假信息）。

常见变体：

• 迭代合同网：允许在中标后，中标者将任务的子任务再次通过合同网分包出去，形成多层分包结构。
• 基于信任的合同网：在评标中引入信任度或信誉度模型，优先选择历史合作良好的投标者。
• 联盟形成：针对一个复杂任务，多个投标者可以联合组成“联盟”共同投标，以承担单个节点无法完成的大任务。

5. 模式四：订阅-发布模式

5.1 模式核心与信息流设计

订阅-发布模式是一种基于事件和消息的松散耦合协作范式。它严格区分了信息的生产者和消费者。生产者（发布者）将消息发布到特定的主题，而不需要知道谁将接收这些消息。消费者（订阅者）则根据自身兴趣，订阅一个或多个主题，并接收所有发布到这些主题上的消息。两者通过一个中介——消息代理——进行连接，完全解耦。

在多智能体系统中，每个智能体既可以作为发布者，广播自己的状态、感知结果或决策；也可以作为订阅者，监听其他智能体或环境的事件，从而触发自身的后续行为。系统的协作逻辑，由消息流而非控制流来定义。

例如，在一个智能家居多智能体系统中，“人体传感器智能体”检测到有人移动，它向“客厅活动”主题发布一条消息。订阅了该主题的“灯光智能体”和“空调智能体”同时收到消息。“灯光智能体”判断是夜晚，于是打开灯；“空调智能体”判断当前温度高于设定值，于是启动制冷。两个智能体之间没有任何直接调用，但它们的行为通过消息主题的订阅关系实现了协同。

5.2 典型应用场景与实战解析

这种模式在事件驱动、需要广播通知或一对多通信的场景中极为高效。

场景一：物联网与数字孪生在工业物联网平台中，成千上万的设备传感器持续产生数据。每个传感器代理智能体将数据发布到以设备ID和数据类型命名的主题（如“factory/line1/motor42/temperature”）。监控智能体、预警智能体、数据分析智能体分别订阅它们关心的主题组合。当温度超过阈值时，预警智能体收到消息立即触发告警；数据分析智能体则将所有温度数据存入时序数据库用于长期分析。数字孪生体智能体订阅所有相关主题，实时更新虚拟模型的状态。

场景二：微服务间的事件通信在微服务架构中，各个服务可以通过发布领域事件来协同。例如，“订单服务”在创建订单后，发布一个“OrderCreated”事件。订阅了该事件的“库存服务”会扣减库存，“支付服务”会发起支付流程，“通知服务”会发送确认邮件。这避免了服务间的直接HTTP调用链，提高了系统的可扩展性和容错性。

实战心得与中间件选型：选择合适的消息代理是成功的关键。主流的选项包括：

• MQTT：轻量级、为物联网设计的协议，支持低带宽、高延迟网络，提供三种服务质量等级，非常适合设备间的通信。
• Apache Kafka：高吞吐、分布式、持久化的日志流平台。它不仅仅是一个消息队列，更是一个流数据平台，适合构建实时数据管道和流式应用。它强调消息的顺序性和持久性。
• Redis Pub/Sub：非常简单易用，但消息是“即发即弃”的，没有持久化，订阅者离线时会丢失消息，适合对可靠性要求不高的实时通知场景。
• RabbitMQ：功能丰富的企业级消息队列，支持复杂的路由规则（Exchange），消息确认和持久化机制完善。

注意：订阅-发布模式最大的挑战是“系统可观测性”和“事件风暴”。由于发布者和订阅者解耦，当系统行为异常时，追踪一个事件是如何产生、流转并最终导致某个结果的，会非常困难。你必须建立完善的事件溯源和日志关联机制，给每一条消息赋予唯一的追踪ID。另外，设计不合理的事件主题粒度可能导致“事件风暴”——一个微小状态变化触发大量事件，进而导致连锁反应，使系统不堪重负。主题设计应遵循“高内聚、低耦合”原则，按业务领域或变更频率进行合理划分。

5.3 优势、局限与架构融合

优势：

1. 极致的解耦：发布者和订阅者生命周期独立，技术栈独立，可以独立部署和扩展。
2. 动态性与灵活性：可以随时增加新的订阅者来响应已有事件，无需修改发布者。
3. 可扩展性高：消息代理可以集群化，轻松应对高并发消息流量。

局限：

1. 数据一致性最终化：由于是异步通信，订阅者接收到消息时，系统的状态可能已经再次发生了变化，通常只能保证最终一致性。
2. 调试与测试复杂：缺乏明确的调用链路，集成测试和问题排查难度大。
3. 对消息代理依赖重：消息代理的可用性和性能直接决定了整个系统的可用性和性能。

架构融合：订阅-发布模式很少单独构成一个完整的多智能体架构，它更多是作为一种基础的通信机制，被其他模式所使用。例如，在黑板模式中，知识源订阅黑板数据变化的事件；在合同网协议中，任务公告可以通过发布-订阅来广播。它就像智能体世界的“神经系统”，负责信息的快速传递，而更上层的模式（管理者-工作者、合同网等）则定义了智能体之间如何利用这些信息进行有意义的协作。

6. 模式五：联盟与协作规划

6.1 模式核心与协同进化

联盟与协作规划模式代表了多智能体协作中更高级、更紧密的形式。它不再是简单的任务分发或事件响应，而是多个智能体为了完成一个共同的、复杂的、长期的目标，主动地组成一个临时或长期的联盟，并进行联合规划与协同行动。

在这个模式中，智能体需要具备更高的“社交”能力：

1. 联盟形成：智能体们通过协商、投标或基于信任度的选择，动态形成一个合作团队。这个团队内的智能体能力互补，共同承担一个单一个体无法完成的大任务。
2. 联合规划：联盟成员需要共同制定一个行动计划。这涉及到任务分解、资源分配、时序安排和依赖关系处理。规划过程可能需要多次协商和妥协。
3. 协同执行与再规划：按照联合计划执行任务。在执行过程中，需要保持紧密的通信以同步状态，当遇到意外（如成员故障、环境变化）时，能够动态地重新规划。

一个典型的例子是“灾难救援多机器人系统”。地震后，需要完成搜救、测绘、运输等任务。一个飞行机器人（擅长快速侦查）和一个地面机器人（擅长精细操作）可能组成联盟。飞行机器人先进行全局扫描，将高价值目标位置共享给联盟。然后它们共同规划：飞行机器人引导地面机器人抵达目标，地面机器人进行生命探测和初步救援，飞行机器人则负责向后方传输实时画面并请求支援。这是一个动态、紧密的协同过程。

6.2 典型应用场景与实战解析

这种模式适用于任务高度复杂、需要深度分工协作且环境动态变化的场景。

场景一：自动驾驶车队协同在高速公路上，多辆自动驾驶卡车可以组成一个“紧密跟车”队列。头车负责破风和对主要路况进行感知，跟随车辆可以减小风阻，节省能源。它们需要组成联盟，协商队列次序、跟车距离、速度策略。当需要换道或应对突发路况时，联盟内部需要进行快速的协同决策和轨迹规划，确保整个车队的安全和效率。这远超过简单的车辆间通信，需要一套完整的联盟管理和协同控制算法。

场景二：分布式制造与供应链协同在智能工厂中，接到一个紧急订单，需要快速生产一批定制化产品。负责不同工序的智能体（物料调度、3D打印、机械臂装配、质量检测）需要迅速组成一个临时生产联盟。它们需要共同规划生产排程：物料何时到位？打印和装配如何衔接？检测工位何时空闲？联盟内部需要实时交换生产进度和资源状态，动态调整计划以应对物料延迟或设备故障等扰动。

实战心得与关键技术：实现这一模式，对智能体的“心智”能力要求最高，通常需要整合多种AI技术：

• 通信与协商协议：需要定义一套丰富的Agent通信语言，如FIPA ACL，用于表达提议、接受、拒绝、修改等语义。
• 联合意图与共享计划：智能体间需要建立“共同信念”和“联合意图”。可以使用基于BDI模型或共享计划理论来形式化描述。
• 分布式规划算法：如部分全局规划、市场导向规划等。智能体各自生成局部计划，然后通过交换约束和效用信息进行协调，迭代出一个全局可接受的联合计划。
• 信任与信誉模型：在开放的动态环境中，智能体需要评估潜在合作伙伴的可靠性，这需要一套去中心化的信誉管理系统。

注意：联盟与协作规划是计算和通信开销最大的模式。联合规划本身就是一个复杂的优化问题，在动态环境中可能需要进行频繁的再规划，这对系统的实时性构成巨大挑战。在实际工程中，往往需要做大量简化。例如，将联合规划问题分解为层次化结构：先由一个“联盟领导者”进行粗粒度任务分配（类似管理者），然后联盟成员在各自子任务内进行细粒度的本地规划。另一个常见问题是“社会困境”，即个体理性与集体理性的冲突。需要设计合理的激励机制或惩罚机制，确保智能体在追求自身利益的同时，也愿意为联盟的整体目标做出贡献。

6.3 优势、局限与未来展望

优势：

1. 解决复杂问题的能力最强：能够应对单个智能体知识、资源、能力不足的宏大目标。
2. 灵活性与鲁棒性：联盟可以动态重组以适应任务和环境变化；成员故障时，联盟可以重新调整计划或招募新成员。
3. 资源利用全局优化：通过深度协同，可以实现资源（时间、算力、物理资源）的全局优化配置。

局限：

1. 系统复杂度极高：设计、实现和调试难度远超前几种模式。
2. 协商与规划开销巨大：达成一致可能需要多轮复杂的通信和计算，不适合实时性要求极高的场景。
3. 对智能体个体能力要求高：要求智能体具备模型他者、推理协商、复杂规划等高级认知能力。

未来展望：随着大语言模型等基础模型的发展，为智能体赋予了更强的自然语言理解和任务分解能力。未来的多智能体协作系统，可能会呈现“大模型赋能的协作规划”形态。LLM可以作为每个智能体的“大脑”，帮助其理解复杂任务指令、生成合作提议、甚至模拟其他智能体的意图，从而极大地降低协商和联合规划的成本。同时，区块链技术可能被用于建立去中心化、可验证的信任和合约机制，为开放环境下的联盟形成提供新的基础设施。这个模式正从实验室走向产业，是构建真正自主、智能的群体系统的关键路径。