目錄
大家好，我是 Ward。今天這篇算是 Magpie 閘道器調優的終結篇了。
前兩篇講過，我把手頭幾份 AI 訂閱都接進了 Magpie（GitHub: yetone/magpie），用 Jev 意圖模型按業務分了組。中篇最後留了一個懸念：日誌體檢抓出 942 次高難度請求被弱模型截胡了。這一篇接著講這件事怎麼查出來，又怎麼改。
中篇寫完那會兒，我圖省事，順手把 codex/gpt-6-astra 塞進了主力寫程式碼的組裡，配了條審查規則，當時想的是這樣可能會比較方便。
結果後面我拿它寫程式碼，才發現不太對勁，額度掉得太快了。
隨後我讓 AI 分析一下近期 Magpie 日誌，看看實際情況是怎樣的，路由是否準確且合理。結果又發現不少問題，下面和大家分享下我踩的坑，以及我是如何進行最佳化的。
主力組大折騰：順位排錯、額度互搶與徹底瘦身
尷尬的 Astra：先是 942 次沒用上，用上後才發現根本用不起
這裡面最折騰的，其實是 codex/gpt-6-astra 這個模型。對於我手頭這檔 Codex 訂閱來說，它的定位極其尷尬：放主力組不耐用，放審查組也經不起耗，我根本用不起。
整個過程也挺戲劇化：一開始是「為什麼完全沒用上」。當時我把它順手排在主力組列表末尾（Opus → Argon → AG Opus → Fable → Flash → Astra），以為平時寫程式碼用不上，排末尾兜底肯定沒事。結果一翻日誌傻眼了：全天有 1,030 次主力寫程式碼請求一路滑到了排在 Astra 前面的 gemini-3.8-flash 身上，而這裡面整整 942 次發生的時候，Astra 的額度明明滿血可用！原因很簡單，因為我設定的規則是按順序走，Flash 排在 Astra 前頭，前面的額度一旦耗盡，閘道器碰見 Flash 活著就直接抓來幹活了，根本輪不到最後面的 Astra，花錢買的高推理模型白白被輕量弱模型截胡了 942 次。
抓到這個漏洞後，我第一反應是把順位往前挪（改成 ... Fable → Astra → Flash）。但真正把流量放進去後，才迎來了後半段更嚴重的問題：我根本用不起。
因為這檔 Codex 訂閱的 5 小時額度其實非常吃緊。主力 Claude 額度一旦見底，順位直接跌落給 Astra，主對話裡寫程式碼、翻檔案、查上下文這些吃 Token 的髒活累活全倒給了 Astra，幾下子就把視窗額度徹底衝爆了。更尷尬的是兩邊打架：有好幾次我明明提問讓它審程式碼，規則也對上了，結果回話的居然還是 Opus。翻日誌一看才明白，寫程式碼早就把 Astra 額度幹光了進入退避期，Magpie 只能灰溜溜退回第一順位的 Opus 來保底。寫程式碼把審方案的額度霍霍了，審方案反過來又去搶寫程式碼的額度。不管是寫程式碼還是做審查，Astra 在這檔訂閱下都極不耐用。在同一個會話裡靠規則切來切去，簡直是自己給自己挖坑，這也讓我最終下定決心：主力組和後續的審查，都徹底放棄 Astra，一個都不用。
移出 Fable：警惕快取親和性偷偷扣額度
至於 Fable，更是讓我大跌眼鏡。
原本我在主力組裡加了 Fable 的架構規則。結果一查快取，整個人都麻了。Magpie 有個快取親和機制，會拼命鎖住上一次命中的模型來保 Prompt Cache。
長會話裡只要有一句不小心碰到了 Fable，後頭哪怕我問一句最簡單的找 Bug，它也死乞白賴繼續走 Fable。日誌裡清清楚楚記著，短短 11 次呼叫，消耗了約 49 萬快取寫入 tokens 和約 108 萬快取讀取 tokens。我的那點額度，哪經得起這麼造。
主力組徹底瘦身，追加 DeepSeek 兜底
所以我想通了，主力組就幹主力組的事，別整那些花裡胡哨的。
我二話不說，把 Astra 和 Fable 連同所有複雜的意圖規則全部清空。寫程式碼老老實實走 Opus，Opus 額度見底了交給便宜大碗的 Gemini Flash。
為了防暴斃，我還把 WorkBuddy 每天簽到領的「賽博雞蛋」DeepSeek Flash 掛在最後兜底。
這塊確實有用。之前，幾個主力模型全被限流卡死，閘道器直接報了全軍覆沒的 400 錯誤。加上 DeepSeek 之後，整晚一次 400 報錯都沒出現了。
審查單獨拎出來，搞跨家族對抗
把寫程式碼和審查混在同一個會話裡行不通，我就開始琢磨怎麼把審查單獨拎出來。其實審程式碼這事，本身就不應該讓寫程式碼的模型自己來幹。
你想啊，平時我們讓 Claude 寫程式碼，寫完又讓它自己 review，或者順位滑給同一個公司的其他模型來審，這不就是自己人審自己人嗎？同一個公司的模型，程式碼習慣和偏好都差不多，甚至習慣順著你的思路往下編，真有邊界漏洞或者併發死鎖，它根本挑不出來。
審查就得找對立陣營的來挑刺。主對話既然是 Anthropic 家族的 Claude 在寫，審查就換成 OpenAI 陣營的 Codex，天然對彼此的程式碼不客氣。
我新建了一個只讀的審查子代理（cross-reviewer），用全新的獨立程序啟動，不帶主會話的歷史上下文包袱，只拿當前的改動和程式碼做純粹的邏輯推演，專找併發競態、死鎖和邊界死角。
那換哪個模型來挑刺呢？我一開始確實想用 Astra，但用了段時間發現，Astra 實在太費額度了，後來我調成了 codex/gpt-6.1-sol。
換了之後效果真不錯。GPT 6.1 Sol 這個模型現在價效比挺高，找起 Bug 來看得很毒辣，關鍵是又快又省。我翻了 10 月 21 日全天的日誌，總共觸發了 105 次審查，全都被 Sol 穩穩吃下來了，沒報過一次錯。而且這裡面有 630 多萬 tokens 都吃到了快取讀取，真正算錢的輸入才 17 萬 tokens，回答輸出也特別幹練，一共才 5,000 多 token，折算下來才花了 0.81 美元左右。
不過為了不讓它動不動就出來指指點點，我順手在專案的 AGENTS.md 里加了個門禁規則。平時改個小樣式、修個錯別字絕不叫它，只有在重構系統架構、動資料庫表結構、改安全鑑權或者提 PR 的時候，才會強制拉起這個子代理來挑刺。要是遇到網路抖動或者模型掛了，順位降級給 Gemini 3.8 Flash，再不行就用 WorkBuddy 的免費 DeepSeek 墊底。要是實在都不行，就帶個標記放行，總歸不能把自己的自動化流水線給卡死。
手頭 4 個 Google 帳號自動輪換，再用外掛處理假 429
除了寫程式碼和審查，手頭的 4 個 Google AI Pro（Antigravity）帳號也要高效地利用起來。
以前用 Agy CLI，最麻煩的就是其中一個帳號額度用光了，我必須手動點選退出登入，再一步步輸入帳號密碼重新登入下一個號，寫程式碼的心流全被打碎了。
在 Magpie 裡面其實完全不需要這麼折騰。我單獨建了一個 antigravity 路由組，排程策略設為 routing: "rotate"，親和性設為 affinity: "session"。這樣它在後臺會自動輪流排程我這 4 個 Google 帳號，同一個會話內部鎖在一個帳號上保快取，新會話就輪轉開。
成員純化為 4 個 Antigravity 官方模型（Flash、Sonnet 5.5、AG Opus、Argon），專心消耗 4 個帳號的官方額度池，給我在寫作、生成影片以及一些需要大量 token 的場景使用。10 月 21 日這個組跑了 1,112 次呼叫，4 個帳號在後臺安安靜靜輪換，我再也沒手動切過號。
此外，用 Antigravity 的朋友應該經常在 Claude Code 或者 Claude Desktop 遇到過 429 Resource has been exhausted 報錯。大家第一反應都是額度沒了，但我翻了日誌裡的錯誤堆疊才發現根本不是，閘道器明確寫著：
Antigravity answers this 429 to the system prompt of Claude Code and the Claude Agent SDK (Claude Desktop's chats) whatever quota is left, so it is not a quota and waiting won't help.
說白了，只要發出去的系統提示詞含有 Claude 用戶端的特徵詞，Antigravity 就會直接丟出 429 拒掉，哪怕帳號剩餘額度是滿的。之前我日誌裡這種假 429 累計被攔截了 289 次。
社群裡有人為此做了一個外掛（Antigravity Cloak）。它的實現細節我這裡不展開。裝上之後，全天后續 2,670 多次請求裡，假 429 一次都沒再出現過，Claude Code 順暢分流給 Gemini Flash 正常返回。
不過這裡也要說清楚風險：這類外掛會改動發給服務商的文字，可能違反 Antigravity 的服務條款，帳號有被封的風險；Google 改了規則之後，效果也可能失效。我自己的帳號之前也被封過，後面自動解封了。所以我的建議是隻用於備用帳號，保守方案仍是把 Antigravity 放在回退鏈靠後的位置。
調整後的 5 大路由組與全天實測資料
中篇時還是 4 個路由組，這一輪調整後，閘道器最終穩定收斂為 5 大路由組，多出來的是 antigravity 輪轉組。
(注：各組均掛載 typesafe/jev-latest 意圖分類器，effort: auto，統一宣告 family: "groups" 隱藏底層 30 多個散裝模型。圖中次數為 10 月 21 日上午的快照，與下文全天數字的統計口徑不同。)
從上面的拓撲圖來看，現在的分工就很簡單了。主力組和架構組負責日常寫程式碼，Claude 扛不住了就讓 Argon 和 Flash 頂上，最底下留 DeepSeek 兜底。快速組跑子代理，Flash 和 Haiku 走在最前頭。那個折騰人的多帳號輪換交給了專門的 antigravity 組，而審查則全權分給了 GPT-6.1-Sol。
這輪最佳化調整後，再次讓 AI 把日誌拉出來分析，終於沒什麼問題了。
10 月 21 日這一整天閘道器吞了 4,685 個請求。除了我自己敲鍵盤 Ctrl+C 掐掉的那 13 次，還有 1 次正常的 429 規避，其餘 4,671 次全綠，一個 400 崩潰都沒有。
快取率也還過得去。Prompt Cache 讀了 5.21 億 tokens，命中率衝到了 95% 以上。
主力寫程式碼跑了 2,000 多趟，按模型拆開是 Opus 1,057 次、Flash 785 次、DeepSeek 108 次，另有 53 次是在移除 Fable 規則之前走的 Fable。Claude 額度見底後由 Flash 接手，到了半夜連 Flash 都卡殼的時候，DeepSeek 順手撈了 108 次，整個過程我手上的程式碼一行都沒斷過。
跑子代理的快速組打了 1,200 多次，其中 Flash 1,035 次、Haiku 186 次。專職審查的那 105 次由 Sol 一個人吃幹抹淨。那 4 個 Google 帳號的輪轉組也跑了 1,100 多次，平均攤在 4 個號上，誰也不用累死，再也沒彈過退登重新輸密碼的彈窗。
折騰了這麼多天，我算是看明白了。閘道器這種東西，千萬別抄別人的現成設定。每個人手裡買的方案不一樣，平時提問寫程式碼的習慣也天差地別。你自己搭好之後，用上幾天，一定要把呼叫日誌翻出來看。哪些模型被截胡了，哪些額度在偷跑，日誌裡記得清清楚楚，適合自己才是關鍵。