使用 AI Agent 处理大型开发任务时，经常会碰到一个很现实的问题：

任务已经执行了很久，中途一旦断掉，后面就很难无缝接着做。

常见情况包括：

• Agent已经修改了多个文件，任务却意外中止；

• 工具调用失败后重新开始，Agent不知道前面做到哪一步；

• 会话中断以后，又重新扫描整个项目；

• 已经解决的问题再次被修改；

• 前面运行过的测试又重复执行；

• 恢复任务以后，后半段思路和前半段不一致。

这种问题表面看起来像：

上下文没有保存好。

但更深一层的问题其实是：

长任务缺少明确的状态记录。

如果整个任务进度只存在于Agent当前对话里，一旦执行链路中断，恢复成本就会很高。

---

一、长任务为什么特别容易出现“恢复困难”？

一个简单任务可能只有：

修改一个函数
↓
运行测试
↓
完成

即使中断，重新开始的成本也不高。

但复杂任务可能是：

分析项目
↓
定位调用链
↓
修改模块A
↓
修改模块B
↓
增加测试
↓
发现新问题
↓
继续修改
↓
运行Build

执行到第六步突然停止以后，新Agent需要知道：

• 原始问题是什么；

• 前面发现了什么；

• 哪些步骤已经完成；

• 哪些修改只是临时尝试；

• 哪些测试已经通过；

• 下一步准备做什么。

如果这些信息没有明确保存，就只能重新推理。

---

二、“记住任务目标”还不够

例如原始任务是：

修复用户模块的并发问题。

这个目标即使还在，也不能告诉Agent：

目前任务进行到了什么状态。

长任务至少存在两类信息：

目标状态

最终要解决什么问题？

执行状态

目前已经完成什么？
下一步要做什么？

很多Agent恢复失败，就是因为只保存了第一类。

于是恢复以后知道：

我要修这个Bug。

却不知道：

前面其实已经找到根因并改完一半了。

---

三、Checkpoint就是给任务建立“存档点”

可以把Checkpoint简单理解成：

Agent任务的阶段性存档。

例如：

Checkpoint 1
完成问题定位

Checkpoint 2
完成核心代码修改

Checkpoint 3
完成测试修复

Checkpoint 4
完成最终验证

每到一个关键阶段，都留下当前状态。

这样即使后面中断，也不需要从头重新理解整个任务。

---

四、一个有效的Checkpoint应该记录什么？

至少可以包含以下几类信息。

1. 当前任务目标

例如：

修复订单重复创建问题

2. 已完成内容

已定位到retry逻辑
已增加idempotency key检查

3. 已修改文件

src/order/service.ts
src/order/controller.ts

4. 已执行验证

order.service.test.ts 已通过

5. 当前未解决问题

E2E测试仍然失败

6. 下一步动作

继续检查测试环境中的数据库清理逻辑

这比简单记录一句：

任务进行中。

有用得多。

---

五、为什么只依赖聊天记录不够？

因为Agent执行复杂任务时，真正重要的信息可能散落在：

• 对话；

• Terminal输出；

• Git Diff；

• 测试日志；

• 文件修改；

• Agent内部的阶段判断。

即使对话仍然存在，也不代表恢复时能快速重建完整状态。

更稳定的做法是：

把关键任务状态压缩成结构化Checkpoint。

例如：

当前状态：

根因：
xxx

已修改：
xxx

验证结果：
xxx

未完成：
xxx

下一步：
xxx

恢复时直接读取这份状态，比重新分析几十轮执行记录高效得多。

---

六、阶段性Commit也是一种非常实用的Checkpoint

如果任务比较长，可以在明确完成一个阶段以后创建阶段性Commit。

例如：

commit 1：完成接口层调整
commit 2：完成数据库逻辑修改
commit 3：补充测试

它的价值不只是保存代码。

还可以明确：

哪些修改已经形成一个稳定状态。

如果后面的实验失败，可以更容易：

• 查看差异；

• 回退；

• 对比；

• 恢复。

相比所有改动最后堆在一个巨大Diff里，长任务更适合分阶段留下清晰边界。

---

七、Checkpoint不能只是“保存文件”

假设Agent已经修改了：

service.ts
controller.ts
test.ts

这些文件都还在。

这并不代表任务状态已经保存完整。

因为新的Agent仍然不知道：

为什么这样改？

所以Checkpoint最好同时保留：

代码状态 + 决策状态。

例如：

选择方案B，因为方案A会破坏旧接口兼容性。

这种信息单纯从最终代码里未必能快速看出来。

---

八、恢复任务时不要直接继续修改代码

任务中断后，一个常见错误是：

重新打开Agent
↓
马上继续改文件

更稳的恢复流程应该是：

读取Checkpoint
↓
检查Git状态
↓
确认当前Diff
↓
确认测试状态
↓
再继续任务

可以先让Agent回答：

当前任务目标是什么？
已经完成到哪一步？
现在有哪些未提交修改？
哪些测试已经执行？
下一步应该做什么？

确认这些信息一致，再继续执行。

---

九、为什么恢复时很容易“重复工作”？

如果Agent不知道哪些步骤已经完成，它可能重新：

扫描项目
↓
重新搜索调用链
↓
重新修改同一段代码
↓
重新运行完整测试

不仅浪费时间，还可能出现更严重的问题：

把前面已经正确的实现再次改掉。

所以Checkpoint的作用不仅是加快恢复。

还可以避免：

重复探索和重复修改。

---

十、长任务最好拆成阶段，而不是一个巨大目标

例如不要只给：

重构整个用户权限系统。

可以拆成：

阶段1：分析现有权限调用链
阶段2：完成权限判断重构
阶段3：迁移相关调用方
阶段4：补充测试
阶段5：执行完整验证

每完成一个阶段，都更新一次任务状态。

这样Agent即使在第四阶段断掉，也能知道：

前三阶段已经完成，不应该重新推翻。

任务拆分的价值不仅是让AI更容易理解。

也让任务变得：

可暂停、可恢复、可检查。

---

十一、可以让Agent定期输出恢复信息

处理长任务时，可以直接要求：

每完成一个主要阶段，请输出一次Checkpoint，包含：

1. 当前目标；
2. 已完成步骤；
3. 修改过的文件；
4. 已执行的测试和结果；
5. 当前未解决问题；
6. 下一步计划；
7. 当前Git状态或Commit。

如果任务突然中断，下一次执行就可以从最后一个Checkpoint继续。

而不是：

重新从项目根目录开始理解。

---

十二、Agent越自主，任务状态管理越重要

短任务时代，开发者一直参与：

AI建议
↓
开发者操作
↓
继续提问

开发者本人就是任务状态的“记忆”。

但Agent开始自主执行：

分析
↓
修改
↓
测试
↓
继续修复
↓
再次验证

可能很长时间不需要人工介入。

这时候如果Agent自己没有留下Checkpoint，一旦中断：

整个执行链的状态就很容易丢失。

所以Agent能力越强，任务管理反而越重要。

---

最后

AI Agent长任务中途断掉后很难继续，本质上不是简单的：

上下文不够长。

真正的问题是：

任务状态没有被显式保存。

更稳定的长任务工作流应该是：

任务拆阶段 → 阶段完成 → 创建Checkpoint → 保存修改与验证状态 → 再继续执行。

这样即使Agent、工具或者会话中途停止，也可以快速回答：

我已经做到哪里了？

真正成熟的Agent开发流程，不应该要求任务：

永远不能中断。

而应该做到：

即使中断，也可以从明确的状态继续。

当Agent开始承担几小时甚至更长的开发任务时，Checkpoint、阶段性Commit和任务恢复机制，会越来越像测试和Git一样，成为自动化开发流程里的基础能力。

---

持续更新 Codex、Claude Code、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。