核心结论避免锁定不是拒绝厂商特性，而是把不可移植部分限制在清晰、可替换的边界里。
锁定通常发生在接口之外
更换 Base URL 很容易，真正难迁移的是 Prompt 中隐含的模型习惯、供应商专属工具格式、批处理脚本、监控字段、缓存策略和团队操作流程。只有 SDK 抽象而没有数据与运营抽象，仍然会被深度绑定。
划分稳定层与特性层
稳定层描述任务、输入资产、输出约束、预算和追踪。特性层保存模型专属参数，并明确默认值和替代行为。当专属能力不可用时，系统应该知道是降级、换模型还是停止，而不是静默产生不同结果。
- Prompt 模板与模型配置分离。
- 结果文件复制到自有存储。
- 使用内部 request_id 串联供应商任务。
- 将错误归一化，同时保留原始错误用于诊断。
- 计费与模型名通过配置映射，不写死在业务逻辑中。
定期做可切换演练
备用供应商只有在真实验证后才是备用。每月把一小部分脱敏流量发送到第二条路线，比较质量、延迟和错误，并确认团队知道如何切换。ModelRush 的多模型路由可以把这种演练变成持续评测，而不是事故当天的临时迁移。
接受有意的锁定
某些能力可能带来足够大的产品优势，值得使用专属接口。关键是记录决策：获得了什么、依赖了哪些字段、替代方案是什么、迁移需要多久。可见且可量化的锁定是一项商业选择；无人知晓的锁定才是风险。
比较可调用模型
按能力、输入输出、价格与区域可用性把文章中的选型方法用于真实模型。继续阅读
围绕相邻决策继续构建你的多模型技术栈。
