1. 项目概述为什么大模型需要“记忆”聊到大模型很多人第一反应是它很聪明能写诗、能编程、能回答问题。但如果你跟它多聊几句尤其是聊一个复杂的话题比如让它帮你规划一个旅行行程你可能会发现一个尴尬的现象它好像有点“健忘”。你刚说完“我预算有限”下一句问它“那家五星级酒店怎么样”它可能就会兴高采烈地给你推荐起来完全忘了你刚才的预算限制。这就是典型的“无状态”对话——模型只根据当前最新的输入你的问题来生成回答而忘记了之前对话的历史上下文。这显然不符合我们人类对话的习惯。我们的大脑天然具备“记忆”能力能记住对话的背景、对方的身份、之前达成的共识甚至是一些微妙的情绪。要让AI助手真正有用尤其是构建多轮对话的智能体Agent或复杂的应用流程赋予它“记忆”能力就成了一个核心课题。这不仅仅是技术问题更是体验问题。一个没有记忆的AI就像金鱼一样只能进行最浅层的互动。在LangChain这个框架里“记忆”被抽象成了一个核心组件。它不是一个玄乎的概念而是一套实实在在的机制用于在应用的不同步骤之间持久化、管理和检索历史信息。简单来说它的任务就是记住该记住的并在需要的时候准确地把相关信息提供给大模型。这听起来简单做起来却涉及到数据存储、信息压缩、相关性检索等一系列工程挑战。今天我们就来深入LangChain的记忆模块看看它是如何让大模型“记住”事情的以及我们在实际开发中该如何用好它。2. 记忆的核心概念与设计思路在深入代码之前我们必须先理解LangChain对“记忆”的抽象。它没有把记忆做成一个黑盒而是将其拆解为几个清晰的部分这种设计非常符合工程思维。2.1 记忆的两种基本形式对话历史与实体记忆首先记忆主要分为两大类对话历史Chat History这是最基础、最常用的记忆形式。它就像一个聊天记录本按顺序记录下用户和AI助手之间所有的消息往来。HumanMessage用户说的、AIMessageAI回的都会被忠实地记录下来。当进行新一轮对话时系统会把这个“聊天记录本”连同新的问题一起交给大模型模型就能基于完整的上下文来生成更连贯、更准确的回答。几乎所有聊天应用都需要这个功能。实体记忆Entity Memory这是一种更结构化的记忆。它不仅仅记录对话的原始文本还会从中提取出关键实体如人名、地点、偏好等及其属性并以键值对Key-Value的形式存储。例如从对话中提取出{“user_name”: “张三”, “favorite_color”: “蓝色”, “budget”: “有限”}。在后续对话中系统可以快速查询这些实体信息而无需让模型重新阅读冗长的历史记录。这对于需要记住用户个人信息的个性化助手特别有用。2.2 记忆系统的关键组件LangChain的记忆系统主要由以下几个核心类构成理解它们的关系至关重要ChatMessageHistory这是记忆的“存储器”或“仓库”。它提供了一个简单的列表接口add_message,messages专门用于存储BaseMessage对象如HumanMessage,AIMessage。它只负责“存”和“取”不负责“怎么用”。你可以把它理解为一个内存中的临时记事本。BaseChatMemory这是记忆的“管理器”或“大脑”。它是一个抽象类定义了记忆应该如何被加载、保存以及与模型交互。它内部通常会持有一个ChatMessageHistory实例作为存储后端。它的核心方法是load_memory_variables和save_context。save_context: 当一轮对话用户输入AI输出完成时调用此方法将这两条消息保存到内部的ChatMessageHistory中。load_memory_variables: 在准备新一轮对话的输入时调用此方法。它会从ChatMessageHistory中读取历史消息并可能对其进行处理如截断、总结然后返回一个字典这个字典最终会被合并到发送给大模型的提示词Prompt中。ConversationBufferMemory这是BaseChatMemory的一个最直接实现即“缓冲区记忆”。它简单粗暴地把所有历史对话都保存下来并在每次调用load_memory_variables时将所有消息拼接成一个长字符串返回。优点是信息完整缺点是当对话轮数很多时会消耗大量Token可能超出模型的上下文窗口限制导致成本增加或历史被截断。ConversationBufferWindowMemory这是“带窗口的缓冲区记忆”。它只保留最近K轮对话例如最近5轮。旧的对话会被自动丢弃。这是一种在记忆完整性和资源消耗之间的折中方案适用于大多数不需要回忆很久以前细节的对话场景。ConversationSummaryMemory这是“总结性记忆”。它不会保存所有原始对话而是会定期或在每次对话后调用一个大模型对已有的对话历史进行总结然后用这个总结文本来替代原始的长篇历史。新的对话会基于这个总结和最近的少量原始对话来进行。这能极大地节省Token但可能会丢失一些细节信息并且增加了调用模型的成本。注意ChatMessageHistory和BaseChatMemory的子类如ConversationBufferMemory是不同层级的组件。通常我们不会直接操作ChatMessageHistory而是通过ConversationBufferMemory等记忆管理类来间接使用它。但ChatMessageHistory的价值在于它定义了存储的接口使得我们可以轻松替换存储后端比如从内存换到数据库。2.3 记忆如何与大模型交互记忆并不是独立工作的。在一个典型的LangChain链Chain或智能体Agent中记忆的集成流程是这样的初始化创建一个记忆对象如ConversationBufferMemory并指定其返回的记忆变量名例如memory_key“chat_history”。保存上下文在链的每次运行结束后调用memory.save_context()将本次的输入和输出作为一组消息保存起来。加载记忆在链的下一次运行前链的模板PromptTemplate中会包含一个变量例如{chat_history}。链在格式化提示词时会自动调用memory.load_memory_variables()获取到的字典中的“chat_history”值就会被填充到这个位置。模型推理最终一个包含了历史对话和当前问题的完整提示词被发送给大模型模型据此生成具有上下文感知的回答。这个流程确保了记忆被无缝地编织到与大模型的每一次交互中。3. 从内存到持久化ChatMessageHistory的演进让我们从最简单的内存存储开始逐步深入到生产环境需要的持久化方案。3.1 基础使用内存中的ChatMessageHistory这是最快速的入门方式所有数据都保存在程序运行的内存中。程序关闭记忆就消失了。from langchain.memory import ChatMessageHistory # 创建一个聊天历史记录对象 history ChatMessageHistory() # 添加用户消息 history.add_user_message(“你好我叫张三”) # 添加AI助手消息 history.add_ai_message(“你好张三很高兴认识你。”) # 继续添加第二轮对话 history.add_user_message(“记住我最喜欢的颜色是蓝色。”) history.add_ai_message(“好的我已经记住你最喜欢蓝色了。”) # 查看所有历史消息 print(history.messages) # 输出类似[HumanMessage(content‘你好我叫张三’), AIMessage(content‘你好张三很高兴认识你。’), ...]实操心得在快速原型验证、单元测试或一次性脚本中使用内存存储非常方便。但切记它不能用于任何需要状态保持的真实服务。ChatMessageHistory的messages属性就是一个Python列表你可以像操作普通列表一样遍历、切片但直接修改这个列表可能会破坏内部状态建议只使用提供的add_*方法。3.2 进阶使用Redis实现持久化记忆RedisChatMessageHistory对于生产环境我们必须将记忆持久化到外部存储中这样即使服务重启用户的对话历史也不会丢失。Redis因其高性能、支持数据结构丰富且简单易用成为存储聊天历史的绝佳选择。RedisChatMessageHistory就是为此而生的。首先确保已安装必要的包pip install langchain redis。from langchain.memory import RedisChatMessageHistory import os # 配置Redis连接信息。生产环境应从环境变量或配置中心读取。 REDIS_URL “redis://localhost:6379/0” # 假设Redis运行在本地 SESSION_ID “user_12345” # 关键用于区分不同用户或会话的唯一标识 # 创建Redis支持的聊天历史对象 history RedisChatMessageHistory( session_idSESSION_ID, # 会话ID是数据存储和检索的键 urlREDIS_URL, # Redis连接URL ttl3600 # 可选设置键的过期时间秒例如1小时。不设置则永久保存。 ) # 使用方式与内存版本完全一致 history.add_user_message(“这次对话会被保存到Redis里。”) history.add_ai_message(“是的即使程序重启只要session_id不变你就能找回这段记忆。”) # 读取历史 messages history.messages print(f“历史消息数{len(messages)}”) for msg in messages: print(f“{msg.type}: {msg.content}”)核心参数解析session_id这是整个设计的灵魂。它决定了记忆的“命名空间”。同一个session_id下的所有消息属于同一段对话历史。在Web应用中这通常对应一个用户ID或一个独立的聊天会话ID。必须确保其唯一性和稳定性。urlRedis服务器的连接字符串。支持密码认证redis://:passwordhost:port/db和SSL连接。ttl生存时间。对于某些临时性会话如客服聊天设置一个合理的TTL可以自动清理过期数据避免Redis被无用数据占满。对于需要长期记忆的用户助手可以不设置或设置很长的TTL。注意事项与避坑指南Session ID 的管理这是最容易出错的地方。如果你的应用是多用户系统必须设计一套可靠的机制来生成和传递session_id。例如在Web后端可以从登录用户的ID派生或为每个匿名会话生成一个唯一UUID。切忌对所有用户使用相同的session_id否则会导致所有用户的记忆混在一起造成严重的隐私和逻辑混乱。Redis 数据结构RedisChatMessageHistory默认使用Redis的List类型来存储消息每条消息被序列化为JSON字符串后推入列表。你可以通过Redis客户端直接查看LRANGE “message_store:[session_id]” 0 -1。了解这一点有助于调试。连接池与性能在生产环境中不要为每次请求都创建新的RedisChatMessageHistory实例和Redis连接。应该使用连接池。虽然LangChain的底层redis包通常有默认连接池但在高并发场景下需要显式配置和管理连接池参数。消息序列化确保你的BaseMessage子类如果你自定义了可以被json.dumps正确序列化和反序列化。标准库的HumanMessage,AIMessage等没有问题。清理记忆RedisChatMessageHistory提供了clear()方法来清空当前会话的所有历史。这在用户主动要求“忘记我”或开始一个全新主题的对话时非常有用。3.3 其他持久化方案简介除了RedisLangChain社区还提供了其他后端的ChatMessageHistory实现以适应不同的技术栈PostgresChatMessageHistory使用PostgreSQL数据库存储。适合已经使用PG作为主数据库的应用便于统一管理。DynamoDBChatMessageHistory使用AWS DynamoDB。适合完全托管在AWS云上的Serverless应用。MomentoChatMessageHistory使用Momento Serverless Cache。这是一种完全托管的、兼容Redis协议的缓存服务无需自运维Redis集群。选择哪种方案取决于你的基础设施、团队熟悉度和性能要求。Redis在延迟和吞吐量上通常表现优异是通用场景下的首选。4. 记忆管理策略实战从Buffer到Summary有了持久化的历史仓库我们还需要智能的管理策略来决定“记什么”和“怎么记”。下面我们结合ConversationBufferMemory及其变体看看如何将RedisChatMessageHistory集成进去。4.1 基础策略ConversationBufferMemory这是最直接的策略保留所有历史。from langchain.memory import ConversationBufferMemory from langchain_openai import ChatOpenAI from langchain.chains import ConversationChain from langchain.memory import RedisChatMessageHistory # 1. 创建持久化的历史存储 redis_history RedisChatMessageHistory( session_id“user_123_session_1”, url“redis://localhost:6379/0” ) # 2. 创建记忆管理器并指定使用上面的历史存储 memory ConversationBufferMemory( chat_memoryredis_history, # 关键注入自定义的ChatMessageHistory memory_key“chat_history”, # 在提示词模板中使用的变量名 return_messagesTrue # 返回Message对象列表而非拼接的字符串。某些提示词模板需要。 ) # 3. 创建大模型和对话链 llm ChatOpenAI(model“gpt-3.5-turbo”, temperature0) conversation ConversationChain( llmllm, memorymemory, # 将记忆管理器注入链 verboseTrue # 打印详细日志便于调试 ) # 4. 进行对话 print(“第一轮”) response1 conversation.predict(input“我叫李雷。”) print(f“AI: {response1}”) print(“\n第二轮”) # 注意这里直接调用predict链内部会自动处理记忆的保存和加载 response2 conversation.predict(input“我的名字是什么”) print(f“AI: {response2}”) # 理想情况下AI应该回答“李雷”。 # 5. 我们可以直接从memory中查看当前加载的记忆内容 print(“\n当前记忆变量”) print(memory.load_memory_variables({}))关键点通过将redis_history传递给ConversationBufferMemory的chat_memory参数我们就将内存记忆升级为了Redis持久化记忆。ConversationChain这个预置的链会自动在每次predict后调用memory.save_context()并在下次predict前调用memory.load_memory_variables()。4.2 优化策略ConversationBufferWindowMemory当对话很长时无限增长的记忆会带来问题。窗口记忆只保留最近的K轮。from langchain.memory import ConversationBufferWindowMemory window_memory ConversationBufferWindowMemory( chat_memoryredis_history, # 同样可以注入持久化存储 memory_key“chat_history”, k3, # 只保留最近3轮对话一轮指一次用户输入一次AI输出 return_messagesTrue ) # 创建一个新的链使用窗口记忆 conversation_with_window ConversationChain( llmllm, memorywindow_memory, verboseTrue ) # 假设之前redis_history中已有5轮对话 print(“窗口记忆加载的内容最近3轮:”) print(window_memory.load_memory_variables({})) # 你将看到只有最近3轮对话被加载到提示词中。参数k的选择k的大小需要权衡。k太小模型容易忘记重要的早期信息k太大又失去了节省Token的意义。通常需要根据具体任务和模型上下文长度来调整。例如对于处理复杂任务的Agent可能需要更大的k如10对于简单闲聊k5可能就足够了。4.3 高级策略ConversationSummaryMemory对于超长对话窗口记忆也可能不够用或者我们想记住对话的“精髓”而非所有细节。总结记忆通过调用另一个LLM来压缩历史。from langchain.memory import ConversationSummaryMemory from langchain_openai import OpenAI # 注意总结器通常使用更便宜的text-davinci-003或gpt-3.5-turbo-instruct # 创建用于总结的LLM可以与对话主模型不同 summary_llm OpenAI(temperature0, model“gpt-3.5-turbo-instruct”) summary_memory ConversationSummaryMemory( llmsummary_llm, # 关键指定用于总结的模型 memory_key“chat_history”, chat_memoryredis_history, # 持久化存储 return_messagesTrue ) conversation_with_summary ConversationChain( llmllm, # 对话主模型 memorysummary_memory, verboseTrue ) # 进行多轮对话后记忆不再是原始文本而是一个动态更新的总结。 print(“总结记忆的内容:”) print(summary_memory.load_memory_variables({})) # 输出可能是一个段落如“用户名叫李雷他喜欢蓝色预算有限正在计划一次旅行...”工作原理ConversationSummaryMemory内部维护一个“总结缓冲区”。当对话轮数累积到一定阈值或者每次对话后可配置它会将新的对话内容与旧的总结合并再次调用LLM生成一个新的、更精炼的总结。因此load_memory_variables返回的通常是这个总结文本加上可能的最新一两轮原始对话。成本与延迟考量总结记忆虽然节省了主对话模型的Token但引入了额外的LLM调用总结器会产生额外成本和延迟。需要根据应用场景评估是否划算。通常在对话非常长超过20轮且需要长期记忆核心事实时它的优势才比较明显。4.4 组合策略与自定义记忆有时单一策略不够用。LangChain允许你组合不同的记忆甚至创建自定义记忆类。例如你可以创建一个同时包含ConversationBufferWindowMemory用于短期细节和ConversationSummaryMemory用于长期概要的CombinedMemory。或者你可以基于BaseChatMemory抽象类实现一个专门记忆用户产品偏好的记忆模块它从对话历史中提取实体信息存储到独立的数据库中。自定义记忆示例思路from langchain.memory import BaseChatMemory from pydantic import BaseModel from typing import Dict, Any class EntityMemory(BaseChatMemory, BaseModel): entity_store: Dict[str, Any] {} # 用于存储实体信息的字典 entity_key: str “user_entities” # 返回的记忆变量名 def load_memory_variables(self, inputs: Dict[str, Any]) - Dict[str, Any]: # 返回存储的实体信息 return {self.entity_key: self.entity_store} def save_context(self, inputs: Dict[str, Any], outputs: Dict[str, Any]) - None: # 1. 先将原始消息保存到基础的chat_memory super().save_context(inputs, outputs) # 2. 从inputs和outputs中提取实体更新entity_store # 这里需要实现一个实体提取函数可以用LLM调用或规则匹配 new_entities extract_entities_from_messages(self.chat_memory.messages[-2:]) # 假设提取最新一轮 self.entity_store.update(new_entities) def clear(self): super().clear() self.entity_store.clear()这个自定义的EntityMemory在保存上下文时不仅会记录原始对话还会尝试提取实体并存储。在加载记忆时它会将结构化的实体信息返回可以单独用于提示词模板的某个部分实现更精准的记忆检索。5. 在复杂链与智能体Agent中集成记忆前面的例子主要使用了ConversationChain它是一个高度封装的简单链。在实际开发中我们更常构建复杂的自定义链或使用智能体。在这些场景下集成记忆需要更清晰的手动控制。5.1 在自定义LLMChain中集成记忆假设我们有一个简单的提示词模板需要显式地包含历史。from langchain.prompts import PromptTemplate from langchain.chains import LLMChain # 1. 定义提示词模板其中包含 {chat_history} 和 {input} 两个占位符 template “““你是一个友好的助手。根据以下对话历史和后续问题给出回答。 对话历史 {chat_history} 人类{input} 助手””” prompt PromptTemplate.from_template(template) # 2. 创建记忆使用窗口记忆示例 memory ConversationBufferWindowMemory(memory_key“chat_history”, k5, return_messagesFalse) # return_messagesFalse 会返回拼接好的字符串适合直接放入上述模板。 # 3. 创建链但此时记忆还没有和链绑定 llm ChatOpenAI(temperature0) chain LLMChain(llmllm, promptprompt) # 4. 手动管理记忆的保存和加载 def chat_with_memory(user_input: str): # a. 从记忆加载历史变量 memory_variables memory.load_memory_variables({}) chat_history_str memory_variables[“chat_history”] # b. 准备链的输入字典 chain_inputs { “chat_history”: chat_history_str, “input”: user_input } # c. 运行链 response chain.invoke(chain_inputs) ai_output response[“text”] # d. 将本轮交互保存到记忆 memory.save_context({“input”: user_input}, {“output”: ai_output}) return ai_output # 测试 print(chat_with_memory(“你好”)) print(chat_with_memory(“我叫王五。”)) print(chat_with_memory(“我刚才说我叫什么”))关键区别在自定义链中记忆的管理不再是自动的。你需要在格式化提示词前调用memory.load_memory_variables()获取历史。在得到模型输出后调用memory.save_context()保存本轮交互。确保你的提示词模板中包含了对应的记忆变量如{chat_history}。5.2 在智能体Agent中集成记忆智能体是能使用工具、自主决策的AI系统。让智能体拥有记忆意味着它能记住自己之前的行动、观察和与用户的交互从而做出更连贯的决策。LangChain的AgentExecutor本身就支持传入memory参数。它会自动将记忆变量通常是对话历史注入到智能体的提示词中并在每轮工具调用和最终回答后自动保存上下文。from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain.memory import ConversationBufferMemory # 1. 定义一个简单的工具例如一个计算器 def calculate(expression: str) - str: “”“计算一个数学表达式。”“” try: return str(eval(expression)) except: return “计算错误” calc_tool Tool( name“Calculator”, funccalculate, description“用于计算数学表达式。输入应该是一个有效的数学表达式字符串如 ‘2 2’ 或 ‘3 * 5’。” ) # 2. 创建记忆 agent_memory ConversationBufferMemory(memory_key“chat_history”, return_messagesTrue) # 3. 创建智能体提示词ReAct框架。注意提示词中需要包含 {chat_history} from langchain import hub prompt hub.pull(“hwchase17/react-chat”) # 这是一个预置的包含聊天历史的ReAct提示词 # 4. 创建智能体和执行器 llm ChatOpenAI(temperature0) agent create_react_agent(llm, tools[calc_tool], promptprompt) agent_executor AgentExecutor( agentagent, tools[calc_tool], memoryagent_memory, # 关键将记忆注入执行器 verboseTrue, handle_parsing_errorsTrue # 处理解析错误 ) # 5. 运行智能体 result1 agent_executor.invoke({“input”: “我的名字是特工007。”}) print(result1[“output”]) result2 agent_executor.invoke({“input”: “计算一下 25 * 4 等于多少”}) print(result2[“output”]) result3 agent_executor.invoke({“input”: “我刚才说我叫什么名字”}) # 智能体应该能记住“特工007” print(result3[“output”])注意事项提示词兼容性不是所有的Agent提示词模板都预留了{chat_history}的位置。你需要使用像“react-chat”这类专为对话设计的提示词或者自定义修改提示词模板以包含记忆变量。工具调用与记忆AgentExecutor在运行过程中会将工具调用的中间步骤Thought, Action, Observation也作为对话的一部分吗这取决于具体的Agent类型和配置。在create_react_agent中通常只有最终的回答和用户的输入会被保存到chat_history中内部的思考过程不会。如果你需要记忆Agent的推理过程可能需要更复杂的自定义记忆逻辑。记忆的粒度对于Agent除了对话历史你可能还需要记忆“它已经执行过哪些操作”、“得到了什么结果”。这超出了ConversationBufferMemory的范畴可能需要结合ConversationSummaryMemory来总结任务进度或者使用像ConversationKnowledgeGraphMemory实验性这样的高级记忆来存储结构化信息。6. 生产环境部署的考量与最佳实践将带有记忆的LangChain应用部署上线会面临一些在开发环境中不常见的问题。6.1 会话Session管理这是生产环境的基石。你必须建立一个稳固的会话ID生成和传递机制。Web后端如FastAPIfrom fastapi import FastAPI, Request from uuid import uuid4 from langchain.memory import RedisChatMessageHistory app FastAPI() # 假设有一个全局的Redis连接池 app.post(“/chat”) async def chat_endpoint(request: Request, user_input: str): # 1. 获取或创建session_id # 方式A从已登录用户的身份信息获取 # user_id request.state.user.id # session_id f”user_{user_id}” # 方式B为匿名会话使用Cookie或前端生成的UUID session_id request.cookies.get(“session_id”) if not session_id: session_id str(uuid4()) # 需要将session_id通过Set-Cookie返回给前端 # 2. 基于session_id创建记忆历史 history RedisChatMessageHistory( session_idsession_id, urlREDIS_URL, ttl24*3600 # 例如会话保持24小时 ) # 3. 创建记忆管理器和链此处应复用LLM和链的配置避免重复创建 memory ConversationBufferWindowMemory(chat_memoryhistory, k10) # ... 后续的链调用逻辑 return {“response”: ai_output, “session_id”: session_id}无状态服务确保你的服务是无状态的所有状态即记忆都存储在外部如Redis。这样服务实例可以水平扩展任何实例都能处理任何用户的请求只要它们能访问同一个Redis集群。6.2 性能与可扩展性Redis连接管理使用连接池。不要在每次请求中创建新的Redis连接。像redis-py这样的客户端库通常默认使用连接池但要确保池的大小配置合理。记忆存储的序列化/反序列化大量消息的读写可能成为瓶颈。确保Redis服务器有足够的内存和网络带宽。对于超高频应用可以考虑对历史消息进行压缩后再存储虽然RedisChatMessageHistory本身不提供此功能但可以自定义子类实现。LLM调用成本使用ConversationSummaryMemory或ConversationBufferWindowMemory来控制发送给大模型的Token数量是控制成本最直接有效的方法。监控你的Token使用量。6.3 记忆的隐私与安全数据加密存储在Redis或其他数据库中的对话历史是明文。如果涉及敏感信息应考虑在存储前进行加密或者在传输层确保Redis连接是加密的使用TLS。数据合规根据用户所在地的法律法规如GDPR你可能需要提供让用户查看、导出和删除其对话历史的功能。这要求你的系统能根据session_id或user_id定位和操作所有相关数据。记忆隔离绝对避免会话ID混淆。做好代码审查和测试防止因Bug导致不同用户的记忆串通。6.4 监控与调试日志记录在关键点记录日志例如记忆保存/加载时、会话ID创建时。但注意不要记录完整的消息内容以免泄露隐私可以记录消息长度、会话ID和操作结果。可视化检查为内部管理员提供工具允许他们通过安全的界面输入session_id来查看对应的对话历史脱敏后这在排查用户问题时非常有用。性能指标监控平均对话轮数、记忆加载耗时、Redis内存使用量等指标以便提前发现容量问题。7. 常见问题排查与实战技巧在实际开发中你肯定会遇到各种关于记忆的问题。下面是一些典型场景和解决方法。7.1 问题模型好像“失忆”了不记得之前说过的话。排查步骤检查session_id这是最常见的原因。确保前后请求使用的是完全相同的session_id。在Web应用中检查前端是否正确地传递了会话标识如Cookie、Token后端是否正确地解析并使用了它。检查记忆是否被保存在调用memory.save_context()后立即检查存储后端。对于Redis可以直接用redis-cli命令查看对应key是否存在且内容是否正确。redis-cli LRANGE “message_store:your_session_id” 0 -1检查记忆是否被加载在调用memory.load_memory_variables()后打印其返回值。确认返回的字典中包含你期望的memory_key并且其值不为空。检查提示词模板确认你的提示词模板中包含了正确的记忆变量占位符如{chat_history}并且链在格式化提示词时传入了这个变量。检查return_messages参数如果你的提示词模板期望一个字符串但memory.load_memory_variables()返回的是一个Message对象列表当return_messagesTrue时会导致格式化错误。反之亦然。确保两者匹配。ConversationChain的默认模板通常期望字符串所以其默认记忆的return_messagesFalse。7.2 问题对话历史太长导致API调用超时或Token超限。解决方案切换到ConversationBufferWindowMemory这是最简单的方案设置一个合理的k值。使用ConversationSummaryMemory对于需要长期记忆核心事实的超长对话这是更好的选择。动态窗口大小实现一个自定义的记忆类根据当前历史消息的总Token数可以用tiktoken库估算来动态调整加载到提示词中的历史消息数量。分片记忆将长对话按主题或时间分割成多个会话每个会话有独立的session_id。这需要前端UI的支持让用户可以选择“开始新话题”。7.3 问题我想在记忆里存储除了对话文本以外的自定义数据。解决方案继承BaseChatMemory或现有的记忆类重写load_memory_variables和save_context方法。在save_context中你可以解析输入输出提取自定义信息存储到额外的字段或另一个数据库中。在load_memory_variables中返回一个包含这些自定义信息的字典。例如创建一个记忆用户偏好的记忆类class UserPreferenceMemory(BaseChatMemory): preference_store: Dict {} preference_key: str “user_prefs” def load_memory_variables(self, inputs): return {self.preference_key: json.dumps(self.preference_store)} def save_context(self, inputs, outputs): super().save_context(inputs, outputs) # 假设我们有一个函数能从最新对话中提取偏好 new_prefs extract_preferences(self.chat_memory.messages[-2:]) self.preference_store.update(new_prefs) # 这里还可以将preference_store持久化到数据库7.4 实战技巧记忆的预热与初始化有时你希望智能体在开始对话时就拥有一些背景知识。这可以通过“系统消息”或预填充记忆来实现。# 方法1在ChatMessageHistory中预添加系统消息 history RedisChatMessageHistory(session_id“user_123”, urlREDIS_URL) if len(history.messages) 0: # 只有新会话才初始化 history.add_message(SystemMessage(content“你是一个专业的编程助手擅长Python和JavaScript。请用中文回答。”)) history.add_ai_message(AIMessage(content“你好我是一个专业的编程助手精通Python和JavaScript。请问有什么可以帮您”)) # 方法2在ConversationBufferMemory初始化时通过input_key和output_key预填充 memory ConversationBufferMemory() # 手动保存一段初始上下文模拟之前的对话 memory.save_context( {“input”: “请记住你的角色是专业编程助手。”}, {“output”: “明白我已设定角色为专业编程助手擅长Python和JavaScript。”} ) # 现在这段“记忆”已经存在后续对话会基于此进行。7.5 实战技巧处理流式输出与记忆当使用LLM的流式输出时记忆的保存时机需要注意。你需要在流式响应完全结束后再调用memory.save_context()以确保保存的是完整的AI回复。from langchain.callbacks.streaming_stdout import StreamingStdOutCallbackHandler memory ConversationBufferMemory() chain ConversationChain(llmllm, memorymemory) def stream_chat(user_input): # 注意这里不能直接使用chain.predict因为它会处理记忆。 # 我们需要手动处理流程。 # 1. 加载历史 memory_vars memory.load_memory_variables({}) # 2. 构建提示词此处简化实际需根据你的模板来 full_prompt f”History: {memory_vars[‘chat_history’]}\nHuman: {user_input}\nAI:” # 3. 调用LLM流式接口 full_response “” for chunk in llm.stream(full_prompt): print(chunk.content, end“”, flushTrue) full_response chunk.content print() # 换行 # 4. 流式结束后保存上下文 memory.save_context({“input”: user_input}, {“output”: full_response})记忆是构建有深度、有价值的大模型应用不可或缺的一环。从简单的对话历史持久化到复杂的记忆策略与智能体集成LangChain提供了一套灵活而强大的工具箱。理解其核心组件ChatMessageHistory与BaseChatMemory的关系掌握从RedisChatMessageHistory进行持久化到使用ConversationBufferWindowMemory、ConversationSummaryMemory等策略进行优化是迈入实战的关键。在生产中务必重视会话管理、性能、安全与监控。记住好的记忆系统是透明的它让用户感觉AI始终在同一个频道上而这正是打造卓越AI体验的秘诀。