★ FEATURED ARTICLE 我不太喜欢用“记忆”这个词来描述大模型应用里的缓存机制因为大部分人第一次给自己的Agent加记忆时都把问题想得太简单了——不就是把聊天记录存起来下次再塞回去吗我一开始也是这么干的结果做出来的东西不仅回答得乱七八糟Token费用还涨了一半。后来被各种线上问题反复教育才算慢慢摸清Agent记忆技术的门道。这篇指南写给刚接触大模型的程序开发者、AI应用搭建者也适合产品侧的同学参考。我会从最基础的问题讲起Agent为什么需要记忆记忆系统到底有哪些形态然后一步步推进到上下文窗口管理、向量存储与检索、长期记忆分层、遗忘机制最后给出踩过坑的经验和一套可以直接照做的落地清单。你不用提前掌握太多数学背景把思路理清楚照着做就能让手上那个只会“聊完就忘”的Agent变成真正记得住上下文的助手。1. 大模型Agent的“失忆”困境为什么这事必须早点解决1.1 一个随手可做的实验你可以现在打开任意一个聊天式大模型应用先输入“我晚上不吃碳水”然后另开一个新会话问“明天晚饭吃什么”。只要对方没有跨会话记忆能力它大概率会推荐土豆泥、米饭套餐这类高碳水食物。这个现象不是模型笨而是它的注意力机制天然没有“跨请求记忆”每一条请求进来时模型只能看到当前上下文窗口里的内容你关掉上一个对话的那一刻这段内容就从它的“注意力”里消失了。有个比喻我一直在用——大模型每次接到你的请求都像走进一间刚被擦干净的白板房答题。你上一次在白板上写过什么它看不见只有你把内容重新写上去它才能读到。想要让模型记住过去的信息本质上是替它在“白板房”外建一个仓库每次答题前把需要的纸片重新贴回白板。1.2 记忆与上下文窗口的纠缠大模型一次能处理多少信息由上下文窗口决定。不同模型的窗口上限从几千到十万Token不等。Token可以简单理解成“字词的碎片”一个汉字通常占一两个Token。窗口就像一张一次性的桌面桌面越大能铺开的纸越多但桌面永远有限而且越用越满。Agent记忆技术的核心命题不是把桌面无限变大——那是模型厂商该干的事——而是想清楚在给定的桌面尺寸里优先摆放哪些纸片哪些纸片收进抽屉等用到时再拿出来。这个“桌面”与“抽屉”之间来回搬运的逻辑就是你整个记忆系统的骨架。1.3 这几类人现在就该学不是所有场景都需要搞记忆系统。我建议以下开发者优先把精力放在这里做个人助手、陪伴类应用的人。用户会把喜好、习惯、作息一股脑告诉你重复询问就是在消耗耐心。做客服、销售支持的开发者。用户诉求通常跨轮次发起订单状态、退款进度都是记忆的一部分。做代码助手、文档问答的人。项目上下文价值极高一个能记住你代码风格的Agent比什么都好用。只做单轮问答比如临时翻译、单次摘要其实连上下文管理都不一定需要不用盲目上记忆系统。不同场景对记忆的“新鲜度”和“精确度”要求完全不一样。我之前同时接过两个项目一个对时效性极其敏感用户昨天说的偏好今天可能就变了记忆需要频繁更新另一个则要求稳定保持长期的语义知识不轻易被单次对话改写。这两种Agent的读写方式完全不是一回事后面会展开讲。2. 记忆不只是“存住”拆解Agent记忆的四种基本形态2.1 工作记忆每次对话中的临时便签工作记忆对应的是“现在这一刻正在聊的内容”。用户刚说“帮我看看上海这周的天气”紧接着说“那我周四带伞吗”这两句话之间的关联依赖的就是工作记忆。它不需要写入任何持久化存储只需要在当前上下文窗口里保留最近几轮原始对话。最容易犯的错就是把所有历史都留在工作记忆里。窗口是有限的如果你追求“完整保留所有对话”很快窗口就会被占满后面模型会因为上下文过于拥挤而变笨。工作记忆的正确用法是保留最近的交互更早的内容交给“摘要”或“抽屉”。2.2 情景记忆记录发生过的事实情景记忆对应“具体发生过的某件事”。比如“用户昨天问过退货需要什么条件”“用户上周三生成过一份报价单”这些都是事件级别的事实。它像一本流水账时间、动作、对象缺一不可。做情景记忆时我一般建议至少存这几个字段时间、用户标识、事件类型、事件摘要、关联实体。时间尤其重要没有时间戳的情景记忆若干天后会变成一堆无法确认时效的脏数据。2.3 语义记忆沉淀下来的知识语义记忆是从具体事件里抽象出的“通用结论”。“用户偏好高性价比商品”“用户周三下午通常不接电话”这类信息就属于语义记忆。它不像情景记忆那样记录单次事件而是经过归纳后形成的稳定认知。语义记忆的写入时机很关键。不能用户提一次就写也不能永远不写。我的经验是同一类事件重复出现两次以上且没有冲突可以考虑沉淀为语义记忆一旦出现相反事实马上更新。2.4 程序性记忆技能与习惯的固化程序性记忆回答的是“某类事情应该怎么处理”。“用户发起退款时先核对订单是否超过七天再走退款流程”“用户问价格时先给区间再给明细”这些属于操作流程层面的记忆。它不以对话内容的形式出现更像Agent的规则库或技能包。实际工程里程序性记忆可以用提示词片段、校验规则或工具链配置来实现。很多团队把它单独拿出来管理不跟情景记忆混在一起就是为了避免“一条规则被当成聊天记录存下去”的尴尬。2.5 四种形态怎么配合在一个真实Agent里这四种记忆不是互斥的而是同时存在、互相协作。工作记忆管当下情景记忆记具体事件语义记忆用来回答“用户大概是什么样的人”程序性记忆决定“遇到事情该怎么反应”。下面这张表是我设计记忆层时常用的对照记忆形态工程化落点更新频率典型示例工作记忆上下文窗口保留最近轮次每轮更新当前对话Buffer情景记忆事件日志、向量库每小时/每天追加用户投诉记录语义记忆画像字段、知识条目按事件触发更新用户偏好标签程序性记忆提示词规则、工具配置低频更新退款处理流程这张表建议直接抄进自己的设计文档里。很多记忆系统踩坑都是因为没有分清当前看到的信息属于哪一种形态一股脑用同一种方式存储。3. 第一版记忆系统用上下文管理把成本压到最低3.1 先别急着上向量库我刚接触Agent记忆时第一反应是上向量数据库。调研一番之后冷静下来发现当时最高效的路径是先把上下文管理做扎实。这里分享一个真实体会对大多数Demo和初版产品先做滑动窗口和摘要压缩比直接上向量检索收益高得多。原因有三个。第一上下文管理的实现成本几乎为零不需要额外部署服务只需要封装一套存储和拼接逻辑。第二直接带来的Token费用下降是肉眼可见的省下来的预算正好对冲后面上检索的支出。第三上下文窗口本身是最接近模型注意力机制的方案对短中期对话的稳定性最友好。当然上下文管理解决不了长时间跨度的记忆问题但那是第二步的事。把眼前这一步做好后面的路会顺很多。3.2 Token预算怎么算设计上下文管理之前先给你的窗口做个预算。以10万Token窗口为例我常用的切分是这样的窗口区域预留Token用途输出预留约1万保证模型有足够空间生成回答系统提示词约0.5万角色设定、工具说明、指令模板当前对话约4万最近几轮完整对话历史摘要约3万压缩后的早期对话检索注入约1.5万从长期记忆里拉回来的内容不同模型窗口大小不一样比例可以调整但逻辑是通用的先留足输出再保系统提示剩下的空间是“输入预算”由当前对话、历史摘要、检索注入三者竞争。3.3 滑动窗口加摘要压缩第一版核心机制第一版实现是滑动窗口加摘要压缩的组合。滑动窗口只保留最近N轮原始对话更早的对话在保留轮数超限后交给一个摘要模型生成浓缩版内容代替原文。这里给出一份简化实现思路用Python伪代码示意# 简化版的多轮对话记忆管理 class ConversationMemory: def __init__(self, system_prompt, keep_recent6): self.system_prompt system_prompt self.history [] # 最近N轮原始对话 self.summary # 旧对话压缩后的摘要 self.keep_recent keep_recent def add(self, message): self.history.append(message) def compress_if_needed(self): # 当历史超过保留轮次时把最早的部分压成摘要 if len(self.history) self.keep_recent: surplus self.history[:-self.keep_recent] self.summary summarize_with_model(surplus, self.summary) self.history self.history[-self.keep_recent:] def build_prompt(self, current_input): # 组装最终的上下文系统提示 摘要 最近对话 当前输入 final_history [] if self.summary: final_history.append({role: system, content: 以下是更早对话的摘要 self.summary}) final_history.extend(self.history) final_history.append({role: user, content: current_input}) return final_history这里的summarize_with_model是你自己封装的模型调用接口正式实现时记得给摘要输出设置长度上限比如300到500Token。我最开始没限制摘要长度结果摘要本身越滚越大几轮之后比保留原文还费Token后来才加上长度控制和“只在旧对话累积超过阈值时才触发”的限制。3.4 摘要触发频率的经验值摘要不是每轮都要做。频率太高摘要调用本身消耗远大于收益频率太低窗口很快被历史填满。我实测下来每3到5轮触发一次是比较稳的区间。如果单轮对话特别长可以按Token量触发而不是按轮数比如当history累积超过8万Token就压缩一次。还要提醒一点摘要模型可以选比主模型便宜、速度更快的模型。摘要任务本身对模型能力要求不高不需要每次都动用最强模型。4. 给记忆加外置硬盘向量存储与检索的落地方案4.1 为什么选择向量存储而不是硬拼提示词对话轮次一旦超过几十轮上下文管理的短板就很明显无论怎么做摘要信息损耗都是不可逆的用户两个月前说过的偏好摘要里根本留不下来。这时需要外置存储。为什么选择向量存储而不是普通数据库因为用户的问题常常不是精确关键字而是语义相近的描述。“有没有推荐过轻薄的笔记本”和“之前那台便宜的电脑”表达的不是同一个词但指向同一件事。向量存储把文本变成数字向量语义相近的内容在向量空间里距离更近检索时能召回“意思接近但字面不同”的记忆。打个比方向量库就像图书馆的索引卡每张卡记录了一本书的主题位置。你不用翻遍书库直接按主题索引找到相关页码范围再打开书确认一下就行。4.2 从文本切片到向量库的完整链路落地一套向量检索记忆链路通常分五步清洗、切分、向量化、写入、检索。下面按顺序拆一遍。清洗是为了去掉乱码、超长空白和无意义符号。切分是把长文本切成若干块每块单独向量化。一个过长的段落向量化后“语义被平均”检索精度会明显下降。切分参数上我常用的以Token为单位块大小256到512重叠64。重叠的意义是保证跨越切分边界的语义不丢。向量化这一步要用Embedding模型把文本变成固定维度的数字向量。写入向量库时顺带写入元数据至少包含用户ID、会话ID、时间戳、记忆类型。检索时同样把用户当前问题向量化在库里做相似度搜索取前top_k条结果拼进上下文。top_k我通常给5人少的场景给3冷启动场景给8具体依召回效果调整。4.3 检索质量调优的几个旋钮很多新手把检索调优理解成“改top_k”其实问题往往出在别处。我按踩坑频率排个序召回不到先检查切片是不是太大。一个重要事实往往被埋在冗长段落里向量化后和问题的相似度被稀释。把切片调小或者给重要信息单独建一条记忆。噪音太多靠元数据过滤。按用户ID过滤是必须的跨用户召回记忆是最严重的隐私泄露和生产事故。相关性差换个更强的Embedding模型或者对用户查询做一次改写。用户说“那个上次给我推荐的店”直接检索很可能失败改写成一个包含店名和商品名的查询召回率立刻上来。相似度阈值可以设一个最低阈值0.6到0.75低于阈值不召回避免把无关内容硬凑进来。伪代码示意def retrieve_memory(user_id, query, top_k5, min_score0.65): # 用户查询向量化 q_vec embed(query) # 按用户ID过滤保证不同用户的记忆互不可见 candidates vector_store.search( vectorq_vec, filter{user_id: user_id}, top_ktop_k * 2 # 先多取一些再按阈值过滤 ) results [c for c in candidates if c.score min_score] return results[:top_k]这里先多取再过滤是为了避免阈值卡掉后结果太少。这个技巧很朴素但实测下来比直接改top_k有效。4.4 向量库选型与部署考量向量库选型要看你的体量。个人项目、Demo阶段本地文件和轻量向量库足够插入和检索都在毫秒级。到了生产环境要关注扩展性、备份、权限控制云厂商的托管向量服务通常更合适。不管选哪种我都建议单独开一个集合来存放记忆索引不要和知识库混在一起。知识库是静态的基础知识记忆是动态的个人上下文两者的更新频率和生命周期完全不同混在一起以后清理会很痛苦。5. 长期记忆工程化分层架构与遗忘机制5.1 一套能撑得住的长记忆分层长期记忆如果只靠一个向量库很快会变成一锅粥。我的经验是做三层核心画像层、情景事件层、最近缓存层。核心画像层存的是用户最稳定的属性偏好、禁忌、身份。这一层体积最小常驻在每次请求的上下文里。情景事件层存的是具体发生过的事件量大平时不进上下文按需检索。最近缓存层是工作记忆的持久化版本让用户关掉会话再打开还能接得上。三个层级的更新周期、访问频率、存储成本差别很大。我常用下面这张表做分工层级内容存储进入上下文的时机核心画像层偏好/禁忌/身份结构化记录每次请求情景事件层历史事件向量库/事件日志按检索命中最近缓存层近期对话缓存库新会话启动时5.2 什么时候写入记忆写入的触发规则写入时机是最容易拍脑袋的地方。我的原则是“事实驱动、冲突优先”。三条触发规则值得记下来。新事实出现就写用户明确说“我不吃香菜”直接写入核心画像。用户纠正必须覆盖用户说“我改主意了我要低卡方案”此时要把旧的“高热量偏好”覆盖掉而不是追加一条新的。重复两次才沉淀语义一次吐槽、一次随口提的偏好在没有二次验证前不急着写进长期画像可以先放情景事件层观察。另外周期性摘要也不能忘。长对话进行中每隔一段轮次把当前对话的关键信息沉淀进情景事件层。我通常让摘要模型输出固定格式方便后续检索。5.3 怎么读取主动拉取与被动注入读取策略分主动和被动。被动注入是把核心画像层的内容固定在系统提示词里每次请求都带上。主动拉取是基于当前问题去检索情景事件层。主动拉取的触发点要克制不是每轮都检索。我的建议是先判断当前问题是否“需要往日信息”。问当下天气不需要检索问“上次你给我推荐的那家店”必须检索。设计一个轻量的意图判断可以省掉大量无效检索也能减少延时。5.4 遗忘与更新记忆系统里最容易被忽略的一环没有遗忘机制的记忆系统本质上是一个稳定增长的垃圾场。遗忘机制至少有三件事要做时间衰减、冲突消解、显式删除。时间衰减超过设定天数没有被访问的记忆从核心画像层降级到情景事件层再久就进入归档。用户半年没提过的事情优先级理应降低。冲突消解同一主题出现新旧两条记忆时以最新的事实为准。很多记忆漂移事故就是因为只增不改两条矛盾记忆同时存在模型随机抽一条结果时灵时不灵。显式删除用户说“忘掉这个”时必须有接口能物理删除对应记录。这个功能不做等用户投诉隐私问题的时候再补就晚了。参考的记忆结构示意{ user_profile: { dietary: low-carb, preferred_brand: neutral, updates: [{field: dietary, old: high-carb, time: 2025-06-12T10:00:00Z}] }, episodes: [ {id: evt_001, time: 2025-06-10T20:11:00Z, type: query, summary: 咨询退货规则}, {id: evt_002, time: 2025-06-11T09:35:00Z, type: feedback, summary: 表示配送速度慢} ], rules: [ 处理退款前先核对订单创建时间 ] }5.5 记忆更新时的“写前查重”技巧更新记忆时我强烈建议做“写前查重”写入前先检索一下库里有没有同一个主题、同一属性的旧记录。有就更新旧记录没有才新增。这个动作虽然多一次检索但能避免大量矛盾记忆堆积。实测案例某客服Agent上线后用户同一个收货地址反复写进画像一周写了12条模型每次拉回来的都是不同的地址用户收货信息完全乱了。后来加了写前查重按用户ID和字段名查重只保留最新的一条问题立刻消失。6. 进阶玩法记忆压缩、结构化记忆与多模态记忆6.1 记忆压缩的三种思路长期跑下来情景事件层会很庞大。压缩方案有三个递进层次。抽取式压缩从对话里提取实体、关键词、结论直接存结构化字段。适合账单、订单、偏好这类信息密度高的内容。生成式压缩让模型把一段对话写成固定格式的摘要适合叙事性内容。重要性评分对每条记忆打一个“对未来回答影响程度”的分高分的长期保留低分的定期清理。打分可以交给模型也可以用一个启发式规则比如包含“永远”“绝对”“以后都”这类词的内容重要性自动加一档。6.2 结构化记忆让模型像查表一样工作纯向量检索适合模糊召回但有些信息需要精确读取。用户当前地址、订单号、偏好开关这类字段就应该用结构化记录。把画像字段定义成JSON每次请求读取对应字段比从全文里检索靠谱得多。更进一步实体关系可以做成简单图谱。用户-偏好-品牌、用户-订单-商品这些三元组适合用图结构存。对于个人助手类应用图谱能回答“用户最近三个月在哪些类目上花的钱最多”这类组合查询单靠向量检索很难一次查出来。6.3 多模态记忆当记忆不只是文字多模态模型的记忆扩展并不复杂核心原则一句话别存原始文件存理解后的结构化信息。语音先转成文字再提炼摘要图片先做描述和关键信息提取再保存字段视频记录取关键帧描述。原始文件留路径不进上下文。为什么这么做原始多媒体文件体积大、进入上下文的成本高而且模型不一定每次都看得全。而“用户上传过一张户型图客厅约25平米朝南”这种结构化描述占用的Token极少还能被后续对话直接引用。6.4 一次多模态记忆的真实场景我做过一个家庭助理方向的模拟项目用户上传“冰箱内食物的照片”Agent把图像内容识别成食品清单再结合用户“这周要控制热量”的偏好生成购物建议。这里至少用了三类记忆图片理解后的内容记录、用户的饮食偏好画像、购买历史事件。三者串起来才组成一次像样的多模态记忆服务。如果只存图片原始路径而不做信息提炼下次对话根本没法直接用。7. 踩坑实录记忆系统最常见的五个事故7.1 记忆污染检索出来的内容反而干扰了回答最典型的事故是用户三年前喜欢某个产品类型最近已经换了偏好。系统检索旧记忆时把三年前的记录当最新信息注入Agent给出了错误的推荐。用户当场就觉得产品是“人工智障”。后来我们给每条记忆加了“采集时间和最后验证时间”检索注入时在Prompt里注明记忆的时间戳并设置规则超过设定时间未更新的偏好只能作为背景不能作为决策依据。这个改动让干扰率明显下降。7.2 记忆漂移同一个问题每次答案不一样记忆漂移的根源是矛盾记忆没有消解。同一主题出现多条旧记忆模型每次检索到的结果不同回答自然飘忽。解决思路就是前面说的写前查重与冲突消解同一属性只保留最新一条冲突发生时主动覆盖。7.3 性能慢检索延迟毁掉了整个对话体验向量检索本身一般很快但加上网络层、模型调用层之后端到端延迟很容易堆到几秒。用户等不住体验直线下降。我的缓解手段是按优先级缓存核心画像层是常驻前缀提前算好拼接结果情景事件层只在必要时检索最近对话走本地缓存。能用短期记忆兜底解决的不要每次都去打检索。7.4 成本失控Token消耗如流水最贵的是把检索结果一股脑全塞进Prompt。一次召回5条记忆、每条500Token再加上上下文成本翻几倍。控制手段很直接限制注入内容长度、用便宜模型做摘要和分类、对低频记忆做缓存。我见过一个项目简单加了一条“每条记忆注入上限200Token”的规则单次调用成本直接降了30%。7.5 隐私与安全记忆越全责任越大记忆系统天然要收集个人信息这是把双刃剑。我的底线是密码、支付信息、身份证号这类核心敏感数据一律不进记忆库对话框内出现的明文敏感信息要自动打码。用户要求删除时提供立即删除接口所有记忆的读取要受权限控制不能跨用户访问。这几点没有妥协空间。7.6 一张问题速查表现象根因首选处理手段回答被旧记忆带偏记忆污染加时间戳与时效分级同一问题答案飘忽记忆漂移写前查重覆盖旧值端到端延迟高检索链路长分层缓存按需检索Token成本上涨注入体积过大限制单条注入长度跨用户信息串缺少权限隔离按用户ID分桶加过滤8. 从Demo到生产一套可以照抄的落地清单8.1 参考架构一个能上生产的记忆系统至少包含五个模块模块职责实现建议对话接入层会话路由、输入输出封装随主服务一起实现记忆管理服务写入触发、读取组装独立服务方便迭代索引存储向量检索与精确读取按数据量选型摘要与提炼上下文压缩、记忆结构化用便宜模型承担数据治理脱敏、删除、权限校验必做不可省略8.2 渐进式路线图人不可能一步到位我建议分四周推进。第一周只做上下文管理和摘要压缩把成本和稳定性先稳住。第二周加向量存储与检索把长期记忆补上。第三周做分层架构和遗忘机制解决矛盾记忆和数据膨胀。第四周开始做评估调优看指标再决定要不要加记忆压缩和结构化记忆。8.3 衡量记忆系统好坏的指标没有指标的优化都是自嗨。我重点看五个指标记忆召回率用户问到旧信息时系统是否能把相关记忆带到上下文里。记忆准确率写入的偏好和用户实际表达的意图是否一致。注入干扰率注入记忆后任务回答的准确率是上升还是下降。端到端延迟包含检索在内的完整响应时间。单位会话成本平均每个会话消耗的Token与费用。8.4 我的几点实际体会做了几个项目的记忆系统之后我最大的体会是记忆系统不是越复杂越好。先跑通“上下文管理 一次简单的向量检索”把基础链路稳定下来再慢慢加分层、遗忘、结构化这些高级功能。每一步都要有明确的指标验证否则你只是在给一个本来就混乱的系统叠更多复杂度。另外还有个技巧所有记忆状态最好都设计成可导出、可回滚、可删除的模块。上周还在用的“用户偏好画像”下周可能需要重新设计结构没有回滚能力一次误写就能污染整个线上环境。如果你正准备给大模型应用加记忆我建议从第一周的上下文管理开始动手别急着架一堆组件。先把每一层记忆的数据形态想清楚再决定用什么存、怎么取。这条路我也走偏过希望这份指南能帮你省掉试错的成本。
阅读完成 · 觉得有帮助？
