OpenAI Codex 幕后工作原理（及与 Claude Code 的对比）

作者：Jared Zoneraich[1]
日期：2025年9月17日

OpenAI Codex 幕后工作原理（及与 Claude Code 的对比）

最近，越来越多人从 Claude Code[2] 转向 OpenAI Codex[3]。我暂时无法判定哪款工具更优（我两款都在用），但二者的差异不只是模型本身——它们的底层构建逻辑完全不同。理解 Codex 采用的智能体架构，不仅能帮我们明确其适用场景，还能为智能体开发提供参考。

本文将深入解析 Codex CLI 的底层运作机制，包括其核心循环、工具体系、安全机制及上下文处理方式，并与 Anthropic 的 Claude Code 进行逐项对比，帮助你判断哪款工具更适配自己的工作流程。

若想了解 Claude Code 的底层逻辑，可参考我的上一篇文章：Claude Code 核心智能体循环的幕后原理[4]。

一、核心智能体循环（Codex CLI 内部机制）

Codex CLI 的核心是基于 「单智能体 ReAct 模式循环」 构建的，该循环通过 AgentLoop.run()[5] 函数实现。这种“思考→调用工具→观察结果→重复”的设计模式，会持续运行直到模型生成无需额外工具调用的最终答案。

该循环借助 OpenAI 的 Responses API 实现流式传输功能，支持函数/工具调用及可选的“推理”项。典型交互流程如下：

用户输入提示（例如“重构 utils. ts 文件，改用箭头函数”）；
CLI 构建包含详细系统前缀的对话上下文；
向 OpenAI 的 GPT-5 系列模型发送请求；
模型流式返回响应，可能包含工具调用请求；
CLI 执行请求的工具，并将结果反馈给模型；
重复上述过程，直至任务完成。

（图示：Codex 的核心循环）

其中，系统提示的设计尤为关键——它是一段内容详尽的提示文本，明确了智能体的角色定位与能力范围，相当于给模型“讲解”一套迷你 API，详细说明工具调用方式与输出格式。例如，提示中会明确：

使用 apply_patch 命令编辑文件：

{
  “cmd” : [
    “apply_patch”,
    “ 开始补丁\n 更新文件：path/to/file…*** 结束补丁”
  ]
}

这种单线程设计确保了流程的简洁性与可调试性：同一时间仅一个智能体进行推理，对话历史以扁平消息列表的形式逐次累积。值得注意的是，Claude Code[6] 也采用了极为相似的单循环设计，通过避免多智能体并发的复杂性，保证了执行路径的清晰性。

完整的系统提示属于私有内容，但目前已有部分信息泄露[7]。

（图示：OpenAI 新模型 gpt-5-codex 的提示泄露内容）

从泄露信息中可发现，Codex 的运行模式在提示中被明确编码：采用单智能体 ReAct 循环，工具调用规则严格，且带有“持续工作直至完成”的倾向。提示中还包含一套“以 Shell 为核心”的工具集（通过 cat 读取文件、grep/find 搜索内容、运行测试/代码检查/ git 命令等），并将文件修改限制在 apply_patch 命令的严格框架内，引导模型优先生成最小化的精准差异代码（diff），而非重写整个文件。

此外，安全与用户体验（UX）的设计也融入了提示逻辑：默认采用沙箱环境/禁止网络访问、对高风险命令设置明确的确认环节、要求模型在宣布任务完成前“通过项目自身的检查机制验证修改”。Codex 的规划过程是隐性的——它不会预先制定完整方案，而是通过“读取→编辑→测试”的迭代逐步推进；同时，差异代码预览与确认环节让人类始终掌握控制权。整体而言，Codex 依赖常规 UNIX 工具构建了一套小型、可审计的补丁循环，且将策略与防护规则直接编码在系统提示中。

二、工具与代码编辑：以 Shell 为核心 vs 结构化工具

Codex 与 Claude Code 的设计理念差异，在工具体系的构建上体现得尤为明显。

1. Codex：以 Shell 为核心的设计

Codex CLI 本质上只暴露 「一个核心工具：通用 Shell 命令执行器」。通过这个统一接口，模型可完成以下操作：

通过 cat 命令读取文件；
通过 grep 或 find 命令搜索内容；
通过 ls 命令查看目录；
运行测试、编译代码或执行 git 操作；
通过特殊的 apply_patch 命令修改文件。

这种设计的优势在于简洁性：模型无需学习多套 API，只需调用开发者熟悉的 CLI 工具即可。CLI 会按功能对命令分组，以实现差异化的权限审批——例如在“建议”模式下，文件读取操作可能自动通过审批，而高风险操作则需人工确认。

（图示：Codex 中简单重构请求的幕后流程）

「文件编辑的设计需要特别说明」：Codex 不会输出完整文件内容，而是生成特定格式的统一差异代码（diff）。CLI 会拦截 apply_patch 命令并在内部处理，以彩色标注的形式（红色表示删除、绿色表示新增）展示差异内容，供用户审核。用户可选择批准、拒绝、编辑该修改，或批量批准所有建议。

（图示：差异补丁是解决长上下文问题的方案）

2. Claude Code：结构化工具设计

Claude Code 采用更规范化的思路，提供 「明确的、专用的结构化工具」，包括：

「View/LS/Glob」：文件发现与读取工具；
「GrepTool」：支持完整正则表达式的搜索工具；
「Edit/Write/Replace」：结构化文件修改工具；
「Bash」：带安全检查的 Shell 命令执行工具；
「WebFetch」：受控的网页内容获取工具；
「Notebook 工具」：Jupyter 笔记本集成工具。

这种设计为每种操作设定了清晰的边界与验证机制，Claude 可对输入内容进行清洗、执行精细化权限控制，并在工具使用错误时提供更明确的报错信息。

3. 设计理念的异同

两款工具在代码修改上均遵循“以差异为核心”的理念，通过最小化、可审核的修改来优化上下文长度。但 Claude 的结构化工具支持更复杂的操作——相比 Codex 需逐步执行的 Shell 命令，Claude 能更轻松地完成大批量写入或多文件重构。

这意味着 Codex 的操作可能更耗时，但同时也更灵活，遇到的限制更少。此外，Codex CLI 默认禁止网络访问（沙箱环境限制），而 Claude Code 提供 WebFetch 支持受控网页交互；Codex 则支持多模态输入（如图片）。

三、安全性、审批机制与沙箱环境

当赋予 AI 智能体系统访问权限时，沙箱环境的安全性至关重要。两款工具均实现了多层安全机制，但设计思路存在差异。

1. Codex 的分级审批系统

Codex CLI 提供三种运行模式：

「建议模式（只读自动审批）」：自动批准安全的读取操作，修改操作与命令执行需人工确认；
「自动编辑模式」：展示差异内容后自动应用文件补丁，但命令执行仍需人工确认；
「完全自动模式」：在沙箱限制范围内，支持读写与执行操作的完全自主化。

审批逻辑（canAutoApprove 函数）会对每一项操作进行分类——例如，cat utils.ts 可能被归类为“文件读取”并自动通过审批，而 rm -rf 这类高风险命令会直接触发人工确认。

2. 沙箱环境实现

「macOS 系统」：Codex 采用 Apple 的 Seatbelt 配置文件，将文件系统访问权限限制在项目目录内，并禁止除 OpenAI API 外的所有网络访问；
「Linux 系统」：CLI 在 Docker 容器中运行，配合 iptables 防火墙规则，同样限制网络访问与文件系统范围。

这些操作系统级别的沙箱环境可防范常见攻击风险：

禁止访问 /etc/passwd 等系统文件；
拦截 curl、wget 等网络命令；
在非 git 仓库目录下操作时发出警告；
自动拦截高风险操作命令。

3. Claude Code 的权限模型

Claude Code 对命令采用 「精细化风险分类」，并提供更完善的输入清洗机制：

拦截高风险 Shell 语法（反引号、$() 命令替换）；
对网络访问目标进行白名单管控；
提供简洁的权限审批界面，支持“不再询问”选项；
网页版在 Anthropic 受控的云环境中运行。

两者的核心差异在于：Codex 侧重操作系统级别的隔离，而 Claude Code 聚焦应用层控制，用户体验更友好。两款工具都会及时向用户发出风险警告，但 Claude Code 的设计更贴合日常使用场景。

对我而言，当需要让工具获取 git 等权限时，Claude Code 的操作流程更流畅。

四、项目感知、上下文加载与规划方式

两款智能体对代码库的理解与导航方式，反映了其底层设计的核心差异。

1. Codex：惰性加载策略

默认情况下，Codex CLI 对文件加载持 「保守态度」——仅读取模型明确请求的文件。这种轻量化设计可减少 Token 消耗，但也可能带来问题：

若未读取相关文件，可能产生内容幻觉；
难以获取项目架构层面的上下文；
若不主动引导，智能体对项目的理解范围较窄。

为弥补这一不足，Codex 提供了以下功能：

「AGENTS. md 配置文件」：支持分层配置（全局→仓库→子文件夹），为智能体提供项目专属上下文；
「Git 感知能力」：鼓励通过 git status 等命令获取仓库状态与历史信息；
「全上下文模式」：实验性功能，可预加载整个项目（Token 消耗较高，但能提供完整上下文）。

2. Claude Code：主动扫描策略

Claude Code 采用截然相反的思路——它会 「自动扫描并加载相关文件」，通常无需额外引导就能理解跨文件依赖关系。这种设计带来的优势包括：

更易理解大型代码库；
减少对不存在组件的幻觉描述；
能提出更具挑战性的重构建议。

3. 规划透明度

「Codex 的规划是隐性的」：模型会在内部确定执行步骤，但不会向用户展示结构化计划（除非启用详细/推理模式）。用户只能看到正在执行的操作，无法提前知晓智能体的意图；
「Claude Code 的规划是显性的」：通过以下功能实现透明化规划：

TodoWrite 工具：生成结构化任务列表；
可见的 /think 模式：展示推理过程；
支持创建受控子任务；
清晰呈现多步骤工作流程。

这种透明性能帮助用户理解并引导 AI 的操作方向，但有时可能显得过于冗长。目前社区对 Claude Code 的主要批评，也集中在其冗长的输出上。

五、以差异为核心的工作流与迭代开发

两款工具均倡导“以差异为核心”的设计理念，这与人类开发流程高度契合。

迭代循环流程

「生成最小化差异代码」→展示彩色标注的修改内容；
「用户审核」→批准/编辑/拒绝修改；
「应用修改」→运行测试/执行命令；
「反馈结果」→模型获取标准输出/错误输出/退出码；
「迭代直至通过」→持续修复问题，直至测试通过。

这种流程天然具备以下优势：

修改内容小型化、可审核；
修改后可立即执行测试验证；
AI 操作轨迹可追溯，便于审计；
借助 git 可轻松回滚修改。

六、快速对比：两款工具的优势场景

尽管两款工具的核心基础一致（单循环、工具调用、以差异为核心的编辑、用户审批），但各自具备独特优势。

1. Codex CLI 的优势

开源且支持本地运行[8]（基于 Apache-2.0 协议）；
工具接口简洁，降低使用复杂度；
操作系统级沙箱环境，安全性强；
以 Shell 为核心的设计，对开发者更友好。

（图示：Codex 简化示意图）

2. Claude Code 的优势

工具集更丰富（支持搜索、网页访问、笔记本集成）；
规划过程显性化，支持任务分解；
主动扫描代码库，上下文理解更全面；
权限审批界面更精致，支持精细化控制。

（图示：Claude Code 简化示意图）

3. 早期用户反馈

社区反馈呈现出以下特点：

Claude Code 在大型代码库场景中表现更优，产生的幻觉更少，能处理更复杂的重构任务；
Codex 更适合精准修改与本地快速迭代；
一位 Reddit 用户提到，在处理两个持续存在的编码问题时，Codex“通过一个提示就轻松解决了”，而 Claude 未能完成；
Hacker News（HN）的讨论中，工具能力被排序为“Cursor-Agent-Tools > Claude Code > Codex CLI”（但这一排名变化迅速）；
Claude 通常输出更详尽、更“乐于助人”（有时过度详尽）；
Codex 对特定请求的聚焦度更高。

需注意的是，两款工具的迭代速度极快，上述差异可能随时变化。

七、该如何选择？

OpenAI Codex 与 Claude Code 均代表了 AI 辅助开发的前沿水平，二者针对不同工作流程进行了优化：

「Codex CLI」 践行 Unix 理念——以简洁工具实现高效组合。其以 Shell 为核心的设计、强大的沙箱环境与开源特性，更适合重视本地开发控制权与流程透明度的开发者。

「Claude Code」 采用结构化工具设计，具备显性规划能力与强大的上下文处理能力，更适合理解大型代码库与执行复杂重构任务的场景。

不妨将它们视为“能力极强的实习生”——它们能帮你节省大量时间，但仍需你引导工作方向并验证输出结果。

「更多 AI 前沿技术与设计灵感，欢迎关注「设计小站」公众号（ID：sjxz00），一起探索科技与设计的融合创新。」

原文地址：https://blog.promptlayer.com/how-openai-codex-works-behind-the-scenes-and-how-it-compares-to-claude-code/