AI智能体长期记忆系统MRMS：多分辨率记忆架构设计与工程实践

1. 项目概述当AI智能体需要“长期记忆”最近在折腾AI智能体AI Agent项目时我遇到了一个几乎所有开发者都会头疼的经典问题“健忘症”。比如你设计了一个客服Agent它和用户聊了十几轮前几轮用户明明说了自己的订单号、偏好但聊到后面它要么重复提问要么给出的建议完全忽略了之前的上下文。这背后的核心瓶颈就是智能体的记忆Memory系统太“短视”了。传统的AI Agent记忆方案无论是简单的对话历史列表还是基于向量数据库的检索增强生成RAG在处理长周期、多任务、信息密度不均的交互时都显得力不从心。它们要么像“金鱼”一样只有7秒记忆上下文窗口限制要么像“杂物间”一样把所有信息胡乱堆在一起需要时翻找效率极低还经常找错东西。这正是“MRMS: A Multi-Resolution Memory Substrate for Long-Lived AI Agents”这个项目要解决的核心痛点。MRMS即多分辨率记忆基底它不是一个具体的工具或库而是一套设计范式与架构思想。它的目标是为长期存活的AI智能体构建一个像人类记忆一样具备不同“清晰度”和“访问速度”的记忆系统。简单来说它试图让AI智能体拥有短期工作记忆用于处理当前对话或任务的即时信息快速但容量小。长期情景记忆存储重要的具体事件、对话和经历可按需检索。语义/概念记忆提炼出的知识、用户画像、行为模式是高度压缩的“经验”。程序性记忆存储常用的技能、工具调用流程实现快速反应。将“多分辨率”这个概念引入记忆系统是解决当前AI Agent在复杂、持久环境中表现不稳定的关键一步。接下来我将结合自己的实践和思考拆解MRMS的核心设计、实现要点以及我们如何将其落地。2. MRMS核心设计思路拆解为什么我们需要“多分辨率”记忆想象一下人类记忆你不会记得三天前午餐每一粒米饭的味道低价值细节但你会记得那家餐厅不错概括性评价你可能会模糊记得去年某次会议的大概内容模糊记忆但能清晰复述上周项目评审的关键结论清晰记忆。这种根据信息的重要性、时效性和访问频率动态分配记忆“精度”和“存储资源”的能力正是高效认知的关键。2.1 从单层存储到分层记忆架构传统Agent记忆大多采用“单层扁平化”存储所有记忆条目无论是“用户喜欢咖啡”还是“今天的天气是晴转多云”都被同等对待塞进一个向量数据库。这导致了几个严重问题检索噪声大当记忆条目成千上万时基于相似性的检索会返回大量无关的、琐碎的记忆干扰当前任务。重要信息淹没关键的用户偏好高价值可能被大量的日常寒暄低价值稀释难以被优先召回。资源浪费存储和计算资源被大量低频、无效的信息占用。缺乏概括与抽象记忆是原始记录的堆砌无法形成更高层次的“知识”或“洞察”智能体无法真正“成长”。MRMS的设计思路正是将记忆系统分层化、结构化。它通常包含以下几个层次分辨率从高到低记忆层级分辨率类比存储内容访问速度更新频率实现形式举例工作记忆 (Working Memory)4K超清当前会话的完整上下文、临时推理中间结果极快内存直接访问极高实时对话历史列表、LLM上下文窗口情景记忆 (Episodic Memory)1080p高清具体的交互事件、对话回合、任务执行记录快向量检索元数据过滤高事件触发向量数据库如Chroma, Weaviate附带时间、实体等元数据语义记忆 (Semantic Memory)720p标清从情景中提炼的事实、概念、用户画像、实体关系中等可能需要复杂查询中定期摘要/聚合知识图谱如Neo4j、结构化数据库表程序记忆 (Procedural Memory)矢量图习得的技能、工具使用流程、问题解决模板慢需加载和解释但执行高效低学习后固化提示词模板库、可执行代码片段、技能函数2.2 记忆的写入、聚合与遗忘机制一个静态的分层结构是不够的。MRMS的核心动态过程在于信息如何在各层间流动。写入与编码所有原始交互首先进入工作记忆。一个重要性评分模块可以是基于规则的也可以是一个轻量级模型会实时评估工作记忆中的信息块如一句话、一个QA对。评分依据可能包括信息熵、情感强度、是否包含关键实体如姓名、数字、用户显式强调如“请记住”。评分高的信息块会被提取关键特征编码成向量并附带丰富的元数据时间戳、来源、关联实体、重要性分数存入情景记忆。聚合与压缩降分辨率定期例如每天或触发式情景记忆达到一定容量地系统会对情景记忆进行“回顾”。摘要聚合将一段时间内相关的、重复的情景记忆通过LLM生成一个概括性的摘要。例如将一周内用户五次询问“Python数据分析”的相关对话聚合成一条语义记忆“用户近期对Python数据分析特别是Pandas和可视化表现出持续且强烈的学习兴趣。”模式提取通过分析情景记忆发现规律。例如用户总是在周一上午询问周报模板这可以形成一条程序记忆“每周一上午9点主动向用户提供周报模板选项。”聚合后的、更抽象的信息存入语义记忆或程序记忆。原始的情景记忆可能被存档或丢弃细节只保留指向聚合结果的指针从而实现“降分辨率”存储。遗忘与清理这是长期运行系统的必备功能。MRMS需要一套“垃圾回收”机制。基于时间的遗忘给每条记忆一个“衰减因子”随着时间推移其重要性分数降低低于阈值后移至归档或删除。基于访问频率的遗忘长期不被检索的记忆被认为是“冷数据”可以转移到更廉价的存储或进行高压缩存储。主动遗忘当用户明确表示某信息已过时或错误“我换手机号了”系统需要能定位并更新或删除相关记忆。实操心得重要性评分是第一个难点。纯规则如关键词匹配太死板用模型又增加复杂度。一个折中方案是“规则LLM轻量化评估”先用规则过滤出候选信息如包含决策、数字、承诺等再用一个专门优化过的小模型或少量提示词调用大模型让其判断“这条信息对未来与用户互动是否有用”输出一个0-1的分数。这个分数直接决定了信息能否进入长期记忆。3. 核心模块实现与实操要点理解了设计思路我们来看看如何动手搭建一个简化版的MRMS。这里我以构建一个“个人学习助手AI Agent”为例。3.1 记忆存储层的选型与搭建工作记忆层最简单直接用列表或队列在内存中维护最近N轮对话。关键在于要包含完整的角色User/Assistant和内容。可以使用LangChain的ConversationBufferWindowMemory或自定义实现。# 简化示例 class WorkingMemory: def __init__(self, window_size10): self.buffer [] self.window_size window_size def add(self, role, content): self.buffer.append({role: role, content: content}) if len(self.buffer) self.window_size: self.buffer.pop(0) # 先进先出模拟滑动窗口 def get_context(self): return self.buffer情景记忆层这是核心推荐使用支持元数据过滤的向量数据库。选型Chroma DB轻量、易嵌入、Weaviate功能强大、支持GraphQL、Qdrant性能优异。我个人在原型阶段喜欢用Chroma生产环境会考虑Qdrant或Weaviate。关键点存入向量时元数据metadata的设计至关重要。除了文本本身至少应包括timestamp: 发生时间。importance_score: 重要性分数。type: 记忆类型如fact,preference,goal,conversation。entities: 提取出的实体列表如[Python, Pandas]。source_session: 来源会话ID。语义/程序记忆层根据需求选择。如果需要复杂的关联查询如“找出所有喜欢咖啡且住在北京的用户”知识图谱如Neo4j是很好的选择。如果主要是键值对或表格型数据如用户个人信息、系统配置用关系型数据库如PostgreSQL或文档数据库如MongoDB更简单直接。程序记忆技能可以直接用代码文件索引或专门的提示词管理工具来存储。3.2 记忆路由与检索策略这是MRMS的“大脑”决定什么时候存、存到哪里、从哪里取。写入路由每次用户交互后系统不仅更新工作记忆还会将当前对话的“摘要”或“关键信息提取”任务抛给一个路由判断器。这个判断器可以是一个简单的分类器基于规则或微调的小模型判断该信息属于“事实”、“偏好”、“任务”、“闲聊”等类别并给出重要性分数。根据类别和分数决定是丢弃、存入情景记忆还是触发更高层的聚合。# 路由判断器伪代码 def memory_router(conversation_turn, working_memory): # 1. 提取关键信息 extracted_info llm_extract(conversation_turn) # 调用LLM提取实体、动作、情感等 # 2. 分类与评分 category, score classifier.predict(extracted_info) # 3. 路由决策 if score IMPORTANCE_THRESHOLD: if category in [fact, preference]: store_to_episodic_memory(extracted_info, metadata{category: category, score: score}) elif category skill_pattern: trigger_aggregation() # 触发模式发现与程序记忆生成 # 低分数信息自然遗忘不存入长期记忆检索策略当Agent需要回忆时例如用户问“我之前跟你提过我喜欢看什么书吗”检索不是单一来源的。分层检索首先检索工作记忆最近几条。如果没有则去情景记忆中用当前问题做向量相似性搜索并利用元数据如typepreference进行过滤。如果情景记忆返回的结果过于具体或零散则同时去语义记忆中查询更高层次的摘要如“用户阅读偏好”。检索结果融合将来自不同层的记忆片段按照相关性、时效性、重要性进行加权排序和去重最后整合成一段连贯的背景信息提供给LLM作为上下文。注意事项避免记忆幻觉Memory Hallucination。这是多源检索时的大坑。不同记忆层可能对同一事实有略微不同的描述。在融合时必须保留记忆的“出处”source并在提供给LLM时明确标注“这是根据XX年XX月XX日对话总结的偏好”。更好的做法是让LLM在生成回答时引用具体的记忆来源增强可信度。3.3 记忆聚合与摘要生成这是实现“降分辨率”、让智能体真正“成长”的关键。定时任务使用Celery、APScheduler等工具设置一个后台任务每隔一段时间如每24小时扫描过去一段时间的情景记忆。聚类分析对情景记忆的向量进行聚类如使用K-means将相似主题的记忆归到一起。摘要生成将同一簇内的原始记忆文本连同其元数据发送给LLM给出明确的指令“请基于以下多条对话记录总结出关于用户的一个核心事实、偏好或模式。总结应简洁、通用避免包含具体的时间、地点等细节。输出格式为[总结类型]: [内容]”。存储与关联将生成的摘要存入语义记忆。同时建立该摘要与原始情景记忆簇的关联例如在语义记忆条目中有一个source_episodes字段存储原始记忆的ID列表。这样既保留了概括性知识又能追溯到具体来源。4. 实战为客服Agent构建MRMS系统假设我们要为一个电商客服AI Agent构建MRMS目标是让它能记住老客户提供个性化服务。4.1 系统架构与数据流用户对话进入对话内容首先进入工作记忆维护最近20轮。实时分析与路由对每轮用户消息进行实时分析提取意图咨询、投诉、查询订单、实体产品ID、订单号、颜色偏好和情感积极、消极、中性。规则示例如果意图是“查询订单”且包含有效订单号则此条信息重要性分数0.9很高类型fact。如果用户说“我再也不买这个牌子了”则情感为消极重要性分数0.8类型preference。记忆写入高分数0.7的信息连同提取的实体、情感、时间戳被编码成向量存入情景记忆Chroma DB。每条记忆的metadata包含user_id,intent,entities,sentiment,score,timestamp。夜间聚合任务每天凌晨2点运行聚合任务。针对每个user_id聚类其过去7天的情景记忆。发现模式例如用户A最近三天内密集咨询了“瑜伽垫”相关产品且情感均为积极。聚类算法将其归为一簇。生成语义记忆LLM根据该簇记忆生成“用户A近期对瑜伽垫类产品尤其是高厚度、环保材质表现出明确的购买意向。” 存入语义记忆PostgreSQL表字段user_id,insight_type,insight_content,generated_date,confidence。个性化检索与服务当用户A再次进入客服系统时系统在欢迎语生成前会进行记忆检索。检索首先从语义记忆中取出最新的几条用户画像如“有购买瑜伽垫意向”。同时从情景记忆中检索最近的具体交互如昨天询问过某个瑜伽垫的库存。融合与提示将“用户画像”和“近期具体交互”作为系统提示词的一部分提供给LLM。例如“当前用户是A根据历史记录他近期对瑜伽垫有购买意向。他昨天曾询问过产品P123的库存。请以此为基础进行本次对话。”这样客服Agent的开场白可能不再是机械的“您好请问有什么可以帮您”而是“您好A先生关于您昨天咨询的那款瑜伽垫P123目前东部仓库已有补货。另外我们新到了一款同样材质的瑜伽球您有兴趣了解一下吗”——实现了真正的个性化记忆。4.2 避坑指南与性能优化向量数据库的索引与性能情景记忆会随时间暴增。必须为向量数据库建立合适的索引如HNSW。定期清理或归档过时、低重要性的记忆。元数据过滤先于向量搜索检索时先利用user_id和timestamp等元数据过滤出一个小集合再在这个集合内做向量相似度计算能极大提升检索速度。LLM调用成本与延迟聚合摘要和实时分析都需要调用LLM。为了控制成本可以使用小模型如ChatGLM-6B、Qwen-7B进行实时的意图、实体、情感分析。聚合摘要任务使用性价比较高的API模型如GPT-3.5-Turbo并在提示词上精心设计要求输出严格格式减少冗余token。考虑缓存机制对于相似的用户行为模式无需重复生成摘要。记忆一致性与冲突解决用户可能改变偏好。例如用户之前说“喜欢黑色”后来又说“现在觉得灰色更好”。系统需要能检测到这种冲突。解决方案在存入新的“喜欢灰色”记忆时可以主动检索旧的“喜欢黑色”记忆。如果新旧记忆属于同一类型颜色偏好且实体冲突则可以提高新记忆的重要性分数并为旧记忆打上superseded_by标签指向新记忆的ID。或者在语义记忆更新时LLM在摘要中体现这种变化“用户颜色偏好已从黑色转变为灰色。”安全与隐私记忆系统存储了大量用户数据。必须加密存储严格管理访问权限。在设计聚合和检索时要确保不会泄露其他用户的信息。提供“记忆查看与删除”接口满足数据合规性要求如GDPR的被遗忘权。5. 常见问题与排查实录在实际部署MRMS的过程中我遇到了不少问题这里记录几个典型的案例和解决思路。问题1检索结果不相关经常把无关对话片段找出来。排查检查向量编码模型。最初我使用通用的sentence-transformers/all-MiniLM-L6-v2但对于垂直领域如电商客服它可能无法区分“询问物流”和“抱怨物流慢”的细微差别。解决使用领域数据微调嵌入模型或者在存入前对文本进行预处理和增强。例如对于客服场景在生成向量前将原始文本“我的快递还没到”增强为“[意图:物流查询][情感:中性]我的快递还没到”这样相似性匹配会更准确。问题2记忆聚合任务耗时过长影响系统正常运行。排查发现是夜间对所有用户的所有记忆进行全量聚类计算量巨大。解决改为增量式聚合。只对新产生的、尚未被聚合过的高重要性情景记忆进行处理。同时将聚合任务分布式化按用户ID分片到不同的工作进程并行执行。问题3LLM在生成摘要时有时会“发明”用户没有提过的信息幻觉。排查提示词过于开放如“请总结用户特点”。解决设计更严格、具体的提示词并让LLM进行“引用”。例如“请严格依据以下原始对话列表进行总结不要添加任何列表外的信息。总结时如果涉及具体属性请注明出自哪条对话用ID。输出格式总结...。依据对话[ID]提及了...对话[ID]提及了...。” 这样生成的摘要更可靠且可追溯。问题4系统运行一段时间后响应速度明显变慢。排查数据库监控发现情景记忆表向量库的查询延迟增高。解决实施记忆归档将超过90天、且重要性分数低于阈值的情景记忆从在线向量库迁移到离线存储如对象存储只在需要深度追溯时才加载。建立热点记忆缓存对于高频用户或高频访问的记忆条目将其向量和内容缓存在Redis中避免每次都要查询向量数据库。优化检索链确保检索流程是“元数据过滤 - 缩小候选集 - 向量搜索”而不是直接全量向量搜索。构建一个高效的MRMS是一个持续迭代的过程。它没有标准答案核心在于理解你的智能体需要什么样的记忆以及如何根据业务场景在记忆的丰富度、检索的准确性和系统的复杂度之间取得最佳平衡。从我自己的经验来看从一个简单的“情景记忆层”开始逐步引入聚合和语义记忆是风险最低、收益最明显的实施路径。这个系统一旦运转起来你会发现你的AI智能体真正开始有了“连续性”和“个性”这无疑是通往更强大AGI道路上的坚实一步。