适合已经用 OpenAI 官方 SDK 或兼容格式写好应用、准备换用另一个接口的开发者，也适合需要同时接多个模型来源的团队。如果应用依赖某家厂商的专有功能（比如特定的文件接口或助手接口），需要单独评估。
代码里要改的三处
以 Python 官方 SDK 为例，改动集中在创建客户端的地方：
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.example.com/v1", # 换成新接口的地址
api_key=os.environ["MODEL_API_KEY"], # 密钥从环境变量读取
)
resp = client.chat.completions.create(
model="<模型名>", # 换成新接口里的模型标识
messages=[{"role": "user", "content": "你好"}],
)
print(resp.choices[0].message.content)
print(resp.usage) # 记录用量，用于对账
上面的地址只是示例，接口地址和模型名以接口方提供的为准。三条原则：
- 地址和密钥放在配置里，不写死在代码中，方便切换和回退。
- 密钥只放环境变量或密钥管理系统，不提交到代码仓库，不发在聊天里。
- 模型名做成映射表，业务代码里用自己的别名，换来源时只改映射。
逐项核对的功能清单
对照应用实际用到的功能，每一项都用真实请求测一次：
| 功能 | 要核对什么 |
|---|---|
| 基本对话 | 多轮消息、系统提示是否按预期生效 |
| 生成参数 | temperature、top_p 的取值范围；输出上限参数名是 max_tokens 还是 max_completion_tokens |
| 流式输出 | 分片格式、结束标记；流式时是否返回用量 |
| 函数调用 | tools 定义格式、并行调用、tool_choice 是否支持 |
| 结构化输出 | JSON 模式或 JSON Schema 是否支持，失败时的表现 |
| 多模态输入 | 图片等输入的格式与大小限制 |
| 向量接口 | embeddings 是否提供，维度是否与现有索引一致 |
| 用量字段 | usage 里的各项是否齐全，缓存 Token 是否单独列出 |
| 错误码 | 限流、超时、内容拦截分别返回什么状态码和消息 |
不支持的参数，有的接口会报错，有的会静默忽略。静默忽略更危险，测试时要确认参数确实生效。
错误处理与重试
迁移后最容易出问题的是异常路径，而不是正常请求：
- 限流（429）：按指数退避重试，并设置最大重试次数；不要立即无限重试。
- 服务端错误（5xx）：可以重试，但要确认请求是否已经计费。
- 超时：区分连接超时和读取超时；长输出请求的读取超时要放宽。
- 内容拦截：不同接口的拦截规则和返回格式不同，应用要能给用户一个明确提示。
- 记录请求标识：每次请求记录时间、模型名、用量和接口返回的请求编号，出问题时便于对账和排查。
上线怎么切
- 影子测试：生产请求复制一份发到新接口，只记录不返回给用户，对比结果和延迟。
- 小比例切流：先切 5% 到 10% 的流量，观察错误率、延迟和用户反馈。
- 保留回退开关：配置里随时可以切回原接口，回退不需要重新发布代码。
- 逐步扩大：每次扩大前确认前一阶段的指标正常。
- 对账：切换后第一个结算周期，核对自己记录的用量与账单。
迁移时常见的四个疏忽
- 只测一条请求就上线：正常请求通过不代表流式、函数调用和异常都正常。
- 模型名直接写在业务代码里：每次换模型都要改代码、重新发布。
- 忽略静默忽略的参数：比如设置了输出上限却没生效，费用会超出预期。
- 没有回退方案：新接口出问题时，只能临时改代码。
常见问题
兼容接口能用官方 SDK 吗？
通常可以，把 SDK 的接口地址改成新地址即可。但 SDK 新版本加入的功能，兼容接口不一定同步支持，升级 SDK 后要回归测试。
同一个模型在不同接口上效果一样吗？
不一定。部署方式、默认参数、上下文限制都可能不同。用同一批样本对比结果，不要假定相同。
迁移需要多长时间？
代码改动通常很小，时间主要花在测试和逐步切流上。功能用得越多，需要核对的项目越多。
易AI能提供哪些模型？
可用模型以模型服务页列出的产品入口和实际沟通为准。企业用量、结算方式需要单独确认。
参考资料
官方资料用于核对产品或通用概念，不构成对易AI的授权、认证或背书。具体合作以双方确认的方案为准。