AI Agent 长任务中断后怎么恢复：断点续跑、上下文重建和检查清单

AI Agent 长任务中断后怎么恢复？最重要的一点是：不要急着让它“继续刚才的任务”。先保现场，再重建上下文，最后把下一步缩小成一个明确动作。

长任务中断很常见。可能是窗口关了、网络断了、额度到顶、上下文太长、电脑休眠、Agent 卡在工具调用、测试跑了一半失败，也可能是你临时打断了它。真正麻烦的不是中断本身，而是恢复时不知道它已经做了什么、哪些文件被改了、哪些验证跑过、哪些结论只是计划还没有执行。

这篇适合 Claude Code、Codex、Cursor、OpenCode、Devin、本地 Agent、带 MCP 工具的办公 Agent，也适合各种需要跨小时运行的研究、写作、代码迁移、数据整理和自动化任务。

快速结论

恢复长任务时，按这个顺序做：

先停止继续执行，不要立刻让 Agent 大范围重跑。
保存当前状态：文件改动、命令输出、任务列表、错误日志。
判断中断点：是在计划阶段、编辑阶段、测试阶段，还是发布阶段。
让 Agent 先复盘，不要先动手。
把下一步改成一个小任务，例如“只修复当前测试失败”。
验证已经完成的部分，避免重复覆盖。
恢复后尽快写 checkpoint，防止再次中断。

一句话：长任务恢复不是“接着跑”，而是“先验尸，再续命”。

为什么 AI Agent 长任务容易断

AI Agent 和普通聊天不同。它不只是回答问题，还会读取文件、执行命令、调用工具、等待权限、写入结果、运行测试、再根据反馈调整。

只要任务变长，就会出现几类风险：

上下文越来越大，模型开始遗漏早期约束；
工具输出太多，关键错误被日志淹没；
文件改动跨多个模块，恢复时很难判断进度；
测试或构建耗时长，中途失败后没有总结；
人工确认卡住，Agent 等待太久；
额度、网络、进程、浏览器或终端中断；
多个 Agent 并行工作，状态不一致；
恢复时重复执行危险命令。

所以，长任务最好一开始就设计成可中断、可恢复、可审计的流程。没有这种设计，也可以通过下面的步骤补救。

第一步：不要直接说“继续”

中断后最危险的提示词是：

1

继续刚才的任务

如果 Agent 仍然有完整上下文，这句话可能没问题。但如果上下文已经丢失、压缩、换窗口、换线程或换工具，它可能会猜测任务状态，然后重复修改、覆盖文件、重新跑昂贵命令。

更稳的恢复提示词是：

1
2
3
4
5
6


先不要修改文件。请根据当前工作区、已有日志和上下文，复盘这个长任务的状态：
1. 原目标是什么；
2. 已经完成了什么；
3. 哪些文件有改动；
4. 哪些验证跑过；
5. 当前最小安全下一步是什么。

先让它做状态盘点，再决定是否继续。

第二步：保留现场

如果是代码任务，先看工作区状态。

1
2
3


git status --short
git diff --stat
git diff

如果改动很多，不要马上格式化、重跑生成器或覆盖文件。先把 diff 保存下来：

1

git diff > agent-interrupted.diff

如果任务涉及命令输出，把关键日志单独保存：

1

npm test 2>&1 | tee last-test.log

如果是办公、研究、写作类 Agent，保存这些内容：

原始任务目标；
已收集的资料；
已生成的草稿；
Agent 的阶段性总结；
外部工具返回的结果；
未确认的假设；
下一步计划。

恢复时，最怕“以为已经完成”。保留现场就是给后续判断留证据。

第三步：判断中断发生在哪一层

长任务中断后，可以按这张表判断恢复方式。

中断位置	典型表现	恢复重点
计划阶段	只有方案，没有文件改动	重新确认目标和约束
搜索阶段	查了很多资料，但未整理	去重资料，确认可信来源
编辑阶段	文件已改，但未测试	先看 diff，再跑最小验证
测试阶段	测试失败或没跑完	只处理当前失败，不扩大范围
发布阶段	构建或部署中断	查发布日志和远端状态
多 Agent 阶段	多个分支结果不一致	先合并状态，不要直接套用结论

如果不确定，就把任务退回“复盘模式”。

第四步：让 Agent 生成恢复摘要

恢复摘要要短，但必须包含关键信息。

可以要求 Agent 输出这个格式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


## 恢复摘要

- 原始目标：
- 当前状态：
- 已完成：
- 未完成：
- 已改文件：
- 已运行验证：
- 失败/阻塞：
- 不应重复执行：
- 最小下一步：

这比让它写一大段“当前我们正在做……”更有用。后面如果再次中断，这份摘要可以直接作为新的起点。

第五步：把任务切小

长任务恢复后，不要马上回到原来的大目标。

错误做法：

1

继续完成整个迁移，并修复所有问题。

更好的做法：

1

只处理当前 diff 中已经改动的文件。先不要新增功能。请运行最小相关测试，找出第一个失败原因，并只修复这个失败。

恢复阶段的目标是重新获得控制感。先让 Agent 完成一个小闭环：

1

读状态 -> 做一个小改动 -> 跑一个小验证 -> 汇报结果

小闭环跑通后，再继续下一段。

第六步：避免重复执行

有些动作重复执行问题不大，例如读取文件、跑只读检查、生成摘要。

有些动作重复执行可能出事：

删除文件；
批量重命名；
数据库迁移；
发布部署；
发送邮件；
提交表单；
调用付费 API；
触发生产任务；
覆盖生成结果；
向外部系统写入数据。

恢复提示词里可以明确写：

1

恢复前请列出任何可能重复执行后产生副作用的动作。没有用户确认前，不要执行删除、发布、迁移、发送、付费调用或外部写入。

如果 Agent 能操作真实系统，这一步尤其重要。

第七步：用 checkpoint 防止二次中断

恢复成功后，立刻让 Agent 写 checkpoint。

可以放在项目根目录、任务目录、issue 评论、PR 描述、临时 Markdown 或当前对话里。

示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# Agent Checkpoint

时间：2026-07-10 11:39

目标：
- 完成用户资料导入流程重构。

已完成：
- 拆出 CSV parser。
- 增加字段校验。
- 更新导入页面文案。

当前改动：
- `src/import/parser.ts`
- `src/import/validate.ts`
- `tests/import-parser.test.ts`

验证：
- `npm test -- import-parser` 已通过。
- 全量测试未跑。

下一步：
- 修复 `validate.ts` 的边界条件测试。
- 再跑 `npm test -- import`.

不要重复：
- 不要重新生成 migration。
- 不要重新导入测试数据库。

Checkpoint 不需要长，但要让下一次恢复的人或 Agent 能接上。

代码任务的恢复提示词模板

可以直接复制这个模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


长任务刚才中断了。先不要修改文件，也不要运行有副作用的命令。

请先恢复现场：
1. 查看 git status 和当前 diff；
2. 判断任务处在哪个阶段；
3. 总结已完成、未完成、已改文件、已运行验证；
4. 标出任何不能重复执行的动作；
5. 给出一个最小安全下一步。

只有在我确认后，再继续执行。

如果你希望它直接进入小步恢复，可以这样：

1

长任务中断后恢复。请先读取当前工作区状态和 diff，然后只做一件事：找出当前最小相关测试命令并运行。不要新增功能，不要重构，不要提交。测试失败时只修复第一个明确失败。

写作和研究任务的恢复模板

写作、调研、竞品分析、资料整理也会中断。恢复时重点不是 diff，而是资料来源和结论状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


这个研究任务中断了。请先不要继续扩写正文。

请根据已有材料输出恢复摘要：
1. 研究问题是什么；
2. 已收集资料有哪些；
3. 哪些结论已有来源支持；
4. 哪些只是推测；
5. 哪些资料还缺；
6. 下一步应该先查什么。

输出后等待我确认。

如果已经有草稿：

1
2


请先审查当前草稿，不要扩写。
标出哪些段落有来源支撑，哪些段落需要补来源，哪些段落可能重复或偏题。

这样能避免中断后越写越散。

办公 Agent 的恢复模板

办公 Agent 可能接入日历、邮件、文档、Slack、Notion、飞书、工单系统。恢复时要特别注意权限和外部写入。

1
2
3
4
5
6
7
8


这个办公自动化任务中断了。恢复前请先列出：
1. 已读取哪些系统或文档；
2. 是否已经发送消息、创建任务、修改文档或提交表单；
3. 哪些动作只是草稿，哪些动作已经对外生效；
4. 下一步是否会写入外部系统；
5. 需要我确认的内容。

没有确认前，不要发送、提交、删除、邀请或修改外部系统数据。

办公场景里，“重复执行”比“少做一步”更危险。重复发邮件、重复建工单、重复改表格，都会造成真实影响。

用 Git 做恢复边界

如果是代码仓库，Git 是最好的恢复边界。

建议长任务开始前先确认：

1

git status --short

如果工作区不干净，先让 Agent 识别哪些改动属于当前任务，哪些是用户原有改动。

长任务中间可以阶段性提交，或者至少保存 patch：

1

git diff > checkpoint-001.diff

如果你不想提交，也可以用 stash 保存中间状态：

1

git stash push -m "agent checkpoint before test fix"

但要注意：stash 也可能把用户未完成改动混进去。多人协作或混合任务时，更推荐小粒度 commit 或 patch 文件。

使用 Codex 或 Claude Code 时的恢复习惯

如果你使用 Codex、Claude Code 这类 coding agent，可以把恢复流程写进项目规则或 skill。

例如，在 AGENTS.md 或团队规则里写：

1
2
3


长任务中断后，先做状态复盘，不要直接继续执行。
恢复时必须列出已改文件、已运行验证、当前阻塞和最小下一步。
任何删除、发布、迁移、外部写入、付费调用都需要用户确认。

如果你经常做同类恢复任务，也可以写成 Codex skill。前面这篇文章可以搭配阅读：Codex Skills 怎么写自己的工作流。

如果中断和 Hooks、测试输出、上下文膨胀有关，也可以参考：

这些文章关注点不同，但都指向同一个问题：Agent 长任务不能只靠一句“继续”，而要有可恢复的工作流。

恢复检查清单

可以把下面这张表保存下来。

检查项	要问的问题
目标	原始任务是什么，是否变化过
状态	当前处于计划、编辑、测试还是发布阶段
文件	哪些文件已改，哪些文件不该碰
日志	最近一次失败输出是什么
验证	哪些测试通过，哪些没跑
外部系统	是否已经发送、提交、发布或写入
风险	哪些动作不能重复执行
下一步	最小安全动作是什么
记录	是否写了 checkpoint

如果 Agent 连这张表都填不清楚，就不要让它继续大范围执行。

常见错误

一恢复就让 Agent 全量重跑

这会浪费时间，也可能覆盖已有结果。先确认状态，再选择最小命令。

只看 Agent 的口头总结

Agent 可能记错。代码任务要看 diff 和测试；研究任务要看来源；办公任务要看外部系统是否已经写入。

没区分计划和执行

Agent 说“我会创建文件”不代表文件已经创建。恢复时要区分“计划过”“尝试过”“已经完成”。

忽略用户原有改动

工作区可能本来就有用户改动。恢复时不要默认所有 diff 都是 Agent 产生的。

没有停止条件

长任务恢复后，还要设置新的停止点。例如“修复第一个测试失败后停下汇报”，而不是继续无限探索。

总结

AI Agent 长任务中断后，恢复的关键不是让它马上继续，而是先把状态重新变清楚。

先保现场，确认 diff、日志、资料和外部系统状态；再让 Agent 输出恢复摘要；接着把下一步缩小成一个低风险动作；最后写 checkpoint，为下一次中断做准备。

只要任务能被分段、能被验证、能被记录，中断就不再是灾难。真正危险的是没有状态、没有边界、没有检查，恢复时全靠 Agent 猜。