openai 兼容格式的 api，一次讲清做法、成本和注意点（「兼容」到底兼容到哪一层）

同一个 SDK 想接三家中转站，结果有的通有的报 404、有的字段被吞、有的流式一半就断——问题多半不在你代码，而在于你对「兼容」这两个字的预期。这篇按含义、请求结构、成本、迁移注意点四块讲清楚，每个环节都给出可以直接照着做的检查动作。

同一个 SDK 想接三家中转站，结果有的能通、有的直接 404、有的字段被悄悄吞掉、有的流式返回一半就断——这类问题多半不在你的代码，而在你对「兼容」这两个字的预期。兼容格式只是一种约定，不同服务商执行到什么程度，得自己验证。

下面按兼容的含义、请求结构、成本核算、换站落地四块讲清楚，每一步都给出能直接照着做的检查动作。适合手里已经有一两个中转站、准备再接第三家的开发者；如果你只接一家并且不打算换，可以跳过迁移那节。

「兼容」到底兼容到哪一层

所谓兼容，指的是请求路径、鉴权头、请求体字段名和响应结构大致对齐，并不等于模型能力、限流策略、错误码细节也一致。照官方 SDK 写代码能跑通，只说明外壳对齐；字段被静默忽略，才是换站之后最常见也最难查的隐性故障。

• 判断标准一：同一段请求分别打到两家，比对原始响应 JSON 的字段是否齐全，而不是只看有没有返回内容
• 判断标准二：请求里塞一个不常用的可选字段，看对方是报错、还是照收却不生效
• 判断标准三：故意发一次错误参数，看错误返回结构是否和官方一致，这决定了你的异常处理能不能通用
• 不适用的情形：你用的是厂商私有协议，比如某些原生多模态或文件接口，本来就绕开了兼容层，不必按这套标准要求它

请求结构逐项对照：哪些字段必须对，哪些看运气

把字段分两档看：必须稳定对齐的，和被吞了你也未必立刻发现的。前者对不上，请求直接失败；后者对上了表面正常，业务逻辑却悄悄走偏，比如工具调用没触发、结构化输出退化成纯文本。

每次换站先跑三条最小请求：纯文本、带工具定义、带流式开关，三条都过再谈接业务。三条里有任何一条不通过，就先停在这一步，别急着把业务流量切过去。

1. 第一步：看 HTTP 状态码先区分是路径或鉴权问题（4xx）还是服务端问题（5xx），这一步能筛掉大半配置错误。
2. 第二步：看响应体里有没有 error 字段有些站状态码给的是成功，错误却藏在响应体里，只看状态码会误判。
3. 第三步：才怀疑模型本身前两步都干净、返回内容却不对，再去看是不是模型名映射或参数被改写，排查顺序反过来会浪费很多时间。

成本怎么看：别只盯单价

成本由三块构成：输入输出 token 的实际计费口径、失败重试带来的浪费、以及被截断后重发的重复消耗。只比单价，很容易得出错误的结论——便宜的那家如果重试率高，最后总账未必更低。

• 不同中转站对缓存、图片、工具调用结果的计费口径可能不同，接入前先在站内核对当期的价格与规格说明
• 拿固定的几条真实样本跑一轮，把用量日志记下来做基线，之后换站才有可比口径
• 把失败重试单独计数，重试率高的服务商要在总成本里一并算进去
• 不适用：短文本、低频调用的小工具，核算成本花的时间本身比省下的钱还多，直接估个上限就够

具体单价和计费细则各家都在变，别凭记忆写进项目文档，需要时到站内的价格追踪页看当时的数字，再乘以你自己的调用量做估算。

换站、加站时的落地清单

迁移出问题，多半不是新站不行，而是代码里把地址、密钥、模型名写死了，换的时候漏改一处。把这三样做成配置项，换站只改一个地方，出问题也好回滚。

1. 抽配置Base URL、鉴权方式、模型名统一放进配置，代码里不再出现硬编码；验证方法是在配置里换个站跑一次，看是否只改一处就生效。
2. 写冒烟脚本覆盖非流式、流式、工具调用三条路径，接新站先跑它，全过再放业务流量。
3. 错误码分类处理鉴权失败不重试，限流和超时走退避重试，参数错误直接暴露给上层，别用一个 catch 全兜住。
4. 定主备关系多站并存时写清谁是主、谁在什么条件下降级，别让两家的限流策略互相打架。

顺带提一句流式：一些站的流式实现会在异常时直接断开而不给结束标记，客户端要有超时和收尾逻辑，否则界面会一直停在加载状态。这类问题冒烟脚本里加一条流式用例就能提前发现。