之前在推特上看到有挺多网友推荐一款叫 Magpie 的开源 AI 网关（GitHub 地址 github.com/yetone/magp… ）。当时看了一些评论，都在各种吹，看着有点夸张，我还以为它是刷数据的，也就没有去试用。后来因为旧方案越来越难用，我还是装上了，这几天已经把手头的订阅都迁了过去。
这篇先讲清楚三件事，旧方案卡在哪，Magpie 解决了哪些问题，以及迁移和插件对应的命令。路由组怎么配放到下篇。
旧方案的结构，两个软件常驻后台
我手上同时有 Claude、ChatGPT、Google AI Pro 几份订阅，日常用 Claude Code、Codex 写代码，偶尔也会用一下 AGY CLI。之前的组合是 CC-Switch（github.com/farion1231/… ）加 AntiGravity Tools（原名 AntiGravity Manager，github.com/lbjlaq/Anti… ）。
用伪拓扑表示大概是这样。
# 以前：两个常驻进程
Claude / ChatGPT ─────────────────────> CC-Switch ─┬─> Claude Code (启动时改配置)
Google AI Pro ─> AntiGravity Tools(反代) ─┘ ├─> Codex (启动时改配置)
│ └┄> AGY CLI (CC-Switch 未接入)
└──────────────────────────────> AGY CLI
# 现在：一个本地网关
订阅(Claude / ChatGPT / Google AI Pro / OpenCode Go / WorkBuddy)
└─ Magpie(路由 · 回退 · 插件) ─┬─> Claude Code
├─> Codex
└─> AGY CLI
旧方案用下来主要有四个问题。
- 复杂度变高。 CC-Switch 借鉴了一款叫 OpenCodex 的软件，增加了“聚合”模式，发布了 v4.0 版本。现在它提供了三种模式，自联（直连）、路由，还有聚合。路由模式我一直没搞懂是干嘛的，加上聚合之后我更加懵逼了。改版后的 UI 我也感觉不是很好看。
- 配置文件容易被搞乱。 它之前经常会把 Agent 的配置文件搞乱，比如识别不到准确模型、或者推理强度对应不上，用起来有点闹心。
- 聚合模式得手动切模型。 订阅额度满了得自己去换，想用其他模型也得自己换。跑长任务时，想根据模型特性和任务难度智能分配模型以及推理强度，又不希望它中断，CC-Switch 做不到。
- Antigravity 的模型接不出去。 CC-Switch 一直没接入
AGY CLI。想把 Antigravity 里面的模型接给其他外部 Agent 用，必须专门启动 AntiGravity Tools 在后台做协议中转。所以我为了正常写代码，电脑后台常年得同时挂着两个软件。
为什么决定试 Magpie
后来我在推特上又刷到 Magpie，看到作者 yetone 在评论里面回复了一个用户说，他这款软件可以直接接入 Antigravity，不需要专门启动 AntiGravity Tools 之类的反代软件，连 AGY CLI 也支持。这样两个软件就能换成一个。
我还看到有用户在 Magpie 里面接入了腾讯的 WorkBuddy 进行白嫖，也有网友晒出了挺复杂的路由图，能根据自己定义的规则来分配使用哪个模型。看到好处这么多，我就想，那就试试吧。
两套方案对照
我参考了各自开源仓库的官方定位与功能说明，整理成下面这张表。
| 对比维度 | CC-Switch 加 AntiGravity Tools | Magpie |
|---|---|---|
| 产品定位 | 多 Agent 服务商与配置切换工具，加一个专职反代 | 跨 Agent 客户端与多模型订阅的统一本地 AI 网关，标语 Every agent's model. One place. |
| 渠道接入 | 未接入 AGY CLI；Antigravity 的模型要给外部 Agent 用，必须另开反代 | 原生接入 Antigravity 并支持 AGY CLI，不需要额外反代 |
| 路由与长任务 | 自联、路由、聚合三种模式，聚合模式依赖手动换模型，额度打满即中断 | 支持路由组、意图模型、自动推理强度、多级回退，长任务可以自动换到有额度的模型 |
| 配置管理 | 直接读写 Agent 本地配置文件，容易出现模型识别不准、推理强度对不上 | 网关统一管理路由配置，支持从 CC-Switch 一键导入 |
| 扩展 | 内置多服务商切换、MCP 管理、提示词管理，没有独立的社区插件机制 | 社区插件，例如 WorkBuddy 自动签到、模型智商测试 |
| 维护 | 常规人工维护 | 作者用 3 个 /loop 会话在后台自动处理 Issue、修 Bug、发版 |
迁移与插件，对应的命令行写法
从 CC-Switch 迁移过去比较方便，Magpie 的应用里直接支持从 CC-Switch 导入配置。导入之后，下面这些命令可以用来核对和补充。命令以写作时本机 magpie 0.1.1283 的 magpie --help 输出为准，版本更新后请以 --help 为准。
# 列出 Magpie 识别到的 Agent，以及每个 Agent 当前用的模型和配置文件位置
magpie ls
# 列出 Magpie 知道的所有订阅账号、各自的额度用量和重置时间
magpie accounts
# 再登录一个 Claude、ChatGPT 或 Google（Gemini CLI、Antigravity）订阅
magpie accounts add <agent>
# 查看所有订阅、套餐和 Key 余额还剩多少
magpie quota
# 某个 Agent 不想再经过 Magpie，恢复到接入之前的配置
magpie <agent> default
如果担心接入后某个 Agent 的配置出问题，可以用最后一条命令把它单独退回接入前的配置。
社区插件我目前主要用两个。
第一个是 WorkBuddy。WorkBuddy 支持自动签到，配合插件或者执行签到命令，就可以白嫖 WorkBuddy 里面的一些免费模型，像 workbuddy/deepseek-v4.1-flash 和 workbuddy/glm-5.3-flash。
第二个是模型智商测试插件 github:mu-zi-lee/magpie-intelligence-check。
# 安装 WorkBuddy 的社区插件（本机插件列表里的包名）
magpie plugin add @magpie-community/opencode-workbuddy-auth
# 对每个 WorkBuddy 账号立即执行一次每日签到（也可以在设置里打开每日自动签到）
magpie accounts checkin
# 安装模型智商测试插件，它以网关中间件的形式工作
magpie plugin add github:mu-zi-lee/magpie-intelligence-check
# 查看已安装的插件和各自的登录状态
magpie plugin list
其他插件暂时还没有用上。
提 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 帮我配出来的。
觉得有用的话，欢迎点赞、收藏，评论区聊聊你现在是怎么管理多个 AI 订阅的。关注我，下篇更新路由组的配置过程。
推荐阅读
把 GPT-6 当默认模型两天后，我把 Codex 改回了 Sol／Medium
