Claude Code 29 個工具 vs Codex 7 個工具：設計哲學完全相反

我厭倦了追蹤 Claude Code 和 Codex 每週的更新，於是回歸基本原則。我打開每一份 SDK 型別定義、每一個系統提示詞、每一個我找得到的設定結構描述。我想理解的不只是每款工具做了什麼，更想知道為什麼工具數量差異如此懸殊。

Claude Code 公開 29 個工具，Codex 公開 7 個。這個比例讓我一直耿耿於懷，因為它不可能只是功能上的落差。兩支資金充足、工程師頂尖的團隊，不會不小心就得出 4 比 1 的比例。這個落差是刻意為之的，背後的理由揭示了兩種截然不同的哲學：AI 應該如何與你的開發環境互動。

工具粒度是一種安全決策

最顯著的差異在於每款工具如何處理檔案操作。Claude Code 將檔案操作分拆成四個獨立工具：Read、Write、Edit 和 MultiEdit。搜尋也有專屬工具，Grep 和 Glob 完全獨立於 Bash 之外。這意味著你可以在 settings.json 中設定允許 Read 但封鎖 Write。你可以讓代理人搜尋程式碼庫，卻完全不授予它修改任何檔案的權限。權限控制在工具層級進行。

Codex 走了不同的路徑。它給代理人的核心基元是 shell、apply_patch 和 file_read。其餘一切都透過 shell 處理。想搜尋檔案？那是一個 shell 指令。想列出目錄？還是 shell。安全性不來自工具層級的權限，而是透過 execpolicy 規則，對特定 shell 指令進行模式比對，將它們分類為 allow、prompt 或 block。

兩種做法都沒有錯。Claude Code 的模型提供精細的鎖定控制，但需要維護更大的工具介面。Codex 的模型較容易理解，但把安全性強制執行推入了對 shell 指令的字串比對，當指令寫得更有創意時，就會變得脆弱。我曾見過精心設計的管線組合，繞過了原本針對相同指令的標準寫法而制定的 execpolicy 規則。

完整分類如下：

• Claude Code（29 個工具）：4 個檔案工具（Read/Write/Edit/MultiEdit）、3 個搜尋工具（Glob/Grep/LS）、2 個網路工具、3 個排程工具、4 個 MCP 工具、Bash 等
• Codex（7 個工具）：shell、apply_patch、file_read、web_search、update_plan、write_stdin、js_repl

技能部署拆分了生態系

兩款工具都採用了 Agent Skills 開放標準，以單一的 SKILL.md 檔案定義技能的行為。結構相同，但發佈模式不同。

Codex 建立了集中式發佈系統。執行 $skill-installer 即可從 OpenAI 官方技能存放庫拉取精選技能。傳入 GitHub URL 也能安裝第三方技能。甚至有 $skill-creator 可以透過對話互動式地產生新技能。整個體驗就像 npm：一道指令、一個登錄表、立即可用。

Claude Code 走向另一個方向。你需要手動在 .claude/skills/ 中建立 SKILL.md 檔案，或透過 /plugin marketplace add 從 git 存放庫安裝套件組合。沒有單一官方登錄表。技能透過社群存放庫、分享連結和口耳相傳來發掘。

我一開始偏好 Codex 的集中式模型，因為可探索性更好。但在兩者都使用了幾週之後，去中心化的做法有個真正的優勢：我可以在工作階段進行中編輯技能檔案，變更會立即生效，不需要重新啟動。Codex 已安裝的技能，若有修改則需要重新安裝。在迭代自訂工作流程時，這個差異比我預期的更重要。

一覽比較：

• 呼叫方式：Claude Code 使用 /skill-name，Codex 使用 $skill-name
• 儲存位置：.claude/skills/ vs .agents/skills/
• 內建技能：Claude Code 內附 /simplify、/batch、/loop、/claude-api；Codex 內附 $skill-installer、$skill-creator
• 發佈方式：去中心化市集 vs 集中式存放庫

工作階段診斷是差距真正體現之處

兩款工具共享基本功能：/model、/plan、/review、/clear、/fast。差異出現在工作階段的自我檢視能力上。

Claude Code 大力投資於讓你了解工作階段內部發生的事情。/compact 手動觸發情境壓縮。/context 顯示已載入的內容。/cost 即時追蹤 token 消耗。/doctor 診斷設定問題。/rewind 回滾到之前的對話狀態。/insights 分析一個月的使用模式並提出改善建議。/usage 顯示跨工作階段的累計用量。這是七個專門用於理解和管理工作階段狀態的指令。

Codex 著重於其他方面。/personality 調整代理人的溝通風格。/theme 改變視覺外觀。/apps 管理已連接的應用程式。這些是使用者體驗的客製化功能，不是診斷工具。

這反映了更深層的哲學分歧。Claude Code 把工作階段視為你應該主動監控和引導的東西。Codex 把它視為應該在背景順暢運行的東西，讓你專注於客製化體驗。使用數個月後，我發現自己兩者都想要。診斷功能在工作階段出問題時救了我，但在詳細架構工作和快速修錯之間切換時，我也很欣賞能夠調整個性的能力。

• Claude Code（約 35 個指令 + 4 個內建技能）：著重工作階段診斷，如 /compact、/context、/cost、/doctor、/rewind、/insights、/usage
• Codex（約 19 個指令）：在使用者體驗客製化方面更強，包含 /personality、/theme、/copy、/apps、/skills、/agent、/tools

團隊架構從不同的假設出發

每款工具如何處理多代理人協作，揭示了或許是最深層的設計差異。

Claude Code 的 Agent Teams 採用點對點通訊。團隊成員直接互相傳送訊息，不需透過主要代理人路由。他們共享任務清單並自主協調。你可以運行 2 到 16 個代理人，他們之間會自行協商誰負責什麼。我用三個代理人測試了一項重構任務，token 消耗是單一工作階段完成同樣工作的 3 到 7 倍。協調開銷是真實存在的。但當任務確實受益於平行探索時（例如偵錯競爭條件，你希望代理人同時探測不同假設），點對點模型找到答案更快。

Codex 使用中心輻射模型。子代理人只向父代理人回報，沒有橫向通訊。spawn_agents_on_csv 指令可從 CSV 檔案批次建立代理人，針對每個工作單元彼此獨立的高度平行任務進行最佳化。例如：「將這個遷移腳本套用到 200 個檔案」或「對清單中的每個端點執行這項檢查」。

點對點並非普遍更好。我曾在一個簡單的批次任務上浪費了大量 token，因為 Claude Code 的代理人不斷相互討論彼此的重疊工作。對那個特定任務而言，Codex 的中心輻射模型才是正確選擇。

• Claude Code：具共享任務清單的點對點訊息傳遞，支援 2 到 16 個代理人，tmux 分割面板支援
• Codex：中心輻射架構，透過 spawn_agents_on_csv 進行基於 CSV 的批次代理人建立

Hook 粒度決定自動化深度

Claude Code 讓你在工具執行的多個生命週期點進行攔截。PreToolUse 在工具執行前觸發，讓你可以驗證或修改呼叫。PostToolUse 在之後觸發，因此你可以附加一個格式化器，在每次儲存檔案時自動執行。Notification hooks 擷取代理人通訊。PreCompact 在情境壓縮前觸發，讓你有機會保留關鍵資訊。HTTP Hooks 可以將 JSON POST 到外部 URL，將 Claude Code 連接到 CI 管線、Slack 或自訂儀表板。

Codex 保持簡單。一個 execpolicy 檔案，包含套用到 shell 指令的 allow/prompt/block 規則。這就是控制代理人行為的整個可擴充介面。

我設定了一個 PostToolUse hook，在每次 Write 操作後執行 Prettier。只花了五分鐘，就消除了整整一類與格式化相關的後續提示詞。這種外科手術式的自動化在 Codex 的模型中是不可能的，你需要在每個提示詞中加入「寫完後執行 prettier」，或把它內建到技能中。

但 Codex 的簡潔也有其價值。我從未因為設定錯誤的 hook 而不小心破壞 Codex 的設定。這種事我在 Claude Code 上發生了兩次，一次是有個 PreToolUse hook 靜默封鎖了合法的檔案讀取，導致我困惑地偵錯了二十分鐘。

• Claude Code：PreToolUse、PostToolUse、Notification、PreCompact 以及 HTTP Hooks
• Codex：具三個層級（allow/prompt/block）的 execpolicy 規則檔案

選擇架構，而非功能清單

29 對 7 的比較，不是關於哪款工具功能更強大。而是兩個不同的答案，回應相同的設計問題：AI 程式開發代理人應該將其能力分解為多少個可個別控制的單元？

Claude Code 的答案是「全部」。每個操作都有自己的工具、自己的權限介面、自己的 hook 點。這給你最大的控制權，代價是設定的複雜性。Codex 的答案是「只要必要的」。核心操作有專屬工具；其餘一切透過 shell 搭配基於政策的防護措施流通。這給你簡潔性，代價是粒度。

當我決定對特定專案使用哪款工具時，功能清單幾乎無關緊要。重要的是這個專案是否需要精細的權限控制（受監管的程式碼庫、具有不同存取層級的多位貢獻者），還是需要輕量的簡潔性（個人專案、快速迭代、最少設定）。你所建構的架構，將決定隨之而來的每一個工作流程決策。