应对代理团队的故障并保障可靠性

随着多代理LLM系统承担日益复杂的编排任务，它们的可靠性成为一个主要考量。在这些精密的流程中，单个代理、通信链接，甚至编排逻辑的一部分都可能出现故障。鉴于LLM系统固有的概率特性以及对外部工具或API的依赖，它们尤其容易受到多种问题的影响。解决这些挑战需要增强代理团队的弹性，概述检测、管理和从故障中恢复的方案，从而保障您的复杂工作流程能够稳定运行。

多代理系统中的故障可以在不同层面显现。了解这些潜在的薄弱点是制定对策的第一步。

代理系统中的常见故障点

• 代理层面的故障:

  • LLM的不可预测性: LLM偶尔会生成不相关、无意义（幻觉）、拒绝回答或严重偏离预期任务的输出。这是其概率生成所固有的特性。
  • 工具集成错误: 代理常依赖外部工具或API。这些工具可能因网络问题、API密钥问题、速率限制、API契约变更或工具本身的缺陷而失效。代理也可能因提供格式错误输入而误用工具。
  • 状态损坏: 代理的内部内存或状态可能因其逻辑中的缺陷或意外交互而损坏，从而导致错误行为。
  • 资源耗尽: 代理可能消耗过多内存或计算资源，导致其终止或速度变慢。

• 代理间通信中断:

  • 消息传递故障: 在分布式系统中，代理之间的消息可能丢失、延迟或乱序传递，特别是在不可靠的网络上或消息队列配置不当的情况下。
  • 超时: 如果接收代理响应缓慢或无响应，代理之间的同步请求可能会超时。
  • 序列化/反序列化错误: 如果数据格式不一致或损坏，代理可能无法正确解析来自其他代理的消息。

• 编排故障:

  • 工作流程死锁: 设计不当的工作流程可能导致代理无限期地相互等待。
  • 状态转换错误: 编排器可能错误地管理整个工作流程的状态，导致跳过步骤或提前终止。
  • 编排器故障: 如果使用集中式编排器，它的故障可能导致整个多代理系统停止运行，除非内置冗余。

• 外部依赖问题:

  • 第三方API中断: LLM提供商的API、向量数据库或其他外部服务等重要依赖项可能会出现停机。
  • 数据源不可用: 依赖特定数据库或知识存储的代理，如果这些源变得不可访问，将无法运行。

构建可靠的代理团队需要多方面的方法，包含代理层面的防御性编程、通信模式以及能够预测并处理故障的智能编排逻辑。

1. 设计有弹性的单个代理

第一道防线是使单个代理尽可能强大。

• 输入和输出验证: 严格验证代理接收的所有输入，无论是来自其他代理、外部源还是用户提示。同样，解析并验证LLM调用或工具执行的输出。对于LLM输出，这可能涉及检查预期结构（例如JSON）、关键词，甚至使用另一个LLM作为验证器。例如，如果代理期望从工具接收JSON响应，它应在继续之前验证其结构：

  # 代理输出验证的伪代码
  raw_output = llm.generate("...")
  try:
      parsed_output = json.loads(raw_output)
      if "expected_key" not in parsed_output:
          raise ValueError("Missing expected key in LLM output")
      # 进一步验证
  except (json.JSONDecodeError, ValueError) as e:
      # 处理格式错误或无效的输出
      log_error("LLM output validation failed", error=e)
      # 可能会重试或升级处理
  

• 带指数退避和抖动的重试机制: 对于瞬时故障，例如调用LLM API时的网络故障或工具暂时不可用，应实现重试逻辑。不要立即重试，而应使用指数退避来增加重试之间的延迟（例如，1秒、2秒、4秒、8秒）。添加抖动（在退避时间上增加少量随机时间）有助于防止许多实例同时重试导致的“惊群问题”。

  一个带有指数退避的简单重试逻辑流程。

• 超时: 为任何可能无限期阻塞的操作实现超时，例如等待LLM响应、工具执行或来自另一个代理的消息。这可以防止代理卡住并消耗资源。

• 幂等性: 设计代理操作，特别是那些修改状态或与外部系统交互的操作，使其具有幂等性。幂等操作可以执行多次，其效果与执行一次相同。这对安全的重试很重要。例如，一个“将任务X分配给代理Y”的命令，即使因重试而发送两次，也不应重复分配或导致错误。

2. 保障容错通信

通信是多代理系统的命脉；它的可靠性是根本。

• 消息队列: 对于异步通信，使用消息队列（例如RabbitMQ、Kafka、Redis Streams）提供持久性。消息会持久存储在队列中，直到代理成功处理它们。这解耦了代理，并在消费者代理暂时停机时防止消息丢失。

• 确认（ACKs）和否定确认（NACKs）: 当代理从队列中接收消息或收到直接请求时，它应该确认其成功处理（ACK）。如果处理失败，它可以发送NACK，可能触发重新投递或将消息移动到死信队列（DLQ）以供后续检查。

• 心跳和健康检查: 代理可以定期向编排器或监控服务发送心跳信号。如果心跳丢失，系统可以假定代理已故障并采取纠正措施，例如重新分配其任务。编排器还可以通过向代理发送简单的“ping”请求来主动执行健康检查。

3. 构建有弹性的编排逻辑

编排器通过管理整个工作流程和响应代理故障，在系统可靠性中扮演着重要作用。

• 状态持久化和检查点: 编排器应将工作流程的状态（例如当前步骤、任务状态、中间结果）持久化到持久存储中。这使得在编排器崩溃或系统重新启动时，工作流程可以从最后已知的良好状态恢复。对于代理或工作流程中非常耗时的任务，设置中间检查点可以减少丢失的工作量。

• 补偿事务（Sagas）: 对于期望原子性（所有步骤都成功或所有都失败）的多步工作流程，Saga模式是有用的。如果序列中的某个步骤失败，将按相反顺序执行一系列补偿事务，以撤销先前已完成步骤的影响。例如，如果工作流程涉及预订机票和酒店，而酒店预订失败，补偿事务将取消机票预订。

  Saga 模式：如果“确认支付”（T3）失败，则执行“取消酒店”（C2），然后执行“取消机票”（C1）。

• 断路器模式: 当代理反复未能与另一个代理或外部服务交互时，继续发送请求会加剧问题或浪费资源。断路器模式监控故障。在达到一定的故障阈值后，电路“断开”，后续调用会立即失败（或被重定向到备用方案），而不再尝试有问题的操作。经过一段超时时间后，电路进入“半开”状态，允许少量测试请求。如果这些测试成功，电路“闭合”，恢复正常操作。否则，它会恢复到“断开”状态。

  调用成功（1）直到故障（0）使断路器切换到断开状态（状态1）。随后调用快速失败（2）。经过一段时间后，它进入半开状态（状态0.5）进行测试调用。成功后闭合（状态0）。

• 错误处理子工作流程: 不仅仅在出错时终止工作流程，而是定义特定的错误处理路径或子工作流程。这可能涉及：

  • 通知管理员。
  • 尝试更简单的回退策略。
  • 记录详细的诊断信息。
  • 将任务安排在稍后重试。

• 冗余和故障转移: 对于中央编排器或独特、专用代理等重要组件，可以考虑部署冗余实例。如果一个实例发生故障，流量可以重定向到正常运行的实例（故障转移）。这增加了复杂性和成本，因此通常保留给高可用性需求。

4. 监控和告警的作用

尽管监控和告警（将在第6章详细说明）并非直接的恢复机制，但它们对于及时检测故障非常重要。如果无法查看系统健康状况、错误率和代理活动，自动化恢复机制可能会盲目运行，或者重要故障可能未被察觉。应配置告警，用于：

• 代理或工具的高错误率。
• 无响应的代理（心跳丢失）。
• 工作流程死锁或任务长时间停滞。
• 资源耗尽（CPU、内存、API配额）。

5. 复杂恢复中的人工干预

自动化恢复策略可以处理许多常见故障。然而，某些情况对于纯自动化解决而言过于复杂或模糊。在这些情况下，系统应被设计为将问题上报给人工操作员。这是“融入人工监督”（本章稍后介绍）的一个重要方面。人工干预可能包括：

• 手动检查代理日志和状态。
• 纠正损坏的数据。
• 强制工作流程进入特定状态。
• 使用修改后的参数重试失败的步骤。
• 批准或拒绝代理提出的恢复动作。

有效的人工干预系统提供清晰的仪表盘和工具，供操作员理解故障背景并采取明智的行动。

案例场景：在线研究代理团队

设想一个负责研究某个主题的代理团队：

1. 规划代理: 将研究主题分解为子问题。
2. 搜索代理: 接收子问题，查询多个搜索引擎，并获取顶部结果。
3. 抓取摘要代理: 从结果URL抓取内容并进行摘要。
4. 聚合代理: 收集所有摘要并生成最终报告。

如果抓取摘要代理在处理其分配的某个URL时遇到付费墙网站或具有反抓取措施的网站，会发生什么？

• 最初故障: 抓取失败。
• 代理层面重试: 代理可能会带延迟重试抓取一到两次。
• 错误报告: 如果重试失败，它会向编排器报告该特定URL的故障，可能附带错误代码（例如，SCRAPE_BLOCKED）。它会继续处理其他URL。
• 编排器逻辑:
  • 编排器记录故障。
  • 它可能会将该URL分配给另一个抓取摘要代理实例（如果可用且配置了此类冗余），该实例可能使用不同的抓取技术或IP地址。
  • 如果仍然不成功，它可能会将该特定源标记为有问题，并指示聚合代理使用现有信息继续，并注明缺失部分。
  • 对于持续性或普遍性的抓取故障，它可能会触发告警，供人工检查（例如，所有搜索结果都指向被阻止的网站吗？抓取工具有问题吗？）。

这种分层方法，从代理自我纠正到编排器干预以及可能的人工上报，创造一个更有弹性的系统。

构建真正可靠的多代理LLM系统是一个持续的过程。它需要细致的设计、对故障模式的预判、恰当的恢复模式实现以及持续的监控。虽然无法避免所有故障，但目标是构建能够应对常见问题、平稳恢复并保持高水平运行完整性的系统，即便它们执行复杂的编排任务。