这类问题我又碰上了一次。凌晨零点 20 个任务同时触发，前三分钟把 TPM 打满，全部返回 429，重试又撞在一起，任务延迟到一点才跑完，日报也跟着晚了。
第一反应是「重试没有抖动，同时再打一轮」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。所有任务都写在整点零分触发；共享同一个 key 的配额；没有排队机制，谁先抢到谁跑。
动手时先把触发时间按任务错开
python stagger.py --tasks tasks.yaml --window 3600 --out crontab.new给批量任务单独分配 key 和配额
curl -X POST https://api.openai.com/v1/organization/api_keys -H "Authorization: Bearer $ADMIN" -d '{"name":"nightly-batch"}'接着重试带随机延迟
python run_task.py --retry 4 --jitter 30 --respect-retry-after剩下的就是观察整点的 429 曲线是否消失
python metrics.py --metric api_429 --window 00:00-01:00这次没动代码，只在配置和运行环境上找原因。
恢复的判定其实很直接。整点前后没有 429，所有任务在一小时内完成，日报生成时间回到原来的一分钟内。
提醒一点。配额是按时间窗算的，任务触发时间集中等于自己制造峰值，错开几分钟就能省掉一轮扩容。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。