目錄
這是 Magpie 系列的第一篇，講我為什麼把兩個常駐後臺的軟體換成了一個閘道器。
之前在推特上看到有挺多網友推薦一款叫 Magpie 的開源 AI 閘道器（GitHub 地址 https://github.com/yetone/magpie ）。當時看了一些評論，都在各種吹，看著有點誇張，我還以為它是刷資料的。當時看到就覺得感覺不是很可靠，也就沒有去試用。
舊方案越來越複雜，後臺還得常年雙開兩個軟體
後面 CC-Switch（GitHub 地址 https://github.com/farion1231/cc-switch ）借鑑了一款叫 OpenCodex 的軟體，增加了「聚合」模式，發布了 v4.0 版本。怎麼說呢？增加這個聚合模式確實方便了一些，但我個人覺得整個軟體的複雜度也上去了。它現在提供三種模式：自聯（直連）、路由和聚合。路由模式我一直沒搞懂是幹嘛的，加上聚合之後，我更懵了。試用了幾天，我個人不太習慣它改版後的 UI。
而且 CC-Switch 還有一個讓我比較糟心的地方：我用下來，它經常會把 Agent 的設定檔搞亂，比如識別不到準確模型、或者推理強度對應不上，用起來有點鬧心。
再加上 CC-Switch 的聚合模式下是得手動切換模型的。如果我的訂閱額度滿了，需要自己去換；或者我想用其他模型，也都得自己換。平時我們跑一些長任務，或者想根據模型特性和任務難度來智慧分配模型以及推理強度，還不希望它中斷，以我的使用來看，CC-Switch 做不到，用起來就不是很友好。
另外我偶爾會用一下 AGY CLI，我用的版本里 CC-Switch 也一直沒接入它。更關鍵的是，如果我想把 Antigravity 裡面的模型接入到其他外部 Agent 使用，我用下來單靠 CC-Switch 做不到，必須專門啟動一個叫 AntiGravity Manager（現已改名為 AntiGravity Tools，官方開源倉庫 https://github.com/lbjlaq/Antigravity-Manager ）的反代軟體在後臺做協議中轉。我為了正常寫程式碼，電腦後臺常年得同時掛著 CC-Switch 和 AntiGravity Tools 兩個軟體。
看到原生支援 Antigravity，我決定上手試試
後來我在推特上又刷到 Magpie，看到作者 yetone 在評論裡面回覆了一個使用者說，他這款軟體可以直接接入 Antigravity，不需要專門啟動 AntiGravity Tools 之類的反代軟體，連 AGY CLI 也支援。我之前還得用 CC-Switch 加上 AntiGravity Tools 兩個軟體才能滿足日常使用，換到 Magpie 就只需要用一個了。
我還看到有使用者在 Magpie 裡接入了騰訊的 WorkBuddy，用它的免費模型。另外還有一個好處，就是我看到它有路由功能，有網友曬出了挺複雜的路由圖，能根據自己定義的規則來分配使用哪個模型。那這樣就很方便了呀。看到好處這麼多，我就想，那就試試吧。
兩套方案的核心體驗與功能對比
為了說清楚兩邊的差異，我參考了各自開源倉庫的官方定位與功能說明，把原方案（CC-Switch 加 AntiGravity Tools，原 AntiGravity Manager）和 Magpie 整理成了一張橫向對照表。
| 對比維度 | CC-Switch + AntiGravity Tools | Magpie |
|---|---|---|
| 官方倉庫與產品定位 | 多 Agent 服務商與設定切換工具 + AntiGravity 反代 | 跨 Agent 用戶端與底層多模型訂閱的統一本機 AI 閘道器 |
| 渠道接入與多 Agent 互通 | 支援主流用戶端，但我用的版本一直沒接入 AGY CLI；想把 Antigravity 裡的模型接入其他外部 Agent，必須單獨開反代軟體，日常需要電腦後臺常年雙開 | 原生直連 Antigravity 並自帶 AGY CLI 支援，無需額外反代即可把各渠道模型分發給 Claude Code、Codex 等各種 Agent |
| 路由機制與長任務自動化 | 疊有自聯、路由、聚合（借鑑 OpenCodex）三種模式，聚合模式要手動換模型，額度打滿即中斷，我沒有找到按任務難度自動分流的辦法 | 原生支援接入 Jev 意圖模型與自動推理強度評估（effort=auto），支援規則分流、多級回退鏈與上下文壓縮獨立分流，長任務自動容錯 |
| 設定管理與日常使用感受 | 直接讀寫和覆寫 Agent 本機設定檔，我用下來容易搞亂原生設定，導致模型識別不準或推理強度脫節，用起來鬧心，還常常要手動修設定 | 獨立管理閘道器路由設定並保留用戶端原生欄位，不易破壞本機檔案，日常無感後臺執行，支援從 CC-Switch 一鍵平滑遷移 |
| 擴充功能生態與社群外掛 | 側重內建的多服務商切換、MCP 管理和提示詞管理，我用下來沒有獨立的社群外掛機制 | 內建社群外掛市場，現成支援 WorkBuddy 每日自動簽到（簽到後可使用其中的免費模型），以及模型智商測試等擴充功能功能 |
| 維護模式與發版響應速度 | 我觀察到的是常規的人工維護節奏 | 作者利用官方 Claude Code 與 Opus 5.5 三開 /loop 全自動處理 Issue、定位修 Bug 併發版，響應速度極快 |
從 CC-Switch 匯入遷移與兩個好用的社群外掛
把 Magpie 安裝下來之後，從 CC-Switch 遷移過去倒還比較方便，因為它直接支援通過 CC-Switch 匯入設定。
它還有一個比較好的地方，裡面提供了社群外掛的支援，而且現在已經有一些比較好用的外掛在裡面了。
比如 WorkBuddy 它是支援自動簽到的，配合外掛或者執行 magpie accounts checkin，我們就可以直接使用 WorkBuddy 裡的一些免費模型（2026 年 10 月實測），像 workbuddy/deepseek-v4.1-flash 和 workbuddy/glm-5.3-flash。另外還有一個模型智商測試的外掛（github:mu-zi-lee/magpie-intelligence-check）。我目前主要用的是這兩個外掛，其他的還沒有用上。
提 Issue 秒響應背後，作者的 AI 自動修復工作流
我在這幾天使用過程中也發現了一些問題，比如開啟路由組和壓縮規則後，Claude Code 的 auto mode 偶爾會提示 session isn't eligible。我去 GitHub 提交了 Issue（#2701），發現作者響應都很快。
瞭解下來才知道，他是用 AI 來掃描 Issue，再用 AI 自主解決的方法，所以響應、修復、發布的效率都很高。甚至因為他這樣全用 AI 開發、收集並解決問題、回饋進度，還在推特上引發了討論，出現了一些過分的指責。
我覺得挺不應該的，畢竟這是一個開源專案，別人都沒從你使用軟體上賺取利益，你還這樣去指責別人。而我看到這件事的時候，我更感興趣的是他的整個工作流是怎麼做到這麼高效的。
有些網友分析他是怎麼做的，後面作者自己也出來說了一下，其實也沒有什麼特別的地方，可以看他發的這篇推文和相關評論（原推連結）。他自己在推文裡說這套方法沒有任何魔法，甚至特別簡陋，就是在官方的 Claude Code 裡用官方的 Claude Opus 5.5 模型，同時開 3 個 /loop 會話在後臺跑，再記一份錯誤記錄防止 AI 重複犯錯，每天晚上只花一點點時間打磨 UI 和體驗細節。
目前我也把我的 Codex、Claude Code、OpenCode Go、4 個 Google AI Pro（Antigravity）訂閱以及 WorkBuddy 都接入了 Magpie。設定著設定著，我發現它的路由模式裡面還支援接入意圖模型，就想起了前段時間比較火的 Jev 模型，把它也接了進來幫我判斷該用什麼模型以及用什麼強度。
這個路由我前前後後大版本改了兩次，從 5 個路由組縮減到了 4 個路由組。下一篇我就結合這幾天的真實日誌和方案變化，聊聊這兩輪路由是怎麼讓 AI 幫我配出來的。