LangGraph 的 Checkpointer 和 Store 有什么区别？
🧑💻 面试官：LangGraph 里配了 Checkpointer，是不是就有长期记忆了？
🙋♂️ 我：不完全是。Checkpointer 主要保存某个 thread 运行过程中的图状态，让同一任务可以恢复。跨会话使用的用户偏好、长期资料，通常要用 Store 或另外的业务存储。
🧑💻 面试官：用户今天聊一半，明天回来继续，应该用哪个？
🙋♂️ 我：继续同一个 thread 的执行状态，靠 Checkpointer；如果开了一个新 thread，仍想读取用户稳定偏好，就从 Store 按授权范围取。
🧑💻 面试官：那 Store 能不能替代 Checkpointer，把所有状态都塞进去？
🙋♂️ 我：可以自行造状态恢复逻辑，但那不是 Store 的主要职责。图的节点执行进度、待恢复状态和快照语义，仍应交给 Checkpointer 管。
一个回答“这次任务做到哪儿了”，另一个回答“跨任务还要记住什么”。
面试速答（60 秒版）
LangGraph 的 Checkpointer 保存图在某个 thread 上的状态快照，适合对话续接、暂停后恢复、查看执行历史。使用时需要稳定的 thread_id；换了 thread_id，就不是继续原任务。
Store 则用来保存需要跨 thread 使用的应用数据，比如用户确认过的偏好、项目背景或长期记忆。它不自动代表当前图执行到哪个节点，也不应不加区分地把所有对话内容都写进去。
工程上，两者可以一起用：Checkpointer 管当前任务状态，Store 管经筛选的长期数据。还要设计身份权限、删除策略和生产级持久化后端。内存实现方便开发演示，但进程一停数据就可能没有了。
知识点详解：先问“这份数据属于哪一次任务”
Checkpointer 保存任务沿途的快照
假设一个报销 Agent 查完规则后暂停，等用户确认金额。系统要记住它在这个任务里已经读过哪些材料、当前状态是什么、下一步等什么输入。Checkpointer 就用于保存这类 thread 级状态，恢复时按 thread_id 找回对应快照。
它的重点是执行连续性。重新启动服务后继续同一任务，或查看某一步之前的状态，都依赖可靠的持久化配置。但 Checkpointer 不会自动帮你判断哪段聊天值得作为用户长期记忆。
Store 保存跨任务仍有用的资料
例如用户确认“今后默认用中文回答”，下周开一个新 thread 时仍希望生效。这个偏好不属于上次任务进行到第几步，而是跨任务可读取的数据，适合放到 Store 或业务数据库，并按用户和租户组织访问范围。
不是所有历史消息都该写进去。长期资料应有来源、更新和删除机制；敏感信息还要经过业务授权。否则新任务可能继承旧任务的临时假设，甚至读到别人的数据。
两种存储解决不同问题
一个真实产品里，用户暂停的报销任务由 Checkpointer 恢复；用户偏好由 Store 读取；订单和报销记录仍以业务数据库为准。它们可以协作，但不能互相冒充“唯一事实来源”。
面试里最容易答错的是把“有持久化”直接等同于“有长期记忆”。保存了图快照，只说明同一条执行线程可续，不等于能正确、安全地跨会话使用用户信息。
面试官继续追问
用户新开一个 thread，为什么看不到旧任务状态？
因为 Checkpointer 按 thread 保存快照。新 thread 是另一条执行线；若需要共享长期资料，应明确从 Store 或业务系统取。
Store 里的偏好改了，旧快照会自动变吗？
不会把过去的状态自动改写。恢复任务时要定义是沿用当时快照，还是重新读取最新偏好，并处理冲突。
开发时用内存 Checkpointer，上线还能用吗？
一般不适合需要跨进程或重启恢复的生产任务。应选可靠持久化后端，并测试恢复与数据清理。
面试速记卡
- Checkpointer：保存 thread 上的图状态快照。
- Store：保存跨 thread 可读取的长期数据。
- thread_id：恢复同一任务的关键标识。
- 不混淆：任务进度、长期偏好、业务事实来源各有归属。
- 上线：持久化、权限、删除和敏感数据治理都要补齐。
