# Claude Code 29 個工具 vs Codex 7 個工具：設計哲學完全相反 > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ > Reading time: 2 minutes > Language: zh-TW > Tags: claude-code, codex, ai-agents, developer-tools, ai-coding, security ## Canonical https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Rollout Alternates en: https://tonylee.im/en/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ko: https://tonylee.im/ko/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ja: https://tonylee.im/ja/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-CN: https://tonylee.im/zh-CN/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-TW: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Description 我深入研究了兩款工具的 SDK 型別定義和系統提示詞。29 對 7 的落差不在於功能數量，而是兩個截然不同的答案，回應同一個問題：AI 程式開發代理人該如何與你的系統互動？ ## Summary Claude Code 29 個工具 vs Codex 7 個工具：設計哲學完全相反 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - 工具粒度是一種安全決策 - 技能部署拆分了生態系 - 工作階段診斷是差距真正體現之處 - 團隊架構從不同的假設出發 - Hook 粒度決定自動化深度 - 選擇架構，而非功能清單 ## Content 我厭倦了追蹤 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 搭配基於政策的防護措施流通。這給你簡潔性，代價是粒度。 當我決定對特定專案使用哪款工具時，功能清單幾乎無關緊要。重要的是這個專案是否需要精細的權限控制（受監管的程式碼庫、具有不同存取層級的多位貢獻者），還是需要輕量的簡潔性（個人專案、快速迭代、最少設定）。你所建構的架構，將決定隨之而來的每一個工作流程決策。 ## Related URLs - Author: https://tonylee.im/zh-TW/author/ - Publication: https://tonylee.im/zh-TW/blog/about/ - Related article: https://tonylee.im/zh-TW/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/zh-TW/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/zh-TW/blog/codex-folder-structure-why-config-breaks/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/zh-TW/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.