你有没有遇到过这种情况：给Agent写了一份特别详细的System Prompt，把用户画像、历史偏好、业务规则全都塞进去了，结果跑了几天之后，Agent的表现依然像第一次见面一样生硬。用户上周明明说过“我正在出差，周末才有空”，这周问它“我什么时候方便沟通”，它完全答不上来。不是模型不行，是Agent根本没记住用户说过什么。
我最早做Agent应用时也被这个问题反复折磨。当时想的很简单：既然模型有上下文窗口，把之前的对话历史一股脑拼到下一轮请求里不就行了吗？一开始确实有效，但跑着跑着问题就来了——上下文越来越长，响应越来越慢，Token费用像开了水龙头一样往外流，最关键的是，当历史消息超过一定量，模型反而被那些过时的旧信息干扰，聊得越久、忘得越快。
后来我意识到，Agent的记忆不是简单的“聊天记录堆叠”，它需要一套分层的结构来承接不同粒度的信息。这就是我想在这篇里展开聊的“Agent分层记忆”。我会直接把这套方案的架构思路、各层的实现路径、检索与更新的策略，以及我实际踩过的坑全部拆开来讲，适合正在做Agent开发、被上下文和记忆问题折磨的工程团队，也适合想了解Agent架构细节的初学者。
1. 先搞清楚：Agent到底需要什么样的“记忆”
1.1 记忆缺失引发的一连串真实问题
我把Agent记忆缺失带来的问题分成三类，你在实际开发中一定遇到过其中至少一个。
第一类是短期语境断裂。用户在对话里刚说过“我预算控制在五千以内”，Agent转身推荐了一万二的产品，还一本正经地介绍“这是目前性价比最高的方案”。不是模型弱智，是因为这一步的请求里根本没带上上一步的上下文。这类问题在你用纯API调用模型、又不做任何会话管理的时候几乎百分之百出现。
第二类是中长期偏好无法沉淀。用户连续一周每天都会说“我不吃辣”“我早上九点开会”，如果这些信息每次都只存在于那一刻的上下文窗口里，窗口一滚动就彻底消失。Agent永远在“重新认识”用户，永远学不会个性化。这造成的结果是，用户必须反复交代同样的背景，一段时间后他们会失去耐心，觉得这个Agent“很笨”。
第三类是知识碎片化导致的行为不一致。今天的对话里你告诉Agent“公司内部项目代号用字母T开头”，明天它又用数字编号生成了一份文档。它并不是违反了指令，而是那条规则从来没有被真正“记住”过。长期来看，一个没有记忆能力的Agent就没有所谓的人设、规则和一致性可言。
这三类问题的本质，是把“对话”当成了记忆的全部载体。但现实中人的记忆本来就分很多层：你记得今天早上吃了什么（短期），记得上周和朋友聚餐的大致内容（中期），也记得自己从小不吃香菜（长期）。Agent的记忆设计，也应该遵循同样的分层逻辑，而不是一个上下文窗口打天下。
1.2 为什么不能只靠上下文窗口硬扛
有人会说：既然上下文窗口越来越大，从4K到32K甚至到128K，全都塞进去不就行了？我实测下来的结论是：不行，而且随着窗口变大，问题边际在加剧。
首先是成本问题。你每次对话都要把所有历史塞给模型，Token消耗是平方级增长的。聊到第20轮，历史部分可能已经超过了新增内容的十倍。用户只是问了一个“在吗”，模型却要把过去一万个Token的历史读一遍。这笔账在商业化项目里根本算不过来。
其次是效果问题。模型对超长上下文的注意力天然存在“中间丢失”现象——醒目的开头和结尾信息保留得比较好，夹在中间的内容容易被忽略。你历史里那一条“用户说预算五千以内”恰好处在上下文中间偏后的位置，当整个上下文拉到几万字时，模型极有可能直接“看漏”。
然后是维护问题。历史里不只是对话，还有工具调用记录、临时变量、错误日志、中间计算结果。这些内容在当前任务完成后就失去了价值，但如果全部塞进上下文，它们会持续占空间、干扰注意力。你需要一个机制把这些内容按价值分类，能丢的丢、能压缩的压缩、能沉淀的沉淀。
所以我最终的结论是：Agent的记忆必须做分层处理，每一层负责不同时间尺度和抽象程度的信息，层与层之间有明确的读写策略。这才是解决“记不住”和“忘记该记的、记住该忘的”这两个问题的根本路径。
2. 分层记忆的整体架构：三个抽屉各管各的
2.1 工作记忆层：当前任务的“临时便签”
工作记忆（Working Memory）对应的是Agent当前这一轮或者当前任务正在使用的信息。它存在于请求上下文之中，生命周期极短，任务一结束就该清空。
很多人忽略了一个细节：工作记忆不只是对话历史，它还包括当前任务的中间状态。举个例子，Agent在做一个“撰写季度报告”的任务，它先检索了数据、生成了图表、写了一段开篇，这些中间产物在工作记忆里都存在。如果Agent因为超出调用限制中断了，重新启动时丢掉的不只是对话上下文，还有这些中间产物，任务就得从头再来。
工作记忆层的设计目标，是“够用且不越界”。它不该承担长期知识存储的责任，也不该无限膨胀。在实际工程里，这一层通常用上下文窗口管理、会话状态存储（比如Redis中的Session数据结构）来实现，核心动作是“裁剪”和“滚动”。
我在项目里给工作记忆层定的规矩是：单轮请求限制上下文在上下文窗口的一半以内，另一半留给模型输出和工具返回结果。之所以留出一半，是因为如果上下文已经塞满，模型就没有空间去老老实实生成结构化输出了。
2.2 情景记忆层：任务历史的“事件记录”
情景记忆（Episodic Memory）存储的是Agent与用户完整交互事件的摘要性记录。它不像工作记忆那么细碎，也不像长期记忆那样抽象成通用知识，它保留的是“发生过什么事”的相对完整的叙事。
这一层的典型例子是：用户在上周二问过“如何做数据迁移”，Agent当时推荐了三种方案，其中用户对方案A表达了兴趣。这些信息不一定要逐字保留，但“用户关注过数据迁移”“对方案A有兴趣”这些关键事件必须被记录。
情景记忆在工程上的常见载体是向量数据库。每条记忆被嵌入成向量，附带时间戳、事件类型、关联主体等元数据，检索时通过相似度查找召回相关段落。它的核心特点是：仍然保留上下文结构，但经过了摘要化压缩，不再逐字记录。
这一层解决的核心痛点是“跨会话的连续性”。没有情景记忆，Agent换个会话就像失忆；有了它，至少在用户说“我上次问过的那个数据迁移方案”时，Agent能准确回忆起是哪个方案。
2.3 语义记忆层：抽象出来的“长期常识”
语义记忆（Semantic Memory）存储的是从具体事件中抽取出的、可独立于事件存在的知识与偏好。它不再关心“什么时候、在哪一次对话里”，只关心“用户有哪些长期偏好”“项目有哪些固定规则”“组件的调用约定是什么”这类稳定信息。
举个例子，从“用户上周二问过数据迁移方案”这条情景记忆中，最终沉淀到语义记忆的内容可能是“用户所在团队倾向于先用小范围试点之后再全量迁移”。这条信息与具体时间无关，但它能指导Agent在未来所有涉及变更类建议时的决策。
语义记忆的工程实现通常是一张结构化的知识库：可以是KV存储、图数据库，甚至就是一张配置表。它的抽象程度越高，复用的价值越大，但同时也越难自动抽取，需要设计完善的沉淀机制。
我常给团队打的比方是：情景记忆像日记，写了日期、经过、感受；语义记忆像人生信条，是翻了很多页日记之后提炼出来的东西。Agent不能只写日记不提炼信条，否则永远活在具体琐事里，做不了高质量的抽象决策。
3. 各层记忆的落地方案与实现路径
3.1 工作记忆层的具体实现：上下文窗口的精细管理
工作记忆层的实现核心是管理好“当前上下文”。我常用的方案分三步走。
第一步是会话状态的外部化。不要让Agent的会话状态只存在于模型服务的上下文里，要把它迁移到外部存储。我在项目里用Redis存当前的会话状态，Key是会话ID，Value是一个结构体，里面包含当前任务的目标、已完成的步骤、最近几轮对话的精简记录。这样即使请求中断，Agent也能从Redis恢复会话状态。
第二步是上下文的裁剪策略。每次组装请求前，先对历史记录做一次过滤。我给每条历史记录打上标签：系统指令、用户消息、Agent回复、工具调用、工具结果。其中工具调用和工具结果只保留最后一轮的，因为大多工具结果在下一步之后就失去了价值。用户消息和Agent回复保留最近10轮，更早的进入压缩流程。
第三步是压缩流程。当历史消息超过阈值时，不是直接截断，而是调用摘要模型把超过10轮之前的内容合并成一段概述。这段概述在下一轮请求时作为“对话背景”注入系统消息，而不是塞在对话历史里。这样一来上下文长度被压住，关键背景又不丢。
我用一个真实项目的参数来说话。当时项目用的是32K上下文窗口的模型，我设定的工作记忆上限是16K，其中：系统指令加背景摘要占4K，当前对话历史占8K，预留4K给模型输出和工具返回。实测下来，这个比例下模型回答质量最稳定。如果背景摘要膨胀到8K，对话历史只剩4K，用户连续聊几轮后模型就会出现“记不起刚才几步”的问题。
3.2 情景记忆层的落地：从对话历史到向量记忆
情景记忆层的实现，核心是把“对话历史”转成“可检索的事件记忆”。我这里说的不是简单的逐句存档，而是有结构的摘要化记录。
我在项目里的做法是：在一轮对话结束后（用户意图已明确、Agent已回复），触发一次记忆写入流程。这个流程会做三件事：整理事件摘要、生成向量、存入向量数据库。
整理事件摘要时，我会按固定结构抽取信息：用户的目标是什么、Agent给出了什么结论、用户有没有表达偏好或异议、有没有遗留待办事项。每一条摘要控制在50到100字之间，既保证信息密度，又不至于太琐碎。这里我会用一次专门的模型调用做摘要抽取，而不是直接把对话原文存下来，因为原文太长了，而且有很多寒暄和无关内容，存进去只会污染向量索引。
向量化用的是一个Embedding模型，把摘要转换成768维或者1536维的向量。我项目里用的是bge-m3，在中文场景的检索效果比较稳。存储介质用的Qdrant，当然你也可以用Chroma、PgVector或者云服务提供的向量能力，各有优劣，后面我专门对比。
还有一个容易被忽视的点：情景记忆一定要带元数据。我在存储的每条记忆里都附加了会话ID、时间戳、事件类型（用户偏好、任务记录、方案讨论等）。这样在检索时，除了相似度匹配，还可以用时间范围、事件类型做过滤。如果没有元数据，向量检索只能做无差别的相似度召回，精确度会大打折扣。
3.3 语义记忆层的构建：从事件中提炼长期规则
语义记忆层是所有层级里最容易做烂的。有些团队直接把它做成“把System Prompt里的硬规则存起来”，但这样根本不算记忆，因为规则没有来源，也没有更新路径。真正有价值的语义记忆，应该从情景记忆中自动沉淀出来。
我的沉淀机制是一个定时/触发式的提炼流程。每次情景记忆新增到达一定规模（比如累计20条新的摘要），就触发一次语义提炼调用。这次调用把所有新闻情景摘要作为上下文，让模型抽取其中具备长期参考价值的信息，输出为结构化的语义记忆条目。
我要求抽取时遵守三条标准：一是不依赖特定时间背景（排除“上周”“昨天”这类时间限定）；二是不依赖特定对话场景（用户这次问A方案，不能得出“用户只喜欢A方案”的结论）；三是具备行动指导价值（能影响未来某一类决策的信息才算）。凡是不满足这三条的，即便在情景摘要里很醒目，也不允许沉淀到语义记忆层。
语义记忆的存储结构我建议用JSON格式，每条记录包含：主体（用户/项目/组件）、谓词（偏好/禁止/要求/规则）、对象（具体内容）、来源（从哪条情景摘要提炼的）、置信度（初始为0.7，后续被验证会提升）。置信度这个字段特别有用，当你发现某条记忆被频繁验证时，可以提升其权重，让它在后续检索排序中占据更靠前的位置。
提取时机：把语义记忆注入到Agent上下文的时机我这里给出了一个规律：语义记忆要在每次请求组装时和基础System Prompt一起注入，而不是检索出来临时拼接。因为语义记忆是Agent做任何决策都要参考的底层背景。但它又不能太占空间，我控制语义记忆条目的总Token在2K以内，超过这个体量就要做优先级裁剪，只保留置信度最高的条目。
4. 写入、检索与更新的完整实操策略
4.1 写入时机：不是所有对话都值得进记忆
把什么信息写入记忆，比怎么存更容易决定记忆系统的成败。我见过太多项目把所有对话全部入库，结果记忆池里充满了“好的”“明白了”“哈哈哈”这类垃圾，检索时把好好的向量空间搅成一锅粥。
我的写入策略分两级。第一级是即时判断：在每轮对话结束后，用一次轻量模型调用判断这轮对话是否包含值得记录的信息。判断维度包括：是否出现了用户的具体偏好、是否做出了决策或承诺、是否引入了新的事实或约束。只要命中其中任意一条，就进入情景记忆的写入流程，否则直接跳过。
第二级是定时萃取：情景记忆池每积累到一定规模，就触发一次向语义记忆的提炼。这也就是我前面提到的批量抽取机制。注意这里有一个取舍——萃取跑得太频繁会耗费大量Token，跑得太慢又会让情景记忆池膨胀。我试过的合理阈值是每20条新情景记忆触发一次，或每24小时触发一次，你先到先的为准。
还有个关键点：写入操作要异步。不要在用户对话的关键路径上做记忆写入，否则每轮对话都要等待一次甚至两次模型调用，响应延迟直接飙升。我通常的做法是把记忆写入动作丢进消息队列，由后台Worker去处理，用户无感知。
4.2 检索策略：相似度、时间衰减和重要性权重
检索决定了记忆能不能在需要的时候被想起来。只做简单的Top-K相似度召回，效果往往不理想，因为相似的句子不一定相关，相关的内容不一定字面相似。
我的检索策略是“两阶段召回加精排”。第一阶段用向量相似度召回候选集，比如召回30条，这个阶段追求召回率，不太在意精度。第二阶段做精排，精排公式结合三个因素：向量相似度、时间衰减因子、重要性权重。
时间衰减因子我用的是指数衰减：score = base_score * exp(-lambda * days_since)。lambda取值在0.01到0.05之间，具体看业务对时效的敏感度。比如做活动运营的Agent，lambda取大值，三天前的信息权重快速下降；做项目知识管理的Agent，lambda取小值，三个月前的信息依然有价值。
重要性权重直接取自元数据。我在写入情景记忆时，会给每条记忆打一个重要性标签，用户明确表达的偏好权重最高，Agent观察到的隐含行为次之，纯粹的流程记录最低。精排时权重叠加，确保高价值记忆不被时间冲掉。
还有一个细节：检索时的查询改写。不要把用户的原始问题直接拿去向量搜索，先做一次查询改写，把用户的自然语言问题转成一个更适合检索的查询语句。比如用户问“你们还有什么适合新手的课程吗”，改写后的查询是“面向新手的课程推荐 入门级别”，召回效果会明显更好。
4.3 更新与遗忘机制：记忆不能只增不减
在所有关于记忆的讨论里，遗忘是最容易被忽略的环节。我早期做记忆系统就栽过跟头：语义记忆越攒越多，注入上下文的条目越来越多，结果模型被一堆过时的旧偏好干扰，做出很怪的判断。
遗忘机制至少要做三件事。第一件是陈旧性清理：定期扫描语义记忆，超过有效期（比如180天）且未被命中的条目，降权或删除。这里“未被命中”的判断依据是检索日志——如果一条记忆长期没有被召回，说明它的存在价值很低。
第二件是冲突消解：当新记忆与既有记忆矛盾时，不能直接写入覆盖。比如用户之前说“我喜欢简洁风格”，今天说“这个设计太简单了，我要更华丽的效果”。正确的做法是把两条记忆都保留，但给新的记忆更高的置信度，同时标记旧的记忆为“可能已失效”，在一段时间内观察用户行为来最终裁决。
第三件是记忆合并：大量相似记忆会占用空间、干扰检索。我定期做一次聚类合并，把同一主题的N条情景摘要合并成一条综述，同时释放原始条目。这一步类似于人类把一段时期内的重复体验浓缩成一个总结性认识，是记忆系统保持敏锐度的关键操作。
5. 实操中的踩坑记录与排查清单
5.1 向量检索结果质量差，怎么排查
这是最常见的坑。你兴致勃勃地做了向量记忆，结果检索出来的东西驴唇不对马嘴。我的排查路径是这样的：第一，先确认Embedding模型选型是否匹配场景。做中文场景用通用英文模型效果大概率差，我这里踩过坑，后来换成了中文优化过的模型，效果立竿见影。第二，检查摘要质量。如果存入向量库的摘要本身就写得模糊不清，检索质量一定上不去，先看一眼库里存的原始摘要，是不是“用户说了一些东西”这种废话。第三，看检索的Top-K取值。K太小会漏掉相关记忆，K太大会掺杂噪声。我的建议是先取大K召回、用精排压缩，而不是一上来就取小K。
还有一个经常被忽略的因素：混合检索。纯向量检索在专有名词和多字面差异场景下效果不稳，比如用户提到“预算方案”而库里存的是“资金计划”，语义接近但向量匹配度不高。加上BM25词法检索做混合，把两路结果合并再精排，效果会稳很多。
5.2 记忆污染和串扰
记忆污染指的是低质量信息混进了记忆池，然后反复被检索到、反复影响模型输出，形成恶性循环。污染源主要有三个：一是对话中的噪声信息被当成偏好记录，用户随口说一句“今天天气真好”，被记成了“用户喜欢晴天”；二是摘要模型抽取时产生了幻觉，写了用户根本没说过的话；三是旧知识没有及时失效，用户已经换了技术栈，旧的偏好还在注入上下文。
应对污染的办法第一是写入端把关，严格按4.1的判断标准过滤；第二是定期抽查，我在可视化后台里做了记忆浏览功能，隔几天人工扫一眼记忆池，发现有问题的条目直接标记删除；第三是建立“记忆反馈环”，当用户明确否定Agent提到的记忆内容时，触发一条“否定信号”，对相关记忆降权，并在上下文里标注“该记忆已被用户推翻”。
5.3 存储膨胀和性能瓶颈
记忆系统跑上几个月后，向量库的体积会膨胀得很厉害，随之而来的问题是检索延迟上升、Token费用上涨、校准流程变慢。我遇到过最极端的情况是，情景记忆库存了超过百万条摘要，单次检索耗时从50毫秒涨到了300毫秒。
解决存储膨胀，核心是分层级的归档策略：热记忆（最近30天、高频命中）放在在线存储；温记忆（30到180天内）做聚合压缩；冷记忆（超过180天）直接转存到低成本存储或者干脆删除。检索时默认只查热记忆，只有在热记忆召回不足时才降级查询温记忆。用这种策略，我把检索延迟压回了60毫秒左右。
还有一点是关于索引参数的调优。向量索引的HNSW参数里，M值决定了每层最大连接数，efConstruction决定了建索引时的候选集大小。M越大内存占用越高但召回质量越好，efConstruction越大建索引越慢但索引质量越好。我在项目里用的M=16、efConstruction=200，在召回质量和资源消耗之间平衡得比较好。如果你只有几千条记忆，直接用暴力扫描就行，建索引纯属多此一举。
5.4 记忆与Agent框架协同时的几个共性问题
最后这一小节想聊一聊记忆模块和整体Agent框架的配合问题。记忆系统不是独立的，它要在Agent的编排流程里被正确调用，才会真正发挥价值。
第一个共性问题是在多Agent协作场景下，记忆要不要共享。我的建议是：共享基础语义记忆（如用户的长期偏好、全局规则），各自保留私有情景记忆（如各自的执行过程）。如果所有的Agent共享全部记忆，会导致A Agent在某次任务中的中间错误被B Agent当作事实使用，造成错误传播。更稳妥的做法是设计一份全局知识库存放可信的、经过确认的共享记忆，各Agent只拥有这个知识库的读权限，没有写权限，只能向“记忆审核队列”提交建议写入的内容。
第二个问题是一致性和刷新时机的冲突。有的框架会在每一轮Agent循环里重新注入全部记忆，这在浅层任务里没问题，但在长链路任务里会明显拖慢速度。我的做法是把记忆注入的时机分成三等：任务开始时全量注入、工具调用之间只注入工作记忆、单轮对话结束时增量异步更新情景记忆。这样既保证Agent在整个任务里方向不偏，又不在高频循环里反复重算大向量检索。
第三个注意到的是安全问题。记忆内容可能包含敏感信息，需要对不同层级设置不同的访问控制。语义记忆层因为它会被全局共享，必须做脱敏处理，比如用户手机号、地址信息只存储在受保护的存储介质中，模型上下文里引用时用脱敏后的占位符。情景记忆层属于会话级数据，默认只允许创建它的会话读取，跨会话访问需要显式授权。这条看似是管理问题，真出了问题就是安全事故，我从一开始就把权限模型写进了记忆服务的访问逻辑里。
还有就是在做Agent和框架选型时，很多人分不清底层模型能力、Agent编排框架和记忆服务之间的关系。如果你用的是常规的对话式应用，一个支持会话历史和摘要功能的应用框架加上外部向量库就能解决大部分问题；但如果你做的是复杂的多步骤、跨会话Agent，我建议独立出一套记忆服务，别和业务逻辑耦合在一起。后面接新的Agent应用时，记忆这块能直接平移复用。
结尾：一点真实体感
分层记忆做下来，我最大的体会是它不只是一个技术架构方案，更是一种“取舍哲学”。每一层记忆都在时间和抽象度之间做权衡：工作记忆快但是短，情景记忆有细节但是散，语义记忆稳定但是抽象。把这三层做扎实、做联动，Agent才真正从一个“每轮都重新开始的接口调用者”变成一个“有连续经验的执行者”。
如果你也在做Agent开发，我建议你先别急着上很复杂的记忆系统。先把工作记忆管好，清理上下文、压缩历史，把最基础的连贯性保住；然后加一层最简单的情景记忆，用向量库存住用户的关键偏好；跑两周之后再慢慢沉淀语义记忆。千万别一上来就把三层全做了，Agent的分层记忆系统复杂度是递增的，每一层都会给你带来新的权衡问题。先跑通，再优化，被问题逼到墙角，你就知道该往哪一层下功夫了。
