1. 从“健忘”到“有记忆”为什么AI Agent需要一个记忆系统如果你玩过早期的聊天机器人或者用过一些基础的LLM API你可能会有一个直观的感受它们很“健忘”。你告诉它“我叫张三”下一句问它“我叫什么”它大概率会一脸茫然地重新问你。这种“对话即焚”的模式对于一次性的问答或许够用但对于一个需要长期运行、持续与用户和环境交互的AI Agent来说是致命的短板。想象一下你雇佣了一个私人助理他每次和你对话后都会清空大脑忘记你的所有偏好、待办事项和之前的对话历史这样的助理显然无法胜任任何复杂工作。这就是Memory记忆系统在AI Agent框架中变得至关重要的原因。它不是一个可有可无的装饰品而是Agent具备“智能体”属性的核心基础设施之一。一个没有记忆的Agent就像一台没有硬盘的电脑每次重启后都是一片空白无法积累经验无法形成连贯的“人格”或“工作流”。在OpenHands这类AI Agent框架中Memory模块正是为了解决这个问题而设计的。它负责将Agent在运行过程中产生的信息——用户输入、自身思考、工具调用结果、环境反馈——进行结构化或非结构化的存储、检索和管理让Agent能够“记住过去”从而做出更连贯、更个性化的决策。简单来说Memory让Agent从“单次反应的函数”进化成了“持续学习的实体”。这不仅仅是技术上的一个模块更是决定了Agent能否在真实、复杂的场景中落地应用的关键。接下来我们就深入OpenHands的Memory模块看看它是如何被设计和实现的以及我们在实际开发中如何用好它、避开它的坑。2. OpenHands Memory模块的架构与核心组件拆解OpenHands的Memory模块并非一个单一的黑盒而是一个由多种记忆类型和存储后端组成的复合系统。理解它的架构是进行有效定制和问题排查的基础。2.1 记忆的“类型学”短期、长期与会话记忆在OpenHands的设计中记忆被抽象为几种不同的类型每种类型服务于不同的目的有着不同的生命周期和容量。短期记忆Short-Term Memory这通常指的是Agent在当前一次“推理循环”或单次对话轮次中所持有的上下文。在LLM驱动的Agent中这直接对应着发送给大语言模型的Prompt上下文窗口。例如当你让Agent分析一份文档时这份文档的内容、你当前的问题以及Agent刚刚生成的思考过程都存在于短期记忆中。它的特点是容量有限受限于模型上下文长度、存取速度快、但生命周期极短一旦推理结束或对话轮次切换如果没有被特意保存就会被丢弃。在OpenHands中这部分通常由ConversationBufferMemory或类似的组件管理。长期记忆Long-Term Memory这是Agent的“知识库”或“经验库”用于存储需要跨会话、跨任务持久化的信息。例如用户的个人偏好“喜欢用Markdown格式回复”、从历史对话中总结出的用户习惯、或者通过工具学习到的特定领域知识。长期记忆的容量理论上可以非常大取决于存储后端但检索速度相对较慢需要设计高效的索引和查询机制。OpenHands通常将这类记忆存储在向量数据库如Chroma, Pinecone或传统数据库中通过VectorStoreRetrieverMemory等组件实现。会话记忆Conversation Memory这是一个特别重要的类别它专门用于维护多轮对话的连贯性。它不仅仅是保存历史消息的列表更重要的是能理解对话的脉络。例如它能记住用户在上文说“帮我看一下北京的天气”然后在几轮关于“穿什么衣服”的讨论后用户突然问“那明天呢”会话记忆需要能关联到“北京”和“天气”这个上下文。OpenHands中的ConversationSummaryMemory或ConversationBufferWindowMemory就属于此类它们可能通过摘要压缩历史、或只保留最近N轮对话来平衡上下文长度和连贯性需求。理解这三者的区别至关重要。很多开发者在设计Agent时错误地将所有信息都塞进短期记忆导致上下文爆炸或者把所有对话记录都当作长期记忆存储导致检索效率低下且包含大量噪音。正确的做法是根据信息的价值和使用频率进行分层存储。2.2 存储后端从内存到向量数据库记忆的类型决定了信息的逻辑组织方式而存储后端则决定了这些信息物理上存在哪里、如何被读写。OpenHands支持多种后端选择哪种取决于你的应用场景。内存存储最简单、最快的方式使用Python的字典或列表在程序运行时保存在内存中。ConversationBufferMemory的默认后端就是内存。它的优点是零延迟、实现简单适合原型验证或短期运行的Agent。致命缺点是无持久化进程重启记忆全部丢失。绝对不要在生产环境中将核心记忆仅放在内存里。文件系统存储将记忆序列化如用JSON、Pickle后保存到本地文件。这解决了持久化问题适合单机部署、记忆量不大的场景。但它在并发写入、分布式部署方面有天然缺陷并且随着文件变大加载和检索会变慢。数据库存储使用SQLite、PostgreSQL、MySQL等关系型或文档型数据库。这提供了强大的结构化查询能力、事务支持和良好的并发性。适合存储高度结构化的记忆例如用户配置、任务状态等。OpenHands可以通过自定义Memory类来集成这些数据库。向量数据库存储这是处理非结构化文本记忆如对话历史、文档片段的利器。向量数据库如Chroma, Weaviate, Qdrant, Pinecone将文本通过嵌入模型Embedding Model转换为高维向量并存储起来。当需要检索相关记忆时将当前查询也转换为向量在数据库中进行相似度搜索如余弦相似度。这使得Agent能够进行“语义检索”而不仅仅是关键词匹配。例如即使用户问“那个关于水果的讨论”向量检索也能找到之前谈论“苹果和香蕉营养价值”的记录。VectorStoreRetrieverMemory就是基于此构建它是实现Agent“长期经验积累”和“上下文关联”的核心。注意向量数据库的选择不是随意的。对于本地开发和小型应用轻量级的Chroma是首选。对于需要高可用、分布式的生产环境可能需要考虑Weaviate或云服务如Pinecone。同时嵌入模型的选择OpenAI的text-embedding-ada-002、本地部署的BGE模型等会极大影响检索质量需要根据语料和成本权衡。2.3 Memory模块在Agent工作流中的位置Memory不是一个孤立的组件。在OpenHands的Agent执行循环中Memory模块在关键节点被调用动作前Pre-action在Agent根据输入决定下一步行动思考、调用工具之前会从Memory中检索相关的历史信息并将其注入到本次推理的Prompt上下文中。这确保了Agent的决策是基于“记忆”做出的。动作后Post-action在Agent执行完一个动作如给出最终答案、调用工具得到结果后会将本次交互中有价值的信息写回Memory。这完成了记忆的“学习”和“积累”过程。这个“检索-推理-存储”的循环是Agent具备持续学习能力的基础。框架的职责是提供标准的接口如load_memory_variables,save_context让开发者可以方便地插入自定义的记忆逻辑。3. 实战在OpenHands中配置与使用Memory理论讲完了我们来看具体怎么用。假设我们要构建一个“旅行规划助手”Agent它需要记住用户的旅行偏好和历史上的目的地讨论。3.1 基础配置让Agent记住对话首先我们从最简单的会话记忆开始。使用ConversationBufferMemory可以让Agent记住当前会话的所有聊天内容。from openhands import OpenHands from openhands.memory import ConversationBufferMemory # 初始化记忆组件 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # memory_key 指定了在Prompt中访问这段记忆的变量名 # return_messagesTrue 会返回Message对象列表方便某些LLM ChatModel使用 # 创建Agent时传入memory agent OpenHands( llmyour_llm, # 你的LLM实例 toolsyour_tools, # 你的工具列表 memorymemory, agent_executor_kwargs{verbose: True} ) # 进行多轮对话 result1 agent.run(我想去一个温暖的海边度假有什么推荐吗) # Agent可能会推荐三亚、普吉岛等 result2 agent.run(上一个地方听起来不错不过预算有点高有更经济的选择吗) # 因为memory存在Agent知道“上一个地方”指的是哪里并能在此基础上推荐消费更低的目的地如国内某些海湾。这段代码跑起来你会发现第二轮对话的Prompt里会自动包含第一轮的对话历史。这就是Memory最基本的作用。3.2 进阶使用结合向量数据库实现长期记忆仅仅记住当前会话不够。我们希望助手能记住用户说过“我海鲜过敏”或者“我喜欢历史文化古迹”并在未来的所有旅行推荐中都考虑这一点。这就需要长期记忆。这里我们使用VectorStoreRetrieverMemory配合Chroma向量数据库。from openhands import OpenHands from openhands.memory import VectorStoreRetrieverMemory from openhands.embeddings import OpenAIEmbeddings # 或其他Embedding类 from openhands.vectorstores import Chroma import chromadb # 1. 准备嵌入模型 embeddings OpenAIEmbeddings(openai_api_keyyour_key) # 或者 HuggingFaceEmbeddings # 2. 创建或加载向量数据库 persist_directory ./chroma_db vectordb Chroma( collection_nameuser_preferences, embedding_functionembeddings, persist_directorypersist_directory ) # 3. 创建检索器 retriever vectordb.as_retriever(search_kwargs{k: 2}) # 每次检索最相关的2条记忆 # 4. 创建基于向量检索的记忆体 memory VectorStoreRetrieverMemory( retrieverretriever, memory_keylong_term_memory, input_keyinput, # 指定从哪个输入变量提取文本进行检索 return_docsTrue # 返回检索到的文档原文 ) # 5. 创建Agent agent OpenHands( llmyour_llm, toolsyour_tools, memorymemory, verboseTrue ) # 6. 先存储一些长期记忆通常这会在用户交互中动态完成 memory.save_context( {input: 用户提到他对海鲜严重过敏预订餐厅和选择目的地时需要避开海鲜丰富的地区。}, {output: 已记录用户海鲜过敏偏好。} ) memory.save_context( {input: 用户特别喜欢参观博物馆和历史遗迹对自然风光兴趣一般。}, {output: 已记录用户对历史文化景点的偏好。} ) # 7. 进行查询 result agent.run(请为我推荐一个适合度假的欧洲城市。) # 在生成推荐时Agent的Prompt中会包含从向量库检索到的“海鲜过敏”和“喜欢博物馆”的记忆从而避免推荐威尼斯海鲜多而更倾向于推荐罗马、柏林等历史文化名城。在这个例子中记忆的存储和检索是基于语义的。即使用户在提问时没有直接说“我不吃海鲜”只要他问的问题与“饮食”、“度假”相关相关的过敏记忆就有可能被检索出来影响Agent的决策。3.3 记忆的定制化实现一个混合记忆系统在实际复杂应用中我们往往需要混合多种记忆。例如既要维护最近10轮对话的流畅性会话记忆又要能从海量历史中检索关键事实长期记忆。OpenHands允许我们组合多个Memory对象。from openhands.memory import ConversationBufferWindowMemory, VectorStoreRetrieverMemory, CombinedMemory # 短期会话记忆只保留最近5轮对话 conversation_memory ConversationBufferWindowMemory( memory_keyrecent_chat, k5, input_keyinput, output_keyoutput ) # 长期向量记忆 long_term_memory VectorStoreRetrieverMemory( retrieveryour_retriever, memory_keyknowledge, input_keyinput ) # 组合记忆 combined_memory CombinedMemory(memories[conversation_memory, long_term_memory]) # 在创建Agent时使用这个组合记忆 agent OpenHands( llmyour_llm, memorycombined_memory, # ... 其他参数 )这样在每次Agent运行时combined_memory会分别从两个子记忆中加载变量并合并到一个大的上下文字典中供Prompt使用。你需要精心设计Prompt模板来区分和使用recent_chat和knowledge这两个不同的记忆变量。4. 避坑指南Memory模块的常见问题与优化策略Memory模块用起来简单但想用好、用稳里面有不少坑。下面是我在实际项目中总结的一些典型问题和解决方案。4.1 上下文窗口爆炸与记忆压缩问题最经典的问题。使用ConversationBufferMemory无限制地保存所有对话很快就会导致发送给LLM的Prompt超出其上下文长度限制如GPT-4的8K、32K或本地模型的2K、4K轻则请求被拒绝重则丢失关键的上文信息。解决方案使用ConversationBufferWindowMemory这是最简单的方案只保留最近K轮对话。缺点是会主动遗忘更早的对话可能破坏超长程的连贯性。使用ConversationSummaryMemory在每轮对话后用一个单独的LLM调用去总结之前的对话历史只把摘要存入记忆下次用摘要作为上下文。这能极大压缩长度但存在摘要信息失真、丢失细节的风险且增加了LLM调用成本和延迟。动态上下文管理实现更智能的策略。例如不是简单截断而是基于重要性对历史对话进行打分只保留高分片段。或者将超长的历史对话分段存入向量数据库在需要时进行相关性检索只召回最相关的片段注入上下文。这需要较多的自定义开发。我的实操心得对于大多数任务型对话AgentConversationBufferWindowMemoryk10~20配合一个存储关键事实的VectorStoreRetrieverMemory是性价比最高的方案。将具体的任务参数、用户属性等存入向量长期记忆将最近的对话流程留在窗口记忆里。4.2 向量检索的“无关记忆”干扰问题配置了VectorStoreRetrieverMemory后发现Agent有时会被检索到的无关记忆带偏。比如用户在讨论“编程Python”却检索到了很久以前关于“蛇Python”的玩笑话导致回答混乱。解决方案优化检索参数调整search_kwargs。k值不宜过大通常2-5条足够。可以尝试使用search_typemmr最大边际相关性在保证相关性的同时增加结果的多样性避免返回高度重复的片段。记忆元数据过滤在向向量库存储记忆时为每条记忆添加丰富的元数据metadata如session_id,topic,timestamp,memory_typefact, preference, conversation等。在检索时通过元数据过滤器进行预筛选。例如只检索memory_type为preference且topic包含diet的记忆。Chroma、Weaviate等数据库都支持元数据过滤。提升嵌入模型质量检索的相关性根本取决于嵌入模型。通用模型如OpenAI的text-embedding-ada-002在通用领域表现好但在你的专业领域如医疗、法律可能不佳。考虑使用在该领域微调过的嵌入模型或者用你领域的语料对开源模型进行微调。记忆的“写”策略不要什么都往长期记忆里存。设计规则只存储经过提炼的、高价值的信息。例如在用户表达明确偏好“我不喜欢X”或陈述重要事实“我的项目截止日是下周五”时才触发存储。可以在Agent的输出环节增加一个“记忆评估”步骤由LLM判断当前交互是否值得存入长期记忆。4.3 记忆的冲突与更新问题用户之前说“我喜欢安静”但最近一次聊天又说“偶尔热闹一下也不错”。向量库里存着两条矛盾的记忆检索时可能同时出现让Agent困惑。解决方案基于时间的衰减或优先级为记忆条目添加时间戳和置信度权重。新的记忆拥有更高的权重或者在检索结果排序时更新时间更近的记忆排在前面。可以在元数据中实现。主动记忆管理实现一个记忆合并或冲突解决机制。当检测到新旧记忆冲突时可以通过LLM判断触发一个解决流程要么用新记忆覆盖旧记忆要么将两者合并成一条更精确的记忆如“用户通常喜欢安静但在周末或特殊场合不排斥热闹的环境”。这同样需要额外的LLM调用和逻辑设计。实用建议对于简单应用可以定期如每周手动或自动扫描向量库清理过时或低质量的记忆条目。对于复杂应用记忆的冲突解决是一个高级课题可能需要引入知识图谱的概念来建立记忆间的关系。4.4 性能瓶颈检索延迟与存储开销问题当记忆条目达到数万、数十万时向量检索可能变慢影响Agent的响应速度。同时存储嵌入向量的空间开销也不小。优化策略索引优化使用支持高效近似最近邻搜索ANN的向量数据库如Faiss、HNSWlib。这些库为大规模向量检索做了深度优化。Chroma的后端默认就支持HNSW。分层存储将记忆分级。高频、热点的记忆如用户最近一周的偏好放在内存或更快的缓存里如Redis全量的长期记忆放在向量数据库。检索时先查缓存未命中再查向量库。量化与压缩对于嵌入向量可以考虑使用量化技术如PQ - Product Quantization在可接受的精度损失下大幅减少存储空间和加速检索。异步写入save_context操作不一定非要同步阻塞Agent的响应。可以将其放入一个后台任务队列异步执行优先保证Agent响应的实时性。5. 超越基础设计更智能的记忆模式OpenHands提供的Memory组件是优秀的起点但要构建真正强大的Agent我们往往需要在其基础上进行定制和扩展。这里分享几个进阶的设计思路。5.1 记忆的“反思”与“提炼”机制原始的对话记录是嘈杂的。让Agent具备“反思”能力定期或基于特定触发条件对记忆进行总结、提炼可以产生更高质量的记忆。例如在完成一个复杂的多步骤任务如规划一次旅行后触发一个“反思”步骤LLM调用“请回顾刚才为用户规划旅行的整个对话过程提炼出用户的核心需求如预算、时间、兴趣点和做出的关键决策如选择了A航班、B酒店。”存储将LLM生成的这份精炼的总结作为一条高质量的“旅行规划案例”记忆存入向量库而不是存储几十轮原始对话。未来当用户再次要求规划旅行时这份总结能提供更清晰、更结构化的参考。5.2 基于记忆的个性化Prompt工程记忆的价值最终体现在Prompt里。我们可以设计更精巧的Prompt模板来利用不同类型的记忆。from openhands.prompts import PromptTemplate template 你是一个旅行规划助手。请根据以下信息为用户提供建议。 # 关于用户的长期了解长期记忆 {long_term_memory} # 最近的对话历史短期记忆 {recent_chat} # 用户当前的问题 {input} 请开始你的回答 prompt PromptTemplate(input_variables[long_term_memory, recent_chat, input], templatetemplate) # 在Agent配置中使用这个自定义的Prompt通过清晰的Prompt结构引导LLM更好地理解和运用不同来源、不同抽象层次的记忆。5.3 将记忆与工具调用结合记忆不仅可以用于生成回答还可以指导工具调用。例如一个“智能家居控制”Agent的记忆里存储了“用户通常在晚上10点关闭客厅灯”。当用户在晚上9点55分说“我准备睡觉了”Agent除了回复“好的晚安”还可以自动调用关灯的工具因为它从记忆中推理出了用户的潜在意图。这需要记忆模块与工具决策逻辑有更深的集成。实现上可以在Agent的决策循环中让记忆检索的结果不仅填充到Prompt也作为工具选择Tool Routing的一个输入特征。例如如果检索到的记忆强烈关联到某个工具如“关灯”则提高该工具被选择的权重。5.4 实现一个简单的“记忆重要性”评分模型不是所有对话都值得记住。我们可以训练或设计一个简单的模型甚至是用Prompt让LLM自己判断为每一段潜在的记忆候选即一轮对话的输入输出对打分。# 伪代码示例 def should_save_to_long_term_memory(user_input, agent_output, conversation_context): # 规则1用户明确要求记住 if 记住 in user_input or 记一下 in user_input: return True, 1.0 # 规则2LLM判断通过一个简单的分类Prompt judgment_prompt f 判断以下对话片段是否包含值得长期记住的用户个人信息或重要事实 用户{user_input} 助手{agent_output} 只回答是或否。 llm_judgment llm.predict(judgment_prompt) if 是 in llm_judgment: return True, 0.8 # 返回True和一个重要性分数 # 规则3检测到关键实体如日期、地点、产品名 if extract_important_entities(user_input): return True, 0.6 return False, 0.0 # 在Agent的post-action步骤中调用 should_save, importance_score should_save_to_long_term_memory(input, output, context) if should_save: memory.save_context({input: input}, {output: output}, metadata{importance: importance_score})通过这种方式我们可以构建一个质量更高、噪音更少的记忆库提升后续检索的效率和质量。Memory系统是AI Agent从“玩具”走向“工具”的灵魂所在。它决定了Agent的“智商”和“情商”——能否从历史中学习能否提供连贯、个性化的服务。OpenHands提供了一个灵活、可扩展的Memory框架但真正的挑战在于如何根据你的具体业务场景设计出合理的记忆分类、存储、检索和更新策略。这没有银弹需要你在理解基本原理的基础上不断实验、迭代和优化。从我个人的经验来看从一个简单的ConversationBufferWindowMemory开始逐步引入向量长期记忆并小心处理上下文长度和检索质量是大多数项目最稳妥的演进路径。记住一个好的记忆系统应该是让Agent变得更聪明而不是更慢或更混乱。 
长河君 · 2026/8/8 12:22:47 · 阅读 1.2k AI Agent记忆系统设计：从原理到OpenHands实战应用
1. 从“健忘”到“有记忆”为什么AI Agent需要一个记忆系统如果你玩过早期的聊天机器人或者用过一些基础的LLM API你可能会有一个直观的感受它们很“健忘”。你告诉它“我叫张三”下一句问它“我叫什么”它大概率会一脸茫然地重新问你。这种“对话即焚”的模式对于一次性的问答或许够用但对于一个需要长期运行、持续与用户和环境交互的AI Agent来说是致命的短板。想象一下你雇佣了一个私人助理他每次和你对话后都会清空大脑忘记你的所有偏好、待办事项和之前的对话历史这样的助理显然无法胜任任何复杂工作。这就是Memory记忆系统在AI Agent框架中变得至关重要的原因。它不是一个可有可无的装饰品而是Agent具备“智能体”属性的核心基础设施之一。一个没有记忆的Agent就像一台没有硬盘的电脑每次重启后都是一片空白无法积累经验无法形成连贯的“人格”或“工作流”。在OpenHands这类AI Agent框架中Memory模块正是为了解决这个问题而设计的。它负责将Agent在运行过程中产生的信息——用户输入、自身思考、工具调用结果、环境反馈——进行结构化或非结构化的存储、检索和管理让Agent能够“记住过去”从而做出更连贯、更个性化的决策。简单来说Memory让Agent从“单次反应的函数”进化成了“持续学习的实体”。这不仅仅是技术上的一个模块更是决定了Agent能否在真实、复杂的场景中落地应用的关键。接下来我们就深入OpenHands的Memory模块看看它是如何被设计和实现的以及我们在实际开发中如何用好它、避开它的坑。2. OpenHands Memory模块的架构与核心组件拆解OpenHands的Memory模块并非一个单一的黑盒而是一个由多种记忆类型和存储后端组成的复合系统。理解它的架构是进行有效定制和问题排查的基础。2.1 记忆的“类型学”短期、长期与会话记忆在OpenHands的设计中记忆被抽象为几种不同的类型每种类型服务于不同的目的有着不同的生命周期和容量。短期记忆Short-Term Memory这通常指的是Agent在当前一次“推理循环”或单次对话轮次中所持有的上下文。在LLM驱动的Agent中这直接对应着发送给大语言模型的Prompt上下文窗口。例如当你让Agent分析一份文档时这份文档的内容、你当前的问题以及Agent刚刚生成的思考过程都存在于短期记忆中。它的特点是容量有限受限于模型上下文长度、存取速度快、但生命周期极短一旦推理结束或对话轮次切换如果没有被特意保存就会被丢弃。在OpenHands中这部分通常由ConversationBufferMemory或类似的组件管理。长期记忆Long-Term Memory这是Agent的“知识库”或“经验库”用于存储需要跨会话、跨任务持久化的信息。例如用户的个人偏好“喜欢用Markdown格式回复”、从历史对话中总结出的用户习惯、或者通过工具学习到的特定领域知识。长期记忆的容量理论上可以非常大取决于存储后端但检索速度相对较慢需要设计高效的索引和查询机制。OpenHands通常将这类记忆存储在向量数据库如Chroma, Pinecone或传统数据库中通过VectorStoreRetrieverMemory等组件实现。会话记忆Conversation Memory这是一个特别重要的类别它专门用于维护多轮对话的连贯性。它不仅仅是保存历史消息的列表更重要的是能理解对话的脉络。例如它能记住用户在上文说“帮我看一下北京的天气”然后在几轮关于“穿什么衣服”的讨论后用户突然问“那明天呢”会话记忆需要能关联到“北京”和“天气”这个上下文。OpenHands中的ConversationSummaryMemory或ConversationBufferWindowMemory就属于此类它们可能通过摘要压缩历史、或只保留最近N轮对话来平衡上下文长度和连贯性需求。理解这三者的区别至关重要。很多开发者在设计Agent时错误地将所有信息都塞进短期记忆导致上下文爆炸或者把所有对话记录都当作长期记忆存储导致检索效率低下且包含大量噪音。正确的做法是根据信息的价值和使用频率进行分层存储。2.2 存储后端从内存到向量数据库记忆的类型决定了信息的逻辑组织方式而存储后端则决定了这些信息物理上存在哪里、如何被读写。OpenHands支持多种后端选择哪种取决于你的应用场景。内存存储最简单、最快的方式使用Python的字典或列表在程序运行时保存在内存中。ConversationBufferMemory的默认后端就是内存。它的优点是零延迟、实现简单适合原型验证或短期运行的Agent。致命缺点是无持久化进程重启记忆全部丢失。绝对不要在生产环境中将核心记忆仅放在内存里。文件系统存储将记忆序列化如用JSON、Pickle后保存到本地文件。这解决了持久化问题适合单机部署、记忆量不大的场景。但它在并发写入、分布式部署方面有天然缺陷并且随着文件变大加载和检索会变慢。数据库存储使用SQLite、PostgreSQL、MySQL等关系型或文档型数据库。这提供了强大的结构化查询能力、事务支持和良好的并发性。适合存储高度结构化的记忆例如用户配置、任务状态等。OpenHands可以通过自定义Memory类来集成这些数据库。向量数据库存储这是处理非结构化文本记忆如对话历史、文档片段的利器。向量数据库如Chroma, Weaviate, Qdrant, Pinecone将文本通过嵌入模型Embedding Model转换为高维向量并存储起来。当需要检索相关记忆时将当前查询也转换为向量在数据库中进行相似度搜索如余弦相似度。这使得Agent能够进行“语义检索”而不仅仅是关键词匹配。例如即使用户问“那个关于水果的讨论”向量检索也能找到之前谈论“苹果和香蕉营养价值”的记录。VectorStoreRetrieverMemory就是基于此构建它是实现Agent“长期经验积累”和“上下文关联”的核心。注意向量数据库的选择不是随意的。对于本地开发和小型应用轻量级的Chroma是首选。对于需要高可用、分布式的生产环境可能需要考虑Weaviate或云服务如Pinecone。同时嵌入模型的选择OpenAI的text-embedding-ada-002、本地部署的BGE模型等会极大影响检索质量需要根据语料和成本权衡。2.3 Memory模块在Agent工作流中的位置Memory不是一个孤立的组件。在OpenHands的Agent执行循环中Memory模块在关键节点被调用动作前Pre-action在Agent根据输入决定下一步行动思考、调用工具之前会从Memory中检索相关的历史信息并将其注入到本次推理的Prompt上下文中。这确保了Agent的决策是基于“记忆”做出的。动作后Post-action在Agent执行完一个动作如给出最终答案、调用工具得到结果后会将本次交互中有价值的信息写回Memory。这完成了记忆的“学习”和“积累”过程。这个“检索-推理-存储”的循环是Agent具备持续学习能力的基础。框架的职责是提供标准的接口如load_memory_variables,save_context让开发者可以方便地插入自定义的记忆逻辑。3. 实战在OpenHands中配置与使用Memory理论讲完了我们来看具体怎么用。假设我们要构建一个“旅行规划助手”Agent它需要记住用户的旅行偏好和历史上的目的地讨论。3.1 基础配置让Agent记住对话首先我们从最简单的会话记忆开始。使用ConversationBufferMemory可以让Agent记住当前会话的所有聊天内容。from openhands import OpenHands from openhands.memory import ConversationBufferMemory # 初始化记忆组件 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # memory_key 指定了在Prompt中访问这段记忆的变量名 # return_messagesTrue 会返回Message对象列表方便某些LLM ChatModel使用 # 创建Agent时传入memory agent OpenHands( llmyour_llm, # 你的LLM实例 toolsyour_tools, # 你的工具列表 memorymemory, agent_executor_kwargs{verbose: True} ) # 进行多轮对话 result1 agent.run(我想去一个温暖的海边度假有什么推荐吗) # Agent可能会推荐三亚、普吉岛等 result2 agent.run(上一个地方听起来不错不过预算有点高有更经济的选择吗) # 因为memory存在Agent知道“上一个地方”指的是哪里并能在此基础上推荐消费更低的目的地如国内某些海湾。这段代码跑起来你会发现第二轮对话的Prompt里会自动包含第一轮的对话历史。这就是Memory最基本的作用。3.2 进阶使用结合向量数据库实现长期记忆仅仅记住当前会话不够。我们希望助手能记住用户说过“我海鲜过敏”或者“我喜欢历史文化古迹”并在未来的所有旅行推荐中都考虑这一点。这就需要长期记忆。这里我们使用VectorStoreRetrieverMemory配合Chroma向量数据库。from openhands import OpenHands from openhands.memory import VectorStoreRetrieverMemory from openhands.embeddings import OpenAIEmbeddings # 或其他Embedding类 from openhands.vectorstores import Chroma import chromadb # 1. 准备嵌入模型 embeddings OpenAIEmbeddings(openai_api_keyyour_key) # 或者 HuggingFaceEmbeddings # 2. 创建或加载向量数据库 persist_directory ./chroma_db vectordb Chroma( collection_nameuser_preferences, embedding_functionembeddings, persist_directorypersist_directory ) # 3. 创建检索器 retriever vectordb.as_retriever(search_kwargs{k: 2}) # 每次检索最相关的2条记忆 # 4. 创建基于向量检索的记忆体 memory VectorStoreRetrieverMemory( retrieverretriever, memory_keylong_term_memory, input_keyinput, # 指定从哪个输入变量提取文本进行检索 return_docsTrue # 返回检索到的文档原文 ) # 5. 创建Agent agent OpenHands( llmyour_llm, toolsyour_tools, memorymemory, verboseTrue ) # 6. 先存储一些长期记忆通常这会在用户交互中动态完成 memory.save_context( {input: 用户提到他对海鲜严重过敏预订餐厅和选择目的地时需要避开海鲜丰富的地区。}, {output: 已记录用户海鲜过敏偏好。} ) memory.save_context( {input: 用户特别喜欢参观博物馆和历史遗迹对自然风光兴趣一般。}, {output: 已记录用户对历史文化景点的偏好。} ) # 7. 进行查询 result agent.run(请为我推荐一个适合度假的欧洲城市。) # 在生成推荐时Agent的Prompt中会包含从向量库检索到的“海鲜过敏”和“喜欢博物馆”的记忆从而避免推荐威尼斯海鲜多而更倾向于推荐罗马、柏林等历史文化名城。在这个例子中记忆的存储和检索是基于语义的。即使用户在提问时没有直接说“我不吃海鲜”只要他问的问题与“饮食”、“度假”相关相关的过敏记忆就有可能被检索出来影响Agent的决策。3.3 记忆的定制化实现一个混合记忆系统在实际复杂应用中我们往往需要混合多种记忆。例如既要维护最近10轮对话的流畅性会话记忆又要能从海量历史中检索关键事实长期记忆。OpenHands允许我们组合多个Memory对象。from openhands.memory import ConversationBufferWindowMemory, VectorStoreRetrieverMemory, CombinedMemory # 短期会话记忆只保留最近5轮对话 conversation_memory ConversationBufferWindowMemory( memory_keyrecent_chat, k5, input_keyinput, output_keyoutput ) # 长期向量记忆 long_term_memory VectorStoreRetrieverMemory( retrieveryour_retriever, memory_keyknowledge, input_keyinput ) # 组合记忆 combined_memory CombinedMemory(memories[conversation_memory, long_term_memory]) # 在创建Agent时使用这个组合记忆 agent OpenHands( llmyour_llm, memorycombined_memory, # ... 其他参数 )这样在每次Agent运行时combined_memory会分别从两个子记忆中加载变量并合并到一个大的上下文字典中供Prompt使用。你需要精心设计Prompt模板来区分和使用recent_chat和knowledge这两个不同的记忆变量。4. 避坑指南Memory模块的常见问题与优化策略Memory模块用起来简单但想用好、用稳里面有不少坑。下面是我在实际项目中总结的一些典型问题和解决方案。4.1 上下文窗口爆炸与记忆压缩问题最经典的问题。使用ConversationBufferMemory无限制地保存所有对话很快就会导致发送给LLM的Prompt超出其上下文长度限制如GPT-4的8K、32K或本地模型的2K、4K轻则请求被拒绝重则丢失关键的上文信息。解决方案使用ConversationBufferWindowMemory这是最简单的方案只保留最近K轮对话。缺点是会主动遗忘更早的对话可能破坏超长程的连贯性。使用ConversationSummaryMemory在每轮对话后用一个单独的LLM调用去总结之前的对话历史只把摘要存入记忆下次用摘要作为上下文。这能极大压缩长度但存在摘要信息失真、丢失细节的风险且增加了LLM调用成本和延迟。动态上下文管理实现更智能的策略。例如不是简单截断而是基于重要性对历史对话进行打分只保留高分片段。或者将超长的历史对话分段存入向量数据库在需要时进行相关性检索只召回最相关的片段注入上下文。这需要较多的自定义开发。我的实操心得对于大多数任务型对话AgentConversationBufferWindowMemoryk10~20配合一个存储关键事实的VectorStoreRetrieverMemory是性价比最高的方案。将具体的任务参数、用户属性等存入向量长期记忆将最近的对话流程留在窗口记忆里。4.2 向量检索的“无关记忆”干扰问题配置了VectorStoreRetrieverMemory后发现Agent有时会被检索到的无关记忆带偏。比如用户在讨论“编程Python”却检索到了很久以前关于“蛇Python”的玩笑话导致回答混乱。解决方案优化检索参数调整search_kwargs。k值不宜过大通常2-5条足够。可以尝试使用search_typemmr最大边际相关性在保证相关性的同时增加结果的多样性避免返回高度重复的片段。记忆元数据过滤在向向量库存储记忆时为每条记忆添加丰富的元数据metadata如session_id,topic,timestamp,memory_typefact, preference, conversation等。在检索时通过元数据过滤器进行预筛选。例如只检索memory_type为preference且topic包含diet的记忆。Chroma、Weaviate等数据库都支持元数据过滤。提升嵌入模型质量检索的相关性根本取决于嵌入模型。通用模型如OpenAI的text-embedding-ada-002在通用领域表现好但在你的专业领域如医疗、法律可能不佳。考虑使用在该领域微调过的嵌入模型或者用你领域的语料对开源模型进行微调。记忆的“写”策略不要什么都往长期记忆里存。设计规则只存储经过提炼的、高价值的信息。例如在用户表达明确偏好“我不喜欢X”或陈述重要事实“我的项目截止日是下周五”时才触发存储。可以在Agent的输出环节增加一个“记忆评估”步骤由LLM判断当前交互是否值得存入长期记忆。4.3 记忆的冲突与更新问题用户之前说“我喜欢安静”但最近一次聊天又说“偶尔热闹一下也不错”。向量库里存着两条矛盾的记忆检索时可能同时出现让Agent困惑。解决方案基于时间的衰减或优先级为记忆条目添加时间戳和置信度权重。新的记忆拥有更高的权重或者在检索结果排序时更新时间更近的记忆排在前面。可以在元数据中实现。主动记忆管理实现一个记忆合并或冲突解决机制。当检测到新旧记忆冲突时可以通过LLM判断触发一个解决流程要么用新记忆覆盖旧记忆要么将两者合并成一条更精确的记忆如“用户通常喜欢安静但在周末或特殊场合不排斥热闹的环境”。这同样需要额外的LLM调用和逻辑设计。实用建议对于简单应用可以定期如每周手动或自动扫描向量库清理过时或低质量的记忆条目。对于复杂应用记忆的冲突解决是一个高级课题可能需要引入知识图谱的概念来建立记忆间的关系。4.4 性能瓶颈检索延迟与存储开销问题当记忆条目达到数万、数十万时向量检索可能变慢影响Agent的响应速度。同时存储嵌入向量的空间开销也不小。优化策略索引优化使用支持高效近似最近邻搜索ANN的向量数据库如Faiss、HNSWlib。这些库为大规模向量检索做了深度优化。Chroma的后端默认就支持HNSW。分层存储将记忆分级。高频、热点的记忆如用户最近一周的偏好放在内存或更快的缓存里如Redis全量的长期记忆放在向量数据库。检索时先查缓存未命中再查向量库。量化与压缩对于嵌入向量可以考虑使用量化技术如PQ - Product Quantization在可接受的精度损失下大幅减少存储空间和加速检索。异步写入save_context操作不一定非要同步阻塞Agent的响应。可以将其放入一个后台任务队列异步执行优先保证Agent响应的实时性。5. 超越基础设计更智能的记忆模式OpenHands提供的Memory组件是优秀的起点但要构建真正强大的Agent我们往往需要在其基础上进行定制和扩展。这里分享几个进阶的设计思路。5.1 记忆的“反思”与“提炼”机制原始的对话记录是嘈杂的。让Agent具备“反思”能力定期或基于特定触发条件对记忆进行总结、提炼可以产生更高质量的记忆。例如在完成一个复杂的多步骤任务如规划一次旅行后触发一个“反思”步骤LLM调用“请回顾刚才为用户规划旅行的整个对话过程提炼出用户的核心需求如预算、时间、兴趣点和做出的关键决策如选择了A航班、B酒店。”存储将LLM生成的这份精炼的总结作为一条高质量的“旅行规划案例”记忆存入向量库而不是存储几十轮原始对话。未来当用户再次要求规划旅行时这份总结能提供更清晰、更结构化的参考。5.2 基于记忆的个性化Prompt工程记忆的价值最终体现在Prompt里。我们可以设计更精巧的Prompt模板来利用不同类型的记忆。from openhands.prompts import PromptTemplate template 你是一个旅行规划助手。请根据以下信息为用户提供建议。 # 关于用户的长期了解长期记忆 {long_term_memory} # 最近的对话历史短期记忆 {recent_chat} # 用户当前的问题 {input} 请开始你的回答 prompt PromptTemplate(input_variables[long_term_memory, recent_chat, input], templatetemplate) # 在Agent配置中使用这个自定义的Prompt通过清晰的Prompt结构引导LLM更好地理解和运用不同来源、不同抽象层次的记忆。5.3 将记忆与工具调用结合记忆不仅可以用于生成回答还可以指导工具调用。例如一个“智能家居控制”Agent的记忆里存储了“用户通常在晚上10点关闭客厅灯”。当用户在晚上9点55分说“我准备睡觉了”Agent除了回复“好的晚安”还可以自动调用关灯的工具因为它从记忆中推理出了用户的潜在意图。这需要记忆模块与工具决策逻辑有更深的集成。实现上可以在Agent的决策循环中让记忆检索的结果不仅填充到Prompt也作为工具选择Tool Routing的一个输入特征。例如如果检索到的记忆强烈关联到某个工具如“关灯”则提高该工具被选择的权重。5.4 实现一个简单的“记忆重要性”评分模型不是所有对话都值得记住。我们可以训练或设计一个简单的模型甚至是用Prompt让LLM自己判断为每一段潜在的记忆候选即一轮对话的输入输出对打分。# 伪代码示例 def should_save_to_long_term_memory(user_input, agent_output, conversation_context): # 规则1用户明确要求记住 if 记住 in user_input or 记一下 in user_input: return True, 1.0 # 规则2LLM判断通过一个简单的分类Prompt judgment_prompt f 判断以下对话片段是否包含值得长期记住的用户个人信息或重要事实 用户{user_input} 助手{agent_output} 只回答是或否。 llm_judgment llm.predict(judgment_prompt) if 是 in llm_judgment: return True, 0.8 # 返回True和一个重要性分数 # 规则3检测到关键实体如日期、地点、产品名 if extract_important_entities(user_input): return True, 0.6 return False, 0.0 # 在Agent的post-action步骤中调用 should_save, importance_score should_save_to_long_term_memory(input, output, context) if should_save: memory.save_context({input: input}, {output: output}, metadata{importance: importance_score})通过这种方式我们可以构建一个质量更高、噪音更少的记忆库提升后续检索的效率和质量。Memory系统是AI Agent从“玩具”走向“工具”的灵魂所在。它决定了Agent的“智商”和“情商”——能否从历史中学习能否提供连贯、个性化的服务。OpenHands提供了一个灵活、可扩展的Memory框架但真正的挑战在于如何根据你的具体业务场景设计出合理的记忆分类、存储、检索和更新策略。这没有银弹需要你在理解基本原理的基础上不断实验、迭代和优化。从我个人的经验来看从一个简单的ConversationBufferWindowMemory开始逐步引入向量长期记忆并小心处理上下文长度和检索质量是大多数项目最稳妥的演进路径。记住一个好的记忆系统应该是让Agent变得更聪明而不是更慢或更混乱。