LangGraph 持久化执行：服务重启后如何恢复 Agent？

上一小节，咱们通过 DDD 理清了演示文稿制作过程中的业务对象、状态和规则。

比如，大纲已经生成到 v2，那么当前有效版本就应该是 v2；大纲还没有通过审核，系统就不能开始制作页面。

但是，这些规则能正确执行，还有一个前提，那就是：应用程序得知道这项任务已经执行到哪里了。

假设，当前流程是这样的：整理制作要求 → 生成演示文稿大纲 → 保存大纲草稿

前两步已经完成，执行到“保存大纲草稿”时，存储服务突然报错，程序直接崩了。

服务重新启动以后，接下来应该执行什么？

如果应用程序从头开始运行，就会再次整理要求、再次调用模型生成大纲，然后再尝试保存。

这样会产生两个问题。

前面已经完成的工作被重复执行了，那就会浪费很多 Token

更麻烦的是，大模型生成内容本身具有一定的随机性。即使输入完全一样，第二次生成的大纲也可能和第一次不同。服务重启一次之后，用户最后看到的内容可能就会发生变化。

那么想要解决这个问题，就要用到这一小节的讲的东西了，也就是：Durable Execution 持久化执行。

持久化执行到底是什么

咱们可以先这样理解：

持久化执行，就是把工作流已经完成的状态和下一步任务保存下来。程序中断以后，再从最近一次可靠保存的位置继续执行。

比如咱们刚才的流程是：整理制作要求 → 生成演示文稿大纲 → 保存大纲草稿

那么持久化了之后，就会变成：

→ 整理制作要求
→ 保存当前 State
→ 生成演示文稿大纲
→ 保存当前 State
→ 保存大纲草稿时失败
→ 进程结束

重新启动服务
→ 读取最近一次保存的 State
→ 继续执行“保存大纲草稿”

这样写可能有点长，给大家用一张图来表示

这样做的话，“整理制作要求”和“生成演示文稿大纲”已经完成并保存，恢复时就不需要重新执行。

所以，持久化执行的关键就是保存两类信息：

• 任务已经产生了哪些结果
• 接下来还需要执行哪个步骤

只要这两类信息没有随着