AI 跑到一半断了，为什么不能直接说「继续」

让 AI 回答一个问题，中途断网，重新问一遍通常没什么损失。让它连续干半小时活，情况就不同了。

假设我请它整理一批公开教程：下载资料，提取目录，做成一份索引，再上传到共享文件夹。进度已经走到上传，界面突然不动了。重新打开会话，我最想说的当然是：继续。

但这两个字藏着好几个问题。下载的文件还在吗？索引写完了吗？刚才的上传只是没开始，还是已经完成、只是回执没回来？

聊天能接上，和工作能接上，是两件事。我觉得这是理解长任务 Agent 很关键的一道坎：它需要保存的不只是“我们说过什么”，还包括“外面的世界已经被改成了什么”。

先分清，究竟是哪一部分断了

我会把这类任务拆开看。模型负责判断下一步；外面的程序负责调用模型、执行工具、把结果送回来；一个具体的运行环境负责存临时文件、跑脚本。还有一份记录，保存任务的目标和经过。

这几样东西可以住在一起，也可以分开。

Anthropic 在 2026 年 4 月的 Managed Agents 工程文章中，介绍了将执行环境、控制循环和持久会话日志分离的做法：执行环境失效，可以作为一次工具失败处理；控制循环崩溃，则可以重新读取外部保存的事件记录。这篇旧文给我的启发是，别让一台临时机器成为整个任务唯一的记忆。

下面的资料整理例子，是我用来说明恢复边界的假设场景，不是对某个产品恢复能力的承诺。

如果只是浏览器断线，后台任务可能还在运行。这时候再开一个任务，反而可能让两份工作同时进行。如果执行脚本的环境消失了，重新连上聊天也不会让临时文件自动回来。如果控制程序停止了，磁盘上的索引又可能完好无损，只是没人接着上传。

所以我不会先问“模型还能不能记住”，而会先问：谁停了，谁还活着，东西存在哪？

一段漂亮摘要，不能替代一份成果

想象新会话拿到这样一段交接：“已完成资料整理，正在上传，接下来通知用户。”看起来够清楚，实际上最重要的信息全空着。

“完成”指写出了文件，还是校验过每条链接？文件在哪个目录？对应哪一批输入？如果目录属于上一次已经销毁的环境，这个路径还有什么用？

我更希望看到的是一张很朴素的任务卡：

任务：demo-guide-index-01
目标：整理指定的 12 份公开教程
限制：只使用公开内容，不发送通知
输入：来源清单 v1，保存在持久目录
成果：index.md，已保存；条目数 12
校验：链接检查通过 11 条，1 条需人工复核
上传：已发起，尚未取得可确认的结果
下一步：查询目标目录，核对同一份文件是否存在

这里的数字只是示例。真正有价值的是，它没有用一个“已完成”盖住所有步骤。

任务卡仍然不是证据本身。新会话要能打开那份文件、找到来源清单，必要时重新运行检查。记录里写着“12 条”，文件却只有 9 条，就应该回到文件查原因，不能为了沿用摘要而宣布成功。

反过来也一样：摘要过时了，但目标目录里已经存在正确文件，就不该再做一份。恢复时，记录负责带路，实际成果负责作证。

最危险的状态，叫“可能已经成功”

我以前容易把工具报错理解成“这一步没做成”。对纯计算，这种直觉往往没问题；对上传、发消息、创建记录，就不够用了。

还是那次上传。请求离开本机，文件已经存到了目标目录，服务器也生成了成功回执。但回执在路上丢了，调用工具等到超时。

从 Agent 这边看，它收到的是失败；从目标目录看，文件已经存在。两边并不矛盾：失败的是拿到确认这件事，不一定是上传这件事。

如果恢复逻辑只有“报错就再来一次”，而上传操作每次都新建文件，文件夹里就可能出现两个内容相同的副本。换成发送通知，别人就会收到两封一模一样的消息。

因此我会把状态至少分成三种：确认没做、确认做了、结果不明。第三种要单独留下来，不能硬塞进失败。

能查询时，先用任务编号、目标路径、内容摘要等线索找结果。目标系统如果支持幂等键，可以让同一次操作的重试沿用同一个键，但具体去重范围和有效期还得看它的规则。如果既查不到结果，又没有可靠的去重机制，重要操作就应该停在“待核实”，而不是让 AI 猜一次。

恢复应该从检查点开始，不是从第一句开始

对这份教程索引，我会把工作划成几个小段：来源清单已保存、原始资料已保存、索引已生成、校验已完成、上传已确认。

每段结束时，把可复用的成果写到不会随临时环境一起消失的位置，再记录它在哪里、对应什么输入。这样换了执行环境，至少可以从最近一个经过验证的成果往下做。

不过，检查点也有边界。上次索引基于清单 v1，这次用户已经删掉两份资料，就不能继续拿旧索引上传。任务卡里保存输入版本，正是为了发现这种变化。恢复时先比输入，再看成果，最后才决定哪些步骤可跳过。

并不是每个动作都值得单独保存。提取一个标题失败，重做很便宜；下载一批大文件花了半小时，保留下载结果就很划算。我更愿意把检查点放在耗时大、成果稳定、后续容易核验的位置。

还要防另一种情况：旧任务只是卡住，新任务已经接手。恢复机制如果允许两个执行者同时上传，同样会重复。系统需要确保同一任务在同一时刻只有一个有效执行者；普通使用者做不到这一层，也至少该先确认旧任务是否结束，再启动替代任务。

普通人怎么把任务交代得更容易恢复

不自己开发 Agent，也能把要求写得更具体。我会在长任务前补上一小段：

每完成一个阶段，把成果保存到指定目录，并更新进度文件。记录输入、成果路径、已做检查和未确认事项。中断后先检查现有成果，再继续。涉及外部写入，结果不明时先查询，不要直接重复执行。

这段话不能凭空给工具增加持久存储，也不能保证模型次次遵守，但它让恢复所需的信息有了明确的去处。工具不支持的部分，应当在开工前暴露出来。

验收时我也会多问一步：“如果现在关掉执行环境，下一个会话靠什么接着做？”如果答案只有“聊天里都说了”，说明任务还很依赖那一刻的现场。

我希望 AI 越来越能独立做长任务。不过，比起一次跑很久，我更在意它能不能在中断后说明白：哪些东西已经留下，哪些动作还没确认，下一步凭什么安全地继续。

能把这些交代清楚，“继续”才不只是重新开始的另一种说法。