Claude Code vs Codex：终端 AI 编程代理怎么选
从一个真实的选型问题说起
上个月我在给团队做 AI 编程工具落地评估时，遇到了一个典型的分歧：前端同事坚持用 Claude Code，说它在多文件重构时上下文理解明显更好；后端同事则推荐 Codex，理由是沙箱安全、跑云任务省心，而且同价位下可用的 token 更多。两个人都在自己的场景里跑出了好结果，但谁也无法说服对方「统一用一个就行」。
这个问题的根源不在于哪个工具更好，而在于终端 AI 编程代理的选型根本不是「模型排行榜」问题。Blake Crosley 在 2026 年 3 月的一篇对比文章中总结得准确：「Codex provides stronger boundaries with coarser control. Claude Code provides weaker boundaries with finer control.」两者在架构哲学上走了不同的路——一个赌 OS 内核级沙箱足够硬，一个赌应用层 26 个生命周期钩子足够灵活。选错了不是因为工具差，是因为拿它去干了它不擅长的事。
这篇文章把我这两周做的对比测试整理出来，覆盖上下文管理、工具生态、权限模型、团队协作和验证闭环五个维度，每个维度都有翻车记录、代码对比和可执行的评估清单。
架构差异：应用层治理 vs 内核级隔离
理解这两个工具的差异，需要先搞清楚它们各自的「治理层」放在哪里。
Claude Code 把治理逻辑放在应用层。它定义了 26 个生命周期钩子事件（截至 v2.1.116），从 SessionStart 到 PreToolUse、PostToolUse、Stop、SubagentStart、TaskCompleted，覆盖了 Agent 在一次会话中可能经历的几乎所有节点。每个钩子可以是一段 shell 脚本、一个 HTTP 请求，或者一段调用 Claude 模型做判断的 prompt。钩子脚本拿到的是 JSON 格式的上下文输入，通过退出码控制行为——退出码 0 放行，退出码 2 拦截并附带错误信息。
这种设计的优势是表达力极强。我可以在 PreToolUse 钩子里写一个 Python 脚本，扫描即将执行的 bash 命令里是否包含 rm -rf、DROP TABLE、硬编码密钥等模式，不符合规则直接阻断。也能在 PostToolUse 钩子里强制跑 Biome 格式化和 typecheck，确保 Agent 每次编辑后代码都保持可编译状态。
Codex 把治理逻辑下沉到操作系统内核。macOS 上用 Seatbelt 框架（通过 sandbox-exec 调用），Linux 上用 Landlock + seccomp（配合 bubblewrap），Windows 上用原生 PowerShell 沙箱。三种模式：read-only 只读，workspace-write 默认允许写项目目录，danger-full-access 完全放开。网络默认关闭，所有出站请求都需要显式授权。
# ❌ 错误做法：直接放开 full-access 图省事
# config.toml
[sandbox]
mode = "danger-full-access"
approval_policy = "never"
# 这让 Codex 可以执行任何命令、访问任何文件、发起任何网络请求
# 等同于没有沙箱
# ✅ 正确做法：workspace-write + on-request 审批
# config.toml
[sandbox]
mode = "workspace-write"
approval_policy = "on-request"
reviewer = "user"
writable_roots = ["./"]
# 只允许写项目目录，跨边界操作需要人工审批两种架构的权衡可以这样理解：内核沙箱更适合威胁模型包含「Agent 可能被对抗性输入误导」的场景，因为 OS 级别的 syscall 拦截不依赖 Agent 的自律。应用层钩子更适合威胁模型是「Agent 出于好意但过度自信」的场景，因为钩子可以编码团队特定的业务规则——比如「禁止在生产配置文件中写入测试域名」「所有 API 路由文件必须包含 rate limit 中间件」。
// ❌ 错误做法：只用 allow/deny 列表，不区分命令参数
{
"permissions": {
"allow": ["Bash"],
"deny": []
}
// 这意味着 Claude Code 可以执行任何 bash 命令
}
// ✅ 正确做法：用 PreToolUse 钩子做细粒度命令审查
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": "python3 .claude/hooks/audit-bash.py"
}
]
}
// audit-bash.py 可以解析命令 AST，
// 区分 git commit（放行）和 rm -rf /（拦截）
}| 对比维度 | Claude Code | Codex |
|---|---|---|
| 治理层级 | 应用层（26 个生命周期钩子） | OS 内核层（Seatbelt / Landlock / seccomp） |
| 配置格式 | JSON（五层优先级层级） | TOML（命名 profile 显式切换） |
| 指令文件 | CLAUDE.md（层级继承，支持 @path 导入） | AGENTS.md（Linux 基金会开放标准，跨工具可移植） |
| 可编程性 | 高——任意 shell/Python 脚本 | 低——二元允许/拒绝 |
| 确定性 | 依赖钩子脚本正确性 | OS 拒绝越权 syscall |
| 适合场景 | 团队规则复杂、需要编码业务约束 | 威胁模型含对抗性输入、需要 OS 级隔离 |
案例一：上下文管理——大仓重构时谁先迷路
我用的测试任务是在一个 pnpm monorepo 里给 API 层加一个统一的错误处理中间件。仓库有 4 个 app、12 个 package，约 180 个 TypeScript 文件。
Claude Code 的表现
Claude Code 读完 CLAUDE.md 后，先输出了一份计划：列出需要修改的文件、分析现有错误处理模式、确认中间件应该放在 packages/api-core/ 而不是各个 app 里（因为 CLAUDE.md 明确写了「跨 app 共享逻辑放 packages/」）。它用了 1M token 的上下文窗口，一次加载了整个仓库的核心结构。修改完成后主动跑了 pnpm typecheck 和 pnpm test，发现两个测试因为 mock 数据格式不匹配而失败，自行修复。
整个过程消耗约 192,000 token，API 成本约 $2.50。
Codex 的表现
Codex 的默认上下文窗口是 272K token，对 180 个文件的仓库来说需要依赖 embedding-based 文件检索。它找到了需要修改的主要文件，但漏掉了 packages/api-core/src/middleware/ 下已有的两个中间件，把新中间件直接放在了 apps/main-api/src/middleware/ 里——违反了项目的目录约定。测试跑了 typecheck 没报错（因为类型确实兼容），但 CI 后来报了一个 lint 规则违反：中间件注册顺序不对。
Codex 消耗约 136,000 token，API 成本约 $2.04。
差异分析
Composio 在 2026 年 4 月做过一组控制变量测试（相同 prompt、相同机器、相同 MCP 配置），发现 Claude Code 和 Codex 之间存在 1.4 倍的 token 消耗差距和 23% 的成本差距。但关键不在于谁更便宜，而在于多出来的 token 花在了哪里。Claude Code「读更多文件、写之前先做计划、调用工具前先验证」，这些额外 token 在那次测试中换来了「一个更解耦的架构（12 个组件 vs 7 个）、一个未经请求的冒烟测试，以及一个在 Codex 返回空结果的任务上成功运行的结果」。
// ❌ Codex 的做法：直接放在 app 层，忽略了 packages 已有中间件体系
// apps/main-api/src/middleware/error-handler.ts
export function errorHandler(err: Error, req: Request, res: Response) {
res.status(500).json({ message: err.message })
// 没有区分 AppError 和 UnexpectedError
// 没有记录结构化日志
// 其他 app 无法复用
}
// ✅ Claude Code 的做法：放在 packages 层，遵循 CLAUDE.md 约定
// packages/api-core/src/middleware/error-handler.ts
import { AppError, isAppError } from '../errors'
import { logger } from '../logger'
export function errorHandler(err: Error, req: Request, res: Response) {
if (isAppError(err)) {
logger.warn('业务错误', { code: err.code, path: req.path })
res.status(err.statusCode).json({ code: err.code, message: err.message })
return
}
// 未预期错误走结构化日志 + 500
logger.error('未预期错误', { error: err.message, stack: err.stack })
res.status(500).json({ code: 'INTERNAL_ERROR', message: '服务内部错误' })
}| 对比维度 | Claude Code | Codex |
|---|---|---|
| 默认上下文窗口 | 1M token（标准价格，无长上下文溢价） | 272K token（长上下文模式可达 1.05M，2x 输入价格） |
| 文件发现策略 | 层级 CLAUDE.md 前置上下文 + 代码搜索 | Embedding-based 文件检索 |
| 仓库结构感知 | 高——先读 CLAUDE.md 理解目录约定 | 中——依赖检索质量，可能漏掉约定 |
| 同任务 token 消耗 | ~192K（$2.50） | ~136K（$2.04） |
| 首次正确率 | ~95%+（多文件架构任务） | ~90%（多文件架构任务） |
案例二：权限模型——让 Agent 审查外部 PR 时谁更安全
我拿一个来自社区的开源 PR 做测试——一个 FastAPI 项目，PR 修改了认证模块和文件上传接口。我想让 AI 审查这个 PR 是否有安全漏洞，同时确保它不会在审查过程中意外修改代码。
Codex 的做法
# 用只读沙箱启动 Codex，审查外部 PR
codex --sandbox read-only "审查这个 PR 的安全问题，关注认证和文件上传"Codex 在只读沙箱中运行，OS 内核直接禁止了所有文件系统写操作。它发现了一个 SSRF 向量——文件上传接口允许用户传入 URL，服务端直接 fetch 而没有做域名白名单校验。这个发现是准确的。
Claude Code 的做法
Claude Code 没有内核级只读模式，但我用钩子实现了等效保护：
// .claude/settings.json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write|Bash",
"command": "echo '{\"decision\": \"block\", \"reason\": \"审查模式：禁止修改文件\"}' && exit 2"
}
]
}
}Claude Code 在这个配置下无法编辑文件或执行 bash 命令，只能读取代码和输出分析结果。它发现了一个时序侧信道漏洞——密码比较使用了 == 运算符而不是 hmac.compare_digest()。这个漏洞 Codex 没有发现。
为什么会互补
Blake Crosley 在文章里总结得好：「Different models trained on different data catch different vulnerability classes.」两个模型在训练数据上的差异导致它们对不同类别的安全问题敏感度不同。Codex 的 SSRF 发现和 Claude Code 的时序侧信道发现都是真实漏洞，但各自漏掉了对方找到的那个。
在安全审查场景中，最稳妥的做法是两个工具都跑一遍，取并集。
# ❌ Codex 和 Claude Code 都漏掉了一半漏洞
# 只跑一个工具的审查结果不完整
# ✅ 两个工具并行审查，取并集
# review.sh
#!/bin/bash
codex --sandbox read-only "review auth PR for security issues" > codex-review.md &
claude --print "review auth PR for security issues" > claude-review.md &
wait
# 合并两份报告，去重后按严重度排序
python3 merge-reviews.py codex-review.md claude-review.md > final-review.md| 对比维度 | Claude Code | Codex |
|---|---|---|
| 只读保护机制 | 应用层钩子拦截（exit 2 阻断） | OS 内核 Seatbelt/Landlock 直接拒绝 syscall |
| 逃逸阻力 | 中——钩子和 Agent 共享进程边界 | 高——OS 在应用之前拒绝越权调用 |
| 已知漏洞类 | 项目配置中的恶意钩子（通过 trust prompt 缓解） | 沙箱逃逸（截至 2026 年 3 月无公开 CVE） |
| 审查任务表现 | 时序侧信道、业务逻辑漏洞 | SSRF、注入类漏洞 |
案例三：团队协作——CI 失败后谁能让 PR 保持干净
最后一个案例来自日常工作最高频的场景：PR 开了，CI 红了，Agent 能不能帮忙修。
我用一个真实的 typecheck 失败做测试——一个同事在 PR 里改了接口签名但没更新调用方，导致 14 个文件编译报错。
Claude Code 修复了全部 14 个文件，跑完 typecheck 确认通过后提交了 commit。它还额外跑了 pnpm test 确认没有测试被破坏。
Codex 修复了 11 个文件，typecheck 后仍有 3 个文件报错——它漏掉了一个间接调用链（A 调用 B，B 调用 C，C 用了被改的接口签名）。这 3 个文件需要人工补修。
Codex 在 Terminal-Bench 2.0 上得分 77.3%（GPT-5.3-Codex），高于 Claude Code 的 69.4%（Opus 4.7）。但在 SWE-bench Verified 上，Claude Code 得分 87.6%（Opus 4.7），高于 Codex 的约 80%。这两个基准测试的分数差异恰好反映了两者的特点：Codex 擅长终端任务（快速定位、执行命令），Claude Code 擅长软件工程任务（理解类型依赖链、跨文件一致性）。
// ❌ Codex 的修复：只改了直接调用方，漏掉间接依赖
// 修改了 B.ts 中对 changedFunction 的调用
// 漏掉了 C.ts——C 通过 B 间接使用了 changedFunction
// typecheck 仍然报 3 个错误
// ✅ Claude Code 的修复：沿着类型依赖链找到所有调用方
// 修改了 B.ts（直接调用方）
// 修改了 C.ts（通过 B 间接调用）
// 修改了 D.ts（通过 C → B 间接调用）
// ... 共 14 个文件
// typecheck 0 errors工具生态与可扩展性
两个工具都在向平台化演进，但扩展路径不同。
Claude Code 的扩展体系由四个层次组成：Hooks（生命周期拦截）、Skills（SKILL.md 定义的可复用指令集）、Subagents（.claude/agents/ 目录下定义的子代理，各有独立的工具白名单）、Plugins（2026 年 5 月上线的市场 + 本地加载）。其中 Dynamic Workflows 可以在单次会话中编排「数十到上百个子代理」，适合大规模代码迁移和并行审查任务。
Codex 的扩展体系围绕 AGENTS.md 开放标准和 Cloud 任务构建。AGENTS.md 已经纳入 Linux 基金会 Agentic AI Foundation，被 Codex、Cursor、Copilot、Amp、Windsurf、Gemini CLI 等工具共同遵守。Codex Cloud 支持 fire-and-forget 模式——提交任务描述后 Agent 在云端沙箱中执行，完成后返回 diff，最多支持 6 个并发线程。原生集成了 Linear、GitHub、Slack。
// Claude Code Subagent 定义示例
// .claude/agents/test-runner.json
{
"name": "test-runner",
"description": "专门跑测试并分析失败的子代理",
"tools": ["Bash", "Read"],
"instructions": "运行测试命令，分析失败原因，按错误类型分类输出"
}
// 在主会话中调用
// claude agents spawn test-runner "pnpm test --filter @app/api"# Codex Cloud 任务提交示例
# codex cloud exec --task "修复 typecheck 错误并提交" \
# --repo ./my-project \
# --profile ci-fix
# 任务在云端沙箱中执行，完成后返回 diff
# 无法实时查看 Agent 推理过程
# 最多 6 个并发线程| 扩展能力 | Claude Code | Codex |
|---|---|---|
| 子代理 | 有，.claude/agents/ 定义，工具白名单隔离 | 无原生对等物，Cloud 任务替代 |
| 生命周期钩子 | 26 个事件，任意代码 | 无对等物 |
| Skills | SKILL.md 渐进式指令集 | 无对等物 |
| Plugins | 市场 + 本地加载 | 无对等物 |
| 开放标准 | CLAUDE.md 私有 | AGENTS.md（Linux 基金会，跨 6+ 工具） |
| Cloud 任务 | Routines（cron/GitHub 触发） | Codex Cloud（fire-and-forget） |
| 原生集成 | MCP 生态（Firecrawl, Sentry, Playwright 等） | Linear, GitHub, Slack 原生 |
| 并发上限 | 子代理协调，无硬上限 | 6 个并发线程 |
定价与成本模型
定价是选型中绕不开的现实问题。两个工具在订阅层面看似对齐，实际可用量差距不小。
| 订阅档位 | Claude Code | Codex |
|---|---|---|
| $20/月 | Pro（每日有限额度，持续重度使用会触发限制） | Plus（15-80 条 GPT-5.5 消息/5 小时窗口 + 10-60 个云端任务） |
| $100/月 | Max 5x（Pro 的 5 倍额度） | Pro 5x（临时提升至 10x，至 2026 年 5 月底） |
| $200/月 | Max 20x（Pro 的 20 倍额度） | Pro 20x（5 小时窗口内 25x Plus 额度） |
| API 按量 | Anthropic API（Opus 4.7: $5/$25 per MTok 输入/输出） | OpenAI API（GPT-5.4: $2.50/$15 per MTok 输入/输出） |
| 团队版 | Team Standard $30/人/月，Team Premium $150/人/月 | Business 按量付费 |
API 层面的价格差更明显：Opus 4.7 的输入价格是 GPT-5.4 的 2 倍，输出价格是 1.67 倍。但实际成本还要看 token 消耗量。Composio 的测试显示，同一个任务 Claude Code 消耗 192K token（$2.50），Codex 消耗 136K token（$2.04），实际成本差距约 23%——小于「凭感觉以为的 5-10 倍」。
一个需要注意的陷阱：Codex 的滚动 5 小时窗口机制。多位用户报告过「额度在没有通知的情况下被调整」。Claude Code 的 Pro 计划也有类似的日用量门控，但触发频率更低。
基准测试分数怎么看
基准测试是选型的参考之一，但不能只看一个分数。
| 基准测试 | Claude Code（Opus 4.7） | Codex（GPT-5.4 / GPT-5.3-Codex） |
|---|---|---|
| SWE-bench Verified | 87.6% | ~80%（第三方，OpenAI 未发布） |
| SWE-bench Pro | 64.3% | 57.7% / 56.8% |
| Terminal-Bench 2.0 | 69.4% | 75.1% / 77.3% |
| CursorBench | 70% | — |
| OSWorld Verified | 72.7% | 64.7% |
规律很明显：在需要理解复杂代码依赖、跨文件一致性、安全审查的任务上（SWE-bench、SWE-bench Pro、OSWorld），Claude Code 领先。在终端操作、命令执行、快速定位的任务上（Terminal-Bench 2.0），Codex 领先。两个模型在基准测试上各有胜负，没有绝对的全面领先。
Firecrawl 文章的总结比较中肯：「Claude Code has the deepest harness and fastest terminal. Codex covers more surfaces at a lower price.」
选型评估清单
以下清单按阶段分组，供团队落地评估时逐项检查。
阶段一：环境准备
- 确认仓库规模是否在工具支持的上下文窗口内
- 准备项目指令文件（CLAUDE.md 或 AGENTS.md），包含目录约定、代码风格、测试要求
- 确认 CI 系统是否支持 Agent 提交 commit 后触发验证
- 评估团队安全策略：是否需要内核级沙箱？应用层钩子是否满足审计要求？
阶段二：任务集设计
- 准备 5 类真实任务：修复已知 bug、新增小功能、分析测试失败、更新技术文档、Review diff
- 每个任务定义明确的输入、观察指标和验收方式
- 不要用「写一个 Todo 应用」做评估——它不能反映真实工程复杂度
阶段三：执行对比
- 同一个任务在两个工具上分别执行，记录 token 消耗和 API 成本
- 记录首次正确率（不需要人工修改即可通过验证的比例）
- 记录返工次数（Agent 自行修复失败的次数 vs 需要人工介入的次数）
- 记录验证证据（Agent 是否主动跑了 typecheck/test/lint，是否附上了输出截图或日志）
阶段四：打分与决策
- 按六个维度打分（1-5 分）：上下文命中、边界遵守、工具使用、失败处理、交付说明、接管成本
- 对比总分，但不唯总分——某些团队更看重权限审计，某些更看重上下文深度
- 如果预算允许，评估混合使用方案：Claude Code 做交互式 pair programming 和前端任务，Codex 做云端自治任务和 PR 审查
阶段五：持续优化
- 定期（建议每月）用新的真实任务重新评估，模型更新后分数可能变化
- 维护项目指令文件，随项目演进更新 CLAUDE.md / AGENTS.md
- 积累钩子和 skill 资产，逐步把团队规则编码为可复用的自动化
混合使用策略
实际落地中，多数重度用户两个工具都在用。Blake Crosley 的建议比较有代表性：Claude Code 用于交互式 pair programming、前端任务、多文件重构和需要实时推理的场景；Codex 用于审查不可信代码（--sandbox read-only）、云端自治任务（24 小时以上长时间运行）和架构二次审查。
两个工具都支持 MCP（Model Context Protocol），意味着为其中一个编写的 MCP 服务器可以直接在另一个上使用。这是混合使用的基础——工具层不需要维护两套。
混合使用时最容易踩的坑是项目指令文件不统一。如果 Claude Code 读 CLAUDE.md、Codex 读 AGENTS.md，两份文件内容不一致，Agent 的行为就会打架。建议把项目级约束放在仓库根目录的文档中，两个 Agent 各自引用同一份核心规则。
采购前必须回答的问题
在团队推广或采购之前，以下五个问题的答案比模型榜单更接近真实采用成本：
- 仓库规模适配：工具是否支持当前仓库的文件数和代码量？上下文窗口是否够用？
- 流程接入：能否接入现有 CI、Issue 追踪、文档系统和 Review 流程？
- 安全合规：权限和审计是否满足公司安全要求？是否需要内核级沙箱？
- 失败恢复：Agent 出错时人能否快速接管？交付物是否包含足够的上下文让人继续？
- 维护成本：团队是否愿意投入时间维护 Agent 规则、钩子和 skill 资产？
工具选择不是一个「选最好的」问题，而是一个「选最适合团队任务类型和安全约束」的问题。Claude Code 和 Codex 都在快速迭代，今天的短板可能在下个版本就补齐了。保持评估机制比保持某个工具选择更重要。
参考资料
- Codex CLI vs Claude Code 2026: Architecture, Pricing, and China — Blake Crosley
- Claude Code vs Codex CLI: 2026 Comparison — Termdock
- Claude Code vs Codex: Which AI Coding Agent Should You Use — Firecrawl
- Automate actions with hooks — Claude Code Official Docs
- Sandbox — Codex Official Docs
- Codex vs Claude Code (June 2026) — MorphLLM
- Claude Code vs Codex vs Gemini CLI: Feature Comparison — IntuitionLabs
- Claude Code vs Codex CLI vs Gemini CLI 2026 Comparison — DeployHQ