核心要点
能讲清 Memory 的职责：在多轮对话中维护历史上下文，并在每次调用前把相关历史注入 prompt，让模型「记得」之前说过什么
能列举主要类型：ConversationBufferMemory（全量缓存）、BufferWindow（只保留最近 K 轮）、Summary（用 LLM 滚动摘要压缩历史）、VectorStore-backed（把历史存向量库按相关性召回）
能说清持久化路径：内存里的对话默认进程结束即丢失，持久化是把消息写入 Redis / 数据库 / 文件，按 session_id 读写
能给出 2026 的写法：旧的 Memory 类已被弱化，LCEL 里用 RunnableWithMessageHistory 包裹链，配合各种 ChatMessageHistory（如 RedisChatMessageHistory）按 session 自动读写历史
标准回答
Memory 解决什么问题
LLM 本身是无状态的，每次调用只看到当前 prompt。要做多轮对话，就得自己把历史对话喂回去。Memory 组件就是封装这件事：它在调用前读取历史、拼进 prompt，在调用后把新一轮的用户输入和模型回复存起来。
常见 Memory 类型
- ConversationBufferMemory：原样保留全部历史。简单、不丢信息，但轮数一多就撑爆上下文窗口、推高 token 成本。
- ConversationBufferWindowMemory：只保留最近 K 轮，控制长度，但会忘掉更早的内容。
- ConversationSummaryMemory：用 LLM 把旧历史滚动压缩成摘要，长对话省 token，代价是多一次 LLM 调用且摘要可能丢细节。
- VectorStore-backed Memory：把每轮对话存进向量库，下次按当前 query 的语义相关性召回最相关的几条历史，适合超长对话或需要跨会话记忆的场景。
对话历史如何持久化
默认历史存在进程内存里，服务重启或换实例就没了。生产中必须外置：
- Redis：最常用，低延迟、带 TTL，适合会话级历史。
- 数据库（Postgres / MongoDB 等）：需要长期留存、可查询审计时用。
- 文件：本地或单机小应用的简易方案。
关键是用 session_id（或 user_id）做隔离键，每个会话独立读写自己的历史。
LCEL 里的现代写法
新版 LangChain 弱化了老的 Memory 类，推荐在 LCEL 中用 RunnableWithMessageHistory 包裹你的链，并传入一个返回 BaseChatMessageHistory 的工厂函数（如 RedisChatMessageHistory(session_id)）。框架会在每次调用时按 session_id 自动加载历史、注入到 prompt 的 MessagesPlaceholder，并在调用后把新消息追加回去——持久化与注入对业务代码透明。
常见误区
⚠️ 常见踩坑
以为「用了 Memory 就万事大吉」而放任 ConversationBufferMemory 无限增长——历史会随轮数线性膨胀，迟早撑爆上下文窗口、让延迟和 token 成本失控；长对话必须用 Window、Summary 或向量召回来裁剪，并且千万别忘了做持久化与按 session_id 隔离，否则多用户会串话、重启即失忆。
追问
追问 1：Buffer、Summary、向量库三种 Memory 该怎么选？
看对话长度和成本约束。短对话（几轮到十几轮）直接用 BufferWindow，最简单可靠；中长对话且关注 token 成本，用 Summary 把旧历史压成摘要、保留最近几轮原文（SummaryBuffer 混合策略）；超长对话或需要跨会话「记住用户偏好」，用向量库按相关性召回最相关历史。实务里常组合：最近 K 轮原文 + 更早历史的摘要或向量召回。
追问 2：RunnableWithMessageHistory 和老的 ConversationChain 有什么区别？
ConversationChain 把 Memory 耦合在一个封装好的链里，扩展性差、难以和 LCEL 的流式、批处理、可组合特性结合。RunnableWithMessageHistory 是 LCEL 原生的包装器：它不绑定具体 Memory 类型，只要你提供一个按 session_id 返回 ChatMessageHistory 的工厂，就能给任意 Runnable 加上自动读写历史的能力，并天然支持 stream、配置化、可观测，是 2026 的推荐做法。
追问 3：多用户、多会话场景下历史隔离要注意什么？
核心是用稳定且唯一的 session_id（通常是 user_id + 会话 id）作为存储键，绝不能让不同用户共用一个历史对象。后端选 Redis 这类支持按 key 隔离并能设 TTL 的存储，给历史加过期时间避免无限堆积；涉及敏感信息时要考虑加密存储与合规删除（用户注销即清历史）；高并发下还要注意同一 session 并发写入的竞态，必要时加锁或用追加型存储。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习