从单一人工智能到多代理成功：系统架构的作用

人工智能正在以惊人的速度发展。重点已经从创建单一、强大的模型转向利用多个专业人工智能代理协调工作的潜力。想象一下，一个由技术娴熟的专业人员组成的团队，每个人都是各自领域的专家--一个负责数据分析，另一个负责与客户互动，第三个负责监督物流。真正的挑战和释放其全部潜能的关键在于实现他们之间的无缝协作。这一愿景经业界讨论，并通过现代平台得以实现，是真正的创新所在。

然而，实话实说：协调一群独立的、有时是不可预测的人工智能代理是一项巨大的挑战。困难不仅在于创建有效的单个代理，决定系统成败的还有中间错综复杂的协调。当代理相互依赖、异步运行并冒着独立故障的风险时，你就不仅仅是在编码，而是在指挥一曲复杂的交响乐。这就是为什么从一开始就必须制定可靠的架构计划，以确保可靠性和可扩展性。

代理协作的复杂挑战

为什么协调多代理系统如此困难？请考虑以下因素：

1. 独立性：与标准程序功能不同，代理通常有自己的内部流程、目标和状态。它们不会简单地等待命令。
2. 复杂的通信：这不是两个代理之间的简单对话。代理 A 可能会播报代理 C 和 D 需要的信息，而代理 B 则会等待代理 E 的提示，然后再通知代理 F。
3. 共同理解（状态）：所有代理如何就当前的真实情况达成一致？如果代理 A 更新了一条记录，代理 B 如何才能可靠、快速地了解这条记录？过时或相互矛盾的数据会严重干扰运行。
4. 不可避免的故障：代理可能会崩溃，信息可能会丢失，外部服务可能会超时。当一个组件出现故障时，整个系统不应该停止运行，更不应该错误运行。
5. 一致性挑战：确保涉及多个代理的多步骤流程得出有效结论非常复杂，尤其是在分布式和异步操作的情况下。

实质上，随着代理和交互的增加，潜在的复杂性也会呈指数级增长。如果没有可靠的策略，调试就会变得力不从心，系统也会感觉不稳定。

选择协调策略

确定代理如何协调工作是最关键的架构决策之一。以下是几种常见的框架：

• 指挥（分层模式）：类似于传统的管弦乐队，由一个中央指挥（指挥）指挥流程，指示特定代理（音乐家）何时行动，并协调整体演出。
  • 优点工作流程清晰，易于执行跟踪，控制简单明了；适用于规模较小或动态性较弱的系统。
  • 缺点：指挥可能成为瓶颈或单点故障。这种方法为动态反应或自主代理工作提供的灵活性较低。
• 爵士乐团（联合/分散模式）：在这里，代理根据共享信号或既定规则直接相互协调，就像爵士乐手围绕一个共同主题即兴演奏一样。可能存在共享资源或事件流，但没有中央管理者来支配每个行动。
  • 优点复原力（如果一个代理出现故障，其他代理可以继续工作）、可扩展性、对变化的适应性，以及突发行为的潜力。
  • 考虑因素：理解整个流程可能很困难，调试也很复杂（"为什么那个代理在那一刻采取行动？"），保持全局一致性需要精心设计。

现实世界中的许多多代理系统（MAS）都采用了一种混合方法--或许由一个高层次的协调者来搭建舞台，而代理群则在该结构内以分散的方式进行协调。

管理集体智慧（共享状态）

为实现有效协作，代理通常需要对世界有一个共同的视角，或至少是与其任务相关的方面。这可能包括客户订单的当前状态、共享知识库或实现目标的集体进展。在分布式代理之间保持这种 "集体智慧 "的一致性和可访问性是一个主要障碍。

主要的架构模式包括

• 中央图书馆（中央知识库）：所有共享信息所在的单一权威来源（如数据库或专用服务）。各代理可从中央知识库读取信息，也可向中央知识库写入信息。
  • 优点：单一真相源，简化一致性执行。
  • 缺点：请求过多，可能会降低性能或造成瓶颈。需要较高的稳健性和可扩展性。
• 分布式笔记（分布式缓存）：在中心库的支持下，代理维护常用信息的本地副本，以加快访问速度。
  • 优点数据检索更快。
  • 缺点：确保本地副本是最新的，这在架构上是一个重大挑战，涉及缓存失效和一致性机制。
• 广播更新（消息传递）：图书馆（或其他代理）通过消息宣布变化，而不是代理不断查询中央图书馆。代理会监听相关更新，并相应调整其本地数据。
  • 优点分离代理，支持事件驱动架构。
  • 缺点：保证消息传递和正确处理增加了复杂性。如果信息丢失会怎样？

最佳选择取决于需要精确到毫秒的准确性与实现最佳性能之间的平衡。

规划不可避免的情况：错误处理和恢复

代理故障只是时间问题，而不是是否发生的问题。您的架构必须预测并管理这些情况的发生。

主要考虑因素包括

• 看门狗（监督）：实施主要作用是监控其他代理的组件。如果某个代理反应迟钝或行为异常，看门狗就会尝试重启或向系统发出警报。
• 智能重试和闲置：如果代理的操作失败，它通常会重试。不过，这只有在操作具有惰性的情况下才会起作用，即多次执行与一次执行的结果相同（例如，设置一个值，而不是递增它）。非幂等操作会导致重试时出现严重问题。
• 清理（补偿）：如果代理 A 成功完成了任务，但代理 B（后续步骤）却失败了，您可能需要 "撤销 "代理 A 的工作。像 Sagas 这样的模式有助于管理这些多步骤、可补偿的工作流。
• 跟踪进度（工作流状态）：维护整个流程的持久日志很有帮助。如果系统在工作流中途出现故障，可以从最后已知的正确步骤重新开始，而不是从头开始。
• 遏制故障（断路器和隔板）：这些模式可防止一个代理或服务出现故障，从而限制影响范围。

确保任务准确完成

即使有可靠的单个代理，您也需要有信心确保整个协作任务正确、一致地完成。

需要考虑的策略

• 近原子操作：虽然真正的 ACID 事务对分布式代理来说具有挑战性，但您可以使用 Sagas 等模式设计工作流，使其尽可能以原子方式运行。
• 不可变日志（事件源）：将每个重要操作和状态变化作为不可变事件记录在日志中。这将提供完整的历史记录，简化状态重建，并有助于审计和调试。
• 达成共识：对于关键决策，代理可能需要达成一致后才能继续。这可能涉及简单的投票表决，也可能涉及用于高风险协调的更复杂的分布式共识算法。
• 验证结果（验证）：在工作流程中加入一些步骤，以便在代理完成任务后检查输出或状态。如果发现异常，则启动调节或纠正流程。

基本基础架构工具

强大的架构依赖于坚实的基础。

• 邮局（消息队列/代理，如 Kafka 或 RabbitMQ）：对解耦代理至关重要。它们向队列发送消息；感兴趣的代理消费这些消息。这可以实现异步通信，处理流量峰值，对弹性分布式系统至关重要。
• 共享文件柜（知识库/数据库）：这是您的共享状态所在。根据数据结构和访问模式选择合适的类型（关系型、NoSQL 型、图型）。该组件必须具有高性能和可用性。
• X-Ray Machine（可观察性平台）：全面的日志记录、度量和跟踪是必不可少的。众所周知，调试分布式系统非常困难。观察每个代理的操作、交互和时间的能力至关重要。
• 目录（代理注册表）：代理如何发现彼此或它们需要的服务？中央注册表有助于管理这种复杂性。
• 游乐场（容器化和协调，如 Kubernetes）：这就是如何可靠地部署、管理和扩展所有这些单个代理实例。

代理如何通信？

代理之间的通信方式影响着从性能到耦合程度的方方面面。

• 标准电话呼叫（REST/HTTP）：简单、普遍支持，适用于基本的请求/响应交互。不过，对于大流量或复杂的数据结构来说，它的效率可能不高。
• 结构化电话会议（gRPC）：使用高效的数据格式，支持包括流在内的各种调用类型，并且是类型安全的。性能优越，但需要预先定义服务合同。
• 公告板（消息队列--AMQP、MQTT 等协议）：代理向主题发布消息；其他人订阅感兴趣的主题。这种异步方法具有很强的可扩展性，并能将发送者与接收者完全分离。
• 直接线路（RPC - 不太常见）：代理直接调用其他代理的函数。这种方法速度快，但耦合紧密--代理必须清楚地知道要调用谁及其位置。

选择最适合交互模式的协议。是直接请求？广播事件？连续数据流？

将一切结合在一起

构建可靠、可扩展的多代理系统并不是要找到单一的完美解决方案，而是要根据具体要求做出明智的架构选择。是采用分层方法优先考虑控制，还是采用联合模式优先考虑弹性？如何管理关键的共享状态？代理故障的应急计划是什么？哪些基础设施组件不可或缺？

毫无疑问，任务是复杂的。但是，只要专注于这些架构蓝图--或协调交互、管理共享知识、规划故障、确保一致性，并在坚实的基础架构上进行构建--就能驾驭复杂性，开发出强大的智能系统，为下一代企业人工智能提供动力。

Nikhil Gupta 是 Atlassian 的人工智能产品管理负责人/员工产品经理。