Agent多轮对话记忆缺失怎么办？Memory分层设计与工程落地实践

我在做客服类 Agent 的时候，碰到过一个印象特别深的场景：用户第一轮说“我住在杭州，孩子上小学三年级”，第五轮问“这周末带娃去哪儿玩合适”，Agent 直接给出一个“推荐您飞往三亚度假”的方案。产品经理当场反问：我们这个 Agent 是不是没有记忆？这个问题不解决，后面所有对话体验都白搭。说白了，大模型每次调用都是无状态的，它自己不会记住任何东西，所谓的 Agent 记忆完全靠外围的 Memory 记忆体系去实现。这篇文章我想把在 Agent 扩展范式、记忆体系分层、以及多轮记忆改造这三块上的实操经验完整梳理一遍，适合正在做 Agent 开发、被“聊着聊着就失忆”问题折磨的同学参考。

1. Agent 记忆缺失的根源：无状态模型与三种遗忘

很多人第一次接触 Agent 时会有一个错觉：模型上下文窗口这么大，把历史消息全塞进去不就有记忆了吗？实际跑过之后会发现根本不是这么回事。大模型的每次请求都是独立的，输入一段文本，输出一段文本，调用结束之后它的状态就清零了。所谓的“记忆”，完全是 Agent 外围工程在替模型补课。

1.1 上下文窗口是上限，不是记忆

以常见的长上下文模型为例，就算支持 128K token 的窗口，看起来很大，但真实使用中消耗得极快。假设用户每轮说 200 token，助手回复 300 token，50 轮对话就是 25,000 token；再加上系统提示词、检索回来的参考资料、工具定义、Agent 的思考链，很快就能吃掉一大半窗口。如果业务里还要塞进商品资料或文档片段，窗口会在你毫无感知的情况下被撑爆。

更麻烦的是窗口满了之后的处理方式。大多数框架默认“截断最旧的消息”，但这恰恰是最蠢的做法——早期对话里往往藏着用户最核心的诉求和偏好。我见过不少项目，Agent 在 20 轮内表现正常，过了 20 轮就开始反复问用户已经回答过的问题，原因就是早期信息被滑动窗口挤出去了。这种“伪记忆”策略虽然简单，但会在长对话中系统性失效。

1.2 短期、长期、永久遗忘分别发生在哪一层

把实际项目中遇到的遗忘问题归类后，会发现它们根本不是同一个层面的问题：

• 短期遗忘：同一场会话还没结束，早期信息就被窗口截断丢了。表现是“刚才说过的话，转头就忘”。
• 长期遗忘：跨天、跨会话之后完全不记得用户是谁、之前聊过什么。表现是“换个 session 就重新认识”。
• 永久遗忘：用户的核心偏好和事实性信息没有被固化下来，后续所有会话都无法复用。表现是“用户反复提供同样的个人信息”。

我在做改造前，一直把这三类问题混在一起处理，结果就是又加摘要又加向量库，却说不清每层到底解决什么。后来把记忆体系按这三层拆开，每层对应一套独立的存储、读写和管理策略，问题一下子就清晰了。短期记忆管“当下的连贯”，长期记忆管“跨会话的上下文召回”，永久记忆管“用户画像的沉淀”。

2. Memory 分层设计：Working Memory、长期记忆与永久画像的实现细节

记忆体系分层的思路，可以用一个类比来理解：短期记忆像你手边的草稿纸，随写随扔；长期记忆像你的笔记本，重要内容会记下来，用时翻一翻；永久记忆像档案柜里的身份证复印件，关键信息必须长期保存且不能搞错。Agent 的 Memory 设计，本质上就是把这三层分别落地。

2.1 Working Memory：窗口内即时上下文的组织方式

Working Memory（工作记忆）解决的是“当下这场对话怎么组织上下文”的问题。它不一定要把全部历史消息都塞进模型，而是要保证模型在每个时刻都能看到它决策所需的关键信息。我的做法是给对话上下文设定 token 预算，然后按优先级分配：

• 系统提示词：约 20% 的预算，里面放 Agent 的角色设定、记忆使用协议。
• 即时对话：约 60% 的预算，保留最近 N 轮完整对话。
• 记忆检索结果：约 15% 的预算，放从长期记忆和画像中查回来的相关内容。
• 工具定义与中间输出：约 5% 的预算。

当对话超过预算时，不要直接删最旧的消息，而是先把旧消息里仍然重要的信息提炼成一句摘要，放进上下文的开头位置，再丢弃原文。这样一来，模型即使看不到完整历史，也能通过摘要保持上下文连续。我在项目中实测，同样的任务，使用摘要压缩后的窗口管理方式，60 轮对话内的追问率比纯截断方式降低了大概 40%。

2.2 长期记忆：摘要抽取与向量检索的组合拳

长期记忆的核心是“跨会话还能想起来”。纯粹的拼接历史行不通，因为存不下也检索不动；纯粹的向量检索也不够，因为用户的问题往往带有时间上下文。我最终采用的方案是“滚动摘要 + 向量检索 + 重排序”的组合。

滚动摘要的触发时机很关键。我的经验是：每累积 20 轮对话，或者当前工作记忆接近 token 阈值时，触发一次异步摘要任务。摘要必须包含四类信息：用户当前的目标、已经确认的事实、尚未解决的问题、明确表达过的偏好。摘要生成后，作为一条独立记忆写入向量库，同时保留时间戳和会话 ID。

检索侧，用户每发来一条新消息，先用 embedding 模型把这条消息向量化，在向量库里召回 top_k 条相关记忆，然后再用 LLM 做一次 lightweight 重排序，选出真正对当前问题有参考价值的 3 条左右。之所以加一步重排序，是因为 embedding 的相似度并不完全等价于“语义相关”，有时候召回的前几条都是噪音，必须让模型再筛一遍。

2.3 永久记忆：结构化用户画像与事实库

永久记忆适合用结构化数据存，我用的是一张用户画像表，字段包括用户身份、所在地区、默认选项、明确禁忌、历史偏好等。这层记忆必须和长期记忆分清楚：长期记忆是“可能有用”的背景资料，永久记忆是“必须遵守”的事实约束。

这里有一个非常容易踩的坑：画像更新时直接覆盖旧值。用户说“我不吃香菜”，过了几天又说“其实我能吃一点”，如果直接覆盖，那没问题；但如果用户只是某次情绪化表达，直接覆盖就会造成误判。我的做法是：更新画像时保留历史值，只改当前值，并记录更新时间和来源。模型读取画像时，看到的是“当前值 + 历史变更记录”，这样既能适应用户偏好变化，又能在上下文冲突时回溯原因。实际上，这套设计帮我解决了不少“用户明明改口了，Agent 还拿旧偏好说事”的投诉。

3. 扩展范式重构：让工具、Skill 与记忆体系协同工作

标题里的“Agent 扩展范式”指的是 Agent 能力扩展的方式：给 Agent 加工具、加技能、加子 Agent。这一层如果不和记忆体系打通，就会出现一种尴尬局面——记忆是有了，但 Agent 根本不知道什么时候该去查记忆、什么时候该把工具结果写进记忆。扩展范式必须跟着记忆体系一起做重构。

3.1 工具扩展层的记忆感知设计

工具的调用场景天然和记忆强相关。以天气查询工具为例，用户第一次说“我在北京”，Agent 调用了带地区参数的天气接口；但第二次、第三次还要不要反复问“您在哪座城市”？不应该。做法是在工具调用前加一个“记忆回填”阶段：从永久画像里提取工具所需的关键参数，如果画像里有就直接填上，没有才向用户询问。

这个“记忆回填”听起来简单，但在工程上涉及工具入参的 schema 改造。我给每个工具定义里加了一个memory_source字段，标注哪些参数可以从画像元数据中自动获取，哪些参数必须由用户显式确认。Agent 在规划工具调用时，会先查询记忆层，能填充的字段直接填充，不能填充的才进入追问流程。这套机制落地后，“为了一个城市信息反复追问”的体验问题基本消失。

3.2 Skill 封装：把记忆操作变成可复用组件

Skill（技能/能力单元）和工具的区别在于：工具通常是纯函数式的接口，输入输出确定；Skill 可以封装完整的状态处理逻辑，包括读写记忆。在我改造后的架构里，以下三个高频操作被封装成了 Skill：

• 偏好提取：从用户消息中抽取结构化事实并更新永久画像。
• 对话摘要：对工作记忆中的历史做滚动压缩，写入长期记忆。
• 记忆检索：结合用户画像、长期记忆和工作记忆，组装成上下文。判断何时该调用哪个 Skill 则由主 Agent 的规划链路负责，不需要业务侧手动调。

这样做的好处是，任何新接入的子 Agent 或工具，只要声明需要这些 Skill，就能立刻拥有记忆读写能力。多轮记忆改造不再是一次性补丁，而是变成框架层的基础能力。

3.3 多 Agent 协作中的记忆共享与隔离

多 Agent 场景下，记忆不是越共享越好。我的实践原则是：全局共享层放用户画像和高频稳定事实，局部工作区放单个子 Agent 当轮对话的上下文，隔离层放敏感信息和临时状态。

举个例子：一个客服系统拆成导购、售后、物流三个子 Agent。用户地址、会员等级这类信息放在全局共享层，所有子 Agent 都能读取；但“当前售后工单的详细信息”只放在售后子 Agent 的 Working Memory 里，其他子 Agent 不需要也不应该读取。这样设计避免了两个问题：一是全局什么都存导致检索时互相干扰，二是子 Agent 之间的临时数据互相污染。记忆的写入和读取权限，一定要跟着业务边界走，而不是简单地把所有记忆堆到一个共享池里。

4. 多轮记忆改造的完整落地链路：从场景盘点到底层中间件

这一部分进入实操。前面讲的是设计思路，现在讲的是改造步骤。我复盘了多个项目的改造过程，沉淀出的标准链路是：场景盘点 → 记忆分层定位 → 读写触发点设计 → Prompt 改造 → 中间件落地 → 回归验证。

4.1 场景盘点：先判断你的 Agent 到底需要哪层记忆

不是所有业务都需要三层记忆全上。单轮查询类场景（翻译、计算、简单问答）只需要基础的用户默认项；多轮任务类场景（客服、导购、编程助手）需要 Working Memory 加长期记忆；跨会话个性化场景（理财顾问、健康助理、学习伴学）才需要三层全上。判断矩阵可以参考：

我见过不少团队一上来就搞向量库，加了一堆基础设施，结果业务只需要短期记忆加用户默认项。先花半天时间盘点场景，比先花两周搭记忆框架要划算得多。

4.2 记忆的写入、读取与更新触发点设计

读写触发点是记忆体系能不能真正跑起来的关键。我的经验是：写入时机、读取时机、更新策略三件事必须分开设计，不能混在一起。

写入时机有四个高价值节点：用户提供了新事实且经模型确认时、对话轮次达到摘要阈值时、用户显式表达偏好变更时、工具返回了影响后续决策的关键结果时。读取时机有两个：用户新消息进入且 Agent 规划下一步时、调用工具之前的参数准备阶段。更新策略上，永久画像走“合并式更新”，长期记忆走“追加式写入”，工作记忆走“滑动窗口 + 滚动摘要”。

4.3 Prompt 层改造：让模型学会“查记忆”而不是“背上下文”

记忆中间件就算写得再好，如果 Prompt 里没有对应的使用协议，模型也可能把检索来的记忆当作上下文随手堆叠。我给记忆改造项目写了一套统一的 System Prompt 模板，核心是给模型一套记忆使用顺序：

你是智能助手，回答问题时按以下顺序使用记忆：

1. 首先读取用户画像中的身份、偏好、禁忌字段，涉及个性化问题时必须引用；
2. 其次从长期记忆中检索与当前问题相关的历史结论、未完成事项；
3. 最后参考当前对话最近几轮内容，但不要超出画像与长期记忆范围做推断；
4. 如果记忆中没有所需信息，直接询问用户，不要编造。

这段协议真正起作用的是第 4 条。加了这一条之后，Agent 在记忆不足时不再“硬答”，而是选择询问。别小看这个改变，它直接决定了记忆体系是“辅助决策”还是“误导决策”。

4.4 回归验证：五个关键指标

改造完成后必须做量化对比。我每次都用同一批业务数据做回归，重点看以下五个指标，改造成果一目了然：

有一个反直觉的发现：加了记忆体系之后，整体 Token 成本不一定上升。因为模型不需要靠反复追问来补齐缺失信息，反而省掉了大量无效对话轮次。只要窗口管理和摘要触发做得好，成本是可以做到不升反降的。

4.5 一段最小可用的记忆中间件核心逻辑

最后放一段我自己项目中精简出来的核心代码，它实现了“写入画像 + 滚动摘要 + 按需检索”三个最基础的能力。框架无关，只保留主干逻辑，方便你抄作业后根据需要扩展：

import json class MemoryMiddleware: def __init__(self, profile_store, memory_store, llm): self.profile_store = profile_store # 永久画像存储 self.memory_store = memory_store # 长期记忆向量存储 self.llm = llm # 对话模型 self.summary_threshold = 20 # 每20轮滚动摘要一次 async def on_message(self, session_id, user_msg, assistant_msg): profile = await self.profile_store.load(session_id) # 1. 抽取结构化事实并合并进永久画像 facts = await self.llm.extract_facts(user_msg) for fact in facts: profile[fact.key] = { "value": fact.value, "updated_at": fact.timestamp, "source": "user", } await self.profile_store.save(session_id, profile) # 2. 记录本轮对话 await self.memory_store.append(session_id, user_msg, assistant_msg) # 3. 达到阈值时，对旧历史做滚动摘要，写入长期记忆 recent = await self.memory_store.load_recent(session_id, limit=21) if len(recent) >= self.summary_threshold: summary = await self.llm.summarize(recent[:-1]) await self.memory_store.save_summary(session_id, summary) await self.memory_store.clean_old(session_id, keep=1) async def retrieve(self, session_id, query): # 按优先级组织：画像 + 长期记忆相关片段 profile = await self.profile_store.load(session_id) memories = await self.memory_store.search(query, top_k=3, min_score=0.7) return {"profile": profile, "memories": memories}

代码里有两个细节需要注意。min_score=0.7是检索阈值，具体值取决于你使用的 embedding 模型，我建议先跑一批真实数据看分数分布再定。clean_old(session_id, keep=1)表示滚动摘要后只保留最新一轮的原始对话，避免历史无限膨胀。这两个参数都要在回归验证阶段调优，不能拍脑袋定死。

5. 记忆框架选型与真实踩坑记录

最后聊框架选型。这个话题很容易被带偏，因为市面上的方案太多，而且新概念一个接一个。我的经验是：先弄清楚自己的记忆需求属于哪一层，再决定是用现成框架还是自研中间件。

5.1 现成框架 vs 自研中间件的取舍

我接触过的方案大致可以分成四类：

对于大多数业务，我建议走“向量库 + 自研中间件”，理由很简单：现成框架的 Memory 模块通常只解决“短期上下文拼接”这一件事，对长期记忆和永久画像的适配不够灵活；而自研中间件虽然要写一部分存储逻辑，但能把记忆分层、读写触发点、业务字段更新完全掌握在自己手里。等业务形态确定之后，再考虑引入更重的框架也不迟。

5.2 向量检索的典型坑：阈值、噪声与过期内容

向量检索是三块里最容易出问题的部分。第一个坑是相似度阈值拍脑袋。阈值设太低，召回一堆无关记忆，模型上下文被污染；阈值设太高，该召回的内容又召不回。我见过有项目用默认的 0.8 阈值，结果几乎所有记忆都被过滤掉了，效果还不如不用。解决方式是先采样一部分真实对话，看查询和正确记忆之间的分数区间，再定阈值。

第二个坑是召回结果不做时效性处理。用户三个月前的偏好和三天前的偏好权重应该不一样。我的做法是给记忆打时间戳，检索评分时乘一个时间衰减因子。第三个坑是混合检索的必要性。用户往往用口语化表达，纯向量检索召回不稳定，混合关键词检索再合并排序会稳定得多。

5.3 记忆污染与安全防线：写好“记忆写入防火墙”

记忆污染是记忆体系里最隐蔽的问题。用户完全可以通过对话诱导 Agent 记住错误信息，比如“请记住我喜欢红色”，然后过一阵子用这条被篡改的记忆误导 Agent 做出错误决策。这在多轮对话里，相当于一次轻量级的提示注入攻击。

我改造时的做法是加一层“记忆写入防火墙”：画像字段白名单化，只有预定义的字段类型允许写入；写入前做事实一致性校验，和已有画像冲突的值标记为低置信度；敏感信息先脱敏再入库。记忆隔离也要做好，不同用户 session 之间的向量检索和画像读取必须严格隔离，否则会出现 A 用户的信息被 B 用户的会话召回的严重事故。这点在自研中间件时尤其容易被忽略，一旦上线就是生产事故。

最后分享几条实际体会

这套改造做完，我自己印象最深的一点是：记忆体系的收益不是“让 Agent 记住更多”，而是“让 Agent 少问一遍”。用户感知最强的瞬间，不是 Agent 背诵式地复述他的资料，而是他发现自己不用再把说过两遍的话说第三遍。如果你正准备做类似改造，我建议不要一上来就上重框架。先花半天把业务场景盘清楚，画出记忆分层图，想清楚每层解决哪个问题，再做最小改动验证效果。另外，记忆写入的安全防线一定不能省，宁可少存几条，也不能让错误信息或越权数据进入长期记忆。改造完成后，坚持跑一段回归数据，用追问率和信息一致性这类硬指标说话，你才会真正知道这套记忆体系值不值。