AI Agent 偶尔收到一次 429 Too Many Requests 很正常：可能是瞬时并发超过限制，也可能是模型线路、账户额度或上游服务正在限流。真正容易把账单和故障一起放大的，是“每一层都觉得自己应该再试一次”。

例如，OpenAI SDK 自动重试 2 次，Dify 节点再重试 2 次，业务队列又把整个任务重跑 2 次。一次用户请求理论上就可能触发多轮重复调用；如果 Agent 还包含规划、检索、工具调用和最终总结，成本会迅速失控。

因此，429 治理的目标不只是“最终请求成功”，而是：在可接受的时间和预算内成功，并且不重复产生业务副作用。

一、先判断 429 来自哪里

遇到 429 时，至少区分四种情况：

1. 单用户短时间请求过多；
2. 应用整体并发超过模型或线路限制；
3. Token 吞吐量超过每分钟配额；
4. 账户余额、日额度或供应商容量不足。

前两种通常适合延迟后重试；Token 吞吐过高需要降低并发、缩短上下文或拆分任务；余额和供应商容量问题则不应该无限重试。日志中应保存状态码、请求 ID、模型、等待时间、重试次数和 workflow_id，但不要记录 API Key 或用户隐私原文。

二、指数退避必须加 jitter

固定每秒重试一次，会让大量失败请求在同一时刻再次撞向服务，形成“惊群”。更稳妥的做法是指数退避，并加入随机抖动：

等待时间 = min(上限, 基础等待 × 2^重试次数) + 随机抖动

如果响应包含 Retry-After，优先尊重服务端建议。下面是一个简化的 Python 示例：

import random
import time
from openai import OpenAI, RateLimitError

client = OpenAI(
api_key="从环境变量读取",
base_url="https://api.woofapi.com/v1",
)

def call_with_budget(messages, model, max_retries=3, max_wait=20):
total_wait = 0.0
for attempt in range(max_retries + 1):
try:
return client.chat.completions.create(
model=model,
messages=messages,
timeout=60,
)
except RateLimitError:
if attempt == max_retries:
raise
delay = min(8.0, 0.8 * (2 ** attempt))
delay += random.uniform(0, 0.5)
if total_wait + delay > max_wait:
raise RuntimeError("retry wait budget exceeded")
time.sleep(delay)
total_wait += delay

生产环境还应读取 Retry-After，并把超时、5xx 与 429 分开处理。不要对 401、无效参数或余额不足做机械重试。

三、设置 retry budget，而不只是 max_retries

max_retries=3 只能限制单次调用，不能限制整个 Agent。一个工作流可能包含 8 个模型调用，每个都允许 3 次重试，理论上仍可能产生大量额外请求。

建议同时限制三个维度：

• 次数预算：单次模型调用最多重试 2～3 次；
• 时间预算：整个工作流累计等待不超过 20～60 秒；
• 费用预算：预计费用超过阈值就停止继续尝试。

还可以定义：重试负载 = 重试请求数 ÷ 首次请求数。如果重试负载长期超过 10%～20%，不应只继续调大重试次数，而要检查并发、上下文长度、路由容量和上游稳定性。

四、三层预算要同时生效

对 Dify、RAG 或多 Agent 系统，建议同时设置：

1. per-call：限制单个模型调用的 Token、超时和重试；
2. per-workflow：限制一次用户任务的总调用数、总等待和总费用；
3. per-user/day：限制单用户每天的总消耗，防止脚本循环或异常流量。

当任一层预算耗尽时，系统应返回明确的可恢复状态，例如“稍后继续”“切换到低成本模型”或“转人工处理”，而不是静默无限重试。

五、工具调用必须有幂等键

模型生成文本通常可以安全重试，但“发送邮件、创建订单、扣款、写数据库”不能简单重复执行。每个有副作用的动作都应带幂等键：

idempotency_key = workflow_id + tool_name + normalized_arguments_hash

服务端先查询这个键是否已经成功执行；如果成功，就返回原结果，不再重复写入。这样即使模型回复丢失、网络超时或队列重投，也不会重复创建订单或发送多封消息。

六、用成功工作流成本比较线路

只看每百万 Token 单价，很容易忽略失败和重试。更有业务意义的公式是：

单个成功工作流成本 =
（输入费用 + 输出费用 + 重试费用 + 工具费用）÷ 成功工作流数

假设线路 A 完成 100 个任务花费 20 元，成功 90 个，每个成功任务约 0.22 元；线路 B 只花 16 元，但因 429 和超时只成功 60 个，每个成功任务约 0.27 元。总账单更低，不代表有效结果更便宜。

免费在线计算器：https://zcl97630815-cpu.github.io/woofapi-openai-compatible-starter/

Python、Node.js 最小接入示例：https://github.com/zcl97630815-cpu/woofapi-openai-compatible-starter

上线前检查清单

• SDK、工作流引擎和业务队列只保留一处主重试策略；
• 429、5xx、超时、401 和参数错误分类处理；
• 指数退避加入 jitter，并尊重 Retry-After；
• 同时设置 per-call、per-workflow、per-user/day 预算；
• 有副作用的工具调用使用幂等键；
• 监控成功率、P95、重试负载和单个成功工作流成本。

WoofAPI 提供 OpenAI-compatible 多模型路线，适合开发者、Dify、RAG 和 AI Agent 工作流测试。部分 GPT 路线在特定官方输入价格比较中最高可低约 95%；不同模型、输入/输出计费和实时线路会变化，最终以价格页和实际压测为准。

本文由 WoofAPI 团队整理，公开关系披露如下：

• 官网：https://woofapi.com
• API Base URL：https://api.woofapi.com/v1