AI 应用上线后，最让人紧张的报错不是"模型回答得不够好"，而是请求超时：用户还在等，主通道却没有返回结果。
很多人的第一反应是：再配一个渠道，失败就切过去。但在生产环境里，有备用渠道，不等于可以安全地重发请求。
10 月 14 日，OpenAI 在官方开发者文章中讨论了跨模型提供方的故障切换。它讲的不是一项"自动切换新功能"，而是一套需要应用和网关共同落实的恢复策略。来源：OpenAI Docs 官方开发者文章
一、先分清：重试、换模型、换提供方
这三个动作经常被混为一谈：
- 重试：同一个请求，再向原通道发一次。
- 模型回退：原模型不可用，改用另一个已验证的模型。
- 提供方故障切换：原提供方无法服务，改走另一个已批准的提供方。
它们都可能让请求"最终成功"，但前提不同。换了模型，输出质量、工具能力和格式可能变化；换了提供方，还要核对数据处理要求、容量、预算和接口支持情况。模型名称相同，也不能跳过这些验证。
二、坑一：看到 429 就切备用
429 不只意味着"请求太快，稍后重试"。OpenAI 的错误码文档还列出了额度耗尽、项目或组织支出上限等不同情况。只看 HTTP 状态码就自动切换，可能掩盖真正需要处理的配置或账单问题。来源：OpenAI 错误码文档
较稳妥的切换起点
比较稳妥的起点是：
- 短暂网络故障、可重试的服务端错误：在请求允许重放时，考虑备用通道。
- 临时限流：先看错误详情和
Retry-After，再判断等待是否会超过业务截止时间。
- 参数错误、
401/403、安全拒绝、额度或预算耗尽：不要盲目切换，先解决原因。
- 无法归类的错误：默认不自动切换。
故障切换规则应基于错误原因，而不只是状态码。
三、坑二：超时后，直接把整个 Agent 任务重跑
假设模型只做一次"只读的文本分类"，结果尚未被使用，请求超时后或许可以安全重试。
但如果 Agent 已经调用工具、写入数据库或发出通知，客户端没收到响应，并不能证明动作没有发生。此时换通道重跑，可能造成重复写入、重复发送。流式输出已经交给下游的请求，也不能假定能在另一条通道上接着生成。
只读步骤与 Agent 会话的区别
OpenAI 特别区分了这种只读推理步骤与持续运行的 Agent 会话：切换提供方不会自动迁移会话状态，也不会核对之前动作的结果 。遇到执行结果不明的操作，应先核对状态、处理幂等性，再决定如何恢复。来源：OpenAI Docs 官方开发者文章
四、坑三：SDK、应用和网关各重试两次
重试还可能在不同层悄悄叠加。应用代码重试、SDK 自动重试、网关渠道重试如果互不知情，一次用户请求就可能产生远超预期的上游调用。
重试在不同层叠加
因此，生产环境要明确由哪一层控制重试，给整个业务请求设置总尝试次数和总耗时上限 。收到有效的 Retry-After 时遵循它；否则使用有上限的退避策略。备用通道也要提前验证容量，不能等主通道故障时才发现它同样繁忙。来源：OpenAI Docs 官方开发者文章
五、可以先做什么？从一个只读请求开始
如果项目需要接入多个模型，统一 API 入口可以先减少客户端对不同地址和鉴权方式的硬编码。下面是一个使用 OpenAI Python SDK 调用 Genvis AI 兼容入口的单次连通性示例：
用统一入口做单次连通性验证
这段代码只验证"当前模型能否通过统一入口正常调用"，不代表已经实现自动跨模型或跨提供方容灾。真正上线前，还需要逐项确认：
上线前逐项确认
- 哪些业务步骤是只读、可重放的？
- 哪些错误允许重试，哪些必须立即停止？
- 备用模型的输出质量、接口能力和数据要求是否通过测试？
- SDK、应用和网关是否共用一套重试预算？
- 主备通道都失败时，是排队、降级，还是明确返回失败？
我的结论是：统一接入解决的是"怎么调用多个渠道"；安全故障切换解决的是"这个请求此刻能不能再执行一次"。先把后一个问题回答清楚，再开启自动切换，才是真正对生产业务负责。