AI 智能体错误处理与恢复：构建弹性生产系统

生产环境中的 AI 智能体时刻面临各类错误。工具会失败，LLM 会返回意外格式，API 会遇到速率限制，网络连接也会中断。如果没有健壮的错误处理机制，这些失败会导致工作流中断和用户挫败。本指南涵盖了生产环境中 AI 智能体系统的实用错误处理与恢复策略。

为什么 AI 智能体的错误处理至关重要

与传统软件中可预测的输入不同，AI 智能体运行在概率性环境中。相同的提示词在不同调用中可能产生不同的输出。工具可能暂时不可用。LLM 响应可能是格式错误或内容不完整的。这些不确定性需要超越简单 try-catch 模式的错误处理策略。

考虑一个处理退款的用户支持智能体。如果支付 API 返回错误，简单实现可能会静默失败或无限重试。而弹性系统则会识别失败，通过替代路径尝试恢复，并向用户显示有意义的状态信息。这两种方法之间的差异决定了你的智能体是可靠还是脆弱。

未处理错误的代价

理解这些分类有助于你设计适当的处理策略，而不是对所有失败一律使用无条件重试。

核心错误处理模式

指数退避加抖动

当工具发生临时性故障时，立即重试不仅浪费资源，还可能加剧速率限制。指数退避将重试尝试分布在递增的时间间隔内，而抖动则添加随机性，防止多个智能体同时重试时引发”惊群”效应。

从 100-500 毫秒的基础延迟开始。每次失败后将延迟翻倍，最高不超过 30 秒。在当前延迟值范围内添加随机抖动（0 到当前延迟之间）。大多数生产系统将总重试次数限制为 3-5 次，之后升级处理。

熔断器模式

当一个工具或 API 反复失败时，继续重试只会浪费时间与资源。熔断器监控故障率，在超过阈值后断开电路，立即快速失败，而不是尝试恢复。

熔断器由三种状态定义：

• 关闭：正常运行状态，请求正常通过
• 打开：故障过多，请求立即失败，不再尝试调用工具
• 半开：超时后，允许发送一个测试请求以探测服务是否已恢复

根据你的 SLA 设置故障阈值。在 10 次请求中有 50% 失败可能表明工具出现降级，值得调查。半开状态让你无需等待人工干预即可检测服务是否已恢复。

回退链

单点依赖就是单点故障。回退链为关键操作维护替代实现或数据源。当主路径失败时，智能体会按优先级顺序尝试替代方案。

示例：一个天气查询智能体可能先尝试 OpenWeatherMap，若主服务限速则回退到 WeatherAPI，若两个外部源都失败则使用缓存结果。每个回退都有不同的保证——缓存命中数据可能过时但即时，而次要提供商可能有不同的数据覆盖范围。

LLM 特有的错误处理

响应验证

LLM 输出是概率性的。即使使用结构化输出提示词，解析器也必须能够优雅地处理意外格式。在处理之前，先按照预期 schema 验证响应。当验证失败时，记录实际输出，然后决定是否使用更严格的提示词重试，或升级为人工处理。

三个验证级别可防范常见故障：

1. 结构验证：检查所需字段是否存在且符合预期类型
2. 语义验证：验证值在域内是否合理（例如，温度应该是数字而非字符串）
3. 业务规则验证：确认输出满足约束条件（例如，退款金额不能超过原始购买金额）

畸形 JSON 恢复

当 LLM 返回截断或格式错误的 JSON 时，在完全拒绝之前先尝试恢复。常见的恢复技术包括：闭合未闭合的括号、转义未转义的引号，以及从周围文本中提取部分结构。某些智能体会使用二次 LLM 调用专门修复格式错误的输出，以延迟换取可靠性。

内容策略失败

LLM 内容过滤器可能会拒绝原本有效的提示词。不要直接失败，而是分析拒绝模式以调整提示词表述。建立已知拒绝触发词词典及替代表述。将拒绝日志与其他错误分开记录，以便区分系统性提示问题与随机过滤。

工具集成弹性

超时配置

每个外部工具都需要设置适当的超时时间。简单查询适合较短超时（5 秒）。复杂操作（如图象生成或文档处理）需要较长超时（30-60 秒）。基于历史延迟的分位数（而非平均值）按工具配置超时，以应对长尾延迟。

权限与认证错误

认证失败不同于临时性错误。当工具报告无效凭据或过期令牌时，不要重试——重试只会得到相同的失败结果。应立即向用户或系统管理员展示认证错误。在可能的情况下，为基于 OAuth 的集成实现令牌刷新流程。

恢复策略

语义重试 vs 盲重试

盲重试重复执行相同的失败操作，期望得到不同的结果。语义重试根据错误上下文修改方法。当工具返回验证错误时，使用相同输入重试只会浪费时间。当工具返回超时错误时，使用调整后的参数（更长超时时间、更小负载）重试的成功概率更高。

在决定重试之前先对错误进行分类。临时性错误（超时、连接被拒绝、5xx 响应）值得重试。永久性错误（400 错误请求、401 未授权、403 禁止）需要替代处理方式。

检查点与恢复

长时间运行的智能体工作流受益于检查点机制。在每步完成后保存进度，这样失败后可以从最后一个成功点重新启动，而不是从头开始。这对多步骤流程（如文档生成流水线或涉及数十个工具调用的数据聚合工作流）尤其有价值。

优雅降级

当完整功能不可用时，提供部分价值而非完全失败。无法获取实时数据的智能体可以提供带有新鲜度时间戳的缓存结果。无法生成自定义内容的智能体可以回退到带明确免责声明的模板化响应。

监控与告警

错误分类

系统化分类错误以实现有效监控。按类型（临时、永久、验证、安全）、工具和严重程度跟踪错误率。展示错误率趋势的仪表盘有助于区分负载增加（绝对错误数增加但比率稳定）与真正降级（错误率上升）。

平均恢复时间

衡量错误在恢复之前持续的时间。恢复时间包括检测延迟、决策时间和执行时间。自动重试减少检测和决策时间。熔断器和回退链通过提供即时代替方案来减少执行时间。

故障模式文档

维护一份已知故障模式及其处理方法的活跃文档。当出现新的错误模式时，将其添加到分类体系中并附上响应流程。新团队成员和自动化 on-call 系统均可从对熟悉错误类型的一致响应中受益。

实施检查清单

常见问题

重试多少次算太多？

超过 5 次重试很少能成功，通常表明是永久性故障。每次重试都消耗 token、时间，并可能加剧速率限制。如果重试耗尽，应切换到回退或错误处理，而不是继续重试。

遇到 400 错误请求是否应该重试？

不应该。400 错误表明请求本身无效，而非服务暂时不可用。重试相同的 400 请求只会浪费资源。相反，应验证输入并修复请求，或升级错误。

如何区分临时性故障与永久性故障？

临时性错误通常返回 5xx 状态码、超时消息或连接被拒绝的响应。永久性错误返回 4xx 状态码、验证消息或认证失败。结合错误消息内容和状态码进行分类判断。

所有回退都失败时会怎样？

当所有恢复路径都已耗尽时，优雅失败。向用户返回清晰的错误消息，说明什么失败了以及有哪些可用选项。记录完整的错误链以供调试。考虑实现死信队列，用于跟踪永久失败的操作以供后续审查。

如何在没有真实故障的情况下测试错误处理？

使用混沌工程原则：通过阻断网络请求、返回错误响应或模拟超时，在测试环境中注入故障。在受控条件下测试重试逻辑、熔断器和回退链。大多数测试框架支持 HTTP 拦截器模式来模拟故障场景。

错误处理是否可能引入安全风险？

是的。过于详细的错误消息可能泄露内部实现细节。没有限速的重试逻辑可能导致拒绝服务攻击。在向用户暴露之前务必对错误消息进行消毒，对重试实施速率限制，且绝不在错误追踪中记录敏感数据。

AI 智能体应如何处理部分成功？

当多步骤工作流完成部分步骤但在其他步骤失败时，保存已完成步骤的进度并从失败点恢复，而不是重新开始。这需要检查点机制和幂等操作——重新执行已完成步骤应产生相同结果。

结论

构建弹性 AI 智能体需要分层错误处理：针对临时故障的即时重试、防止级联故障的熔断器、关键操作的回退链，以及完整功能不可用时的优雅降级。持续监控错误模式，并根据生产经验不断优化处理策略。在生产中表现可靠的智能体共享一个特征：它们能够显式失败、自动恢复，并从失败中学习以提升未来性能。