1. 记忆系统到底在解决什么问题智能体做任务的时候最让人头疼的一件事就是“聊完就忘”。你上一轮告诉它用户偏好、任务背景、已经排除的方案下一轮它就像第一次见面一样重新问一遍。这不是模型不够聪明而是它压根没有一套像样的记忆机制。我最早接触这类需求是在做一个多轮任务编排的模拟项目时。当时智能体需要连续处理十几个步骤每一步都依赖前面步骤产出的中间结果。结果发现只要对话轮次一多前面说过的约束条件就丢了导致后面生成的方案和前面的设定自相矛盾。那时候我才意识到记忆系统不是锦上添花的功能而是智能体能否稳定完成复杂任务的基础设施。所谓记忆系统说白了就是给智能体配一套“记事儿”的机制。它要解决的核心问题有三个第一存什么——哪些信息值得记哪些是噪音第二怎么存——用什么结构组织方便后续检索第三怎么用——在需要的时候把相关记忆捞出来塞进当前推理上下文。这套东西适合谁来参考如果你正在做对话系统、任务型智能体、个人助理类应用或者任何需要跨轮次保持状态的项目那记忆系统就是你绕不过去的一环。哪怕你只是用现成的智能体框架搭东西理解记忆系统的设计逻辑也能帮你判断什么时候该用短期缓存、什么时候该上向量库。接下来我会从整体设计思路讲起然后拆解核心细节再给出一套可复现的实操方案最后把我踩过的坑和排查经验整理出来。内容会尽量贴近实际工程不搞纯理论。2. 记忆系统的整体设计与思路拆解2.1 为什么不能只靠上下文窗口硬撑很多人第一反应是现在模型上下文窗口不是越来越大吗直接把所有历史都塞进去不就行了我一开始也这么想实测下来问题很多。首先是成本问题。上下文越长每次推理的token消耗越大如果每轮都把完整历史带上费用会线性增长。其次是注意力稀释。上下文里塞太多无关信息模型反而抓不住重点该记住的没记住不该记的干扰了判断。最后是窗口上限。再大的窗口也有边界长任务跑几十轮之后照样溢出。所以记忆系统的本质是在上下文窗口之外建一套可持久化、可检索、可裁剪的存储层。它和上下文窗口的关系类似于电脑的内存和硬盘内存快但容量有限硬盘慢但能存东西需要的时候再把相关数据调进内存。2.2 短期记忆与长期记忆的分层设计我在实际项目里会把记忆分成两层这个分层思路参考了常见智能体架构的实践。短期记忆负责当前会话内的即时状态比如最近几轮对话、当前任务进度、临时变量。它通常直接放在上下文里或者用一个固定长度的队列维护超出长度就淘汰最旧的。短期记忆的特点是读写快、容量小、生命周期短。长期记忆负责跨会话、跨任务的知识沉淀比如用户偏好、历史决策、领域知识。它需要持久化存储通常用向量数据库或者结构化数据库来存检索时按相关性召回。长期记忆的特点是容量大、读写相对慢、生命周期长。这两层不是割裂的而是有流转机制。比如短期记忆里反复出现的重要信息可以提炼后写入长期记忆长期记忆里召回的内容会临时注入短期记忆供当前推理使用。2.3 存储选型的考量向量库、KV库还是图数据库存记忆用什么取决于你要存什么类型的记忆。我整理了一个选型对照表方便你按场景判断。存储类型适合的记忆内容检索方式典型场景向量数据库语义化文本片段、对话摘要相似度检索用户偏好召回、知识片段匹配KV存储结构化状态、键值对配置精确键查询任务进度、会话状态关系型数据库有明确关系的数据SQL查询用户档案、历史记录图数据库实体间复杂关系图遍历知识图谱类记忆我大多数项目里用的是“向量库KV库”的组合。向量库存语义记忆KV库存状态记忆。原因很简单语义召回靠向量相似度最自然而状态类数据用键值对查最快没必要什么都往向量库里塞。注意不要一上来就上图数据库。图数据库的维护成本高除非你的记忆确实有复杂的实体关系需要遍历否则向量库加KV库足够覆盖八成场景。2.4 记忆的写入、检索与遗忘机制一套完整的记忆系统光有存储不够还得有写入、检索、遗忘三个动作的策略。写入策略决定什么信息进记忆。我的做法是设一个“重要性评分”综合考量信息的新颖度、重复出现次数、是否包含关键实体。评分超过阈值才写入长期记忆否则只留在短期记忆里。这样可以避免记忆库被废话撑爆。检索策略决定怎么把记忆捞出来。常见做法是把当前查询转成向量在记忆库里做相似度搜索取Top-K条。但纯向量检索有时候会漏掉关键词精确匹配的情况所以我会再加一路关键词检索两路结果合并去重。遗忘机制决定什么记忆该淘汰。记忆不是越多越好过时、矛盾、低价值的记忆会干扰推理。我会给每条记忆设一个“新鲜度”衰减因子长期没被召回的记忆逐渐降权低于阈值就归档或删除。3. 核心细节解析与实操要点3.1 记忆条目的数据结构设计记忆存成什么样直接决定了后续检索好不好用。我踩过的坑是一开始只存了纯文本结果检索出来没法判断时效性和来源导致召回了一堆过时信息。后来我固定了一套记忆条目的结构每条记忆包含这几个字段content记忆正文文本形式embedding内容的向量表示用于相似度检索timestamp写入时间用于时效性衰减importance重要性评分0到1之间source来源标识区分是用户说的还是系统推断的access_count被召回次数用于热度加权tags标签列表用于分类过滤这个结构看起来字段多但每个都有用。timestamp和importance配合做衰减access_count做热度加权tags做检索时的预过滤。实际检索时最终得分是相似度、重要性、新鲜度、热度的加权和这样召回结果更符合直觉。3.2 记忆写入的触发时机与去重写入时机很关键。如果每轮对话都写记忆库很快就满了如果写得太少又记不住东西。我的经验是设几个触发点用户显式表达偏好时比如“我喜欢简洁的回答”这种必须写。任务关键决策点比如“方案A被排除了因为成本太高”这种要写。信息重复出现时同一件事被提到两次以上说明重要写入。会话结束时对整段对话做一次摘要把摘要写入长期记忆。去重也很重要。我遇到过同一个偏好被写了十几遍检索时全是重复内容。解决办法是写入前先做一次相似度检查如果和已有记忆的相似度超过阈值我一般设0.92就不新增而是更新已有记忆的时间戳和access_count。def should_write(new_content, existing_memories, threshold0.92): new_emb embed(new_content) for mem in existing_memories: sim cosine_similarity(new_emb, mem[embedding]) if sim threshold: mem[timestamp] now() mem[access_count] 1 return False return True这段逻辑不复杂但能省掉大量重复存储。3.3 检索时的相关性排序与重排检索不是简单取Top-K就完事。我一开始只按向量相似度排序结果发现有些高相似度的记忆其实已经过时了反而误导了推理。后来我改成两阶段先召回再重排。召回阶段用向量检索取Top-20同时用关键词检索取Top-20合并去重得到一个候选集。重排阶段对候选集重新打分打分公式大致是final_score 0.5 * 相似度 0.2 * 重要性 0.2 * 新鲜度 0.1 * 热度权重可以根据场景调。比如做知识问答相似度权重可以高一些做个性化推荐重要性权重可以高一些。新鲜度用时间衰减函数算热度用access_count归一化。重排之后取Top-5注入上下文这样既保证了相关性又兼顾了时效和质量。3.4 记忆注入上下文的方式与长度控制检索出来的记忆怎么塞进上下文也有讲究。我试过两种方式一种是直接拼接把记忆内容原样加到系统提示里。这种方式简单但记忆多了会占用大量token而且格式混乱。另一种是结构化注入把记忆整理成固定格式比如“已知用户偏好...历史决策...相关背景...”。这种方式更清晰模型更容易理解。我现在用的是结构化注入并且严格控制注入长度。一般注入的记忆总长度不超过上下文窗口的15%留足空间给当前对话和推理。如果记忆太多就只注入重排后的Top-3其余的留在库里等下次用。提示注入记忆时最好带上时间标记比如“三天前用户提到...”这样模型能判断信息的时效性避免把过时信息当当前事实用。4. 实操过程与核心环节实现4.1 环境准备与依赖选型这套记忆系统我用Python实现核心依赖就几个向量化模型、向量数据库客户端、一个轻量KV存储。向量化模型可以用现成的文本嵌入接口也可以本地部署小模型。向量数据库我选的是支持持久化和元数据过滤的方案KV存储直接用SQLite就够没必要上重型数据库。环境准备步骤安装Python 3.10以上版本确保依赖兼容。安装向量数据库客户端和嵌入模型依赖。初始化SQLite数据库文件建两张表一张存记忆条目一张存会话状态。配置嵌入模型的维度和相似度度量方式我一般用余弦相似度。这里有个细节嵌入模型的维度要和向量库的索引维度一致否则写入会报错。我踩过一次坑换了嵌入模型但忘了改向量库配置结果写入全失败排查了半天。4.2 记忆写入模块的实现写入模块的核心逻辑是接收一条候选记忆判断是否值得写值得写就生成嵌入、算重要性、存库。def write_memory(content, source, tagsNone): if not should_write(content, get_recent_memories()): return emb embed(content) importance calc_importance(content, source) mem { content: content, embedding: emb, timestamp: now(), importance: importance, source: source, access_count: 0, tags: tags or [] } vector_db.insert(mem) kv_db.set(fmem:{mem[id]}, mem)重要性评分我用了几个启发式规则包含“喜欢”“偏好”“不要”“必须”等词的加分来自用户显式表达的加分包含具体实体人名、时间、数字的加分。这套规则不完美但比不评要好得多。4.3 记忆检索模块的实现检索模块负责根据当前查询召回相关记忆。我实现的是混合检索加重的方案。def retrieve_memories(query, top_k5): query_emb embed(query) vec_results vector_db.search(query_emb, top_k20) kw_results keyword_search(query, top_k20) candidates merge_dedup(vec_results, kw_results) scored [] for mem in candidates: sim cosine_similarity(query_emb, mem[embedding]) freshness decay(mem[timestamp]) heat normalize(mem[access_count]) score 0.5*sim 0.2*mem[importance] 0.2*freshness 0.1*heat scored.append((score, mem)) scored.sort(reverseTrue) return [m for _, m in scored[:top_k]]这里的关键是decay函数。我用的是指数衰减半衰期设7天。也就是说一条记忆7天没被召回新鲜度降到0.514天降到0.25。这样自然淘汰旧记忆不用手动清理。4.4 记忆注入与上下文组装检索到记忆后要组装进当前推理的上下文。我的组装顺序是系统提示、记忆区块、最近对话、当前查询。记忆区块的格式我固定成[相关记忆] - (3天前, 重要性高) 用户偏好简洁回答 - (1天前, 重要性中) 方案A因成本被排除 - (刚刚, 重要性高) 当前任务目标是生成报告这种格式模型很容易解析。注入时我会限制总条数和总字数一般不超过5条、500字。如果记忆太多就按重排分数截断。4.5 遗忘与归档的定时任务遗忘机制我做成定时任务每天跑一次。逻辑是遍历所有记忆算新鲜度低于0.1的归档到冷存储低于0.05的直接删除。归档的记忆不参与常规检索但保留在冷库里万一需要还能查。def forget_task(): for mem in vector_db.get_all(): freshness decay(mem[timestamp]) if freshness 0.05: vector_db.delete(mem[id]) elif freshness 0.1: archive(mem)这个任务我一般放在低峰期跑避免影响在线检索性能。5. 常见问题与排查技巧实录5.1 记忆检索不准的排查思路检索不准是最常见的问题表现是召回的记忆和当前查询不相关。排查我一般按这个顺序检查嵌入模型。嵌入质量差相似度计算就不准。可以拿几条明显相关的文本测一下相似度如果分数很低说明模型不适合当前领域。检查检索参数。Top-K设太小会漏设太大引入噪音。我一般从20开始调。检查重排权重。如果新鲜度权重太高会召回很多新但不相关的记忆相似度权重太高又会召回旧但相关的。需要按场景调。检查记忆质量。如果写入的记忆本身就是废话检索再准也没用。回头看看写入策略是不是太宽松。5.2 记忆冲突与矛盾的解决同一个问题记忆库里存了互相矛盾的两条比如用户先说喜欢A后来说喜欢B。这种情况检索出来会让模型困惑。我的解决办法是引入记忆版本概念。每条记忆有个version字段新记忆写入时如果和旧记忆冲突就把旧记忆标记为superseded检索时默认只召回最新版本。判断冲突用相似度加实体匹配相似度高但结论相反的就判定为冲突。注意冲突判断不要全自动有些矛盾其实是不同场景下的不同偏好不是真的冲突。我一般会把疑似冲突的记忆标出来人工确认后再处理。5.3 记忆膨胀导致性能下降记忆库越来越大检索越来越慢这是必然的。我遇到过检索延迟从50毫秒涨到500毫秒的情况。解决办法有三个一是定期归档把低价值记忆移到冷存储二是加索引向量库一般支持索引优化记得开三是分片按时间或标签把记忆分到不同集合检索时只查相关分片。我一般组合用归档加索引能解决大部分性能问题。5.4 常见问题速查表问题现象可能原因排查方向解决建议召回不相关记忆嵌入模型不匹配测相似度分数换模型或微调召回重复记忆写入去重失效检查相似度阈值调低阈值或加去重检索延迟高记忆库过大看库大小和索引归档加索引记忆矛盾版本管理缺失查冲突记忆引入版本标记重要记忆丢失衰减太快看新鲜度参数调半衰期注入超长条数没限制看注入逻辑加条数和字数上限5.5 几个我踩过的坑和实操心得第一个坑是嵌入模型换版本。有次我升级了嵌入模型维度从768变成1024结果旧记忆全部检索失败。教训是换模型必须重建所有记忆的嵌入或者做维度兼容处理。第二个坑是时间戳时区混乱。服务器时区和数据库时区不一致导致新鲜度计算错乱新记忆被当成旧的淘汰了。后来我统一用UTC时间戳问题解决。第三个坑是过度依赖自动写入。一开始我让系统自动判断什么该记结果记了一堆无关紧要的寒暄。后来改成自动加人工确认关键记忆手动标记质量才上来。心得方面我觉得最重要的一条是记忆系统要可观测。你得能看到记忆库里有什么、检索时召回了什么、注入后模型用了什么。我专门做了个调试面板实时显示这些信息排查问题效率高很多。另外记忆不是越多越好。我见过有人恨不得把每句话都存下来结果检索时全是噪音。精简的记忆库比庞大的记忆库好用得多宁可少记不可乱记。最后测试要覆盖边界情况。比如空记忆库、超长记忆、冲突记忆、过期记忆这些边界不测上线后必出问题。我一般会写一套边界测试用例每次改检索逻辑都跑一遍。这套记忆系统我在几个模拟项目里跑下来稳定性还不错。核心就是分层存储、混合检索、加权重排、定期遗忘这四件事。每件事单独看都不复杂组合起来就能让智能体真正“记住”东西。如果你正在做类似的东西建议先从最简单的KV存储加向量检索起步跑通了再逐步加复杂度别一上来就搞大而全的架构。
1. 记忆系统到底在解决什么问题智能体做任务的时候最让人头疼的一件事就是“聊完就忘”。你上一轮告诉它用户偏好、任务背景、已经排除的方案下一轮它就像第一次见面一样重新问一遍。这不是模型不够聪明而是它压根没有一套像样的记忆机制。我最早接触这类需求是在做一个多轮任务编排的模拟项目时。当时智能体需要连续处理十几个步骤每一步都依赖前面步骤产出的中间结果。结果发现只要对话轮次一多前面说过的约束条件就丢了导致后面生成的方案和前面的设定自相矛盾。那时候我才意识到记忆系统不是锦上添花的功能而是智能体能否稳定完成复杂任务的基础设施。所谓记忆系统说白了就是给智能体配一套“记事儿”的机制。它要解决的核心问题有三个第一存什么——哪些信息值得记哪些是噪音第二怎么存——用什么结构组织方便后续检索第三怎么用——在需要的时候把相关记忆捞出来塞进当前推理上下文。这套东西适合谁来参考如果你正在做对话系统、任务型智能体、个人助理类应用或者任何需要跨轮次保持状态的项目那记忆系统就是你绕不过去的一环。哪怕你只是用现成的智能体框架搭东西理解记忆系统的设计逻辑也能帮你判断什么时候该用短期缓存、什么时候该上向量库。接下来我会从整体设计思路讲起然后拆解核心细节再给出一套可复现的实操方案最后把我踩过的坑和排查经验整理出来。内容会尽量贴近实际工程不搞纯理论。2. 记忆系统的整体设计与思路拆解2.1 为什么不能只靠上下文窗口硬撑很多人第一反应是现在模型上下文窗口不是越来越大吗直接把所有历史都塞进去不就行了我一开始也这么想实测下来问题很多。首先是成本问题。上下文越长每次推理的token消耗越大如果每轮都把完整历史带上费用会线性增长。其次是注意力稀释。上下文里塞太多无关信息模型反而抓不住重点该记住的没记住不该记的干扰了判断。最后是窗口上限。再大的窗口也有边界长任务跑几十轮之后照样溢出。所以记忆系统的本质是在上下文窗口之外建一套可持久化、可检索、可裁剪的存储层。它和上下文窗口的关系类似于电脑的内存和硬盘内存快但容量有限硬盘慢但能存东西需要的时候再把相关数据调进内存。2.2 短期记忆与长期记忆的分层设计我在实际项目里会把记忆分成两层这个分层思路参考了常见智能体架构的实践。短期记忆负责当前会话内的即时状态比如最近几轮对话、当前任务进度、临时变量。它通常直接放在上下文里或者用一个固定长度的队列维护超出长度就淘汰最旧的。短期记忆的特点是读写快、容量小、生命周期短。长期记忆负责跨会话、跨任务的知识沉淀比如用户偏好、历史决策、领域知识。它需要持久化存储通常用向量数据库或者结构化数据库来存检索时按相关性召回。长期记忆的特点是容量大、读写相对慢、生命周期长。这两层不是割裂的而是有流转机制。比如短期记忆里反复出现的重要信息可以提炼后写入长期记忆长期记忆里召回的内容会临时注入短期记忆供当前推理使用。2.3 存储选型的考量向量库、KV库还是图数据库存记忆用什么取决于你要存什么类型的记忆。我整理了一个选型对照表方便你按场景判断。存储类型适合的记忆内容检索方式典型场景向量数据库语义化文本片段、对话摘要相似度检索用户偏好召回、知识片段匹配KV存储结构化状态、键值对配置精确键查询任务进度、会话状态关系型数据库有明确关系的数据SQL查询用户档案、历史记录图数据库实体间复杂关系图遍历知识图谱类记忆我大多数项目里用的是“向量库KV库”的组合。向量库存语义记忆KV库存状态记忆。原因很简单语义召回靠向量相似度最自然而状态类数据用键值对查最快没必要什么都往向量库里塞。注意不要一上来就上图数据库。图数据库的维护成本高除非你的记忆确实有复杂的实体关系需要遍历否则向量库加KV库足够覆盖八成场景。2.4 记忆的写入、检索与遗忘机制一套完整的记忆系统光有存储不够还得有写入、检索、遗忘三个动作的策略。写入策略决定什么信息进记忆。我的做法是设一个“重要性评分”综合考量信息的新颖度、重复出现次数、是否包含关键实体。评分超过阈值才写入长期记忆否则只留在短期记忆里。这样可以避免记忆库被废话撑爆。检索策略决定怎么把记忆捞出来。常见做法是把当前查询转成向量在记忆库里做相似度搜索取Top-K条。但纯向量检索有时候会漏掉关键词精确匹配的情况所以我会再加一路关键词检索两路结果合并去重。遗忘机制决定什么记忆该淘汰。记忆不是越多越好过时、矛盾、低价值的记忆会干扰推理。我会给每条记忆设一个“新鲜度”衰减因子长期没被召回的记忆逐渐降权低于阈值就归档或删除。3. 核心细节解析与实操要点3.1 记忆条目的数据结构设计记忆存成什么样直接决定了后续检索好不好用。我踩过的坑是一开始只存了纯文本结果检索出来没法判断时效性和来源导致召回了一堆过时信息。后来我固定了一套记忆条目的结构每条记忆包含这几个字段content记忆正文文本形式embedding内容的向量表示用于相似度检索timestamp写入时间用于时效性衰减importance重要性评分0到1之间source来源标识区分是用户说的还是系统推断的access_count被召回次数用于热度加权tags标签列表用于分类过滤这个结构看起来字段多但每个都有用。timestamp和importance配合做衰减access_count做热度加权tags做检索时的预过滤。实际检索时最终得分是相似度、重要性、新鲜度、热度的加权和这样召回结果更符合直觉。3.2 记忆写入的触发时机与去重写入时机很关键。如果每轮对话都写记忆库很快就满了如果写得太少又记不住东西。我的经验是设几个触发点用户显式表达偏好时比如“我喜欢简洁的回答”这种必须写。任务关键决策点比如“方案A被排除了因为成本太高”这种要写。信息重复出现时同一件事被提到两次以上说明重要写入。会话结束时对整段对话做一次摘要把摘要写入长期记忆。去重也很重要。我遇到过同一个偏好被写了十几遍检索时全是重复内容。解决办法是写入前先做一次相似度检查如果和已有记忆的相似度超过阈值我一般设0.92就不新增而是更新已有记忆的时间戳和access_count。def should_write(new_content, existing_memories, threshold0.92): new_emb embed(new_content) for mem in existing_memories: sim cosine_similarity(new_emb, mem[embedding]) if sim threshold: mem[timestamp] now() mem[access_count] 1 return False return True这段逻辑不复杂但能省掉大量重复存储。3.3 检索时的相关性排序与重排检索不是简单取Top-K就完事。我一开始只按向量相似度排序结果发现有些高相似度的记忆其实已经过时了反而误导了推理。后来我改成两阶段先召回再重排。召回阶段用向量检索取Top-20同时用关键词检索取Top-20合并去重得到一个候选集。重排阶段对候选集重新打分打分公式大致是final_score 0.5 * 相似度 0.2 * 重要性 0.2 * 新鲜度 0.1 * 热度权重可以根据场景调。比如做知识问答相似度权重可以高一些做个性化推荐重要性权重可以高一些。新鲜度用时间衰减函数算热度用access_count归一化。重排之后取Top-5注入上下文这样既保证了相关性又兼顾了时效和质量。3.4 记忆注入上下文的方式与长度控制检索出来的记忆怎么塞进上下文也有讲究。我试过两种方式一种是直接拼接把记忆内容原样加到系统提示里。这种方式简单但记忆多了会占用大量token而且格式混乱。另一种是结构化注入把记忆整理成固定格式比如“已知用户偏好...历史决策...相关背景...”。这种方式更清晰模型更容易理解。我现在用的是结构化注入并且严格控制注入长度。一般注入的记忆总长度不超过上下文窗口的15%留足空间给当前对话和推理。如果记忆太多就只注入重排后的Top-3其余的留在库里等下次用。提示注入记忆时最好带上时间标记比如“三天前用户提到...”这样模型能判断信息的时效性避免把过时信息当当前事实用。4. 实操过程与核心环节实现4.1 环境准备与依赖选型这套记忆系统我用Python实现核心依赖就几个向量化模型、向量数据库客户端、一个轻量KV存储。向量化模型可以用现成的文本嵌入接口也可以本地部署小模型。向量数据库我选的是支持持久化和元数据过滤的方案KV存储直接用SQLite就够没必要上重型数据库。环境准备步骤安装Python 3.10以上版本确保依赖兼容。安装向量数据库客户端和嵌入模型依赖。初始化SQLite数据库文件建两张表一张存记忆条目一张存会话状态。配置嵌入模型的维度和相似度度量方式我一般用余弦相似度。这里有个细节嵌入模型的维度要和向量库的索引维度一致否则写入会报错。我踩过一次坑换了嵌入模型但忘了改向量库配置结果写入全失败排查了半天。4.2 记忆写入模块的实现写入模块的核心逻辑是接收一条候选记忆判断是否值得写值得写就生成嵌入、算重要性、存库。def write_memory(content, source, tagsNone): if not should_write(content, get_recent_memories()): return emb embed(content) importance calc_importance(content, source) mem { content: content, embedding: emb, timestamp: now(), importance: importance, source: source, access_count: 0, tags: tags or [] } vector_db.insert(mem) kv_db.set(fmem:{mem[id]}, mem)重要性评分我用了几个启发式规则包含“喜欢”“偏好”“不要”“必须”等词的加分来自用户显式表达的加分包含具体实体人名、时间、数字的加分。这套规则不完美但比不评要好得多。4.3 记忆检索模块的实现检索模块负责根据当前查询召回相关记忆。我实现的是混合检索加重的方案。def retrieve_memories(query, top_k5): query_emb embed(query) vec_results vector_db.search(query_emb, top_k20) kw_results keyword_search(query, top_k20) candidates merge_dedup(vec_results, kw_results) scored [] for mem in candidates: sim cosine_similarity(query_emb, mem[embedding]) freshness decay(mem[timestamp]) heat normalize(mem[access_count]) score 0.5*sim 0.2*mem[importance] 0.2*freshness 0.1*heat scored.append((score, mem)) scored.sort(reverseTrue) return [m for _, m in scored[:top_k]]这里的关键是decay函数。我用的是指数衰减半衰期设7天。也就是说一条记忆7天没被召回新鲜度降到0.514天降到0.25。这样自然淘汰旧记忆不用手动清理。4.4 记忆注入与上下文组装检索到记忆后要组装进当前推理的上下文。我的组装顺序是系统提示、记忆区块、最近对话、当前查询。记忆区块的格式我固定成[相关记忆] - (3天前, 重要性高) 用户偏好简洁回答 - (1天前, 重要性中) 方案A因成本被排除 - (刚刚, 重要性高) 当前任务目标是生成报告这种格式模型很容易解析。注入时我会限制总条数和总字数一般不超过5条、500字。如果记忆太多就按重排分数截断。4.5 遗忘与归档的定时任务遗忘机制我做成定时任务每天跑一次。逻辑是遍历所有记忆算新鲜度低于0.1的归档到冷存储低于0.05的直接删除。归档的记忆不参与常规检索但保留在冷库里万一需要还能查。def forget_task(): for mem in vector_db.get_all(): freshness decay(mem[timestamp]) if freshness 0.05: vector_db.delete(mem[id]) elif freshness 0.1: archive(mem)这个任务我一般放在低峰期跑避免影响在线检索性能。5. 常见问题与排查技巧实录5.1 记忆检索不准的排查思路检索不准是最常见的问题表现是召回的记忆和当前查询不相关。排查我一般按这个顺序检查嵌入模型。嵌入质量差相似度计算就不准。可以拿几条明显相关的文本测一下相似度如果分数很低说明模型不适合当前领域。检查检索参数。Top-K设太小会漏设太大引入噪音。我一般从20开始调。检查重排权重。如果新鲜度权重太高会召回很多新但不相关的记忆相似度权重太高又会召回旧但相关的。需要按场景调。检查记忆质量。如果写入的记忆本身就是废话检索再准也没用。回头看看写入策略是不是太宽松。5.2 记忆冲突与矛盾的解决同一个问题记忆库里存了互相矛盾的两条比如用户先说喜欢A后来说喜欢B。这种情况检索出来会让模型困惑。我的解决办法是引入记忆版本概念。每条记忆有个version字段新记忆写入时如果和旧记忆冲突就把旧记忆标记为superseded检索时默认只召回最新版本。判断冲突用相似度加实体匹配相似度高但结论相反的就判定为冲突。注意冲突判断不要全自动有些矛盾其实是不同场景下的不同偏好不是真的冲突。我一般会把疑似冲突的记忆标出来人工确认后再处理。5.3 记忆膨胀导致性能下降记忆库越来越大检索越来越慢这是必然的。我遇到过检索延迟从50毫秒涨到500毫秒的情况。解决办法有三个一是定期归档把低价值记忆移到冷存储二是加索引向量库一般支持索引优化记得开三是分片按时间或标签把记忆分到不同集合检索时只查相关分片。我一般组合用归档加索引能解决大部分性能问题。5.4 常见问题速查表问题现象可能原因排查方向解决建议召回不相关记忆嵌入模型不匹配测相似度分数换模型或微调召回重复记忆写入去重失效检查相似度阈值调低阈值或加去重检索延迟高记忆库过大看库大小和索引归档加索引记忆矛盾版本管理缺失查冲突记忆引入版本标记重要记忆丢失衰减太快看新鲜度参数调半衰期注入超长条数没限制看注入逻辑加条数和字数上限5.5 几个我踩过的坑和实操心得第一个坑是嵌入模型换版本。有次我升级了嵌入模型维度从768变成1024结果旧记忆全部检索失败。教训是换模型必须重建所有记忆的嵌入或者做维度兼容处理。第二个坑是时间戳时区混乱。服务器时区和数据库时区不一致导致新鲜度计算错乱新记忆被当成旧的淘汰了。后来我统一用UTC时间戳问题解决。第三个坑是过度依赖自动写入。一开始我让系统自动判断什么该记结果记了一堆无关紧要的寒暄。后来改成自动加人工确认关键记忆手动标记质量才上来。心得方面我觉得最重要的一条是记忆系统要可观测。你得能看到记忆库里有什么、检索时召回了什么、注入后模型用了什么。我专门做了个调试面板实时显示这些信息排查问题效率高很多。另外记忆不是越多越好。我见过有人恨不得把每句话都存下来结果检索时全是噪音。精简的记忆库比庞大的记忆库好用得多宁可少记不可乱记。最后测试要覆盖边界情况。比如空记忆库、超长记忆、冲突记忆、过期记忆这些边界不测上线后必出问题。我一般会写一套边界测试用例每次改检索逻辑都跑一遍。这套记忆系统我在几个模拟项目里跑下来稳定性还不错。核心就是分层存储、混合检索、加权重排、定期遗忘这四件事。每件事单独看都不复杂组合起来就能让智能体真正“记住”东西。如果你正在做类似的东西建议先从最简单的KV存储加向量检索起步跑通了再逐步加复杂度别一上来就搞大而全的架构。
