AI生成的重试循环如何耗尽免费额度

症状：凭空出现的 429

这套环境刻意做得很小：一个用 MonkeyCode 免费模型访问权限生成的 Webhook 端点，部署在免费服务器上，连接到一个偶尔返回 503 的第三方 API。MonkeyCode 是一个开源项目，其免费层包含 1000 万 Token 额度加一个免费服务器实例，对于小型集成来说绰绰有余，但约束条件也足以暴露放大 bug。该处理器正常运行了两天，然后正常的请求开始失败并返回 429 Too Many Requests，尽管应用远未达到月度 Token 预算。

第一个调试直觉是怪第三方提供商，因为 429 是限流状态码，而且那个提供商这周一直很不稳定。快速查看提供商的状态页没有发现任何事件，这就把怀疑转回到了免费服务器。服务器自身的日志没有显示异常，因为失败的请求是发出的重试，不是传入的流量。

转折点出现在开发者在本地用相同的 API 重放那个确切的失败请求序列，结果得到了 200 响应。代码相同，负载相同，唯一不同的是服务器环境。本地成功强烈暗示是环境原因，于是调查转向了服务器的出站流量。

调查：追踪重试轨迹

免费服务器上的访问日志揭示了问题模式：每当下游 API 返回 503，处理器就立即发出一个新请求，然后又一个，又一个，尝试之间没有任何间隔。一次三秒的下游抖动在一分钟内产生了四十个出站请求，第三方 API 于是对该服务器的 IP 进行了限流。用一条命令就能让放大效应一目了然：

grep "POST /api" access.log | awk '{print $4}' | cut -d: -f2 | uniq -c

这个 AI 生成的重试循环猛一看无害，因为它很短且易读。以下是导致该事件的简化版本：

def call_api(payload):
    while True:
        response = requests.post(API_URL, json=payload)
        if response.status_code < 500:
            return response.json()
        # keep retrying until the API accepts the request

这个循环无限重试、立即重试，并把每个 5xx 都视为值得再试一次。在有每分钟请求限制的免费层上，这种行为将一个短暂的下游错误转化为自我造成的故障，因为重试本身消耗了正常请求所需的配额。第二个问题是该循环忽略了 API 在 429 响应中包含的 Retry-After 头；API 明确在说"等 30 秒"，而处理器回应的是"不如现在"。

根本原因：happy path 是生成的，failure path 不是

真正的教训不是 AI 模型写了一个糟糕的循环，因为大量人工写的循环也有同样的缺陷。真正的教训是生成的代码往往针对 happy path 优化，而 failure path 才是假设所在：重试需要退避，退避需要抖动，抖动需要一个上限 ceiling。这个模式现在更重要了，因为 AI 编程工具在代码库中产生的代码越来越多，happy path 正是模型有把握生成的部分，而 failure path 正是它们一带而过的部分。

该事件的修复包含三部分：

1. 只要下游服务提供了 Retry-After 头，就尊重它。
2. 使用带抖动的指数退避，让重试分散而不是聚集。
3. 设定总重试预算，这样一个卡住的服务不会消耗整个免费层。

import random
import time

MAX_RETRIES = 5
BASE_DELAY = 1.0

def call_api(payload):
    for attempt in range(MAX_RETRIES):
        response = requests.post(API_URL, json=payload)
        if response.status_code < 500:
            return response.json()
        retry_after = response.headers.get("Retry-After")
        if retry_after is not None:
            delay = float(retry_after)
        else:
            delay = BASE_DELAY * (2 ** attempt) + random.uniform(0, 0.5)
        time.sleep(min(delay, 30))
    raise RuntimeError("downstream API still failing after retries")

现在放在这段代码旁边的决策表很简单：收到 429 时按响应头中的延迟重试，收到 5xx 时用指数退避重试，收到 4xx 验证错误绝不重试，因为问题出在请求本身。最后那条规则比看起来更重要，因为重试一个坏负载只会成倍放大损害。

可复用的调试工作流

找到这个 bug 的调试路径值得作为任何与外部服务通信的 AI 生成代码的检查清单。从症状开始，验证在失败环境之外能否复现，因为本地成功强烈暗示是环境原因。然后追踪出站流量而不是入站流量，因为失败的请求是服务器发起的，不是它接收的。

下一步是寻找放大循环，即任何一条外部一次失败产生多次内部尝试的代码路径。在生成的代码中快速 grep while True 或 retry 通常能发现该循环，统计每分钟出站请求数可以确认循环是否在放大问题。最后一步是应用重试决策表并重新运行确切的失败场景，在本例中意味着模拟一个下游 503，然后观察出站请求率从每分钟四十次降到五次。

局限性与不适用场景

这个重试策略不是通用解决方案，有些场景下它本身就是错误的工具。如果下游服务要求精确一次 delivery，单独靠重试是不够的，因为重试可能复制副作用，所以处理器需要在退避逻辑之上再加幂等性 key 或去重层。该方案还假设调用方控制着重试预算，当客户端是自行激进重试的第三方时就不是这样了；那种情况下服务器需要在接收侧限流，而不是仅仅在发送侧礼貌地重试。

拥有慷慨付费层的团队可能永远不会看到这个 bug，因为配额大到足以吸收放大效应，而这恰恰是免费层成为更好学习场所的原因。约束条件早早暴露了缺陷，在受限预算下修复它产生的代码在流量最终增长时表现良好。

实践要点

AI 生成的代码生产快，但信任慢，这个事件是一个具体例子，说明这种信任需要在何处赢得。修复不是更多代码，而是更多克制：一个重试上限、一个尊重服务器指示的延迟、以及一条验证错误永不重试的规则。产生该 bug 的受限环境也让调试变得便宜，因为免费服务器的日志和配额讲述了整个故事，无需任何付费可观测性工具。

对于任何想在不冒险生产账号的情况下测试这个模式的人，工作流是：生成一个 Webhook 处理器，指向一个不稳定的端点，然后在每分钟限制下观察会发生什么。免费的一千万 Token 额度和免费服务器让这个实验零成本运行，而失败模式的教育意义恰恰来自于它触发成本低。