小白程序员必看：收藏这份 Agent Memory 模块设计指南，面试必杀技！

本文深入解析 Agent Memory 模块的设计要点从认知科学的三种记忆类型语义、情节、程序性出发结合短期记忆和长期记忆的双层架构详细阐述了记忆的提取、写入、管理和检索流程。特别介绍了 Mem0 框架的四种记忆操作ADD、UPDATE、DELETE、NOOP以及记忆冲突的处理机制。文章最后总结了记忆系统设计的三个维度帮助读者全面掌握 Agent Memory 模块的设计思路提升面试竞争力。前段时间一位读者在后台私信我说去字节面试聊到了他做的 Agent 项目。面试官问“你的 Agent 有没有记忆能力”他说“有用户上周问过的问题这周还记得。”面试官接着问“那这个记忆存在哪”他说“存在向量数据库里。”面试官继续追“向量数据库里有多少条记忆怎么检索出来的全量检索还是按用户过滤”他说“用语义相似度检索取 Top5。”面试官没停“那如果用户上周说他有两个孩子这周又说他有三个孩子你怎么处理追加一条还是更新原来那条系统怎么判断的”他当场卡住了答不上来。面试官最后说了一句话点到了根上“你知道怎么查记忆但你不知道怎么管记忆。记忆管理才是 Agent 可用不可用的分水岭。”这篇文章我们就来系统讲清楚 Agent 的 Memory 模块该怎么设计。为什么 Agent 需要 Memory先说一个具体的背景。我们在做的项目是银行对公客户智能咨询助手拓业智询服务的对象是企业客户咨询的内容涉及理财产品、贷款方案、汇率避险等专业金融问题。这类客户有个特点需求复杂决策周期长一个项目要咨询好几次。客户经理要记住每位客户的偏好、资质、历史问题——这是基本功。但如果 AI 每次都失忆客户每次都要重新介绍自己体验极差。我们做了一组对比测量没有 Memory 模块用户第二次咨询时要重新介绍需求平均多说 3-4 轮对话才能进入正题有 Memory 模块系统识别到回头用户后直接基于历史偏好给出回答满意度提升 23%平均对话轮次减少 2.1 轮这组数据说明Memory 不是锦上添花是 Agent 落地的基础能力。那 Memory 到底是什么它不是把所有对话记录存起来而是一套结构化的信息管理体系——哪些信息值得记怎么存怎么取怎么更新怎么删。要回答这些问题先得搞清楚 Agent 的记忆到底有哪几种每种记忆的性质不同对应的存储和检索策略也完全不一样。认知科学视角三种记忆类型在设计 Agent Memory 之前我们先从认知科学借一个框架。人类的记忆分为三种类型Agent 的记忆设计也可以完全对照这套体系来做。Agent记忆系统三种类型语义记忆Semantic Memory语义记忆是关于世界的通用知识不依附于特定时间和人物。在拓业智询里语义记忆包括各类金融产品的说明和条款监管政策、利率基准、汇率规则常见业务问答如对公账户开户需要哪些材料这类信息的特点是长期稳定更新频率低对所有用户共享。存储方式是传统的知识库向量数据库按内容语义检索。示例平安银行对公理财产品的起购金额为100万元最短持有期30天。这条信息对所有咨询用户都适用存在共享向量库里任何用户问到都可以检索到。情节记忆Episodic Memory情节记忆是具体事件的记录与时间、人物绑定。在项目里情节记忆包括用户张三在 2024 年 3 月询问过重疾险的保障范围用户李四的企业注册资本 5000 万属于中型企业客户用户王五明确表示不接受股票类高风险产品用户赵六上次咨询时提到公司准备做跨境业务这类信息是每个用户独有的与用户 ID 强绑定更新频率高。存储时必须按用户 ID 隔离检索时先过滤用户再做语义匹配。这是 Agent 产生认识你感知的核心来源。程序性记忆Procedural Memory程序性记忆是操作流程和行为规则对应的是怎么做而不是知道什么。在项目里程序性记忆包括处理理赔咨询时先查保单状态再查对应条款涉及高净值客户时优先推荐私行产品线客户首次咨询时先确认企业性质和注册地这类信息不需要检索直接固化为系统 Prompt在每次对话开始时注入。更新方式是修改系统 Prompt 而不是检索时注入。这三种记忆类型对应完全不同的存储和检索策略混在一起处理是很多初学者踩的第一个坑。分清楚了记忆的内容分类接下来要解决的是时效性问题——同样是情节记忆当前对话里刚说的话和三个月前记录的偏好处理方式是完全不同的。这就引出了短期记忆和长期记忆的双层架构。短期记忆与长期记忆的双层架构三种类型是对记忆内容的分类接下来说的是对记忆时效的分类——短期记忆和长期记忆。Agent记忆管理四步流程短期记忆对话上下文窗口短期记忆就是当前对话的消息历史存在 LLM 的上下文窗口里。实现上用滑动窗口管理保留最近 N 轮对话class ShortTermMemory: def __init__(self, window_size: int 10): self.window_size window_size self.messages [] def add_message(self, role: str, content: str): self.messages.append({role: role, content: content}) # 超出窗口大小则移除最早的消息 if len(self.messages) self.window_size * 2: # 每轮包含userassistant两条 self.messages self.messages[-self.window_size * 2:] def get_context(self) - list: return self.messages短期记忆的局限很明显对话结束后就消失了下次会话无法访问。这就是长期记忆存在的原因。长期记忆向量数据库分区存储长期记忆存在向量数据库里在拓业智询里我们用 Milvus。存储结构上按记忆类型和用户 ID 分区# Milvus集合设计 schema { collection_name: agent_memory, fields: [ {name: memory_id, type: VARCHAR, max_length: 64}, {name: user_id, type: VARCHAR, max_length: 64}, {name: memory_type, type: VARCHAR, max_length: 32}, # semantic/episodic {name: content, type: VARCHAR, max_length: 2048}, {name: embedding, type: FLOAT_VECTOR, dim: 1536}, {name: created_at, type: INT64}, # Unix timestamp {name: ttl, type: INT64}, # 过期时间-1表示永久 {name: is_deleted, type: BOOL} # 软删除标记 ] }语义记忆分区user_id字段为空或固定值global对所有用户共享 情节记忆分区user_id字段绑定具体用户检索时必须带user_id过滤条件这个分区设计解决了两个问题隔离性用户 A 不会检索到用户 B 的记忆和性能先按user_id过滤再做向量检索检索范围大幅缩小。对话结束时的记忆提取一次对话结束后系统需要从对话内容里提取值得长期保存的记忆点MEMORY_EXTRACTION_PROMPT 你是一个记忆提取助手。请从以下对话中提取值得长期记忆的信息。 只提取以下类型的信息 1. 用户明确表达的偏好如风险偏好、产品偏好 2. 用户的基本信息企业规模、行业、注册地等 3. 用户的重要决策或需求变化 4. 对未来咨询有参考价值的关键事件 不要提取普通的问答内容、系统的标准回复、临时性的闲聊 对话内容 {conversation} 请以JSON格式输出每条记忆包含content内容、memory_typeepisodic/semantic async def extract_memories(conversation: list, user_id: str) - list: prompt MEMORY_EXTRACTION_PROMPT.format( conversation\n.join([f{m[role]}: {m[content]} for m in conversation]) ) response await llm.ainvoke(prompt) memories json.loads(response.content) return memories这个提取步骤是 Memory 系统的入口提取质量直接决定长期记忆的有效性。有了提取结果下一个问题是新提取出来的记忆怎么写入如果每次都无脑追加时间一长记忆库里就会充满相互矛盾的信息这正是 Mem0 框架要解决的核心问题。Mem0 框架四种记忆操作提取出来的记忆怎么写入这里就要谈到记忆管理的核心问题——当新信息到来时系统应该做什么操作Mem0 是目前最成熟的 Agent Memory 开源框架它把记忆操作抽象为四种ADD、UPDATE、DELETE、NOOP。# Mem0的记忆管理接口 from mem0 import Memory memory Memory() # ADD新增记忆全新信息之前没有记录过 memory.add(用户偏好低风险产品不接受股票类投资, user_iduser_001) # UPDATE更新记忆信息发生了变化 memory.update(memory_idmem_xxx, data用户已升级为VIP客户授信额度从50万提升到200万) # DELETE删除记忆信息已过期或不再有效 memory.delete(memory_idmem_xxx) # 如用户注销账户后 # NOOP不操作信息已存在内容一致无需重复写入 # 系统自动判断不需要手动调用这四种操作看起来简单但背后的判断逻辑是整个 Memory 系统最有技术含量的地方。Mem0 的核心机制是每次写入新记忆前先用 LLM 比较新信息和现有记忆的语义关系然后决定做哪种操作。MEMORY_DECISION_PROMPT 你是一个记忆管理助手。请判断以下新信息与现有记忆的关系并决定操作类型。 新信息{new_info} 现有记忆相关度最高的5条 {existing_memories} 请判断 - ADD新信息是全新的现有记忆中没有相关内容 - UPDATE新信息是对某条现有记忆的更新同一实体信息变化了 - DELETE新信息表明某条现有记忆已经失效 - NOOP新信息与现有记忆完全一致无需操作 输出JSON格式{{action: ADD/UPDATE/DELETE/NOOP, target_memory_id: 如果是UPDATE/DELETE则填写目标记忆ID, reason: 判断理由}} 这套判断逻辑在测试环境下运转流畅但在实际业务中会遇到更复杂的情况——用户的信息前后矛盾了该更新还是保留这就是记忆冲突问题也是面试官最喜欢深挖的地方。面试官追问的核心记忆冲突怎么处理回到文章开头的面试场景那个让读者答不上来的问题用户上周说有两个孩子这周说有三个孩子怎么处理这是记忆冲突问题也是 Memory 系统工程挑战里最难的一个。方案一语义去重判断用 LLM 比较新旧信息的语义相似度相似度超过阈值则判断为同一实体的更新async def check_memory_conflict( new_memory: str, existing_memories: list, similarity_threshold: float 0.85 ) - dict: 检查新记忆是否与现有记忆冲突 返回{action: ADD/UPDATE, conflict_memory_id: str or None} if not existing_memories: return {action: ADD, conflict_memory_id: None} # 对每条现有记忆计算语义相似度 new_embedding await embedder.aembed_query(new_memory) for mem in existing_memories: similarity cosine_similarity(new_embedding, mem[embedding]) if similarity similarity_threshold: # 相似度高判断为同一实体——需要更新而不是追加 # 进一步用LLM确认是否真的是更新 is_update await llm_confirm_update(new_memory, mem[content]) if is_update: return {action: UPDATE, conflict_memory_id: mem[memory_id]} return {action: ADD, conflict_memory_id: None}用户有两个孩子和用户有三个孩子的语义相似度会很高都是关于孩子数量的描述系统判断为 UPDATE 操作用新信息替换旧信息而不是同时保留两条相互矛盾的记录。方案二记忆过期与 TTL 管理有些记忆天然有时效性过了有效期就应该删除而不是保留。# 写入带TTL的记忆 def add_memory_with_ttl( content: str, user_id: str, ttl_days: int -1 # -1表示永久0表示有效天数 ): ttl_timestamp -1 if ttl_days 0: ttl_timestamp int(time.time()) ttl_days * 86400 memory_record { memory_id: str(uuid.uuid4()), user_id: user_id, content: content, created_at: int(time.time()), ttl: ttl_timestamp, is_deleted: False } milvus_client.insert(agent_memory, memory_record) # 示例本月预算信息有效期30天 add_memory_with_ttl( content用户本月可用于理财的预算为5万元, user_iduser_001, ttl_days30 ) # 定时清理任务每天运行 async def cleanup_expired_memories(): current_time int(time.time()) expired milvus_client.query( collection_nameagent_memory, filterfttl 0 ttl {current_time} is_deleted false ) for mem in expired: milvus_client.update( collection_nameagent_memory, filterfmemory_id {mem[memory_id]}, data{is_deleted: True} )用户本月预算是 5 万这类信息30 天后就过期了继续保留反而会干扰后续回答。TTL 机制让系统自动完成清理不需要人工干预。方案三隐私合规与被遗忘权金融行业有严格的数据合规要求用户有权要求删除自己的所有数据这就是 GDPR 和国内个人信息保护法里的被遗忘权。工程上的实现方式是软删除配合审计日志async def forget_user(user_id: str, operator: str, reason: str): 软删除用户的所有记忆保留审计日志 # 1. 标记所有记忆为已删除 milvus_client.update( collection_nameagent_memory, filterfuser_id {user_id} is_deleted false, data{is_deleted: True} ) # 2. 写入审计日志审计日志不删除用于合规审查 audit_log { operation: USER_FORGET, user_id: user_id, # 保留user_id用于审计 operator: operator, reason: reason, timestamp: int(time.time()), memory_count: deleted_count } audit_db.insert(audit_log) return {status: success, message: f已删除用户{user_id}的所有记忆数据}注意审计日志本身不删除这是合规要求——监管机构有权审查数据处理记录但实际的用户数据记忆内容通过is_deleted标记在业务查询中完全屏蔽。冲突处理、过期清理、合规删除这三个机制解决了记忆怎么管的问题。记忆存好之后每次对话时怎么把它用起来才是最终落地的关键。记忆检索如何把记忆注入 Prompt记忆存好了每次对话开始时怎么用async def retrieve_memory(query: str, user_id: str) - str: 检索与当前问题相关的历史记忆返回格式化的Prompt片段 # 第一步向量检索用户相关记忆先过滤user_id再做语义检索 relevant_memories memory.search( queryquery, user_iduser_id, limit5 ) if not relevant_memories: return # 第二步格式化为Prompt片段 memory_context \n.join([ f- {m[memory]} (记录于{m[created_at]}) for m in relevant_memories ]) return f 【用户历史信息】 以下是该用户的历史偏好和关键信息请在回答时参考 {memory_context} # 在对话流程中注入 async def chat(user_message: str, user_id: str, session_id: str): # 检索相关记忆 memory_context await retrieve_memory(user_message, user_id) # 构建完整的系统Prompt system_prompt BASE_SYSTEM_PROMPT if memory_context: system_prompt \n\n memory_context # 调用LLM response await llm.ainvoke( messages[ {role: system, content: system_prompt}, *short_term_memory.get_context(), {role: user, content: user_message} ] ) # 更新短期记忆 short_term_memory.add_message(user, user_message) short_term_memory.add_message(assistant, response.content) return response.content有几个细节值得注意第一检索时一定要先按user_id过滤再做向量相似度计算不能把所有用户的记忆混在一起检索。不然不同用户的信息会相互污染也是严重的隐私问题。第二limit5不是固定值要根据 Prompt 长度预算来决定。如果上下文窗口紧张可以减少到 3 条如果问题复杂、需要更多背景信息可以增加到 8 条。第三检索到的记忆要带上时间戳让 LLM 知道这条信息是什么时候记录的方便它判断信息的时效性。把定义、写入、管理、检索这四个环节串起来就得到了一套完整的记忆管理闭环下面用一个统一的流程图把它梳理清楚。四步记忆管理流程把上面所有内容串起来完整的记忆管理流程是四步短期记忆长期记忆双层架构第一步Define定义明确哪些信息值得记忆。不是所有对话内容都有保存价值要聚焦在用户明确表达的偏好风险偏好、产品偏好、服务偏好用户的基本信息企业规模、行业、注册地用户的重要决策和关键事件对后续服务有实质参考价值的信息今天天气真好不值得记忆我们公司明年计划做出口业务值得记忆。第二步Write写入用 LLM 从对话中提取记忆点按类型分类后写入对应的存储情节记忆写入向量数据库绑定 user_id语义记忆写入共享知识库程序性记忆更新系统 Prompt 配置第三步Manage管理写入前做冲突检测决定 ADD/UPDATE/DELETE/NOOP 操作语义相似度 0.85 且内容有变化UPDATE新信息表明旧记忆已失效DELETE新信息之前没有类似记录ADD新信息与现有记忆一致NOOP第四步Read读取每次对话开始时先检索长期记忆取相关度最高的 5 条格式化后注入系统 Prompt拼接短期记忆最近 N 轮对话发送给 LLM 生成回答这四步构成一个闭环每次对话既消费记忆又产生新的记忆。理解了这套完整的设计体系回到面试场景就能把面试官的每一层追问都接住。面试怎么答 Agent Memory 设计回到面试场景如果面试官问你Agent 的 Memory 模块怎么设计可以按这个框架回答第一层分类“我们把记忆分三类参考认知科学的语义记忆、情节记忆、程序性记忆。语义记忆是通用知识对所有用户共享存知识库情节记忆是用户专属的历史信息按用户 ID 隔离存储程序性记忆是操作规则直接固化为系统 Prompt。”第二层架构“架构上分短期和长期两层。短期记忆是当前对话的上下文窗口用滑动窗口保留最近 10 轮长期记忆存在向量数据库里我们用 Milvus按用户 ID 分区支持语义检索。”第三层管理“写入时用 Mem0 框架的四种操作——ADD/UPDATE/DELETE/NOOP写入前先做语义去重比较新信息和现有记忆的相似度超过 0.85 判断为同一实体需要更新避免同一信息的矛盾版本并存。时效性信息加 TTL 字段定时清理。”第四层检索“每次对话开始时先按用户 ID 过滤再做向量相似度检索取相关度最高的 5 条格式化后注入系统 Prompt。”第五层合规“金融场景下还要考虑被遗忘权实现方式是软删除加审计日志——业务查询屏蔽已删除记忆但审计日志保留用于合规审查。”这五个层次说完面试官想追问的点基本都覆盖了。在理解这套体系的过程中还有一个概念上的混淆需要特别说清楚它会影响你在面试中的表达精确度。一个常见误区最后说一个我见过很多人踩的坑把 Memory 和 RAG 混为一谈。RAG检索增强生成是从知识库里检索文档来回答问题检索的是通用知识内容。Memory 是存储和检索用户专属的历史信息检索的是与特定用户相关的个性化记忆。两者的区别很清晰RAG 处理的是世界知道什么Memory 处理的是我知道关于这个用户什么。在拓业智询里这两个模块并存用户问贷款利率是多少 → RAG 从产品知识库里检索回答用户问我上次咨询的那个方案怎么样了 → Memory 从用户历史记录里检索上下文两者都需要功能不重叠不能相互替代。把这个区分讲清楚整套 Memory 设计的轮廓就完整了用三个维度做个收尾。总结Agent Memory 系统的设计可以用三个维度来概括第一个维度是分类——区分语义记忆、情节记忆、程序性记忆对应不同的存储位置和检索策略第二个维度是架构——短期记忆用滑动窗口管理当前对话长期记忆用向量数据库按用户 ID 分区存储第三个维度是管理——写入时做冲突检测ADD/UPDATE/DELETE/NOOP过期信息用 TTL 自动清理用户注销时软删除保留审计。面试官问的存在哪、怎么检索、什么时候更新、什么时候删除这四个问题的答案都在这个框架里。最后2026 年春节前后国内大模型迎来史无前例的集体爆发与同台竞技。短短不到一个月主流厂商几乎全部登场字节跳动 Seedance 2.0 刷屏科技圈各大互联网公司纷纷推出 AI 红包新玩法一场场精心准备的“大模型春晚”轮番上演吸引无数 AI 爱好者围观喝彩。大模型赛道竞争如此激烈普通人到底该怎么入局抢占未来 10 年的行业红利如果你还不知道从何开始我特别整理了一套全网最全、最细的大模型零基础教程。我也是一路自学走过来的太清楚小白前期学习的痛点没人带、没方向、没资源真的很难学进去下面这套资料就是我专门为零基础、想转行、想提升的同学准备的全套学习方案。扫码免费领取全部内容资料包分享1、大模型完整学习路线图2、从 0 到进阶大模型视频教程从入门到实战全套视频都整理好了跟着学效率更高3、入门必看精选书籍 核心文档PDF 版市面上技术书太多我已经帮你筛选出最值得看的一批还有大量补充资料不在图里一并打包给你4、AI大模型最新行业报告2026 年最新行业报告系统分析各行业现状、趋势、痛点与机会帮你看清哪些行业最适合落地大模型哪里才有真正的机会。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】