智能体记忆系统三层架构：从上下文崩溃到长期记忆的工程实践

1. 先说说我为什么把记忆系统做崩溃了

做Agent相关项目的人应该都有这种感受：单轮对话效果还行，一旦进入多轮、跨天、跨项目的长周期任务，Agent就开始“失忆”——要么忘了用户半小时前提过的要求，要么把昨天的事记成今天的，严重的时候干脆逻辑错乱。我最早遇到这个问题时，第一反应是“上下文窗口不够大”，于是拼命往提示词里塞历史记录，结果更糟：Token爆炸、响应变慢、模型注意力被稀释，核心指令反而被淹没。真正让我意识到“记忆”是个独立工程问题的，是一次线上事故，用户在一个客服问答Agent里反复问同一个售后政策，Agent每次都给不同答案，最后用户直接投诉。

事后复盘发现根子不在模型，而在记忆系统：所有对话历史不分轻重缓急全部塞进一个“长期记忆”集合，没有层级、没有过期、没有冲突处理。那之后我开始系统性地重构，最终沉淀出一套三层记忆架构，跑了大半年再没出过同类问题。这篇文章把这套架构的来龙去脉、每一层的落地方案、以及我在崩溃排障过程中验证过的细节完整写出来，希望能帮你绕开我踩过的坑。

这套方案适合正在做Agent、Copilot、智能客服、个人助理类项目的开发者，也适合想从“单轮Demo”往“多轮稳定服务”跨一步的团队。内容不依赖特定框架，核心思路可以复用到绝大多数项目里。

2. 崩溃根因：我踩过的四个典型记忆错误

2.1 把所有历史当作“长期记忆”一股脑存起来

这是我最开始犯的错误。当时设计很简单：把每轮对话拼接成一个超长文本，用向量库存起来，检索时按相似度取TopK丢给模型。听起来合理，实际跑起来全是问题。举个例子，用户第一天问了一堆账号注册流程，第二天问退款政策，系统检索时把第一天的“注册流程”也当作高相似内容召回，结果模型开始推荐用户去注册新账号，完全跑偏。

这里的核心误区在于：会话级上下文和长期记忆不是一回事。会话级上下文是短时窗口内的连续性信息，过了这个窗口价值急剧衰减；而长期记忆应该是从大量历史中提炼出的稳定事实、用户偏好、业务规则。把两者混在一个存储里，等于让模型自己在噪声里找信号，代价是极高的。

2.2 写入记忆没有“闸门”，垃圾进了永久留存

另一个更隐蔽的问题是写入环节完全没有质量控制。早期实现里我对每一轮对话都做向量化、入库，导致大量闲聊内容、错误信息、甚至模型自身的幻觉内容全部沉淀下来。等记忆库跑了几万条，检索出来的结果里充斥着“用户昨天说今天天气不错”这种毫无业务价值的碎片。

更麻烦的是，如果某次模型回答本身是错的，这条错误内容也会作为一个“事实”被写进记忆库。后续检索一旦命中它，模型就会拿着错误信息继续推导，形成滚雪球式的错误放大。我在一次排障中见过连续七轮对话都在围绕一个并不存在的订单号展开，就是因为第二天检索时反复命中前一天的幻觉内容。

2.3 检索条件过于粗糙，向量相似度扛不住一切

我也试过更“高级”的做法：全部依赖向量检索，靠Embedding相似度直接取TopK。单看离线评测指标还不错，但线上多用户并发时就露馅了。向量检索本质上是语义近似搜索，它不理解业务约束——比如“这个记忆属于哪个用户”“这条记忆在什么时间范围内有效”“这条记忆是用户主动声明还是模型推断的”。

有一次事故就是因为没有用户维度隔离：A用户问过的东西，在某个语义相近的问题下被系统当作B用户的历史记忆回复了出去。这不是向量模型的锅，是检索链路设计不完整，过滤条件缺位。

2.4 没有遗忘机制，陈旧信息持续产生误导

记忆如果只增不减，迟早出问题。用户半年前设置过一个偏好“所有消息优先邮件通知”，后来改成“微信通知”，但旧偏好仍然在记忆库中。默认的相似度检索看的是语义，不看时间，于是模型有一半概率建议用邮件。

人类记忆本来就有遗忘和修正机制，长期记忆系统如果只有叠加没有修正，就会越跑越失真。这个教训是让我下定决心做分层架构的最后一根稻草。

3. 三层记忆架构：工作记忆到语义记忆的完整设计

3.1 架构总览：每一层解决什么

重构之后我把记忆系统拆成三层，每一层的职责、生命周期、存储方式都明确区分：

• 工作记忆层：负责当前会话的上下文管理，回答用户问题时保持连续性和一致性，生命周期是当前任务或会话。
• 情景记忆层：负责存储具体发生过的事件、对话、操作记录，以“情景”为单位保存，生命周期是数天到数周，需要按时间和语义可回溯。
• 语义记忆层：负责存储从情景中提炼出的稳定事实、用户偏好、领域规则，生命周期是长期，需要做去重、冲突消解和版本管理。

这三层的顺序对应了数据的“加工深度”：原始数据先进工作记忆，经过筛选和结构化沉淀到情景记忆，再由定期提炼形成语义记忆。每一层都有独立的读写入口和生命周期策略，互不越界。

3.2 数据流向与生命周期管理

数据在层与层之间的移动不是自动的，需要显式触发。工作记忆在会话结束时通过一个“摘要与提炼”步骤，把值得保留的内容写入情景记忆；情景记忆通过定时离线任务做重大主题提取、重复片段合并，形成候选语义记忆，再经过冲突检测进入语义记忆库。

我特别想强调生命周期策略的设计原则：每一层的生存周期必须匹配它的用途。如果情景记忆也存一年，数据规模会拖慢检索，同时引入大量过时干扰；如果语义记忆保存太短，则无法形成稳定的用户画像。三层各管各的节奏，整体才可控。

3.3 层间接口的边界：什么内容允许跨层

跨层不是所有内容都搬，而是“摘要化”地搬。比如用户在会话里仔细描述了一个系统的部署步骤，工作记忆保存的是这轮对话原文，情景记忆保存的是“用户已开始部署xx系统”这件事实，语义记忆最终抽象为“用户负责xx系统运维，倾向自部署方案”。如果直接把原文丢进情景记忆，维度和噪声又会失控。

从一开始就要写清楚层间接口的数据格式。我第一版架构没做这一步，导致情景记忆和语义记忆的数据互相掺和，切分逻辑反复返工。

4. 每一层的实现细节：数据结构、选型与核心参数

4.1 工作记忆层：上下文预算分配与摘要兜底

工作记忆层最核心的不是存储，而是上下文预算管理。模型窗口是有限的，不能把所有历史对话都堆进去。我采用的方案是给上下文划分预算：核心指令区、当前用户目标区、最近对话轮次区、检索到的记忆区，各自有Token上限。

举个例子，假设模型窗口是8K Token，我会预留2K给系统指令，2.5K给当前对话上下文，1.5K给检索到的记忆，剩下的预算给模型输出。超出部分不是截断，而是触发一个“滚动摘要”——把最早的若干轮对话用一次LLM调用压缩成一段摘要，作为上下文的一部分参与后续生成。

这里有个实操细节：滚动摘要不能太频繁触发，否则LLM调用成本吃不消。我设置了触发阈值，当上下文超过预算的80%才做一次摘要，摘要本身也会计入预算。实测下来单会话平均摘要次数控制在两到三次，效果和成本平衡得比较好。

4.2 情景记忆层：以“事件块”为单位写入，向量库只是索引

情景记忆的存储我最终选了“元数据表+向量索引”的组合，而不是纯向量库。每条记录包含的元数据字段包括：用户ID、会话ID、事件类型、时间戳、来源模块、重要程度、可见范围。向量字段只负责语义召回，业务约束交给元数据过滤。

事件块的大小需要仔细拿捏。粒度太细（比如一轮对话一条）会导致检索结果碎片化，召回一堆半句话；粒度太粗（比如整个会话一条）会导致语义混叠，相似度计算失准。我最终按“一个完整任务或一个话题链条”为切分单位，配合会话内的分段器，把连续对话切分成多个事件块。

向量库的选型上，如果项目规模小，用轻量的开源方案足够；如果并发和规模都大，优先考虑托管式服务，省去运维负担。离线评测时可以重点看一下P99召回延迟和索引构建耗时，这两个指标决定了线上效果的上限。

4.3 语义记忆层：离线提炼与冲突消解

语义记忆是最能体现“智能”的一层，也是最容易被过度设计的一层。我的落地方式是：每晚跑一次离线任务，从当天新增的情景记忆中抽取候选语义事实，经过过滤得到三类内容——用户稳定偏好、业务关键事实、长期目标。

冲突消解是这层的核心难点。同一个用户星期一说“习惯用邮件接收报告”，星期五说“以后用企业微信就行”，如果两条都进语义库，模型就会无所适从。我的处理方式是为每条语义记忆增加“置信度”和“最后确认时间”，当新事实与旧事实矛盾时，不直接删除旧记录，而是标记为“待确认”，并在下一次会话中让模型优先采用新记录，同时温和地向用户确认是否有变更。

为了保证离线任务的输出质量，我对抽取prompt做了严格的格式约束，要求返回JSON结构，包含事实内容、类别、置信度、来源事件ID。这样下游的冲突检测和去重逻辑就不需要依赖自然语言解析。

4.4 Embedding模型选择与参数调优

三层架构里情景记忆和语义记忆都会用到向量检索，Embedding模型的选择直接影响召回效果。我的经验是：优先选领域匹配度高的模型，而不是一味追求榜单分数。通用榜单分数高不代表在垂直场景里的语义区分度好，尤其是一些业务术语频繁出现的场景，需要自己建一个几百条的本地评测集，人工标注相关和不相关，跑一轮对比再定。

关于向量维度，不是越高越好。维度越高存储成本越大，召回延迟也会上升。如果业务语义区分度已经够用，尝试降到256甚至更低的维度，性价比会高很多。我在一个客服场景里做过对比，从768维降到384维，效果几乎无损，存储却砍了一半。

另一个容易忽略的参数是距离度量。默认常用余弦距离，但如果你在某些模型上发现归一化之后距离分布过于集中，可以试试用点积（dot product），有时候反而更稳定。这个要靠你自己的数据集实测，没有统一答案。

5. 检索策略：为什么命中率直接决定Agent的“智商”

5.1 先过滤，后向量召回，再精排

检索链路是我重构后改动最大的一环。第一版是“裸”向量检索，什么都靠相似度。第二版改成了三段式：先按元数据做硬过滤（用户、时间窗、事件类型、可见范围），再做向量召回取TopK，最后用一个轻量级重排模型或规则对TopK重新排序，挑出最合适的内容进入上下文。

硬过滤的价值在于它能够消灭一类系统性问题。比如用户ID过滤可以直接根除跨用户干扰；时间过滤可以保证“上周的偏好”不会在“今天的会话”里被高权重召回。这个逻辑用代码实现比用模型学更可靠。

重排阶段的规则我列了几个加分项：

• 与当前问题的时间间隔越短，得分越高
• 提到当前任务关键词的记忆，得分越高
• 来自用户主动描述的记忆，比模型推断的得分更高
• 来源为较新会话的记忆，设置轻微提权

5.2 混合检索：向量+关键词互为兜底

纯向量召回有一个典型问题：对专有名词、订单号、报错码这一类精确信息不敏感。用户上一次说“订单号是ABC123456”，下一次问“ABC123456这个订单怎么样了”，向量召回可能命中不了。所以我加了关键词检索（BM25）作为并列召回通道，最后用RRF（Reciprocal Rank Fusion）做结果融合。

RRF的实现很简单：对每个召回通道的结果按排序位置打分，然后合并排序。核心参数是常数k，我一般设为60左右。这个融合方案最大的好处是不需要调权重，通道间得分不可比的问题直接绕开了。实测里混合检索的召回率比纯向量高出十几个百分点，尤其在包含编号、代码片段、版本号的场景里优势非常明显。

5.3 检索结果的质量控制：宁可少给，不要乱给

记忆进入上下文之后，模型会把它们当作事实依据来用。如果检索结果本身不相关，模型就会被带偏。所以我在检索环节设置了“最低相关性阈值”，低于阈值的记忆不进入上下文。这个阈值需要通过测试集反复校准，太严会漏掉有用信息，太松又会引入噪声。

我另外做了一个被同事称为“记忆去毒”的步骤：凡是标记为“模型推断”的记忆，在检索结果里的展示权重要低于“用户亲述”；凡是带“待确认”标记的内容，除非当前问题与之强相关，否则不展示。这样即使离线提炼阶段有一些误判，也不会直接污染在线回答。

6. 一次生产事故的完整排查链路：从症状到根因

6.1 症状描述：客户投诉历史上演的第一次事故

那次事故的背景是一个已上线的客服问答Agent，某天突然集中出现三类用户投诉：第一类，用户重复提问时，Agent给出的答复前后不一致；第二类，用户明明已经提供了身份信息，Agent在下一轮仍然让用户再报一遍；第三类，A用户的问题，Agent拿B用户的信息进行回答，非常致命。

第一时间我看了看模型日志，输入端上下文确实存在异常：出现了大量与本用户无关的片段。顺着这个线索往下查，最终定位到记忆系统。整个过程大概经历了四步，我把每步的关键观察点列出来。

6.2 排查过程：日志、检索采样、写入链路打点

第一步是查日志关键词。我把输入到模型的Prompt完整拉出来，重点看“记忆片段”的来源ID，很快确认了异常内容不是来自当前会话，而是检索层返回的长期记忆。

第二步是复现检索过程。我挑了一个出问题的用户，把他当前问题和历史数据放到检索接口里跑了一遍，观察召回结果的组成。很快就发现问题：检索环节没有做用户ID过滤，用户ID这个字段在索引里是空的。也就是说，记忆写入时没有把用户ID关联上去，历史数据全是“无主”的，自然无法过滤。

第三步是查写入链路。我在写入接口临时加了打点，查看入库时事件块的元数据填充情况，发现约三成事件块缺少用户ID和会话ID。原因是同一个事件写入函数被多个调用方复用，部分调用方没有传入上下文的用户信息。

第四步是评估影响面。通过统计缺失元数据的事件块比例，以及对所有线上用户的检索命中情况做抽样，确认这是一个系统性Bug而不是偶发问题，修复优先级拉到最高。

6.3 修复动作与验证

修复分两批。第一批是紧急止血：写一个离线脚本，按会话日志反填缺失的用户ID和会话ID，恢复数据关联关系；同时修改在线检索逻辑，强制要求必须带用户ID过滤条件，否则直接返回空结果，宁可不给记忆也不给错记忆。

第二批是规范补丁：修改所有事件写入入口统一传入用户上下文；增加写入前置校验，元数据不完整的事件块直接拒绝入库；接入监控大盘，按小时监控“无主记忆”的数量。验证阶段我重点观察三个指标：记忆命中率、用户重复提问率、跨用户误召回次数。两周后，这三个指标恢复到了事故前水平，后两个指标甚至因为强制过滤而更低了。

7. 重构后的收益：一组可以量化的变化

三层架构跑通之后，我对自己项目的数据做了一个对比统计，时间跨度为重构前两个月和重构后四个月。这里列出的数字都是我们内部的实际观测值，供你参考，不构成标准答案：

这里面我最看重的是“跨用户记忆误用”清零。记忆系统最大的风险不只是效果差，而是信息安全边界被击穿。分层架构本身不能完全杜绝这类问题，强制检索过滤和写入校验才是真正的防线。

Token消耗下降的直观原因是：没有必要的历史记录被重复塞入上下文，预算被更合理地分配给有效信息。如果你的Agent目前存在Token费用高企的问题，多半不是模型太贵，而是记忆检索给模型喂了太多没用的东西。

8. 落地建议与我的个人体会

8.1 从哪一层开始改造

如果你当前项目也只有一个“假长期记忆”的大口袋，不要试图一次到位。我会建议分三步走：

第一步，先做工作记忆层的预算管理。把上下文拆分定价，超出部分滚动摘要，这个改动不大，收益却立竿见影，Token费能降下来，模型表现会更稳定。

第二步，引入情景记忆层的元数据过滤。至少把用户ID、时间戳、事件类型这三个字段补上，检索时先过滤再召回。大多数严重的记忆事故都是缺这三个字段导致的，补上就能规避。

第三步，再考虑沉淀语义记忆。语义记忆依赖离线提炼和冲突消解，逻辑更重，建议在情景记忆稳定运行两三周之后再引入，用实打实的数据来验证提炼效果。

8.2 我自己还在继续优化的方向

这套架构稳定运行之后，我正在做两件事：第一，给语义记忆层的“待确认”机制加一个自动确认触发——当用户对某个问题连续给出同一答案两次以上，就自动把新事实更新为生效版本；第二，研究跨用户无关的信息能否安全复用，比如某个行业通用的政策解读类记忆，脱敏后做成公共知识层，进一步降低冷启动成本。

这个方向目前还在验证中，但我会建议做Agent的团队尽早思考“记忆”的工程属性，把它当作一个独立的可靠模块来对待，而不是模型能力的附属品。记忆系统一旦崩溃，不会像丢一个缓存那样无声无息，它会让整个Agent看起来像一个精神状态不稳定的人。先把稳定性问题解决掉，再谈聪明不聪明。