说起来，

一、从“无状态”到“有记忆”的演进

bug。而是设计如此，

但真实的对话场景恰好需要记忆。使用者不会每次都把“我叫小明，我在北京”重复一遍。按理说，给 LLM 加记忆。本质上是做一件事：把历史对话以某种形式“带进”下一次请求。

LangChain 的记忆程序从 2023 年 Q1 首发至今经历了三个清晰可辨的阶段。阶段是 2025 年 Q3 LangChain 发布至今旧 Memory API 被移入 @langchain/classic，官方推荐转向 createAgent 的 checkpointer + store 两层架构。

这条演进路线背后有一个贯穿始终的问题：对话历史应该怎么存、存多少、存哪里。理解这三个问题的答案如何逐版变化，才能真正看懂 LangChain 记忆方案的设计意图。不过，

二、旧版八种 Memory 类型详解

LangChain 早期陆续推出了八种 Memory API。按策略可以归为四类：存原文、压缩原文、抽知识、搜历史。这四类不是并列关系，而是递进关系——每一类都在解决前一类留下的问题。说起来，

存原文这方面。Buffer 系

ConversationBufferMemory 是最原始的实现。再看做法极简，每轮对话的 input 和 output 原样追加进一个 buffer。下次调用时整个 buffer 塞给模型。 优点只有一个——实现最简单，上下文零丢失。 说起来，缺点也只有一个但致命：对话越长 Token 消耗线性增长。迟早超出模型的，

这就是 BufferMemory 的本质：以空间换简单。短对话演示、PoC 原型、智能客服里轮次可控的场景可以一用，再长就不行了。ConversationChain 默认就用它。 也侧面说明它的定位——入门级默认方案，但不是生产级方案。

ConversationBufferWindowMemory 尝试解决 Buffer 无限膨胀的问题。引入一个 k 参数。只保留最近 k 轮对话，更早的自动丢弃。内存使用固定了但新的问题也随之而来：早期信息被丢弃。例如 k=5 时使用者三轮前提到项目名称，第六轮再问时模型已经不知道了。k 调太大又退化回 Buffer——这是一个没有最优解的 trade-off。

Window 的本质是：以信息换效率。丢老信息，换稳定内存，

ConversationTokenBufferMemory 把控制粒度从“轮次”升级为“Token 数”。设一个 max_token_limit，超了就裁剪最早的消息。这比按轮次裁剪更精准，尤其适合有明确 Token 预算的场景——API 按 Token 计费。你只关心花多少钱，不关心保留了几轮。

但问题在于 Token 计数因语言而异；中文一字约一 Token，英文一词约一 Token。需要引入 tiktoken 等工具做精确计数。而且和 Window 一样，截断就可能丢上下文。不过，

TotalTokenBuffer 的本质是：以精度换可控。不过，在成本与长度之间做权衡。

压缩原文的观点是，Summary 系