1. 为什么 Agent 的失败重试值得单独拿出来讲做 Agent 开发的人迟早会被 429 教做人。你写了一个看起来逻辑无懈可击的智能体本地跑得好好的一上量就开始报exceeded retry limit, last status: 429 too many requests然后整个任务链断掉用户看到的就是一句冷冰冰的“执行失败”。更气人的是有些请求明明只差最后一次就能成功偏偏在第三次重试时又撞上速率限制前功尽弃。这个问题的本质不是“网络不稳定”而是 Agent 的调用模式和传统 API 客户端有根本区别。一个 Agent 在一次任务里可能发起几十甚至上百次模型调用每次调用又可能触发工具链、检索、再推理形成扇出效应。如果所有失败请求都用固定间隔重试它们会在同一时刻再次涌向服务端形成二次冲击。指数退避就是用来打破这种同步性的而抖动则是用来打散“退避后仍然同步”的最后一层保险。这篇文章面向的是正在做 Agent 开发、已经踩过或即将踩到 429 坑的工程师。我会从退避策略的设计逻辑讲起拆解指数退避加抖动的具体实现给出可直接复用的代码并分享我在实际项目里遇到的典型问题和排查思路。不管你是刚接触 Agent 框架还是已经在做多 Agent 协作编排这些内容都能直接落到你的重试层里。2. 指数退避的核心逻辑与 Agent 场景的特殊性2.1 从固定间隔到指数退避为什么线性重试会失效最朴素的重试策略是固定间隔比如失败后等 1 秒再试再失败再等 1 秒。这个策略在单客户端、低并发场景下勉强能用但在 Agent 场景里几乎必然出问题。假设你有 50 个 Agent 实例同时运行每个实例在某一刻都遇到了 429如果它们都等 1 秒后重试那么第 1 秒会有 50 个请求同时到达服务端大概率继续返回 429。然后它们再等 1 秒又是 50 个请求同时到达。这就是典型的重试风暴服务端被自己的客户端反复冲击恢复时间被无限拉长。指数退避的思路很直接每次失败后等待时间按倍数增长。第一次等 1 秒第二次等 2 秒第三次等 4 秒第四次等 8 秒以此类推。这样做的效果是随着重试次数增加请求密度快速下降给服务端留出恢复窗口。从数学上看第 n 次重试的等待时间是base * 2^(n-1)总等待时间呈指数增长而请求速率呈指数衰减。但这里有一个容易被忽略的点指数退避解决的是“单个客户端重试密度”问题它并没有解决“多个客户端之间的同步”问题。如果 50 个客户端都在第 1 秒失败它们第一次重试都在第 2 秒第二次都在第 4 秒第三次都在第 8 秒。虽然密度下降了但同步性依然存在服务端在每个重试时刻仍然会收到一波集中请求。这就是为什么必须引入抖动。2.2 Agent 调用链的扇出效应与重试放大Agent 和普通 API 客户端最大的区别在于调用链的深度和宽度。一个普通客户端可能一次任务只调一次 API失败了重试一次就结束。但 Agent 不一样它可能先调模型做规划然后调工具查数据再调模型做推理再调工具做验证最后调模型生成结果。每一步都可能失败每一步失败都可能触发重试而重试本身又会占用配额导致后续步骤更容易触发 429。我实测过一个中等复杂度的 Agent 任务单次执行平均触发 12 次模型调用和 8 次工具调用。如果每次调用的失败率是 5%那么整个任务至少有一次失败的概率大约是 1 - 0.95^20接近 64%。也就是说三分之二的任务都会遇到至少一次失败。如果重试策略设计得不好这 64% 的任务会反复重试把配额消耗在无效请求上形成恶性循环。更麻烦的是多 Agent 协作场景。假设一个编排 Agent 下面挂了 5 个子 Agent每个子 Agent 又各自发起多次调用。当编排 Agent 遇到 429 开始退避时子 Agent 可能还在正常发请求整体请求量并没有下降。等编排 Agent 退避结束子 Agent 的请求又叠加进来形成新的峰值。所以 Agent 场景下的退避策略不能只考虑单次调用还要考虑整个调用树的协同退避。2.3 429 之外哪些错误应该重试哪些不应该不是所有失败都值得重试。我在项目里见过有人把所有异常都塞进重试逻辑结果一个参数错误的请求被重试了 5 次白白浪费了 5 次配额还拖慢了整个任务。正确的做法是先对错误分类再决定是否重试。错误类型典型状态码/异常是否重试说明速率限制429是必须退避后重试且要尊重 Retry-After 头服务端临时故障500, 502, 503, 504是指数退避重试通常 3 到 5 次足够网络超时Timeout, ConnectionError是退避重试但要注意幂等性认证失败401, 403否重试多少次都不会成功直接失败参数错误400, 422否请求本身有问题重试无意义资源不存在404否除非是最终一致性场景否则不重试配额耗尽402, 配额类 429视情况如果是硬配额重试无用如果是软限流可退避注意有些服务端会在 429 响应里带Retry-After头告诉你应该等多少秒。这个值优先级高于你本地计算的退避时间。如果服务端说等 30 秒你等 2 秒就重试大概率还是 429。3. 抖动打破同步性的关键一步3.1 为什么纯指数退避还不够前面提到指数退避只解决了单客户端的重试密度问题没有解决多客户端之间的同步问题。假设你的服务部署了 20 个 Agent 实例它们在同一时刻都遇到了 429。如果没有抖动它们的重试时刻会高度对齐第 1 次重试都在 1 秒后第 2 次都在 2 秒后第 3 次都在 4 秒后。服务端在每个重试时刻都会收到 20 个并发请求如果服务端的恢复速率跟不上就会持续返回 429。抖动的作用就是给每个客户端的退避时间加一个随机偏移让重试时刻分散开。这样服务端收到的请求就是平滑的而不是脉冲式的。从统计上看加入抖动后重试请求的到达过程更接近泊松过程服务端的负载曲线会变得平缓。3.2 三种常见抖动策略的对比与选择业界常用的抖动策略主要有三种Full Jitter、Equal Jitter和Decorrelated Jitter。它们的核心区别在于随机范围的选择。Full Jitter的做法是退避时间在[0, base * 2^n]之间随机取值。比如第 3 次重试理论上限是 8 秒实际等待时间在 0 到 8 秒之间随机。这个策略的优点是分散性最好能最大程度打散请求缺点是可能取到很小的值导致重试过于频繁。Equal Jitter的做法是退避时间 理论值的一半 在[0, 理论值的一半]之间随机。比如第 3 次重试理论值 8 秒实际等待时间在 4 到 8 秒之间。这个策略保留了指数退避的下限不会出现等待时间过短的情况同时也有一定的分散性。Decorrelated Jitter的做法是每次退避时间基于上一次的等待时间随机生成公式是min(cap, random(base, prev * 3))。这个策略的分散性介于前两者之间而且不需要记录重试次数适合长时间运行的任务。策略随机范围优点缺点适用场景Full Jitter[0, base * 2^n]分散性最好可能等待过短高并发、服务端恢复快Equal Jitter[base * 2^(n-1), base * 2^n]保留下限较稳定分散性一般通用场景推荐默认Decorrelated Jitter[base, prev * 3]无需计数自适应上限不易控制长任务、不确定重试次数我在实际项目里默认用 Equal Jitter因为它在分散性和稳定性之间取得了比较好的平衡。如果服务端明确说恢复很快可以切到 Full Jitter如果是长时间运行的后台任务Decorrelated Jitter 更合适。3.3 抖动参数的实操选择base、cap 和最大重试次数参数选择没有绝对标准但有一些经验值可以参考。base通常设为 0.5 到 1 秒太小会导致重试过于频繁太大则会让首次重试等待过久。cap是单次退避的上限一般设为 30 到 60 秒避免退避时间无限增长导致任务卡死。最大重试次数通常设为 3 到 5 次超过这个次数还没成功说明问题不是临时性的继续重试只会浪费配额。这里有一个容易踩的坑最大重试次数和总超时时间要配合使用。假设你设了 5 次重试base 是 1 秒cap 是 60 秒那么最坏情况下总等待时间可能超过 2 分钟。如果你的任务本身有 30 秒的超时限制那么重试还没结束任务就被杀了。所以要么把重试次数降下来要么把任务超时时间调大两者必须匹配。提示如果你用的是 Agent 框架自带的重试机制一定要确认它的默认参数。有些框架默认重试 10 次base 是 0.1 秒这在 Agent 场景下几乎必然触发重试风暴。4. 在 Agent 框架里落地指数退避加抖动4.1 手写一个可复用的重试装饰器不管你用什么 Agent 框架重试逻辑最好自己掌控而不是完全依赖框架默认行为。下面是一个 Python 实现的重试装饰器支持指数退避、Equal Jitter、Retry-After 头解析和错误分类。import random import time import functools from typing import Callable, Tuple, Type RETRYABLE_STATUS {429, 500, 502, 503, 504} def retry_with_backoff( max_retries: int 4, base: float 1.0, cap: float 60.0, jitter: str equal, retryable_exceptions: Tuple[Type[Exception], ...] (Exception,), ): def decorator(func: Callable): functools.wraps(func) def wrapper(*args, **kwargs): last_exc None for attempt in range(max_retries 1): try: return func(*args, **kwargs) except retryable_exceptions as exc: last_exc exc status getattr(exc, status_code, None) if status is not None and status not in RETRYABLE_STATUS: raise if attempt max_retries: raise delay compute_delay(attempt, base, cap, jitter) retry_after getattr(exc, retry_after, None) if retry_after is not None: delay max(delay, float(retry_after)) time.sleep(delay) raise last_exc return wrapper return decorator def compute_delay(attempt: int, base: float, cap: float, jitter: str) - float: theoretical min(cap, base * (2 ** attempt)) if jitter full: return random.uniform(0, theoretical) if jitter equal: half theoretical / 2 return half random.uniform(0, half) if jitter decorrelated: return random.uniform(base, theoretical) return theoretical这个装饰器的关键点在于先判断错误是否可重试再计算退避时间最后检查是否有Retry-After头。Retry-After的优先级最高因为它代表服务端的明确指示。4.2 与 Agent 调用链的集成方式在 Agent 里重试不应该只加在最外层的任务执行上而应该加在每一次模型调用和工具调用上。因为一次任务失败往往是因为某个中间步骤失败如果只重试整个任务会把已经成功的步骤重新执行一遍浪费配额和时间。我的做法是分两层调用层重试和任务层重试。调用层重试针对单次 API 请求用上面的装饰器max_retries 设为 3base 设为 1 秒。任务层重试针对整个 Agent 任务max_retries 设为 1 到 2 次base 设为 5 秒因为任务层重试的代价更高。两层重试之间要有协调机制。如果调用层已经重试了 3 次都失败任务层不应该立即重试而应该先检查是不是配额已经耗尽。如果是配额问题任务层重试也没有意义应该直接失败并通知上层。class AgentExecutor: def __init__(self, llm_client, tool_registry): self.llm_client llm_client self.tool_registry tool_registry retry_with_backoff(max_retries3, base1.0, jitterequal) def call_llm(self, prompt, **kwargs): return self.llm_client.invoke(prompt, **kwargs) retry_with_backoff(max_retries3, base1.0, jitterequal) def call_tool(self, tool_name, **kwargs): tool self.tool_registry.get(tool_name) return tool.run(**kwargs) def execute_task(self, task): for step in task.steps: if step.type llm: result self.call_llm(step.prompt) elif step.type tool: result self.call_tool(step.tool_name, **step.args) else: raise ValueError(fUnknown step type: {step.type}) task.record(step, result) return task.result4.3 多 Agent 协作下的协同退避多 Agent 场景下退避策略需要额外考虑协同问题。如果编排 Agent 发现某个子 Agent 频繁触发 429它应该主动降低整体请求速率而不是让每个子 Agent 各自退避。我的做法是在编排层加一个令牌桶所有子 Agent 的请求都要先获取令牌令牌的发放速率根据最近的 429 比例动态调整。具体来说维护一个滑动窗口统计最近 60 秒内的请求数和 429 数量。如果 429 比例超过 10%就把令牌发放速率降低 20%如果低于 2%就逐步恢复。这样整个系统的请求速率会自适应服务端的承载能力而不是等到大量 429 出现才开始退避。class AdaptiveRateLimiter: def __init__(self, initial_rate10.0, window60): self.rate initial_rate self.window window self.requests [] self.throttled [] def acquire(self): now time.time() self._cleanup(now) if len(self.requests) self.rate * self.window: return False self.requests.append(now) return True def record_429(self): self.throttled.append(time.time()) self._adjust() def _adjust(self): now time.time() self._cleanup(now) if not self.requests: return ratio len(self.throttled) / len(self.requests) if ratio 0.1: self.rate max(1.0, self.rate * 0.8) elif ratio 0.02: self.rate min(50.0, self.rate * 1.1) def _cleanup(self, now): cutoff now - self.window self.requests [t for t in self.requests if t cutoff] self.throttled [t for t in self.throttled if t cutoff]这个限流器的好处是它不依赖固定的退避时间而是根据实际反馈动态调整。在流量波动大的场景下比固定参数的指数退避更稳。5. 常见问题与排查技巧实录5.1 重试次数用完了还是 429怎么办这是最常见的问题。exceeded retry limit, last status: 429 too many requests这个报错说明你的重试次数已经耗尽但服务端仍然在限流。这时候继续重试没有意义需要从根因上解决。第一步是确认限流类型。有些服务端的 429 是短时速率限制比如每秒最多 10 个请求这种通过退避可以恢复。有些是日配额限制比如每天最多 1000 次调用这种退避再久也没用只能等配额重置或升级套餐。区分方法是看响应头里有没有X-RateLimit-Remaining或类似的配额字段如果剩余配额是 0那就是硬配额问题。第二步是检查是否有请求放大。我遇到过一种情况Agent 在重试时把整个上下文重新发送导致每次重试的 token 消耗比原请求还大反而加剧了限流。正确的做法是重试时只发送必要的增量信息或者使用幂等键让服务端识别重复请求。第三步是考虑降级。如果 429 持续出现可以让 Agent 切换到更小的模型、更短的上下文或者跳过非关键步骤。我在项目里加了一个降级策略当 429 比例超过 30% 时自动把模型从大模型切到小模型等限流恢复后再切回来。5.2 抖动导致重试时间过长任务超时怎么破抖动的一个副作用是可能把等待时间拉得很长。比如 Equal Jitter 在 cap 为 60 秒时第 5 次重试的等待时间可能在 30 到 60 秒之间。如果任务本身有 60 秒超时那么重试还没结束任务就被杀了。解决思路有两个一是降低 cap把单次退避上限压到 10 到 15 秒这样即使多次重试总等待时间也可控。二是设置总重试预算比如整个任务最多花 30 秒在重试上超过这个预算就直接失败。我通常两个一起用cap 设为 15 秒总预算设为 45 秒。class RetryBudget: def __init__(self, total_budget45.0): self.total_budget total_budget self.spent 0.0 def can_retry(self, delay): return self.spent delay self.total_budget def spend(self, delay): self.spent delay在重试循环里每次计算完 delay 后先检查预算如果超了就放弃重试。这样能保证任务不会因为重试而无限期挂起。5.3 如何判断是客户端问题还是服务端问题429 不一定是服务端的锅有时候是客户端行为触发的。我整理了一个排查清单按顺序检查检查项可能问题排查方法请求频率是否超过服务端文档标注的 QPS统计本地请求速率对比文档并发数是否同时开了太多 Agent 实例检查部署配置和实例数请求大小是否单次请求 token 过多查看请求日志中的 token 数重试逻辑是否重试放大了请求量统计重试次数和原始请求比例配额使用是否接近日配额上限查看响应头中的配额字段共享配额是否有其他服务共用同一密钥检查密钥使用方服务端状态是否服务端整体故障查看服务状态页或社区反馈我踩过最坑的一次是本地测试时一切正常上线后 429 暴增。排查了半天才发现测试环境和生产环境共用了一个 API 密钥生产环境的流量把测试环境的配额吃掉了。所以密钥隔离这件事一定要在项目初期就做好。5.4 重试日志应该记录哪些字段重试日志是排查问题的关键。如果日志里只有“重试第 3 次”这种信息出问题时根本没法定位。我建议至少记录以下字段请求 ID 和任务 ID用于串联整个调用链重试次数和本次等待时间错误状态码和错误消息服务端返回的 Retry-After 和配额剩余当前 Agent 的并发数和整体请求速率请求的 token 数和模型名称这些字段能帮你快速判断是单点问题还是系统性问题。比如如果发现所有 429 都集中在某个模型上那可能是该模型的配额单独受限如果所有 429 都发生在某个时间段那可能是定时任务导致的流量峰值。提示重试日志不要只写文件最好接入监控系统设置 429 比例告警。当 429 比例超过 5% 时触发告警超过 20% 时自动降级。6. 几个容易忽略的细节和我的实操心得第一个细节是幂等性。重试的前提是请求幂等否则重试可能导致重复扣款、重复发消息、重复写数据。对于 Agent 来说模型调用通常是幂等的但工具调用不一定。我在项目里给所有写操作工具加了幂等键重试时带上同一个键服务端识别到重复请求就直接返回上次结果。第二个细节是退避时间的单位。有些服务端的 Retry-After 头返回的是秒有些返回的是毫秒还有些返回的是 HTTP 日期格式。解析时要做好兼容否则可能把 1000 毫秒当成 1000 秒任务直接卡死。第三个细节是随机数种子。在多进程或多线程环境下如果随机数种子相同抖动就失效了。Python 的random模块默认使用系统时间作为种子一般没问题但如果你手动设了种子记得每个进程用不同的值。第四个细节是重试的可观测性。我见过很多项目重试逻辑写得很完善但没有任何监控出了问题只能靠猜。建议在重试装饰器里加一个回调每次重试时上报指标这样你能清楚地看到重试频率、成功率、平均等待时间等数据。最后一个心得是不要过度重试。有些开发者觉得重试次数越多越好实际上超过 5 次的重试成功率极低反而会拖慢整体任务。我的经验是3 次调用层重试加 1 次任务层重试能覆盖 95% 以上的临时故障。剩下的 5% 要么是硬配额问题要么是代码 bug重试解决不了。这套策略我在三个不同的 Agent 项目里用过从单机脚本到分布式多 Agent 协作效果都比较稳。核心思路就是分类错误、指数退避、加抖动、设预算、做监控。把这五件事做好429 就不再是拦路虎而是一个可以预期的正常现象。