ChatGPT、Codex 和 AI Agent 执行短任务时，表现已经足够好。

写个函数。
改个样式。
查个报错。
总结个文档。

这类任务有一个共同点：一次性完成，不需要记忆。

但真实世界的任务，很少是一次性的。

重构一个模块，要改十几个文件。
分析一个系统，要读几十份文档。
上线一个功能，要经过拆解、编码、测试、审查、发布。
处理一个工单，要跨多个系统来回确认。

任务一旦变长，一个新问题就出现了：

AI 做到一半，忘了自己在干什么。

长任务的失败，往往不是能力问题，而是状态问题

观察 AI Agent 执行长任务的失败案例，很少是"这一步不会做"。

更多的是：

改了第八个文件，忘了第一个文件的设计约定。
执行到第三阶段，把第一阶段已经否决的方案又提了回来。
中途被一个新信息带偏，偏离了最初的目标。
多轮对话之后，把旧结论当成新事实。
任务中断重开，完全从头再来一遍。

这些不是智力不足。
这是状态管理失败。

传统程序有调用栈，AI 有什么

传统程序执行长任务时，状态是明确的：

程序的状态
├── 调用栈：执行到哪个函数
├── 局部变量：当前的中间结果
├── 堆内存：持久的数据结构
└── 断点：随时可以暂停和恢复

任何一个环节中断，调试器都能告诉你：执行到哪了，变量是什么，下一步是什么。

但 AI Agent 的状态在哪里？

它散落在对话历史里。
混杂在上下文窗口里。
依赖模型的注意力去"回忆"。

上下文窗口不是状态存储。
它只是状态的一块易失的投影。

窗口满了，旧状态被挤出去了。
注意力飘了，关键状态被忽略了。
会话断了，状态直接蒸发了。

状态工程：把"进行到哪了"从模型脑子里搬出来

工程化的解法，是给任务建立一个显式的状态结构：

TaskState
├── goal           任务的最终目标
├── plan           拆解后的步骤清单
├── progress       当前执行到第几步
├── decisions      已经做过的关键决策及原因
├── rejected       已经否决的方案及原因
├── artifacts      已产出的中间结果
├── open_issues    尚未解决的问题
└── next_action    下一步要做什么

这个结构，存在模型之外。

每完成一步，更新一次。
每次中断，从这里恢复。
每轮执行前，先读状态，再干活。

ChatGPT 不再需要"记住"一切。
它只需要在执行时读取一份永远最新的任务档案。

检查点：长任务的"存档机制"

玩游戏的人都有一个直觉：打大 Boss 之前要存档。

AI 执行长任务，同样需要检查点。

Checkpoint
├── 阶段产出已验证 → 存档，进入下一阶段
├── 阶段产出未验证 → 不存档，先验证
└── 执行出错 → 回滚到上一个存档点

没有检查点的 Agent，出错之后只有两个选择：将错就错，或者推倒重来。

有检查点的 Agent，可以精确回滚到"最后一个可信状态"，从那里继续。

这个机制对 Codex 尤其重要。

代码任务天然适合检查点：
每改完一个逻辑单元，跑一次测试。
测试通过，提交一个 commit。
commit 就是存档。
测试失败，reset 回去。

Git 本来就是程序员的检查点系统。
AI 编程要真正工程化，就必须让 Codex 学会用这套机制管理自己的任务状态。

状态污染：比状态丢失更隐蔽的敌人

状态丢失是显性的，任务做不下去，你能发现。

状态污染是隐性的，任务还在继续，但状态已经坏了。

典型场景：

前面探索阶段试过三个方案，对话历史里全是旧方案的残留。
后面执行时，模型把三个方案的碎片拼在一起，生成一个"缝合怪"。

或者：

某个中间结论当时是假设，后来被证伪了。
但它还留在上下文里，模型继续把它当事实引用。

防污染的原则只有一条：

进入新阶段之前，做一次状态压缩。

把"已验证的结论"提炼出来。
把"探索过程的垃圾"清理出去。
给模型的不是全部历史，而是一份干净的当前状态。

写在最后

ChatGPT 的上下文窗口会越来越大。
但窗口再大，也改变不了一个事实：

靠模型记住状态，是易失的。
靠系统管理状态，才是可靠的。

长任务时代，AI 系统的差距不在单次生成的质量。
在于谁能连续执行十步、一百步之后，依然清楚自己在干什么、为什么这么干、下一步干什么。

模型决定 AI 的智力上限。
状态工程决定 AI 的任务续航。

未来优秀的开发者，不只是会启动一个任务的人。
而是能为任务建立状态、设置检查点、设计恢复机制的人。

生成是一瞬间的事。
状态是全过程的事。