LLM Agent重试Bug：是分布式系统问题，不是AI问题

当LLM Agent从实验原型走向生产系统，一个反复出现的故障模式正在困扰开发者：Agent陷入无限循环、重复执行动作，或在重试时破坏状态。面对这类问题，行业的第一反应往往是调整提示词、修改温度参数或更换模型，默认"智能"是瓶颈。这种归因可能本身就是个错误。

为什么说这不是AI的问题

当Agent未能完成任务时，标准容错手段是重试——这一做法直接借自微服务架构：网络调用超时或返回503，重试即可。但LLM Agent不是简单的HTTP客户端。它是有状态的、非确定性的进程，会与外部系统交互。把朴素的重试逻辑套用在Agent上，暴露出的问题与模型推理能力无关。

原文列出了三类典型故障：

非幂等操作。Agent发送邮件、创建数据库记录或触发金融交易后，如果重试时未保证幂等性，就会产生重复。这不是AI"幻觉"出了重复操作，而是系统架构没能安全地处理重试。

状态漂移。Agent通常维护上下文窗口或外部记忆。一次重试可能重新执行了已经成功的步骤，但Agent的内部状态并未反映这一点，导致前后矛盾的动作。

级联失败。在多Agent系统中，一个Agent的重试可能触发下游Agent的不必要重试，形成"惊群"问题。

这三类问题的共同点是：它们都发生在系统层，而非模型层。继续在提示词里打转，越努力越偏离病灶。

三个被忽视的分布式系统原则

幂等键：让重复执行无害

分布式系统中，幂等性保证同一请求执行多次与执行一次效果相同。对LLM Agent而言，这意味着每个改变状态的动作都必须绑定唯一的幂等键。重试发生时，系统先检查该键，若动作已完成则直接跳过。

原文用代码对比了两种写法。朴素版本在异常时递归调用自身，直接导致无限循环和重复执行；修正版本在执行前查询缓存，命中则返回缓存结果，未命中才执行并写入缓存，同时将立即重试换成了指数退避。区别不在于模型多聪明，而在于外层是否有一套幂等保护。

指数退避（Exponential Backoff）是重试策略中的标准做法：每次重试失败后，等待时间按指数级增长（如1秒、2秒、4秒、8秒……），并通常加入随机抖动（Jitter）以避免多个客户端同时重试造成的“重试风暴”。它的核心作用有两个：一是给下游系统留出恢复窗口，避免在瞬时故障期间持续加压；二是防止重试快速耗尽调用方资源。在LLM Agent场景中，指数退避还需配合最大重试次数上限和总超时预算，否则一个意图明确但不断失败的任务仍可能长期占用token和计算资源。

惊群效应（Thundering Herd）指大量进程或线程在同一时刻被唤醒并争抢同一资源，导致瞬时负载激增、系统吞吐骤降。在多Agent系统中，若一个上游Agent失败后触发重试，而每个重试又同步唤醒多个下游Agent，就会形成层层放大的重试洪峰。缓解手段包括随机化重试延迟、限制并发重试数量、以及用熔断器在检测到连续失败时快速失败，避免无效请求继续向下游扩散。

最终一致性与状态管理

Agent所处的环境往往不具备即时一致性。动作可能已在后端成功，但确认响应丢失了。重试机制必须把这种情况考虑进去，采用事件驱动架构，让Agent监听确认事件，而不是依赖同步响应。这解决的是"我到底做没做过"这个分布式系统经典难题。

事件驱动架构（Event-Driven Architecture）中，系统组件通过发布和订阅事件来通信，而不是直接同步调用。对Agent而言，这意味着动作发起后不必阻塞等待结果，而是订阅“操作已完成”“操作已失败”等事件来更新自身状态。这种模式天然契合最终一致性：确认响应可能丢失或延迟，但事件日志（或消息队列）能保证状态变更最终被感知。实践中常配合发件箱模式（Outbox Pattern）——将状态变更与待发布事件写入同一事务，再由后台进程可靠投递，从而避免“动作成功但事件丢失”导致的状态漂移。

熔断器：该停的时候停

微服务中的熔断器同样适用于Agent。当某个Agent或下游服务连续失败，熔断器打开，阻止后续重试继续浪费资源、加剧拥塞。原文指出，这是经典分布式模式，但在早期Agent框架中很少实现。

生产环境的代价

随着自主Agent承担复杂的多步骤任务，重试机制的可靠性变得关键。忽视其分布式属性会带来三类后果：数据损坏，包括重复交易、更新丢失和状态不一致；资源耗尽，无限循环持续消耗API token和算力；行为不可预测，Agent在高负载下的表现与隔离测试时截然不同。

原文的结论很直接：解决方案不是更好的提示词或更大的模型，而是更好的工程。需要把LLM Agent当作分布式系统的组件来对待，配齐幂等、熔断、最终一致性和健壮的错误处理。

常见疑问

是否该放弃重试？ 不是。重试对处理瞬时故障仍然必要，关键是配合幂等和退避策略来实现。

如何在Agent中实现幂等？ 为每个动作请求分配唯一ID，执行前检查该ID是否已处理，已处理则返回缓存结果。

有现成框架吗？ 新兴Agent框架开始纳入这些模式，但多数仍需手动实现幂等和熔断。审计Agent的重试逻辑时，应重点排查分布式系统反模式。

AI并不存在于真空之中，它嵌入在有其自身复杂性和故障模式的系统里。承认这一点，才能用被验证过的工程实践，把Agent的可靠性从演示级推到生产级。