1. 为什么“存下来”不等于“记得住”很多人第一次给 Agent 加记忆思路特别朴素搞个向量库把对话历史一股脑塞进去用的时候按相似度捞几条出来拼进提示词。跑个 demo 看着挺像那么回事一旦对话轮次拉长、话题来回切换Agent 就开始胡言乱语——要么把三天前随口一提的偏好当成铁律要么把刚刚纠正过的信息又原样犯一遍。问题出在哪存储和记忆是两码事。存储是“我把东西放进去了”记忆是“我在需要的时候能准确想起来并且知道它现在还算不算数”。这两者之间隔着检索、时效、冲突消解、抽象归纳好几道坎。我见过太多项目把“接了向量数据库”当成“实现了长期记忆”结果上线后用户抱怨“它怎么老是记岔”。这篇内容就是围绕这个坑展开的。我会把 Agent 长期记忆拆成几个能落地的模块记忆怎么分类、写入时怎么决策、检索时怎么排序、冲突怎么处理、遗忘怎么做。适合已经跑通基础对话、想让 Agent 真正“记住事”的开发者也适合刚接触这块、想少走弯路的朋友。核心关键词就一个——长期记忆但我会把它拆得足够细细到你能直接照着改自己的代码。先说一个我自己的判断长期记忆的难点从来不在“存”而在“取”和“信”。取错了等于没记取对了但过期了比没记还糟。后面所有设计都是围绕这两点转的。2. 长期记忆的整体架构该怎么搭2.1 先分清三类记忆别混在一个池子里我踩过的第一个大坑就是把所有信息塞进同一个集合。用户偏好、事实知识、任务进度、临时上下文全扔一块儿检索时互相污染。后来我强制分成三类效果立刻不一样事实型记忆用户是谁、做什么的、有什么长期不变的属性。比如“用户偏好用 Python 而不是 Java”。这类记忆写入要谨慎一旦写入就长期有效除非用户明确更正。情景型记忆某次对话里发生了什么。“上周三用户让我帮他调过一个报错”。这类记忆有时效性会随任务结束而降低权重。语义型记忆从多次交互里抽象出来的规律。“这个用户每次问性能问题其实都关心内存占用”。这类记忆不是直接存的是归纳出来的价值最高但也最难做。为什么要分因为它们的生命周期和检索策略完全不同。事实型记忆检索时应该高权重、低衰减情景型记忆要带时间戳、会过期语义型记忆需要定期用 LLM 做归纳更新。混在一起你就没法给它们配不同的衰减曲线。提示分类不是目的是为了让每类记忆有独立的写入阈值、检索权重和淘汰策略。分类维度可以按你的业务调整但一定要分。2.2 写入决策不是每句话都值得记新手最容易犯的错是“全量写入”。每轮对话结束就把整段历史存进去结果向量库里全是噪音。检索时相似度最高的往往是那些废话真正有用的信息被淹没。我的做法是加一个写入决策层在存之前先问三个问题这条信息是新的吗跟已有记忆重复的直接跳过。这条信息是长期有效的吗临时性的“好的”“收到”不存。这条信息未来可能被用到吗纯寒暄、纯确认的不存。具体实现上我会用一个轻量 LLM 调用做判断提示词大概是这样WRITE_DECISION_PROMPT 判断以下对话片段是否值得写入长期记忆。 值得写入的标准 - 包含用户的长期偏好、身份信息、重要事实 - 包含任务的关键结论或决策 - 包含用户明确要求记住的内容 不值得写入 - 寒暄、确认、临时性对话 - 已经存在于记忆中的重复信息 对话片段{segment} 已有相关记忆{existing_memories} 输出 JSON{{should_write: true/false, reason: ..., memory_type: fact/episodic/semantic}} 这个判断本身有成本但比事后清理便宜得多。我实测下来加了这一层之后向量库的条目数能降 60% 以上检索准确率反而上升。2.3 检索排序相似度只是起点很多人检索就靠一个余弦相似度取 Top-K 完事。这在记忆场景下远远不够。我现在的排序公式大概是这样最终得分 相似度 × 时效权重 × 重要性权重 × 类型权重相似度向量检索的原始分数占大头但别给满分。时效权重越新的记忆权重越高但事实型记忆衰减要慢。我一般用指数衰减半衰期设 7 天左右事实型设 90 天。重要性权重写入时让 LLM 打个 1-5 分重要的记忆即使旧了也不容易被挤掉。类型权重事实型 语义型 情景型因为事实型最稳定。这套加权下来检索结果会比纯相似度靠谱很多。代价是要多存几个字段但值得。2.4 冲突消解新记忆和旧记忆打架怎么办这是长期记忆里最容易被忽略、也最容易翻车的地方。用户上个月说“我住在北京”这个月说“我搬到上海了”。两条记忆都在库里检索时可能同时被捞出来Agent 就懵了。我的处理方式是写入时做冲突检测。新记忆进来时先检索最相似的几条已有记忆如果相似度超过阈值我一般设 0.85就交给 LLM 判断是“更新”“补充”还是“矛盾”更新新信息覆盖旧信息旧记忆标记为失效不删除但降权。补充两条都保留合并成更完整的记忆。矛盾保留新的旧的标记为“待确认”下次相关对话时主动向用户求证。注意不要直接删除旧记忆。保留失效标记一是方便回溯二是万一新信息是误判还能恢复。我吃过直接删除的亏用户改口后想找回原来的信息没了。3. 核心模块的实操细节3.1 记忆的存储结构设计光靠向量库不够我一般用“向量库 结构化存储”双写。向量库存 embedding 用于检索结构化存储比如 SQLite 或 Postgres存元数据用于过滤和排序。一条记忆的完整结构大概长这样字段类型说明idstring唯一标识contenttext记忆原文embeddingvector向量表示memory_typeenumfact/episodic/semanticimportanceint1-5写入时打分created_attimestamp创建时间last_accessedtimestamp上次被检索时间access_countint被检索次数statusenumactive/superseded/pendingsuperseded_bystring被哪条记忆取代source_turnstring来源对话轮次为什么要存last_accessed和access_count因为这两个字段能帮你做热度加权。经常被用到的记忆说明它重要检索时应该加分从来没被用到的记忆可以考虑淘汰。这是从缓存系统里借来的思路用在记忆管理上意外地好用。3.2 向量化模型的选择与取舍embedding 模型的选择直接影响检索质量。我的经验是纯中文场景选中文语料训练充分的模型别直接用英文为主的通用模型中文语义相似度会差一截。中英混合选多语言模型但要注意多语言模型在单语言上的表现通常不如专用模型。长文本记忆如果单条记忆很长要么用支持长上下文的 embedding 模型要么先做摘要再向量化。这里有个细节记忆的向量化粒度。我试过整段对话向量化也试过按句向量化最后发现按语义单元向量化效果最好。一个语义单元可能是一句话也可能是几句话判断标准是“能不能独立表达一个完整意思”。太细了检索碎片化太粗了检索不精准。实操上我会在写入前做一次切分用 LLM 判断语义边界SEGMENT_PROMPT 将以下对话切分成独立的语义单元每个单元能独立表达一个完整信息。 不要切得太碎也不要合并不同主题的内容。 输出 JSON 数组每个元素是一个语义单元。 对话{conversation} 3.3 检索时的上下文组装检索出记忆后怎么拼进提示词也有讲究。我见过直接把记忆列表贴进去的效果一般。我的做法是按类型分组、按重要性排序、加时间标注【用户长期偏好】 - 偏好 Python2024-01 确认 - 关注内存占用多次提及 【相关历史】 - 上周讨论过类似性能问题结论是缓存命中率是关键 【当前任务上下文】 - 正在优化一个数据处理脚本这样组织LLM 能清楚区分哪些是稳定事实、哪些是历史参考、哪些是当前上下文。比一堆无序的记忆条目强太多。提示记忆注入的位置也影响效果。我一般放在系统提示词之后、用户输入之前让模型先“回忆”再“回答”。3.4 遗忘机制主动淘汰比无限堆积更聪明记忆不是越多越好。库里堆到几万条检索质量必然下降。我设计了一套主动遗忘机制时间衰减超过一定时间没被访问的情景型记忆权重降到阈值以下就归档。容量上限每类记忆设上限超了就淘汰重要性最低、最久未访问的。归纳压缩多条相似的情景型记忆定期用 LLM 归纳成一条语义型记忆原始条目归档。归纳压缩这块特别值得做。比如用户十次问性能问题与其存十条情景记忆不如归纳成一条“该用户高度关注性能尤其是内存和响应时间”。存储省了检索还更准。CONSOLIDATE_PROMPT 以下是一组相关的历史记忆请归纳成一条简洁的语义型记忆。 保留关键信息去掉重复和细节。 如果这些记忆不足以归纳出规律返回 null。 记忆列表{memories} 输出 JSON{{consolidated: ..., confidence: 0.0-1.0}} 4. 常见问题与排查实录4.1 记忆检索不准的排查思路检索不准是最常见的问题原因可能有好几层。我一般按这个顺序排查现象可能原因排查方法检索结果完全不相关embedding 模型不匹配手动测几条 query看相似度分布相关但排序靠后权重配置不合理打印各维度得分看是哪项拖后腿该记的没检索到写入时被过滤了查写入日志看是否 should_writefalse检索到过期信息冲突消解没生效检查 status 字段和 superseded_by结果重复冗余写入没去重查相似度阈值是否太低我遇到最多的是第一种和第三种。第一种通常是 embedding 模型选错了换成领域匹配的模型立刻改善。第三种往往是写入决策太严格把有用信息误杀了这时候要放宽阈值或者调整提示词。4.2 记忆冲突的典型场景冲突消解做不好Agent 会显得“精神分裂”。我整理了几个高频冲突场景事实更新用户搬家、换工作、改偏好。这类必须让新记忆覆盖旧的。偏好矛盾用户说“我喜欢简洁的回答”后来说“能不能详细点”。这可能是场景不同不一定是矛盾要结合上下文判断。任务状态变化任务从“进行中”变成“已完成”。旧状态要标记失效。误记纠正Agent 记错了用户纠正。这类要优先处理且要记录纠正来源。我的处理原则是事实类冲突以新为准偏好类冲突看场景任务类冲突看时间戳。拿不准的时候宁可保留两条并标注也不要武断覆盖。4.3 性能与成本的平衡长期记忆会带来额外的 LLM 调用写入判断、冲突检测、归纳压缩和向量检索开销。我实测下来一个中等规模的 Agent每轮对话额外增加 200-500ms 延迟和少量 token 成本。优化手段有几个写入判断用轻量模型不需要用最强的模型做“要不要记”这种判断小模型足够。批量处理归纳压缩、冲突检测可以攒一批离线做不占实时链路。缓存检索结果相同 query 短时间内重复检索直接走缓存。分级存储热记忆放内存冷记忆放磁盘按访问频率自动迁移。注意别为了省成本把写入判断砍掉。我试过直接全量写入再定期清理结果清理逻辑比写入判断复杂得多还容易误删。写入时多花的那点成本远比事后补救便宜。4.4 几个我踩过的坑坑一把记忆当数据库用。有人把 Agent 记忆当成精确查询的存储指望“我存了什么就能原样取出来”。但向量检索是模糊匹配不是精确查询。需要精确取的信息老老实实用结构化存储加条件过滤。坑二忽略记忆的时效性。我早期版本没做时间衰减结果半年前的临时信息还在影响当前对话。加了衰减曲线后Agent 的“当下感”明显变强。坑三归纳压缩做太早。归纳需要足够的样本样本太少归纳出来的规律是噪音。我一般等某类情景记忆攒到 5 条以上才触发归纳。坑四没有记忆的可解释性。用户问“你为什么这么说”Agent 答不上来。后来我在每条记忆里保留来源检索时把来源一起注入Agent 就能说“根据你上周提到的……”。这个改动让用户信任度提升很多。5. 记忆系统的评估与迭代5.1 怎么判断记忆系统好不好没有评估就没法迭代。我一般看几个指标检索命中率构造一批 query看正确记忆是否在 Top-K 里。冲突处理准确率构造冲突场景看系统判断是否正确。记忆冗余度库里相似记忆的比例越低越好。用户纠正率用户纠正 Agent 记忆错误的频率越低越好。这些指标不用很精确但要有不然你改了半天不知道是变好还是变坏。我习惯每次调整检索权重或写入阈值后跑一遍固定的测试集对比指标变化。5.2 迭代节奏的建议记忆系统不是一次做完的我建议分阶段第一阶段先做基础写入和检索能存能取就行别追求完美。第二阶段加写入决策和冲突消解解决“记岔”问题。第三阶段加归纳压缩和遗忘机制解决“越用越臃肿”问题。第四阶段做评估和调优把指标跑起来。每个阶段之间留出观察期别一口气全上。我见过一次性把四个阶段全做完的项目出问题时根本不知道是哪层的锅。5.3 一个容易被忽略的点记忆的隐私边界长期记忆会存大量用户信息哪些能记、哪些不能记、记了怎么保护这些要在设计初期就想清楚。我的做法是敏感信息不写入长期记忆写入决策层加一条硬规则命中敏感类别直接拒绝。这不是技术问题是产品底线问题别等出事再补。6. 我个人的几点实操体会做了几个带长期记忆的 Agent 之后我最大的体会是记忆系统的价值不在于“记得多”而在于“记得准、用得对”。一个只记 50 条但条条精准的系统比记 5000 条但检索混乱的系统好用得多。第二个体会是别迷信向量检索。向量检索适合模糊语义匹配但记忆管理里很多判断需要精确逻辑——时间比较、状态判断、冲突检测这些用结构化查询更靠谱。混合使用各取所长。第三个体会是记忆要能被用户感知和干预。我后来加了一个功能让用户能看到 Agent 记住了什么并且能手动删除或修正。这个功能上线后用户对记忆错误的容忍度明显提高因为他们知道“我能控制”。最后分享一个小技巧给记忆加“置信度”字段。写入时让 LLM 评估这条记忆的可靠程度检索时低置信度的记忆要么不注入要么标注“不确定”。这样 Agent 在引用记忆时能说“我记得你好像提过……”而不是斩钉截铁地说错。这个细节对用户体验的提升比很多复杂优化都管用。记忆这块后续还能往深做比如跨会话的记忆迁移、多 Agent 之间的记忆共享、记忆的版本管理。但那是另一个话题了先把单 Agent 的长期记忆做扎实比什么都强。