从 2021 年的代码补全玩具到如今能独立干 25 小时活的编程 Agent，Codex 走了一条很野的路。这篇文章不是产品说明书，而是一个 AI 编程重度用户的深度拆解——包括我踩过的坑、社区总结出来的实战套路、以及为什么越来越多老手开始"Codex 写代码 + Claude Code 做审查"这种骚操作。
〇、开篇先泼盆冷水
先说结论：Codex 很强，但没有任何一个 AI 编程工具是银弹。
社区里最真实的声音是这样的：有 Hacker News 用户吐槽"Codex 有时候会标记一个看起来很合理的数据库并发 bug，你花 30 分钟验证后发现是幻觉"。也有 Builder.io 的 CTO 说"我从 Cursor 切到 Claude Code，又从 Claude Code 切到 Codex，最后发现——我不需要花哨的功能，我需要一个可靠的 Agent 和一份写得好的指令文件。"
这两个声音，恰好勾勒出了 Codex 的真实面貌：在对的场景下极其强大，在错的场景下浪费你的时间。 这篇文章就是要帮你搞清楚，什么时候该用它、怎么用好它、以及它在整个 AI 编程工具链里到底处在什么位置。
一、两个 Codex，别搞混了
很多文章把 2021 年的 Codex 和 2025 年的 Codex 混为一谈，这是最常见的认知错误。
Codex v1（2021-2023，已废弃） ：GPT-3 的代码微调版本，170 亿参数，在 159GB Python 代码上训练。本质是个"更懂代码的补全模型"——你写个注释，它给你补一段代码。这个模型驱动了早期的 GitHub Copilot，在 2023 年 3 月被正式废弃。
Codex v2（2025 至今，本文主角） ：一个完整的 软件工程 Agent 产品矩阵，包含 CLI、Web、桌面 App、IDE 扩展、SDK、Slack Bot、GitHub Action。底层模型从 codex-1（基于 o3）一路迭代到了 GPT-5.4。
区别有多大？这么说吧：v1 就像一个打字速度极快的实习生，你说一句它写一行。v2 更像一个中级工程师——你把 Jira ticket 扔给他，他去读代码、改文件、跑测试、修 bug、最后提个 PR 给你 review。
二、Codex 的真实进化轨迹：关键转折点
不讲完整编年史了，只说几个真正改变游戏规则的节点：
2025 年 4 月 —— CLI 开源，Rust 重写
Codex CLI 开源是一步妙棋。它让社区能看到 Agent 的完整实现——prompt 怎么构建、工具调用怎么编排、沙箱怎么隔离。在 GitHub 上拿到了 59K+ Star。而且它是用 Rust 写的，零依赖安装，这比 Claude Code 的闭源策略赢了不少开发者好感。一个 HN 用户说："OpenAI 开源了 Codex CLI，这对任何想学习编程 Agent 如何工作的人来说都是大事。"
2025 年 5 月 —— codex-1 发布，RL 训练范式确立
codex-1 的训练方式是关键创新。它不是简单地在代码上做 fine-tuning，而是通过强化学习在真实编程任务上训练。RL 的奖励函数很有意思：不只是"代码能跑"，还包括"代码风格像人写的"、"遵循 PR 偏好"、"失败时诚实承认而不是瞎编"。这意味着模型被训练成了一个有职业素养的程序员，而不只是一个代码生成器。
2025 年 12 月 —— GPT-5.2-Codex，Context Compaction 改变一切
这是社区公认的"让人开始相信自主 Agent 可以可靠工作"的版本。原生 Context Compaction 意味着 Codex 可以在不丢失关键信息的情况下压缩上下文，从而支持多小时的连续工作。在此之前，所有 Agent 都会在长会话中"失忆"——这个问题终于被系统性地解决了。
2026 年 2 月 —— 25 小时马拉松实验
一个 OpenAI 工程师给了 GPT-5.3-Codex 一个任务：从零构建一个设计工具。结果：连续运行 25 小时，消耗 13M tokens，生成 30K 行代码。每完成一个里程碑都会自动跑测试、lint 和类型检查，遇到失败自动修复。
这不是 demo，这是对 Agent 耐力的极限测试。关键技巧是持久化项目记忆：把规格、计划、约束、状态都写进 Markdown 文件，让 Codex 反复回顾。这个模式后来成了社区的标准实践。
三、架构拆解：为什么 Agent Loop 的工程质量比模型更重要
这是整篇文章最硬核的部分，也是很多人忽略的部分。
SWE-Bench Pro 的数据给了一个残酷的事实：同一个模型，在基础 scaffold 下得分 23%，在优化后的 scaffold 下得分超过 45%。 22 个百分点的差距，远大于任何两个前沿模型之间的差异。
这意味着什么？意味着 Agent Harness 的工程质量比模型选择更重要。而 Codex 的 Agent Loop 设计，恰好是它最大的竞争力之一。
3.1 Agent Loop 是怎么转的
OpenAI 在 2026 年 1 月发了一篇技术文章拆解这个循环，核心流程：
用户输入 → Prompt 组装 → 模型推理 →
├─ 返回最终回复 → 结束
└─ 请求工具调用 → 执行工具 → 结果追加到 Prompt → 重新推理 → ...
看起来很简单，但魔鬼在细节里。
Prompt 的分层构建：不是简单拼接字符串。它有四个优先级层——system（通用规则）> developer（AGENTS.md）> user（环境信息 + 用户输入）> assistant（历史记录）。冲突时高优先级层胜出。
无状态请求模型：每次 API 调用都带完整对话历史，不依赖服务端会话存储。好处是天然支持 Zero Data Retention（零数据留存）——加密的推理消息可以临时解密用于推理，但不会被持久化。代价是网络传输量更大。
Prompt Caching：如果每次都重新处理完整历史，计算复杂度是 O(n²)。Codex 利用 Responses API 的缓存机制把它降到了线性。这是长会话性能的关键。
3.2 一个被低估的设计：App Server 协议
Codex 有四五个"表面"——CLI、VS Code、Web、桌面 App——它们共享同一个 Codex Harness。连接它们的是 App Server，一个双向 JSON-RPC 协议。
它定义了三个核心原语：
- Item：原子级的输入/输出单元，有完整生命周期（started → delta → completed），支持流式渲染
- Turn：一次完整的交互循环（可能包含几十次模型-工具迭代）
- Thread：持久化的对话，支持创建、恢复、分叉、归档
为什么这个设计重要？因为它让所有客户端都能一致地渲染 Agent 的渐进式输出。当 Codex 在后台跑一个 7 小时的任务时，你可以在手机上查看进度、在电脑上审查 diff、在 Slack 里收到完成通知——体验是连贯的。
OpenAI 一开始尝试过把 Codex 做成 MCP Server 来给 VS Code 用，但发现维护 MCP 语义太难了。最终才设计了这个专用协议。这种"走弯路后的正确选择"往往比一开始就做对更有价值——它意味着团队真正理解了问题。
四、实战：怎么写 AGENTS.md 才不是在浪费时间
AGENTS.md 是 Codex 最重要的可控性杠杆。但社区里大量的 AGENTS.md 都写得像废话——"请写高质量代码"、"遵循最佳实践"之类的。这些不是指令，这是祈祷。
4.1 一个真正有用的 AGENTS.md 长什么样
社区里流传最广的是一个开发者分享的个人 AGENTS.md，核心思路是把约束写成可验证的规则：
## Code Style
- 注释只用英文
- 优先函数式编程，OOP 只用于连接外部系统
- 所有函数必须有严格类型标注——返回值、参数、集合
- 禁止 default 参数值，所有参数必须显式传递
- 写代码前先检查是否已有类似逻辑
- 禁止无类型变量和泛型类型
- 单一职责函数——禁止多模式行为、禁止用 flag 参数切换逻辑
## Error Handling
- 所有错误必须显式抛出，禁止静默忽略
- 使用明确的错误类型
- 禁止 catch-all 异常处理器
- 错误消息必须清晰且可操作
## Git
- 禁止自动 commit 或创建分支，除非明确要求
- 变更要最小化，聚焦于当前任务
- 不要试图修复不相关的 bug
注意这份文件的特点：全是否定句和边界条件。不是告诉 Codex "应该怎么做"，而是告诉它"绝对不能做什么"。这比正面指导有效得多，因为 LLM 对负面约束的遵循度更高。
4.2 层级覆盖的实战用法
AGENTS.md 支持多层覆盖：全局 → 项目根目录 → 子目录。
实际中最有用的场景：你的 monorepo 里有个 services/payments/ 目录，金融相关代码有额外的安全要求。在这个目录下放一个 AGENTS.override.md：
## Payments Service Rules
- 使用 make test-payments 而不是通用 npm test
- 所有金额计算必须使用 Decimal 类型，禁止浮点数
- 任何涉及用户资金的变更必须有对应的审计日志
- PR 描述必须包含安全影响分析
Codex 会在全局规则的基础上叠加这些特殊约束。这种"渐进式细化"的设计，比在一个大文件里塞所有规则要优雅得多。
4.3 一个重要的陷阱
OpenAI 自己的 Codex 仓库有 88 个 AGENTS.md 文件。但这不意味着你需要这么多。一个社区帖子总结的经验是：先从一个简短的根目录 AGENTS.md 开始，只在 Codex 犯了你不想看到的错误时才加规则。 把 AGENTS.md 当成是你和 Agent 之间的"bug 修复日志"，而不是提前写好的用户手册。
五、我的日常工作流：Codex + Claude Code 的混合打法
这是 2026 年初越来越多资深开发者采用的模式。不是二选一，而是让每个工具干它最擅长的事。
5.1 为什么要混合使用
NxCode 做过一个详细对比，结论很清晰：
| 场景 | 更好的选择 | 原因 |
|---|---|---|
| 架构设计和规划 | Claude Code | 深度推理更强，处理模糊需求更好 |
| 自主后台任务 | Codex | 沙箱隔离更强，Token 效率更高 |
| 前端 React 开发 | Claude Code | Codex 在前端框架上偶尔犯低级错误 |
| 代码审查 | Codex | 捕获逻辑错误和竞态条件的能力更强 |
| 终端调试 | Codex | Terminal-Bench 上明显领先 |
| CI/CD 自动化 | Codex | GitHub Action 原生集成 + cloud exec |
| 大规模重构 | Codex | Context Compaction 支持更长会话 |
| 安全审计 | Codex | GPT-5.3+ 的网安能力获"High"评级 |
社区里最流行的组合拳：Claude Code 写功能 → Codex 审查代码 → 合并。有开发者说"我专门用 Codex 来 review Claude 的产出，它确实能抓到 Claude 漏掉的微妙问题"。
5.2 具体怎么操作
场景一：收到一个新 feature 需求
# 1. 先用 Claude Code 做规划（交互式，可以追问）
claude "分析 auth 模块的现有架构，设计 OAuth2 集成方案，输出到 docs/oauth-plan.md"
# 2. 根据规划，拆成多个小任务交给 Codex 并行执行
codex --full-auto "根据 docs/oauth-plan.md 实现 OAuth2 的 token 管理模块"
codex --full-auto "根据 docs/oauth-plan.md 添加 OAuth2 相关的集成测试"
codex --full-auto "更新 API 文档以反映 OAuth2 端点"
# 3. 用 Codex 的 code review 功能审查所有变更
codex "审查刚才三个任务的所有变更，检查安全性和一致性"
场景二：在 CI 里自动化
# .github/workflows/codex.yml
- name: Auto-fix failing tests
run: |
npm i -g @openai/codex
codex exec --full-auto "Fix failing tests and make npm test pass"
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
场景三：Slack 里当同事用
GA 之后 Codex 支持 Slack 集成。在频道里 @Codex 帮我查一下 payment service 为什么从昨天开始延迟增加了，它会自动读取上下文、选择合适的 environment、完成分析并回复一个链接。这比 Copilot 的 IDE 体验更适合"我正在开会但需要有人帮我查个东西"的场景。
5.3 成本的真实对比
这是很多人关心但很少有人说实话的部分。
两边入门价都是 20) 能做的事比 Claude Pro ($20) 多得多。多个开发者反映 Claude Pro 的限额在重度使用下很快耗尽，而 Codex Pro 用户几乎没人抱怨限额不够。
但如果你用 Codex Pro ($200)，你同时还获得了 ChatGPT 的全部能力——图像生成、视频生成、桌面 App 等。这个捆绑价值在 Claude 那边是没有的。
六、Codex 的 Skills 和 Plugins：Agent 的"技能树"
6.1 Skills：教 Agent 新本事
Skills 是 Codex 的能力扩展系统。一个 Skill 就是一个包含 SKILL.md 的目录，可以附带脚本。关键设计是渐进式加载——Codex 启动时只看元数据，用到时才读全文，避免上下文爆炸。
社区里已经有人做了很有意思的 Skill：
- 图片生成 Skill：通过 Gemini API 的 nanobanana 生成或编辑图片
- YouTube 转录 Skill：从视频 URL 提取字幕保存为本地文件
- Deep Research Skill：多实例多 Agent 编排，分解研究目标、并行执行
codex exec子进程、最终汇总成报告 - Spec-Kit Skill：基于 constitution 的规格驱动开发
6.2 Plugins：企业级的治理工具
Plugins 把 Skills 推到了企业级。它们将 Prompt、集成、策略打包成一个可审计的单元。平台工程团队可以用它强制执行编码标准。
但说实话，Plugins 目前还只有 OpenAI 官方策划的，没有开放第三方生态。这是一个潜力很大但尚未兑现的方向。
6.3 MCP：连接一切
Codex 可以作为 MCP Server 运行（codex mcp），也可以连接外部 MCP Server。这打开了多智能体协作的大门。
OpenAI Cookbook 里有一个完整示例：用 Agents SDK 编排一个"项目经理 → 设计师 → 前端工程师 → 后端工程师 → 测试"的多 Agent 流水线，每个 Agent 都通过 MCP 调用 Codex CLI，有严格的文件交接检查和 hand-off 逻辑。
# 每个 Agent 都有明确的职责和交付物
designer_agent = Agent(
name="Designer",
instructions=(
"Your only source of truth is AGENT_TASKS.md and REQUIREMENTS.md.\n"
"Deliverables (write to /design):\n"
"- design_spec.md\n- wireframe.md\n"
"When complete, handoff to the Project Manager."
),
mcp_servers=[codex_mcp_server],
)
这种"Agent 编排 Agent"的模式是当前最前沿的实践方向。
七、Codex 的真实能力边界——不吹不黑
7.1 真正厉害的地方
代码审查：这可能是 Codex 当前最被低估的能力。OpenAI 内部几乎每个 PR 都经过 Codex 审查，每天捕获数百个问题。GPT-5.3 已经发现了 500+ 个零日漏洞（测试环境中）。多个开发者反馈"Codex 在 review 时能抓到竞态条件和微妙的逻辑错误——这些是 Claude 经常漏掉的"。
自主长程任务：Context Compaction + 自适应推理使得 Codex 能持续工作数小时。简单任务时它很快（底部 10% 复杂度的任务比 GPT-5 节省 93.7% 的 Token），复杂任务时它会投入更多思考。
终端能力：Terminal-Bench 2.0 上 Codex 明显领先（GPT-5.3 Codex 77.3% vs Claude Opus 4.6 65.4%）。系统管理、Git 操作、CI/CD 调试、环境管理——这些终端场景是 Codex 的主场。
Token 效率：在同等质量下，Codex 的 Token 消耗远低于 Claude 家族。这不只是省钱，更意味着在固定上下文窗口里能做更多事。
7.2 真实的短板
前端开发：多个用户报告 Codex 在 React 等前端框架上偶尔犯基础错误。如果你主要做前端，Claude Code 目前体验更好。
长会话的稳定性：虽然 Context Compaction 解决了"失忆"问题，但仍有用户反映在超长会话中偶尔出现"行为不稳定"。社区的共识是：对于真正长程的任务，更重要的是把状态外化到文件里而不是依赖上下文。
错误恢复：Morphllm 的对比文章指出了一个很实在的差异——"当 Codex 失败时，你通常需要从头重新 prompt。当 Claude 失败时，你往往可以通过对话把它引导回正轨。" Claude 的交互式失败恢复确实更好。
开源但功能较少：Codex CLI 是开源的，但功能数量明显少于 Claude Code。Claude Code 有 sub-agents、自定义 hooks、丰富的配置层。不过，Builder.io 的 CTO 说了句很有道理的话："我从 Claude Code 学到的是——我不需要花哨的功能。我需要一个可靠的 Agent 和一份好的指令文件。"
八、企业落地的真实故事：不只是"提升 50%"
8.1 Cisco：从设计合作伙伴到生产级部署
Cisco 是 Codex 最深度的企业用户。他们的工程团队在多仓库、多安全域的复杂环境中集成了 Codex，用于自主构建和测试循环。实际成果：代码审查时间缩短 50%，框架迁移从数周缩短到数天。
但更有价值的是 Cisco 的反馈如何反向塑造了产品。他们在合规、长时间运行任务和 CI 管线集成方面的需求，直接影响了 Codex 的企业路线图。这种"共建"关系比单纯的"客户案例"有意义得多。
8.2 Instacart：用 SDK 构建内部平台
Instacart 通过 Codex SDK 集成到了内部的 Olive 平台。工程师一键启动远程环境并完成端到端任务。最有意思的用例是自动清理技术债——死代码、过期实验代码，这些"谁都知道该清但谁都不愿意干"的活，现在交给 Codex 持续处理。
8.3 OpenAI 自己：最好的 dogfooding
OpenAI 内部的数据是最有说服力的。到 2025 年 10 月 GA 时，几乎所有工程师都在使用 Codex（从 7 月的刚过半数快速增长）。每周合并的 PR 增加了 70%，几乎每个 PR 都经过 Codex 自动审查。
更关键的是，OpenAI 用 Codex 来改进 Codex 本身——Context Compaction 机制就是用 Codex 开发和优化的，形成了"用 AI 改进 AI"的飞轮。据报道，OpenAI 大部分代码现在都是由 Codex 生成的。
8.4 一个独立开发者的故事
ZDNet 报道了一个开发者的案例：用 ChatGPT Plus 的 $20/月计划运行 GPT-5.2-Codex，发现了一个他自己怎么也找不到的"幽灵 bug"，还用 Agent 实现了新功能。这个案例说明 Codex 不只是大厂的玩具，独立开发者也能从中获得实实在在的价值。
九、模型矩阵：选对模型比会用命令更重要
到 2026 年 3 月，Codex 的模型家族已经很庞大了。怎么选？
日常交互问答：用 GPT-5.4 mini，速度快、Token 消耗低（只有标准模型的 30%），适合快速的 Q&A 和小修改。
中等复杂度任务：用 GPT-5.3-Codex + medium reasoning。这是大多数任务的甜蜜点——够聪明、够快、够省。
重度自主任务：用 GPT-5.3-Codex + high/xhigh reasoning。大规模重构、完整功能实现、长程调试。可以连续工作数小时。
极速响应：Codex-Spark（与 Cerebras 合作的研究预览版），延迟极低，适合对速度要求极高的场景。
安全相关：GPT-5.2-Codex 或更新版本，网络安全能力最强。一位安全研究员用 Codex 发现并负责任地披露了 React 中的一个源代码暴露漏洞。
一个实用的经验法则：不要一直用最高配。reasoning effort 设成 xhigh 不是免费的——它会消耗大量 Token 和时间。只有在任务真正复杂时才提高。GPT-5-Codex 在底部 10% 复杂度的任务上，使用的 Token 比通用 GPT-5 少了 93.7%。这种自适应能力意味着你应该信任模型自己的判断，而不是一味地调高参数。
十、安全模型：为什么 Codex 的沙箱是 OS 级别的
这是 Codex 和 Claude Code 最根本的架构差异之一。
Codex CLI 的沙箱是在 操作系统内核级别 实现的——macOS 用 Seatbelt，Linux 用 Landlock/namespace。这意味着即使模型"决定"要做越界操作，OS 也会阻止它。
Claude Code 的沙箱依赖 应用层 hooks——本质上是在同一个进程边界内的约束。好处是更灵活（可以编写任意验证逻辑），坏处是理论上可以被绕过。
一个架构对比文章的总结很精准：
- 低信任场景（审查不认识的代码、处理外部输入） → 用 Codex，内核沙箱保底
- 中信任场景（自己的代码库，做常规开发） → 两者都行
- 高信任场景（有完善的治理框架，需要精细控制） → Claude Code 的 hooks 更灵活
对于企业来说，Codex 还支持 Zero Data Retention——你的代码只在推理时临时使用，不会被持久存储。这对金融和医疗行业的合规要求很重要。
十一、展望：我认为接下来会发生什么
11.1 Agent 的时间地平线还在快速延长
METR 的基准测试显示，前沿 Agent 能可靠完成的任务时长大约每 7 个月翻一倍。从最初的几分钟到现在的 25 小时，再到明年可能是几天甚至一周。这意味着 Agent 能承接的任务粒度会越来越大——从"修个 bug"到"实现一个完整的微服务"。
11.2 多 Agent 协作将成为主流
现在已经有人用 Codex 编排 PM → Designer → Frontend → Backend → Tester 的完整流水线了。当模型能力继续提升，这种多 Agent 协作会从"前沿实验"变成"日常操作"。
11.3 非开发者参与编程
Superhuman 让 PM 通过 Codex 直接贡献代码变更（仅需工程师 review），这是一个非常有想象力的方向。当 Agent 足够可靠时，"写代码"将不再是工程师的专利——就像 Excel 曾经把"数据分析"从统计学家手里解放出来一样。
11.4 开源 vs 闭源的路线之争
Codex CLI 开源 vs Claude Code 闭源，这个路线分歧会持续影响生态。开源让社区能贡献 Skill、Plugin、配置模板（GitHub 上已经有人维护了 codex-settings 这样的配置合集），而闭源让产品体验更一致。目前来看，Codex 在社区信任度上领先，Claude Code 在产品完成度上领先。
写在最后：这不是工具的选择，而是工作方式的变革
写这篇文章的过程中，我越来越觉得，讨论"Codex 好不好用"已经不是最重要的问题了。更重要的问题是：你是否已经开始把 AI Agent 当成团队成员来管理，而不只是一个更快的搜索引擎？
写 AGENTS.md 本质上就是在做 onboarding——给新入职的 AI 同事写入职文档。选 reasoning effort 本质上就是在做任务分配——简单的活不需要派高级工程师。用 Codex review Claude 的代码本质上就是在做 code review 流程——只不过 reviewer 也是 AI。
Builder.io 那位 CTO 说得最好："我不关心功能。我需要一个 Agent 和一份好的指令文件。就这样。"
这个判断简单得近乎粗暴，但我越想越觉得它抓住了本质。在 AI 编程工具疯狂内卷的 2026 年，真正决定你效率的不是你用哪个工具，而是你有没有想清楚怎么和 AI 协作。
Codex 是目前这个方向上最完整的产品之一——开源的 CLI、云端的异步执行、企业级的安全模型、持续进化的模型家族。它不完美，前端开发有短板，长会话偶尔翻车，功能不如 Claude Code 丰富。但它提供了一个清晰的心智模型：你是一个工程团队的 leader，Codex 是你的远程团队成员。你的工作不是写代码，而是写好指令、分配好任务、做好 review。
这才是 AI 编程真正在改变的东西——不是让你打字更快，而是让你的角色从"执行者"变成"指挥者"。
免责声明：本文作者同时使用 Codex 和 Claude Code 作为日常开发工具，没有对任何一方的商业偏好。文中所有 benchmark 数据和企业案例来源于公开资料，已在行文中标注。AI 工具领域变化极快，所有信息以撰写时（2026 年 3 月）为准。
