1. 从加了 Redis 就该记住这个直觉说起很多人第一次给 Agent 做持久化记忆时脑子里想的都是同一件事把对话历史序列化一下塞进 Redis下次会话开始再读出来问题就解决了。我当初也是这么想的甚至觉得这属于基础设施层面的事跟 Agent 本身的逻辑没什么关系。结果上线之后发现用户第二天回来Agent 表现得像第一次见面——名字不记得、偏好不记得、上次聊到哪一步也不记得。Redis 里数据明明在键也没过期读出来的 JSON 也完整可 Agent 就是失忆。这个现象特别容易让人误判。第一反应通常是去查 Redis 连接、查序列化、查 TTL折腾一圈发现基础设施完全正常。真正的问题不在存储层而在于我们默认了一个错误的前提把历史存下来和让 Agent 用上历史是同一件事。实际上这是两件完全不同的事中间隔着一层被绝大多数人忽略的东西——记忆的组织与召回层。这篇内容适合两类人看一类是正在给对话式 Agent 做多轮记忆、被跨会话失忆折磨过的开发者另一类是还没踩坑、正准备往 Redis 里塞历史的同行提前知道这层缺失能省掉你至少两天的排查时间。我会把整个排查链路、为什么单纯加 Redis 不够、以及那少的一层到底该怎么补完整讲一遍。核心关键词就三个Agent 记忆、跨会话、召回层全文围绕它们展开。先说结论免得你带着疑问往下读Redis 解决的是存得住但 Agent 需要的是想得起。存得住是存储问题想得起是召回问题。你只做了前者Agent 自然会在需要的时候找不到该用的那条记忆。下面我把这个结论拆开从现象到根因再到补法一层层说清楚。2. 跨会话失忆的真实现象与常见误判路径2.1 失忆不是全忘而是选择性想不起来这里有个特别关键的细节很多人没注意到Agent 跨会话之后并不是什么都忘了。如果你把最近几轮对话原封不动塞进上下文它其实能接上话。真正丢的是那些更早的、被压缩过的、或者跨主题的信息。比如用户第一轮说过我对花生过敏聊了二十轮之后提到帮我推荐个餐厅Agent 会推荐带花生酱的菜——因为它上下文里只剩最近几轮那条过敏信息早就被挤出去了。所以失忆这个词其实不准确更准确的说法是召回失败。信息还在 Redis 里躺着但 Agent 在当前这轮对话里没有把它捞出来放进上下文。这就解释了为什么你查 Redis 一切正常因为问题根本不在那儿。我见过一个典型的误判路径开发者发现 Agent 忘了用户名字于是去查存储发现名字字段确实存了于是怀疑是读取逻辑有 bug改了半天读取代码重启服务测试——还是忘。然后又怀疑是并发写入覆盖加了锁还是忘。最后怀疑 Redis 集群主从同步延迟换了个单机实例依然忘。整整两天全花在了存储层而真正的病灶在存了但没召回。2.2 为什么大家默认存了就等于记住了这个思维惯性有它的来源。在传统后端开发里缓存和读取是强绑定的你SET user:123然后GET user:123拿到就是拿到拿不到就是没存。这种存取对称的直觉被无意识地迁移到了 Agent 记忆上。但 Agent 的记忆使用方式和缓存完全不同——它不是按 key 精确取而是根据当前语境模糊找。打个比方。传统缓存像图书馆的取书你报书号管理员去架上拿有就有没有就没有。Agent 记忆像你走进图书馆想找上次看的那本讲海洋生物的书你只记得大概内容得靠检索、靠联想、靠管理员帮你缩小范围。Redis 是个很好的书架但它不会帮你做后面这件事。你只搭了书架没配检索系统书当然找不到。提示判断自己是不是踩了这个坑有个简单方法——把 Redis 里的历史全部 dump 出来人工检查那条被遗忘的信息在不在。如果在那你的问题 100% 不在存储层别再折腾 Redis 了。2.3 一个可复现的最小现象为了让你能自己验证我给一个最小复现思路不涉及具体业务纯逻辑构造一个 Agent系统提示里只放最近 5 轮对话。第一轮用户说我叫 A我住在某城市。然后连续进行 10 轮无关闲聊。第 12 轮问我住哪。你会发现 Agent 答不上来因为那条信息在第 6 轮就被挤出上下文了。此时你去查持久化存储那条信息完好无损。这个实验的价值在于它把存储和召回彻底分离开了。存储层完全正常失忆照样发生。这就逼着你去想——中间到底缺了什么。3. 拆开看存储层、上下文层、召回层各自在干什么要理解少了一层得先把 Agent 记忆涉及的几个层次分清楚。很多人把它们混成一坨所以排查时无从下手。我把它拆成三层每层的职责、常见实现、以及失效表现都不一样。3.1 存储层负责不丢不负责好用存储层就是 Redis、数据库、对象存储这些。它的核心指标是持久性、容量、读写延迟。你把对话历史、用户画像、事实条目写进去它保证不丢。这一层做得好不好看的是数据在不在。但存储层有个天然缺陷它是无语义的。Redis 不知道我对花生过敏比今天天气不错更重要它只知道这是两个字符串。它也不会根据当前对话主题去判断该取哪条。存储层是中立的、被动的你给它什么它存什么你要什么它给什么——前提是你得明确知道要什么。而 Agent 的困境恰恰是它不知道自己该要什么。当前用户说推荐个餐厅Agent 需要意识到过敏信息和这个请求相关但存储层不会替它做这个关联。3.2 上下文层负责当前这轮能用上什么上下文层就是喂给模型的那段 prompt包括系统提示、最近几轮对话、以及任何你手动拼进去的检索结果。它的核心约束是长度有限。不管模型窗口多大你都不可能把所有历史全塞进去——成本扛不住而且塞太多反而稀释了关键信息模型注意力会被淹没。所以上下文层本质上是个筛选结果。问题是筛选由谁来做如果你只是取最近 N 轮那筛选规则就是时间最老的信息最先被淘汰。但信息的重要性跟时间无关——第一轮说的过敏信息可能比第 50 轮的寒暄重要得多。用时间做筛选必然丢关键信息。3.3 召回层被跳过的那一层召回层的职责就一句话在当前语境下从存储层里挑出最该进上下文的那几条记忆。它要解决三个问题——挑哪些相关性、挑多少预算、怎么排优先级。这一层是存储和上下文之间的桥梁。没有它你要么全塞超预算要么只塞最近的丢关键信息。绝大多数加了 Redis 还失忆的案例缺的就是这一层。开发者把存储做了把上下文拼装做了唯独跳过了中间的召回于是存储里的数据成了死数据——存着但永远进不了模型的视野。层次核心职责典型实现失效表现存储层数据不丢、可持久Redis、关系库、向量库数据丢失、读取报错召回层按语境挑相关记忆向量检索、规则打分、混合排序存了但用不上、答非所问上下文层组装当前 prompt模板拼接、token 预算控制超长截断、关键信息被挤掉这张表建议你对着自己的系统过一遍。如果你发现召回层那一栏是空的或者只是简单写了句取最近 10 条那基本可以确诊了。3.4 为什么这层最容易被跳过因为它看起来不像个独立模块。存储是基础设施上下文是 prompt 工程这两个都有明确的存在感。召回夹在中间容易被当成顺手就做了的事——比如在读取历史时顺手slice(-10)。但这个顺手恰恰是问题所在它把召回简化成了时间截取丢掉了相关性判断。另一个原因是召回做起来比存储麻烦。存储是确定性的写进去读出来就完事召回涉及相关性计算、打分、排序还要考虑性能。人天生倾向于先做简单的、确定的部分把难的往后拖。于是存储先上了召回一直待优化Agent 就一直失忆。4. 补上召回层从取最近 N 条到按相关性取知道了缺什么接下来就是怎么补。召回层的实现方式有好几种复杂度从低到高差别很大。我按落地难度排个序你可以根据自己的场景选。4.1 最朴素的做法规则 关键词匹配如果你的 Agent 场景比较垂直比如客服、特定领域助手其实不一定需要上向量检索。用关键词匹配 规则打分就能解决大部分问题。思路是把每条记忆打上标签或抽取关键词当前用户输入也抽关键词做交集匹配命中的记忆优先召回。举个例子记忆条目存成{content: 用户对花生过敏, tags: [过敏, 饮食, 健康]}。当前输入推荐个餐厅抽出的意图标签是[饮食, 推荐]跟饮食命中这条记忆就被召回。这种做法的好处是可解释、可控、零额外依赖坏处是覆盖不全——用户换个说法关键词对不上就漏了。我实测下来规则召回在垂直场景里能覆盖 70% 到 80% 的关键记忆作为第一版完全够用。别一上来就追求向量检索先把规则跑通你会更清楚自己的数据长什么样。4.2 进阶做法向量检索做语义召回当你的记忆条目多、表达多样时关键词就不够用了。这时候上向量检索把每条记忆用 embedding 模型转成向量存起来当前输入也转成向量算余弦相似度取 top-k。这样我对花生过敏和推荐个餐厅即使字面不重合语义上也能关联上如果 embedding 质量够好。向量检索的关键细节在于存什么。很多人直接把整轮对话做 embedding效果很差因为一轮对话里废话太多向量被稀释了。正确做法是先做记忆抽取——从对话里抽出原子化的事实条目比如用户叫 A用户住某城市用户对花生过敏每条单独 embedding。这样召回精度会高一个档次。注意向量检索不是银弹。它对精确事实如订单号、日期反而不如关键词准。所以生产环境里常见的是混合召回向量召回 关键词召回两路结果合并去重再排序。4.3 召回之后还有一步重排与预算控制召回出来的候选可能有很多条不能全塞进上下文。这时候要做重排按相关性分数、时间新鲜度、记忆类型加权排序取前若干条。同时要控制 token 预算——记忆占用的 token 不能挤掉当前对话的空间。我一般会给记忆分配上下文总预算的 20% 到 30%。比如模型窗口 8k那记忆部分最多 2k 左右。超了就按分数砍。这个比例不是死的看场景如果是长期陪伴类 Agent记忆占比可以高些如果是任务型 Agent当前任务上下文更重要记忆占比就低些。4.4 一个可落地的召回流程把上面几步串起来一个完整的召回流程大概是这样用户输入进来先做意图/关键词抽取。并行发起两路召回关键词匹配存储层、向量检索记忆库。两路结果合并按记忆 ID 去重。对合并结果打分相关性分 新鲜度分 类型权重。按分数排序在 token 预算内取 top-k。把选中的记忆格式化后拼进系统提示或对话前缀。记录本轮召回了哪些记忆用于后续效果分析。第 7 步很多人不做但它特别重要。没有召回日志你根本不知道 Agent 为什么答对或答错。我建议从第一版就把召回结果落盘排查问题时能省大量时间。5. 记忆抽取召回质量的上限由它决定召回层做得再好如果存储里躺的都是整轮对话原文效果也好不到哪去。因为原文里噪音太多召回时容易被无关内容干扰。所以召回层之上其实还有个前置动作——记忆抽取。这一步决定了你召回质量的上限。5.1 为什么不能直接存对话原文直接存原文有三个问题。第一冗余用户说我叫 A今年 30住某城市这一句话里三个事实但作为一条记忆它们绑在一起召回住哪时会把年龄也带出来浪费预算。第二噪音寒暄、语气词、重复确认这些对记忆没用但会稀释向量。第三不可更新用户后来说我搬家了原文里两条矛盾信息并存Agent 不知道该信哪个。所以正确做法是把对话蒸馏成原子事实。每条事实独立、可更新、可单独召回。这一步通常用一次轻量的模型调用完成输入是最近几轮对话输出是结构化的事实列表。5.2 抽取什么事实、偏好、状态、事件我一般把记忆分成四类抽取时分别处理事实类姓名、年龄、住址、职业等相对稳定的信息。这类要支持覆盖更新。偏好类喜欢什么、讨厌什么、习惯怎样。这类会累积不覆盖。状态类当前在做什么、进行到哪一步。这类时效性强过期要清理。事件类某天发生了什么、约定过什么。这类带时间戳按时间召回。分类的好处是召回时可以按类型加权。比如当前是任务型对话状态类记忆权重调高是闲聊偏好类权重调高。不分类的话所有记忆一视同仁召回精度会下降。5.3 抽取的时机与成本控制抽取不能每轮都做太费。我的做法是按需触发检测到对话里出现新的、值得记的信息时才抽。判断方式可以是规则出现我叫我喜欢记住等触发词也可以是轻量分类器。抽出来的事实先写存储再更新向量索引。成本上抽取用的模型不需要太强小模型足够。因为抽取是信息压缩任务不是推理任务对模型能力要求不高。我实测用小模型抽取准确率能到 90% 以上成本却只有大模型的零头。这笔账要算清楚否则记忆系统跑起来 token 费用会很吓人。5.4 冲突处理用户改口了怎么办这是抽取环节最容易忽略的问题。用户先说我住 A 城后来说我搬到 B 城了。两条事实冲突。处理方式有两种一是覆盖新事实替换旧事实适合事实类二是并存 时间戳适合偏好类用户可能只是口味变了不是否定过去。覆盖时要小心不能简单按 key 覆盖因为抽取出来的事实未必有稳定的 key。我的做法是给每条事实算一个语义指纹比如对事实内容做归一化后哈希指纹相同或高度相似的视为同一事实新版本覆盖旧版本同时保留更新时间。这样既避免了矛盾又不会误删不相关的事实。6. 排查这类问题的通用思路与几个真实教训讲完原理和方案最后说说排查方法论。这类存了但用不上的问题其实有一套通用的排查顺序掌握了能少走很多弯路。6.1 先确认信息到底进没进存储第一步永远是确认数据在不在。别急着改代码先把存储 dump 出来看。如果信息压根没存进去那是写入逻辑的问题跟召回无关。如果存进去了才进入下一步。这一步能过滤掉一半的误判。6.2 再确认召回有没有被触发如果数据在下一步看召回日志——本轮到底召回了哪些记忆。如果目标记忆根本没出现在召回结果里那是召回逻辑的问题相关性算错了、关键词没命中、向量没检索到。如果召回了但没进上下文那是预算或排序的问题。如果进了上下文但 Agent 还是答错那可能是模型没用好这段上下文属于 prompt 组织的问题。这个链路一层层往下查每层都有明确的判断依据比盲目改代码高效得多。6.3 我踩过的三个坑第一个坑以为 TTL 是罪魁祸首。早期我给记忆设了 7 天过期结果用户一周后回来全忘。我第一反应是 TTL 太短改成永久。但改完发现一周内的用户照样失忆。这才意识到 TTL 只是背锅的真问题是召回。后来我把 TTL 按记忆类型分开设事实类永久状态类短 TTL事件类按需。这才是合理做法。第二个坑向量库和存储库不同步。我一开始把记忆同时写 Redis 和向量库但写入是两步操作中间失败就会出现Redis 有、向量库没有的情况导致这条记忆永远召不回。后来改成先写主存储再用消息队列异步同步到向量库并加了补偿任务定期对账。这个坑很隐蔽因为单看任何一个库都正常。第三个坑召回结果没去重。关键词召回和向量召回各返回一批合并时没去重同一条记忆出现两次白白占了预算还把真正需要的记忆挤出去了。这个 bug 导致 Agent 偶尔答非所问查了好久才发现是重复占位。去重逻辑一定要在合并阶段就做掉。6.4 监控什么指标才能提前发现问题光靠用户反馈发现失忆太被动了。我建议监控这几个指标召回命中率本轮有记忆被召回的比例、召回空转率召回了但没进上下文的比例、记忆覆盖率存储里的记忆被召回过的比例。如果召回空转率高说明预算或排序有问题如果记忆覆盖率长期很低说明大量记忆是死数据召回逻辑覆盖不到。这几个指标不用做得很复杂每天跑个脚本统计一下就行。关键是要有有了才能从用户投诉才发现变成自己提前发现。说到底给 Agent 加记忆这件事存储只是地基召回才是让记忆活起来的那一层。Redis 帮你把书放上了架但你还得配一个会找书的图书管理员。这个管理员就是召回层——它决定了 Agent 到底是记得住还是想得起。我现在的习惯是任何记忆相关的需求先问一句召回怎么做而不是先问存哪。这个顺序一换很多坑就提前避开了。 
长河君 · 2026/10/18 6:17:05 · 阅读 1.2k Agent跨会话失忆真相：Redis存了记忆，为什么还是想不起？
1. 从加了 Redis 就该记住这个直觉说起很多人第一次给 Agent 做持久化记忆时脑子里想的都是同一件事把对话历史序列化一下塞进 Redis下次会话开始再读出来问题就解决了。我当初也是这么想的甚至觉得这属于基础设施层面的事跟 Agent 本身的逻辑没什么关系。结果上线之后发现用户第二天回来Agent 表现得像第一次见面——名字不记得、偏好不记得、上次聊到哪一步也不记得。Redis 里数据明明在键也没过期读出来的 JSON 也完整可 Agent 就是失忆。这个现象特别容易让人误判。第一反应通常是去查 Redis 连接、查序列化、查 TTL折腾一圈发现基础设施完全正常。真正的问题不在存储层而在于我们默认了一个错误的前提把历史存下来和让 Agent 用上历史是同一件事。实际上这是两件完全不同的事中间隔着一层被绝大多数人忽略的东西——记忆的组织与召回层。这篇内容适合两类人看一类是正在给对话式 Agent 做多轮记忆、被跨会话失忆折磨过的开发者另一类是还没踩坑、正准备往 Redis 里塞历史的同行提前知道这层缺失能省掉你至少两天的排查时间。我会把整个排查链路、为什么单纯加 Redis 不够、以及那少的一层到底该怎么补完整讲一遍。核心关键词就三个Agent 记忆、跨会话、召回层全文围绕它们展开。先说结论免得你带着疑问往下读Redis 解决的是存得住但 Agent 需要的是想得起。存得住是存储问题想得起是召回问题。你只做了前者Agent 自然会在需要的时候找不到该用的那条记忆。下面我把这个结论拆开从现象到根因再到补法一层层说清楚。2. 跨会话失忆的真实现象与常见误判路径2.1 失忆不是全忘而是选择性想不起来这里有个特别关键的细节很多人没注意到Agent 跨会话之后并不是什么都忘了。如果你把最近几轮对话原封不动塞进上下文它其实能接上话。真正丢的是那些更早的、被压缩过的、或者跨主题的信息。比如用户第一轮说过我对花生过敏聊了二十轮之后提到帮我推荐个餐厅Agent 会推荐带花生酱的菜——因为它上下文里只剩最近几轮那条过敏信息早就被挤出去了。所以失忆这个词其实不准确更准确的说法是召回失败。信息还在 Redis 里躺着但 Agent 在当前这轮对话里没有把它捞出来放进上下文。这就解释了为什么你查 Redis 一切正常因为问题根本不在那儿。我见过一个典型的误判路径开发者发现 Agent 忘了用户名字于是去查存储发现名字字段确实存了于是怀疑是读取逻辑有 bug改了半天读取代码重启服务测试——还是忘。然后又怀疑是并发写入覆盖加了锁还是忘。最后怀疑 Redis 集群主从同步延迟换了个单机实例依然忘。整整两天全花在了存储层而真正的病灶在存了但没召回。2.2 为什么大家默认存了就等于记住了这个思维惯性有它的来源。在传统后端开发里缓存和读取是强绑定的你SET user:123然后GET user:123拿到就是拿到拿不到就是没存。这种存取对称的直觉被无意识地迁移到了 Agent 记忆上。但 Agent 的记忆使用方式和缓存完全不同——它不是按 key 精确取而是根据当前语境模糊找。打个比方。传统缓存像图书馆的取书你报书号管理员去架上拿有就有没有就没有。Agent 记忆像你走进图书馆想找上次看的那本讲海洋生物的书你只记得大概内容得靠检索、靠联想、靠管理员帮你缩小范围。Redis 是个很好的书架但它不会帮你做后面这件事。你只搭了书架没配检索系统书当然找不到。提示判断自己是不是踩了这个坑有个简单方法——把 Redis 里的历史全部 dump 出来人工检查那条被遗忘的信息在不在。如果在那你的问题 100% 不在存储层别再折腾 Redis 了。2.3 一个可复现的最小现象为了让你能自己验证我给一个最小复现思路不涉及具体业务纯逻辑构造一个 Agent系统提示里只放最近 5 轮对话。第一轮用户说我叫 A我住在某城市。然后连续进行 10 轮无关闲聊。第 12 轮问我住哪。你会发现 Agent 答不上来因为那条信息在第 6 轮就被挤出上下文了。此时你去查持久化存储那条信息完好无损。这个实验的价值在于它把存储和召回彻底分离开了。存储层完全正常失忆照样发生。这就逼着你去想——中间到底缺了什么。3. 拆开看存储层、上下文层、召回层各自在干什么要理解少了一层得先把 Agent 记忆涉及的几个层次分清楚。很多人把它们混成一坨所以排查时无从下手。我把它拆成三层每层的职责、常见实现、以及失效表现都不一样。3.1 存储层负责不丢不负责好用存储层就是 Redis、数据库、对象存储这些。它的核心指标是持久性、容量、读写延迟。你把对话历史、用户画像、事实条目写进去它保证不丢。这一层做得好不好看的是数据在不在。但存储层有个天然缺陷它是无语义的。Redis 不知道我对花生过敏比今天天气不错更重要它只知道这是两个字符串。它也不会根据当前对话主题去判断该取哪条。存储层是中立的、被动的你给它什么它存什么你要什么它给什么——前提是你得明确知道要什么。而 Agent 的困境恰恰是它不知道自己该要什么。当前用户说推荐个餐厅Agent 需要意识到过敏信息和这个请求相关但存储层不会替它做这个关联。3.2 上下文层负责当前这轮能用上什么上下文层就是喂给模型的那段 prompt包括系统提示、最近几轮对话、以及任何你手动拼进去的检索结果。它的核心约束是长度有限。不管模型窗口多大你都不可能把所有历史全塞进去——成本扛不住而且塞太多反而稀释了关键信息模型注意力会被淹没。所以上下文层本质上是个筛选结果。问题是筛选由谁来做如果你只是取最近 N 轮那筛选规则就是时间最老的信息最先被淘汰。但信息的重要性跟时间无关——第一轮说的过敏信息可能比第 50 轮的寒暄重要得多。用时间做筛选必然丢关键信息。3.3 召回层被跳过的那一层召回层的职责就一句话在当前语境下从存储层里挑出最该进上下文的那几条记忆。它要解决三个问题——挑哪些相关性、挑多少预算、怎么排优先级。这一层是存储和上下文之间的桥梁。没有它你要么全塞超预算要么只塞最近的丢关键信息。绝大多数加了 Redis 还失忆的案例缺的就是这一层。开发者把存储做了把上下文拼装做了唯独跳过了中间的召回于是存储里的数据成了死数据——存着但永远进不了模型的视野。层次核心职责典型实现失效表现存储层数据不丢、可持久Redis、关系库、向量库数据丢失、读取报错召回层按语境挑相关记忆向量检索、规则打分、混合排序存了但用不上、答非所问上下文层组装当前 prompt模板拼接、token 预算控制超长截断、关键信息被挤掉这张表建议你对着自己的系统过一遍。如果你发现召回层那一栏是空的或者只是简单写了句取最近 10 条那基本可以确诊了。3.4 为什么这层最容易被跳过因为它看起来不像个独立模块。存储是基础设施上下文是 prompt 工程这两个都有明确的存在感。召回夹在中间容易被当成顺手就做了的事——比如在读取历史时顺手slice(-10)。但这个顺手恰恰是问题所在它把召回简化成了时间截取丢掉了相关性判断。另一个原因是召回做起来比存储麻烦。存储是确定性的写进去读出来就完事召回涉及相关性计算、打分、排序还要考虑性能。人天生倾向于先做简单的、确定的部分把难的往后拖。于是存储先上了召回一直待优化Agent 就一直失忆。4. 补上召回层从取最近 N 条到按相关性取知道了缺什么接下来就是怎么补。召回层的实现方式有好几种复杂度从低到高差别很大。我按落地难度排个序你可以根据自己的场景选。4.1 最朴素的做法规则 关键词匹配如果你的 Agent 场景比较垂直比如客服、特定领域助手其实不一定需要上向量检索。用关键词匹配 规则打分就能解决大部分问题。思路是把每条记忆打上标签或抽取关键词当前用户输入也抽关键词做交集匹配命中的记忆优先召回。举个例子记忆条目存成{content: 用户对花生过敏, tags: [过敏, 饮食, 健康]}。当前输入推荐个餐厅抽出的意图标签是[饮食, 推荐]跟饮食命中这条记忆就被召回。这种做法的好处是可解释、可控、零额外依赖坏处是覆盖不全——用户换个说法关键词对不上就漏了。我实测下来规则召回在垂直场景里能覆盖 70% 到 80% 的关键记忆作为第一版完全够用。别一上来就追求向量检索先把规则跑通你会更清楚自己的数据长什么样。4.2 进阶做法向量检索做语义召回当你的记忆条目多、表达多样时关键词就不够用了。这时候上向量检索把每条记忆用 embedding 模型转成向量存起来当前输入也转成向量算余弦相似度取 top-k。这样我对花生过敏和推荐个餐厅即使字面不重合语义上也能关联上如果 embedding 质量够好。向量检索的关键细节在于存什么。很多人直接把整轮对话做 embedding效果很差因为一轮对话里废话太多向量被稀释了。正确做法是先做记忆抽取——从对话里抽出原子化的事实条目比如用户叫 A用户住某城市用户对花生过敏每条单独 embedding。这样召回精度会高一个档次。注意向量检索不是银弹。它对精确事实如订单号、日期反而不如关键词准。所以生产环境里常见的是混合召回向量召回 关键词召回两路结果合并去重再排序。4.3 召回之后还有一步重排与预算控制召回出来的候选可能有很多条不能全塞进上下文。这时候要做重排按相关性分数、时间新鲜度、记忆类型加权排序取前若干条。同时要控制 token 预算——记忆占用的 token 不能挤掉当前对话的空间。我一般会给记忆分配上下文总预算的 20% 到 30%。比如模型窗口 8k那记忆部分最多 2k 左右。超了就按分数砍。这个比例不是死的看场景如果是长期陪伴类 Agent记忆占比可以高些如果是任务型 Agent当前任务上下文更重要记忆占比就低些。4.4 一个可落地的召回流程把上面几步串起来一个完整的召回流程大概是这样用户输入进来先做意图/关键词抽取。并行发起两路召回关键词匹配存储层、向量检索记忆库。两路结果合并按记忆 ID 去重。对合并结果打分相关性分 新鲜度分 类型权重。按分数排序在 token 预算内取 top-k。把选中的记忆格式化后拼进系统提示或对话前缀。记录本轮召回了哪些记忆用于后续效果分析。第 7 步很多人不做但它特别重要。没有召回日志你根本不知道 Agent 为什么答对或答错。我建议从第一版就把召回结果落盘排查问题时能省大量时间。5. 记忆抽取召回质量的上限由它决定召回层做得再好如果存储里躺的都是整轮对话原文效果也好不到哪去。因为原文里噪音太多召回时容易被无关内容干扰。所以召回层之上其实还有个前置动作——记忆抽取。这一步决定了你召回质量的上限。5.1 为什么不能直接存对话原文直接存原文有三个问题。第一冗余用户说我叫 A今年 30住某城市这一句话里三个事实但作为一条记忆它们绑在一起召回住哪时会把年龄也带出来浪费预算。第二噪音寒暄、语气词、重复确认这些对记忆没用但会稀释向量。第三不可更新用户后来说我搬家了原文里两条矛盾信息并存Agent 不知道该信哪个。所以正确做法是把对话蒸馏成原子事实。每条事实独立、可更新、可单独召回。这一步通常用一次轻量的模型调用完成输入是最近几轮对话输出是结构化的事实列表。5.2 抽取什么事实、偏好、状态、事件我一般把记忆分成四类抽取时分别处理事实类姓名、年龄、住址、职业等相对稳定的信息。这类要支持覆盖更新。偏好类喜欢什么、讨厌什么、习惯怎样。这类会累积不覆盖。状态类当前在做什么、进行到哪一步。这类时效性强过期要清理。事件类某天发生了什么、约定过什么。这类带时间戳按时间召回。分类的好处是召回时可以按类型加权。比如当前是任务型对话状态类记忆权重调高是闲聊偏好类权重调高。不分类的话所有记忆一视同仁召回精度会下降。5.3 抽取的时机与成本控制抽取不能每轮都做太费。我的做法是按需触发检测到对话里出现新的、值得记的信息时才抽。判断方式可以是规则出现我叫我喜欢记住等触发词也可以是轻量分类器。抽出来的事实先写存储再更新向量索引。成本上抽取用的模型不需要太强小模型足够。因为抽取是信息压缩任务不是推理任务对模型能力要求不高。我实测用小模型抽取准确率能到 90% 以上成本却只有大模型的零头。这笔账要算清楚否则记忆系统跑起来 token 费用会很吓人。5.4 冲突处理用户改口了怎么办这是抽取环节最容易忽略的问题。用户先说我住 A 城后来说我搬到 B 城了。两条事实冲突。处理方式有两种一是覆盖新事实替换旧事实适合事实类二是并存 时间戳适合偏好类用户可能只是口味变了不是否定过去。覆盖时要小心不能简单按 key 覆盖因为抽取出来的事实未必有稳定的 key。我的做法是给每条事实算一个语义指纹比如对事实内容做归一化后哈希指纹相同或高度相似的视为同一事实新版本覆盖旧版本同时保留更新时间。这样既避免了矛盾又不会误删不相关的事实。6. 排查这类问题的通用思路与几个真实教训讲完原理和方案最后说说排查方法论。这类存了但用不上的问题其实有一套通用的排查顺序掌握了能少走很多弯路。6.1 先确认信息到底进没进存储第一步永远是确认数据在不在。别急着改代码先把存储 dump 出来看。如果信息压根没存进去那是写入逻辑的问题跟召回无关。如果存进去了才进入下一步。这一步能过滤掉一半的误判。6.2 再确认召回有没有被触发如果数据在下一步看召回日志——本轮到底召回了哪些记忆。如果目标记忆根本没出现在召回结果里那是召回逻辑的问题相关性算错了、关键词没命中、向量没检索到。如果召回了但没进上下文那是预算或排序的问题。如果进了上下文但 Agent 还是答错那可能是模型没用好这段上下文属于 prompt 组织的问题。这个链路一层层往下查每层都有明确的判断依据比盲目改代码高效得多。6.3 我踩过的三个坑第一个坑以为 TTL 是罪魁祸首。早期我给记忆设了 7 天过期结果用户一周后回来全忘。我第一反应是 TTL 太短改成永久。但改完发现一周内的用户照样失忆。这才意识到 TTL 只是背锅的真问题是召回。后来我把 TTL 按记忆类型分开设事实类永久状态类短 TTL事件类按需。这才是合理做法。第二个坑向量库和存储库不同步。我一开始把记忆同时写 Redis 和向量库但写入是两步操作中间失败就会出现Redis 有、向量库没有的情况导致这条记忆永远召不回。后来改成先写主存储再用消息队列异步同步到向量库并加了补偿任务定期对账。这个坑很隐蔽因为单看任何一个库都正常。第三个坑召回结果没去重。关键词召回和向量召回各返回一批合并时没去重同一条记忆出现两次白白占了预算还把真正需要的记忆挤出去了。这个 bug 导致 Agent 偶尔答非所问查了好久才发现是重复占位。去重逻辑一定要在合并阶段就做掉。6.4 监控什么指标才能提前发现问题光靠用户反馈发现失忆太被动了。我建议监控这几个指标召回命中率本轮有记忆被召回的比例、召回空转率召回了但没进上下文的比例、记忆覆盖率存储里的记忆被召回过的比例。如果召回空转率高说明预算或排序有问题如果记忆覆盖率长期很低说明大量记忆是死数据召回逻辑覆盖不到。这几个指标不用做得很复杂每天跑个脚本统计一下就行。关键是要有有了才能从用户投诉才发现变成自己提前发现。说到底给 Agent 加记忆这件事存储只是地基召回才是让记忆活起来的那一层。Redis 帮你把书放上了架但你还得配一个会找书的图书管理员。这个管理员就是召回层——它决定了 Agent 到底是记得住还是想得起。我现在的习惯是任何记忆相关的需求先问一句召回怎么做而不是先问存哪。这个顺序一换很多坑就提前避开了。