Codex CLI 与 Claude Code 2026：架构、定价与中国访问

Codex CLI 与 Claude Code 都以终端原生的智能体工具形态发布。到 2026 年年中，两者都通过两层来保障安全：底层是操作系统级沙箱，上层是可编程的治理层。如今真正区分二者的，是侧重点与深度。Codex 以内核沙箱打头阵，hook 系统则保持精简；Claude Code 以同类工具中最丰富的 hook 面打头阵，并在其下补上了操作系统级的沙箱化执行。这种侧重点差异，仍然一路传导到两者处理配置、权限、多智能体工作流与团队治理的方式上。下面的对比会用具体的判断标准梳理这些差异，也是我在本站持续构建的AI 工程版图的延伸。

我的主力工具是 Claude Code。这一偏向先摆在明面上。文中的观察来自在生产任务、盲测评估以及双工具工作流中对两者的日常使用。

TL;DR: Codex 主要在操作系统内核层（Seatbelt、Landlock、seccomp）强制安全约束¹，其上叠加一套仅五个事件的小型 hook 系统（自 CLI v0.124.0 起稳定）。Claude Code 以应用层治理见长，截至 2026 年 8 月提供 31 个可编程的 hook 事件²，并以操作系统级沙箱化的 Bash（Seatbelt/bubblewrap）作为托底；自 v2.1.219 起，还新增了直接拒绝白名单外主机的 strictAllowlist。两款工具都能在大上下文下运行：Claude Code 在 Max、Team Premium、Enterprise 与 API 账号上默认使用 Opus 5，在 Pro 与 Team Standard 上默认使用 Sonnet 5（两者均原生 1M；Sonnet $2/$10、Opus $5/$25 per MTok）²⁰；Codex CLI 默认使用 GPT-5.6 系列（Codex 内默认 272K，配置 model_context_window 后为 872K；GPT-5.6 Sol 享受 $4/$20 per MTok 的促销价，至少持续到 2026 年 11 月 21 日）¹⁹²¹。需要云端沙箱化的任务委派和内核级隔离，用 Codex；需要可编程治理、长周期重构和以安全为重点的代码审查，用 Claude Code。最好的结果，来自两者并用。

要点速览

• 独立开发者： 从与您主力语言生态更契合的那一款开始。两款工具可在同一仓库中共存且互不冲突（CLAUDE.md 与 AGENTS.md 彼此独立）。
• 团队负责人： Codex 的 profile 提供显式、可审计的配置切换；Claude Code 的分层体系会自动套用与上下文相符的规则。取决于团队更偏好显式控制还是自动适应。
• 安全工程师： Codex 的内核沙箱能在操作系统层面阻止智能体绕过限制。Claude Code 的 hook 与智能体共享进程边界，但可以写任意校验逻辑——如今其下还垫了一层操作系统级沙箱化的 Bash。按您的威胁模型来选。

该选哪一款？（按读者画像的决策路径）

对比的答案取决于您是谁。下面按这个页面最常见的几类读者，给出四条路径。

个人或小团队项目的独立开发者

默认选 Claude Code。 Sonnet 5 在 $2/$10 价格下的原生 1M token 上下文、31 个事件的 hook 治理体系，以及插件市场，覆盖了独立开发者每天都会遇到的场景（大型代码库重构、会话连续性、保存时自动格式化）。每月 $20 的 Pro 或每月 $100–200 的 Max，费用可预期且额度充裕。

什么时候引入 Codex CLI： 需要内核级沙箱来做一次性的不可信代码审查时；或者 ChatGPT Pro/Plus 已经覆盖了您主要的 AI 支出，再加一份 Claude 显得重复时。两款工具可以干净地共存，CLAUDE.md 与 AGENTS.md 并排放着即可。

10 至 50 人工程组织的团队负责人

默认选 Claude Code。 可编程的 hook（lint 卡点、安全扫描、禁用命令拦截）以确定性的方式把团队标准固化下来，而不是指望模型乖乖听从提示词。借助托管设置，负责人可以制定全组织范围内、个人开发者无法覆盖的策略。claude agents CLI 与 Agent Teams 原语，与团队在审查工作流中实际采用的模式相吻合。

什么时候引入 Codex CLI： 安全敏感的审查需要内核级硬隔离时（例如审查外部承包商的代码、来自陌生作者的开源 PR）；或者团队已经通过 Azure OpenAI / Microsoft Foundry 深度绑定 OpenAI 工具链时。把它当作用途明确的审查工具来跑，而不是日常主力。

以安全为重点的审查者或红队研究人员

默认选 Codex CLI（应对对抗性输入）+ Claude Code（负责受治理的执行）。 Codex 的内核沙箱借助 macOS Seatbelt / Linux Landlock+seccomp，在应用层之下拒绝系统调用，因此怀有恶意的智能体根本碰不到您未授权的文件系统区域。Claude Code 的 hook 跑在应用层，不过自 2026 年年初起，沙箱化的 Bash 已在其下铺了一层操作系统级的地板（Seatbelt/bubblewrap），v2.1.219 的 strictAllowlist 又进一步收紧了网络策略。按威胁类型选工具。

什么时候引入 Claude Code： 需要对审查后的动作编程时（分诊 hook、审计日志、自动生成报告）。典型工作流是这样的：Codex 在沙箱约束下勘察，Claude Code 承担分诊与策略执行层。

身处中国大陆的开发者

两款工具都能用，但真正左右选择的是连通性与成本，而非功能。决定之前，请先跳到从中国访问 Codex 与 Claude Code。

架构上的核心分野

Codex 与 Claude Code 最深层的差别，在于治理发生在哪一层。Codex 在内核层强制安全约束：macOS 上用 Seatbelt，Linux 上用 Landlock 与 seccomp¹。操作系统在文件系统访问、网络调用、进程派生这些操作抵达应用之前就加以限制。模型无法绕过这些限制，因为操作系统在系统调用执行之前就拒绝了它。

Claude Code 则通过 hook 在应用层强制安全约束。hook 是在生命周期节点上拦截动作的程序，截至 2026 年 8 月共有 31 个节点²。作用于 Bash 的 PreToolUse hook 可以检查每一条命令，用任意逻辑加以校验，并以退出码 2 拦截它。这套 hook 系统带来的是可编程的治理：固化业务规则、跑 linter、扫描凭据。过去的取舍在于，应用层的强制与智能体共享同一个进程边界——但这条界线已经从两个方向被模糊掉了。自 2026 年 1 月的沙箱功能发布以来，Claude Code 就在操作系统级原语（macOS 上的 Seatbelt、Linux 上的 bubblewrap）之上运行沙箱化的 Bash，v2.1.219 又新增了 sandbox.network.strictAllowlist 设置，直接拒绝白名单外的主机。而 Codex 在 v0.124.0 获得了稳定的 hook 系统：在 config.toml 中以 [[hooks]] 块配置的五个事件（SessionStart、UserPromptSubmit、AfterToolUse、AfterAgent、Stop）——但没有 pre-tool 事件，因此不存在像 Claude 的 PreToolUse 那样在工具调用之前触发的钩子。

任何安全架构都在表达力与边界强度之间做取舍。这两款工具从光谱的两端出发，各自向中间靠拢，但侧重点仍是有意为之。当威胁模型中包含可能怀有恶意的智能体时（审查恶意代码、运行不可信脚本），内核沙箱才说得通。当威胁模型是一个过度自信但心怀善意的智能体时（您自己的代码、自己的团队、自己的规范），应用层 hook 才说得通。大多数开发者在不同时刻两种威胁模型都需要。

配置哲学

Codex 用 TOML 做配置，Claude Code 用 JSON。格式上的差别只是表象，哲学上的差别不是。

Codex 围绕 profile 来组织配置：一个个具名预设，用 --profile 显式切换。careful profile 会设置 approval_policy = "untrusted" 并施加更严格的沙箱⁹；deep-review profile 则切到能力更强的模型。因为是按名字选出来的，您始终知道当前生效的是哪套配置。指令层用的是 AGENTS.md，这是 Linux Foundation 旗下 Agentic AI Foundation 的一项开放标准³，Codex、Cursor、Copilot、Amp、Devin Desktop 与 Gemini CLI 都能读取。

Claude Code 围绕分层体系来组织配置：五层依次层叠，从托管设置（优先级最高）到命令行、本地项目、共享项目，再到用户默认值。CLAUDE.md 文件在用户、项目、本地三个级别上生效。Skills、hook 与规则目录又叠加了更多层。与上下文相符的配置会自动套用，但当前生效的配置无法从任何单一文件中看出来，只能靠通读整个层级去重建。

profile 偏向显式与可审计。“当时生效的是哪套配置？”这个问题，看传入了哪个 --profile 标志就能回答。分层体系偏向自动化与上下文敏感：合适的上下文会自动套用，但要回答“现在生效的是哪套配置？”，就得读多达五层并理解它们的合并顺序。这个取舍是真实存在的：我本人就不止一次被用户级 CLAUDE.md 覆盖项目级指令的情况打个措手不及——换成显式 profile 就不会发生。

安全模型对比

规律很清楚：Codex 提供更强的边界、更粗的控制；Claude Code 提供更弱的边界、更细的控制¹¹。孰优孰劣取决于您的威胁模型。要审查不可信的外部代码？内核沙箱。要在可信代码上落实组织的编码规范？可编程 hook。

上下文与模型

更新，2026 年 9 月 3 日。 对下文各段做两处更正、加一项补充；下文一仍 8 月 11 日写就的原样保留，以便留存记录。

第一，Codex 的默认模型。到 8 月 10 日，OpenAI 的 Codex 模型页已把 gpt-5.6-sol 列为默认的 Power 设置，因此本文在 8 月 11 日更新时，“推荐的默认模型是 GPT-5.5”这一说法就已经过时。GPT-5.5 正是被 GPT-5.6 Sol 取代的那一代旗舰。截至 9 月 3 日，同一页面不再点名默认模型：“请从您的账号可用的默认 Power 设置开始。”；而对符合条件的 Pro、Business 与 Enterprise 账号，Astra 的分批放量“会把 Power 选项更新为 Terra Light、Sol Light、Sol Medium、Astra Light、Astra Medium 与 Astra Extra High。”下文描述的工具内上下文不对称，也已经发生变化。GPT-5.6 系列在 Codex 内的默认窗口是 272,000 token（v0.144.6 的发布说明更正了这一数字）；自 8 月 20 日的 v0.149.0 起，model_context_window 设置可以把 Sol、Terra 与 Luna 提升到 872,000，仍不及 Claude Code 的 1M。Codex 0.153.1 中的模型目录同样把 GPT-5.5 在 Codex 内列为 272,000，而不是下文引用的 400K。¹⁹

第二，Claude Code 的默认模型是按套餐区分的，并非单一一个模型。Anthropic 的模型配置文档列出：“Max、Team Premium、Enterprise 与 Anthropic API：默认使用 Opus 5”以及“Pro 与 Team Standard：默认使用 Sonnet 5”。Sonnet 5 的 $2/$10 per MTok，下文写作截至 8 月 31 日的首发优惠价，如今已是标准价；原定的涨价并未发生。²⁰

第三，真正改变这场对比的那个模型。OpenAI 于 9 月 3 日发布 GPT-6 Astra：每百万输入 token $10，缓存输入 $1，输出 $50，上下文窗口 1,050,000 token，最大输出 128,000。长窗口是要加价的：“输入超过 272K token 的提示，整个请求按 2 倍输入与缓存费率、1.5 倍输出计价。”可用性方面，原文为：“GPT-6 Astra 今天面向我们 Trusted Access Program 中的企业开始分批放量，通过 API 以及我们的 Plus、Pro、Business 与 Enterprise 套餐的访问将在未来数日内开放。”同一天的 Codex CLI 0.153.1“新增了通过 API 配置 GPT-6-Astra 的支持，且不改变默认模型，也不在模型选择器中显示它。”Anthropic 在其正式可用产品线顶端的对应者，是 Claude Fable 5.1（9 月 1 日）：$10/$50 per MTok，缓存读取 $0.25，1M 上下文。如今两家厂商都在各自的编码默认模型之上，列出了一款基础费率 $10/$50 的旗舰。9 月 3 日当天，按 Astra 模型页的说法，Trusted Access Program 之外的访问仍未开放；按 Codex 模型页的说法，Astra 的 Power 选项也只覆盖到符合条件的账号。两家都没有把自家旗舰设为编码工具的默认模型。¹⁹²⁰

截至 2026 年 8 月，Codex CLI 推荐的默认模型是 GPT-5.5（2026 年 4 月 23 日发布）⁴：在 Codex 内为 400K 上下文，API 中为 1M，$5/$30 per MTok，Terminal-Bench 2.0 成绩 82.7%——发布时在公开可用模型中处于最高水平。上一代旗舰 GPT-5.4 仍可通过 API 使用，带有 1.05M 的实验性长上下文模式（输入超过 272K 后按 2 倍输入 / 1.5 倍输出计费）⁴，但 Codex v0.145.0（2026 年 7 月 21 日）已将随包的 GPT-5.4 选项迁移到 GPT-5.6 的 Terra 与 Luna 变体（各 272K 上下文）。gpt-5.2-codex 快照已于 2026 年 7 月 23 日下线——固定使用它的脚本现在会失败，OpenAI 推荐的替代是 GPT-5.6 Sol。⁴

Claude Code 自 v2.1.197（2026 年 6 月 30 日）起默认使用 Sonnet 5：原生 1M token 上下文，最大输出 128K，$3/$15 per MTok，并在 2026 年 8 月 31 日之前享受 $2/$10 的首发优惠价⁵。opus 别名自 v2.1.219（2026 年 7 月 24 日）起指向 Opus 5：1M 上下文，最大输出 128K，$5/$25 per MTok，Anthropic 将其定位为相对 Opus 4.8 同价位的能力升级。两家厂商的默认模型与上下文上限都会随版本变动，当前数值请以各厂商页面为准。

如今两款工具都能很好地处理大上下文，只有一处不对称：Claude Code 的默认模型在工具内就是原生 1M，且没有长上下文溢价；而 Codex 把 GPT-5.5 在 Codex 内限制到 400K（完整的 1M 窗口仅限 API）。就单窗口吞下整个 monorepo 而言，目前工具内的优势在 Claude Code 一侧；不过对大多数项目来说，检索质量（各工具找到相关代码的能力）仍比原始窗口大小更要紧。

8 月 11 日的正文到此结束；上文 9 月 3 日的更新取代了它。

公开基准的变化速度，快过任何一篇对比文章。2026 年 4 月的快照中，Opus 4.7 在 SWE-bench Verified（87.6%）与 SWE-bench Pro（64.3%）上领先，而 Terminal-Bench 2.0 由 GPT-5.4（75.1%）与 GPT-5.3-Codex（77.3%）领跑¹²。GPT-5.5 在 4 月 23 日发布时以 82.7% 拿下 Terminal-Bench 2.0，当时在公开可用模型中处于最高水平⁴。此后两家厂商都发布了更新的模型：OpenAI 有 GPT-5.6 Sol 与 GPT-6 Astra，Anthropic 有作为同等成本能力升级的 Opus 4.8（5 月）与 Opus 5（7 月），以及位于它们之上、$10/$50 的 Fable 5.1（9 月 1 日）。¹⁹²⁰ 本文没有为这些更晚的模型给出基准表。请把这里的每一个数字都当成某个时间点的测量值，做决定前先查厂商页面。在我用早期版本 Opus 做的盲测中，即便上下文更小，它在审查与安全任务上依然更胜一筹，到了 1M 这一规律依旧成立。

两款工具都支持模型路由。Codex 按 profile 选择模型⁹；Claude Code 按套餐默认使用 Opus 5 或 Sonnet 5，opus 别名指向 Opus 5，每次调用都可以通过 --model 或设置层面的配置覆盖。

定价深度解析

定价可归为三种模式：按 token 的 API 计费、包含智能体 CLI 用量的订阅，以及通过 AWS / GCP / Azure 的云厂商计费。哪条路最便宜，取决于每天的 token 用量，而不是标价。

Claude Code 定价（2026 年 9 月 3 日核验）

按 token（Anthropic API）：¹³

Sonnet 5 的 $2/$10 在发布时是首发优惠价，如今已成为标准价；原定 9 月 1 日的涨价被取消。Opus 4.8、4.7 与 4.6 作为旧版模型继续以同样的 $5/$25 费率提供。没有长上下文溢价：Opus 5 与 Sonnet 5 的 1M token 窗口按标准费率计价。Batch API 对输入和输出提供 50% 折扣。¹³

包含 Claude Code 的订阅：⁸

云厂商定价遵循 AWS Bedrock / Google Vertex AI / Microsoft Foundry 的目录价，与 Anthropic 直连 API 的价格十分接近，但在区域可用性与数据驻留上有差异。

Codex CLI 定价（2026 年 9 月 4 日核验）

按 token（OpenAI API）：¹⁴

OpenAI 每轮换一次模型变体，价格就会调整。GPT-5.6 Sol、GPT-6 Astra 与 GPT-5.5 三行的费率于 2026 年 9 月 4 日核验；其余各行为截至 2026 年 8 月 8 日的数据。GPT-5.6 Sol 在输入超过 272K 时，整个请求按 $8/$30 计费。

按 OpenAI 的弃用表，gpt-5.2-codex 快照已于 2026 年 7 月 23 日下线；OpenAI 推荐的替代是 GPT-5.6 Sol。⁴ GPT-5.4 上的长上下文提示（输入超过 272K token）在该会话内按 2 倍输入、1.5 倍输出计费，standard、batch、flex 各档位一律如此。⁴

包含 Codex 的订阅：

ChatGPT Plus（每月 $20）、Pro（5x 档位每月 $100 起，20x 每月 $200）与 Business（Codex 专用席位按量付费，或带 Codex 用量上限的标准 ChatGPT Business 席位），都按各自套餐的上限包含 Codex 系列的用量。GPT-5.5、GPT-5.4 与 GPT-5.3-Codex 均可通过 OpenAI API 使用，受支持的 API 档位都有公开的按 token 价格与速率限制（免费档不支持）。¹⁴ 纯 API 的团队可以完全跳过订阅；当随包的 Codex 用量加上更广的聊天界面对团队更划算时，再选 ChatGPT 订阅。

Opus 5 的 1M 上下文实际要花多少钱

现实的问题是：“如果我把一个 1M token 的代码库喂给 Opus 5，账单是多少？”

一次完整上下文的处理，附带 10K token 的回复： - 输入：1,000,000 token × $5.00/MTok = $5.00 - 输出：10,000 token × $25.00/MTok = $0.25 - 合计（无缓存）：每次 $5.25

在这个 1M token 代码库上启用 5 分钟提示缓存（假设写入一次缓存，后续追问反复读取）： - 首次写入：1,000,000 × $6.25/MTok = $6.25（一次性） - 5 分钟内每次后续读取：1,000,000 × $0.50/MTok + 10,000 输出 × $25/MTok = $0.75 - 一次会话读取五次：$6.25 +（5 × $0.75）= 五次完整上下文处理共 $10.00

按 1 美元 ≈ 6.82 元人民币的参考汇率折算（2026 年 4 月前后，人民银行中间价大致集中在 6.82–6.90 区间）：在 1M token 的代码库上跑五次完整上下文的 Opus 5 会话，约合 ¥68.20。 汇率是会动的，用于采购报价前请核对当时的汇率。对做预算而言，重要的是这套算法，而不是那个精确的人民币数字。

在 GPT-5.4 的长上下文模式下做同样的计算（它是上一代旗舰；GPT-5.5 的 1.05M 窗口仅限 API，输入超过 272K 后按 2 倍输入、1.5 倍输出计费，因此同样一次无缓存的完整 1M 处理为 $10.45）： - 输入：1,000,000 token ×（基础 $2.50 × 长上下文倍率 2）= $5.00 - 输出：10,000 token ×（基础 $15.00 × 长上下文倍率 1.5）= $0.225 - 合计（无缓存）：每次 $5.23，与 Opus 5 在完整 1M 上下文下的无缓存价格相差不到 1%

在 GPT-5.3-Codex（输入上限 272K）上，要吞下同样的 1M 代码库至少得分四次，会话层面的成本结构因此改变。多数中国开发团队并不需要每天都用满 1M 上下文，所以现实的比较发生在典型会话规模（50K–200K token）上——在这个区间，两款工具的单次会话成本都低于 $1。

订阅什么时候比按 token 更划算

一个粗略的经验法则（Anthropic 并未公布 token 配额，所以这不是官方数字）：轻量的交互式使用，Pro 绰绰有余；在 Opus 5 上跑较重的日常智能体工作流，就进入了 Max 5x 或 Max 20x 的区间；持续使用完整上下文（每次会话 $5 以上）的负载，配合激进的提示缓存，按 token 付费可能比有上限的订阅更便宜。不要靠公式猜测——用 Pro 跑一个有代表性的星期，看看 Claude 用量面板，再按需升级档位。团队按人头做同样的测算，另外再加上 Enterprise 档位所吸收的管理、策略与 SSO 开销。

从中国访问 Codex 与 Claude Code

按两家厂商各自公布的支持国家/地区清单，OpenAI 与 Anthropic 的第一方 API 访问在中国大陆并未获得官方支持。¹⁸ 有开发者会通过非大陆的网络和账号绕行，但这样做要承担账号封停与合规风险，需要与您所主张的效率收益权衡。CLI 二进制文件一旦下载即可在本地安装运行，日常的智能体循环行为在哪里都一样。真正合规的路径，在云厂商的接入方式上。

AWS Bedrock 的区域可用性

Anthropic 的 Claude 模型通过 Amazon Bedrock 在特定 AWS 区域提供服务。截至 2026 年 4 月，公开的 Bedrock 运行时端点覆盖了包括东京、首尔、新加坡、孟买与悉尼在内的亚太区域，但目前中国大陆或香港没有在运行的 Bedrock 运行时端点。¹⁵ 走 AWS 的中国客户通常选用新加坡或东京，并承担相应的延迟成本。

Google Vertex AI 的区域可用性

Google Cloud 在亚太区域提供 Vertex AI 的生成式 AI 端点。¹⁶ 具体哪些 Claude 模型可用因区域而异，asia-east2（香港）在过去对华南用户的延迟表现更好。在决定之前，请先确认所选 Vertex 区域是否提供目标 Claude 模型；覆盖范围会随时间扩大，但在亚太并不均匀。

Microsoft Foundry

Claude 可通过 Microsoft Foundry 在 Azure 的全球标准部署中使用，通常需要符合条件的 Enterprise / MCA-E 订阅。目前没有公开文档表明 Claude 在 Azure 中国（由世纪互联运营）可用——那是一片独立的主权云，服务目录也不相同。使用 Foundry 的中国客户走的是全球 Azure 版图，而非 Azure 中国。¹⁷

从中国使用 OpenAI Codex

OpenAI 的支持国家/地区清单不包含中国大陆；OpenAI 警告说，从不受支持的地区访问可能导致账号被封或被停用。¹⁸ Azure OpenAI 在特定的全球区域提供（不含 Azure 中国），寻求合规访问的中国企业，通常是在允许的区域通过 Azure OpenAI 并配以适当的合同条款接入，而不是直接调用 OpenAI API。

中国厂商的模型替代方案

DeepSeek、Qwen（阿里巴巴）与 Kimi（月之暗面）是中国团队出于成本与延迟考虑会评估的模型级替代方案。它们是模型，不是智能体 CLI。要与 Claude Code 搭配，需要一个兼容 Anthropic API 的适配器或网关（Claude Code 期待的是 Anthropic 的请求/响应结构，ANTHROPIC_BASE_URL 指向的是 Anthropic 兼容端点，而非 OpenAI 兼容端点）。Codex 支持 profile 级的模型路由，但同样期待 OpenAI 兼容的响应。两款工具都没有把 DeepSeek/Qwen/Kimi 作为一等公民支持；可行的路径是加一层适配器，在厂商的 API 结构与 CLI 所期待的结构之间做翻译。采购、延迟与数据驻留这类问题，这些模型答得很好；而智能体循环的正确性与工具调用的成熟度，仍然是这些 CLI 所针对调优的前沿 Claude 与 GPT 模型更拿手。

多智能体能力

Codex 通过 codex cloud exec 提供云端任务委派⁶，OpenAI 目前仍将这一能力标注为实验性。您描述一项任务，Codex 拉起一个云环境，针对您的代码库运行智能体，然后返回一份 diff。您无法实时观察智能体的推理过程；任务在开头定义好，结果稍后收取。云端委派天然契合 CI/CD 流水线与批处理。至于本地并行，多智能体 v2 体验已在 v0.145.0（2026 年 7 月 21 日）以可选开启的形式趋于稳定，子智能体的模型、推理等级与并发度都可配置⁷。

Claude Code 通过 Task 工具提供显式的子智能体派生¹⁰，这一能力面在 2026 年间扩展显著：自 v2.1.198 起子智能体默认在后台运行，可嵌套派生至第 3 层，截至 v2.1.219 默认最多并发 20 个，再加上动态工作流（/workflows，v2.1.154 及以上）来编排更大规模的机群。父智能体带着具体任务与隔离的上下文派生子智能体，协调结果，再综合输出。子智能体派生带来的是交互式编排：您看得见推理过程，也可以中途介入。再结合多个智能体互相批评彼此输出的审议模式，交互式编排能抓到“发完就不管”的模式会漏掉的问题。

云端任务适合那种任务在开头定义好、结果稍后再取的工作流；子智能体协同适合那种任务在推理中不断演化、需要实时综合的工作流。

信任光谱

在看决策矩阵之前，先想想您的任务落在信任光谱的哪一段。每一项智能体编码任务都隐含着一个信任判断：在这件具体的事情上，您有多信任智能体的判断？

低信任（用 Codex）： 您在审查不是自己写的代码、运行来自外部的脚本，或把工作委派给无法实时监控的云环境。智能体可能遇到对抗性输入。无论模型作何决定，您都希望由操作系统来守住边界。

中等信任（两者皆可）： 您在自己熟悉模式的代码库上作业。智能体可能犯错，但那是过度自信的错，不是恶意。您希望在改动落地前过一遍，但并不需要内核级隔离。

高信任（用 Claude Code）： 您已经通过 hook、CLAUDE.md 指令与白名单权限搭好了护栏。智能体在您设计的受治理环境中运行。您对治理层的信任足以让您有选择地批准动作，而不是一刀切地全面限制。

大多数开发者大部分时间都处在中等信任区间，这正是双工具工作流奏效的原因：沙箱最出彩的低信任任务交给 Codex，可编程 hook 比内核限制更有价值的中高信任任务交给 Claude Code。

决策框架

下面是一份基于具体需求的实用决策矩阵。

没有哪一款工具能通吃这张矩阵。底层规律比这十行所暗示的更简单：需要硬边界时 Codex 更强，需要可编程逻辑时 Claude Code 更强。 如果您在运行不可信代码、审查外部贡献，或委派给无法监控的云环境，硬边界更重要；如果您在落实团队规范、编排多步工作流，或搭建把业务规则固化下来的护栏，可编程逻辑更重要。如果您的需求里有三条以上指向同一款工具，就从那里开始；如果势均力敌，不妨考虑双工具工作流。

我的建议

两个都用。我把同一批代码审查任务在两款工具上各跑了一遍，覆盖 12 个任务类别（记录在我的盲测系列中），结果发现哪一款单独用都不能把问题抓全。举个具体例子：在一次 FastAPI 认证审查中，Opus 指出了密码比较函数里的时序侧信道——比较用的是 Python 的 == 运算符而不是 hmac.compare_digest()，从而制造出一个时序预言机¹¹。Codex 完全漏掉了这个问题。在同一个代码库上，Codex 的沙箱抓到了一个 URL 拉取端点中的 SSRF 向量：用户提供的 URL 可以触达内部服务。Opus 之所以放行了那个端点，是因为在应用层看输入校验是对的；而内核沙箱标记出了那次指向内网 IP 段的出站网络请求。用不同数据训练出的不同模型，抓到的漏洞类型也不同。两个都跑，每次审查的成本大约翻倍，但在安全敏感的代码上确实能多抓到有意义的问题。

我的日常工作流按任务类型划分：

• Claude Code 负责功能实现、代码审查与多文件重构。hook 强制格式化、拦截危险命令，并在每次编辑后跑测试。交互式的子智能体模式，很适合那些在推理中不断演化的任务。
• Codex 负责用 --sandbox read-only 做不可信代码审查（外部 PR 与依赖我都放在内核沙箱里看）、通过 codex cloud exec 做云端委派的批处理任务，以及提供架构上的第二意见——换一个模型的视角，常能照见盲区。

CLAUDE.md 与 AGENTS.md 在同一个仓库里共存且互不冲突。维护成本很低，因为两个文件的大部分内容是相同的：我维护一段共用的规范章节，再复制进两处。

什么时候两款都不该用。 当您需要确定性保证时，Codex 与 Claude Code 都不是正确选择。两者都是概率性的：同一条提示词在不同运行中可能给出不同结果。如果您的工作流要求严格可复现（例如生成必须与 schema 逐字节一致的配置文件），请改用模板引擎或代码生成器。智能体工具在任务需要判断力时最强，在任务需要不含判断的精确性时最弱。

完整对比、盲测方法论以及 12 个任务类别的结果，见 Claude Code 与 Codex：何时用哪一个。想分别上手，请看 Claude Code 指南或 Codex 指南。想了解支撑 Claude Code 治理层的 hook 系统的实操走查，请看 hook 教程。

参考资料

常见问题

我能在同一个项目里同时用 Codex 和 Claude Code 吗？

可以。CLAUDE.md 与 AGENTS.md 是两个独立文件，各自的工具独立读取，谁也不会解析对方的指令文件，配置文件也不冲突。我在每个在跑的项目里都同时维护这两份。唯一需要留意的是让两份指令文件之间的共用内容保持同步，由于格式相近，几分钟就能搞定。

日常使用哪个更便宜？

请看上文的定价深度解析一节。简版是：Claude Code 有 Anthropic API 的按 token 定价（Sonnet 5 为 $2/$10，发布时是首发优惠价，如今已成为标准价；Opus 5 为 $5/$25），外加一整套订阅阶梯（Pro $20、Max 5x $100、Max 20x $200、Team $30/人、Team Premium $150/人）。Codex CLI 有 OpenAI API 的按 token 定价（GPT-5.6 Sol 为输入 $4 / 输出 $20 per MTok，属促销价，至少持续到 2026 年 11 月 21 日；GPT-5.5 为 $5 / $30），以及 GPT-5.4 / GPT-5.3-Codex 系列，外加 ChatGPT Plus/Pro 的包含额度。token 效率随任务类型而变；预算敏感的工作，建议拿一个有代表性的任务在两边各跑一次，比较实际扣费。两家厂商的按 token 价格不同，所以原始 token 数并不能直接换算成成本。

哪个更擅长处理大型代码库？

两者都能很好地处理大仓库。Claude Code 的默认模型（按套餐为 Opus 5 或 Sonnet 5）按标准价即为原生 1M token。Codex 的 GPT-5.6 默认系列在 Codex 内默认跑 272K，配置 model_context_window 后为 872K；而 1.05M 的窗口（GPT-5.6 Sol、GPT-6 Astra 与 GPT-5.5 皆然，输入一旦超过 272K，都按 2 倍输入、1.5 倍输出计费）在 API 一侧，详见上下文与模型一节中 9 月 3 日的更新。两款工具都不会一次性读完您的整个代码库，日常作业都依赖检索（Claude Code 用代码库搜索加分层 CLAUDE.md 预置上下文；Codex 用搜索驱动的文件发现）。原始窗口大小最要紧的场景，是在单轮之内推理跨多个文件的关系——在这一点上，目前 Claude Code 工具内的窗口更大。

Codex CLI 是在本地运行还是在云端运行？

两者都有，但模式不同。Codex CLI 默认在本地运行，与任何终端工具无异。¹ 云端委派是另一条通路，经由 codex cloud exec 或 Codex Cloud，在 OpenAI 托管的基础设施的容器中运行您的任务并返回一份 diff。人们说“Codex 沙箱”时，通常指的就是 Codex Cloud；而 Codex CLI 的本地沙箱，是上文安全模型一节里描述的内核级 Seatbelt / Landlock 路径。

我能从中国大陆访问 Claude Code 与 Codex 吗？

OpenAI 与 Anthropic 的第一方 API 访问在中国大陆并未获得官方支持。CLI 二进制文件可以在本地安装运行，但从中国大陆把流量导向第一方 API，可能带来账号封停或合规问题。合规的路径包括：Azure OpenAI（特定的非中国区域）、AWS Bedrock（最近的公开亚太区域，包括东京、首尔、新加坡、孟买与悉尼；没有中国大陆或香港的运行时端点）、Google Vertex AI（asia-east2 香港及其他亚太区域，注意各模型可用性的差别），以及面向 Claude 的、部署在全球 Azure 上的 Microsoft Foundry（不是 Azure 中国）。细节请看上文的从中国访问 Codex 与 Claude Code。

中文注释或代码会怎样影响 token 用量？

汉字的分词方式与英文不同。Claude 的分词器把多数汉字各算作一个 token，这意味着按行来看，中文源代码往往比等价的英文更省 token，但按字符来看效率更低（一个 token 只覆盖一个字，而不是一个 4 到 6 个字母的英文单词）。Codex（GPT 系列）采用类似的做法。实际效果是：内容等价的注释或 docstring，两种语言的 token 数大致相当，而每个 token 的表现更多由代码结构决定，而非自然语言的占比。

我能让 Claude Code 或 Codex CLI 用 DeepSeek、Qwen 或 Kimi 作为后端模型吗？

只能通过适配器或网关。Claude Code 期待 Anthropic API 的请求/响应结构（ANTHROPIC_BASE_URL 指向 Anthropic 兼容端点），Codex 期待 OpenAI 的结构。DeepSeek / Qwen / Kimi 都有各自的 API，需要先做转换，Claude Code 或 Codex CLI 的会话才能驱动它们。社区的适配器项目是有的，但并非一等支持；而且各家在工具调用与提示缓存上的“方言”差异足够大，多轮智能体循环经常会断。若通过独立的 shell 外壳做一次性代码生成，或在各自的价位上做单文件审查，DeepSeek / Qwen / Kimi 是可信的选项。完整的智能体循环正确性与工具调用可靠性，仍然来自这些 CLI 所针对调优的前沿 Claude 与 GPT 模型。

Codex CLI 与 ChatGPT 里的 Codex 功能有什么区别？

Codex CLI 是 github.com/openai/codex 上的终端工具。ChatGPT 里的“Codex”指的是同一模型系列，通过 ChatGPT 的网页/桌面/移动应用以不同的界面形态呈现（云端任务委派、异步结果、与 ChatGPT 历史记录打通）。CLI 与 ChatGPT 共用底层模型，差别在工作流与上下文管理。如果您的问题是“我该在笔记本上装哪个？”，那说的就是 Codex CLI。

使用 Codex CLI 需要 ChatGPT 订阅吗？

不需要，不过订阅有助于控制成本。Codex CLI 可以用一把独立的、按 token 计费的 OpenAI API key 工作。ChatGPT Plus 或 Pro 会捆绑一部分 Codex 用量（上限请查阅当前的 ChatGPT 订阅页面）。¹⁴ 对中国开发者而言，用 OpenAI 账号直接按 API 计费，通常比让 ChatGPT 订阅走中国大陆支付渠道更省事。

Claude Code 的 hook 到底有多少个？

按 2026 年 8 月的官方 hook 参考文档，是 31 个生命周期事件。² 这个数字一直在稳步增长，这也正是过时引用不断堆积的原因：早前的文章会写 17 个或 26 个，取决于它们是在什么时候定稿的。2026 年间新增的包括 PostToolUseFailure、SubagentStart、TeammateIdle、TaskCompleted、PermissionRequest、PermissionDenied、PreCompact / PostCompact、Elicitation / ElicitationResult、StopFailure、TaskCreated、CwdChanged、FileChanged、InstructionsLoaded、ConfigChange、WorktreeCreate / WorktreeRemove、Setup，以及最近的 DirectoryAdded（v2.1.219，2026 年 7 月）。

Opus 4.7 是什么时候发布的，它如何改变这场对比？

2026 年 4 月 16 日。这是 Anthropic 在 Glasswing 之后首个正式发布的 Opus 版本，带着明确的网络安全防护措施出厂，并把 Claude Code 以标准价推到 1M token，同时以 87.6% 在 SWE-bench Verified 上领先。此后阵容又变动了两次：Opus 4.8（2026 年 5 月），随后是同为 $5/$25 的 Opus 5（2026 年 7 月 24 日）；而 Sonnet 5（6 月 30 日，原生 1M，$2/$10 首发优惠价）成了 Claude Code 的默认模型。OpenAI 那边，GPT-5.5（4 月 23 日）以 82.7% 拿下了 Terminal-Bench 2.0 的最高水平。基准领先地位是流动的，任何单一结果都应当当作某个时间点的测量值。当前全貌见上文的上下文与模型一节。