LangGraph 中的容错机制：重试、超时和错误处理器

在实际生产环境中，AI 代理会遇到原型中从未出现的错误：网络故障、工具调用错误、LLM 速率限制。一个运行数小时的任务如果中途遇到不可恢复的错误，是直接放弃还是从头开始？这显然不是可持续的生产方式。编写正常路径通常很简单，但使代理在生产中存活下来的错误处理样板代码（重试、超时、降级）往往比业务逻辑本身还要长。

LangGraph 将容错视为一等公民。它是一个底层编排框架，将代理建模为一组离散步骤（节点），组织成图。由于 LangGraph 控制执行，它也是处理任何步骤失败的正确位置。本文介绍 LangGraph 帮助处理样板代码的三个原语：RetryPolicy（带退避和抖动的自动重试），TimeoutPolicy（基于墙钟时间或进度超时），以及 error_handler（重试耗尽后运行的节点，带有失败上下文）。它们如何组合以及为何在工作流引擎内部实现至关重要，尤其是当你开始考虑清理/补偿逻辑时。

在 LangGraph 中，你通过添加节点和边到 StateGraph 来定义代理。所有三个原语直接通过 add_node 附加到节点，因此容错配置位于它保护的逻辑旁边。RetryPolicy 支持指数退避、可选抖动和可配置的异常谓词（默认只重试 ConnectionError 和 5xx 响应）。TimeoutPolicy 提供 run_timeout（硬墙钟时间上限）和 idle_timeout（无进展时的空闲超时），并可通过 heartbeat 刷新。当超时触发时，节点尝试被取消并引发 NodeTimeoutError。

错误处理器在重试耗尽后才运行。这使其非常有用：例如，在支付提供商持续宕机后标记订单失败、通知客户、回滚部分副作用或发布事件。在 LangGraph 中，错误处理器接收 NodeError 对象（包含失败节点名称和异常），并且状态迁移是原子的：原始节点失败后，其 ERROR 写入被提交到检查点，处理器任务在同一超步中被调度。这确保了主机崩溃后恢复时，会重新调度处理器而非原始失败节点。

这三个原语组合的真正力量体现在涉及副作用的流程中，如航班预订。每个步骤（预订座位、处理付款、出票）都与外部系统交互，任何步骤都可能失败。简单的整体重试方法会导致状态不一致，例如座位已预留但付款失败。SAGA 模式是分布式系统中处理此类失败的标准方式。在 LangGraph 中，你可以为每个步骤设置相同的重试策略和错误处理器，后者将流程路由到补偿节点，该节点检查已完成步骤列表并反向撤销它们。

LangGraph 的 retry_policy、timeout 和 error_handler 使得构建能够优雅处理各种错误的代理变得简单。你只需为用例定义合适的策略，运行时负责其余工作。