上一篇文章差點寫錯一段
上一篇寫 subagent vs teammate 時，我同時叫了 Codex 跟 Gemini 獨立查官方文件。Gemini 提了一個具體說法：「agent teams 必須使用 Opus 4.6+ 模型」。Claude 跟 Codex 兩方都沒有這個說法。三方對照下來 2-1 剔除，文章沒寫這段。回查官方文件，Anthropic 沒有這個硬性要求——這是 Gemini 的推論幻覺。
這次是多模型比對救了我。但換個角度想——如果我手邊沒有 Codex 跟 Gemini，改用 Claude Code 的 subagent 跑三次呢？三份都來自同一個基礎模型，共用同一組訓練資料偏見，一起說「必用 Opus」的機率相當高。三次「一致的答案」不代表「正確的答案」，只代表「Claude 自己一致」。
這就是為什麼 multi-LLM 不能用同模型 subagent 取代。
為什麼是 Codex 跟 Gemini（成本的契機）
在講 pattern 之前先交代為什麼我手邊剛好有這兩個外部 LLM。光講「叫 Codex 跟 Gemini 省 token」是假議題——如果它們比 Claude Code 貴，外包給它們反而浪費錢。實際組合：
Codex（OpenAI）：新訂閱有 1 個月免費試用。試用期內做研究跟審查程式碼，幾乎零邊際成本
Gemini（Google）：去年 Google AI Pro 年費優惠期時入手，價格遠低於 Claude Code 訂閱方案，還額外送 5TB Google One 儲存空間（本來就要買的東西）。算下來 Gemini 幾乎是「買 Google One 送的」
這兩個湊起來的月成本仍低於再開一份 Claude Code 訂閱（順帶一提：根據最新消息，20 美金的那個 tier 聽說快收掉了），而且他們分別是 OpenAI 跟 Google 的旗艦，品質不輸前線。
這篇文章的前提：主力還是 Claude Code。Codex 跟 Gemini 不是取代，是輔助做研究與交叉驗證。本文所有模式都建立在這個前提上。
Self-consistency 不等於 cross-validation
同一個模型跑 N 次在學術上叫 self-consistency（Wang et al. 2022, arxiv 2203.11171）。它對數學、邏輯這種「答案分佈銳利」的題目有效——多採樣、取多數。但對事實核對、偵測幻覺，同模型 N 次常常一起錯，因為它們共享同一組偏見。
換成 Claude + Codex + Gemini 三方，才有真正的多樣性：不同訓練資料、不同推理風格、不同錯誤模式。三方一致 = 高信心；有分歧 = 值得追查的線索。
Pattern 1：Delegate — 把整個任務外包
最基本的用法。把任務丟給外部 LLM，它怎麼想、跑多少輪、讀多少文件 都不佔你 Claude 的 context——只有最終的報告會回來。
實際數字：上一篇文章我派了一個 claude-code-guide subagent 去查 agent teams 官方文件，那個 subagent 燒了 63K tokens（reasoning + 5 次 tool call + 官方文件爬取）。如果我改用 Codex 直接跑：我的 prompt ~500 tokens，回來的報告約 1.5K tokens，總共 ~2K tokens 進我的 Claude context。Codex 自己內部燒多少是 Codex 的帳，不是我的（而且 Codex 還在試用期，這次零成本）。
Claude context 節省：30x。
適合什麼：推理密集、研究密集、你不需要看中間過程、只要結論的任務。
Pattern 2：Verify — 獨立交叉驗證
不把任務委外，是讓多個 LLM 各自做一次同樣的事，然後比對。關鍵規則：
獨立 prompt：每個 LLM 不知道其他 LLM 在做什麼，也不知道你已經查到什麼
不 prime：不要在 prompt 裡暗示「我覺得答案是 X」
分歧處理：三方有分歧時，回事實依據（官方文件、原始碼）裁決
這不是浪費 token——是為了保留多樣性。如果你把 Claude 的初步結論餵給 Codex 當 context，Codex 會傾向確認你已經有的結論（SelfCheckGPT, arxiv 2303.08896 的觀察）。
適合什麼：事實敏感的陳述（版本號、功能支援、API 簽名）、技術決策的前提假設、要對外發表的內容。
Pattern 3：Vote — 多數決裁決
Verify 是「收集意見」，Vote 是「做出決定」。當你需要一個明確答案而不是一份參考報告時升級到這個。
M=3 的實用規則：
2-of-3 主議決：多數贏
1-1-1 三個不同答案：回 SoT 或追加第四方
高風險場景：改用 unanimity-or-escalate——三方不一致就直接升級處理，不接受多數
實例：上一篇的 Gemini「必用 Opus 4.6+」就是在這一關被 2-1 剔除。
適合什麼：架構決策、版本選型、安全/合規相關判斷。
最大的雷：False Consensus
三個模型都訓練在大量重疊的網路資料上。他們「不同」的程度比想像中低。研究顯示當兩個模型都錯時，相關錯誤率可達 60%+——不只一起錯，還經常一起錯成同一個答案。
降低 false consensus 的三個做法：
給不同來源：Claude 讀文件、Codex 讀論文、Gemini 做網頁搜尋。三個資料來源本身就有多樣性
不讓他們看對方草稿：共識應該是事後發現的，不是 prompt 階段誘導出來的
保留分歧：2-of-3 通過但有一方反對時，花 30 秒看反對意見。可能那一方才是對的
Token 帳單實拆
Claude Code + MCP 的計費邊界其實很清楚：
算 Claude 的帳：你對 Claude 的 prompt + MCP tool call 的 input + 回傳的 output
不算 Claude 的帳：外部 LLM 內部推理、tool call、temperature 搜索
MCP 限制：回傳 >10K tokens 會警告，預設上限 25K。過大會截斷或寫到檔案
隱藏成本：外部 LLM 有自己的 API 帳單。但如前面交代的——Codex 試用期零成本，Gemini 是 Google One 附贈，所以這邊的「另一個錢包」幾乎是空的。如果你是按 token 付費的 API 使用者，就要另外算。
什麼時候別用
答案固定的簡單任務：「這個 function 用哪個 decorator」—— Claude Code 自己就行
需要專案脈絡的任務：外部 LLM 看不到你的 CLAUDE.md、MCP skill、檔案內容。把整個 repo 塞過去成本太高
低延遲需求：三方串行加往返通訊，UX 會很痛
強弱模型差距太大：Self-MoA 論文（arxiv 2502.00674）指出，加入明顯較弱的模型反而會拉低準確率。不是「模型多就好」
實戰套路
Delegate-first：讓 Codex 寫草稿，Claude 審定稿。適合：技術文章、程式碼審查、長文摘要
Verify-on-publish：內容發佈前三方驗證關鍵事實。適合：要對外發表的技術陳述
Vote-for-decision：架構抉擇用 unanimity-or-escalate。適合：一次性、高代價的決策
收尾
這篇文章——以及上一篇——都是用這組 pattern 寫出來的。Codex 負責技術驗證、Gemini 負責網頁研究、Claude 負責整合與下筆。三方意見交叉比對後，我才決定哪些陳述寫進來、哪些剔除。
工具都擺在那裡，我也已經付過錢了（或還在試用期）。不用它的代價不會當下顯現——會在你發表一個錯的陳述、讀者指出錯誤時才付出來。多模型交叉比對值得做，是因為它讓錯誤在還來得及改的時候被抓到。