作者注：magpie 和 CC Switch 都在改你本機的 Agent 配置文件。本文從架構路線、發佈節奏、能力差異和適用人羣幾個角度做對比，並說明爲什麼兩者只能留一個來寫配置。
~/.claude/settings.json 最近的處境有點尷尬。CC Switch 陪了它一年多，切供應商時只改連接字段，其他內容原樣保留。magpie 進來之後也要往這份文件裏寫字，把入口改成 127.0.0.1:3425。兩個程序都要寫它，誰最後寫入就以誰爲準，前一個的修改會被靜默覆蓋。所以這份配置文件同一時間只能聽一個程序的。
兩個項目的節奏差別很大。截至 2026-10-28，magpie 的發佈倉庫從 2026-09-23 建立到現在，累計發佈號已超過 1000 個。僅 2026-10-27 一天，GitHub 接口能查到的就有 87 個。另一邊的 CC Switch 從 v3.19.0（2026-07-30）走到 v4.0.21（2026-10-26），三個月發了 30 個正式版，每版都附中文發佈說明。magpie 的英文意思是喜鵲，這隻喜鵲一天要報幾十次版本更新。
社區對 magpie 的評價也有分歧。linux.do 上 2026-10-10 有一帖，標題就是「magpie用起來好亂呀 用慣了ccswitch不建議切換」。第二天又有一帖：「爲什麼大家都在推 magpie 下了一個感覺不到什麼優越性」。有人擔心 CC Switch 會被取代，我們的結論是不會被取代，但 magpie 確實分走了一部分用戶。
本文不是安裝教程，也不打算判定哪邊全面勝出，只講清兩條路線的差別，幫你判斷該留哪一個。
Magpie VS CC Switch 發佈節奏：一天幾十個包 vs 三個月 30 版
兩者的發佈節奏差異最明顯，可以先從這裏看。magpie 的版本號停留在 0.1.x，補丁號卻在快速增長。2026-10-03 13:00 到 10-04 14:00 這 25 小時內，它從 v0.1.756 發到了 v0.1.859，正好 100 個版本。截至 2026-10-28，最新版是 v0.1.1801。GitHub 接口最多隻返回前 1000 條發佈記錄，更早的已經查不到，說明總數還在繼續增加。
這些發佈號的性質需要說明一下。它們是自動構建生成的補丁號，幾乎每個提交都會出一次包，不等於做了 1000 次功能升級。這個頻率反映了兩點：維護很活躍，問題修復快；同時 0.1.x 仍處在高頻試錯階段，版本號本身就提示用戶不要指望它很穩定。
| 指標（截至 2026-10-28） | magpie | CC Switch |
|---|---|---|
| 倉庫創建 | 2026-09-23 | 2025-08-04 |
| 最新版本 | v0.1.1801 | v4.0.21（2026-10-26） |
| 發佈節奏 | 單日最多查到 87 個，累計超 1000 個 | 三個月 30 個正式版 |
| GitHub star | 約 2.38 萬 | 約 14.9 萬 |
| 支持的工具 | README 列出 68 個 Agent | 12 個工具，每個都有專門預設 |
| 維護方式 | 不接外部 PR，只有維護者能開 | 開放 issue / PR 協作 |
把 14.9 萬 star 和一天 100 個包放在一起，可以看出兩個項目所處的階段不同：CC Switch 已經有龐大的用戶羣，magpie 還在快速迭代。這不是哪邊更勤奮的問題，而是團隊節奏和風險偏好不同。CC Switch 作者自述在 4.0 重構時關掉了 500 多個歷史 issue。magpie 一個多月內漲到約 2.38 萬 star，但熱度和穩定性需要分開看。
還有一點：API易 文檔站的 CC Switch 頁面（docs.apiyi.com 場景教程）仍寫着 v3.12.0 和 5 款工具，已落後於官方倉庫的 12 個工具和 v4.0.21，版本請以 GitHub 爲準。
Magpie VS CC Switch 核心差異：改配置文件，還是先過本機網關
兩者最根本的區別在於路線：CC Switch 以 Agent 爲中心，magpie 以網關爲中心。
CC Switch 的做法是在切換時只替換各工具配置文件中的連接字段，包括請求地址、Key 和模型。插件、Hook、MCP、你自己加的設置和註釋都原樣保留，第一次改寫前還會自動備份原文件。Claude Code、Codex、Gemini CLI 使用「切換型」，同一時間只有一個供應商生效。OpenCode、OpenClaw、Hermes、Pi 使用「共存型」，多個供應商同時寫進工具自身配置。CC Switch 也有本地路由，但需要手動開啓。開啓後可在 Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Native 之間做協議轉換，並提供故障轉移隊列和熔斷器。
magpie 則先把各個 Agent 的入口統一指向 127.0.0.1:3425，密鑰集中存放在 magpie 中，再由網關轉發給上游。網關支持四種協議互轉，流式輸出、工具調用和推理內容都能轉換。它同樣會改寫 Agent 自身配置中的關鍵字段，README 的原話是 magpie edits the one key that matters in the agent’s own config，採用原子寫入，並保留註釋、順序和格式。如果不想讓它改配置文件，也可以把 OPENAI_BASE_URL、ANTHROPIC_BASE_URL、GOOGLE_GEMINI_BASE_URL 指向本機網關，Key 填 magpie 即可。
| 維度 | magpie | CC Switch |
|---|---|---|
| 定位 | 本機網關 + 切換器 | 桌面配置管理器 + 可選本地路由 |
| 切換方式 | 請求先經過 127.0.0.1:3425 再發出 |
改寫各工具配置中的連接字段 |
| 賬號容錯 | 路由組五種模式 + 多賬號 failover + Daily warm-up | 故障轉移隊列 + 熔斷器 + 健康監控 |
| 日常管理 | Library：指令、MCP、skills、subagent 寫一次 | MCP 面板 + Skills + 提示詞庫 + 會話管理器 |
| 會話 | 列表顯示每次花費，可一鍵在終端重開 | 解析成結構化內容、輪次摘要、導出與恢復命令 |
| 運行形態 | 桌面、TUI、CLI、Web UI、Docker、Termux | 桌面 + 托盤 |
magpie 的優勢：路由、容錯與遷移
magpie 吸引用戶的地方主要有以下幾點：
- 遷移成本低：供應商頁面的 Import 功能可以直接導入 CC Switch 中的供應商，幾分鐘就能完成遷移。這一點對 CC Switch 的衝擊最直接。
- 路由組：可以把一個組當作一個模型交給 Agent，例如
group/daily-coding。組內支持 smart、order、rotate、usage、pace 五種模式。有緩存價值的會話會留在最初應答它的賬號上。 - 訂閱當供應商：已登錄的 Claude、ChatGPT、Copilot 等訂閱可以變成 provider 供其他 Agent 使用，這項功能可在隱私設置中關閉。
- 隱私遮罩：Key、token、郵箱等信息在本機替換成佔位符後再發送。該功能默認關閉，開啓後如果遮罩該生效卻沒生效，請求會直接返回 503，不會把原文發出去。
- 局域網共享與部署：可以爲每個客戶端分配獨立的網關 key 並設置花費上限，也能用 Docker 跑在 NAS 上。
CC Switch 的優勢：日常管理更細緻
CC Switch 在日常管理功能上做得更細：
- MCP 統一面板：按工具勾選同步，支持從各工具導入現有配置。
- Skills 管理：可從 GitHub 或 ZIP 一鍵安裝，並支持一鍵全部更新。
- 提示詞庫：啓用時寫入 CLAUDE.md / AGENTS.md，啓用前會先把文件中原有的內容存回提示詞庫。
- 會話管理器：每一輪摺疊成一行摘要，失敗步驟標紅顯示，可複製恢復命令繼續對話。
- 項目快照：供應商、MCP、Skills、提示詞可以按項目整套切換。
v4.0.21 還新增了多個 Claude 官方訂閱賬號的切換。登錄走官方流程，令牌只存放在 Claude Code 自己的位置，CC Switch 不記錄、不上傳，也明確不按額度自動輪換。這個設計偏保守，和 magpie 的思路正好相反。
工具只負責搬運：Magpie 與 CC Switch 背後的模型和 Key
無論選哪個工具，它們都只負責把請求轉發出去，模型和 Key 需要另外準備。能否順利用起來，取決於你是否有一個穩定可用的 claude-opus-5-5 Key。API易（apiyi.com）同時提供 Anthropic 兼容入口和 OpenAI 兼容入口，兩個工具都可以直接接入。
| 接入項 | 填寫內容 | 說明 |
|---|---|---|
| Anthropic 兼容地址 | https://api.apiyi.com |
不帶 /v1，適合 Claude Code |
| OpenAI 兼容地址 | https://api.apiyi.com/v1 |
適合 Codex 等 OpenAI 協議工具 |
| 模型名 | claude-opus-5-5 |
thinking 版本 claude-opus-5-5-thinking 同價 |
| 價格（每百萬 token） | 輸入 $4 / 輸出 $20 / 緩存讀 $0.2 | 截至 2026-10-28，型號與價格以平臺型號列表爲準 |
| 端點與分組 | chat、messages；ClaudeCode、Default、SVIP 等分組 | 按自己的用途選擇分組 |
需要注意的是，兩個工具讀取的是同一份 Agent 配置。CC Switch 把 Key 寫進 ~/.claude/settings.json，magpie 把 Key 存在網關中，最終都通向同一個上游賬戶。因此更換 Key 只需在 API易 控制檯操作一次，餘額和用量也在同一處查看，不用在兩個工具裏分別填寫。
Magpie VS CC Switch 場景推薦：誰該留，誰該換
繼續用 CC Switch 的人
如果你主要使用 Claude Code，只有一兩個供應商，偏好穩定，不想在每次升級後排查問題，CC Switch 更合適。它改動範圍小，備份機制完善，出問題時直接打開配置文件就能看到原因。經常整理 MCP、Skills 和提示詞，或者需要回看歷史會話的用戶，也會更習慣 CC Switch 的界面和操作方式。
10-10 那帖的樓主說得很直接：「供應商揉在一起完全沒必要換成這個 太亂了，更麻煩的是模型經過這個軟件，選擇之後無法再cli中切換模型」。同帖還有人說「目前沒有感覺到有能斬殺CCS的特有的功能」。這類用戶的需求是一鍵換 provider，CC Switch 已經能滿足。
換到 magpie 的人
如果你同時使用 Codex、Gemini CLI、OpenCode、Pi 等多個 Agent，手上有多個訂閱和多個 Key，希望額度用完後自動切換，同時需要成本看板，magpie 的網關路線更適合你。同一天有人在帖子裏說：「下午才從ccswitcg切到magpie，終於不用一箇中轉一箇中轉測試可用性了。」10-11 那帖也有支持者表示「magpie添加和切換都比ccs方便，而且還有很強的路由規則」，還有人提到 CC Switch 用在 codex app 上無法正常顯示和切換模型。
關於 magpie 的負面反饋要區別對待。有人反饋接入 magpie 後 Claude 緩存像是掉了、費用變高。帖子裏還有一個人說中間層疑似加了提示詞審查，導致請求被拒。這兩條都是單例，沒有復現路徑，不能據此認定 magpie 存在這類問題。本文的信息來源分三類：項目官方自述、第三方單例反饋、尚無定論的內容，請讀者分開看待。
Magpie VS CC Switch 決策建議：五類人怎麼選
| 你的情況 | 推薦 | 理由 |
|---|---|---|
| 只用 Claude Code，一兩個供應商，要穩 | CC Switch | 改動小、有備份，三個月 30 個正式版節奏穩定 |
| 多 Agent、多賬號，要自動容錯和成本看板 | magpie | 路由組 + failover + 用量統計 |
| 主要痛點是 MCP、Skills、提示詞、會話翻查 | CC Switch | 管理面板更細，會話解析更完整 |
| 要局域網共享、跑在 NAS、給不支持的 Agent 做協議互譯 | magpie | 有網關和 Docker 部署形態 |
| 兩個都想要 | 只讓一個寫配置 | 見下一節 |
💡 選擇建議：不確定選哪個，可以先用同一個 Key 在兩個工具裏各試一個下午。CC Switch 的接入步驟見 API易 教程
docs.apiyi.com/scenarios/programming/cc-switch，magpie 的統一網關接入見help.apiyi.com/magpie-unify-claude-code-codex-pi-hermes-api-gateway.html，按教程配置即可，不用自己從頭摸索。
同時安裝的問題：settings.json 只能由一個程序管理
這裏回到開頭的問題。magpie 和 CC Switch 改寫的是同一批文件，例如 ~/.claude/settings.json 和 ~/.codex/config.toml。兩者同時運行時，在一邊切換供應商，另一邊的設置就會被靜默覆蓋，不會有任何提示。之後 Claude Code 實際用的是哪個供應商，取決於誰最後寫入。
想讓兩者共存，就必須約定由誰擁有配置文件：一個負責寫入，另一個只讀或者用完就退出。比如保留 CC Switch 管理 MCP 和提示詞，供應商切換完全交給 magpie；或者反過來。不能讓兩個程序長期各自寫入。如果打算遷移，可以用 magpie 的 Import 把 CC Switch 的供應商導入過去，確認無誤後再關閉舊工具，避免兩邊同時寫入。
風險與封號自負：Magpie 和 CC Switch 都要先備份
以下幾點需要提前說明：
- 兩個都是第三方開源工具（均爲 MIT 協議），都會改寫本機 Agent 的配置文件。安裝前請先手動備份
~/.claude/settings.json、~/.codex/config.toml等文件，不要完全依賴工具自帶的備份。 - 訂閱外用存在條款風險：在官方客戶端之外使用 Claude、ChatGPT、Copilot 訂閱，可能違反廠商的服務條款，CC Switch 自己的文檔也有類似提示。magpie 的「訂閱當供應商」功能可以在 Settings → Privacy 中關閉。
- 後果需要自行承擔：配置被覆蓋、額度損失、賬號風險等後果由讀者自行承擔，本文不爲任何一方背書。建議先在小號或次要項目上試用。
常見問題 FAQ
Q1：Magpie 和 CC Switch 能同時安裝嗎？
可以同時安裝，但不能同時寫入配置。兩者改寫的是同一份 `~/.claude/settings.json`，必須約定由一個負責寫入，另一個只讀或退出。
Q2：magpie 一個多月發佈上千個版本，是不是很不穩定？
這些主要是自動構建出來的補丁號，說明維護頻率高、修復速度快。但 0.1.x 確實還處在試錯期，對穩定性要求高的用戶建議觀望一段時間。
Q3：magpie 會導致緩存失效、費用上漲嗎？
目前只有個別用戶反饋，屬於單例，沒有復現路徑，不能當作結論。如果擔心，可以對比切換前後的用量看板自行驗證。
Q4：換了工具，Key 要重新申請嗎？
不需要。兩個工具都只是轉發請求，Key 可以沿用。在 API易 apiyi.com 控制檯管理同一個 Key，填進 CC Switch 或 magpie 都可以使用。
Q5：claude-opus-5-5 應該填哪個地址？
Claude Code 走 Anthropic 協議，填不帶 `/v1` 的地址；Codex 等 OpenAI 協議工具填帶 `/v1` 的地址。截至 2026-10-28 的價格爲輸入 $4、輸出 $20、緩存讀 $0.2（每百萬 token），具體以 apiyi.com 型號列表爲準。
Q6：magpie 會取代 CC Switch 嗎？
不會。兩者不在同一層：CC Switch 負責管理和切換 Agent 的配置，magpie 讓所有請求先經過本機網關。受影響的主要是「只需要一鍵換 provider」的那部分 CC Switch 用戶。
Magpie VS CC Switch 核心要點 Key Takeaways
- 路線不同：CC Switch 改寫配置文件，magpie 讓請求先經過本機網關
127.0.0.1:3425。 - 節奏不同：截至 2026-10-28，magpie 累計超過 1000 個發佈號，CC Switch 三個月 30 個正式版。
- 各有優勢：magpie 擅長路由、容錯和協議互譯，CC Switch 擅長 MCP、Skills 和會話管理。
- 不能同時寫入：兩者改寫同一份 settings.json，只能由一個擁有寫入權。
- 負面反饋多爲單例：緩存、審查等反饋都沒有復現路徑，不能當作結論。
- Key 只需管理一次：在 API易 控制檯統一更換，兩個工具讀取的是同一份 Agent 配置。
總結
magpie 和 CC Switch 的對比，本質上是兩條路線的差異：一邊以網關爲中心、快速迭代，一邊以 Agent 配置爲中心、穩步打磨。magpie 分走了「只想一鍵換 provider」的那部分用戶，CC Switch 在日常管理功能上依然更細緻。社區的爭論會持續一段時間，但對個人用戶來說，需要做的選擇比較簡單。
~/.claude/settings.json 同一時間只能由一個程序管理。根據上面的五類場景選定一個工具，長期使用即可，不必兩邊來回切換。
模型和 Key 的準備可以通過 API易 apiyi.com 完成，用同一個 Key 接入 claude-opus-5-5，無論選擇哪個工具都能直接使用。
📚 參考資料
- magpie GitHub 倉庫：本地統一 AI 網關與模型切換器
- 鏈接：
github.com/yetone/magpie -
說明：README 含 68 個 Agent 列表和網關說明，中文版爲 README.zh-CN.md
-
magpie 官方文檔：功能與配置說明
- 鏈接：
usemagpie.ai/docs -
說明：路由組、隱私遮罩、局域網共享等功能的詳細說明
-
CC Switch GitHub 倉庫：跨平臺 All-in-One 管理器
- 鏈接：
github.com/farion1231/cc-switch -
說明：發佈說明與逐條修復記錄，版本以此爲準
-
CC Switch 官方站：產品介紹與下載
- 鏈接：
ccswitch.io - 說明：支持工具列表與使用說明
作者：APIYI 技術團隊
技術交流：歡迎在 API易 網站首頁聯繫我們，更多接入資料可訪問 docs.apiyi.com 文檔中心
