v0 的 Memory 类有两个结构性问题

v0 有一组叫 Memory 的类——ConversationBufferMemoryConversationSummaryMemoryVectorStoreRetrieverMemory——它们直接挂在 Chain 上，调用一次自动管理一轮历史。看上去很省心，但生产场景里两个痛点让人很苦恼

1. 记忆与具体 Chain 紧耦合换个 Agent 实现就得重写。导致代码难以复用，
2. 多使用者、多会话隔离缺失需要自行 sessionId老 API 没把这件事当成一等公民。

.x 用 checkpointer + store + tool 三件套掀翻旧抽象

@langchain/classic将 Memory 类拆分为两大概念：

• checkpointer: 线程级短期记忆，用于快速恢复当前会话状态。
• store: 跨会话长期记忆，用于持久化使用者特点、偏好等信息。
• sensing tool : 把向量检索包装成 Tool，让 Agent 自主决定何时回忆。 话说回来，

为什么 Agent 必须有状态？

LMM 本身无状态，每次调用只看到当前 prompt。若想让 Agent 记住 “张三 / 北京 / 后端”，只能在应用层把上一轮消息重新喂回去。这就是“记忆”在工程上的本质——状态管理。老实说，

.x 把这两类记忆干干净净地分开：短期负责即时上下文，长期负责跨会话知识。

说到工作记忆，当前 Prompt 里的 Messages

This is what LLM actually sees— messages you pass via { messages: }. It’s limited by context window.

说到短期记忆。thread-based checkpointer

A “thread” in LangGraph is identified by a thread_id*. By configuring a checkpointer;">MemorySaver) you can persist all messages per thread and automatically restore m on subsequent invocations.