Claude Code 29 個工具 vs Codex 7 個工具：設計哲學南轅北轍

我對追蹤 Claude Code 同 Codex 每週更新感到厭倦，於是返回基本功。我逐一翻閱所有 SDK 類型定義、每個系統提示、每份 settings schema。我唔單止想知道每個工具做咩，更想搞清楚點解工具數量的差距會咁懸殊。

Claude Code 提供 29 個工具，Codex 提供 7 個。這個比例一直令我耿耿於懷，因為唔可能純粹係功能差距。兩個資金充裕、工程師頂級的團隊，唔會無意中落得個 4:1 的比例。這個差距係刻意為之，背後的原因揭示了兩種截然不同的哲學，關於 AI 應該點樣同你的開發環境互動。

工具粒度係一個安全決策

最明顯的分別在於每個工具點樣處理檔案操作。Claude Code 將檔案操作拆分成四個獨立工具：Read、Write、Edit 同 MultiEdit。搜尋同樣有專屬工具，Grep 同 Glob 完全獨立於 Bash 之外。這意味你可以配置 settings.json 允許 Read 但封鎖 Write。你可以讓 agent 搜尋你的 codebase，同時完全唔需要授予佢修改任何檔案的權限。權限控制發生在工具層面。

Codex 走另一條路。它將 shell、apply_patch 同 file_read 作為核心 primitives 交俾 agent。其他所有操作都經過 shell 進行。想搜尋檔案？Shell 指令。想列出目錄？又係 shell。安全性唔係來自工具層面的權限，而係來自 execpolicy 規則，透過 pattern matching 比對特定 shell 指令，將其分類為 allow、prompt 或 block。

兩種方式都沒有錯。Claude Code 的模型提供精細的鎖定機制，但需要維護更大的工具介面。Codex 的模型更易理解，但將安全執行推到對 shell 指令進行字串匹配，當指令變得有創意時就容易出問題。我見過有人精心設計一條 pipe chain，繞過了一條針對同一指令標準寫法而編寫的 execpolicy 規則。

完整分類如下：

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

Skill 部署方式分裂了生態系統

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

Codex 建立了一個集中式分發系統。執行 $skill-installer 可從 OpenAI 官方 skills 庫拉取精選技能。傳入 GitHub URL 便可安裝第三方 skills。甚至有 $skill-creator 讓你透過對話互動式地生成新 skills。整個體驗就像 npm：一個指令、一個 registry、即時可用。

Claude Code 走相反方向。你需要手動在 .claude/skills/ 建立 SKILL.md 檔案，或透過 /plugin marketplace add 從 git 倉庫安裝套件。沒有單一官方 registry，skills 靠社群倉庫、分享連結同口耳相傳去發掘。

我最初偏好 Codex 的集中式模型，因為可探索性更好。但用了幾個星期之後，去中心化的方式有個真正的優勢：我可以喺 session 中途編輯 skill 檔案，改動即時生效，唔需要重啟。Codex 已安裝的 skills 若有改動就要重新安裝。當你不斷迭代自訂工作流程時，這個分別比我預期的更重要。

快速對比：

• 調用方式：Claude Code 用 /skill-name，Codex 用 $skill-name
• 儲存位置：.claude/skills/ vs .agents/skills/
• 內建 skills：Claude Code 帶有 /simplify、/batch、/loop、/claude-api；Codex 帶有 $skill-installer、$skill-creator
• 分發方式：去中心化市集 vs 集中式倉庫

Session 診斷是差距最明顯的地方

兩款工具都有基本功能：/model、/plan、/review、/clear、/fast。分歧出現在 session 內部觀察上。

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

Codex 着力點在別處。/personality 調整 agent 的溝通風格。/theme 改變視覺外觀。/apps 管理已連接的應用程式。這些是 UX 自訂功能，唔係診斷工具。

這反映了更深層的哲學分歧。Claude Code 將 session 視為你應該主動監控和引導的東西。Codex 則將其視為在背景自行運作的東西，讓你專注於自訂體驗。用了幾個月之後，我發現自己兩樣都想要。診斷功能在 session 出問題時救了我，但我同樣欣賞能夠在詳細架構工作同快速修 bug 之間切換時調整 personality。

• Claude Code（約 35 個指令 + 4 個內建 skills）：着重 session 診斷，例如 /compact、/context、/cost、/doctor、/rewind、/insights、/usage
• Codex（約 19 個指令）：UX 自訂更強，提供 /personality、/theme、/copy、/apps、/skills、/agent、/tools

團隊架構出發點不同

每個工具處理多 agent 協作的方式，揭示了可能是最深層的設計差異。

Claude Code 的 Agent Teams 使用點對點通訊。隊員直接互相發訊息，唔需要透過主 agent 轉發。他們共享任務清單，自主協調。你可以運行 2 至 16 個 agents，他們會自行商討誰負責什麼。我用三個 agents 測試一個重構任務，token 消耗係單一 session 做同樣工作的 3 至 7 倍。協調開銷係真實存在的。但當任務真正受益於並行探索時（例如調試競態條件，你希望 agents 同時探索不同假設），P2P 模型會更快找到答案。

Codex 採用輪轂架構。子 agents 只向父 agent 匯報，沒有橫向通訊。spawn_agents_on_csv 指令可從 CSV 檔案批量創建 agents，針對每個工作單元互相獨立的並行任務進行優化。例如：「將這個 migration 應用到 200 個檔案」或「對清單中每個 endpoint 執行這項檢查」。

P2P 並非在所有情況下都更好。我在一個直接的批量任務上浪費了大量 token，因為 Claude Code 的 agents 不斷互相討論他們的重疊工作。Codex 的輪轂架構才是那個特定任務的正確選擇。

• Claude Code：P2P 訊息傳遞，共享任務清單，2 至 16 個 agents，支援 tmux split-pane
• Codex：輪轂架構，透過 spawn_agents_on_csv 以 CSV 批量生成 agents

Hook 粒度決定自動化深度

Claude Code 讓你在工具執行的多個生命週期節點進行攔截。PreToolUse 在工具執行前觸發，讓你驗證或修改呼叫。PostToolUse 在執行後觸發，你可以附加一個 formatter，在每次儲存檔案時自動執行。Notification hooks 捕捉 agent 通訊。PreCompact 在 context 壓縮前觸發，讓你有機會保留關鍵資訊。HTTP Hooks 可以將 JSON POST 到外部 URL，將 Claude Code 連接到 CI pipeline、Slack 或自訂 dashboard。

Codex 保持簡單。一個 execpolicy 檔案，包含應用於 shell 指令的 allow/prompt/block 規則。這就是控制 agent 行為的全部擴展介面。

我設置了一個 PostToolUse hook，在每次 Write 操作後執行 Prettier。花了五分鐘，消除了整類與格式相關的後續提示。這種精準的自動化在 Codex 的模型中無法實現，你需要在每個提示中加入「寫完之後執行 prettier」，或將其內建到一個 skill 裡。

但 Codex 的簡單性同樣有其價值。我從來沒有因為配置錯誤的 hook 而意外破壞 Codex 設定。這件事在 Claude Code 上我幹了兩次，一次係一個 PreToolUse hook 靜默封鎖了合法的檔案讀取，導致二十分鐘的困惑調試。

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

選擇架構，而非功能清單

29 vs 7 的比較唔係關於哪個工具更有能力。而係針對同一個設計問題的兩種不同答案：AI 編程 agent 應該將自身能力分解成多少個可獨立控制的單元？

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

當我為某個項目選擇使用哪個工具時，功能清單幾乎唔重要。重要的是這個項目需要精細的權限控制（受監管的 codebase、多個不同存取級別的貢獻者），還是輕量的簡單性（個人項目、快速迭代、最少設置）。你建立在上面的架構，塑造了後續每一個工作流程決策。