最近用ChatGPT、Codex处理复杂项目时，我越来越明显地感觉到一个变化：

Agent能够连续执行的任务越来越长了。

以前很多AI任务很短：看一个报错、改一个函数、补几条测试，十几分钟就结束。即使失败，重新跑一遍成本也不高。

但现在的Agent越来越像真正的执行者。一次任务里，它可能连续读项目、分析依赖、修改多个文件、运行测试、修复失败，再继续下一步。

这时候一个过去不明显的问题开始变得重要：

如果Agent已经做到80%，最后一步失败了，前面的工作还能不能留下来？

如果答案还是“重新开始”，那么Agent越能跑长任务，失败成本反而越高。

所以随着ChatGPT、Codex开始承担更长、更复杂的任务，一个新的基础能力会越来越重要：

Recoverable Execution——可恢复执行

也就是：

任务中途失败以后，可以从一个可信状态继续，而不是全部归零。

---

一、长任务真正放大的，是失败成本

一个3分钟的Agent任务失败，重新跑一次问题不大。

但如果一个任务已经执行了40分钟：

读了几十个文件。

定位了根因。

修改了代码。

跑过几轮测试。

排除了几个错误方向。

最后因为测试环境异常、网络中断或者工具超时而停止。

如果下一次还要重新读项目、重新分析、重新验证，浪费的就不只是40分钟。

更重要的是：

前面建立起来的任务理解和Evidence也一起丢了。

长任务步骤越多，外部依赖越多，中间出现异常的概率也会不断累积。

所以以后衡量Agent长任务能力，不能只看：

“它能连续跑多久。”

还要看：

“它失败以后能不能回来。”

---

二、为什么Checkpoint会越来越重要？

现在很多Agent任务已经不是“一次回答”。

而是：

计划 → 执行 → 看结果 → 调整 → 再执行 → 验证。

在这个过程中，Agent会形成大量中间状态。

例如：

哪些文件已经检查。

根因定位到了哪里。

哪些修改已经完成。

哪些测试已经通过。

哪些假设已经排除。

下一步准备做什么。

如果这些信息只存在于当前聊天上下文里，一旦任务中断，就很容易重新开始。

所以长任务真正需要保存的，不只是代码。

还要保存：

任务现在到底处于什么状态。

这就是Checkpoint的价值。

---

三、Checkpoint到底应该保存什么？

不需要非常复杂，至少要有四类信息。

第一是：

任务目标。

Agent到底在解决什么问题，避免恢复以后方向漂移。

第二是：

已经完成的步骤。

例如：

问题已复现。

根因已确认。

代码已修改。

单测已通过。

集成测试未完成。

第三是：

当前代码和环境状态。

比如当前Commit、修改过哪些文件、依赖版本、哪些Diff还没有验证。

第四是：

Evidence和下一步。

不仅记录“根因已找到”，还应该记录：

为什么确定是这个根因。

恢复以后第一步应该做什么。

这样Agent重新进入任务时，就不需要重新猜一次。

---

四、为什么不能简单“从最后一步继续”？

因为任务中断以后，外部环境可能已经变化。

比如：

代码被别人提交了新版本。

依赖发生变化。

测试数据库被重置。

远程环境重新部署。

外部API状态改变。

如果Agent直接从上一次停止的位置继续，很可能建立在已经失效的前提上。

所以真正可靠的恢复应该是：

Revalidate → Resume

也就是：

先验证，再继续。

例如恢复以后先检查：

当前Commit有没有变化。

关键文件有没有被修改。

依赖是否一致。

测试环境是否仍然有效。

之前的Evidence是不是还成立。

确认这些前提以后，再执行剩余步骤。

所以好的Checkpoint保存的并不只是：

“做到第几步。”

而是：

“为什么现在可以从这里继续。”

---

五、任务拆分会变得越来越重要

如果任务一开始就是：

“把这个项目的问题全部处理好。”

那么恢复会非常困难。

更合理的长任务结构应该是：

复现问题
→ 定位根因
→ 修改代码
→ 单元测试
→ 集成验证
→ 输出结果

每完成一个独立阶段，就形成一个自然Checkpoint。

这样如果集成测试阶段失败：

不需要重新从复现问题开始。

所以以后任务拆分的价值，不只是让Agent更容易理解Prompt。

更重要的是：

让任务本身拥有可以恢复的位置。

通常最值得建立Checkpoint的地方有三类：

完成一个独立阶段以后。

进入高风险修改之前。

以及大型测试、CI、远程环境等高失败概率步骤之前。

不需要每一步都记录，但关键节点不能完全依赖聊天上下文。

---

六、长任务状态不能一直藏在对话里

随着Agent任务越来越长，单纯依赖聊天上下文会出现一个问题：

过程信息越来越多，真正重要的状态反而容易被淹没。

所以更成熟的Agent Workflow，很可能会把任务状态单独保存。

例如：

当前状态：验证中

已完成：
- 复现问题
- 定位根因
- 修改代码
- 单元测试

待完成：
- 集成测试

当前版本：
abc123

这种结构化状态比重新翻整个对话有效得多。

尤其是任务跨会话、跨时间甚至跨执行环境以后：

Task State会越来越像Agent基础设施的一部分。

---

七、可恢复执行还能降低人工接管成本

Agent长任务失败以后，有时候并不是立刻让Agent继续，而是开发者先接手。

如果没有Checkpoint，人需要重新搞清楚：

Agent为什么这样改。

已经做过哪些验证。

哪些方向已经排除。

剩下什么风险。

这本身就是很大的理解成本。

但如果Checkpoint已经记录清楚：

当前状态、Evidence、已完成步骤和下一步，

人接手会快很多。

处理完以后，还可以重新把任务交给Agent继续。

所以可恢复执行解决的不只是：

Agent失败以后自己恢复。

它还解决：

Agent → 人 → Agent

之间的任务交接。

---

八、为什么这会成为Agent的新基础能力？

未来真正值得交给ChatGPT、Codex的任务，很可能越来越不是：

生成一个函数。

而是：

复杂Bug修复。

跨文件修改。

依赖升级。

项目迁移。

大型测试。

长期重构。

这些任务天然具有：

步骤多、持续时间长、外部依赖多的特点。

如果每次中断都必须全部重来，那么Agent长任务能力越强，失败时浪费也越大。

所以真正成熟的Agent系统不能只追求：

更长时间不停地跑。

还必须具备：

失败以后保住已有工作。

---

九、给自己测一个指标：可恢复任务率

这篇只看一个指标：

Recoverable Task Rate——可恢复任务率

统计最近一段时间的长Agent任务。

例如最近20个长任务里：

有12个中途失败以后，可以从可信Checkpoint继续，而不需要重新从头理解项目。

那么：

可恢复任务率 = 60%。

这个指标反映的不是Agent有多聪明。

而是：

任务失败以后，之前完成的工作还能保留多少。

如果低于40%，说明大量长任务一旦失败，就会重新读、重新分析、重新验证。

这个阶段最应该补的是：

任务拆分。

Checkpoint。

Evidence记录。

恢复前验证。

如果在40%—70%，可以重点找出最容易失败的环节，例如大型测试、CI、依赖安装和远程工具，在这些位置增加恢复点。

如果长期超过70%，说明大部分长任务即使中断，也能够稳定继续。

这时候Agent的长任务能力才真正开始成熟。

---

十、怎么提高可恢复任务率？

其实先做四件事就够了。

第一，把长任务拆成阶段。

不要让Agent一次性承担一个没有边界的大任务。

第二，在关键阶段保存Checkpoint。

明确：

已经完成什么。

当前状态是什么。

下一步是什么。

第三，恢复前重新验证关键状态。

不要盲目Resume。

先确认代码、环境、依赖和数据状态有没有变化。

第四，保存Evidence，而不是只保存结论。

不要只记录：

“根因已经找到。”

还要保存：

为什么确认这个根因。

这样恢复以后才不会把已经排除的问题再查一遍。

---

十一、Plus和Pro怎么判断？

如果你的可恢复任务率还比较低：

Agent长任务一失败，就要重新读项目、重新分析、重新跑测试，

那当前真正限制效率的不是AI容量。

而是：

任务执行机制还不能稳定恢复。

这种阶段Plus通常已经够用。

先把：

Checkpoint、任务拆分、状态保存和恢复验证

做好，收益往往更大。

否则即使提高AI容量，也只是让Agent更快地重复已经做过的工作。

如果你的可恢复任务率已经比较高：

任务中断以后能够稳定Resume。

Evidence可以继续复用。

人工接管以后也能顺利重新交还Agent。

同时大量成熟任务长期排队，AI容量真正开始限制吞吐，

这时候Pro才更容易放大效率。

因为增加的是：

可持续、可恢复的Agent执行能力。

---

最后

ChatGPT、Codex越来越能长时间自己跑以后，我们很容易只关心：

它能不能运行更久。

能不能一次完成更多步骤。

但真正决定长任务价值的，可能是另一个问题：

失败以后，前面的工作还能不能留下来。

一个跑5分钟的Agent，从头再来问题不大。

一个跑1小时的Agent，如果每次失败都清零，自治能力越强，失败成本反而越高。

所以Agent进入长任务阶段以后：

Checkpoint、Task State、Evidence保存、Resume、恢复前验证，

这些过去看起来只是执行细节的东西，会越来越接近真正的基础设施。

真正成熟的Agent，不只是能够一直跑到底。

还应该做到：

中途停下来以后，知道自己做到哪里，并且能够从可信状态继续。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。