上一篇立了「记忆 = state + middleware」的框架。这一篇落到短期记忆——一次会话里的上下文怎么管理。
短期记忆的核心问题：一次会话跨很多轮，怎么让每一轮都能接上前面。答案就是 Phase 2 讲过的 checkpointer——现在从记忆视角再看它。
短期记忆 = 一次会话的上下文
短期记忆，就是当前这次会话的上下文：用户和 Agent 从开始聊到现在，说过什么、Agent 做过什么。
它和长期记忆的区别是范围：短期记忆只在「这次会话」里有意义，会话结束（或超时）就可以忘；长期记忆是跨会话持久的。
Checkpointer：按 thread 管理会话
短期记忆怎么实现？靠 Phase 2（第 14 篇）讲的 checkpointer。回忆一下：checkpointer 给每个 super-step 存档，按 thread_id 组织。
从记忆视角看，thread_id 就是「一次会话的标识」。同一个 thread_id 的所有存档，连起来就是这次会话从头到现在的完整上下文。
所以短期记忆 = 一个 thread 内的 state。同一 thread 里，前面轮次的内容在 state（messages）里，后面轮次能接上——这就是「短期记忆」。
多轮怎么接上
具体看一次多轮对话怎么靠 checkpointer 接上：
- 第 1 轮：用户说话 → 进 Agent → state.messages 加上这轮 → checkpointer 存档（thread=A，step1）
- 第 2 轮：用户又说话 → 用同一个 thread=A 调 Agent → checkpointer 取出 thread A 的最新存档 → state 里带着第 1 轮的内容 → 继续加第 2 轮
关键在第 2 步：用同一个 thread_id 调用，checkpointer 会自动恢复这个会话之前的 state。所以第 2 轮的 Agent「记得」第 1 轮——不是模型记得，是 checkpointer 把第 1 轮的 state 恢复了，beforeModel 注入给模型。
换 thread_id 就是新会话——checkpointer 取不到之前的存档，Agent 从零开始，不记得之前。这就是会话隔离。
为什么必须持久化 checkpointer
第 14 篇强调过：生产用持久化 checkpointer（Postgres 等），别用内存的。从记忆视角看更清楚为什么：
短期记忆要跨请求存活。Web 应用里，每一轮对话是独立的 HTTP 请求，请求之间进程不持续。如果 checkpointer 在内存，第一个请求结束内存可能就没了，第二个请求取不到第 1 轮的记忆。
持久化 checkpointer（存数据库）让记忆跨请求、跨进程存活——不管哪个请求、哪台机器，只要给同一个 thread_id，都能取到这个会话的完整记忆。
这是生产 Agent 必须解决的事，也是为什么一直强调用持久化 checkpointer。
短期记忆的边界
短期记忆有个自然边界：会话结束就过期。这是「短期」的含义——它不需要永久保存。
什么算「会话结束」？通常是：
- 用户主动结束（点「结束对话」）
- 超时（一段时间没活动）
- 应用逻辑判定（任务完成）
结束后，这个 thread 的短期记忆可以清理（或归档）。要永久记的，转成长期记忆（下一篇）。
收束：短期记忆就是 thread 内的 state
这一篇讲了短期记忆：
- 短期记忆 = 一次会话的上下文，会话结束即过期
- 实现：checkpointer 按 thread_id 管理，同 thread 能接上
- 多轮接上靠「同 thread_id 调用，自动恢复之前 state」
- 生产必须持久化 checkpointer，让记忆跨请求存活
- 边界：会话结束过期，要永久的转长期记忆
下一篇讲长期记忆——跨会话的记忆怎么实现（LangGraph Store）。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识底层到 LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
