LangChain 中的 Memory（记忆）机制有哪些类型？

1. Memory 的设计目的

大语言模型本质上是无状态的，每次 API 调用都是独立的。Memory 组件通过显式管理对话历史和上下文状态，将无状态的 LLM 调用转化为有连续性的对话体验。所有 Memory 组件统一实现 load_memory_variables() 和 save_context() 接口。

2. 五种 Memory 类型

• ConversationBufferMemory（全量缓存记忆）：完整保存所有对话轮次，不做任何压缩。优点是精确无误，缺点是随着对话增长会无限消耗 Token，最终超出模型的上下文窗口。适用于短对话、轮次少的场景
• ConversationBufferWindowMemory（滑动窗口记忆）：只保留最近 K 轮对话，丢弃更早的内容。通过设置 k 参数控制保留轮数，在 Token 使用和记忆范围之间取得平衡。适用于话题切换频繁的一般聊天场景
• ConversationSummaryMemory（摘要记忆）：使用 LLM 定期将长对话压缩为摘要，摘要随每轮对话更新。相比全量缓存大幅减少 Token 占用，代价是需要额外的 LLM 调用成本，且可能丢失细节。适用于主题连贯的长对话
• ConversationSummaryBufferMemory（摘要缓冲混合记忆）：结合上述两种方式的优点——近期对话以全文形式保留，早期对话被摘要压缩。通过 max_token_limit 控制总 Token 上限，超过后 oldest messages 被摘要化。这种混合方案兼顾了近期上下文的精确性和长期上下文的成本控制
• VectorStoreRetrieverMemory（向量库长期记忆）：将对话片段向量化存入向量数据库（如 FAISS、Chroma），通过语义搜索而非时间顺序检索相关记忆。模拟人类的"联想记忆"，能从海量历史中精准抓取相关信息，适合构建个人专属助手或需要跨会话长期记忆的系统

3. 持久化记忆方案

对于生产环境，Memory 需要支持跨会话持久化。LangChain 提供了多种持久化后端：

• Redis 后端：通过 RedisChatMessageHistory 实现，速度快、支持过期时间配置，适合实时性要求高的场景
• SQL 后端：通过 SQLChatMessageHistory 支持 SQLite、PostgreSQL 等关系型数据库
• MongoDB 后端：通过 MongoChatMessageHistory 实现文档型存储
• LangGraph Checkpointer：通过 LangGraph 的检查点机制实现 durable execution，支持状态持久化和断点续跑

4. Memory 选型建议

选择 Memory 类型时可根据以下维度判断：对话时长较短（20 轮以内）选用 Buffer Memory；需要保留近期上下文但控制成本选用 Buffer Window；长对话且关注成本选用 Summary Memory；需要从大量历史中精确回忆特定事实选用 Vector Store Memory；需要跨会话持久化则配合 Redis 或 SQL 后端。许多生产应用会组合使用多种 Memory 类型。