做聊天机器人这几年，我踩过最深的坑，就是记忆设计。模型能力再强，如果记不住人、记不住事、记不住前因后果，对话体验就是散的。用户上午说"我最近在准备考研"，下午再问"给我推荐点复习资料"，它完全接不上，这就是典型的失忆。所以"聊天记忆设计"从来不是某个单一功能，而是一整套从采集、分层、存储到检索的闭环工程。这篇文章，我把实际操作中总结的方案、踩过的坑、以及一套可以直接落地的轻量级架构，完整写下来。
1. 先搞清楚：聊天记忆到底在解决什么问题
1.1 对话场景里的“失忆”现象
你回想一下自己用对话助手的经历。刚聊完上一句，下一句就忘了，这是最基础的失忆。更让人崩溃的是跨会话失忆：昨天聊过的需求，今天重新说一遍。稍微好一点的产品会记住你上次报过的账号、偏好，但换个话题、隔两天，又断片了。
我刚开始做某智能客服项目时，一开始以为只要把上下文拼进模型提示词里就行。结果上线不到一周，用户投诉集中在同一个点：客服机器人每次会话都像第一次见面。用户已经在前一轮说了"我的地址是某某小区3栋"，下一轮问配送时间，它还在问地址。说白了，没有记忆的对话机器人，本质上就是个"一次性筷子"，用完就扔。
这里的核心问题不是模型没有记忆能力，而是我们没有给它设计记忆机制。模型本身是个"天才鱼"，只有7秒的注意力。你需要在外面挂一个"鱼缸"，帮它把要记的东西存起来、随时取出来。
1.2 记忆设计的目标拆解
做记忆设计之前，先要明确目标。我把它拆成三个层次：
第一层，会话内连续性。指的是在同一轮对话中，模型能记住前面几轮说过的话，这个词通常叫上下文连续。比如用户说"帮我订一家川菜馆"，接着问"有没有评分高的"，模型要能知道"评分高的"修饰的是"川菜馆"，而不是什么别的东西。
第二层，跨会话稳定性。用户隔几天再回来，系统能认出这是同一个人，记住他上次的需求、偏好、说过的重要信息。这是最常规也是最有价值的一层，能直接影响留存。
第三层，个性化自适应。更进一步，系统能从多次对话中抽象出用户的长期偏好和行为模式。比如知道用户习惯晚睡、喜欢清淡口味、预算敏感度高，然后主动调整回答策略和推荐逻辑。
你设计每一块记忆时，都得先问自己：它服务于这三层里的哪一层？不要什么都记，也不要什么都忘。做记忆的第一步，不是选技术方案，而是定清边界。
2. 记忆分层模型：把记忆拆成三块来管
你要是把所有信息一股脑塞进同一个存储里，用不了多久就乱套。我在实践中不断调整后，最后稳定下来的方案，是把聊天记忆拆成三个层级：工作记忆、情景记忆、语义记忆。这三个词是从认知科学借来的，但工程上非常好用。
2.1 工作记忆：会话窗口里的短期记忆
工作记忆就是当前对话中模型能够直接看到的那部分信息，对应大模型提示词里的上下文窗口。它不需要额外存储，只要处理好窗口的内容组织。
这里的核心矛盾是：大模型的上下文窗口是有限的。你现在随便一个模型都能支持几千、几万 token，但你把每一轮原始对话都往里灌，一是很快顶到上限，二是信息密度低，一些关键信息会被淹没在闲聊里。
我做这个模块时，最常用的手段是滑动窗口。设定一个最大轮数，比如 10 轮，超过就把最早几轮干掉。或者按 token 数控制，超过某个阈值就裁剪。但滑动窗口有个隐患：如果关键信息出现在很早就被裁掉的那几轮，后面就找不到了。所以滑动窗口要配合"关键信息提取"，在每轮对话结束后，把该轮的要点抽出来，放进一个独立区块，保证即使原始轮次被裁，要点还在。
另外，工作记忆要记得给模型一个明确的"记忆格式"。我会在系统提示词里放一个固定的区块，叫"当前已知信息"。每轮更新一次，格式大概是：
已知信息： - 用户所在地：某市 - 当前需求：寻找高评分川菜馆 - 特殊偏好：不吃香菜模型每次回答前，先读这个区块，就能快速定位本期核心信息，不用从头翻聊天记录。
2.2 情景记忆：跨会话的场景信息
工作记忆只管当前会话，但用户不会每次都只聊一个话题。上次聊的是订餐，这次聊的是行程规划，这两件事之间没有直接关联，但对同一个用户，他的地点、口味偏好、常活动区域是互通的。这些跨会话的、按时间顺序排列的场景化记忆，就是情景记忆。
在我的项目里，情景记忆是按事件为单位存的。每个"记忆事件"包含几个字段：发生时间、会话主题、关键实体、用户意图、解决结果。举个例子：
时间：2025-01-10 主题：用户咨询考研复习计划 实体：考研、英语、数学 意图：获取复习资料推荐 结果：推荐了资料清单，用户表示满意这种存法最大的好处是，检索时有明确的筛选维度。用户重新提到"考研"时，系统可以直接把过去所有"考研"主题的记忆事件拉出来，拼进工作记忆里，模型立刻就知道这位用户是二战还是首战、上次推荐过什么。
情景记忆的存储结构我建议用 JSON 或者关系型结构，而不是一股脑丢进向量库。因为它有明确的结构化字段，用传统查询就能精准过滤，没必要全部依赖语义相似度。
2.3 语义记忆：用户画像与长期偏好
如果说情景记忆是"发生过的事"的记录，那语义记忆就是从这些记录里抽象出的"稳定的用户画像"。比如"用户偏好川菜"、"用户在备考"、"用户对价格敏感"，这都不是某一条对话产生的，而是从多轮对话中归纳出来的。
这里有个非常关键的工程问题：谁来生成语义记忆？
我试过两种路线。第一种是每轮对话结束后，调用模型做一次"画像增量更新"。好处是灵活，能捕捉很细的偏好；坏处是成本高，而且容易产生幻觉，可能把一次性的情绪表达归纳成稳定特征。比如用户只是随口说了一句"今天不想吃辣"，模型可能就把它记成"用户不吃辣"，后面全都按不辣推荐，反而失真。
第二种是定期批量归纳。每次会话结束后只记录原始摘要和行为日志，等到积累了 N 条（我一般设 5~10 条），再触发一次画像更新，让模型综合判断哪些偏好是稳定的。
我现在更推荐第二种，因为它能大幅降低误归纳率，省成本还是次要的，主要是准确性高。用户画像不是靠单一证据，而是靠模式识别。你需要的是"多次出现、且未被推翻"的结论。
3. 核心实现细节：从存储到检索的落地思路
记忆分层是理论图景，真正的难点在于把每一层的存储、更新、检索做扎实。这一章写几个核心的落地思路。
3.1 上下文长度不够用怎么办：摘要压缩
模型上下文窗口有限，但信息量可能无限。摘要压缩是我目前觉得最实用的一招。
具体做法：设置一个阈值，比如对话轮数超过 15 轮，或者 token 数超过窗口的 50%，就触发压缩流程。把前面的对话记录发给模型，让它总结成一份不超过固定长度的摘要，然后把摘要放回上下文，替换掉原始对话。
过程中有一个很容易犯的错误：摘要粒度太粗。有些实现直接把整个历史总结成三段话，结果模型丢失了大量细节，连用户说过的重要数字都忘了。我的做法是分层摘要：保持一个"最近 N 轮完整对话"的缓冲区，N 轮之前的内容再压缩成摘要。相当于一个两级结构——完整细节保留最近，更早的内容以摘要形式存在。
压缩时我还要求模型保留这几类信息，缺一不可：
- 用户明确表达过的偏好和需求
- 所有数字、时间、地点、人名等实体信息
- 用户情绪状态的转折点（比如从平静到明确不满）
- 待办事项和承诺
这样就算摘要丢掉了很多对话过程，但这些关键锚点还在，记忆连贯性就不会崩。
3.2 向量检索与召回：如何快速找到相关记忆
如果只有摘要，那记忆还是"死"的，得能被检索出来。跨会话检索，最自然的技术选型是向量检索。把记忆文本用嵌入模型转成向量，存进向量数据库，查询时把用户当前问题也转成向量，算相似度，取 top-k。
但你要注意，向量检索不是万能的。我刚开始做这个模块时，对每条记忆事件都做向量化，结果发现召回质量并不理想。原因有两个：一是向量相似度捕捉的是"语义相关"，但很多记忆检索本身就是精确匹配，比如用户报过手机号、订单号，这些数字串用向量检索纯属鸡肋；二是记忆事件里往往包含多个子主题，比如一条对话里既聊了用餐偏好，又聊了行程安排，整体向量化后内容互相稀释，检索精度就下降了。
所以我现在做的是混合检索。结构化字段（时间、实体名、会话主题标签）走传统的精确匹配或倒排索引，正文描述走向量检索。两条路并行，再合并打分。这样"考研"一词能直接命中所有带考研实体标签的记忆，"口味偏好"这种语义关联交给向量去联想。
检索结果回来之后，还要做一步重排。向量相似度只是初筛，真正注入提示词前，我会按一个简单规则过滤一遍：时间衰减（越新的记忆权重越高）、意图匹配（当前提问类型和记忆事件类型的对齐度）、矛盾检测（有多条冲突记忆时，以最近一条为准）。
3.3 记忆写入策略：哪些信息值得被记住
做记忆设计时，大家关注的多是"怎么读"，却容易忽略"怎么写"。你什么东西都往记忆里塞，后面的检索一定噪音爆炸。
我的写入策略是四个原则：
第一，实体优先。人、地点、时间、价格、数量、偏好标签等，这类信息值得记。情绪化表达（"我好烦"）除非反复出现，否则不记。
第二，不变量优先。用户反复强调的事实（"我住在某小区"）比一次性指令（"今天帮我点一杯美式"）更值得记。
第三，存来源，不存结论。如果说的是主观结论，比如"这个餐厅不错"，你存原文就行，别替用户归纳。归纳是画像层做的事，情景层只负责记录。
第四，显式确认才写画像。如果用户自己说了"我比较喜欢清淡"，这是高置信信号，可以进语义记忆。如果只是基于行为的推测，必须等到行为重复出现两次以上再进。
4. 实操过程：一个轻量级记忆模块的实现方案
理论讲完了，来点能直接动手的东西。下面这套方案是我在某智能助手Demo里的完整实现，可以跑通整个闭环。
4.1 整体结构设计
模块拆成四个子模块：采集层、处理层、存储层、检索注入层。
- 采集层：拦截每次用户输入和模型输出，按会话组织原始记录。
- 处理层：负责摘要、实体抽取、画像更新判断。
- 存储层：分三张表——会话表（存原始对话和摘要）、事件表（存情景记忆）、画像表（存语义记忆）。
- 检索注入层：查询时按当前输入触发检索，把结果拼进系统提示词。
我的事件表结构大致如下：
| 字段 | 说明 | 示例 |
|---|---|---|
| event_id | 唯一ID | evt_001 |
| user_id | 用户标识 | u_1024 |
| event_type | 事件类型 | task_order / preference / fact |
| content | 事件描述 | 用户预订了周五晚上的川菜馆，4人桌 |
| entities | 关键实体标签 | 川菜馆、周五、4人 |
| session_id | 来源会话 | sess_045 |
| created_at | 发生时间 | 2025-01-12 19:30 |
| importance_score | 重要性评分 | 0.8 |
画像表是长这样的：
| 字段 | 说明 | 示例 |
|---|---|---|
| user_id | 用户标识 | u_1024 |
| attr_name | 画像属性 | 口味偏好 |
| attr_value | 属性值 | 川菜、重辣 |
| confidence | 置信度 | 0.9 |
| source_count | 确认次数 | 5 |
| last_updated | 最近更新 | 2025-01-12 |
4.2 关键代码骨架
存储我用的是关系型数据库（比如 SQLite 起步就够），加一个嵌入模型服务做向量检索。核心的逻辑我抽出来几个关键片段。
第一段，会话摘要更新。每次对话轮次达到阈值时触发：
def condense_history(session_history: list[str], max_tokens: int = 800) -> str: prompt = f""" # 任务：压缩对话历史，保留关键信息 # 必须保留：用户偏好、实体信息（时间/地点/数字/人名）、情绪转折、待办事项 # 输出格式：分条列出的中文摘要，不超过 {max_tokens} tokens # 对话历史： {session_history} """ response = llm.chat(prompt) return response["content"]第二段，情景记忆写入。每轮对话结速后做实体抽取，判是否值得写入：
def extract_and_store_events(session_id: str, user_id: str, messages: list[dict]): # 抽取实体和意图 extraction = llm.extract(messages, fields=["entities", "intent", "summary", "important"]) if extraction.important_score < 0.5: # 不重要的不写入，避免噪音 return # 写入事件表 insert_event( user_id=user_id, event_type=extraction.intent, content=extraction.summary, entities=extraction.entities, session_id=session_id, importance_score=extraction.important_score )第三段，检索与注入。用户发起一轮新对话时，先去画像表与事件表里捞记忆：
def retrieve_memories(user_id: str, current_input: str, top_k: int = 5): # 1. 精确匹配：实体标签命中 entities = extract_entities(current_input) exact_hits = query_events_by_entities(user_id, entities) # 2. 向量检索：语义相关 vec_hits = vector_search(user_id, current_input, top_k) # 3. 合并去重，按时间衰减与相关度重排 merged = merge_and_rerank(exact_hits, vec_hits) return merged[:top_k] def build_prompt(user_id: str, current_input: str, system_prompt: str) -> str: memories = retrieve_memories(user_id, current_input) memory_block = "\n".join([m.content for m in memories]) return f""" {system_prompt} # 已知记忆信息 {memory_block} # 用户当前输入 {current_input} """这里有个细节要强调：记忆块要放到系统提示词或者单独分隔的区块里，不要混在用户输入的正中间，否则模型容易把记忆当成当前对话内容，产生奇怪的回复。
4.3 参数与阈值的选择依据
这类系统里，阈值拍脑袋是常态，但每个参数都有讲究。
重要性评分要不要写入，我设过 0.4、0.5、0.6 三档测试。0.4 太敏感，随便聊两句就记一堆，噪音太多；0.6 太高了，很多真正有用的隐性需求被过滤掉；最后稳定在 0.5。怎么判断阈值合不合理？跑完一批对话后，人工抽查记忆事件的"应记率"，就是随机抽 100 条已写入的记忆看它是否真的有用，以及另外抽 100 条"未写入"的记录看是否有遗漏。应记率在 70% 以上就算及格。
时间衰减参数用半衰期函数，我设的是 30 天。也就是说，一条记忆在 30 天后权重降到一半，90 天后基本沉底。这个数值要根据你的业务场景调：客服机器人（用户回归频繁）可以设更长，比如 90 天；闲聊类产品可以短一些，用户忘性大，记忆更新快。
向量检索的 top-k 我一般取 5。多了容易引入噪音，少了又不够全面。但这是对一般对话场景而言，你要是做深度咨询类产品，比如心理咨询助手，top-k 可能得拉到 10~15，因为这类对话高度依赖历史细节。
5. 常见问题与排查实录
做记忆模块一定会遇到各种奇怪的毛病，我整理几个最常踩的坑，按影响程度排列。
5.1 记忆混乱与串线
表现：用户明明之前说的是"喜欢靠窗的座位"，隔天系统却给他推荐了包间；或者更严重，把上一个人的偏好安到另一个人头上。
排查方向：先查 user_id 是否正确地传进了每次请求。这个听起来很基础，但我真的排查过好几次，发现是前端在某个场景下没带 user_id，导致后端把记忆写到了默认用户或新用户上。尤其是从会话切换页面跳转时，id 很容易丢。建议在写入记忆前加一层校验：当前 user_id 与会话绑定的 user_id 必须一致，否则拒绝写入。
另一种情况是向量检索召回串线。同一 user_id 下没混，但语义相似的记忆太多，出现相互干扰。这时候可以给事件表加一个简单的"场景标签"，比如 dining / travel / study，检索时先按场景过滤，再跑向量相似度，串线的概率会大幅下降。
5.2 记忆膨胀与遗忘
表现：记忆越攒越多，检索速度变慢，模型提示词里的记忆块过大，回答反而变得拖沓，甚至开始说一些过时信息。
这里要分清两种情况：一种是存储膨胀，但检索做得不好，把所有记忆不分轻重全塞进去；另一种是遗忘机制缺失，旧记忆和新记忆权重一样，旧事实覆盖不了。
第一种的解决办法是加强检索过滤，加重要性门槛，相关性得分太低的就不要进提示词。第二种需要强制"遗忘"机制。我设计了一个定期任务：每周扫描一次事件表，把 createdAt 超过 180 天、importance 低于 0.6 的记忆标记为 archived，不再参与检索。画像表同理，置信度低的 attr 自动降级。不要想着永久保留所有记录，聊天记忆和人的记忆一样，会遗忘才是健康的。
5.3 隐私与数据边界
做记忆设计不能回避隐私。我见过有团队把用户的完整聊天记录长期保留当作记忆库，这非常危险。一旦数据泄露，后果不可控。
我的做法是最小化采集。原始会话记录只保留 24 小时，用于当天的上下文连续；跨会话的记忆只存"提炼后的结果"，不存全文。比如用户说自己"在某公司做前端开发"，事件表里存"职业：前端开发"，而不会存完整对话内容。这样就算事件表泄露，黑客拿到也只是偏好标签，拿不到聊天原文。
另外要给用户一个"清除记忆"入口。这是很多产品容易忽略的，但做记忆系统必须要有。我在实现里加了一个全清按钮，调用后直接删除该 user_id 下所有事件、画像、会话记录。不做假删除，就是物理删除。
5.4 记忆准确性：模型幻觉渗透进记忆层
表现：模型在对话中生成了不符合事实的回答，比如用户说下周出差，模型误以为用户下周旅游，然后把这个错误理解写进了记忆。后期检索到这条记忆，错误就会被反复放大。
这是我觉得记忆系统里最可怕的问题，因为它的错误是累积性的。
应对方案有三道闸门：
第一道，写入前校验。实体抽取和摘要生成后，用关键词比对原对话，如果摘要里有原文没有出现过的结论，直接丢弃。这个可以用规则实现，不需要模型参与。
第二道，双模确认。重要程度超过阈值（比如 importance 高于 0.8）的记忆，再做一次二次确认，把摘要发给模型问一句"以下摘要是否完全由对话内容支撑？请回答是或否"。只通过确认的才写入。
第三道，冲突检测。新写入的记忆如果和已有的画像属性冲突，不直接覆盖，而是先标记为 pending，等再次出现同样的新结论时才落地。比如画像表里已有"口味偏好：清淡"，新对话出现"用户想吃重辣"，先把"重辣"标记为待确认，下一轮如果用户再次重辣，才把偏好改成"重辣"。
这套流程下来，准确率能提升不少。我实际跑下来，"用户明确说过的偏好"基本不会记错，"基于行为的推测"会有一定误判，但有了 pending 机制，误判也能在下一轮被纠正。
6. 聊天记忆设计还可以怎么扩展
如果你做完基础版，想更进一步，这里有几个可扩展的方向，都是我实际验证过价值的。
一种是记忆驱动的内容推荐。记忆检索出来的不单是给模型看，还可以直接驱动推荐系统。比如用户反复问健身相关话题，检索模块发现近期健身记忆特别高频，首页就可以自动推健身内容。这在内容社区、电商场景非常实用。
一种是多用户会话记忆，也就是群聊场景的升级。区分"某个人的偏好"和"这个群聊的共同记忆"，难度会增加不少，但价值也大，适合做社群机器人或者协同工具。
还有一种是记忆的显式提问。当系统检索不到相关信息时，不硬编，直接向用户提问："上次你提到的某项目，现在进展如何？"这种主动追问特别能拉近用户体验，但要注意频率，问多了反而烦人。我这边的经验是一轮对话里最多触发一次，而且只问重要信息。
最后放下之前几个失败的尝试。最开始我天真地以为"所有对话都存，所有记忆都给模型"，结果效果最差。后来又试过"只看最近 3 轮对话 + 全量向量检索"，效果中等偏上，但噪音太多。最终让我稳定下来的是这套"分层记忆 + 混合检索 + 写入控制"的组合。做记忆设计没有银弹，核心思路就一句话：记该记的，忘该忘的，检索准一点，注入稳一点。我那套方案从年初跑到现在，基本稳定，后面还会继续优化。如果你也在做类似的事情，欢迎一起交流。
