目录
这是 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 帮我配出来的。