Codex vs Claude Code：兩套 Subagent 機制怎麼選

現在的 AI 編程工具越來越重視 Subagent。這不是功能跟風，而是單個 Agent 處理真實工程任務時，很快會碰到邊界。

如果一個 Agent 同時負責讀程式碼、查日誌、改實作、跑測試、分析錯誤、總結結果，主上下文很快會變髒。搜尋結果、命令輸出、測試日誌和中間推理混在一起，後續判斷就會被噪音干擾。任務也很難並行：探索、實作、驗證和審查都塞在同一條主線上。

Subagent 的本質，是替 Agent 減壓。主會話不再從頭到尾做完所有事，而是更像協調者：判斷目標、安排任務、接收結果，再把結果合成最終答案。子 Agent 處理某一段局部工作，例如探索、實作、驗證或審查，最後只帶回壓縮後的結論。

所以 Subagent 不是「再開一個同款自己」，而是把原本糊成一團的工程工作拆成邊界更清楚的角色。

底層共識

成熟的 Subagent 系統通常繞不開四件事：

上下文隔離。
角色專用化。
專案和使用者級配置。
工具與權限邊界。

上下文隔離是前提。真實倉庫裡的中間結果很多：搜尋結果、測試日誌、命令輸出都可能很吵。如果全部塞進主會話，主線很快會混亂。Subagent 的價值之一，就是讓局部過程先在局部被消化，主會話只看到有決策價值的結論。

角色專用化也很重要。多 Agent 不是多開幾個一樣的模型。探索型角色要擅長搜尋、閱讀和總結；實作型角色要專注改碼；驗證型角色要跑檢查、識別風險，並清楚回報。

工具和權限邊界決定系統能否安全落地。子 Agent 不應預設擁有主會話的全部能力。探索角色未必需要寫檔案，驗證角色未必需要改實作，背景任務和 worktree 隔離也應保持可見。

在這些共識之上，Codex 和 Claude Code 走出了不同路線。

Codex：顯式派工

Codex 的 Subagent 設計更克制。

它提供一套受控、輕量、圍繞當前主會話展開的分工機制。什麼時候派活、派給誰、什麼時候收結果，都由主會話明確決定。控制流始終留在當前任務裡。

它的特點是：

主會話明確發起委託。
角色集保持輕量。
主會話知道哪個 Agent 在做什麼。
結果回到主線後再統一判斷。
協作邊界透明。

這種方式適合重視手動編排、可預期性和執行確定性的團隊。可以先派探索角色查清調用鏈，再派工作角色做小範圍修改，最後由主會話整合結果並決定是否繼續測試。

缺點是編排壓力仍在主會話身上。主會話要判斷何時拆分、怎麼拆、交給誰、怎麼合併結果。輕量協作很舒服，但長期複雜工程流可能會變累。

Claude Code：正式工位

Claude Code 的取向更平台化。

它不是只提供幾個臨時幫手，而是把 Agent 做成可描述、可選擇、可配置、可記憶、可隔離、可背景執行的正式物件。子 Agent 不只是會話裡的工具，更像工程系統裡的一個工位。

系統可以把 Agent 列表、適用場景、描述資訊和工具邊界交給模型，讓模型判斷本輪該呼叫哪個角色。這類模型驅動的委託帶來更強自動化。

它的關鍵能力包括：

第一，角色體系。探索、規劃、通用處理、驗證等角色可以帶用途說明、工具限制、預設模型和執行條件。探索型角色可以只讀，規劃型角色負責方案，驗證型角色專注檢查。

第二，繼承和覆蓋。子 Agent 預設繼承主會話的大邊界，但可在規則允許範圍內做局部調整。主會話定義大邊界，Agent 在邊界內局部裝配。

第三，記憶。記憶可以有作用域：使用者級記憶像長期偏好，專案級記憶像倉庫背景，本地級記憶像當前環境狀態。某些 Agent 不必每次從零理解專案。

第四，背景和 worktree 隔離。某些驗證任務可以在背景持續執行，主線不用原地等待。需要強隔離時，Agent 可進入獨立 worktree，同一專案內操作空間被明確隔開。

第五，插件生態。當 Agent 是正式物件時，就需要考慮分發、安裝、覆蓋、排序和安全。插件 Agent 可以進入系統，但高風險欄位如 permission mode、hooks、MCP servers 應被收口。

這讓 Claude Code 更像 Agent runtime，而不是單次會話裡的協作工具。

兩種路線的差異

可以把兩者理解成兩種產品哲學。

Codex 更像受控分工工具：

主對話明確派工。
角色集合保持輕量。
控制流程清楚。
子任務圍繞目前對話展開。
適合強調確定性和人工編排的工作方式。

Claude Code 更像工程工位系統：

Agent 被正式建模。
角色更具系統性。
支援記憶、背景執行、隔離和外掛生態。
模型可以參與選擇角色。
適合長期專案、複雜工作流程和平台化擴充。

這不是誰的功能較多誰就更好。真正的差別在於：你希望 Subagent 是「我明確叫來的助手」，還是「系統裡長期存在的工位」。

怎麼選

Codex 更像受控分工工具：顯式派工、角色輕量、控制流清晰、子任務圍繞當前會話，適合強調確定性和人工編排的工作方式。

Claude Code 更像工程工位系統：Agent 被正式建模，角色更體系化，記憶、背景執行、隔離和插件都屬於 runtime，適合長期專案和平台化工作流。

真正的問題不是誰功能更多，而是你希望 Subagent 是「我明確叫來的助手」，還是「系統裡長期存在的工位」。

可以問兩個問題：

你能不能接受模型自己選擇該派誰幹活？
你是否需要更完整的 Agent runtime？

如果第一個問題讓你不舒服，顯式派工更合適。若第二個答案是肯定的，平台化工位系統更值得考慮。

使用建議

不要把 Subagent 當作「多開幾個模型就更強」。更有效的做法是：

給每個角色明確任務邊界。
控制每個角色可用工具。
讓子 Agent 回傳結論，而不是原始日誌。
主會話保留最終決策權。
讓背景任務和 worktree 隔離保持可見。
對插件 Agent 設定清楚安全邊界。

Subagent 的價值不在數量，而在分工品質。角色越清楚，上下文越乾淨，主線判斷越穩。

Claude Code subagent 的適用專案與落地方法

適合場景一：大型程式碼庫摸底

剛接手陌生專案時，最常見的問題不是「程式碼怎麼改」，而是「我根本不知道從哪裡看」。

這時 subagent 很有用。主會話只負責提出問題和彙總結論，把探索任務拆出去：

api-reader：只看路由、控制器、介面鑑權。
db-reader：只看 schema、migration、ORM model。
frontend-reader：只看頁面結構、狀態管理、元件入口。
test-reader：只看測試框架、覆蓋範圍、執行命令。

每個 subagent 最後只返回 5 到 10 條結論。主會話不用背下整個倉庫細節，只需要拿到一張結構化地圖。

這特別適合 monorepo、歷史包袱較重的業務系統、前後端混合倉庫、測試與部署腳本散落的專案，以及技術債評估。

如果你正在設計 Codex 和 Claude Code 的接力方式，可以把這類「讀倉庫、摸結構」任務放在 Claude Code subagent 側，再把結論交給 Codex 執行更長的修改流程。相關思路可以看：Codex 和 Claude Code 任務接力教程：從實作、審查到長任務恢復。

適合場景二：程式碼審查拆角色

subagent 很適合做程式碼審查，因為審查天然可以按關注點拆開：

bug-reviewer：找邏輯錯誤、空值、邊界條件、回歸風險。
security-reviewer：看權限、輸入校驗、密鑰、注入、越權。
performance-reviewer：看迴圈、查詢、快取、渲染、並發瓶頸。
test-reviewer：看測試是否覆蓋真實風險，而不是只補 snapshot。

但要注意邊界：審查型 subagent 最好預設只讀。

更穩妥的流程是：

主會話收集 diff。
多個只讀 subagent 分別審查。
主會話合併結論，決定改哪些。
由主會話或一個明確的 fixer subagent 做小範圍修改。

如果你關注「Claude Code 和 Codex 程式碼審查流程怎麼搭」，可以看這篇閉環流程文章：Claude Code 和 Codex 代碼審查流程怎麼搭：從本地改動到 PR 的閉環工作流。

適合場景三：測試失敗和日誌雜訊處理

自動化測試失敗時，主會話最容易被大量輸出拖慢。前端 E2E、後端整合測試、CI 日誌，失敗資訊常常夾在幾百行輸出裡。

這類任務很適合交給 test-runner subagent：

執行指定測試命令；
截取失敗用例；
歸納失敗原因；
標出最可能相關的檔案；
不直接修程式，只返回排查建議。

subagent	建議工具	適合任務
`test-runner`	`Bash, Read, Grep`	跑測試、讀日誌、定位失敗
`log-analyzer`	`Read, Grep, Glob`	分析日誌和錯誤堆疊
`coverage-reviewer`	`Read, Grep, Glob`	找缺失測試和高風險分支

如果你已經用 Claude Code hooks 自動執行測試，可以讓 hooks 負責「觸發」，subagent 負責「解釋失敗」：。

適合場景四：大重構前的影響面分析

大重構最怕一上來就改。subagent 更適合先做「只讀偵察」。

例如替換認證模組、升級資料庫存取層、重構前端狀態管理，可以讓多個 subagent 分別回答：

哪些檔案直接依賴舊介面？
哪些測試覆蓋了這塊邏輯？
哪些呼叫路徑最容易破壞相容性？
是否存在文件、腳本、設定也要同步改？
哪些地方應該先加測試再動手？

關鍵是：subagent 輸出影響面，不要急著輸出 patch。

主會話拿到影響面後，再決定一次性改、分階段改，還是先補測試。這也有助於長任務中斷後恢復，因為每個階段都有清晰結論。可參考：。

不適合場景：別把所有任務都拆成 subagent

subagent 有成本。它會消耗額外上下文、額外等待時間，也會增加協調複雜度。

通常不建議用於：

1. 小到可以直接解決的問題

例如 typo、import、CSS class、一行空值判斷、設定項更新。主會話直接做最快。

2. 邊界不清的需求

「幫我最佳化這個專案」「讓頁面更好看」這類需求，拆分前需要先問清目標、約束和驗收標準。

3. 需要頻繁協商的任務

subagent 適合獨立工作，不適合每改兩行就重新討論設計。

4. 多個代理同時寫同一批檔案

更好的方式是先只讀審查，再由一個執行者統一落地。

5. 高風險外部操作

涉及生產環境、真實帳號、付費 API、刪除資料、改權限、發郵件或訊息的任務，不要輕易交給背景 subagent 自動執行。

專案級 subagent 應該怎麼設計

Claude Code 支援把 subagent 寫成 Markdown 檔案。專案級 subagent 通常放在：

1

.claude/agents/

全域可複用的 subagent 通常放在：

1

~/.claude/agents/

專案級適合寫進倉庫，因為它反映的是這個專案自己的約定，例如測試命令、目錄結構、審查重點、禁止修改的檔案、輸出格式。

一個最小只讀程式碼審查 subagent 可以這樣寫：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


---
name: code-reviewer
description: Use when the task needs a read-only review of code changes for bugs, regressions, security risks, and missing tests.
tools: Read, Grep, Glob
---

# Code Reviewer

只做只讀審查，不修改檔案。

重點檢查：

- 邏輯錯誤和邊界條件
- 可能的回歸風險
- 安全和權限問題
- 缺失的測試
- 與專案現有風格不一致的實作

輸出格式：

1. 先列高風險問題。
2. 每個問題給出檔案路徑和原因。
3. 沒有發現問題時明確說明。
4. 不要輸出大段重寫後的程式碼。

最重要的不是正文有多長，而是 description 要寫清楚。Claude Code 會根據 description 判斷何時呼叫這個 subagent。

常見 subagent 組合

實際專案裡，不建議一開始就建十幾個 subagent。先從 3 到 5 個高頻角色開始：

名稱	工具	作用
`code-reviewer`	`Read, Grep, Glob`	只讀審查 bug、回歸和測試缺口
`test-runner`	`Bash, Read, Grep`	執行測試並解釋失敗
`docs-researcher`	`Read, Grep, Glob`	整理專案文件、遷移說明、約定
`security-reviewer`	`Read, Grep, Glob`	審查權限、輸入、密鑰、注入風險
`refactor-planner`	`Read, Grep, Glob`	大改前分析影響面和分階段計畫

如果某個 subagent 經常只輸出泛泛建議，說明角色太虛。要麼縮小任務範圍，要麼補充專案規則。

怎麼呼叫 subagent

可以用自然語言顯式呼叫：

1

Use the code-reviewer subagent to review the current diff. Do not modify files.

也可以點名具體 subagent，例如 @code-reviewer，或用命令列啟動：

1

claude --agent code-reviewer

關鍵任務盡量顯式點名，不要完全依賴自動委派。尤其是審查、測試、遷移評估，明確說「只讀」「不要改檔案」「只返回結論」會穩定很多。

一個實用判斷公式

如果不確定要不要用 subagent，可以問 5 個問題：

任務能不能按模組、目錄、角色或關注點拆開？
子任務之間是否相對獨立？
子任務輸出能不能壓縮成明確結論？
是否需要不同工具權限？
上下文隔離收益是否大於額外 token 和等待成本？

如果 5 個問題裡有 3 個以上答案是「是」，就適合嘗試 subagent。只有 1 個是「是」，大概率不值得拆。

避坑清單

subagent 名稱要具體，不要叫 helper、assistant、worker。
description 要寫觸發場景。
審查型 subagent 預設只讀。
寫程式型 subagent 一次只負責一個小範圍。
大重構先做影響面分析，再決定誰來改。
測試 subagent 應返回失敗摘要，不要把完整日誌塞回主會話。
多個 subagent 的輸出由主會話合併。
高風險操作要限制工具和範圍。
專案級規則放 .claude/agents/，個人習慣放 ~/.claude/agents/。
定期刪掉低頻、重複、輸出品質差的 subagent。

參考資料

小結

Codex 和 Claude Code 都在解決同一個問題：單個 Agent 很難承載真實工程任務。它們都承認上下文隔離、角色專用、權限邊界和局部匯總的重要性。

差異在於取向。Codex 更克制，強調顯式派工和主會話控制；Claude Code 更體系化，把 Agent 做成可配置、可記憶、可隔離、可背景執行、可進入插件生態的正式工位。

選哪個，不是看哪個品牌贏，而是看你的工作方式需要受控協作工具，還是完整 Agent runtime。