上一篇我们把 Memory 的三种策略——截断、总结、检索——从原理到选型梳理了一遍。这篇直接进实战你现在用的 Memory 写法可能已经被官方标注为过时了而且坑还不少。作为开发者最怕的不是不会用而是用错了还不知道——跑起来没报错上线了才发现对话记忆时好时坏Token 开销莫名爆表多用户串话。这篇把最常踩的坑一一拆开附上可运行的正确写法。01 你真的了解 Memory 在 LangChain 里的位置吗很多人把 Memory 当成一个独立的记忆插件插上去就能用。实际上Memory 只做一件事在每次调用时往 Prompt 里塞历史消息。用户输入 ↓ Memory.load_memory_variables() ← 读历史注入 Prompt ↓ LLM 推理 ↓ Memory.save_context() ← 写历史 ↓ 返回输出┌─────────────────────────────────────────────────┐ │ 一次完整对话轮次 │ │ │ │ [用户输入] ──► [Memory读取] ──► [Prompt组装] │ │ │ │ │ ▼ │ │ 历史消息注入模板 │ │ │ │ │ ▼ │ │ [LLM推理] ──► [输出] │ │ │ │ │ ▼ │ │ [Memory写入] ← save_context() │ └─────────────────────────────────────────────────┘理解这个流程很多坑就自然明白了。02 最高频的坑Memory 没有被调用先看一个典型的错误写法importConversationBufferMemoryfromlangchain/memoryimportChatOpenAIfromlangchain/openaiimportLLMChainfromlangchain/chainsimportChatPromptTemplatefromlangchain/core/promptsconstnewConversationBufferMemoryconstnewChatOpenAImodelNamegpt-3.5-turboconstChatPromptTemplatefromMessagessystem你是一个助手。human{input}// ❌ 错误Memory 传了但 Prompt 里没有 {history} 占位符constnewLLMChainawaitcallinput我叫张三awaitcallinput我叫什么名字// 它不记得问题在哪Prompt 里没有{history}占位符历史消息根本没被注入。正确写法importConversationBufferMemoryfromlangchain/memoryimportChatOpenAIfromlangchain/openaiimportLLMChainfromlangchain/chainsimportChatPromptTemplateMessagesPlaceholderfromlangchain/core/promptsconstnewConversationBufferMemoryreturnMessagestrue// 返回消息对象而非字符串memoryKeyhistory// 与 Prompt 占位符名称一致constnewChatOpenAImodelNamegpt-3.5-turbo// ✅ 正确Prompt 里有 MessagesPlaceholderconstChatPromptTemplatefromMessagessystem你是一个助手。newMessagesPlaceholderhistory// ← 必须有这行human{input}constnewLLMChainawaitcallinput我叫张三constawaitcallinput我叫什么名字consolelogtext// 输出你叫张三03 五种 Memory 类型选错了比没有还糟LangChain 提供了 5 种内置 Memory 类型每种定位不同Memory 类型选型图 短对话20轮 ──► ConversationBufferMemory 完整存储所有历史 中等长度对话 ──► ConversationBufferWindowMemory 只保留最近 K 轮 长对话Token受限 ──► ConversationTokenBufferMemory 按 Token 数裁剪 超长对话精度要求高 ──► ConversationSummaryBufferMemory 近期原文 早期摘要 需要语义检索历史 ──► VectorStoreRetrieverMemory 相似度召回历史片段对比一张表类型Token消耗信息损失适合场景BufferMemory随轮次线性增长无短对话 / 原型验证BufferWindowMemory(K10)稳定在~10轮10轮前全丢客服/问答TokenBufferMemory稳定在Token上限按Token裁剪资源敏感场景SummaryBufferMemory中等摘要压缩细节轻微损失长会话助手VectorStoreMemory低按需检索依赖召回精度知识密集型Agent生产环境里90% 的场景用ConversationSummaryBufferMemory就够了。04 ConversationSummaryBufferMemory最被低估的 Memory很多人没用过这个觉得配起来复杂。实际上它才是最接近人类记忆工作方式的设计。原理时间线 ────────────────────────────────────────────► 早期对话 [已压缩为摘要] 近期对话 [保留原文] ┌──────────────────────┐ ┌────────────────────────┐ │ SummaryLLM生成 │ │ Recent Messages Buffer │ │ 用户是张三工程师 │ │ 轮次N-5 到 轮次N │ │ 正在开发RAG系统... │ │ 完整消息对象 │ └──────────────────────┘ └────────────────────────┘ │ │ └──────────── 合并注入 Prompt ──────────────►代码示例importConversationSummaryBufferMemoryfromlangchain/memoryimportChatOpenAIfromlangchain/openaiconstnewChatOpenAImodelNamegpt-3.5-turboconstnewConversationSummaryBufferMemory// ← 用来生成摘要的模型maxTokenLimit2000// ← Token 超过 2000 时开始摘要returnMessagestruememoryKeyhistory// 随着对话增长早期轮次自动被压缩为摘要// Token 始终控制在 maxTokenLimit 附近一个关键细节maxTokenLimit是触发压缩的阈值不是硬上限。实际注入 Prompt 的 Token 可能略超这个值因为摘要本身也有长度。生产里建议设为上下文窗口的30%给用户输入和输出各留足空间。05 多用户场景的致命坑Memory 实例共享这个坑在测试环境不会出现生产一上就串话。// ❌ 危险全局单例 Memory所有用户共用同一个历史constnewConversationBufferMemorypost/chatasyncconstnewLLMChainmemoryconstawaitcallinputbodymessagejsonreplytext// 用户A的历史混入了用户B的对话正确做法每个 session 对应独立的 Memory 实例。importConversationSummaryBufferMemoryfromlangchain/memoryimportChatOpenAIfromlangchain/openai// ✅ 用 Map 按 sessionId 隔离 MemoryconstnewMapstringConversationSummaryBufferMemoryfunctiongetMemorysessionId: stringConversationSummaryBufferMemoryifhassetnewConversationSummaryBufferMemoryllmnewChatOpenAImodelNamegpt-3.5-turbomaxTokenLimit2000returnMessagestruememoryKeyhistoryreturngetpost/chatasyncconstbodyconstgetMemory// ← 按用户隔离constnewLLMChainconstawaitcallinputjsonreplytext生产里还要加过期清理否则memoryStore会无限增长// 简单 TTL 清理30分钟无活动则释放constnewMapstringnumbersetInterval() constDatenowforconstofif30601000deletedelete5601000// 每5分钟扫一次06 新版写法RunnableWithMessageHistoryLCEL 推荐方式LangChain v0.3 之后官方推荐用RunnableWithMessageHistory替代旧的 Memory Chain 写法。区别在哪旧方式Memory LLMChain Memory 对象内嵌到 Chain 中耦合紧难复用 新方式RunnableWithMessageHistory LCEL 历史管理与 Chain 逻辑分离sessionId 驱动更清晰新写法示例importChatOpenAIfromlangchain/openaiimportChatPromptTemplateMessagesPlaceholderfromlangchain/core/promptsimportRunnableWithMessageHistoryfromlangchain/core/runnablesimportInMemoryChatMessageHistoryfromlangchain/core/chat_historyconstnewChatOpenAImodelNamegpt-3.5-turboconstChatPromptTemplatefromMessagessystem你是一个助手。newMessagesPlaceholderhistoryhuman{input}constpipe// 历史存储按 sessionId 隔离conststoreRecordstringInMemoryChatMessageHistoryfunctiongetHistorysessionId: stringifnewInMemoryChatMessageHistoryreturn// ✅ 用 RunnableWithMessageHistory 包装constnewRunnableWithMessageHistoryrunnablegetMessageHistoryinputMessagesKeyinputhistoryMessagesKeyhistory// 调用时传入 sessionIdconstawaitinvokeinput我叫张三configurablesessionIduser-123// ← 关键这套写法和 LangGraph 的 Checkpoint 机制无缝衔接如果你在用 LangGraph直接用它的持久化方案就好不需要额外引 Memory 模块。07 生产环境自查清单上线前对照这份清单检查一遍Memory 生产上线自查 □ Prompt 里有 MessagesPlaceholder / {history} 占位符 □ Memory 实例按 sessionId 隔离没有全局单例 □ 设置了 maxTokenLimit建议上下文窗口的 30% □ SummaryBufferMemory 的 llm 参数已指定 □ 多进程/多实例部署时Memory 用了外部存储Redis/DB □ 有 TTL 清理机制防止 Map/内存无限增长 □ 测试过 20 轮对话摘要压缩后语义未丢失 □ 多用户并发测试确认不串话一个容易忽视的点在多进程/K8s 部署时内存里的 Map 各进程不共享。这时候需要用外部存储importRedisChatMessageHistoryfromlangchain/redis// ✅ 生产多实例部署用 Redis 存历史functiongetHistorysessionId: stringreturnnewRedisChatMessageHistoryclientttl1800// 30 分钟过期学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】