同事問我，怎麼讓 Codex 自動去叫 Claude Code 幫忙做事？我說，其實沒你想得那麼神祕。
Claude Code 有個 non-interactive mode，打 claude -p "你的 prompt"，stdout 直接吐結果。Codex 在它自己的 bash 工具裡跑這行就好（事實上，你叫 Codex 驗證，它就·是·跑這一行）：
claude -p "幫我驗證這份研究報告"
這不是正式的 Agent to Agent(A2A) Protocol，但底層原理就是 agent-to-agent 的最小可行版本。
🔹 但在繼續講之前 — 為什麼要跨 AI 寫作、跨 AI 驗證？
這幾個月密集用三家旗艦 model，我的體感越來越清楚——它們真的有各自擅長的事：
- 🔸 ChatGPT 處理對話式語氣、社群貼文、社群研究的能力，明顯比 Claude 強
- 🔸 Claude 在系統架構、寫程式、framework 設計上強到誇張
- 🔸 Gemini ？？？？？（如果有人找到了麻煩告訴我😐）
這個體感一旦建立，工作流就自然分化了——根據任務性質選主軸 model，再用另一個 model 來挑戰、驗證、補洞：
- 寫貼文 — ChatGPT 主寫、Claude 來找邏輯漏洞跟 framework 強度
- 設計架構 — Claude 主寫、ChatGPT 來幫忙重整 narrative 跟讀者體驗
- 做研究 — 兩個都丟同樣的素材，看哪個切角更銳利
跨 model 不是因為哪個 model 不夠好，而是因為每個 model 都有自己看不到的盲點。
🔹 真正 cross-model 的關鍵：對稱性
但這個玩法有趣的地方，不只是「Codex 能呼叫 Claude」，而是反過來——Claude Code 裡面也能呼叫 Codex：
codex exec "用 second opinion 角度挑戰這個報告"
兩邊都是 non-interactive mode，stdout 拿結果，互為 first-class。這是最底層的版本——但 2026 已經不用這麼土砲了 🫣。
OpenAI 上個月直接出了官方 codex-plugin-cc，在 Claude Code 裡裝完打 /codex:review、/codex:rescue、/codex:adversarial-review 就能直接呼叫 Codex。社群更輕量的做法是用 Codex skill——在 ~/.claude/skills/ 放一個 SKILL.md，Claude 看到適合的任務會自己決定要不要丟給 Codex。
這個對稱性才是關鍵——orchestrator 不是被綁在某一邊，誰擅長什麼就叫誰。跨 model 從這裡開始才真的成立。
🔹 但這條路 6/15 之後不一樣了
Anthropic 上週公告，6/15 開始 claude -p 跟整個 Agent SDK 從 subscription 用量池搬出去，改成獨立的 monthly credit，按 API list price 計費。不過這個變動背後其實揭露了一件更基本的事——Claude Code 一直以來就有兩種計費模型，只是大多數人沒意識到。
🔹 OAuth vs API Key：兩種計費模型
💡 在 terminal 打 claude 進去 interactive 跟它聊天時，走的是 OAuth 認證 + subscription quota。
💡 打 claude -p 在 script 裡自動跑時，6/15 之後會改吃獨立的 Agent SDK monthly credit，credit 用完後才接 standard API rates（要 user 自己開 extra usage 才會接）。
Interactive 跟 Autonomous 本來就是兩種完全不同的工作模式：
- Interactive 的特性：人在迴圈裡、有判斷力、會被自然限速（打字速度有上限）
- Autonomous 的特性：機器自動跑、可以一晚燒掉幾百萬 token、需要硬性 cost ceiling
這個差異一旦理解了，後面要講的三條跨 model 路徑，本質上也是在區分這兩種工作模式。
🔹 OpenClaw 上其實也是這套玩法
OpenClaw 寫 code 我覺得還是輸 Claude Code，所以我讓兩邊互相 trigger。OpenClaw 規劃任務、分解步驟，碰到實作就丟給 Claude Code。更妙的是——我會用 Claude Code 自己的 web search 當 harness，拿外部資訊驗證它「左右互搏」的結果。兩個 model 都同意某件事？不夠——還要 web 上有獨立來源證實才算數。
順帶一提，OpenClaw 跟 Anthropic 之間其實有一段「封→繞→再封」的歷史。OpenClaw 底層用的是 pi-ai 這套工具，最早走的是 Anthropic 的 setup-token + OAuth 路徑。1 月 9 日 Anthropic server-side block + 2 月正式更新 ToS，這條 OAuth 路被堵了。社群繞道——改成讓 OpenClaw 直接呼叫本機已登入的 Claude Code，走 claude -p non-interactive mode，OpenClaw 又能用了。然後就到 5/14 公告的這次——6/15 開始 claude -p 從 subscription 搬走，連這條繞道路的經濟模型都要重算。
兩次操作的意圖顯然——interactive 跟 autonomous 該分開算錢，subscription 不該補貼自動化（好吧，股票買起來🥴）。
🔹 跨 model 三條路徑全景：你的員工管理工具
回到一個更實用的問題——如果想開始讓不同 model 變成你的「員工」，有哪些工具可以用。整個生態其實已經分成三條路徑，門檻由低到高。
📍 路徑 1：Web 介面手動複製貼上
最低門檻——開兩個 tab，一個 ChatGPT 一個 Claude，把 A 的回答整包貼給 B：
「請以獨立 reviewer 角度找出這份回答最弱的論點、漏掉的角度、你會怎麼重排重點順序」
我自己每天也是這樣做研究。這條路有個常被忽略的隱形優點——所有資料、運算、空間都掛在 OpenAI 跟 Anthropic 的伺服器上，你不用付硬體錢，也不用管 storage。
- 適合：寫作、研究、決策、論點驗證
- 特性：人在迴圈裡，每次都自己判斷要不要繼續
📍 路徑 2：Coding Agent 之間互相呼叫
第二條路徑是 agent 之間直接溝通。最底層的版本是 CLI 互相呼叫——Claude Code 用 codex exec 呼叫 Codex、Codex 用 claude -p 呼叫 Claude Code。但 2026 主流的做法是：
-
🔸 用 plugin — OpenAI 官方 codex-plugin-cc 提供
/codex:review、/codex:rescue、/codex:adversarial-review這些 slash command，裝一次直接用 -
🔸 用 skill — 在
~/.claude/skills/放 codex skill，Claude 看到適合的任務會自動丟給 Codex，不用人為觸發 -
適合：coding、自動化、有明確 task boundary 的工作
-
特性：機器幫你跑，routing 由 plugin / skill / CLI 控制
📍 路徑 3：統一的 API 路由層（Gateway 模式）
這條路是真正的「員工總機」——不再決定哪個 model 跑哪個 task，而是把所有 model 放在同一個 API 層後面，由 client 端按需切換。兩個主流方案：
- 🔸 OpenRouter — SaaS model gateway，一個 API key 通數百個模型，OpenAI-compatible，按 token 付費，內建 auto-routing 跟 fallback
- 🔸 LiteLLM — open source 自建版本，已經是 production 級別。可以自己 host gateway，支援 100+ providers，把 cost tracking、virtual key、rate limit 全部抓在自己手上
兩者的差別：OpenRouter 是「用別人的總機」，LiteLLM 是「自己當總機」。選擇邏輯也單純——個人用 OpenRouter，公司或重度使用就上 LiteLLM。
值得一提的是還有一種「IDE-driven 的 gateway」——RooCode、Cline、Cursor 這類 coding agent。它們本質上是把 OpenRouter / LiteLLM 那層 API gateway 包進 IDE 介面，讓你在寫 code 的同時切換 Claude、GPT、Gemini、DeepSeek。我去年寫論文時就是用 RooCode + OpenRouter，同一個 task 輪流跑 Gemini、Opus、GPT 做 cross-validation。這條路的優點是：context 跟著 IDE 走（檔案、git diff、開啟 tab）自動帶入，不用手動貼。缺點是：它把你綁在 IDE 裡——對寫作研究型 user 反而是負擔，因為寫論文的 context 不完全在 IDE 裡。
🔹 學術視角：這些其實早就被分類好了
寫到這裡可能會覺得——這套東西好像在臨時拼湊。其實沒有，學界早就把它整理好了。2025 年《Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems》他們把 multi-agent system 的溝通模式分成三大類：
- 🔸 Message Passing — 點對點或廣播，agent A 直接把訊息送給 agent B。對應到我們的「路徑 2 agent 之間互相呼叫」——不管是 CLI、plugin 還是 skill，本質都是 message passing，差別只在抽象層次。
- 🔸 Blackboard / Indirect — 一個共享的「黑板」，誰想寫就寫、誰想讀就讀，沒有明確 sender / receiver。對應到我們的「路徑 1 Web 手動貼」——瀏覽器、筆記本就是 blackboard，model 之間並不知道對方存在，你才是那個搬運訊息的人。
- 🔸 Shared Memory — agent 之間不直接對話，而是寫入跟讀取同一個共享記憶體層。這層比較微妙——路徑 3 的 OpenRouter 跟 LiteLLM 嚴格來說是「Gateway / 通訊路由層」，本身並不儲存狀態。真正在做 Shared Memory 的，是另一層獨立於 model 之外的工具——工程師用的 Mem0、Letta、Zep，但其實 repo、database、Obsidian、Notion 也都算。
換句話說，目前主流 cross-model 工作流還停留在前兩種模式，Shared Memory 則是越來越重要。
🔹 更深的問題：cross-model 的終極樣貌
寫到這裡，我想留一個沒人在談的洞察。很多人講 cross-model 講到最後，會收在「把 context 帶到另一個 model」這個 mental model。但這個 mental model 其實不夠終極，因為它隱含了一個假設——context 屬於某個 model，換 model 時要「帶過去」。
真正成熟的 cross-model 狀態，本質上是軟體工程裡那個經典的 Stateless Execution（無狀態執行）概念——運算跟狀態解耦：
- 🔸 舊思維：context 是一封信，model 是收信人，換 model 等於把信轉寄
- 🔸 新思維：context 是雲端硬碟，model 是打開檔案的軟體，換 model 等於換打開檔案的軟體
第一個版本下，載體是 chat session，所以會去找「同 session 切 model」的工具。第二個版本下，載體是 memory store + protocol，所以會去找 Mem0、Letta、Zep、A2A 這些東西。
這個翻轉是 cross-model 從「工具技巧」升級為「系統架構」的關鍵。管的不再是 model，而是 context——model 是可以被換掉的執行單元。
🔹 回到最開始
回到同事的問題——怎麼讓所有 model 都變成你的員工？三條路徑挑一條開始：
- 🔸 寫作研究型 user → path 1（Web 複製貼上）+ Obsidian / Notion 整理
- 🔸 工程師 → path 2（CLI 互相呼叫）配合計費邏輯精算 token 預算
- 🔸 重度自動化、要管多個 model 變成 production workflow → 直接上 path 3（OpenRouter 或 LiteLLM）
這個時代真正的 leverage：
- 怎麼讓不同的 model / AI 一起工作
- 怎麼設計它們之間的協作
下一個更難的話題⋯⋯怎麼讓跨領域的工作者透過 AI 框架協作？