引言“一鍵切換 API ProviderMCP、Skills、Prompts 集中管理——不用再手動編輯 JSON/TOML/YAML 配置文件。”這是一天一個開源項目系列的第 234 篇。今天的項目是CC Switch。現(xiàn)在同時用好幾款 AI 編程工具已經(jīng)是常態(tài)——Claude Code 跑一個項目,Codex 跑另一個,偶爾還要切到 Gemini CLI 或 Grok Build 對比效果。問題是這些工具各自有一套配置格式:Claude Code 用一種 JSON 結構,Codex 用 TOML,Gemini CLI 又是另一套 YAML——每次換 Provider、換 API Key、換模型,都要翻到對應工具的配置文件里手動改,MCP 服務器和 Skills 還得在每個工具里各配一份。CC Switch 把這件事做成了一個統(tǒng)一的桌面應用:一款工具,管理十款 AI 編程工具(Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、Pi、MiniMax Code)的 Provider 配置,支持一鍵切換、90 Provider 預設,還能做本地請求的格式轉換路由(Routing)和多 Provider 模型聚合(Aggregation)。142.8k Stars,MIT 協(xié)議,基于 Tauri 2 Rust React 18 構建,目前是這個賽道里規(guī)模最大的開源項目之一。你將學到什么CC Switch 如何用 Switch/Coexist 兩種模式統(tǒng)一十款工具的配置管理方式Direct、Routing、Aggregation 三種連接模式的具體區(qū)別和適用場景最小侵入設計理念:切換 Provider 為什么不會破壞你手動加的插件和 Hook本地請求路由的格式轉換與故障轉移(Failover)機制數(shù)據(jù)存儲設計:~/.cc-switch目錄結構與云同步方案前置知識使用過至少一款 AI 編程 CLI 工具(Claude Code、Codex、Gemini CLI 等)了解 API Provider、Base URL、API Key 這些基本概念可選:了解 MCP(Model Context Protocol)的基本用途會更容易理解集中管理部分項目背景項目簡介CC Switch 的官方定位是:“面向 Claude Code、Codex、OpenCode、OpenClaw、Grok Build 和 Hermes Agent 的跨平臺桌面全能助手”。更完整的說法是Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes Agent、Pi 和 MiniMax Code 的全能管理器。核心價值主張:“一鍵切換 API Provider,MCP、Skills、Prompts 集中管理——不用再手動編輯 JSON/TOML/YAML 配置文件”。團隊與項目信息作者:Jason Young(farion1231)協(xié)議:MIT License技術棧:Tauri 2、Rust、React 18、TypeScript、SQLite官網(wǎng):ccswitch.io項目數(shù)據(jù)? GitHub Stars:142,800 Forks:9,500 Watchers:264 協(xié)議:MIT主要功能解決什么問題沒有 CC Switch 時的多工具管理 Claude Code → 配置文件是 JSONProvider 信息藏在深層嵌套字段 Codex → 配置文件是 TOML格式完全不同 Gemini CLI → 配置文件是 YAML又是另一套結構 ↑ 每換一次 Provider/API Key/模型都要分別打開對應工具的配置文件手改 ↑ MCP 服務器、Skills、Prompts 要在每個工具里各自配置一份無法共享 CC Switch 的做法 一個桌面應用統(tǒng)一管理十款工具的 Provider 配置 ↓ 一鍵切換90 預設 ProviderAWS Bedrock、NVIDIA NIM、社區(qū)中轉等 ↓ MCP、Skills、Prompts 集中管理一次配置多工具復用 ↑ 切換只改動必要的連接字段endpoint/key/model ↑ 插件、Hook、自定義配置保持不變使用場景同時使用多款 AI 編程 CLI 的開發(fā)者想要統(tǒng)一管理 Provider 和 API Key,而不是在每個工具的配置文件之間來回切換需要在多個 Provider 之間頻繁切換測試的用戶對比不同模型/Provider 的效果,一鍵切換而不用手動改配置文件想要跨工具復用 MCP 服務器配置的團隊不想在 Claude Code、Codex、Gemini CLI 里分別配置同一套 MCP 服務器想在 Claude Code 里用 GPT,或者混用不同廠商模型的用戶通過 Routing 模式做本地格式轉換,實現(xiàn)跨 Provider 格式兼容需要追蹤多 Provider 使用量和費用的用戶在 Provider 卡片和系統(tǒng)托盤上直接查看 Token 用量、花費、訂閱額度,不需要分別打開每個廠商的后臺快速開始安裝:# macOSbrewinstall--caskcc-switch# macOS 升級brew upgrade--caskcc-switch# Arch Linuxparu-Scc-switch-bin基本使用流程:1. 在側邊欄通過預設或自定義配置添加一個 Provider 2. 通過主界面、系統(tǒng)托盤或項目切換器切換 Provider 3. 切換生效方式因工具而異Claude Code 即時生效其他工具可能需要重啟 4. 可選開啟 Routing/Aggregation 標簽頁實現(xiàn)跨格式轉換或多 Provider 聚合 5. 通過Apps頁面管理已安裝 CLI 工具的版本核心特性1. 兩種配置管理模式模式含義Switch同一時刻只有一個 Provider 處于激活狀態(tài)Coexist多個 Provider 同時寫入該工具自己的配置文件2. 工具支持能力矩陣工具配置模式本地路由聚合托盤切換MCPSkillsPrompts會話用量統(tǒng)計Claude CodeSwitch?????CLAUDE.md??Claude DesktopSwitch僅模型映射–?––––僅模型映射CodexSwitch?????AGENTS.md??Gemini CLISwitch?–???GEMINI.md??Grok BuildSwitch?–???AGENTS.md??OpenCodeCoexist–––??AGENTS.md??OpenClawCoexist–––––工作區(qū)編輯器?–HermesCoexist–––??Memory?–PiCoexist–––??AGENTS.md/SYSTEM.md/提示模板??MiniMax CodeCoexist–––??AGENTS.md??3. 三種連接模式Direct(直連):工具直接連接到 ProviderRouting(路由):請求本地經(jīng)過 CC Switch 轉發(fā),支持格式轉換和故障轉移,實現(xiàn)跨 Provider 兼容(比如在 Claude Code 里用 GPT)Aggregation(聚合):把多個 Provider 的模型合并成一個選擇列表,每次請求路由到對應模型的真實 Provider4. 集中管理 MCP、Skills、Prompts一次配置,多工具復用,不需要在每個工具里重復設置同一套 MCP 服務器或 Skills。5. 會話閱讀視圖把原始日志轉換成可讀的步驟/文件/失敗摘要,不需要翻看原始日志文件。6. 用量與額度追蹤Token 用量、花費、訂閱額度直接顯示在 Provider 卡片和系統(tǒng)托盤上。7. 數(shù)據(jù)存儲結構默認存儲在~/.cc-switch目錄:文件/目錄用途cc-switch.dbSQLite 數(shù)據(jù)庫(Provider、MCP、Prompts、Skills、項目、用量)settings.json設備級設置backups/自動備份,默認每 24 小時一次,保留最近 10 份skills/Skills 目錄(可遷移到~/.agents/skills)backups/live-first-write/安裝 CC Switch 前的原始配置快照支持 Windows 上的 WSL 路徑配置,以及通過 WebDAV 或 S3 兼容存儲做云同步。深入剖析最小侵入設計:切換只改必要字段CC Switch 有一條明確的設計原則值得關注:即使卸載這個應用,你的工具依然能正常工作。“切換 Provider 時,只會改動關鍵字段”(endpoint、key、model),而插件、Hook、MCP,以及你自己添加的注釋保持不動。如果切換 Provider 時整體覆蓋配置文件 用戶手動加的 Hook/插件/注釋 → 被覆蓋丟失 ↑ 每次切換都有破壞現(xiàn)有配置的風險 ↑ 用戶不敢隨意切換因為代價不可預測 CC Switch 的最小侵入做法 只改動 endpoint/key/model 這幾個連接字段 ↓ 插件、Hook、MCP、自定義注釋原樣保留 ↑ 卸載 CC Switch 后工具配置文件依然是完整可用的 ↑ 用戶可以放心頻繁切換不用擔心丟失自定義配置這個設計選擇的意義在于:它把 CC Switch 定位成一個配置管理的外層工具,而不是配置文件的唯一真相源。即便某天不再使用 CC Switch,底層工具的配置依然完整、可獨立工作——這降低了用戶嘗試這個工具的心理門檻,因為退出成本被顯式地做到了接近零。Routing 模式:本地格式轉換加故障轉移Routing 模式的核心能力是在本地做協(xié)議格式轉換——在 Anthropic Messages、OpenAI Chat Completions、OpenAI Responses 和 Gemini Native 這幾種格式之間互相轉換,從而實現(xiàn)在 Claude Code 里用 GPT這種跨廠商兼容場景。沒有 Routing 時 Claude Code 只認 Anthropic Messages 格式 ↑ 想用 OpenAI 格式的 Provider工具本身不支持 Routing 模式 請求先經(jīng)過本地 CC Switch默認 http://127.0.0.1:15721 ↓ 格式轉換Anthropic ? OpenAI Chat Completions ? OpenAI Responses ? Gemini Native ↓ 附帶斷路器circuit breaker和 Provider 健康監(jiān)控做自動故障轉移 ↓ Rectifier 功能自動修復部分上游無法處理的請求 ↑ Claude Code 不需要知道背后實際在用哪家 Provider這個設計把工具只認一種 API 格式這個限制,轉化成了一個本地代理層能解決的問題——用戶不需要等待工具廠商官方支持某個 Provider,只要 CC Switch 支持格式轉換,跨廠商組合就是可行的。Aggregation 模式:致謝 opencodex 的設計借鑒值得一提的是,CC Switch 的聚合模式設計明確致謝了開源項目opencodex的設計思路。這是一個值得肯定的開源協(xié)作細節(jié)——沒有把借鑒來的設計思路據(jù)為己有,而是在文檔里明確歸功于原作者和貢獻者。聚合模式本身有一個明確的能力邊界:“聚合模式不提供故障轉移”——這是文檔主動說明的局限,而不是讓用戶自己踩坑后才發(fā)現(xiàn)。此外,Codex 在模型列表變化后需要完整重啟才能生效,而 Claude Code 則是即時更新——這種工具間行為差異也被顯式記錄在文檔里。Switch vs Coexist:兩種模式背后的工具差異CC Switch 沒有對所有工具用同一套配置管理策略,而是根據(jù)工具自身的能力邊界分成 Switch(單一激活)和 Coexist(多 Provider 共存寫入)兩類。這個劃分背后是對每個工具自身配置機制的尊重——像 Claude Code、Codex 這類支持顯式切換激活 Provider 的工具用 Switch 模式;而 OpenCode、Hermes 等工具本身的配置機制允許多個 Provider 同時存在于配置文件里,CC Switch 就不強行套用只能激活一個的模型,而是采用 Coexist 模式寫入。這種按工具能力適配管理策略而非強行統(tǒng)一所有工具行為的設計,體現(xiàn)了對底層工具差異的尊重,而不是用一套抽象硬套所有場景。對于 Headless/服務器場景的態(tài)度對于沒有 GUI 的無頭環(huán)境,CC Switch 沒有自己做一個 CLI 版本,而是在文檔里指向一個獨立的社區(qū)項目CC Switch CLI(SaladDay/cc-switch-cli),并明確說明它與桌面應用共享~/.cc-switch數(shù)據(jù)目錄,但版本發(fā)布是獨立的,可能存在版本滯后。這是一個坦誠的生態(tài)邊界說明——沒有把這個能力硬塞進自己的產(chǎn)品范圍,也沒有掩蓋兩者版本可能不同步這個潛在的使用風險。項目地址與資源官方資源GitHub:https://github.com/farion1231/cc-switch官網(wǎng):ccswitch.io協(xié)議:MIT License更新日志:倉庫內CHANGELOG.md相關資源opencodex —— CC Switch 聚合模式的設計靈感來源CC Switch CLI —— 面向 Headless/服務器環(huán)境的社區(qū) CLI 版本,共享同一數(shù)據(jù)目錄總結與展望核心要點回顧一個應用統(tǒng)一管理十款 AI 編程工具的 Provider 配置:告別手動編輯 JSON/TOML/YAML 的碎片化體驗最小侵入設計把退出成本降到接近零:切換只改連接字段,插件/Hook/自定義配置原樣保留,卸載后工具依然能獨立工作三種連接模式覆蓋不同需求:Direct 直連、Routing 本地格式轉換加故障轉移、Aggregation 多 Provider 模型聚合按工具能力差異化管理策略:Switch(單一激活)/Coexist(多 Provider 共存)分別適配不同工具自身的配置機制坦誠的生態(tài)邊界意識:聚合模式明確標注不提供故障轉移、致謝 opencodex 的設計借鑒、Headless 場景指向獨立社區(qū) CLI 項目而非自己硬做適合誰同時使用多款 AI 編程 CLI 的開發(fā)者:想要一個統(tǒng)一入口管理所有工具的 Provider 和配置需要頻繁切換 Provider 對比效果的用戶:一鍵切換比手動改配置文件效率高得多想要跨廠商混用模型的用戶:通過 Routing 模式實現(xiàn)在 Claude Code 里用 GPT這類場景需要集中管理 MCP/Skills 的團隊:避免在每個工具里重復配置同一套能力一句話評價CC Switch 解決的不是哪個 AI 編程工具更好用的問題,而是用好幾款工具時,配置管理本身不應該成為負擔這個更樸素但更真實的痛點。