# 一個介面，操作多種 Agent：Claude、Codex、Antigravity 與 Grok 的跨 Agent 工作流 > 當 Claude、Codex、Antigravity 與 Grok 可以在同一個介面中被操作、交接與協作，AI 工作流的基本單位也開始改變。本文結合每週更新的模型選擇地圖，整理統一介面、場景分工、任務交接與人工治理的完整流程。 - Author: Paul Kuo（郭曜郎） - Date: 2026-09-03 - Pillar: 智能與秩序 / Intelligence & Order - Tags: 跨 Agent 協作, Claude, Codex, Antigravity, Grok, 人機協作, AI 工作流 - Canonical: https://paulkuo.tw/articles/cross-agent-one-interface/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：一個介面操作多種 Agent，最先解決的是工具切換與上下文搬運的摩擦。更深一層，它讓使用者可以依照任務場景選擇合適的 Agent，再讓 Claude、Codex、Antigravity 與 Grok 共同完成工作。模型頁面負責縮小選擇範圍，統一介面負責調度與交接，人類則保留權限、證據與最終判斷。
影片｜如何在一個介面中安排 Claude、Codex 與其他 Agent 接力工作（繁體中文，約 1 分 45 秒；桌面橫式、窄螢幕直式）。本片為文章重點摘要；實際分工仍應依任務、權限與當期工具能力調整。
目前我的工作環境已經實現了在單一介面上操作多種 Agent。這體驗極其奇妙，宛如《射雕英雄傳》中的郭靖，竟能一人集結降龍十八掌、七十二路空明拳、左右互搏術、易筋鍛骨章、九陰真經總綱、療傷篇、上天梯、蛇行狸翻、飛絮勁、收筋縮骨法、移魂大法、大伏魔拳法、手揮五弦、摧堅神爪、白蟒鞭法、全真內功、金雁功、天罡北斗陣、南山拳法、開山掌法、分筋錯骨手、空空拳、越女劍法、伏魔杖法、金龍鞭法、南山刀法、呼延槍法、金鐘罩鐵布衫、哲別神箭術、蒙古摔角、逍遙遊、奇門遁甲與武穆遺書等萬般絕學於一身。 Claude 可以操作 Codex，Codex 也可以操作 Claude。這個工作方式再延展出去，也可以讓 Antigravity 與 Grok 參與其中。 表面上看，這像是多了幾個工具選項。實際上，它改變的是我們使用 AI 的基本方式。 過去使用多個 AI 工具時，通常需要自己處理中間的摩擦： **圖 1｜多工具切換如何造成工作中斷** ```mermaid flowchart LR A[想到一個問題] --> B[打開第一個工具] B --> C[複製內容] C --> D[切換到第二個工具] D --> E[重新說明背景] E --> F[再切換其他工具] F --> G[整理多份輸出] G --> H[回到原本的工作] ``` 每個工具可能都很強，但使用者必須一直負責搬運內容、維持上下文、記住工作進度，也要判斷哪一份輸出應該交給下一個工具。 現在的變化是，這些 Agent 可以被放進同一個操作面裡。 **圖 2｜單一介面把多個 Agent 放進同一個工作脈絡** ```mermaid flowchart TB U[使用者] I[統一操作介面] C[Claude] X[Codex] A[Antigravity] G[Grok] U --> I I --> C I --> X I --> A I --> G ``` 少開幾個視窗只是表面結果。 它讓使用者開始從「使用某一個 AI」轉向「調度一組可以互相協作的 Agent」。 ## 真正的便利，是減少工作被切碎 多種 AI 工具同時存在，原本是一種選擇自由，也可能變成一種操作負擔。 每增加一個工具，就可能增加一套介面、一種操作方式、一組上下文，以及一種輸出格式。工作者看似擁有更多能力，實際上卻要花更多時間管理工具本身。 這裡至少有四種摩擦。 第一種是介面摩擦。 使用者要不斷開啟、關閉與切換不同的視窗。這些動作本身不產生價值，卻會中斷思考。 第二種是上下文摩擦。 同一項任務交給不同 Agent 時，使用者經常需要重新說明背景、目標、限制與目前進度。只要其中一段資訊沒有傳過去，下一個 Agent 就可能從錯誤的前提開始工作。 第三種是流程摩擦。 使用者需要自己記住，哪一個 Agent 已經完成什麼，下一步應該交給誰，哪些輸出已經確認，哪些內容還只是建議。 第四種是責任摩擦。 當多份結果散落在不同工具中，使用者很難回頭追蹤：哪一個 Agent 做了哪個決定？哪一段內容是原始資料？哪一段是推論？哪一個結果經過人工驗收？ 因此，一個介面操作多種 Agent 的價值，首先在於降低工具摩擦，讓人的工作不要被工具切碎。 ## 從「一個 AI 回答」變成「一個工作網路」 傳統的 AI 使用方式，大致是這樣： **圖 3｜傳統的一問一答式 AI 使用方式** ```mermaid flowchart LR H[人提出問題] --> M[一個 AI 產生答案] M --> J[人判斷是否採用] ``` 跨 Agent 工作流則更接近這個結構： **圖 4｜跨 Agent 工作網路的基本結構** ```mermaid flowchart TB H[人提出任務] --> I[統一介面接收任務] I --> P[任務拆解與角色分配] P --> E[不同 Agent 分別執行] E --> T[Agent 之間交接結果] T --> R[統一介面整合進度] R --> J[人類驗收與決策] ``` 這個變化的關鍵，在於工作能否在不同 Agent 之間流動。 一個 Agent 可以負責理解問題，另一個 Agent 可以負責執行，第三個 Agent 可以負責找錯，第四個 Agent 可以提供獨立觀點。最後，再由使用者或指定的整合 Agent 收斂結果。 在這種架構中，AI 不再只是回答問題的工具，也成為工作網路中的不同節點。 我之前寫過一篇〈[三個 Claude，一個迴圈：我如何把設計探索接到實作上線](/articles/three-claudes-one-loop/)〉，當時談的是不同 Claude 介面之間如何透過 mock、spec 與 screenshot 接成一個迴圈。現在的跨 Agent 工作流再往前走了一步：交接的對象不再只是同一個產品的不同介面，而可能是不同系統、不同模型、不同權限環境中的 Agent。 ## 模型選擇要跟著場景走，而不是跟著品牌走 我每週會定期更新兩次[模型前沿即時儀表板](/ai/models/)。這個頁面不是固定的模型排行榜，而是一張選擇地圖：依照寫作、研究、程式開發與日常任務，整理目前值得考慮的模型與成本。 這一點對跨 Agent 工作流很重要。模型會更新，價格會變動，同一個模型在不同任務上的表現也可能不同。今天適合某個角色的模型，下一次更新後可能已經有更好的選擇。 因此，文章不應該把 Claude 永遠寫成規劃者、Codex 永遠寫成執行者，也不應該把 Antigravity 或 Grok 固定成某一種性格。比較準確的說法是：先看任務，再看當期模型資料，最後決定哪個 Agent 在這一輪工作中負責哪個角色。 模型頁目前採取的閱讀順序，也可以直接轉成跨 Agent 的選擇流程：先看能力差異是否超過誤差範圍；如果分數接近，再比較成本；接著確認評測是否真的對應自己的任務；最後把資料主權與安全風險放進決定裡。 **圖 5｜依任務場景選擇本輪 Agent** ```mermaid flowchart TB A[輸入任務場景] --> B[查看模型選擇地圖] B --> C{主要限制是什麼？} C --> D[能力與任務適配] C --> E[成本與使用頻率] C --> F[泛化能力與陌生問題] C --> G[安全與提示注入風險] D --> H[選擇本輪 Agent] E --> H F --> H G --> H H --> I[設定角色與權限] I --> J[執行、交接與驗收] ``` 這張地圖不是要替使用者做最後決定。它的作用，是先把選擇範圍縮小，讓使用者可以再用自己的任務測試。尤其要注意，長程 agentic 編碼的結果，不能直接當成日常對話、寫作或研究的總排名；成本也要確認計算基準，API 用量成本與聊天訂閱費不是同一件事。 這也代表模型角色是一種工作配置，不是品牌本質。 ## 不同 Agent 可以在同一項工作裡分工 跨 Agent 協作的前提，是不要把所有 Agent 都當成同一種工具。 在一項任務裡，Agent 可以有不同角色： | 角色 | 主要工作 | |---|---| | 規劃者 | 理解需求、拆解任務、安排順序 | | 執行者 | 寫程式、整理資料、產出文件 | | 審查者 | 找錯、提出反例、檢查遺漏 | | 外部顧問 | 提供另一個系統或模型的觀點 | | 整合者 | 比較結果、處理衝突、形成最後輸出 | 同一個 Agent 在不同任務中，也可能扮演不同角色。 例如，一次任務可以採取以下流程： **圖 6｜不同 Agent 在同一項工作中的角色分工** ```mermaid flowchart LR H[使用者提出任務] --> C[Claude：理解與規劃] C --> X[Codex：執行或修改] X --> G[Grok：提出獨立觀點] G --> A[Antigravity：協助檢查或延伸] A --> C2[Claude：整合結果] C2 --> H2[使用者：確認是否採用] ``` 這張圖是角色示意，實際流程仍然要依任務內容決定，不必固定成同一條路徑。 這裡真正要問的是：「哪個 Agent 適合負責目前這一步？」 當工作被拆成不同階段後，Agent 的價值就不再只由單次回答品質決定，也包含它能否正確接收任務、交付結果，以及讓下一個 Agent 繼續工作。 ## Claude 與 Codex 的雙向操作 目前已經可以看見一種更接近協作的關係：Claude 可以提供建議，也可以把工作交給 Codex；Codex 可以獨立執行，再把結果交回 Claude。 流程可以表示為： **圖 7｜Claude 與 Codex 的正向交接流程** ```mermaid sequenceDiagram participant U as 使用者 participant C as Claude participant X as Codex participant I as 統一介面 U->>I: 提出工作目標 I->>C: 交給 Claude 分析 C->>I: 回報任務拆解 C->>X: 交接具體工作 X->>I: 回報執行結果與證據 I->>C: 提供結果供整合 C->>U: 提出下一步或待確認事項 ``` 反向流程則是： **圖 8｜從執行回到分析的反向回饋流程** ```mermaid flowchart LR X[Codex 執行中] --> Q[發現需要重新分析的問題] Q --> C[交給 Claude 重新整理] C --> D[Claude 提出判斷或替代方案] D --> X2[Codex 繼續執行] X2 --> U[使用者驗收] ``` 這裡的重點，在於任務能否順利流動。 真正重要的是，任務不必在某一個工具裡結束。它可以從規劃進入執行，再從執行回到分析，最後形成一個可以被人類驗收的結果。 這種工作方式也延續了我之前讓 Codex 審查 Claude 的經驗。那篇〈[我讓 codex 挑 Claude 的錯，但不照它說了算](/articles/ai-second-opinion-independence/)〉談的是如何保留第二意見的獨立性；這篇更進一步處理的是，當第二個 Agent 不只審查，還可以被納入同一個工作流時，交接與權限要怎麼設計。 另外，〈[讓 Claude Code 借 Codex CLI 生圖](/articles/claude-code-codex-imagegen/)〉已經是一個具體的跨 Agent 實例：一個工作環境中的 Agent 借用另一個 Agent 的能力，完成原本不在單一工具裡的任務。本文要討論的範圍更大，從單一能力借用，延伸到一個介面裡的多 Agent 調度。 ## 一個介面扮演的是工作控制面 統一介面的重要角色，是讓使用者掌握整個工作的狀態，而不只是把不同品牌的按鈕放在一起。 理想的操作面，至少要讓人看見： **圖 9｜統一介面需要呈現的工作狀態** ```mermaid flowchart TB T[目前任務] --> R[目前負責的 Agent] R --> P[目前進度] P --> D[已完成的工作] D --> N[下一步接手者] N --> H[需要人工確認的地方] ``` 因此，統一介面可以被理解成一個工作控制面： **圖 10｜統一介面作為跨 Agent 工作控制面** ```mermaid flowchart TB U[使用者] I[統一工作控制面] T[任務規劃] S[Agent 選擇] P[權限管理] V[進度追蹤] R[結果整合] H[人工驗收] U --> I I --> T I --> S I --> P I --> V I --> R I --> H ``` 這個控制面將不同 Agent 的能力放在同一個工作脈絡裡。 使用者可以先說明自己要完成什麼工作，再決定這項工作適合由哪個 Agent 負責，不必先思考「我現在應該打開哪個工具」。 這是很大的差異。 工具導向的工作方式，是人配合工具。 任務導向的工作方式，則是工具配合任務。 ## 一次跨 Agent 任務的完整流程 一個比較完整的跨 Agent 工作流，可以拆成九個步驟： **圖 11｜一次跨 Agent 任務的九步流程** ```mermaid flowchart TB A[1. 輸入需求] --> B[2. 拆解任務] B --> C[3. 選擇適合的 Agent] C --> D[4. 設定上下文與權限] D --> E[5. Agent 執行] E --> F[6. 交接輸出與證據] F --> G[7. 另一個 Agent 審查或延伸] G --> H[8. 統一介面整合] H --> I[9. 人類驗收、繼續或停止] ``` 每一個步驟都有自己的責任。 「輸入需求」要處理的是目標。 「拆解任務」要處理的是工作順序。 「選擇 Agent」要處理的是角色分工。 「設定上下文與權限」要處理的是邊界。 「交接輸出與證據」要處理的是可追蹤性。 「人類驗收」則要處理最終責任。 如果只把多個 Agent 放在一起，沒有這些流程，最後可能只是多個答案並排出現。只有當任務、資料與責任能夠被傳遞，才真正形成工作流。 ## Agent 交接不能只靠複製聊天記錄 跨 Agent 工作最容易出現的問題，是把一整段聊天記錄直接交給下一個 Agent。 這樣看似保留了完整上下文，卻不一定真的有幫助。下一個 Agent 仍然需要自己判斷： - 哪一句是任務 - 哪一句是背景 - 哪一句只是討論中的想法 - 哪些內容已經確認 - 哪些內容只是暫時假設 - 哪些事情不能執行 因此，Agent 交接應該整理成一份簡單的工作契約： ```text 任務目標： 目前進度： 已知上下文： 可使用的資料： 不可使用或不可外傳的資料： 允許的操作： 禁止的操作： 期待輸出： 驗收條件： 停止條件： 下一步接手者： ``` 這份交接資料的價值，在於讓下一個 Agent 不需要重新猜測工作邊界。 更完整的交接流程如下： **圖 12｜從 Agent A 到 Agent B 的交接資訊流** ```mermaid flowchart LR A[Agent A] B[整理任務目標] C[整理已知上下文] D[標示證據與待確認事項] E[標示權限與限制] F[交給 Agent B] G[Agent B 產出結果與依據] H[回到統一介面] I[人工或其他 Agent 驗收] A --> B --> C --> D --> E --> F --> G --> H --> I ``` 好的交接應傳遞下一步工作真正需要的資訊，而不是把所有聊天記錄全部搬過去。 ## 便利性越高，權限邊界越重要 一個介面可以操作多種 Agent，會大幅降低使用門檻。但這種便利性也會帶來新的問題。 如果 Agent 可以操作其他 Agent，誰決定它可以做什麼？ 如果一個 Agent 可以啟動另一個 Agent，這個權限是否會一路擴大？ 如果多個 Agent 都能看到同一份資料，哪些內容可以共用，哪些內容不能離開原本的工作範圍？ 因此，跨 Agent 工作流除了確認「能不能做」，還需要處理「允許做到哪裡」。 可以把權限分成幾個層次： **圖 13｜權限從資訊查看逐步接近外部行動** ```mermaid flowchart TB A[查看資訊] --> B[分析資訊] B --> C[提出建議] C --> D[修改工作內容] D --> E[執行外部操作] E --> F[代表使用者對外行動] F --> H[人工確認] ``` 越接近外部世界，越需要人工確認。 例如，以下事項不應該只因為工作流很順，就直接自動完成： - 登入帳號 - 使用私人資料 - 讀取或傳遞機密 - 使用 API 金鑰 - 發送對外訊息 - 執行付款 - 發布內容 - 部署網站 - 進行不可逆的刪除或修改 統一介面可以把這些操作集中起來，但集中不等於放任。 它應該讓使用者更清楚看見：現在是哪個 Agent 在工作、它正在使用什麼權限，以及下一個動作是否需要本人確認。 ## Agent 越多，判斷未必更可靠 多個 Agent 可以協助找出不同角度，但數量本身不會自動產生正確答案。 它們可能共享同一個錯誤前提，也可能因為上下文相同而一起得出相似的錯誤結論。 因此，跨 Agent 協作需要區分三種東西： **圖 14｜原始資料、Agent 分析與人類判斷的分層** ```mermaid flowchart TB A[原始資料] --> B[Agent 的分析] B --> C[使用者或其他 Agent 的判斷] A -. 必須保留來源 .-> C ``` 這三者不能混在一起。 在交接時，最好標明： - 哪些內容已經確認 - 哪些內容來自原始資料 - 哪些內容是 Agent 的推論 - 哪些內容仍然待查 - 哪些內容只是暫時方向 這也是為什麼我不會把「多個 Agent 都同意」直接當成證明。 共識可以增加信心，但不能取代證據。 ## 統一介面也需要失敗時的退路 一個工作流如果只有成功路徑，還不能算完整。 跨 Agent 協作可能在不同地方中斷：某個 Agent 無法使用、權限不足、上下文不完整、輸出格式不符合、外部服務沒有回應，或不同 Agent 對同一個問題得出互相衝突的判斷。 因此，流程中應該預先保留退路： **圖 15｜Agent 失敗時的修正、轉交與人工接管** ```mermaid flowchart TB A[Agent 執行] --> B{結果符合驗收條件嗎？} B -->|是| C[交給下一步] B -->|否| D{問題是否可修正？} D -->|是| E[回到原 Agent 修正] D -->|否| F[交給另一個 Agent 審查] F --> G{是否需要人工判斷？} G -->|否| C G -->|是| H[停止並交回使用者] ``` 這個設計有一個重要含義：Agent 失敗時，系統應該清楚顯示失敗，不能為了讓流程看起來順利，就偷偷改變任務目標或降低驗收標準。 對使用者來說，「現在需要我判斷」本身就是一種有效的結果。 ## 從多模型使用，走向跨 Agent 工作系統 Claude、Codex、Antigravity 與 Grok 的存在，讓我們可以依照不同任務安排不同 Agent。 更值得注意的是，這些工具被放進了什麼樣的系統裡。 一個成熟的跨 Agent 工作系統，應該具備： **圖 16｜成熟跨 Agent 工作系統的核心組成** ```mermaid flowchart TB A[統一介面] --> B[清楚的任務拆解] B --> C[明確的角色分工] C --> D[可追蹤的 Agent 交接] D --> E[受控的權限邊界] E --> F[可驗收的輸出] F --> G[保留人工決策] ``` 這個系統的中心仍然是人。 人不必親自完成每一個步驟，但需要知道每一個步驟發生了什麼，也需要在關鍵地方保留停止與修正的能力。 對我來說，最有價值的變化，在於我可以在一個介面裡，讓不同 Agent 進入同一項工作，讓任務從規劃流向執行，再流向檢查與整合。 ## 人開始設計自己的 Agent 工作環境 過去我們問的是： > 哪一個 AI 最適合我？ 現在更值得問的是： > 我能不能在同一個介面裡，讓不同 Agent 各自完成適合自己的工作？ 這個問題的答案，取決於模型能力、介面設計、任務交接、權限管理與人工判斷如何被放在一起。 當 Claude 可以操作 Codex，Codex 可以回到 Claude，工作又能延展到 Antigravity 與 Grok，AI 的使用方式就不再只是「打開一個聊天視窗，等待一個回答」。 我與我們身邊的同溫層，已經開始建立的是一個由人類設定方向、由多個 Agent 協作完成的工作環境。 ・一個介面解決了工具切換的問題。 ・跨 Agent 交接解決了工作流動的問題。 而權限與人工驗收，則決定這個系統是否值得信任。重要的是我們能不能讓多個 Agent 在清楚的邊界內，為同一項工作彼此接力。每一位後AI時代的工作者都需要自己設計與優化最適合自己工作模式與流程的系統。