标准回答
第一步：抽象统一接口
写一层 adapter，把「发消息、流式、function calling」等能力封装成统一的内部接口，每家供应商写一个适配器处理各自的请求体、鉴权、响应格式。业务代码只依赖内部接口，换供应商不用改业务。
第二步：路由策略
给每个供应商定优先级或权重，按维度路由：成本敏感的批量任务走便宜模型，复杂推理走能力强的，再叠加可用性（实时健康状态）。可以配主备模式，也可以按比例灰度。
第三步：自动 failover
每次调用设超时，主供应商超时或返回 5xx 时，自动重试到备用供应商（注意幂等）。配健康检查定期探测各通道，连续失败的暂时摘除，恢复后再放回。
第四步：兼容性与监控
各家的参数名、上下文上限、function calling 格式、内容审核策略都不同，prompt 可能要按供应商微调。分通道监控成功率、P95 延迟、成本和输出质量，发现某家劣化就调权重或下线。
常见误区
⚠️ 常见踩坑
以为换供应商只是改个 baseURL——实际各家的参数、能力边界、prompt 效果和返回格式都有差异，不做适配和回归测试，切过去后输出质量可能明显下降。
追问
追问 1：failover 切换后输出风格不一致怎么办？
主备模型风格难完全一致，可接受范围内优先保可用性。要减小差异：为每家维护适配过的 prompt、统一输出格式约束（如强制 JSON schema）、对关键场景做跨供应商的回归评测，把风格差异控制在业务可接受范围内。
追问 2：怎么避免 failover 把故障放大？
主供应商挂了全量切到备用，备用可能被瞬时流量打垮。要给备用也加限流和并发上限，failover 时配合熔断和降级（必要时返回兜底文案），并对切换设比例上限或渐进放量，而不是一刀切全量倒灌。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。