GPT5.5 + Codex 如何跑一整夜，编程的下一步，不是辅助编程，是可托管执行单元

GPT-5.5 真正的红利，不是少写几行代码，而是把一个人能托管的工作块变大。

有人给GPT-5.5 Codex 一份新项目 PRD，只说了一个 go，它就跑了几个小时，从 build 到 visual review 再继续补功能。GPT-5.5 的变化从「更聪明」改写成「更能被托管」。

GPT-5.5 在 Codex 里是 agentic coding 的 frontier。他给了一个新项目 PRD，只说 go。Codex跑了几个小时，构建完整项目。build -> visual review -> build more 的闭环更强。GPT-5.5 更贵，但 更 to ken-efficient。

还有一个做真实业务的人很谨慎地说，别信那些空泛 hype，但她确实让 Codex + GPT-5.5 跑过接近 6 小时，做迁移前 edge case synthetic data 工具，而且结果能用。

GPT-5.5 + Codex | 特性

Codex模式下的自主性：OpenAI官方强调GPT-5.5是他们目前最强的agentic coding模型。它擅长处理长时程、多步骤任务，能自主规划、用工具、检查输出、迭代修复，甚至在复杂工作流（如Terminal-Bench 2.0上达到82.7%准确率，SWE-Bench Pro上58.6%）。不像以前的模型需要你一步步指导，它更能“理解你的意图”后自己把活干完，包括构建、调试、跨文件修改。

GPT-5.5在Codex里强化了闭环自主性（build → visual/functional check → iterate），减少了人类干预。以前AI更多是“助手”，现在更像“能独立推进项目的伙伴”。OpenAI自己也说，这朝着“real work”和未来superapp方向迈了一步，尤其适合编码、研究、文档/数据处理等知识工作。

GPT-5.5在Codex里对高层次指令响应极强。很多人分享用一个粗略描述或计划文档，就能让它启动完整项目构建、迭代修复、甚至视觉/功能检查。OpenAI提到它能处理“messy, multi-part task”，自己完成循环（plan → execute → check → iterate），这和传统“写代码等人审”区别很大。类似“一句话启动复杂开发”的案例在Codex用户中越来越常见。

OpenAI 的 Noam Brown 说，自己明明是 manager，但用了 GPT-5.5 以后，比过去任何时候都更像一个有效 IC。（我现在写CUDA内核像专业人士一样，还能靠它跑研究实验。）IC指Individual Contributor，即一线动手干活的角色，他作为经理却觉得自己在技术产出上达到了新高峰。

AI 编程这件事，好像开始从「你在旁边指挥它写」，变成「你能不能把一块工作托管给它」。

问题变成了，它能不能连续知道自己在干嘛，能不能失败后自己修，能不能跑几个小时以后，给你一个你敢验收的结果。

这个变化挺大的。

因为如果一个东西只能陪你写几行代码，那它是工具。

但如果一个东西可以拿走你的一整块工作，几个小时后回来交付，那它就开始像一个执行单元。

执行单元这四个字，听着有点硬。

但我想不到更合适的说法。

你不能再只问它「会不会写」。

你要开始问，它怎么接任务，怎么记住目标，怎么证明自己干对了，怎么在跑偏的时候停下来。

这就不是传统意义上的 AI 辅助编程了。在旁盯着，一次次交互改。

AI 辅助编程这个词，可能开始不够用了。代理式编程越来越关乎时间跨度，而不仅仅是单次智能。

当 Codex 这种 Agent 可以连续跑几个小时、十几个小时，甚至官方展示到 25 小时以后，未来我们该怎么把它从「辅助编程」当成「可托管执行单元」来管理。这，我觉得很重要。

这里面会有一种更大的变化：高级人类会越来越像「经理 + 架构师 + 验收者」的混合体。

验收者：成功长跑复盘 ，包含过程、成本、停机规则、验收结果的复盘。不要只要“跑了 8 小时”，要看最后交付物和怎么验收。

这里我们说 GPT-5.5 可能还不太合适，不过可以换成未来的：SOTA编程AI。

怎么跑一晚上

大家应该有好奇怎么跑长任务。我时常的提示也喜欢让他跑的久一点，把时间跨度拉长的端到端的来验收。许多人知道它能写代码，但不知道怎么让它把一个大任务跑完。

早在Claude code泄露的时候。有人用 Oh-my-codex，赶在天亮之前，把它用 Python 重构了一遍。据他所述，全程都是 Codex 自主执行。Oh-my-系列还有Claude Code，属于是同一作者所作。

Oh-my-codex README 核心：

OMX 是 Codex CLI 的 workflow layer。它让 Codex 更容易从 clarification 到 completion。

canonical workflow 包括 $deep-interview、$ralplan、$team、$ralph。

.omx/ 存 plans、logs、memory、mode tracking。

$ralph 是 persistent completion loop，

$team 是 coordinated parallel execution。

OMX 是在给 Codex 包一层长跑工作流和团队运行时。一句话丢给你的AI，它自己装完。

还有一个，可能很多人听过的。 superpowers，

README 直接说，Claude 可以 autonomously work for a couple hours without deviating from the plan。

它不是单个工具，而是 agentic skills framework & software development

methodology。

先 brainstorm，不直接写代码。

先把 spec 从对话里问出来，再写 implementation plan。

任务拆成 2-5 分钟的小块。

subagent-driven-development，review，TDD，verification。

它长跑不是靠模型硬扛，是靠方法论把人类判断外置成流程。

oh-my-codex、gstack、superpowers 这些项目的共同点，模型外面加了流程。

回到官方材料里，这件事其实更清楚。

OpenAI 今年 2 月发过一篇文章，叫 Run long horizon tasks with Codex。

里面有一个很夸张的实验。

他们给 Codex 一个空 repo，一个任务，让它从零构建一个 design tool。

Codex 用 GPT-5.3-Codex，在 Extra High reasoning 下，连续跑了大概 25 个小时。

大概 13M tokens。

大概 30k 行代码。

这组数字很容易被拿来当标题党。

25 小时，13M tokens，30k 行代码。

一看就很爽。

但我觉得这篇官方文章最重要的地方，反而不是这些数字。

最重要的是，OpenAI 把它为什么没跑丢，拆给你看了。

它不是靠一句神奇 prompt。

它靠的是一套很土，但是很工程化的东西。

四个 Markdown 文件。

1. Prompt.md，写清楚目标、非目标、硬约束、交付物，还有 done when。
2. Plan.md，把开放任务拆成 milestones，每个 milestone 都有 acceptance criteria 和 validation commands。
3. Implement.md，告诉 Codex 怎么执行，跟着计划走，验证失败就修，diff 不要乱扩。
4. Documentation.md，持续记录当前状态、决策、怎么运行、已知问题。

你看，这事就很有意思。

很多人还在问，怎么写一个让 Codex 跑 24 小时的 prompt。

但官方案例告诉你的，是 prompt 不够。

你得给它项目记忆。

你得给它计划。

你得给它验收标准。

你得让它在跑的过程中持续写状态。

像是在给一个会干活但会忘事的人，建工位、排日程、留工单、做验收。

一位GPT-5.2 早期实践者说Codex 默认长跑会丢 outcome，需要 continuity guidance。

他的连续运行 3 小时且思路连贯的方法：

另外，我翻了一下Codex changelog

changelog 中出现 memory extensions、context-window lineage headers、state DB、multi-agent followup、guardian/approval 相关变更。

这些不是宣传句，但它们说明底层工程也在补状态、恢复、审批、上下文 lineage。

越长跑，越不像单纯模型能力，越像状态机、权限、恢复和审计系统。

状态机有点不一样，他植入硬编码程序来支撑长跑。在一定时间还能清空上下文。这个值得聊，以后再论。

长跑 Codex 并不是没有问题

甚至恰恰因为它能跑得更久，问题会更明显。

我看到 Reddit 上有人问，怎么让 Codex autonomous 地跑几个小时。

他的痛点很直白。

他不想把 Codex 当 chat assistant。

他想让它像 autonomous agent 一样连续做 feature 或 refactor。

但现实是，它做一轮就停，等你继续说 continue。

还有人想让 Codex Cloud 并行处理 4 到 5 个任务，自己只 review code。

每个 runner 大约每小时仍要人工 approval。

一轮步骤有限，做完就 summary 然后等确认。

步骤塞多了，又容易碰 context limit 或 compression。

Cloud 有时像黑盒，任务卡住但不知道为什么。

GitHub issue 里也有类似的具体症状。

有人反馈 Codex 启动 npm run dev、python -m http.server、flask run 这种长驻进程后，会一直等进程结束。

Agent 显示 Working，但不继续改代码。

你想让它「启动 server，然后继续改 API endpoint」，它却卡在前台进程里。

这不是模型不会写代码。

这是执行系统不懂长驻进程。

还有一个 issue 里，用户想让 Codex sleep、wake、analyze、run、sleep，形成 continuous loop。

但 Codex 每做一个小块就 report back，打断连续执行。

最后用户只能 queue 多条 continue。

甚至有人说，Extra High reasoning 有时反而太谨慎，觉得大重构风险太高不敢推进。

切回 Medium，它反而先做第一步，再把事情跑通。

这点我觉得很重要。

高 reasoning 不等于高产出。

长跑有时需要的不是更谨慎的脑子，而是更清楚的任务切片和风险边界。

所以你会发现，长跑 Codex 的关键矛盾，不是模型能不能连续工作。

而是人能不能在它连续工作的时候，保留控制权、证据链和恢复能力。

这就是为什么最近很多相关东西都在往治理层长。

Codex Memories 默认关闭，但官方已经把它做出来了。

它让 Codex 把早期线程里的稳定偏好、工作流、技术栈、项目约定和已知坑带到未来工作中。

官方也提醒，必须稳定适用的团队规则，还是应该放在 AGENTS.md 或 checked-in docs 里。

memory 只是本地 recall layer。

这句话很克制，但很关键。

官方其实在承认一个事实。

长任务不是靠单线程上下文硬扛。

它需要可回收、可注入、可审查的记忆层。

看看你机器上的 Codex Memories 有没有开启。默认关闭，我自个检查的时候，发现自己的也没开。

长任务不该靠单线程硬扛，而要有可回收、可注入、可审查的记忆层

再看 Automations。

Codex 可以按 schedule 和 trigger 自动运行任务，可以返回同一段 conversation，继续已有上下文。

官方建议好的 automation 要 specific、repeatable、easy to review。

你看，它强调的仍然不是「完全自治」。

而是 reviewable。

可审阅。

这和我前面说的是同一件事。

AI 越能跑，人越不能只当观众。

你得设计它怎么跑。

还得设计它怎么停。

开源 / 产品

更有意思的是，社区也在自己造这层东西。

总

比如 gsd-2，讲的是 spec-driven development、context engineering、workflow state machine。

比如 ProofLoop，口号就很直白，define done，go to sleep，wake up to verified results。

比如 just-every/code，直接 fork Codex CLI，加 validation、automation、browser integration、multi-agents、provider orchestration。

比如 headless-pm，把多个 LLM coders 当成项目管理问题来协调。

这些东西有的成熟，有的很早期，有的只是一个小 repo。

但它们指向同一个方向。

用户不只想要一个更强的 Codex。

用户想要一个更强的 Codex harness。

或者说，想要一个能让 Codex 长跑时不乱跑、不黑盒、不失忆、不无限消耗的工作流层。

这才是我觉得这篇文章后面真正有意思的地方。

GPT-5.5 是入口。

Codex 25 小时是证据。

但下一个问题不是「它还能跑多久」。

下一个问题是，跑完以后，你凭什么相信它。

如果没有状态机，长跑只是一次更贵的走神。

如果没有证据链，睡醒验收就会变成开盲盒。

如果没有熔断器，它可能会在错误方向上越跑越勤奋。

如果没有恢复包，你中途打断一次，下一轮就要重新考古。

目标契约，知道什么算完成。

持久记忆，知道自己从哪来。

状态机，知道下一步该做什么。

验证链，知道交付有没有用。

熔断器，知道什么时候该停。

恢复包，知道断了以后怎么接。

人类审阅点，知道什么不能自己越权。

如果你今天晚上把任务交给一个 Agent，第二天早上你凭什么敢验收。

跑完以后，你能看懂它干了什么，知道它错在哪里，也知道下一步怎么接。

管理一个会自己调用工具、自己修错误、自己写状态、自己继续推进的执行单元。