26 状态、记忆与恢复¶

难度：中高级｜前置：Workflow、状态机、幂等｜目标：让长任务在暂停、故障和重启后继续

四种不同的信息¶

不要都叫“Memory”：

类型	示例	存储建议
当前任务状态	当前步骤、工具结果	Checkpoint/数据库
短期对话	本轮上下文	消息历史、摘要
用户长期偏好	输出语言、格式	独立用户配置
业务事实	设备、工单、权限	业务数据库

业务事实不应该只存在模型上下文。

Checkpoint¶

每个重要步骤后保存状态：

{
  "task_id": "t-123",
  "step": "collect_alarm",
  "status": "completed",
  "output_ref": "result-456",
  "prompt_version": "v3",
  "model": "model-x"
}

重启后从最后一个成功边界继续。

恢复不是简单跳到下一步¶

恢复前要确认：

上一步是否真的完成；
工具结果是否保存；
外部副作用是否发生；
输入和代码版本是否兼容；
是否需要重新验证权限；
任务是否已被取消。

人工中断¶

生成操作计划
→ 保存 checkpoint
→ waiting_approval
→ 人工批准/修改/拒绝
→ 恢复执行

恢复可能从节点开头重新执行，因此中断之前的副作用必须幂等，或拆到单独节点。

上下文压缩¶

不要永久保存所有推理过程并全部塞回模型。保留：

用户目标；
已确认事实；
决策和结果；
未完成事项；
必要引用。

丢弃：

重复内容；
无用工具原始响应；
已被总结的冗长历史；
不应长期保存的敏感数据。

自测¶

任务状态、对话历史和业务事实为什么要分开？
Checkpoint 后恢复前还要检查什么？
人工中断前为什么要避免非幂等副作用？
上下文摘要可能丢失什么？

完成标准¶

能划分四类状态与存储
能设计 checkpoint 内容
能画出审批暂停与恢复
能说明上下文压缩策略

延伸阅读：LangGraph Persistence、Interrupts

下一单元：Agent Eval