Claude Code vs Codex：两种 Agent 编排哲学
一句话结论
市面上常把「Claude Code」和「Codex」对立成「本地可编程 vs 云端黑盒」——这是错的。两者的 CLI 都是运行在本地的 coding agent，而且都支持 Skill、Hook、MCP、AGENTS.md、memory 这一整套可编程机制。 真正的差异在三个地方：实现栈（TypeScript/Bun vs Rust）、执行模型（Claude Code 全程本地，Codex 能把子任务丢到云端沙箱并行跑）、以及集成深度（Claude Code 有 IDE Bridge + 企业权限体系，Codex 主打多模型 provider）。理解这三个差异，才不会被「谁更强」这种伪问题带偏。
一、先澄清一个常见误解：Codex 到底指哪个
「Codex」这个词对应至少四个产品，很多对比文章把它们混为一谈：
| 产品 | 是什么 | 在哪 |
|---|---|---|
| Codex CLI | 本地 coding agent（openai/codex 仓库，Rust 写的 codex-rs） | 你本机 |
| Codex Web | 云端 agent | chatgpt.com/codex |
| Codex App | 桌面应用（codex app） | 桌面 |
| Codex in IDE | VS Code / Cursor / Windsurf 里的 Codex | 编辑器 |
和 Claude Code 对比的是「Codex CLI」（本地那个），不是 Codex Web。Codex CLI 的 README 原话就是 “a coding agent from OpenAI that runs locally on your computer”。所以「Codex = 云端黑盒」这个印象，其实是把 Codex Web 张冠李戴到了 Codex CLI 头上。
💭 思考：为什么这篇要先花一整节澄清「Codex 到底指哪个」？—— 因为「对比」这个动作的前提是双方处于同一类。如果对比对象是 Codex Web（云端 agent），那「本地 vs 云端」的结论成立，但这句结论套到 Codex CLI（本地 coding agent）头上就是错的。这个错误有实际代价：它会把你导向「要可编程就选 Claude Code、要云端就选 Codex」这种错误选型。所以先对齐「在比哪个 Codex」，不是咬文嚼字，而是让后面的差异（实现栈、执行模型、集成深度）建立在同一基准上——否则「谁更强」从一开始就比错了对象。
二、Claude Code：TypeScript 写的本地全能 agent
从恢复的客户端源码（约 51 万行，来自 @anthropic-ai/claude-code 的 source map）能看出它的完整骨架：
- 主循环在
QueryEngine.ts——这对应上一篇文章讲的 Tool Loop，是那个while循环的产品化实现。 - UI 用 React + Ink——一个真正的终端原生应用，而不是「API 壳 + 打印」。
- 工具系统：
src/tools/下有 42 个一级工具目录，覆盖文件读写、搜索、Web、任务、LSP、MCP、计划模式、worktree、Agent/Team 等。 - 命令系统：
src/commands/下有 86 个一级命令目录 + 15 个根级命令文件（/review、/commit、/mcp、/memory、/permissions、/resume、/doctor等）。 - 服务层
src/services/：API、MCP、OAuth、插件、LSP、策略限制（policyLimits）、设置同步、团队记忆同步——这些说明它不只是一个本地工具，而是一套带企业能力的产品。 - Bridge 与 Remote：
src/bridge/接 IDE（VS Code/JetBrains），src/remote/支持远程会话、Direct Connect、SSH Remote。 - 权限体系：
src/hooks/toolPermission/是主干的一部分——「安全地写代码」是核心价值，不是附属。
一句话：Claude Code 是一个用 TypeScript/Bun 写成的、深度集成本地环境与 IDE 的 agent runtime，扩展点（skill/hook/subagent/MCP）是它的公开能力。
三、Codex CLI：Rust 写的本地 agent + 云端沙箱并行
Codex CLI 的 codex-rs 是一个 Rust workspace，从目录结构能看出它的设计重心：
- 核心在
core/：agent、codex_delegate.rs（委托）、codex_thread.rs（线程）、compact.rs（上下文压缩）、config。 - 云端沙箱：
sandboxing/、linux-sandbox/、bwrap/（bubblewrap）、windows-sandbox-rs/——这是 Codex 最鲜明的差异化：代码执行可以隔离在沙箱里，甚至丢到云端跑。 - 并行 delegation：
cloud-tasks/、cloud-tasks-client/、thread-store/——把一个大任务拆成多个子任务，并行派发执行。这正是 Claude Code 的 subagent 做不到的形态：Claude Code 的 subagent 主要在同机上下文里隔离，Codex 的子任务是真正的云端并行任务。 - 多模型 provider：
model-provider/、chatgpt/、ollama/、lmstudio/、models-manager/——Codex 不是只绑 OpenAI 模型，还能接本地模型（Ollama、LM Studio）。 - 同样有 skill/hook/MCP/AGENTS.md/memory：
skills/、hooks/、codex-mcp/、mcp-server/、agents_md.rs（AGENTS.md 解析）、memories/——这些可编程机制，Codex 一个都不少。其中AGENTS.md是业界正在统一的 agent 指令标准。 - TUI + app-server：
tui/做终端 UI，app-server/、app-server-daemon/支撑桌面应用。
一句话：Codex CLI 是一个 Rust 写成的本地 agent，它的杀手锏是「云端沙箱 + 并行 delegation + 多模型」，而不是「可编程性」（可编程性它也有）。
💭 思考：为什么 Codex 的杀手锏落在「云端沙箱 + 并行 delegation」，而不是可编程性？—— 从「它押注的约束」反推：Codex 的差异化能力在
cloud-tasks、codex_delegate、sandboxing这些目录里，它们解决的是同一个问题——「一次改几十个文件、跑一堆测试」这种吞吐密集型任务。这类任务的瓶颈不在「规则多、要模型读懂」，而在「循环够不够鲁棒、能不能无人值守并行跑完」。所以它把子任务派出去后强制never审批、把执行丢进隔离沙箱，人只守在验收端。可编程性（skill/hook/MCP）它也全有，但那不是它要和你比的地方——比可编程性，两者打平；比并行吞吐，它才有独门。
四、真正的差异：不是「可编程 vs 黑盒」
把两边拆开对齐后，差异集中在三点：
| 维度 | Claude Code | Codex CLI |
|---|---|---|
| 实现栈 | TypeScript + Bun + React/Ink | Rust + 自定义 TUI |
| 执行模型 | 全程本地；subagent 在同机隔离上下文 | 可把子任务丢到云端沙箱并行跑（cloud-tasks） |
| 模型绑定 | 主打 Anthropic 自家模型 | 多模型：OpenAI + 本地（Ollama/LM Studio） |
| 集成深度 | IDE Bridge + 企业权限/策略/同步 | GitHub/IDE + 桌面 app |
| 扩展机制 | Skill / Hook / Subagent / MCP | Skill / Hook / MCP / AGENTS.md / memory |
三个最值得记住的判断：
- 可编程性两者打平。 skill、hook、MCP、memory 这些，双方都有。所以「Claude Code 可编程、Codex 是黑盒」这个说法站不住。
- Codex 的独门是「云端沙箱并行」。 它能
codex_delegate把任务拆出去、丢到云端沙箱并行执行——这适合「一次改几十个文件、跑一堆测试」这种能并行的活。Claude Code 的 subagent 主要是在同机、同账号下做上下文隔离，没有这种「真·云端并行任务」。 - Claude Code 的独门是「本地 + IDE + 企业」深度。 Bridge 接 IDE、权限体系、策略限制、团队同步，这些是它作为「面向企业开发者的一体化工具」的护城河。
💭 思考：为什么「可编程性打平」这个结论比「谁更强」更重要？—— 因为它拆掉了一个伪问题。很多人问「Claude Code 和 Codex 谁更可编程」，但双方都支持 skill/hook/MCP/AGENTS.md/memory，这个问题没有区分度。真正有区分度的，是两者在「同一个 Tool Loop 骨架之外各自长了什么」：Claude Code 长的是本地 IDE 与企业治理（权限、策略、团队同步），Codex 长的是云端沙箱并行与多模型。一旦你把「可编程性」从差异清单里划掉，剩下的差异才是指向选型的：你的任务是知识密集编排还是并行吞吐，决定你选谁——而不是「谁的可编程能力更强」这种永远比不出结果的问法。
五、选型判据
- 本地深度开发、要和 IDE 深度配合、重视权限/企业治理 → Claude Code。
- 大批量、能并行的任务（多文件重构、跑测试矩阵）、想接本地模型省钱 → Codex CLI。
- 纯云端、不想碰本地环境 → 那是 Codex Web，不是 Codex CLI，别混。
总结
回到上一篇的核心：两者都跑在同一个 while Tool Loop 骨架上。差异不在「谁更可编程」，而在这个骨架之外各自长了什么——Claude Code 长了「本地 IDE 与企业治理」，Codex CLI 长了「云端沙箱并行与多模型」。把这三点讲清楚，比背「可编程 vs 黑盒」这种过时的二分法有用得多。
说明：本文的 Claude Code 事实来自恢复的客户端源码镜像，Codex 事实来自
openai/codex的codex-rs源码与官方 README。两者都是独立的工程分析，非官方背书，具体数字（工具数、命令数）随版本变化。
章末提问
追问 1：「Claude Code 可编程、Codex 是黑盒」这个说法错在哪？
结论先行：错在把「Codex Web」的云端黑盒印象张冠李戴到了「Codex CLI」头上——两者的 CLI 都是本地 coding agent，且都支持 Skill、Hook、MCP、AGENTS.md、memory 一整套可编程机制。
因为：Codex 至少对应四个产品（CLI / Web / App / IDE），和 Claude Code 对比的是本地那个 Codex CLI（Rust 写的 codex-rs）。它的 skills/、hooks/、codex-mcp/、mcp-server/、agents_md.rs、memories/ 一个不少。所以「可编程性」两边打平，这不是差异点。
追问 2：两者的执行模型差在哪，为什么 Codex 能并行而 Claude Code 的 subagent 做不到同一种形态？
结论先行：Claude Code 全程本地、subagent 在同机上下文隔离；Codex 能把子任务派到云端沙箱、作为真正的云端并行任务跑（cloud-tasks / codex_delegate）。
因为：Codex 的 codex_delegate 拉起一个子 Codex 线程、强制审批策略为 never，并把执行放进隔离沙箱，所以它能把「一次改几十个文件」拆成多个子任务并行跑、人守在验收端；Claude Code 的 subagent 主要解决同账号下的上下文隔离，没有这种「真·云端并行任务」的形态。这决定了「大批量可并行任务」是 Codex 的主场。
追问 3：怎么选型，本质上是回答什么问题？
结论先行：不是「谁更强」，而是「你的瓶颈在知识密集编排还是在并行吞吐」。
因为：Claude Code 把编排复杂度放在提示词与文件上（声明式，人要写清规则，模型在上下文里自主执行），适合「一堆规则和能力怎么被一个模型正确调用」；Codex 把复杂度放在循环与沙箱上（执行式，系统要跑得稳），适合「并行跑 100 个独立任务」。本地 IDE 深度配合 + 企业权限治理选 Claude Code；大批量并行 + 接本地模型省钱选 Codex CLI；纯云端不碰本地那是 Codex Web，别混。
追问 4：Codex 的 compact（上下文压缩）为什么自己会弹「降低准确度」的警告？
结论先行：因为压缩（Memento 策略）是把旧历史总结成摘要，本质是「有损的止损阀」——省 token 但丢精度，所以它提示「能开新线程就开新线程」。
因为：compact 把旧历史压成带 SUMMARY_PREFIX 的摘要，同时倒序保留最近若干条用户消息，总预算硬控在 20,000 token 内。摘要丢了细节，压缩越多次精度越低，所以它硬编码弹 WarningEvent 提示开新线程。这印证了「循环是免费的，工程是昂贵的」：压缩解决 token 爆炸，但它自己不是免费的。