大家好，我是 Ward 。今天这篇文章接着上篇，聊聊我把手头的 5 大 AI 订阅接进开源网关 Magpie 后，如何借助 Jev 意图模型，根据手头订阅情况推翻旧配置、重构多模型路由规则的实战经历。
上一篇聊到我把 CC-Switch 和 AntiGravity Tools（原 AntiGravity Manager）换成了开源 AI 网关 Magpie（GitHub 地址 github.com/yetone/magp… 安装好之后，我把我的 Codex、Claude Code、OpenCode Go、Google AI Pro（Antigravity）订阅以及 WorkBuddy 都接了进去。
配置着配置着，我发现它的路由模式里面还支持接入意图模型。这样我就想起来前段时间比较火的 TypeSafe Jev 模型（typesafe/jev-latest），于是把这个模型也接了进来，用来给我判断每一轮该用什么模型以及用什么推理强度（effort=auto）。
不过这个路由该怎么配呢？我自己也不懂，看着有点复杂。我是直接把官方文档（usemagpie.ai/docs/zh/int… ）丢给AI，让它根据我手头订阅情况和对各个模型的使用方向来帮我配置。
前前后后，我这个路由模式按大的版本算一共改了两次，昨天改完的是第二版。
为什么第一版 5 个路由组用起来效果很差？
第一轮配完的时候，AI 帮我分了 5 个路由组（intent-coder、intent-deep、intent-fast、intent-visual、intent-auto）。用了几天我感觉那个路由模式不太好，没有把各个模型的优势发挥充分。很多事情最后都交给一些比较差的模型去做了，写出来的代码效果自然也比较差。
昨天我让 AI 结合网关里 4600 多条请求日志分析了一下我实际使用的模型情况，才看清楚第一版到底差在哪儿。
第一点是每个组都把 18 个模型按顺序塞在一个列表里（routing=order），从顶部的 Opus 一直排到底部的免费 Flash 模型。前几天 Codex 模型有一阵子状态不对被跳过（出现了约 2600 次 unlisted），等到 Claude 的 5 小时窗口额度一满触发限流，哪怕命中了“复杂架构设计、安全审计”这种高难度规则，请求也会顺着列表滑到底部，有 860 多次直接落到了 workbuddy/deepseek-v4.1-flash 和 gemini-3.8-flash 上面。本来该用主力大模型干的重活，结果全交给轻量级模型去做了。
第二点是子代理（subagents）把主模型的额度吃光了。第一版把子代理绑在了 intent-auto 组，这个组排第一的是 claude/claude-opus-5-5，而且当时还开着 ultracode。日志统计下来，5 小时窗口里一共 255 次 Claude 请求，有 195 次（占了 76%）都是后台搜文件、读代码的子代理发出去的，导致我主对话写代码时反而没额度可用。
第三点是看图规则的粘性问题。第一版配了 images → antigravity/gemini-3.8-flash 并且默认带了 stays=auto，只要对话历史里发过一张截图，后面整场对话就一直停在 gemini-3.8-flash 上不往回切，一共触发了 300 多次；反倒专门建的 intent-visual 组一次都没走过。
另外我也让 AI 抽样检查了 248 轮 Jev 模型的 effort=auto 强度判断。因为 Jev 只看当前这一轮输入的字面内容，如果前面刚聊完复杂方案，我只回一句“继续”或者“同意”，它经常会给成 low；而遇到带了大段 <system-reminder> 的系统消息，又容易给成 high 或 xhigh。所以路由组本身的模型排队顺序必须守住底线，不能全指望单轮分类。
结合套餐变化，第二轮把 5 个路由组缩减为 4 个
这一轮大改，除了前面说的模型没发挥出优势之外，也和我的订阅套餐发生改变有关系。
我在刚开始用 Magpie 的那几天，手头的套餐还是 Codex 的 100 刀套餐，当时的主力模型是 codex/gpt-6.1-sol。后面这个套餐到期了，我就把它降成了 Plus（保留 gpt-6.1-sol、gpt-6-astra 和 gpt-6-luna）。Claude Code 是我前天（10 月 15 日）才开通的，一开始先订的 Plus，后面又升级成了 Pro/Max 100 刀套餐。不过我是用 Google Play 来订阅的，加上渠道费用一共花了 125 刀。所以现在我的主力模型就变成了 Claude Opus 5.5（外加 claude-fable-5-1、sonnet-5-5 和 haiku-5-5）。
因此在第二轮让 AI 给我做改进方案时，我特别强调了两点，一是主力已经换成了 Opus 5.5，二是一定要把各个模型的优势发挥出来，不能再让差模型去干核心活儿。
当时我电脑上还开着 12 个正在干活的 Claude Code 终端。为了不让这些运行中的会话因找不到旧路由组 ID 而报错中断，AI 直接复用了原来的 4 个 ID，删掉了 0 请求的 intent-visual，把 5 个路由组缩减成了 4 个路由组。
改完之后这 4 个组大概是这么分的。
主力编程这组（group/intent-coder）给 Claude Code 当默认模型，也占着 opus 槽位。排第一的是官方的 claude/claude-opus-5-5，5 小时窗口限流了的话，就轮到 4 个 Google AI Pro 账号轮询的 antigravity/gemini-4-argon（1M 上下文）和 antigravity/claude-opus-5-5，再往后是 claude-fable-5-1，垫底那些免费小模型我全删了。这组还配了两条规则，上下文压缩（compacting）丢给免费的 gemini-3.8-flash，碰到复杂架构设计或者跨模块重构，就切到 claude-fable-5-1。
架构设计那组（group/intent-deep）绑的是 fable 槽位，claude/claude-fable-5-1 推理比较深，就放第一个，claude/claude-opus-5-5 和 gemini-4-argon 跟在后面。
审查专线（group/intent-auto）我绑给了 Claude Code 的 sonnet 槽位，还有 Codex CLI 的主模型。Codex 虽然降成 Plus 了，但 codex/gpt-6.1-sol 和 codex/gpt-6-astra 拿来审代码、给方案挑错还是挺好用的。平时 gpt-6.1-sol 打头，Jev 看出来是在审方案、查漏洞的时候，再切给 codex/gpt-6-astra。
剩下一组是快速与子代理（group/intent-fast），haiku 槽位和 Claude Code、Codex 的子代理 subagents 都走它，ultracode 我也顺手关了。子代理平常就是搜搜文件、跑个小脚本，交给 4 个号轮询的 antigravity/gemini-3.8-flash、haiku-5.5，再加上 WorkBuddy 签到白嫖的 deepseek-v4.1-flash、glm-5.3-flash 就够了，这样就不会再去吃 Opus 的额度。
第二版用了一天多，发现审查专线根本切不过去
第二版用了一天多，我发现 Claude Code 好像老是停在“主力编程”这个组里。我让它 review 方案，甚至直接说用 GPT-6 Astra、Claude Fable 5.1 来 review，它也不往“审查专线”那边切。
我第一反应是之前 5 个组的旧数据没清掉。因为印象里第一版的时候它还挺常切过去的，改成 4 个组以后就很少了。结果让 AI 去翻了配置和日志，又对着官方文档看了一遍，发现是我自己把路由组想错了。
我原来以为它会按意图在几个组之间跳来跳去，其实不是。路由组是跟 Agent 的模型槽位绑死的，Claude Code 的主对话永远走 model 槽位，我这个槽位绑的是 group/intent-coder，那主对话发出去的请求就只会进主力编程组。审查专线绑在 sonnet 槽位上，主对话压根就碰不到它。
那在组里面能不能切呢？可以，但 Jev 判出来的规则只能在当前这个组的成员里挑，规则后面也只能写一个具体模型（provider/model），写不了另一个 group/<id>。偏偏我第二版的主力编程组里就没放 gpt-6-astra，review 相关的规则也一条没配，我说得再清楚它也没地方切。
还有架构设计那条规则，也写得太死。AI 当时在 Fable 的意图后面又加了一长串“不涉及常规写代码、修 Bug、单点修改、测试或 Git 部署操作”的排除条件，Jev 一看基本都判成没命中。日志统计下来，第二版之前规则命中率大概是 53%，改成第二版之后掉到了 7.5%。没命中规则的时候，就按组里的顺序加上 prompt cache 的亲和留在 Opus 上，看上去就像“一直停在主力编程”。
所以其实不是旧数据的问题，是第二版配置本身有缺陷。
我顺着这个问题还想了一下，那其实主对话这块我只需要一个路由组就够了，把要用的模型都放进主力编程组，再靠规则去分就行。最后的改法也是这样，主要改了主力编程组 group/intent-coder 这一个组，其他几个组继续留给 fable、haiku、子代理和 Codex CLI 用。
- 把
codex/gpt-6-astra加进主力编程组的成员里。 - 新加一条审查规则，意图写的是“审查、评审或 review 已有的技术方案、架构设计、代码改动、PR 或数据库迁移方案，找出问题和风险；或明确要求用 Astra / GPT 来审查”，命中就切给
gpt-6-astra。 - 把
Fable那条规则的排除条件删掉，改成“设计系统架构、跨模块技术方案或核心技术选型，或规划一个较大功能的整体实现方案；或明确要求用 Fable 来设计”。
改之前 AI 先把 providers.json 备份了一份，改完我又让它查了一下日志。在另一个项目里我发了一条 review 方案的消息，Jev 用了 1 秒左右判成审查规则，这一轮直接由 gpt-6-astra 来回答，后面二十多次工具调用也一直留在 Astra 上，没有中途换回 Opus。
中间也碰到一次小插曲。Astra 有一次回复到一半连接断了（Codex: connection lost mid-reply (unexpected EOF)），Magpie 就让它先休息了一分半钟左右。刚好这时候我又发了一条审查请求，规则其实命中了，但因为 Astra 还在退避期，就退回到组里排第一的 Opus 来回答。这个是出错之后的保护机制，不是配置的问题，等退避时间过了就会切回去。
另外 Fable 那条架构规则，改完之后我还没有真正发过架构设计的问题，所以还没在日志里验证到。
未完待续：以为大功告成，日志体检却抓出了更大盲点
折腾到这一步，我原以为这套拓扑终于打磨得严丝合缝、大功告成了。
然而第二天，我让 AI 对着网关里最新的几千条请求日志做全量体检时，没想到又抓出了更让人意想不到的“顺位盲点”：整整 942 次高难度请求，在 Astra 额度完全充足的情况下，居然被垫底的 Flash 模型给硬生生“截胡”了！
不仅如此，这次体检还促使我彻底反思起在同一个主会话里切模型的局限，并最终做出了一次大手术：把审查彻底踢出主路由，做成了独立的跨家族对抗子代理，并把全局门禁制度化写进了工程规范。
具体的日志体检复盘、942 次隐性降级真相，以及最终的跨家族审查子代理与工程门禁设计，我们在下篇接着聊。
如果这篇文章对你有启发，欢迎点赞、收藏、关注，分享给身边的工程团队与开发者伙伴，也欢迎在评论区交流你的多模型路由与网关调优心得，我们下篇见！
推荐阅读
多个订阅接多个 Agent 怎么管？我从 CC-Switch 迁移到了开源 AI 网关 Magpie（上篇）
