magpie 和 CC Switch，两个多 Agent 配置管理工具的取舍

两个工具最近都在处理同一件事：机器上装了多个 AI Agent，每家配置文件格式不一样，模型怎么选、密钥怎么管、配置怎么不被改坏。

一个是 yetone/magpie，Go + Wails，二进制压到 15MB 内。另一个是 farion1231/cc-switch（CC Switch），Tauri 2 + Rust + React + SQLite。都是 MIT，都是跨 macOS/Windows/Linux。 下面这份对比基于两个项目的官方 README，没有上手跑过，所以只讲设计取舍和适用场景，不下”谁好用”的实测结论。

定位就不是一类东西

CC Switch 自称管理 10 个工具的 All-in-One：Claude Code、Claude Desktop、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、Pi、MiniMax Code。它管的不只有模型，还有 MCP 服务器、Skills、Prompts，甚至会话历史和工具版本。

magpie 只做模型，但做的是全套模型方案。它列的 Agent 更多：Claude Code、Codex、Gemini CLI、OpenCode、MiMo Code、Pi、Goose、Cursor、Copilot CLI、Devin、Kimi Code、omp 等等，目标是”每个 Agent 用哪个模型”在一个地方定。成本核算、路由组、备份是围绕模型展开的。

一句话：CC Switch 是”配置中枢”，magpie 是”模型中枢”。两者在”切换 provider”上有重叠，越往深走差异越大。

改配置的方式：都强调只动关键字段

这是两个项目最接近、也最值得看的地方。

CC Switch 的原则叫 “minimal intrusion”。它明确写：切换 provider 只替换 config 文件里的 key fields（endpoint、key、model name、API 协议），自己加的 plugins、hooks、MCP、环境变量、注释都不动。首次改写前把原文件备份到 ~/.cc-switch/backups/live-first-write/。

它还保证一件 magpie 没做的事：卸载后你的工具照常能用。所以每个单活动模式的工具永远保留一个活动配置，防止删光后工具不可用。

magpie 的说法是 “edits config files surgically”——只改你点的那一个键，注释、排序、缩进原样保留，写入是原子的。它用 stash.json 记录被替换掉的值，换回原生模型时恢复。

两者都明白同一个道理：Agent 的配置文件是你自己长年改出来的资产，不是能随手重写的模板。

路由网关：都有，但形态不同

两个工具都有本地网关，用来在 Claude Code 里用 OpenAI/Gemini 的模型，或者在 Codex 里用 Claude 的模型。

CC Switch 的 local routing 跑在 127.0.0.1:15721，转换 Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Native 四套格式。带 per-tool 开关、自动 failover、断路器、provider 健康检查和 Rectifier（修复某些上游处理不了的请求）。但它作为桌面应用的属性很重：开路由时，工具的 config 文件被写成 127.0.0.1 加占位 key PROXY_MANAGED，真实地址和密钥都存在 CC Switch 里。退出 CC Switch 会把直连配置写回去。

magpie 的网关跑在 127.0.0.1:3425，三套 API + 一个 Gemini 直连。它的差异化特征是两个：一是 Claude 订阅不直接转发，而是驱动本机真正的 claude 二进制，把调用者工具经 MCP 桥接进那次实时对话，绕开 Anthropic 对第三方流量的判定——这是 CC Switch 没有的重活；二是路由组（group/<id>），把多个模型的密钥和账户合成一个挑选项，路由规则有 smart/order/rotate/usage 四种，会话粘连时长可控。

同样做格式转换，magpie 把网关当成跨机器共享、可编程的主干，CC Switch 把它当成桌面工具的一个可选开关。

密钥与安全的口径

CC Switch 的密钥存 ~/.cc-switch 目录，SQLite 数据库 cc-switch.db 里存 provider/MCP/Skills/usage 记录；OAuth 凭据独立在 copilot_auth.json、codex_oauth_auth.json、xai_oauth_auth.json。数据文件在用户主目录，Unix 权限靠系统默认。

magpie 明确写：从不从 shell 环境变量读密钥；自己的密钥在 ~/.config/magpie/providers.json，权限 0600。Docker 部署时密钥只放 volume，端口默认只绑 loopback；局域网共享要显式开 "lan": true 并带 lanKey。magpie backup 的 --no-keys 能导出不含密钥的加密备份，AES-256-GCM，密钥由口令经 PBKDF2-SHA256 派生。

对比下来，magpie 把”密钥是责任”写进了设计，CC Switch 把”数据不丢”写进了设计。两者侧重点不同，没有高下，看用户更在意哪个。

成本核算是条分水岭

这是两者差异最大的功能，直接反映定位。

magpie 把成本核算做成了核心能力。模型定价拆成四级回退：你给这个模型设的价 → 给 provider 名下所有模型的价 → provider 自家目录挂牌价 → models.dev 出厂价。README 还自己承认出厂价对不按挂牌价收费的中转是错误的，专门留了 magpie model price 让你修正。usage 记录带上游密钥指纹归因，能核对哪把 key 实际服务了哪次调用。

CC Switch 也有 usage dashboard，但默认靠扫描每个工具本地的会话日志来统计，开路由的请求才额外计入。支持配额/余额查询（官方订阅、各类 Coding Plan、账户余额）和自定义定价，可导入 models.dev。它是”配置管理顺手带记账”，不是把价格当成第一公民。

形态和部署差一个量级

CC Switch 只是桌面应用。它是 Tauri 2 的原生 GUI，README 明确写”只作为需要图形界面的桌面应用发布”，无官方 CLI，服务器或 SSH 场景要靠社区维护的 SaladDay/cc-switch-cli，数据库版本还可能滞后。

magpie 一个二进制四种形态：桌面 app、菜单栏 tray、TUI、纯 CLI。这意味着它能在无桌面环境里跑，能进脚本，能 magpie claude deepseek/deepseek-chat 一条命令改模型。它还支持一个 magpie 在局域网里服务多台电脑（Remote magpie），用于办公室加个人电脑的组合。

各自适合谁

就 README 呈现的能力看：

CC Switch 适合那种 Agent 生态集中、且在意 MCP/Skills/Prompts 也要一起管的人。十种工具全自己的格式，MCP 和 Skills 加一次同步到多个工具，这是个桌面应用能干得漂亮、magpie 不做的事。它甚至管 CLI 工具的安装和升级。代价是绑定图形界面。

magpie 适合醉心于模型本身的人：多个 Agent 共用一套模型目录，路由、成本、密钥、多机共享都在命令行和网关层面解决。用得越深，它那个网关的价值越明显。代价是 MCP/Skills/提示词这些”模型之外的东西”它一概不碰。

两者都做得很克制的地方在于：都默认你的配置文件是资产，不轻易重写。这一点比它们各自多出多少功能都更值得抄。

最后

如果只装一个 Claude Code，两个都不需要，手动改 settings.json 就够了。如果 Agent 多到开始纠结”哪个模型、什么价、配置别坏”，那么先在 magpie 的模型/成本/CLI 和 CC Switch 的 MCP/Skills/桌面管理之间选一个方向，比两个一起装更省心。

它们谁的切换更稳、哪个网关真的不丢请求，是必须装上跑一段时间才能回答的问题。这份对比只到设计层面，实测结论留给下一步。

---

来源：yetone/magpie 官方 README（MIT）、farion1231/cc-switch 官方 README（MIT）。

#magpie #cc-switch #Agent #模型管理 #配置管理 #CLI #对比