CC Switch 不只是切换 API：从 GitHub 更新日志看懂它的功能和底层原理

很多人第一次看到 CC Switch，会先把它理解成一个“Claude Code / Codex 供应商切换工具”。

这个理解没有错，但已经不够了。

如果只看早期版本，CC Switch 确实主要是在帮用户少改几个配置文件：Claude Code 用哪个 API，Codex 用哪个 API，切换时把对应的 settings.json、auth.json、config.toml 写进去。可是如果沿着它的 GitHub Releases 一路看下来，尤其是从 v3.1.0 到 v3.16.1，就会发现这个工具已经变成了一个更完整的 AI 编程工具管理面板。

它现在关心的已经不只是“把 Key 写到哪里”，而是：

• 多个 AI CLI 工具怎样统一管理
• 多个 API 供应商怎样安全切换
• 本地代理怎样接管请求
• 不同 API 协议之间怎样转换
• MCP、Prompts、Skills 怎样跨工具同步
• 会话、用量、成本、模型映射怎样被统一记录
• 官方登录态和第三方 API 怎样尽量同时保留
• 复杂配置切换时怎样避免覆盖、丢失和损坏

所以这篇文章不按普通软件介绍来写，而是按 GitHub 更新日志反向解读：CC Switch 到底有哪些功能，这些功能背后的设计逻辑是什么，它对我们这类重度使用 Claude Code、Codex、Gemini CLI 等 AI 编程工具的人到底有什么意义。

一、先总览：CC Switch 到底是一个什么工具？

按照项目 README 的定位，CC Switch 是一个面向 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 和 Hermes Agent 的桌面管理工具。

它的核心目标很明确：把原本分散在不同目录、不同格式、不同工具里的 AI 编程配置，收拢到一个统一界面里管理。

简单说，它主要做六类事情。

第一类是供应商管理。

也就是管理不同 API 服务商、不同模型、不同 base URL、不同 API Key，并且支持一键切换。早期 CC Switch 更像是“Claude Code 供应商切换器”，后来逐步加入 Codex、Gemini CLI、OpenCode、OpenClaw、Hermes。它还内置了大量供应商预设，减少用户手动配置成本。

第二类是配置文件同步。

不同工具的配置格式不一样。Claude Code 常见的是 ~/.claude/settings.json，Codex 是 ~/.codex/auth.json 和 ~/.codex/config.toml，Gemini、OpenCode、OpenClaw、Hermes 又有自己的配置入口。CC Switch 的作用不是让这些工具改变自己的规则，而是在切换时替用户把正确配置写回对应工具的 live 文件。

第三类是本地代理和路由。

这是后期版本最重要的方向之一。CC Switch 不只是写配置，还可以启动本地代理，让目标工具先请求本地代理，再由本地代理转发到真正的上游供应商。这样就能做格式转换、热切换、故障转移、健康检查、请求修正、模型映射等更高级的事情。

第四类是跨工具能力管理。

比如 MCP、Prompts、Skills。原来这些东西可能分别写在 Claude、Codex、Gemini 或其他工具自己的配置里。CC Switch 把它们抽象成统一面板，支持添加、启用、同步、导入、安装。对长期维护 AI 工作流的人来说，这比单纯切换模型更重要。

第五类是会话和用量管理。

CC Switch 后来加入了会话管理器、用量仪表盘、Token 统计、成本追踪、请求日志、模型定价等能力。也就是说，它开始从“配置工具”变成“AI 编程使用记录和成本观察工具”。

第六类是安全性和稳定性保护。

这也是更新日志里反复出现的主题：SSOT 单一事实源、SQLite 数据库、原子写入、自动备份、迁移归档、回填保护、并发锁、接管状态判断、官方 OAuth 保留、模型目录防丢失。这些看起来没有“新功能”那么显眼，但是真正决定了工具能不能长期用。

如果用一句话概括：

CC Switch 的本质，是一个围绕 AI 编程工具配置、供应商、代理、能力和使用数据建立起来的本地控制台。

二、供应商切换：从“复制配置文件”进化到“统一供应商系统”

CC Switch 最容易理解的功能，就是切换供应商。

比如同一个 Claude Code，今天想用官方 Claude，明天想用某个中转，后天想换成 Bedrock 或其他兼容接口。如果手动改配置，就要反复处理 API Key、base URL、模型名、环境变量、认证方式。用久了之后，最麻烦的不是改一次，而是“改完之后不知道现在到底是哪一套配置在生效”。

从更新日志看，CC Switch 早期就是为了解决这个问题。

v2.0.3 还主要是 Claude Code 供应商切换，并增加 DeepSeek v3.1 这类预设。v3.1.0 开始新增 Codex 供应商管理，一键切换 ~/.codex/ 下的配置。v3.2.0 则是一个关键节点：它引入 SSOT 架构，不再长期依赖“每个供应商一份副本文件”的方式，而是把供应商数据统一收进 CC Switch 自己的配置系统。

这个变化非常重要。

早期的切换逻辑可以理解成：

供应商 A -> auth-A.json / config-A.toml
供应商 B -> auth-B.json / config-B.toml
切换时复制到 auth.json / config.toml

这种方式直观，但时间长了容易出现几个问题：

• 副本越来越多
• 哪个副本是最新的不好判断
• 用户手动改了 live 文件以后，副本不一定同步
• 迁移和回滚复杂
• 多应用、多平台、多窗口场景下更容易乱

所以 v3.2.0 之后，CC Switch 转向“单一事实源”：

供应商数据 -> CC Switch 自己的主配置 / 数据库
切换时 -> 写回目标工具 live 配置文件
编辑当前供应商时 -> 必要时从 live 文件回填

这个设计背后的思想是：不要让多个副本同时假装自己是真相。

真正的供应商数据集中保存，目标工具的配置文件只是当前生效投影。切换时把投影写出去，读取时再把用户可能手动改过的 live 配置回填回来。

后来 README 里进一步说明，当前版本的数据主要存储在 ~/.cc-switch/cc-switch.db，也就是 SQLite 数据库里；设备级偏好则放在 ~/.cc-switch/settings.json。这说明 CC Switch 已经从简单 JSON 配置时代，进入了更标准的本地应用数据管理阶段。

三、支持的工具：从 Claude Code、Codex 扩展到多应用管理

CC Switch 的另一个变化，是管理对象越来越多。

从 release 线索看：

• v3.0.1 重点仍在 Claude Code，并完成从 Electron 到 Tauri 2.0 的迁移
• v3.1.0 加入 Codex 供应商管理
• v3.5.0 开始直接管理 Claude MCP 服务器配置
• 后续版本不断扩展 Gemini、OpenCode、OpenClaw 相关能力
• v3.14.0 增加 Hermes Agent 支持
• v3.15.0 把 Claude Desktop 也作为一等管理对象处理
• v3.16.0 的“受管 CLI 工具管理”已经覆盖 Claude、Codex、Gemini、OpenCode、OpenClaw、Hermes

这说明 CC Switch 的定位已经从“某一个工具的切换器”，变成“多个 AI 编程入口的控制面板”。

为什么这件事重要？

因为现在很多人的 AI 编程工作流不是只用一个工具。

可能是：

• Claude Code 负责日常代码修改
• Codex 负责某些工程任务和插件能力
• Gemini CLI 负责长上下文或特定模型场景
• OpenCode / OpenClaw 负责开源 Agent 工作流
• Hermes 负责另一类本地 Agent 配置
• Claude Desktop 又承担桌面 MCP 和日常助手入口

如果每个工具都单独维护供应商、MCP、提示词、技能、会话和成本，实际成本会越来越高。CC Switch 做的事情，就是在这些工具上面加一层统一管理。

这层统一管理不是替代原工具，而是做三件事：

1. 读懂各工具原有配置格式
2. 用统一数据库保存可复用数据
3. 在用户切换或同步时写回各工具自己的 live 文件

这也是它能保持“最小侵入”的原因。卸载 CC Switch 后，目标工具的配置文件还在，工具本身仍然能运行。

四、本地代理与路由：CC Switch 后期最关键的能力

如果只写配置文件，CC Switch 只是一个配置管理器。

但从 v3.14、v3.15、v3.16 的更新日志看，它真正变复杂的地方在本地代理和路由。

所谓本地代理，可以这样理解：

Claude Code / Codex / Gemini
        |
        v
本地 CC Switch Proxy
        |
        v
真实上游供应商

目标工具以为自己在请求某个 API 地址，实际上请求先进入 CC Switch 的本地代理。代理再根据当前供应商、模型映射、请求格式、健康状态，把请求转发给真正的上游。

这样做的好处是，CC Switch 不再只能“静态切换配置”，而是可以在请求过程中做动态处理。

比如：

• 将一种 API 协议转换成另一种协议
• 根据上游状态做故障转移
• 对请求字段做修正
• 对响应事件做重建
• 统计用量和成本
• 在本地热切换供应商
• 保留目标工具认为自己需要的配置形态

这也是为什么 v3.16.0 里会重点讲 Codex Chat Completions 路由。

Codex 原本使用的是 OpenAI Responses 相关形态，而很多第三方供应商提供的是 OpenAI Chat Completions 兼容接口。二者不是简单换个 URL 就能完全兼容。请求格式、流式事件、工具调用、reasoning、usage、错误返回，都可能不一样。

所以 CC Switch 在本地代理里做了转换：

Codex Responses 请求
        |
        v
转换为 Chat Completions 请求
        |
        v
第三方 Chat Completions 上游
        |
        v
返回 JSON / SSE
        |
        v
重建为 Codex 能理解的 Responses 形态

这就是 v3.16.0 里“你可以在 Codex 里使用 DeepSeek、Kimi、GLM”的关键。

表面看，是多支持几个供应商。

底层看，是 CC Switch 在本地做了协议适配层。

五、Codex 增强：为什么 v3.16.0 和 v3.16.1 特别重要？

最近两个版本对 Codex 用户尤其重要。

v3.16.0 的重点，是让 Codex 第三方供应商通过 Chat Completions 路由成为一等公民。也就是说，第三方供应商不再只是“勉强填个 base URL 试试”，而是有了专门的路由开关、模型映射表、reasoning 识别、Stream Check、格式转换和历史统一。

这里面最关键的功能有几个。

第一，Codex Chat Completions 路由。

它解决的是 Codex 与第三方 Chat API 协议不一致的问题。没有这层转换，很多供应商即使模型能力足够，也不能稳定接入 Codex。

第二，Codex 模型映射表。

很多第三方供应商的模型名和 Codex 期望看到的模型名不一致。模型映射表的意义是把“工具侧模型名”和“上游真实模型名”分开。用户在 Codex 里看到或选择一个模型，代理实际请求时可以映射到供应商支持的另一个模型。

第三，Codex reasoning 自适应。

不同上游对 reasoning、thinking、<think>、工具调用历史的表达方式不同。CC Switch 需要识别并转换这些内容，否则轻则丢思考过程，重则后续轮次工具调用上下文断掉。

第四，Codex Goal Mode 与远程压缩控制。

这类功能说明 CC Switch 不是只在处理 API Key，而是在适配 Codex 自己的高级会话能力。

第五，第三方供应商身份与历史统一。

v3.16.0 提到第三方 Codex 供应商统一进入稳定的 custom model-provider 桶，并迁移历史 JSONL 会话和 state_5.sqlite 线程。这个点很细，但很重要。

因为模型供应商切换不只是当前请求的问题，还会影响历史会话归属。如果历史里记录的 provider id 乱了，后续恢复会话、继续上下文、统计用量都会受影响。统一身份桶，本质上是在修复“切换配置”和“会话历史”之间的关系。

v3.16.1 则更像是 v3.16.0 之后的稳定性补丁。

它最重要的变化是：Codex 官方认证保留变成可选开关，默认关闭。

这个问题的背景是，Codex 既可能有官方 ChatGPT / Codex OAuth 登录态，又可能通过第三方供应商走 API Key。如果切换第三方供应商时直接覆盖 auth.json，就可能破坏官方登录态；但如果默认改变写入方式，又可能影响老用户预期。

所以 v3.16.1 采用了比较保守的方式：

• 默认保持旧行为
• 用户需要时手动开启“Codex 应用增强”
• 开启后，官方 OAuth 留在 auth.json
• 第三方 token 写入 config.toml 的 provider-scoped 字段

这背后的设计取舍很典型：功能更强，但默认不惊扰已有用户。

v3.16.1 还修复了 Codex 模型目录被清空、工具和插件路由恢复、本地路由接管状态误判、编辑弹窗读取 live OAuth、代理错误诊断不足等问题。这些问题看似零碎，其实都指向同一个核心：一旦 CC Switch 进入本地代理和接管 live 配置的阶段，就必须非常清楚“谁是真实数据，谁只是临时投影”。

六、MCP、Prompts、Skills：真正提高长期工作流复用性的部分

CC Switch 另一个容易被低估的功能，是 MCP、Prompts 和 Skills 管理。

很多人刚开始只关心模型和 API，但用一段时间之后会发现，AI 编程工具的真正差异不只在模型，而在上下文能力。

比如：

• MCP 服务器决定工具能访问哪些外部能力
• Prompts / AGENTS.md / CLAUDE.md / GEMINI.md 决定工具的长期行为
• Skills 决定某些任务是否有标准化工作流
• 插件和连接器决定工具是否能进入更复杂的工程环境

如果这些东西每个工具单独维护，就会出现重复劳动：

• Claude Code 配了一套 MCP
• Codex 又要配一套
• Gemini 又要配一套
• 换电脑后还要重新搬
• 某个项目里改了提示词，另一个工具不知道

CC Switch 的做法，是把这些能力抽象成统一资源，再同步到各工具对应的 live 配置。

从 v3.5.0 的 Claude MCP 管理开始，到后面统一 MCP 面板、Prompts 跨应用同步、Skills 一键安装、多应用过滤、Deep Link 导入，可以看出它的方向是：让 AI 编程工作流不再完全绑定某一个客户端。

这里的原理可以理解为：

统一资源层
  - MCP servers
  - Prompts
  - Skills
        |
        v
按应用生成配置投影
  - Claude
  - Codex
  - Gemini
  - OpenCode
  - OpenClaw
  - Hermes

这和供应商管理的逻辑是一样的：数据库里保存抽象后的资源，目标工具里写入它能理解的配置。

这种设计的价值在于，它把“工具配置”提升成了“工作流资产”。

七、会话管理和用量统计：从能用到可观察

AI 编程工具用多了之后，还有两个现实问题。

一个是会话在哪里。

有时候一个项目的关键讨论在 Claude Code，有时候在 Codex，有时候又在 Gemini。过几天再想找，不一定记得是哪一个工具、哪一个目录、哪一次会话。

另一个是钱花在哪里。

多供应商、多模型、多订阅、多 API Key 并行之后，只知道“今天用了很多”，但不知道哪个供应商消耗多、哪个模型贵、哪个项目在烧 Token。

CC Switch 后续版本加入 Session Manager 和 Usage Dashboard，其实就是在解决这两个问题。

会话管理器负责浏览、搜索、恢复多个应用的历史会话。更新日志里还提到 Codex / OpenClaw 会话标题提取、Gemini Session Restore 路径、长会话列表虚拟滚动等细节。这说明它不仅是列出文件，还在处理会话元数据、项目路径、标题可读性和性能问题。

用量统计则包括：

• 请求数
• Token 用量
• 成本
• 趋势图
• 详细请求日志
• 模型定价
• 缓存命中率
• 托盘用量提示
• 自定义 usage script

这些能力的意义，是让使用者从“凭感觉用 AI”进入“可观察地用 AI”。

尤其是团队或重度个人用户，多供应商并行以后，如果没有统一统计，很容易出现两个问题：

• 以为某个供应商便宜，实际上因为上下文和重试导致消耗更高
• 以为某个模型慢，实际上是端点或网络路径有问题

CC Switch 的延迟测试、Stream Check、健康监控、用量看板，都是在帮用户把这些隐性成本显性化。

八、稳定性设计：为什么它反复强调 SSOT、原子写入、备份和锁？

看 CC Switch 更新日志，会发现一个特点：它很少只写“新增某功能”，经常会写大量迁移、备份、回滚、并发、接管、修复边角问题。

这不是啰嗦，而是因为它碰到的是配置管理里最麻烦的一类问题。

AI 编程工具的配置文件一般都在用户主目录下，而且很多都是 live 文件：

• 写错了，工具可能启动不了
• 覆盖了，官方登录态可能丢
• 写一半失败，配置可能损坏
• 两个操作同时写，结果可能互相覆盖
• 代理接管后，live 文件可能已经不是原始供应商配置
• 用户手动改了 live 文件，应用数据库又可能不是最新

所以 CC Switch 必须做很多保护。

第一，SSOT。

单一事实源解决的是“谁说了算”的问题。供应商、MCP、Skills 等核心数据集中存储，live 文件只是应用到目标工具的结果。

第二，原子写入。

原子写入一般是先写临时文件，再通过 rename 替换目标文件。这样可以避免写到一半程序崩溃，导致目标配置文件只剩半截。

第三，自动备份和轮转。

切换、迁移、导入、覆盖之前保留备份，出了问题可以恢复。但备份也不能无限增长，所以需要轮转，比如 README 提到保留最近若干备份。

第四，回填保护。

如果用户直接改了目标工具的 live 文件，CC Switch 不能无脑用旧数据库覆盖。合理做法是在编辑当前供应商或切换前，从 live 文件回填可能有价值的变化。

第五，并发锁。

v3.16.1 里提到供应商切换和接管开关按 app 串行执行。这个设计是为了避免两个流程同时修改同一份 live 配置。否则一个流程刚写入代理配置，另一个流程又恢复供应商配置，最终状态就乱了。

第六，接管状态判断。

本地代理接管后，live 配置可能临时指向 localhost 或代理占位符。这个时候判断“当前配置是谁管理的”不能只看代理服务是否运行，也不能只看 enabled 状态。v3.16.1 里提到结合备份和 live 中的代理占位符判断，就是在解决这个问题。

这些设计合起来，才让 CC Switch 能从“玩具级切换器”变成“可长期使用的配置控制台”。

九、协议转换：为什么不是所有兼容 API 都能直接用？

很多人容易有一个误解：只要供应商说自己兼容 OpenAI，就一定能接入所有工具。

实际不是。

“OpenAI 兼容”这个说法本身就可能有不同层级：

• 只兼容 Chat Completions
• 兼容 Responses
• 兼容流式 SSE，但事件字段不完整
• 支持工具调用，但工具调用格式不同
• 支持 reasoning，但字段名不同
• usage 返回不完整
• 错误格式和 HTTP 状态不规范

对普通聊天应用来说，这些差异可能还能凑合。但对 Codex、Claude Code 这类 Agent 工具来说，工具调用、流式事件、历史上下文、reasoning、cache key 都很关键。

所以 CC Switch 的本地代理不是简单转发，而是要做适配。

以 v3.16.0 / v3.16.1 的 Codex Chat 路由为例，它至少要处理这些问题：

• 把 Codex Responses 请求转换成 Chat Completions 请求
• 把 Chat Completions 返回转换回 Responses 事件
• 保留或重建工具调用
• 处理 tool_search、命名空间工具、自定义工具
• 处理流式自定义工具输入事件
• 保留 reasoning / thinking 信息
• 修复 usage 缺失或格式异常
• 规范化错误返回
• 做模型名映射
• 让 Stream Check 能按真实生产路径测试

这就是为什么 CC Switch 的更新日志里会有大量“某供应商工具思考历史规范化”“SSE 聚合”“空 tool_calls 修复”“usage 解析鲁棒性”之类的内容。

这些不是边角小问题，而是 Agent 工具能不能连续工作下去的关键。

十、官方登录态与第三方 API：v3.16.1 的取舍很有代表性

v3.16.1 里最值得单独拿出来讲的，是 Codex 官方认证保留。

这里面有一个现实矛盾：

很多用户既想保留官方 ChatGPT / Codex OAuth 登录，因为官方登录可能关联远程操作、官方插件、订阅能力；又想把模型流量切到第三方 API，因为第三方供应商可能便宜、可用、模型选择更多。

但配置文件层面，这两类东西可能会发生冲突。

如果第三方供应商切换直接改写 auth.json，就可能破坏官方 OAuth 登录态。

如果 CC Switch 默认强行改成另一种写入方式，又可能让老用户觉得行为突然变了。

所以 v3.16.1 的策略是：

• 增加官方认证保留设置
• 默认关闭
• 用户需要时手动开启
• 开启后第三方 token 写到 config.toml
• 官方 OAuth 缓存在 auth.json

这其实是一个很成熟的软件设计思路：新能力可以提供，但不应该默认改变老用户的关键配置写入语义。

对我们理解配置工具也有启发。

配置管理最怕的不是功能不够，而是工具自作主张。尤其是涉及认证文件、OAuth、API Key、官方订阅能力时，默认行为必须保守。

十一、从更新日志看 CC Switch 的进化路线

把几个关键版本串起来，CC Switch 的路线其实很清楚。

v2.x 阶段，它主要是 Claude Code 供应商切换工具，重点是 API Key 和预设供应商。

v3.0.1 从 Electron 迁移到 Tauri 2.0，应用体积、启动速度和跨平台形态更适合做本地小工具。

v3.1.0 加入 Codex 支持，开始管理 ~/.codex/auth.json 和 ~/.codex/config.toml。

v3.2.0 引入 SSOT、一次性迁移、归档、系统托盘、内置更新器、原子写入与回滚。这个版本基本奠定了后续“可靠配置管理”的底座。

v3.3.x 到 v3.5.x 开始加入通用配置片段、VS Code 同步、WSL 支持、MCP 管理、导入导出、备份轮转、延迟测试等能力。

v3.14.0 增加 Hermes Agent，并加强 Gemini Native API Proxy、Usage、Session、Skills、窗口控制等更广泛的管理能力。

v3.15.0 把 Claude Desktop 纳入管理面，强化反向代理、角色模型映射、Codex OAuth 模型发现、用量看板和供应商生态。

v3.16.0 把 Codex 第三方 Chat Completions 路由做成重点能力，同时扩展受管 CLI 工具生命周期、默认模型和供应商矩阵。

v3.16.1 则集中修复 v3.16.0 后真实使用中暴露的 Codex OAuth、模型目录、工具路由、本地接管、错误诊断等稳定性问题。

这条路线说明，CC Switch 的发展不是简单堆功能，而是在围绕一个中心持续展开：

让多 AI 编程工具、多供应商、多协议、多能力配置，变得可管理、可切换、可恢复、可观察。

十二、对我们的意义：AI 编程工作流需要一个“配置中台”

CC Switch 对我们的意义，不只是省了几次手动改文件。

更重要的是，它说明 AI 编程工具生态已经进入了一个新阶段。

早期我们关心的是“哪个模型更强”。后来开始关心“哪个工具更好用”。再往后，当工具和模型都越来越多时，真正的问题变成：

• 我的长期配置放在哪里
• 我的供应商怎么切
• 我的官方登录态怎么保留
• 我的 MCP 和 Skills 怎么跨工具复用
• 我的会话怎么找回
• 我的成本怎么统计
• 我的代理和路由怎么排查
• 我的配置坏了怎么恢复

这些问题单独看都不大，但叠加起来就是工作流维护成本。

CC Switch 的价值就在这里。

它把原本散落在各个工具里的配置、供应商、代理、MCP、Skills、会话、用量，收拢成一个本地可控的管理层。对个人用户来说，这能减少反复折腾配置的时间；对重度开发者来说，这能让多供应商、多工具并行变得更稳定；对团队来说，这类工具甚至可能成为 AI 编程环境标准化的一部分。

当然，使用这类工具也要有边界意识。

尤其是本地代理、第三方供应商路由、OAuth 保留、官方订阅能力复用等功能，可能涉及不同供应商的服务条款、计费规则和数据处理方式。CC Switch 在 release notes 里也反复提示了相关风险。实际使用时，不应该只看“能不能跑”，还要看“是否符合自己账号、团队和供应商规则”。

总结：CC Switch 真正解决的是“多工具时代的混乱”

如果只用一句话介绍 CC Switch，我不会再说它只是“供应商切换工具”。

更准确的说法是：

CC Switch 是一个面向 AI 编程工具链的本地管理控制台，用来统一管理供应商、配置、代理、MCP、Prompts、Skills、会话和用量。

它的功能表面上很杂：切换 API、同步 MCP、安装 Skills、查看会话、统计用量、启动代理、映射模型、保留 OAuth、修复 Codex 工具调用。

但这些功能背后的逻辑其实很统一：

• 用 SQLite / SSOT 保存真正的数据
• 用 live 文件投影适配不同工具
• 用本地代理适配不同协议
• 用原子写入和备份保护配置安全
• 用会话和用量统计提升可观察性
• 用统一面板降低多工具维护成本

这也是为什么它值得专门写一篇文章。

因为它不只是一个小工具，而是一个信号：当 AI 编程从“试用单个模型”进入“长期维护多工具工作流”之后，我们需要的不只是更强的模型，也需要更稳的本地基础设施。

CC Switch 做的，正是这件事。

参考资料

• CC Switch GitHub Releases：https://github.com/farion1231/cc-switch/releases
• CC Switch README_ZH：https://github.com/farion1231/cc-switch/blob/main/README_ZH.md
• CC Switch v3.16.1 Release：https://github.com/farion1231/cc-switch/releases/tag/v3.16.1
• CC Switch v3.16.0 Release：https://github.com/farion1231/cc-switch/releases/tag/v3.16.0
• CC Switch v3.2.0 Release：https://github.com/farion1231/cc-switch/releases/tag/v3.2.0