CC Switch 的本机多模型路由实践

本文记录一次本机开发环境的配置过程。重点是怎样把多个模型接口放到同一个兼容层后面，减少重复修改配置的次数。示例只使用本地地址和脱敏参数，具体字段以当前版本文档为准。

我遇到的问题

我在日常开发中会切换不同的模型服务。每个工具的配置位置不同，有的写在设置文件里，有的写在环境变量里，还有的需要重启插件才能生效。切换一次模型，常常要重复改接口地址、模型名称和密钥变量。

我希望把这几个变量集中管理，同时保留一个简单的回退路径。这样做的判断标准有三个。请求能否返回，模型切换是否可追踪，原有工具能否在路由层停止后恢复原配置。

本机路由层的工作方式

CC Switch 在我的测试环境中承担本地路由层的角色。开发工具只连接本机地址，具体的服务商配置由路由层读取。一次请求的大致路径如下。

IDE 或脚本
    ↓
本机兼容接口
    ↓
模型配置与路由规则
    ↓
选定的模型服务

这层结构的价值在于把工具配置和服务商配置分开。工具只需要知道本机地址，切换模型时不必逐个修改 IDE 设置。

配置一个最小 Provider

下面是脱敏后的配置示例。真实密钥放在系统密钥链或环境变量中，不能写进文章、截图或代码仓库。

{
  "name": "provider-a",
  "baseUrl": "PROVIDER_BASE_URL",
  "apiKeyEnv": "MODEL_PROVIDER_A_KEY",
  "model": "model-a"
}

如果路由程序支持多个 Provider，可以再添加一个配置对象。每个对象只保留名称、接口地址、密钥变量名和默认模型，避免把凭据直接写进配置文件。

在开发工具中接入本机接口

以支持 OpenAI 兼容协议的工具为例，配置项通常包含三部分。

接口地址：
LOCAL_ROUTER_BASE_URL

模型名称：
由路由层当前选择的模型决定

密钥字段：
使用本机环境变量，不填写真实密钥到项目文件

配置后先用一个短请求测试，不要直接把长任务交给新路由。测试内容包含模型列表、简单问答和一次超时处理，三项都通过后再接入日常工作流。

回退与故障判断

本地路由层出问题时，最容易误判成模型服务故障。我把排查顺序固定为四步。

1. 检查本机端口是否在监听。
2. 请求模型列表接口，确认路由层能返回数据。
3. 发送一个最短请求，记录状态码和响应时间。
4. 临时绕过路由层，用原始配置做一次对照测试。

下面的命令只用于本机诊断，输出结果中不要包含密钥。

curl -sS "$LOCAL_ROUTER_BASE_URL/models" \
  -H "Authorization: Bearer $LOCAL_ROUTER_KEY"

如果第四步成功而第二步失败，问题在本地路由层。如果第二步成功、第三步超时，应检查路由规则和上游服务的响应时间。这样的分层排查，比反复修改 IDE 配置更容易定位原因。

我保留的限制

不同服务对工具调用、上下文长度和流式输出的支持不完全一致。路由层能统一接口，不代表所有模型的行为完全相同。遇到结构化输出或工具调用时，我会先用目标模型做小样本验证，再决定是否切换。

本文没有把某个模型称为“最好”，也没有用未经验证的成功率或成本数字做结论。配置字段和端口只是示例，读者应当根据自己安装的版本和官方文档调整。

小结

本机多模型路由解决的是配置重复问题。它适合需要频繁切换模型的开发环境，但仍然需要密钥隔离、请求对照和故障回退。把这些检查步骤固定下来，切换模型才不会变成新的不确定因素。