什么是多智能体架构？
您可能最近在不同的开源项目或专注于 GenAI 的供应商中听到过“智能体”这个词。的确，虽然大多数 GenAI 应用程序目前都专注于 RAG 应用程序，但人们越来越有兴趣将可以通过更专业的模型完成的任务隔离到所谓的“智能体”中。
明确地说，智能体将被赋予一个任务（可能是一个提示），并通过利用其他模型、数据源和知识库来执行该任务。根据应用领域，结果最终应类似于生成的文本、图片、图表或声音。
现在，多智能体架构是指通过以下方式围绕给定任务利用多个智能体的过程：
- 利用多个智能体协调复杂的系统监督
- 利用战略推理进行实时分析和制定策略
- 专业化智能体，将任务分解为更小的、专注于专家的元素
- 共享见解以制定有凝聚力的行动计划，创建协作动态
简而言之，多智能体架构的超能力是解决超越人类速度的复杂挑战并解决复杂问题。它可以实现以下几件事：
- 随着数据和复杂性的增长，扩展智能。任务被分解为更小的工作单元，专家网络也相应增长。
- 协调跨系统的同时行动，扩展协作
- 随着数据的发展，允许通过新数据进行持续适应，从而做出最前沿的决策。
- 可扩展性、高性能和弹性
单智能体与多智能体架构
在深入探讨多智能体架构之前，让我们先谈谈单智能体架构。单智能体架构专为简单任务和最终用户的后期反馈循环而设计。有多个单智能体框架，例如 ReAct（推理+行动）、RAISE（ReAct+短期/长期记忆）、Reflexion、AutoGPT+P 和 LATS（语言智能体树搜索）。这些架构支持的通用流程如下：
智能体采取行动、观察、执行并自行决定是否完成，如果完成则结束该流程，否则将新结果作为输入操作重新提交，该流程将继续进行。
虽然简单任务使用这种类型的智能体还可以，例如用户会提出问题，智能体根据 LLM 和知识库返回答案的 RAG 应用程序，但存在一些限制：
- 无休止的执行循环：智能体永远不满意输出，并不断重复。
- 幻觉
- 缺乏反馈循环或足够的数据来构建反馈循环
- 缺乏计划
出于这些原因，人们越来越需要更好的自我评估循环、外部化观察阶段和劳动分工，从而产生了对多智能体架构的需求。
多智能体架构依赖于获取复杂任务、将其分解为多个较小的任务、计划解决这些任务、执行、评估、共享见解并交付成果。为此，需要不止一个智能体；事实上，网络大小 N 的最小值是 N=2，包括：
- 一个管理者
- 一个专家
当 N=2 时，源任务足够简单，只需要一个专家智能体，因为该任务无法分解为多个任务。现在，当任务更复杂时，架构可能如下所示：
在 LLM 的帮助下，管理者分解任务并将解决方案委派给多个智能体。上面的架构称为垂直架构，因为智能体直接将其结果发送给管理者。在水平架构中，智能体作为一个小组一起工作并共享见解，使用基于自愿的系统来完成任务，它们不需要领导者，如下所示：
一篇很好的论文涵盖了这两种架构，并提供了更多见解，请访问此处：https://arxiv.org/abs/2404.11584
将垂直多智能体架构应用于可观测性
垂直多智能体架构可以有一个管理者、专家和一个沟通者。当这些架构将任务的结果暴露给最终用户时，这一点尤其重要。
在可观测性的情况下，我们在这篇博文中设想的是 SRE 运行根本原因分析 (RCA) 流程的场景。高级逻辑如下所示：
- 沟通者
- 读取来自人的初始命令
- 将命令传递给管理者
- 向人提供状态更新
- 向人提供建议的解决方案计划
- 将人的后续命令传递给管理者
- 管理者
- 读取来自沟通者的初始命令
- 创建工作组
- 将专家分配到组
- 评估来自专家的信号和建议
- 生成建议的解决方案计划
- 执行计划（可选）
- 专家
- 每个专家任务都具有与 Elastic 集成相关的独特专业知识
- 使用 o11y AI 助手来分类和排除与其专业知识相关的数据故障
- 根据需要与其他专家合作以关联问题
- 提供与其专业知识相关的建议根本原因分析（如果适用）
- 提供与其专业知识相关的建议解决方案计划（如果适用）
我们认为，在可观测性的情况下，按集成划分专家提供了足够的粒度，并允许他们专注于特定的数据源。这样做还会在接收涉及多个数据层（应用程序、网络、数据存储、基础设施）的复杂事件时，为管理者提供一个分解键。
例如，电子商务应用程序中的警报发起的复杂任务可能是“最近一小时收入下降了 30%”。此任务将提交给管理者，后者将查看所有涉及的服务、应用程序、数据存储、网络组件和基础设施，并将其分解为调查任务。每个专家将在其特定范围内进行调查，并向管理者提供观察结果。管理者将负责关联并提供有关问题原因的观察结果。
核心架构
在上面的示例中，我们已决定在以下软件架构上部署该架构：
- 代理管理器和专家代理部署在 GCP 或您喜欢的云提供商上。
- 大多数组件是用 Python 编写的。
- 需要一个任务管理层来将任务排队到专家。
- 专家代理根据集成/数据源进行专门部署，并与部署在 Kibana 中的 Elastic AI 助手进行对话。
- AI 助手可以访问实时上下文来帮助专家解决他们的任务。
- Elasticsearch 用作 AI 助手的上下文，并作为专家构建经验的记忆。
- 这里的后端 LLM 是 GPT-4，现在是运行在 Azure 上的 GTP-4o。
代理体验
代理体验是基于存储在 Elasticsearch 中的先前事件构建的，专家可以语义地查找类似的事件。当他们找到一个时，他们会获得存储在内存中的执行路径来执行它。
使用 Elasticsearch 向量数据库的优点在于，代理将能够对内存执行语义查询，以及如何管理内存本身。实际上，存在短期和长期记忆的概念，这在可观察性的情况下可能非常有趣，在可观察性中，某些事件经常发生，可能值得存储在短期记忆中，因为它们被更频繁地查询。较少查询但重要的事件可以存储在具有更高成本效益硬件的长期记忆中。
代理体验的另一个方面是 Elasticsearch 的语义重新排序功能。当代理执行任务时，重新排序用于显示与过去经验相比的最佳结果。
如果您正在寻找上述内容的实际示例，请查看这篇博文，其中 2 个代理与 Elastic Observability AI 助手一起在 RCA 上工作。