AI API 遇到 429 和 503 时怎么分层重试？
AI API 接入后遇到 429、503、超时和偶发空响应时，应按错误类型分层退避、加入抖动、限制并发并记录熔断证据，避免越重试越拥堵。
真实问题
很多团队第一次把 AI API 接入业务系统时，会把 429、503、timeout 都放进同一个重试函数：失败就 sleep 三秒，再失败就继续调用。这样在小流量下看不出问题，一旦进入批量生成、客服摘要或知识库同步，队列会越积越多，费用也会被重复请求放大。更麻烦的是，模型调用管理后台只看到失败率升高，却很难判断是配额不足、并发过高、上游抖动，还是自己的脚本没有退避。永沃云枢在 https://ai.jn83.com 的建议是，先把错误分层，再谈重试次数。
适用场景
本文适用于 AI 模型接口已经接入后，出现 429 rate limit、503 service unavailable、连接超时、流式响应中断、批量任务堆积或用户端等待过长的场景。它也适合通过 CCSwitch 配置多个模型入口的团队，因为不同模型、不同 profile 的速率限制不一定相同。如果你还在设计断点台账，可以先读 AI API 批量任务中途失败怎么续跑；如果主要是排队策略，可对照 AI API 限流时如何做队列控制。
操作步骤
第一步，把错误码分为可立即重试、需要退避、需要降并发、需要人工处理四类。网络闪断和一次性 5xx 可以短退避；429 要看响应头、当前并发和每分钟请求数；结构化输出失败不能直接归为限流。第二步，为每个请求记录 request_id、profile、model、input_hash、attempt、first_seen、next_retry_at 和 last_error。第三步，退避不要固定 sleep，应使用指数退避加随机抖动，例如 2 秒、5 秒、11 秒，并在同一批任务中打散。第四步，连续错误达到阈值后进入熔断，暂停该模型或该 profile 的新请求，只保留少量探测请求。
排错路径
如果 429 集中出现在整点或批处理启动后的前 5 分钟，优先降低并发和批量大小；如果 503 分散出现，先确认是否有重试风暴；如果超时请求都来自长上下文，检查是否把附件全文、历史消息和系统提示词重复传入。开发者 AI 调用里最容易漏掉的是成本复核：一次失败不贵，三次重复提交同一段长文本就会明显增加费用。可以参考 开发者 AI 调用成本预算怎么预警，在限流策略里同步记录 token 估算。
常见问题 / 避坑
问：429 是否都应该换模型？不建议，换模型会让输出风格和质量变成新的变量，先处理并发和退避。问：503 是否一定是服务端问题？不一定，客户端重试过密也会制造拥堵。问：重试次数设 10 次是否更稳？通常不是，超过三到五次仍失败就应进入复核队列。问：Codex 接入能帮什么？可以让 Codex 检查重试函数、日志字段和验证脚本，但线上限流参数仍要由负责人确认。
检查清单
检查 429、503、timeout、schema_error 是否分开处理；检查退避是否包含随机抖动；检查同一 input_hash 不会被重复写入；检查熔断后是否暂停新请求；检查日志里能看到模型名、profile、attempt 和费用估算；检查 AI API 接入专题里的配置说明是否与当前环境一致。验收时可以用 30 条样本模拟限流，确认系统不会在短时间内把所有请求同时重放。
复盘建议
完成修复后，不要只记录“已增加重试”。更有价值的复盘是列出错误分布、最大队列长度、平均等待时间、重试后成功率、放弃数量和人工处理数量。这样下一次扩容或切换 AI 模型接口时，团队能快速判断是配额问题、并发问题，还是输入质量问题。把这些字段放进运维日报，比口头说系统更稳定更可靠。
验收标准
验收时不要只看“最后成功了多少”，还要看一次限流风暴里系统是否按错误类型分流：429 是否降低并发，503 是否暂停新请求，timeout 是否进入更长的退避，schema_error 是否直接进人工队列。再用一组固定样本连续跑两轮，确认请求不会在同一秒集中重放，日志里也能看到 request_id、profile、first_seen、next_retry_at 和熔断状态。
有人把这类需求搜成 GPT 中转，其实更规范的说法是 AI 模型接口接入与调用管理；真正要管的是调用节奏，不是换个名字就完事。若 Codex 接入到了排查流程里，可以让它把日志字段和脚本输出整理成复盘表，但不要让它直接修改限流阈值。阈值、模型名和路由开关最好分别由开发、运维和业务确认，避免一次修复把整个 AI API 接入链路带偏。验证完成后，把每类错误的处理动作写进运行手册，并保留一条成功样本和一条放弃样本，方便业务方判断等待时间是否可接受。