记忆不是“多带几轮聊天记录”。记忆是一个可读、可写、可压缩、可持久化的上下文系统。

1. 记忆不是历史消息

很多人第一次做多轮对话，会把历史消息全部拼进 Prompt。刚开始没问题。聊十轮、二十轮以后，问题就来了：上下文越来越长，成本越来越高，回答越来越慢，模型还会被旧信息带偏。

LangChain 当前的记忆设计，不再鼓励把 Memory 理解成一个简单的 ConversationBuffer。更准确的理解是：短期记忆放在线程状态里，长期记忆放在 Store 里，中间再加上下文压缩。

历史消息会线性增长，风险也会线性增长。

2. 为什么不能只靠“硬塞历史消息”？

因为大模型每次回答，只能基于本轮输入里的上下文做判断。你把一大堆旧消息塞进去，模型不是“更聪明”，而是“背着更重的包袱”。

第一，token 成本会涨。每轮都带历史，历史越长，账单越高。

第二，响应速度会慢。模型要读更多内容，推理链路自然变长。

第三，旧信息会干扰新任务。昨天用户说“我要保守”，今天可能已经换了目标。

第四，隐私边界会变模糊。不该继续使用的信息，可能被反复带进上下文。

官方文档也明确提到：长对话会挑战上下文窗口，即使模型支持长上下文，也可能被陈旧或偏题内容分散注意力，同时带来更慢的响应和更高的成本。

3. LangChain 的 Memory：三层结构

Memory 三层结构：messages、state/checkpointer、store。

这三层不要混在一起。messages 是模型输入的一部分；state 是当前 thread 的工作台；store 是跨会话的长期资料库。

messages：本轮模型要看的上下文。越少越好，越准越好。

State + Checkpointer：同一个 thread 里的短期记忆。让多轮对话不断线。

Store：跨 thread、跨会话的长期记忆。保存用户事实、偏好、画像、经验。

4. Checkpointer 和 Store 的边界

Checkpointer 和 Store 是两个概念。很多系统混用这两个东西，后面一定会乱。

Checkpointer 保存线程状态，Store 保存长期知识。

Checkpointer 解决的是“这条对话怎么继续”。Store 解决的是“这个用户以后还要不要记得”。

5. create_agent(..., checkpointer=...)

短期记忆的入口很直接：创建 Agent 时传入 checkpointer。这个 checkpointer 会跟随 Agent 图一起编译。之后每次 invoke，只要传入同一个 thread_id，就能接上这条对话。

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver
agent = create_agent(
model="openai:gpt-5.5",
tools=[...],
checkpointer=InMemorySaver(),
)
config = {"configurable": {"thread_id": "user_1001_session_001"}}
agent.invoke({"messages": [{"role": "user", "content": "我叫张三"}]}, config)
agent.invoke({"messages": [{"role": "user", "content": "我叫什么？"}]}, config)

这里的关键不是 InMemorySaver。关键是 checkpointer 这个接口。开发环境可以用内存，生产环境要换成数据库型 checkpointer，例如 PostgresSaver。

6. AgentState["messages"]

LangChain Agent 默认用 AgentState 管理短期记忆。最核心的字段就是 messages。模型节点读取 messages，工具节点也会把 ToolMessage 追加进去。

这也是为什么多轮对话能继续：不是模型真的“记住了”，而是图状态被保存，下次同一个 thread_id 又被取出来。

短期记忆的源码链路压缩图。

# 源码链路可以压缩成这条线：

create_agent(checkpointer=...)
-> AgentState["messages"]
-> graph.invoke(..., thread_id)
-> checkpointer.get_tuple(config)
-> model_node / tool_node 更新 state
-> checkpointer.put(...)
-> 下一轮同 thread_id 恢复状态

7. 工具如何读写记忆？

工具不是只能接收模型传来的参数。工具还可以通过 ToolRuntime 读取运行时信息。这里面有 state，也有 store。

runtime.state：当前 thread 的短期状态，包括 messages 和自定义字段。
runtime.store：长期记忆存储，跨会话仍然可用。
runtime.context：本次调用的只读上下文，例如 user_id、租户信息、权限信息。
from langchain.tools import tool, ToolRuntime
from langgraph.types import Command
@tool
def set_user_name(name: str, runtime: ToolRuntime) -> Command:
return Command(update={"user_name": name})
@tool
def save_user_profile(user_id: str, profile: dict, runtime: ToolRuntime) -> str:
runtime.store.put(("users",), user_id, profile)
return "saved"

这就是工具和记忆打通的地方：工具可以读当前对话状态，也可以把稳定事实写入长期 Store。

8. 长对话要治理：trim、delete、summarize、extract

上下文治理的四种常见动作。

长对话不是一直追加，而是不断整理。短期上下文里只应该留下当前任务有用的信息。

trim：保留最近几条。速度快，适合普通聊天。

delete：删除无关消息。适合清理工具噪声和敏感信息。

summarize：把旧对话压缩成摘要。适合长任务。

extract：抽取稳定事实。适合写入长期记忆。

LangChain 官方短期记忆文档给出了 trim、delete、summarize 等模式。它们本质上都在做一件事：让模型看到更少、更有用的上下文。

9. SummarizationMiddleware：自动摘要的源码思路

摘要中间件的作用很像“对话保洁员”。模型调用前，它先看 messages 是否接近 token 阈值。如果没有超，直接放行。如果超了，就压缩旧消息，保留最近消息。

SummarizationMiddleware 在模型调用前压缩旧消息。

注意一个细节：工具调用消息不能乱删。AIMessage 里的 tool_call 和后面的 ToolMessage 是一组。裁剪或摘要时拆坏这组消息，模型下一轮可能直接报错。

# 摘要链路可以理解为：

before_model(state)
-> messages = state["messages"]
-> count_tokens(messages)
-> below threshold: return None
-> summarize older messages
-> keep recent messages
-> return state update

10. 长期记忆：不要存聊天记录，要存知识

长期记忆的三种常见类型。

长期记忆不是“把所有聊天记录永久保存”。长期记忆应该是可复用、可解释、可更新的知识。

语义记忆：事实。比如用户偏好、岗位、风险承受能力。

情节记忆：经验。比如上次怎么处理类似问题。

程序记忆：规则。比如遇到退款必须走人工确认。

LangGraph Store 使用 namespace + key 保存 JSON 文档。namespace 可以放 user_id、org_id、业务域。key 可以是 profile、preference、case_xxx。

# 长期记忆的典型结构：
namespace = ("users", user_id)
key = "profile"
value = {
"risk_level": "medium",
"language_style": "short_direct",
"watch_list": ["三安光电", "节能风电"]
}

11. 什么时候写记忆？热路径 vs 后台任务

热路径写入：用户一句话进来，Agent 先判断要不要保存，再回答。好处是立即生效，坏处是慢。

后台写入：先回答用户，再异步分析哪些内容值得存。好处是不拖慢主流程，坏处是新记忆不会立即出现在本轮对话里。

12. 企业级 Memory 架构怎么落地？

Java 主服务负责业务边界：登录态、权限、租户、审计、会话 ID。Python AI 服务负责 Agent 执行：模型、工具、RAG、短期状态、长期记忆。

前端传 userId 和 sessionId，不直接传任意 memory。

Spring Boot 生成稳定的 thread_id，并做权限校验。

AI 服务用 thread_id 读取 checkpointer，用 user_id 读取 store。

所有记忆写入都要有审计日志和来源。

敏感记忆必须支持删除、过期和用户可见。

13. Memory 上线前的避坑清单

Memory 做不好，比没有 Memory 更危险。没有 Memory 只是答得笨；坏 Memory 会答得自信又错误。

不要把记忆写入交给模型完全自由决定。要有 schema、规则和审计。

不要把所有用户表达都当事实。要区分事实、偏好、临时需求和情绪。

不要把工具结果永久保存。工具结果可能过期，要设置 TTL 或来源时间。

不要只看功能跑通。要评测误写率、漏写率、召回准确率、删除有效性。

14. 总结

Memory 的重点不是“记得更多”，而是“记得更准”。短期记忆解决当前会话连续性，长期记忆解决跨会话个性化，上下文治理解决长对话膨胀。