Agent 有记忆，和任务能恢复，是同一回事吗？
讨论 Agent 时，“有记忆”很容易让人想到它记得以前说过的话。但当任务执行到一半，服务重启之后还能不能继续，是另一个需要检查的问题。
我用整理 Notion 草稿的流程，区分几种容易混在一起的信息。
对话历史：刚才聊了什么
对话历史帮助模型理解当前交流。例如，我先要求写一篇文章，再补充“语气自然一点”，下一次生成需要知道这句话指的是哪篇文章。
保存历史并不代表每次都要把全部内容放进提示词。系统仍然需要决定读取哪些信息，以及什么时候摘要或裁剪。
任务状态：事情做到了哪里
任务状态记录的是执行进度。例如，资料已经读取，草稿已经生成，当前在等待确认。
恢复任务时，我需要知道已经完成哪些步骤、哪些结果可以复用，以及哪里需要重新检查。只读聊天记录，未必能可靠得到这些信息。
在 LangGraph 中，checkpointer 用于保存一个 thread 的图状态快照；store 则保存应用定义的跨 thread 数据，例如用户偏好。它们承担不同范围的记忆。官方持久化文档
长期偏好：以后也希望记住什么
“技术文章尽量保留来源”“发布之前让我看一下”，可以作为后续任务参考的偏好。
但这些偏好不应该和某次任务进度混在一起。“已经保存到页面 A”是执行记录，“中文是默认写作语言”则可以跨任务使用。
长期信息还需要更新与删除。用户改了偏好，系统应当以当前指令为准，不能一直沿用旧记录。
放在内存里，重启后就可能没有了
一个演示程序可能在内存里维护历史和状态，运行期间看起来一切正常。进程退出后，这些数据却未必保留。
官方文档说明，InMemorySaver 的 checkpoint 保存在 RAM，进程重启会丢失。因此，“能在同一进程继续聊天”和“重启后能恢复任务”，需要分别验证。
我会用具体动作检查：执行到某一步，停止程序，重新启动，确认是否能读回原来的任务与中间结果。
最容易忽略的情况：写入成功了，但响应丢了
下面是设计情形，不是项目的实际失败日志：
提交保存请求 → Notion 已经创建页面 ↓ 客户端没有收到成功响应 ↓ 恢复任务后准备再次写入
这时，恢复状态还不够。系统需要确认外部操作是否生效，否则可能创建两份页面。
我会考虑为操作保留唯一标识、目标位置和返回的页面 ID，并在重试之前查询已有结果。如何实现，还要依据外部 API 能力与具体任务来验证。
我会怎样检查“可恢复”
我想分别测试读取失败、生成后中断、保存时超时，以及人工取消。它们需要不同的处理方式。
读取失败可能重试；已经生成的草稿可以复用；写入超时需要确认结果；用户取消则应停止后续动作。
这些是我完善 Agent 的验收思路，不代表自己的项目已经全部实现。
当我再看到“有记忆”这个描述，会继续问：记住的是什么，保存在哪里，什么时候读取，重启之后还在不在，外部操作会不会重复。这些问题更接近我真正需要的能力。