“代码只处理理想响应，就已埋下生产事故。”这种说法听起来偏激，但无数整合OpenAI的开发者用亲身经历验证了它——压测通过、演示顺畅，然后某天接口突然返回429，或者模型名失效，整个服务直接崩盘。一次成功的请求在日志里像证据一样躺着，证明“系统稳定”，但这恰恰是假象：它只验证了这次碰巧一切参数都对。

真正“抗造”的调用远不止拿到200和一段文本。如果切换模型配置就得改业务代码，如果连速率限制都没被归类处理，那么所谓“集成完毕”不过是把定时炸弹包了一层熟宣。反过来想，OpenAI的SDK本身已经为我们做好了异常分层和默认重试，大部分团队却没有让这些能力在自己的代码里“显形”。

打开网易新闻 查看精彩图片

一个最小化的适配器可以用三次测试说清问题。第一种走正常响应流，第二种故意触发错误，第三种在测试里更换模型配置再触发错误。三个场景分别验证，并把结果写进同一本日志：一次成功，一次异常链完整捕获，一次证明不碰业务逻辑也能完成降级切换。日志的价值不是记录事件，而是把集成点劈成两半——左边是客户端自己能兜住的，右边才是必须由我们写代码处理的。没有这种分割，“能跑”和“持久抗造”就永远是一个词。

那么SDK到底给了什么？按照openai/openai-python仓库的文档，库的异常体系以openai.APIError为根，分出两条主分支：APIConnectionError捕捉网络、代理和SSL层面的问题；APIStatusError则对应一切非2xx响应，直接暴露status_code和原始response。再往下，400、401、403、404、422、429和≥500的状态码都有专用子类，连超时都有单独的APITimeoutError。不用自己对着状态码写if-else，异常名称本身已经替你完成分类。

别忘了客户端自带退避重试。默认情况下，对连接错误、408、409、429以及所有5xx会发起最多两次短指数退避重试，可以在初始化时通过max_retries参数调大，也能在单次调用上.with_options(max_retries=N)覆盖。这层内置策略已经吃掉大量抖动，只是少有人主动确认它在自己场景里的行为。

最终验金石只有一条：当切换模型或处理新异常时，需不需要改动计算折扣、拼接提示词之类的核心逻辑？如果动了，就暴露了适配器契约失效——这说明隔离根本没做到位。反之，只需改一处配置、日志自动记下切换痕迹，这才是真正可验证的稳健。与其迷信一次成功的‘证明’，不如让错误场景在可观察的日志里反复重现，直到每一次降级路径都变成例行公事。