就在刚刚，OpenAI 再次投下重磅炸弹！正式发布编程智能体 Codex！

OpenAI CEO Sam Altman 激动地表示：

今天我们推出了 Codex。它是一个在云端运行的软件工程智能体，能为你完成诸如编写新功能或修复 bug 等任务。你可以并行运行许多任务。一个人借助这样的工具能创造出多少软件，这太神奇也太令人兴奋了！

「你只管做就行」是我最喜欢的句子之一；我没想到它会这么快，并以如此重要的方式应用于 AI 本身及其用户。

OpenAI 联合创始人 Greg Brockman 也难掩兴奋：

我们刚刚发布了 Codex，一个可以并行处理多项任务的软件工程智能体。它运行在基于云计算的基础设施上，可以修复 bug、回答关于你代码的问题、运行测试等等。感觉这是向软件工程未来迈出的一大步。

那么，这个被 OpenAI 寄予厚厚望的 Codex 究竟是什么？它将如何改变软件开发的未来？我们第一时间为你解读！

划重点：

• 全新 Codex： 云端软件工程智能体，可并行处理多任务。
• 核心模型 codex-1： o3 专门微调版，专为软件工程打造，注重代码质量与实用性。
• 强大功能： 写功能、修 Bug、答疑、提 PR、跑测试、主动建议任务。
• 运行环境： 每个任务在独立云沙箱运行，预装代码库，可配置。
• 智能引导： 可通过仓库内 AgentS.MD 文件指导。
• 透明可信： 提供详细操作日志、引用和测试结果，方便验证。
• Codex CLI 升级： 同步推出 codex-mini-latest 模型，使用更便捷。
• 上线节奏： ChatGPT Pro、Team、Enterprise 用户今日可用，Plus 和 Edu 稍后。

软件工程的未来已来？Codex 震撼亮相

在 OpenAI 的发布会上，Greg Brockman 开场便定下基调：「软件工程正在发生变革，到 2025 年底，它将发生根本性的不同。」

回想 2021 年，OpenAI 发布了初代 Codex 模型，那可能是「氛围编程」（vibe coding）概念的首次亮相。几周前，他们又推出了在本地终端运行的 Codex CLI。而今天，OpenAI 则迈出了更大的一步——推出了这款全新的、可在云端并行处理多任务的远程软件智能体，依然命名为 Codex。

「Codex 令人兴奋之处在于，它在 OpenAI 的计算资源上运行你的代码仓库和环境。这意味着你可以运行非常非常多的 Codex 实例，并行处理海量任务，然后稍后再回来查看结果。」Greg 介绍道。

核心驱动力：全新 codex-1模型

驱动这款强大智能体的是一个名为 codex-1 的全新模型。OpenAI 称其为迄今为止最强的编码模型。它基于

o3 进行深度微调优化，不仅追求基准测试的高分，更注重生成那些开发者真正愿意合并到代码库中的代码——考虑注释、避免不必要的更改、符合代码风格，从而真正加速开发工作。

在编程评估和内部基准测试中，codex-1 模型即便没有其他 Agent 能力的优化，表现也十分出色。

实战演练：Codex 如何施展「魔法」？

发布会上，Codex 团队成员 Hanson Wang, Joshua Ma, Thibault Sottiaux, Katy Shi, 和 Andrey Mishchenko 详细演示了 Codex 的强大能力。

首先，你需要连接你的 GitHub 账户并选择一个代码仓库。演示中，团队选择了自家的开源项目 preparedness repo。

一上来，Codex 就提供了三个推荐的初始任务：

1. 1. 解释代码库：让 Codex 向新手解释代码库的整体结构。
2. 2. 查找并修复 Bug：在代码库中寻找并修复一个潜在的错误。
3. 3. 主动任务建议：让 Codex 浏览代码库，不仅是探索，还要主动提出它可以独立完成的任务建议。

Thibault Sottiaux 还即兴添加了一个他个人非常喜欢的任务：「找到并修复尽可能多的拼写和语法错误。」 然后展示了一个预设的任务，要求 Codex 针对「代码库可维护且无 Bug」的目标提出新颖的改进建议（而非简单的 TODO）。

Codex 思考 3 分钟后给出了反馈，例如指出了代码中存在的「可变默认参数」问题，并建议修复。对于超时设置不一致的问题，Codex 甚至主动为自己提出了一个任务来统一它们！Thibault 感叹：「这种委托的委托，每次都让我大开眼界。」

云端运行：强大的智能体基础设施

这些并行任务并非在本地运行。「我们现在需要新的智能体编码基础设施，在这个世界里，智能体不仅需要自己的 GPU，还需要一些 CPU。Codex 运行在 OpenAI 的计算基础设施上，事实上，这与我们用于强化学习的基础设施相同，这意味着它在发布前就已经在大规模训练中得到了实战检验。」

每个 Codex 任务都在其独立的微型虚拟机（micro-VM）沙箱中运行，拥有独立的文件系统、CPU、内存和网络策略。智能体可以在这个沙箱内自由发挥，使用 grep 等 POSIX 命令，运行 linter、formatter，编写并执行代码。

更棒的是，这个环境是可配置的。用户可以通过设置脚本、环境变量、密钥等来定制运行时，从而解锁智能体的全部潜力。OpenAI 内部甚至设置了 pre-commit 钩子，让智能体在编码时就能像人类开发者一样提交并检查。

智能体的「养成」：agents.md与强化学习

OpenAI 还演示了 Codex 如何处理一个来自用户的 Bug 报告：当文件名包含特殊字符时，Codex CLI 的 diff 命令会报错。

为了更好地引导模型，OpenAI 引入了一个名为 agents.md 的文件概念。开发者可以在仓库中放置这个文件，向 Codex 提供关于代码库布局、测试命令、编码规范等指令。演示中，agents.md 甚至指示 Codex 在终端打印一个 ASCII 艺术猫咪，趣味十足。

通过端到端的强化学习训练，Codex 不仅学会了写代码，还学会了导航代码库，甚至复现问题。它会编写脚本程序来验证 Bug，就像人类开发者使用 print 调试一样。这种能力在 SWE-bench 等评估中达到了 SOTA 水平。

在短短几分钟的演示中，Codex 成功定位问题、编写测试用例、修复代码，并遵循 agents.md 中的指示运行 linter、准备提交信息，最终生成了一个 PR。Greg Brockman 看后直呼：「这简直是魔法！我确实感受到了 AGI 的影子。」

超越语言模型：构建真正的 AI 系统

Greg Brockman 强调，Codex 的意义在于，OpenAI 正在超越仅仅将 AI 系统视为语言模型的阶段，而是围绕它们构建真正的系统。「这不仅仅关乎核心 AI 智能，更关乎它能接触到什么工具，它能在什么样的环境中运作，以及它被训练来接触什么样的真实世界条件。它开始感觉更像是我们将看到的真正 AGI 的界面。」

Jerry Tworek 回顾了从早期驱动 GitHub Copilot 的 Codex 模型（更像智能自动补全）到 GPT-4 的演进。他认为，当前的强化学习范式终于能让我们自动化更大块的工作，让模型为用户在真实的生产代码库上长时间工作。而且，这套云端基础设施是完全可扩展的，「一键之下，你可以启动一个智能体、10 个，甚至 10000 个。这是一个按需分配、AI 驱动的『力量倍增器』。」

可信赖的「AI 同事」：对齐、可解释与验证

Katy Shi 讨论了如何训练这些模型以符合人类期望。她指出，在审查 AI 生成的代码时，人们关注点包括：更改是否合理、是否精确执行了 PR 描述、有无额外更改、代码质量和风格等。

Codex 在这方面做了大量工作，力求输出易于审查的代码。更重要的是可解释性和可验证的输出。在 Codex 界面左侧，模型会生成它所做操作的摘要，解释它为什么这么做，并提供「引用视图」，精确显示它参考了哪些代码。测试部分则会明确报告测试是通过还是失败，并显示相关日志。

「我们发现 Codex 和我们的同事一样值得信赖，甚至更值得信赖。我无法像这样随时查看 Andrey 某一天具体做了什么、日志是什么、测试输出是什么。随着 AI 编写越来越多的代码，这种可验证性将变得至关重要。」

安全第一：负责任地构建 AI 智能体

OpenAI 强调，Codex 作为研究预览版发布，遵循其迭代部署策略。设计时优先考虑了安全性和透明度。

• 安全执行： Codex 智能体完全在云端的安全隔离容器中运行。任务执行期间，互联网访问被禁用，仅能与通过 GitHub 仓库明确提供的代码和用户配置的预装依赖项交互。
• 防止滥用： Codex 经过训练，能够识别并明确拒绝旨在开发恶意软件的请求，同时区分并支持合法的、可能涉及类似技术的任务（如底层内核工程）。OpenAI 还更新了 o3 系统卡以反映这些评估。
• 对齐人类偏好： codex-1 致力于生成更整洁、可直接供人审查和集成的代码补丁。

内部使用与早期用户反馈

OpenAI 的工程师们已经开始在日常工作中使用 Codex。Andrey Mishchenko 分享道，他常常在处理协调工作间隙，将一些代码更改、重构或功能想法用 30 秒快速交给 Codex 处理，然后继续忙其他事情，稍后回来任务就已经完成。有时甚至是数百行的代码差异，而且看起来是正确的！「当一个重要的改动，分支甚至从未接触我的笔记本电脑，就完全通过与这些智能体的异步委托完成了，那种时刻真的很神奇。」

其他外部的早期测试者也给出了积极反馈：

• Cisco： 探索 Codex 如何帮助工程团队更快实现宏大构想。
• Temporal： 使用 Codex 加速功能开发、调试、编写和执行测试、重构大型代码库。
• Superhuman： 利用 Codex 加速重复性任务，如改进测试覆盖率和修复集成失败，甚至让产品经理也能贡献少量代码（工程师仅需审查）。
• Kodiak： 使用 Codex 编写调试工具、改进测试覆盖率和重构代码，加速其自动驾驶技术的开发。

本地版 Codex CLI 同步迎来升级

与云端 Codex 并行，本地的 Codex CLI 也迎来了重要更新：

1. 1. 全新模型 codex-mini-latest： 这是 codex-1 的一个小型化版本（基于 o4-mini），专为 Codex CLI 设计。它针对低延迟代码问答和编辑进行了优化，同时保持了指令遵循和代码风格的优势。该模型也通过 API 提供，定价为输入 $1.50/百万 token，输出 $6/百万 token，并有 75% 的提示缓存折扣。
2. 2. 便捷登录： 不再需要手动生成和配置 API 令牌，现在可以直接使用 ChatGPT 账户登录，并选择要使用的 API 组织。系统会自动生成和配置 API 密钥。
3. 3. API 额度赠送： Plus 和 Pro 用户通过 ChatGPT 登录 Codex CLI，从今天起的未来 30 天内，将分别获得 $5 和 $50 的免费 API 额度。

可用性、定价与局限性

• Codex (云端版)：
• 首批用户： ChatGPT Pro、Enterprise 和 Team 用户今日起全球陆续开放。
• 后续用户： Plus 和 Edu 用户即将推出。
• 初始定价： 未来几周内免费，并提供非常慷慨的使用额度。之后会推出速率限制和灵活的按需购买选项。
• 局限性：
• 仍是研究预览版，功能尚不完善（如不支持前端图像输入）。
• 目前无法在任务执行中途进行纠正。
• 远程委托比交互式编辑耗时更长，需要适应。

未来展望：人机协同的新范式

OpenAI 对 Codex 的未来充满期待。Greg Brockman 展望道：「你真正想要的是一个拥有自己电脑的远程同事，但它也能随时『站在你身后』看你的屏幕。你正在写代码，想去吃午饭，对 Codex 说『能帮我完成这个吗？』它就能无缝接管并在云端运行。」

未来的蓝图包括：

• 功能融合： 本地同步的 Codex CLI 与云端异步的 Codex 将走向融合，形成统一的工作流。
• 更强交互： 允许开发者在任务中途提供指导、协作制定实施策略、接收主动进度更新。
• 深度集成： 与 GitHub 的连接只是开始，未来将能从 Codex CLI、ChatGPT 桌面版，甚至 Jira 等问题跟踪器或 CI/CD 系统直接分配任务。如果 CI 报错，Codex 或许能自动修复。

「它是一个你可以委托任务的实习生，一个导师，一个结对编程伙伴，集所有角色于一身。」Greg 总结道，「我们的目标是加速有用的工作，让世界上有更多的软件工程师，完成更多有用的编程工作，推动世界前进。」

One more thing：发布即公开 System Prompt

每当有 AI 工具发布时，大家总是很好奇背后的系统指令。这次，OpenAI 直接大方地公开了 Codex 的系统指令！大家可以自行挖掘其中的亮点：

# Instructions
- The user will provide a task.
- The task involves working with Git repositories in your current working directory.
- Wait for all terminal commands to be completed (or terminate them) before finishing.

# Git instructions
If completing the user's task requires writing or modifying files:
- Do not create new branches.
- Use git to commit your changes.
- If pre-commit fails, fix issues and retry.
- Check git status to confirm your commit. You must leave your worktree in a clean state.
- Only committed code will be evaluated.
- Do not modify or amend existing commits.

# AGENTS.md spec
- Containers often contain AGENTS.md files. These files can appear anywhere in the container's filesystem. Typical locations include `/`, `~`, and in various places inside of Git repos.
- These files are a way for humans to give you (the agent) instructions or tips for working within the container.
- Some examples might be: coding conventions, info about how code is organized, or instructions for how to run or test code.
- AGENTS.md files may provide instructions about PR messages (messages attached to a GitHub Pull Request produced by the agent, describing the PR). These instructions should be respected.
- Instructions in AGENTS.md files:
  - The scope of an AGENTS.md file is the entire directory tree rooted at the folder that contains it.
  - For every file you touch in the final patch, you must obey instructions in any AGENTS.md file whose scope includes that file.
  - Instructions about code style, structure, naming, etc. apply only to code within the AGENTS.md file's scope, unless the file states otherwise.
  - More-deeply-nested AGENTS.md files take precedence in the case of conflicting instructions.
  - Direct system/developer/user instructions (as part of a prompt) take precedence over AGENTS.md instructions.
- AGENTS.md files need not live only in Git repos. For example, you may find one in your home directory.
- If the AGENTS.md includes programmatic checks to verify your work, you MUST run all of them and make a best effort to validate that the checks pass AFTER all code changes have been made.
  - This applies even for changes that appear simple, i.e. documentation. You still must run all of the programmatic checks.

# Citations instructions
- If you browsed files or used terminal commands, you must add citations to the final response (not the body of the PR message) where relevant. Citations reference file paths and terminal outputs with the following formats:
  1) `【F:<file_path>+L<line_start>(-L<line_end>)?】`
  - File path citations must start with `F:`. `file_path` is the exact file path of the file relative to the root of the repository that contains the relevant text.
  - `line_start` is the 1-indexed start line number of the relevant output within that file.
  2) `【<chunk_id>+L<line_start>(-L<line_end>)?】`
  - Where `chunk_id` is the chunk_id of the terminal output, `line_start` and `line_end` are the 1-indexed start and end line numbers of the relevant output within that chunk.
- Line ends are optional, and if not provided, line end is the same as line start, so only 1 line is cited.
- Ensure that the line numbers are correct, and that the cited file paths or terminal outputs are directly relevant to the word or clause before the citation.
- Do not cite completely empty lines inside the chunk, only cite lines that have content.
- Only cite from file paths and terminal outputs, DO NOT cite from previous pr diffs and comments, nor cite git hashes as chunk ids.
- Use file path citations that reference any code changes, documentation or files, and use terminal citations only for relevant terminal output.
- Prefer file citations over terminal citations unless the terminal output is directly relevant to the clauses before the citation, i.e. clauses on test results.
  - For PR creation tasks, use file citations when referring to code changes in the summary section of your final response, and terminal citations in the testing section.
  - For question-answering tasks, you should only use terminal citations if you need to programmatically verify an answer (i.e. counting lines of code). Otherwise, use file citations.

结语

软件工程，乃至整个创造性工作的范式，或许正站在一个新的颠覆点。对于开发者而言，这既是挑战，更是前所未有的机遇。我们拭目以待，看 Codex 将如何被全球开发者玩出花来！