大型语言模型构成单个智能体的核心，并且常采用特定的架构模式。然而，将这些智能体组合成一个可用的多智能体系统（MAS）会带来一系列不同的设计和部署障碍。让多个LLM驱动的实体进行互动、协作或竞争本身就会引入操作上的复杂性，这些复杂性在单独考虑智能体时通常不明显。提前了解这些挑战对于构建有弹性和高效的多智能体LLM应用非常重要。这些系统不仅仅是单智能体应用的放大版本；它们具有特有的属性和故障模式，需要特别关注。
涌现 (emergence)行为与不可预测性
多智能体LLM系统的一大难题是管理涌现行为。这指的是由多个自主智能体互动而产生的系统层面行为，这些行为并未明确编程，且难以预测。LLM本身固有的非确定性（即使在低温设置下）以及复杂的内部推理 (inference)过程，都会加剧这种不可预测性。当多个此类智能体互动时，可能的状态和互动路径的组合性爆发可能导致意想不到、有时不理想且通常难以重现的结果。调试追踪分布式因果关系变得不简单，这通常因LLM决策过程的不透明性而变得模糊。例如，两个LLM智能体之间的协商可能会停滞不前或导致次优协议，这可能是由于措辞或推断意图的轻微变化所致，这些变化难以预料。
通信与协调开销
高效通信是MAS中协作的基础，但它会带来可观的开销，尤其是在LLM智能体中。
- 延迟： LLM之间的通信通常涉及生成文本、传输文本，然后由接收LLM解析/解释文本。每一步都会增加延迟，这在多轮对话或复杂工作流程中会累积。
- Token消耗： 当智能体通过提示其他LLM进行通信时（一种常见模式），每次消息交换都会消耗Token，直接影响运行成本。冗长的通信协议或频繁的互动会迅速提高这些成本。
- 语义模糊： 尽管LLM擅长自然语言，但生成消息的准确含义仍可能模糊不清。要确保智能体按预期解释通信内容，不产生误解或“幻觉 (hallucination)”细节，需要对消息生成和解释进行细致的提示工程 (prompt engineering)，并可能需要在自然语言中或其旁边嵌入 (embedding)结构化数据交换格式（例如JSON）。
- 网络复杂性： 在一个包含 N 个智能体的系统中，全连接网络中潜在的直接通信路径数量为 N(N−1)/2。管理这些连接、确保消息传递以及处理通信故障，随着智能体数量的增加而变得越来越复杂。
某个全连接五智能体系统中的通信路径。连接数量随智能体数量二次增长，凸显了通信管理潜在的扩展问题。
知识一致性与连贯性
在多智能体系统中，智能体可能基于不同的信息源运行，接收不同的输入，或对共享信息有不同的理解。这可能导致知识缺乏一致性，即智能体拥有相互冲突的信念或过时信息。维护对任务或环境的一致性共享理解是一大难题。例如，一个智能体可能会根据新的信息更新其知识，但如果此更新未能有效传播并与其他智能体的知识达成一致，系统可能会行为异常或效率低下。这类似于分布式数据库中的陈旧数据问题，但由于LLM的解释层而变得更为复杂。
错误传播与级联故障
LLM容易产生“幻觉 (hallucination)”，或以高置信度生成事实不准确的信息。在多智能体系统中，源自单个LLM智能体的错误可能通过网络传播，潜在导致级联故障。如果智能体A生成了一条有缺陷的信息，而智能体B接受并将其用作任务输入，那么智能体B的输出也很可能有缺陷。这个有缺陷的输出随后可能被智能体C使用，以此类推。识别这种链式错误的原因可能极其困难，因为问题可能在其源头很远的地方才表现出来。系统的整体可靠性取决于检测、缓解和隔离此类错误的机制，这比在单LLM应用中更为复杂。
LLM引起的错误传播。智能体1最初的误解产生了一个缺陷洞察，该洞察被传递给智能体2，导致智能体3执行了一个错误计划，最终产生了错误的系统输出。
可扩展性与资源管理
随着系统中智能体数量的增加，对计算资源、API速率限制和预算的需求也随之增加。
- 成本： 每次LLM调用都会产生费用。如果未仔细设计以实现成本效益，一个拥有数十或数百个智能体频繁执行LLM推理 (inference)的系统可能会变得极其昂贵。
- API速率限制： LLM提供商会对API调用施加速率限制。多智能体系统很容易达到这些限制，尤其是在活动高峰期，这需要精密的排队、重试机制，以及可能的分布式API密钥管理。
- 状态管理： 追踪和管理大量智能体的状态、它们正在进行的任务以及它们的互动历史，可能成为一个复杂的分布式系统问题。集中式状态管理可能成为瓶颈，而去中心化方法则带来了数据一致性挑战。
- 并发与并行： 有效协调多个智能体并行工作，管理它们任务间的依赖关系，以及避免竞争条件或死锁，需要细致的架构规划。
系统级提示工程 (prompt engineering)与管理
尽管单个智能体的提示工程是一门艺术和科学，但管理整个多智能体系统的提示则增加了另一层复杂性。
- 相互依赖的提示： 一个智能体的输出，由其提示塑造，通常会成为另一个智能体提示的输入。对一个提示的更改可能产生连锁反应，需要调整系统中的其他提示以保持预期行为。
- 角色定义一致性： 提示定义了智能体的角色、能力和约束。确保这些定义在系统范围内保持一致，并共同为整体目标做出贡献而无重叠或遗漏，并非易事。
- 动态提示： 在某些系统中，可能需要根据互动演变的环境动态生成或调整提示。管理这些动态提示模板并确保其可靠性增加了工程工作量。
- 版本控制与测试： 多智能体系统的一套提示是一项重要资产。对这些提示集进行版本控制、测试其集体行为并系统地推出更新，对于可维护性非常重要。
评估与调试挑战
衡量多智能体LLM系统的有效性并诊断问题，远比单智能体系统困难。
- 整体性能指标： 定义有意义的性能指标，不仅要衡量单个智能体的表现，还要体现系统的集体成功和效率，这是一项挑战。
- 贡献归属问题： 当多智能体系统在任务中成功或失败时，将结果归因于特定的智能体、互动或提示组件（即“贡献归属问题”）是困难的。这使得确定改进点变得不易。
- 可重现性： LLM的非确定性特性可能使重现特定的系统行为变得困难，从而使调试工作复杂化。即使使用固定的种子和温度，也可能发生微小差异。
- 可观测性： 获取多个互动LLM内部“推理 (inference)”过程的理解，需要全面的日志记录、追踪和针对MAS定制的可视化工具，这些工具仍在发展中。
多轮对话中的上下文 (context)窗口限制
LLM在有限的上下文窗口中运行。在智能体之间的长时间互动中，或当智能体需要参考大量之前的交流历史时，对话历史很容易超出此限制。
- 信息丢失： 简单截断历史会导致信息丢失，可能损害智能体保持连贯性或回忆相关过往细节的能力。
- 摘要复杂性： 实施摘要策略以压缩对话历史需要额外的LLM调用（增加成本和延迟），并存在在摘要过程中丢失重要细节或引入偏见的风险。
- 检索增强生成（RAG）开销： 集成外部知识库或向量 (vector)存储以提供长期记忆或访问信息源会增加架构复杂性和检索延迟。确保检索到的上下文与智能体当前提示相关并良好集成是另一项工程任务。
应对这些固有复杂性需要系统性的设计方法、工程实践，以及对LLM能力和分布式系统原理的充分理解。本课程的后续章节将讨论应对这些挑战的具体策略和技术，帮助您构建更复杂、更可靠的多智能体LLM系统。
