OpenAI 的开发者博客前几天放出一组数字。一个空仓库，全权限，一句话的任务，GPT-5.3-Codex 把 reasoning 开到 Extra High，连续跑了 25 小时没断，烧掉约 1300 万 token，写出大约 3 万行代码。任务是从零做一个设计工具。

这组数字散开之后，讨论基本停在"25 小时"和"1300 万 token"上。我倒觉得这两个数只说明一件事，算力确实变便宜了。真正值得看的是另一面，它凭什么能跑 25 小时还不跑偏。

它凭什么没断线#

写代码的 agent 一晚上跑不完一个功能，多数时候不是因为它不会写，而是跑到某个点就忘了自己在干什么。上下文塞满，决定散在对话里，下一步没人记得。

Codex 这次扛住了，靠的不是模型记性好。它靠的是那个循环把状态全搬到了模型外面。

官方的描述是这样一圈：出计划，改代码，跑工具（测试、构建、lint），看结果，修失败，更新文档和状态，回到开头。

七步里有一半动作是把东西写到硬盘上。diff、日志、状态文档、worktree。模型在下一轮能重新读回来。也就是说它可以忘，但不会丢。

这个区别很容易被略过。模型记不住的东西越多，就得往上下文里塞越多；塞得越满，越容易在无关的地方跑偏。状态外置之后，上下文只需要装"现在这一步该干什么"，不用装"过去二十小时发生过什么"。

官方还引了 METR 的时间跨度基准。前沿 agent 能以大约 50% 和 80% 可靠性完成的软件任务长度一直在快速上升，大致七个月翻一倍。那条曲线讲的是同一件事：任务能拉多长，取决于 agent 内部能不能维持一个可恢复的状态机。

五周、400 个子 agent，值得看的不是 400#

OpenAI 开发者体验负责人 Jason Liu 在一次 workshop 上展示了一个已经跑了五周的 Codex thread，这期间协调了大约 400 个子 agent。

这个数字好传播，但它记录的是算力活动，不是组织成熟度。真正有意思的是另一点，这个 thread 被再次唤醒的时候还认得出自己是干什么的，会去翻之前的记录，然后接着做同一摊事。

那一步做不到，前面跑多久都白搭。

他们用 pinned thread 承载长期职责，比如 chief of staff、Agents SDK 支持、命令行工具、开源项目、用户反馈。每个 thread 有自己的历史、目标、自动化时间表，彼此之间还能找到、改名、发消息。

真正持久的单位不是子 agent 的数量，是一个职责边界。它至少要撑住四层东西。

层要留住什么用来干什么
职责一个角色、它服务谁、允许它碰什么范围不让它每次醒来重新猜自己的岗位
状态事实、做过的决定、没闭环的事、卡点、下一步让工作跨天之后还能被人读懂
唤醒条件定时、事件、人发一句话、重试规则决定系统什么时候花资源、什么时候下判断
验收与停止测试、证据、审批、终止条件不让完成标准漂移，也不让循环无限跑

四层里没有一层是给模型看的，全是给人看的。这句话可以反过来读：长跑 agent 的工程质量，等于它留给人的可读性。

账单不在 token 上#

短任务的成本好算，就是 token。长任务不是。

每一次定时唤醒，都要重新加载足够多的上下文才能做出一个安全的判断。这是推理成本。

时间表排得太密，就会产生一堆没有任何新信息的检查。这是监控成本。

草稿、改动、异常不断往人这边推。这是审查成本，也是最容易被低估的那一项。

一个跑五周的 thread，如果每小时醒一次，就是八百多次判断。哪怕其中九成都是"没事发生"，那九成也要花钱，也要占掉一次决策预算。

跑得越久，边际成本涨得越快的那部分不是机器，是人。四个并行 agent 产生四份 diff，读还是得人来读。如果审查本来就是瓶颈，并行只会把瓶颈压得更窄。

有界自主，别读成"让它一直跑"#

Codex 现在的功能面铺得很开。app、CLI、IDE 集成、云端任务、后台作业、子 agent、AGENTS.md，还有针对长任务调过的模型。看到这一堆，很容易得出一个错结论，那就让它一直跑。

正确的读法是有界自主。这条线比任何 prompt 技巧都实在：

  • AGENTS.md 说清项目怎么运转
  • 每一项活有自己的 worktree 和分支
  • 任务有明确的终点和停止条件
  • 它往前推之前先交证据
  • 只有当工作真的能拆开时才上子 agent
  • token、时间、磁盘、进程都有可见的上限
  • 提交、测试、截图、日志、diff 构成可复查的痕迹

这些不是在限制 agent 的能力，是在把能力变成可交付。没有停止条件的 agent 不会在完成后停下，它会开始改你没让它改的东西。这一点我在自己那几个定时任务上见过太多次。

25 小时那次实验，条件很干净#

官方那篇的措辞很小心，说这是一次实验，不是生产部署。这句话值得认真读。

实验条件是空仓库、全权限、一个写得出来的规格。这三样在真实项目里一样都不齐。仓库新旧混杂，测试覆盖不全，规格往往是开会时口头传下来的。25 小时里能犯的错，在这种环境里会被放大 25 倍。

但这不影响结论的有效性。它证明的是，当循环能提供真实反馈、状态落在模型外面、停止条件又被人检查的时候，长跑是成立的。剩下的是工程问题，不是模型问题。

工具侧这两周的变化#

Codex CLI 0.163.0 是十月十五号发的，两个改动和这个话题直接相关。

一个是能在 agent 还在生成的时候改方向，不用杀掉整个 run 重来。以前只有两个选项，等着，或者取消。长会话里这两样都贵。

另一个是只读工具可以并行跑。读文件、搜索不必一个个排队，空等的时间压下去了。

再往前的 alpha 里还有几件更底层的事。agent 可以自己创建和列出托管 worktree，限定在明确信任的项目、并且开了功能开关的前提；终端状态用 OSC 7501 报出 idle、working、blocked；可选的输出回放用来做事后审计。

这些改动没有一个能让交互体验变好。它们全部服务于同一个场景，把 Codex 当成一个长时间运行、可以被观察的基础设施组件来用。

最后#

关于长任务，我现在的判断是，判断力还在人这边，而且比以前更吃重。

模型能连着跑 25 小时，说明"写"这个动作的边际成本在往下掉。“这 3 万行该不该合进去"的成本没有跟着掉。两边一升一降，瓶颈自然挪到了审查这一侧。

所以比起把任务写得更大，我更愿意先把停止条件写清楚。一个能自己停下的 agent，才敢让它跑过夜。

参考来源#

  • OpenAI Developers Blog，Run long horizon tasks with Codex：https://developers.openai.com/blog/run-long-horizon-tasks-with-codex
  • Tenten Developer，Codex’s Long-Running Agents Turn Autonomy Into an Operations Problem：https://developer.tenten.co/codex-long-running-agent-workflow
  • Developers Digest，Codex-Maxxing: How to Run Long-Running Codex Workflows Without Losing the Plot：https://www.developersdigest.tech/blog/codex-maxxing-long-running-workflows
  • Shattered，Claude Code, Codex CLI, OpenCode Update in 4 Days：https://shattered.io/claude-code-codex-cli-opencode-update-4-days-2026/