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