Claude Code 29个工具 vs Codex 7个工具：设计理念截然相反

我厌倦了追踪Claude Code和Codex每周的更新，于是回归到了最基本的问题。我打开了所有能找到的SDK类型定义、系统提示词和配置schema，想弄清楚的不只是每款工具能做什么，而是为什么工具数量会有如此大的差异。

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个Web工具、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
• 发布方式：去中心化marketplace vs 集中式仓库

会话诊断才是真正体现差距的地方

两款工具都具备基础功能：/model、/plan、/review、/clear、/fast。差异体现在会话内省能力上。

Claude Code在帮助你理解会话内部状态方面投入了大量精力。/compact可手动触发上下文压缩，/context显示已加载的内容，/cost实时追踪token消耗，/doctor诊断配置问题，/rewind回滚到之前的对话状态，/insights分析一个月的使用模式并提出改进建议，/usage显示跨会话的累计消耗。七条命令，全部用于理解和管理会话状态。

Codex将重点放在了其他地方。/personality调整智能体的沟通风格，/theme更改视觉外观，/apps管理已连接的应用。这些是用户体验定制功能，而非诊断工具。

这反映了一种更深层的理念分歧。Claude Code将会话视为你应该主动监控和引导的东西，Codex则将其视为应该在后台自行运转的东西，让你专注于定制体验。用了好几个月之后，我发现自己两者都想要。诊断功能在会话出问题时救了我，但我也很欣赏在做架构设计和快速修bug之间切换时能调整personality。

• 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倍，协调开销确实存在。但当任务真正受益于并行探索时（比如调试竞态条件，你希望智能体同时探索不同假设），P2P模型能更快找到答案。

Codex使用轮辐式架构，子智能体只向父智能体汇报，没有横向通信。spawn_agents_on_csv命令可以从CSV文件批量创建智能体，专为每个工作单元相互独立的并行任务而优化。比如：“对200个文件应用这个迁移”或”对列表中的每个端点运行这项检查”。

P2P并非总是更好的选择。我在一个简单的批处理任务上浪费了大量token，因为Claude Code的智能体不断就相互重叠的工作进行讨论。对那个特定的任务来说，Codex的轮辐式架构才是正确选择。

• Claude Code：共享任务列表的P2P消息传递，支持2到16个智能体，支持tmux分屏
• Codex：轮辐式架构，通过spawn_agents_on_csv进行CSV批量智能体创建

Hook粒度决定自动化深度

Claude Code允许你在工具执行的多个生命周期节点拦截操作。PreToolUse在工具运行前触发，让你可以验证或修改调用；PostToolUse在运行后触发，可以附加一个格式化程序在每次文件保存时自动运行；Notification Hook捕获智能体通信；PreCompact在上下文压缩前触发，让你有机会保留关键信息；HTTP Hook可以向外部URL发送JSON，将Claude Code连接到CI流水线、Slack或自定义仪表盘。

Codex保持了简洁。一个execpolicy文件，其中包含应用于shell命令的allow/prompt/block规则，这就是控制智能体行为的全部扩展接口。

我设置了一个PostToolUse Hook，在每次Write操作后运行Prettier。只花了五分钟，就消除了整类与格式相关的后续提示。这种精细的自动化在Codex的模型中无法实现，在Codex里你要么在每个提示词中加上”写完之后运行prettier”，要么将其构建进一个技能里。

但Codex的简洁也有其价值。我从未因为Hook配置错误而搞坏Codex的配置。而在Claude Code上，我做到了两次：一次是PreToolUse Hook悄悄阻断了合法的文件读取，导致困惑地调试了二十分钟。

• Claude Code：PreToolUse、PostToolUse、Notification、PreCompact以及HTTP Hook
• Codex：三级规则（allow/prompt/block）的execpolicy规则文件

选择架构，而非功能列表

29与7的对比，并不是说哪款工具更强大，而是对同一设计问题的两种不同回答：AI编程智能体应该将其能力分解为多少个可独立控制的单元？

Claude Code的答案是”全部”。每个操作都有自己的工具、自己的权限面、自己的Hook点，以最大控制权换取配置复杂度。Codex的答案是”只保留核心”。核心操作有专属工具，其他一切通过shell加策略guardrail完成，以简洁换取粒度。

当我为一个项目选择工具时，功能列表几乎不重要。重要的是项目是否需要精细的权限控制（受监管的代码库、多个不同访问级别的贡献者），还是只需要轻量的简洁性（个人项目、快速迭代、最小化配置）。你所构建的架构基础，决定了后续每一个工作流决策的走向。