OpenAI 工程师实测 GPT-5.3-Codex 连续运行约25小时从零构建设计工具
Run long horizon tasks with Codex
OpenAI 开发者博客记录一次长时程实验：用 GPT-5.3-Codex 在空白仓库上以 Extra High 推理从零构建设计工具， uninterrupted 运行约25小时、消耗约13M token、生成约30k行代码。
作者用一次25小时的实测复盘，给出长时程 Codex 任务的文件栈和验证方法，可迁移到自己跑长任务。
2025 年 9 月，OpenAI 推出了 GPT-5-Codex，这是 GPT-5 首个针对智能体编程优化的版本。2025 年 12 月，我们发布了 5.2，从那时起人们开始相信使用自主编程智能体可以是可靠的。特别是，我们看到模型能够可靠遵循指令的时长出现了巨大跃升。
我想对这个阈值进行压力测试。于是我给了 Codex 一个空白仓库、完全访问权限，以及一项任务：从零开始构建一个设计工具。然后我让它以 GPT-5.3-Codex 在“Extra High”推理级别下运行。Codex 不间断运行了约 25 小时，使用了约 1300 万 token，生成了约 3 万行代码。
这是一次实验，而非生产部署。但它在对长周期工作至关重要的方面表现良好：遵循规范、保持任务专注、运行验证，并在过程中修复故障。
一次长时间 Codex 会话是什么样的
我让 Codex 为会话数据生成一个摘要页面：
以下是 CLI 会话统计和 token 使用情况的视图：
这些截图很有用，因为它们让核心转变变得可见：智能体编程越来越关乎时间跨度，而不仅仅是一次性的智能。
真正的转变是时间跨度
这不仅仅是“模型变得更聪明了”。实际的变化是，智能体能够更长时间保持连贯、端到端完成更大块的工作，并在不丢失线索的情况下从错误中恢复。
METR 在时间跨度基准方面的工作为这一趋势提供了有用的框架：前沿智能体能够以约 50% 和 80% 可靠性完成的软件任务长度一直在快速攀升，大约每 7 个月翻一番。参见 Measuring AI Ability to Complete Long Tasks (METR)。
我们最近的 GPT-5.3-Codex 发布公告 从两个实际方面进一步推进了智能体工作：
- 它更擅长多步骤执行（规划 → 实现 → 验证 → 修复）。
- 它更容易在运行中途进行引导，而无需重置整个运行（纠偏不会抹掉进度）。
我也受到 Cursor 关于长时间运行自主编程系统文章的启发，包括他们的浏览器构建实验：How Cursor built a web browser (Scaling agents)。
Cursor 团队写道，OpenAI 模型“在扩展性自主工作方面要好得多：遵循指令、保持专注、避免漂移，并精确而完整地实现事物。”
为什么 Codex 能在长任务中保持连贯
长时间运行的工作与其说取决于一个巨大的提示词，不如说取决于模型所运行的智能体循环。
在 Codex 中，这个循环大致是：
- 规划
- 编辑代码
- 运行工具（测试/构建/lint）
- 观察结果
- 修复故障
- 更新文档/状态
- 重复
这个循环之所以重要，是因为它赋予智能体：
- 真实反馈（错误、差异、日志）
- 外部化状态（仓库、文件、文档、工作树、输出）
- 随时间可引导（你可以根据结果进行纠偏）
这也是为什么 Codex 模型在 Codex 界面上比在通用聊天窗口中感觉更好：该运行框架提供结构化上下文（仓库元数据、文件树、差异、命令输出），并强制执行一套有纪律的“何时算完成”例程。
我们最近发表了一篇关于 Codex 智能体循环的 文章，其中有更多细节。
除此之外，我们还推出了 Codex 应用，使这个循环在日常中可用：
- 跨项目的并行线程（长时间工作不会阻塞你的日常工作）
- 技能（标准化规划/实现/测试/报告）
- 自动化（在后台处理例行工作）
- Git worktrees（隔离运行，保持 diff 可审查，减少反复折腾）
我的测试环境搭建
我为这个“实验”选择了一个设计工具，因为它是一个毫不留情的测试：UI + 数据模型 + 编辑操作 + 大量边缘情况。你没法糊弄过去。如果架构错了，它很快就会崩溃。
我给 GPT-5.3-Codex 一份内容丰富的规格说明，以“Extra High”推理级别运行它，最终它不间断运行了约 25 小时，并能够保持连贯并交付高质量代码。该模型还为其完成的每个里程碑运行了验证步骤（测试、lint、类型检查）。
核心思路：持久的项目记忆
最重要的技术是持久的项目记忆。我将规格、计划、约束和状态写在 markdown 文件中，Codex 可以反复查看。这防止了偏离，并保持了稳定的“完成”定义。
仓库链接在下方，文件栈如下：
Prompt.md（规格 + 交付物）
目的：冻结目标，这样 agent 就不会“构建出令人印象深刻但错误的东西”。
文件中的关键部分：
- 目标 + 非目标
- 硬性约束（性能、确定性、UX、平台）
- 交付物（完成时必须存在的内容）
- “完成条件”（检查 + 演示流程）
初始提示告诉 Codex 将 prompt/spec 文件视为完整的项目规格，并生成基于里程碑的计划：
Plan.md（里程碑 + 验证）
目的：将开放式工作转化为一系列 agent 可以完成并验证的检查点。
文件中的关键部分：
- 里程碑足够小，可以在一个循环内完成
- 每个里程碑的验收标准 + 验证命令
- 停止并修复规则：如果验证失败，先修复再继续
- 决策记录以避免摇摆
- 代码库的预期架构
请注意，我们最近为 Codex 应用、CLI 和 IDE 扩展添加了原生计划模式。这有助于在做出更改之前将较大的任务分解为清晰、可审查的步骤序列，以便你可以提前对齐方法。如果需要进一步澄清，Codex 会提出后续问题。要开启它，请使用 /plan 斜杠命令。
Implement.md（引用计划的执行说明）
目的：这是运行手册。它告诉 Codex 具体如何操作：遵循计划、保持 diff 范围、运行验证、更新文档。
文件中的关键部分：
- 计划 markdown 文件是唯一事实来源（逐里程碑）
- 每个里程碑后运行验证（立即修复失败）
- 保持 diff 范围（不要扩大范围）
- 持续更新文档 markdown 文件
Documentation.md（交付时的状态 + 决策）
目的：这是共享记忆和审计日志。这样我就可以离开几个小时，仍然了解发生了什么。
文件中的关键部分：
- 当前里程碑状态（已完成什么，下一步是什么）
- 做出的决策（以及原因）
- 如何运行 + 演示（命令 + 快速冒烟测试）
- 已知问题 / 后续事项
这是运行期间里程碑验证在实践中的样子：
每个里程碑的验证
Codex 不只是写代码并希望它能工作。在里程碑之后，它运行验证命令并在继续之前修复失败。
以下是它被指示使用的质量命令示例：
以及 Codex 在 lint 失败后修复问题的示例：
agent 构建了什么
结果并不完美，也未达到生产就绪，但它是真实且可测试的。这次运行的标准不是“它能编译”；而是“它是否遵循指令，并且它是否真的能工作？”
已实现的高级功能：
- 画布编辑（框架、分组、形状、文本、图像/图标、按钮、图表）
- 实时协作（在线状态、光标、选区、跨标签页的编辑同步）
- 检查器控件（几何、样式、文本）
- 图层管理（搜索、重命名、锁定/隐藏、重新排序）
- 参考线/对齐/吸附
- 历史快照 + 恢复
- 回放时间线 + 从先前时间点分支
- 原型模式（热区 + 流程导航）
- 评论（带解决/重新打开的固定讨论串）
- 导出（保存/导入/导出 + CLI 导出为 JSON 和 React + Tailwind）
长周期 Codex 任务的要点
这次运行之所以成功，并不是因为某个巧妙的提示词。而是以下因素的结合：
- 明确的目标和约束（规范文件）
- 带有验收标准的检查点里程碑（
plans.md） - 指导智能体如何运行的运行手册（
implement.md） - 持续验证（测试/lint/类型检查/构建）
- 实时状态/审计日志（
documentation.md），使运行过程始终可检查
这正是长周期编码工作的发展方向：更少看护，更多在护栏下进行委托。
在你自己的长周期任务上试用 Codex
这次 25 小时的 Codex 运行，是对用代码构建未来走向的一次预览。我们正在超越单次提示和紧密结对编程循环，迈向能够端到端承担真实工作片段的长期队友，由你在里程碑处掌舵，而不是事无巨细地管理每一行。
我们对 Codex 的方向很简单：更强的队友行为、与你真实上下文的更紧密集成，以及让工作可靠、可审查、易于交付的护栏。我们已经看到，当智能体承担常规实现和验证时，开发者能更快推进，从而将人类解放出来，专注于最重要的部分：设计、架构、产品决策，以及没有模板可循的新问题。
而这不会止步于开发者。随着 Codex 在捕捉意图和提供安全脚手架（计划、验证、预览、回滚）方面变得更强，更多非开发者将能够构建和迭代，而无需生活在 IDE 中。Codex 各界面和模型还会有更多进展，但北极星始终不变：让智能体感觉不再像是一个需要你照看的工具，而更像是一个你可以在长周期工作中信赖的队友。
如果你想亲自尝试，可以从以下内容开始：
来源：OpenAI Developers：Blog（网页） · developers.openai.com