考察点
这道题出自 Google 大模型应用工程师岗位的技术轮，是 DSPrep 标注的 Google/Amazon 双常考题。表面问两个类的区别，实际考的是你对「多轮对话的上下文是有成本的」这件事有没有量化概念——token 费用、延迟、上下文窗口挤占，以及信息压缩带来的失真。面试官想听你说清楚两种机制各自在什么规模下失效，追问会往「窗口型 Memory」「实体记忆」「自己实现一套记忆系统」走。
参考答案
机制差异：原样存 vs 滚动压缩
ConversationBufferMemory 做的事情极其简单：把每一轮 human/AI 的消息原样追加到一个列表里，下次调用时整个列表拼进 prompt。它不做任何加工，所以信息零失真——模型能看到对话的每一个字，包括用户三轮前随口提到的一个约束条件。代价同样直接：token 消耗随轮次线性增长。一个日均 50 轮的客服对话，到第 50 轮时每次请求都要带上前 49 轮的完整文本，输入 token 轻松上万，按 GPT-4 级别的定价，长会话的成本可能翻倍甚至更多，而且首 token 延迟也随输入长度明显变长。
ConversationSummaryMemory 换了个思路：不让历史无限膨胀，而是用 LLM 自己把已有对话压缩成一段摘要。每来一轮新对话，就把「旧摘要 + 新消息」再交给模型重新生成摘要，滚动更新。prompt 里带的永远是这段固定量级（几百 token）的摘要，输入成本被压成近似常数。代价是信息有损——摘要是有损压缩，用户说过的具体数字、订单号、细节偏好随时可能被模型在总结时丢掉，而且每一轮都多一次 LLM 调用来更新摘要，成本省在输入、花在摘要生成上，并不是白捡的。
一张表看清权衡
| 维度 | BufferMemory | SummaryMemory |
|---|---|---|
| 信息保真 | 无损，全文保留 | 有损，细节可能丢 |
| 输入 token | 随轮次线性增长 | 近似常数 |
| 额外 LLM 调用 | 无 | 每轮一次摘要调用 |
| 短对话表现 | 好 | 反而更贵更差 |
| 长对话表现 | 成本爆炸、可能超窗口 | 稳定，但依赖摘要质量 |
生产里的真实选法
面试里说完区别只是及格线，加分项是讲工程上没人裸用这两个。常见做法：
- ConversationBufferWindowMemory（窗口型）：只保留最近 k 轮原文，k 通常取 5-10。绝大多数 chatbot 场景里，用户问题的有效上下文就在最近几轮内，这是性价比最高的默认选项。
- ConversationSummaryBufferMemory（混合）：保留最近若干轮原文，超出 token 阈值的部分转成摘要。短对话等于 Buffer，长对话自动降级成 Summary，是 LangChain 内置方案里最接近生产可用的。
- 自己实现结构化记忆：对话轮次多、且需要长期记住用户事实（姓名、偏好、历史订单）的场景，通用摘要不够用。实战中会用 entity memory 或干脆把抽取出的事实写进外部存储（Redis/关系库），每轮按需注入 prompt，而不是指望摘要记住一切。
还有一个容易忽略的点：Memory 存的内容直接进 prompt，意味着它也占上下文窗口。模型标称 128k 窗口，不等于你可以随便塞——检索内容、系统提示、输出都要占额度，历史部分要有预算意识，我一般会硬性限制记忆部分不超过总窗口的三到四成。
版本提醒
LangChain 官方已把这套 Memory 组件标记为 legacy，新代码推荐用 LangGraph 的 checkpoint 机制管理状态。面试时主动提这一点，说明你跟进过框架演进，而不是背的旧文档。
可能的追问
1. 摘要把关键信息丢了怎么办？
两条路：一是让摘要 prompt 显式要求保留实体类信息（订单号、日期、承诺过的事项）；二是关键事实不依赖摘要，抽取后单独存，摘要只负责「聊了什么」的脉络。
2. 多用户并发时 Memory 怎么隔离？
按 session_id 隔离存储，绝不能全局共享一个 memory 实例。LangChain 里用 RunnableWithMessageHistory 配 Redis/SQL 后端，每个会话独立的 key，同时要考虑会话过期清理。
3. 什么时候宁可超长也不用 Summary？
法律、医疗这类对原文措辞敏感的场景，摘要改写一句话都可能引入责任风险。这种场景用窗口型保留原文，或者干脆让用户确认关键信息后再继续。