一场 7 天的全集团切换，暴露了什么
7 月 3 日，阿里巴巴向全集团下发了通知：7 月 10 日起全面禁用 Claude 全系产品，替代方案为通义千问与自研 Qoder。20 多万员工，7 天，必须切完。
从技术视角看，这不是一个简单的「换 API endpoint」问题。Prompt 模板的适配差异、stop sequence 的厂商特定格式、thinking 等独有参数——这些集成深度决定了切换成本远高于改一行 URL。测试、上线、验证，两周算顺利的。
但这件事真正值得关注的不是阿里有多快，而是一个更底层的架构问题：为什么我们的业务代码和模型供应商是硬绑定的？
切换成本的本质：集成深度
大多数技术团队调模型的方式可以概括为三步：
1. 代码里硬编码 api.openai.com 或 api.anthropic.com
2. Key 从环境变量读取
3. 请求直发供应商服务器
这套架构的问题在于：当你需要切换供应商时，切换的不是一个配置项，而是一次代码变更。
具体来说，切换成本集中在三个层面：
Prompt 适配层。Claude 和 DeepSeek 对同一段提示词的输出结构、语气、粒度差异显著。调试数十轮的 Prompt 模板在新模型上需要重新验证，这不是 promptfoo 跑一遍就能过的。
参数兼容层。Anthropic 特有的 thinking 字段、特定的 stop sequence 格式，这些厂商私有参数硬编码在业务逻辑里，切模型意味着改代码。
监控对接层。告警规则、token 统计、返回头解析——这些基础设施按特定供应商格式搭建，切换后需要重新适配。
持有 5 个供应商的 Key 和「随时能切走」是两回事。切换成本不在注册环节，在集成深度。
解法：抽象出一层路由
本质上，我们需要做的是把「用什么模型」这个决策从代码里拿出来，放到一个可以随时改的地方。
# 之前：业务代码直连供应商
client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_KEY"])
response = client.messages.create(model="claude-sonnet-4-20250514", ...)
# 之后：通过路由层调用
response = ai_proxy.call(
logical_model="code_generation", # 逻辑模型，非物理模型
messages=[...]
)
这层的核心设计思路是一个逻辑模型映射表：
| 逻辑模型 | 当前供应商 | 备用供应商 |
|---|---|---|
| code_generation | claude-sonnet-4 | qwen-coder |
| long_context | claude-opus | qwen-max |
| reasoning | claude-sonnet-4 | deepseek-r1 |
当供应商不可用时，管理员在控制面改一条映射，业务侧无感知。不需要改代码、不需要通知全组换环境变量、不需要重新调试 Prompt。
这件事为什么重要
从 Anthropic 去年 9 月的禁令升级到最近的封号范围扩大，供应商单方面断供已经不是技术假设，而是可观测的风险模式。
企业做技术选型时通常考虑性能、价格、生态，很少把「切换成本」作为一级指标。但当一个供应商从可用到不可用的窗口只有一封邮件那么短时，架构层面的解耦就不再是过度设计了。
这不是让你今天就把 Claude 换成通义千问。是让你下次写调用代码的时候，在中间留一层。
实践建议
- 统一调用入口：业务代码不直接依赖任何供应商 SDK，所有模型调用通过统一接口
- 逻辑模型抽象：用「代码生成」「长文本分析」等业务语义替代
claude-sonnet-4等物理模型名 - 路由可配置：映射关系从配置文件读取，支持运行时热切换
- 凭证集中管理：所有 API Key 统一管理、轮换、审计，不散落在各业务的环境变量里
留了这一层，切换是改配置的事。没留，切换是改代码的事。中间差的不是技术复杂度，是时间窗口。
