magpie 会成为下一个 CC Switch 吗

最近又发现了一个比较火的项目 magpie（github.com/yetone/magpie）。它和 CC Switch 属于同一类工具，都是把各个 AI 编程 Agent 的供应商统一管起来。官方定位是 “Every agent’s model. One place."，让 Codex 跑 DeepSeek、Claude Code 跑 Kimi，从菜单栏一键切。两周多涨到 8.5k star，速度不慢。

它干的事和 CC Switch（github.com/farion1231/cc-switch）几乎一模一样：读写你各个 AI 编程工具的配置，把 API 供应商、key、model 换掉，省得你手动去改 JSON / TOML。

不过 CC Switch 名气要大得多，14.2 万 star，前几天刚发的 v4 还把界面整个推倒重来了一遍。

一个管配置，一个管流量

CC Switch 是一个跨平台桌面应用，技术栈用的是 Tauri 2 + Rust + React，主打「All-in-One 助手」：把供应商切换、MCP、Skills、Prompts、会话、用量全收进一个图形界面里管。它解决的问题很具体：Claude Code、Codex、Gemini CLI 这些工具各写各的配置格式，换个供应商就要手动改一遍 JSON、TOML、YAML 或者 .env，MCP 和 prompt 还得在每个工具里各自维护一遍。

magpie 是一个用 Go 写的菜单栏应用，但它的重心不在界面上，而在一个常驻的本地网关。它同样能改各工具的配置，但它更想让你所有 agent 的请求都从 127.0.0.1:3425 走一遍，由这个网关统一做协议翻译、账号调度和用量统计。

两边都在绕开 Electron 那套重运行时：Tauri 借系统自带的 WebView，Go 编译成单个不带运行时依赖的可执行文件，安装包和待机内存都比 Electron 系轻一截。magpie 因为是单文件二进制、本来就能 headless 跑，顺手还能进 Docker，挂在服务器或 NAS 上。

安装

magpie 覆盖 macOS、Windows、Linux，另有 Docker 镜像和 Termux 构建；macOS 版本做了签名和公证，装完自带更新。最省事的是官方的一行脚本：

1

curl -fsSL https://usemagpie.ai/install.sh | sh

或者走包管理器：

1

go install github.com/yetone/magpie@latest

官方下载地址 https://usemagpie.ai

像我这边使用的是 Windows 版本，下载完以后不需要安装，双击就能够直接打开，从图中可以看到这边集成了很多供应商，像 Anthropic、OpenAI、Google Gemini、DeepSeek、Kimi、智谱 GLM、OpenRouter 等等。它还能从 CC Switch、Claude Code、Codex、Alma 导入现成的供应商，从 CC Switch 迁过来的成本几乎是零。

使用

装完的主路径就三步：供应商 页加供应商 → 在 Agents 页给每个 agent 点一下、从可搜索列表里选 provider/model → 开新会话，直接生效。它改的是 agent 自己配置文件里那一个关键值，注释、顺序、格式都不动。想整套配置一起切，可以存成 Profiles（比如 Budget、Focus）。

习惯终端的话，同一套东西全有命令：

1
2
3
4
5
6

magpie provider add deepseek sk-…              # 预设只需一个 key
magpie claude deepseek/deepseek-v4-pro          # 让 Claude Code 跑 DeepSeek
magpie codex moonshot/kimi-k2.5                 # 让 Codex 跑 Kimi
magpie save work && magpie use work             # 存 / 切一套 profile
magpie quota                                    # 每个 key、plan 还剩多少
magpie tui                                      # 全部操作，在终端里

用量和成本也在同一个地方看：token、缓存读写、调用次数，按列表价折成美元或人民币；每个 key、plan、账号的余额和额度窗口都能查（magpie quota）。

形态：一个桌面应用，一个菜单栏加网关

先把量级和形态摊开看，这决定了你日常用哪个更顺手。

一是支持的 agent 数量差距悬殊。CC Switch 目前覆盖 10 个（Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、Pi、MiniMax Code）。magpie 列了一长串，Claude Code、Codex、Gemini CLI、Cursor、Zed、Copilot、Crush、Droid、Cline、Kimi Code、Qwen Code、Grok Build、WorkBuddy…… 数下来 50 个以上。magpie 只显示你机器上真装了的那些。

二是运行形态。CC Switch 是纯图形桌面应用，官方没有无头版本（社区另有一个 cc-switch-cli）。magpie 除了菜单栏 app，还给了 CLI、TUI、Web UI，另有多架构 Docker 镜像和 Termux 构建，能在服务器或者 NAS 上跑，再用网页界面管。

CC Switch 的 v4 大改

这是它建仓以来最大的一次更新，正式版 v4.0.4 现在修到了 v4.0.8。改动大致是这些：

• 界面从侧边栏到托盘全部重做，供应商页顶部加了「直连 / 路由 / 聚合」三个标签页
• 新增 Apps 页面，集中展示每个 CLI 的版本、安装位置，支持一键安装和升级
• 新增聚合模式：把多家供应商的模型塞进 Claude Code 或 Codex 的同一个模型列表，一个会话里混用
• 会话阅读页重做（由社区贡献者主导），「一轮工作一行摘要」，失败的命令标红可展开
• 用量页加了热力图和逐请求日志
• 供应商卡片直接显示额度，比如「5 小时剩余 94%」「余额 8.99 CNY」，带重置倒计时

底层还改了一处很重要的机制：切换供应商时，从「全量重写配置文件」改成「只替换关键字段」，你自己加的插件、hooks、注释都不会被动。这个思路其实和 magpie 说的「只编辑 agent 配置里那个关键的值，注释、顺序、格式保持原样」是同一套东西。

magpie 把「网关」当成了核心

magpie 和 CC Switch 分岔最大的地方，就是它坚持让流量走一遍自己的网关。这个网关监听 127.0.0.1:3425，同时支持 OpenAI Chat、OpenAI Responses、Anthropic Messages、Gemini 四种格式，并在它们之间互转，流式输出、工具调用、reasoning 都带着走。

好处有三个，都是「桌面应用改配置」这个模式给不了的：

一是任何吃 base URL 的工具都能接。 没被 magpie 显式支持的客户端，导出两个环境变量就完事了：

1
2
3

export OPENAI_BASE_URL=http://127.0.0.1:3425/v1     OPENAI_API_KEY=magpie
export ANTHROPIC_BASE_URL=http://127.0.0.1:3425     ANTHROPIC_API_KEY=magpie
export GOOGLE_GEMINI_BASE_URL=http://127.0.0.1:3425 GEMINI_API_KEY=magpie

二是路由组（routing group）能做账号级故障转移。 你可以把几个模型组成一个，让它当「一个模型」用，网关在成员之间分摊请求：

1
2

magpie group add "Opus anywhere" models=claude/claude-opus-5-5,copilot/claude-opus-5.5 routing=smart
magpie claude group/opus-anywhere   # 订阅之间自动 failover

smart 模式会挑「还有额度、且最快重置」的那个账号，尽量少浪费；另外还有 order（按顺序）、rotate（每轮换一个）、usage（用最少优先）、pace（按周剩余额度平推）。额度用完自动切下一个账号，agent 那边根本看不到报错。这一点上，两家的目标是一样的（CC Switch 也有故障转移和断路器），但 magpie 把「选择策略」做成了五种可选项，粒度更细。

三是订阅账号能跨 agent 复用。 你登录过的一个 Claude 或 ChatGPT 订阅，会被 magpie 当成一个 provider，喂给别的所有 agent 用。它还支持多账号、以及「定时唤醒」每个账号的 5 小时窗口。

另外 magpie 有一套 Bun 跑的插件系统，插件可以只管登录和出模型，也可以当网关中间件，在请求进出时改写内容。它自带的中间件基本照着 New API 那套抄了一遍，名字都一样：param-override、model-map、system-prompt、word-guard、think-tags。用过 New API 的人会觉得很熟。

magpie 的隐私政策

在官方仓库的底部有一段 Privacy 的说明，写得很详细，也是大家需要重点注意的地方，因为这个工具会少量收集数据。

原文是这样：

你的提示词、回复、密钥和账号只发给你用的供应商。正式版 magpie 每天告诉我们一次它在用：一个随机 ID、版本和系统，以及用了哪些 agent、供应商和模型，只用 magpie 自己的 ID（你自己添加的供应商只记作 custom），以及添加供应商页里排在最前的合作伙伴每天被展示、打开和添加的次数（只有次数）。不发送名称、URL、账号、密钥、提示词和用量。可以在 设置 → 隐私 里关掉一部分或全部，也可以设 DO_NOT_TRACK=1。合作伙伴的官网和获取 Key 链接经 usemagpie.ai/go/… 跳转并计一次点击，usemagpie.ai 也统计合作伙伴列表的拉取次数；这是服务器本身看到的，不受设置影响，不记录 ID 和 IP。插件、导入链接和库里的图标经 usemagpie.ai/api/icon 获取，图标所在的服务器只看到 Cloudflare 的地址，看不到你的 IP；这台服务器只转发图片，不计数也不记录。

翻译成人话，它其实分了四件事在交代：

• 你真正的数据（prompt、回复、key、账号）只去你自己用的供应商，不经过 magpie 的服务器。
• 每天一次匿名上报，告诉作者「有人在用」：一个随机 id、版本号、操作系统，加上用到了哪些 agent / provider / model（用的是 magpie 内部 id，你自己加的供应商只会显示成 custom）；外加合作方在添加面板里的展示、打开、添加次数（只有计数）。没有名字、没有 URL、没有账号、没有 key、没有 prompt、没有用量。
• 可以关。 Settings → Privacy 里可以部分或全部关掉，也可以一次性设置环境变量 DO_NOT_TRACK=1。
• 点击和图标走代理。 合作方网页和 key 链接会经过 usemagpie.ai/go/… 计一次点击，图标则经由 usemagpie.ai/api/icon 转发，所以对方看到的是 Cloudflare 的地址而不是你的。服务器只转图，不存东西。

说白了，它承认了「我会统计一点匿名使用情况」，但同时把范围框得很死，并且给了关闭开关。

我特意去翻了 CC Switch 的 README，里面没有对应的隐私 / 遥测章节。各位别误会，这不等于 CC Switch 在偷传数据，它的数据默认都老老实实躺在本地 ~/.cc-switch 目录里（SQLite 数据库、设置、备份）。只能说它没把这块写出来。

而且它们都是 MIT 协议开源，有没有偷偷做些什么东西，大家都能够发现。

那到底该选哪个

偏向 CC Switch 的情况：你主要就用 Claude Code、Codex、Gemini CLI 这几个主力工具；你更看重成熟的图形界面和打磨过的交互（v4 的会话阅读器、用量热力图确实好用）；你想要更长的迭代历史和更大的社区。14 万 star 不是白来的。

偏向 magpie 的情况：你用的 agent 特别杂，或者要在服务器、NAS 上跑；你想让所有工具共用一套本地网关和订阅账号；你在意「数据到底发了什么」这件事的透明度。另外它那个 WebDAV / S3 / 远程 magpie 的跨设备方案，比单纯的云盘同步更完整。

几个要提前知道的坑：

• magpie 还很年轻（建仓才两周多），迭代很快，v0.1.xxxx 版本号几乎天天在涨，别指望完全稳定。
• magpie 仓库不收 PR，只允许维护者提 PR，想加功能得去 Discord 提；CC Switch 则是先开 issue 讨论方案。
• magpie 的 Docker 用法有个安全提醒：-p 3425:3425 会把端口暴露到主机所有网卡，如果没在设置里开 LAN 密钥，同一个网络里的任何 key 都能访问。局域网共享前记得配好。

写在最后

magpie 和 CC Switch 属于同一类工具，但走的是两条路：一个把「集中管理配置」做到极致，一个把「统一流量入口」当成地基。目前看下来，CC Switch 更成熟、更好看好用；而 magpie 更激进、覆盖面更广。

我的建议是：先装 CC Switch，用熟了这类工具的用法；再装 magpie，把它的网关开起来试试订阅复用和路由组。 两个并不冲突，magpie 甚至支持从 CC Switch 导入现有供应商配置（Import 里就有 CC Switch 这个来源），迁移成本几乎为零。

至于 magpie 会不会成为下一个 CC Switch，说实话短期挺难，往后就得看它自己了。网关这条路确实比 CC Switch 更有想象力，但最终能长多大，我总觉得还得看它愿不愿意把社区那扇门打开。