Claude 返回 529 overloaded_error，重试该怎么写

先别急着改参数，把报错原文、版本号和最近的变更记录摆在一起看，方向会清楚很多。 晚高峰批量跑摘要时连续收到 529，返回体是 {“type”:”error”,”error”:{“type”:”overloaded_error”}}，脚本没有重试逻辑，整批 800 条任务在第三分钟直接中断。

如果同一时间还改过其他配置，建议一次只回退一项，方便确认是哪一步起的作用。

先分清是哪一类原因

1. 服务端容量紧张时主动返回 529，属于可重试错误
2. 客户端只有一次调用，没有任何退避重试
3. 重试间隔固定为一秒，反而持续打到同一个过载节点
4. 并发数没有上限，重试请求自身把压力放大

按顺序处理

1. 先区分可重试错误码，别把 400 也一起重试

RETRY = {429, 500, 502, 503, 529}

2. 用指数退避加随机抖动包住调用

delay = min(2 ** i, 30) + random.random()

3. 超过次数后降级到更小的模型继续跑

curl https://api.anthropic.com/v1/messages -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" -d '{"model":"claude-3-5-haiku-20241022","max_tokens":512,"messages":[{"role":"user","content":"hi"}]}'

4. 把最终失败的任务写进补偿队列

python requeue.py --failed failed.jsonl

怎么确认已经恢复

批量任务全部完成，日志里 529 次数明显下降，最终失败数为零，补偿队列里只剩人工复核的极少数样本。

容易忽略的地方

529 和 429 语义不同，前者是容量问题后者是频率问题，但处理方式一样要退避；直接原地重试只会让过载持续更久。 复现步骤最好记下来，下次同类问题可以直接照单执行，不用再从零开始想。