设计一个 AI 的长期记忆系统听起来像学术课题但真正做过 AI 产品的人都知道它是产品体验的胜负手。没有记忆的 AI 像一条只有 7 秒记忆的鱼聊完就忘有记忆的 AI 才像一个能连续工作的搭档。Mindbase 这个项目核心就是解决“让 AI 记住该记住的、忘掉该忘掉的”同时让记忆可以被检索、被更新、被沉淀成长期经验。这篇文章会把我在设计这套长期记忆系统时的完整思路、分层方案、写入检索流程和踩过的坑全部摊开讲适合正在做 AI 助手、智能体、对话机器人的开发者也适合想给自己的模型加“人设连续性”的产品经理。1. 先想清楚AI 的“长期记忆”到底指什么1.1 记忆不是聊天记录更不只是 RAG很多团队一开始会把长期记忆直接等同于“把历史聊天记录存下来下次提问时拼进 Prompt”。这么做确实能解决一部分问题比如用户上次问了什么、你上次回答了什么。但它的局限非常明显聊天记录是流水账不是记忆。流水账里没有重点没有实体关系没有时间维度的变化也没有“哪些信息已经过时”。RAG 经常被拿来和记忆混在一起。RAG 解决的是“让模型知道外部知识库里的内容”它本质上是一种可检索的外部事实库。而长期记忆要解决的是“让模型形成对用户、对任务、对自己行为的持续理解”。RAG 的知识是相对静态的记忆是动态演化的RAG 的检索目标是答案记忆的检索目标是上下文和行为依据。Mindbase 在设计之初就把两者区分开知识库挂在系统外部记忆系统则是贴着对话和任务动态生长的内部状态。我见过一个很典型的反面例子某项目把用户的全部历史对话都塞进 Prompt结果 token 消耗暴涨响应变慢而且模型经常被几条早期无关对话带偏回答质量反而下降。原因很简单——没有记忆结构的原始文本对模型来说是噪声大于信号。1.2 记忆的分类情景、语义、程序人的记忆分很多种AI 的记忆系统也可以借鉴这套分类情景记忆Episodic Memory记录“过去发生的具体事件”。比如用户昨天说“我下周要去上海出差”这就是一条情景记忆。语义记忆Semantic Memory记录“提炼出来的事实和概念”。比如从上面那句话里我们可以提炼出“用户经常出差”“用户近期行程涉及上海”。程序性记忆Procedural Memory记录“怎么做某件事的流程和偏好”。比如“用户喜欢先看结论再看细节”“用户习惯用中文技术术语”。Mindbase 采用这套分类不是单纯模仿认知科学而是因为它对存储和检索策略有直接的指导意义。情景记忆适合按时间和事件索引语义记忆适合按实体和关系索引程序性记忆适合按触发场景绑定行为偏好。如果只用一个扁平列表存记忆检索时会很难决定该优先命中哪类信息。1.3 长期记忆系统的核心能力模型在设计 Mindbase 之前我把长期记忆系统拆成五个能力写入、保存、检索、更新、遗忘。这五个词看起来简单落到实现上各有难点写入如何决定哪些信息值得记录而不是把每句话都存下来。保存用什么数据结构、放在什么存储引擎里才能支撑后续的高效检索。检索如何在用户发出请求时从海量记忆中捞出最相关的几条。更新当新信息和旧记忆冲突时怎么合并、怎么修正。遗忘如何让过时信息自然降权而不是永远占据检索位。这五个能力不是独立的。写入策略直接决定保存形态保存形态又反过来限制检索方式。所以我建议先从系统结构层面做统一设计而不是零散地加功能。Mindbase 的完整版本会把这五条链路全部串起来下面我会按设计顺序逐层展开。2. Mindbase 的整体设计思路与存储架构2.1 分层记忆模型工作区、短期缓存、长期库我不建议只做一个记忆库更合理的是分成三层第一层是工作区Working Memory。这是当前对话正在使用的上下文窗口包括最新的几条消息、当前任务状态、临时推理结果。工作区的内容不是记忆而是“正在处理的信息”。每次对话开始时工作区从长期库中加载相关记忆对话结束后工作区里值得保留的信息会被清洗、压缩、写入下一层。第二层是短期缓存Short-term Cache。它的作用是承接工作区和长期库之间的缓冲。比如用户在一个会话里连续聊了十件事其中一些可能只是寒暄不必立刻写入长期库但也不能直接丢弃因为可能在同一次会话后面还会用到。短期缓存通常用带 TTL 的键值存储实现数据保留几个小时或几天。第三层是长期库Long-term Store。只有经过筛选、压缩、结构化的记忆才会进入这一层。长期库里的数据需要具备良好的组织性通常用向量索引 结构化字段组合存储。这套分层的最大优势是降低了记忆写入的噪声。如果所有信息都直接进入长期库系统很容易记了一堆无关内容最后检索效果极差。短期缓存承担了“待定”状态让长期库只保留高置信度的长期信息。2.2 为什么用向量库做记忆载体又不能只用向量长期记忆的前提是“相似语义能被召回”所以向量化是基础。每条记忆可以用 Embedding 模型转成向量然后在向量数据库中做相似度检索。这个方案很成熟但它有一个陷阱向量相似度不等于用户当前真正需要的记忆。举个例子用户以前说过“我喜欢喝美式咖啡”这次说“推荐一家咖啡馆”。向量检索确实能召回那条咖啡偏好但它没有考虑时间衰减、偏好强度、当前对话的额外约束。如果同时存在“最近在戒咖啡”这条新记忆纯向量检索就很可能把旧记忆也带出来。Mindbase 的做法是“向量 结构化字段”双通道存储。每一条记忆记录除了有向量字段还有类型、时间戳、重要度、来源事件 ID、关联实体等基础字段。检索时先按结构化条件做粗筛再用向量做精排。这样既利用了向量的语义匹配能力又保留了记忆生命周期管理需要的元数据。2.3 记忆单元设计事件、实体、关系、摘要长期库里存什么这是整个系统里最关键的设计决策。Mindbase 把记忆单元分成四类事件Event一条带时间戳的实际发生记录。例如“2025-05-10 用户提到计划去杭州出差”。事件是最原始的记忆素材。实体Entity用户、项目、地点、事物等核心对象的抽象。例如“用户 A”“杭州”“出差项目”都是实体。关系Relation描述实体之间的联系。例如“用户 A 计划前往杭州出行”“用户 A 负责某项目工作”。摘要Summary对一段时期或一类主题的提炼。例如“近一个月用户频繁出差偏好住在离高铁站近的酒店”。这四个维度的关系是事件经过抽取变成实体和关系实体和关系经过聚合变成摘要摘要反过来可以作为更高层级的记忆索引。这样设计的好处是系统既能回答“用户上次什么时候说要去杭州”这种具体问题也能回答“用户出差时一般有什么偏好”这种抽象问题。2.4 记忆索引从标签到知识图谱只靠向量索引还不够。Mindbase 在记忆库外层维护一个轻量级的实体图谱用来记录实体之间的关联。为什么需要这个因为很多记忆检索用例是“沿着关系找记忆”的。比如用户问“我之前提过的那个喜欢喝手冲咖啡的同事叫什么来着”如果只做向量检索模型需要把“同事”“手冲咖啡”两个语义同时匹配到同一条记忆难度很大。但实体图谱可以直接提供一个路径先找到“用户提到的同事”相关实体再筛选“咖啡偏好”属性答案就出来了。实体图谱不需要做得很重也用不着在记忆库里完全复刻知识图谱的推理能力。我只用邻接表维护“实体-实体-关系类型-权重”的四元组支撑一跳或两跳的查询就够了。这个轻量索引在实践中已经能覆盖大多数“回忆型”问题。3. 写入与更新的实操细节3.1 什么内容值得记住重要性打分机制记忆系统最怕的是“什么都记”所以写入环节必须有一道闸门。Mindbase 用一套规则 模型打分混合机制来决定一条信息是否进入长期库。规则层面凡是满足以下条件之一强制提升记忆优先级——包含明确时间/地点的行程安排包含用户偏好我喜欢、我不喜欢、我习惯包含任务状态变化已完成、进行中、失败包含明确的身份信息包含需要后续跟进的事项。模型层面我把当前对话的文本片段和已有的用户画像摘要一起交给一个轻量评分模型让它输出 0 到 1 的重要度得分。通常我会同时要求模型输出“记忆类型”和“触发更新关联的实体 ID”这样一次调用就能同时完成关键信息抽取和重要性判断。提示不要只依赖大模型的“自觉”。规则层可以兜底确保重要事实不会被模型漏掉模型层负责捕捉语义层面的抽象信息。两者配合写入精度才会稳定。3.2 如何从对话流中抽取结构化记忆从对话流中抽记忆本质上是一个信息抽取任务。我建议按以下流程操作把最新一轮用户输入和助手输出拼成一段“候选记忆文本”。调用抽取模型输出一个 JSON 对象包含events、entities、relations、summary四个字段。对抽取结果做合法性校验时间是否正确、实体是否对应已有实体、内容是否与已有记忆重复。如果抽取置信度较低先放入短期缓存如果多轮对话后仍被反复提及再提升到长期库。这里有个很容易踩的坑不要每次对话都立即抽取整段文本。更合理的做法是按“信息块”切分比如以用户每轮完整发言为单位而不是按句子切。因为同一句话里的信息往往是关联的切碎了会丢失上下文。3.3 记忆压缩与反思定期摘要与重写原始记忆会随时间膨胀。就算每条都做过重要性过滤长期运行后还是会累积大量事件记录。Mindbase 借鉴了反思Reflection机制——系统定期对某一主题或某一时间段的记忆做一次压缩生成更高层级的摘要并将冗余的原始事件降权。具体执行时我会设定一个时间触发器每天晚上对当天新增的记忆做一次轻量聚合每周对重点实体相关记忆做一次跨时间线摘要每月做一次全局性的用户画像重写。重写摘要时要注意的一点摘要不能取代原始事件它只是更高层级的索引。如果用户在摘要生成后又问了“我上个月具体哪天说要去的杭州”系统还是要能定位到原始事件。所以摘要和原始事件是共存关系只是在检索排序时会优先使用更具体的命中记录。3.4 冲突检测与新旧记忆合并长期记忆系统最容易被忽略的问题是“记忆冲突”。用户上个月说“我每周三去健身房”这个月说“我换到周末锻炼了”。如果两条记忆同时存在检索时会很困惑。Mindbase 对冲突的处理分为三步检测写入新记忆时先找同一实体下是否存在同类型、但取值不同的记忆。对比比较新旧记忆的时间戳和来源。如果新记忆时间更新通常以新记忆为主旧记忆标记为“历史状态”并降低权重。合并如果冲突不是非此即彼而是条件变化则把条件信息写入原记忆。例如“周末锻炼从某月某日起”这样系统既能理解当前状态也不会丢掉历史变化。这个更新机制很重要。AI 的记忆如果只能增、不能改时间一长就会变成一团互相矛盾的浆糊。我强烈建议在记忆存储层预留valid_from和valid_to两个时间字段而不是简单更新覆盖。4. 检索侧怎么让 AI 在需要时“想起来”4.1 从“一问一查”到多路召回很多初版记忆系统只做一次向量查询把 top 5 结果拼进 Prompt。这种方式在测试环境里看似能跑但真实场景下召回质量非常不稳定。Mindbase 采用了多路召回策略同一时刻分别从不同维度取记忆候选集。典型的三路召回包括语义召回用当前 Query 生成向量从长期库中检索相似度前 20 条。实体召回从当前对话中抽取实体在图谱索引中命中与实体相关的记忆取前 10 条。时间召回检索近期发生的事、最近用户提及的偏好变化取前 10 条。多路召回的目的不是“取并集”而是“别漏掉任何可能性”。召回完再统一做重排保证最终进入 Prompt 的记忆是最有用的。4.2 混合检索排序时间衰减、相关性、重要度召回之后要排序。排序函数里至少包含三项语义相似度、重要度得分、时间衰减系数。时间衰减不能等比例衰减而是按记忆类型区分。行程安排和用户偏好这类信息的半衰期很长三周前的偏好依然值得参考而任务状态类信息半衰期很短三天前的任务状态也可能已经失效。Mindbase 会给每条记忆打上一个decay_rate字段排序时用指数衰减函数计算有效分数。公式可以简单写成score semantic_similarity * 0.6 importance * 0.3 time_decay * 0.1这个权重不是固定的需要在不同业务场景里调。比如做客服机器人时间衰减的权重可以更高做个人助理重要度和语义相似度要更均衡。我实际跑下来最有效的做法是先做一次硬过滤把valid_to早于当前时间、且is_active为假的记忆直接排除再做软排序。硬过滤能避免模型被已失效信息误导。4.3 上下文组装把记忆注入 Prompt 的两种方式记忆不是越多越好注入方式也有讲究。Mindbase 里我主要用两种注入方式第一种是“显式记忆块”。把选中的记忆整理成带编号的文本块放在系统提示词后面像是给模型一份参考资料。这种方式适合需要精确引用记忆的场景比如“以下是关于用户的已知信息1. ... 2. ...”。第二种是“行为约束注入”。不直接给模型罗列记忆而是把记忆转化成一两条行为指导比如“用户偏好简洁回答请用不超过三句话回复”。这种方式适合程序性记忆和偏好类记忆因为它让模型直接执行而不是做信息拼接。在实际系统中我会混合使用事实类记忆用显式块偏好类和行为类记忆用约束注入。这样能避免 Prompt 里出现一长串无用的“记忆”也更容易控制输出风格。4.4 记忆上限与滑动窗口的取舍即使有了长期库每次对话能携带的记忆上下文仍有上限。Mindbase 的策略是设定一个“记忆预算”比如每次最多注入 12 条记忆超过的部分宁可不注入也不能强行塞进 Prompt。预算怎么分配我通常按比例分配语义命中的 top 5、实体命中的 top 5、时间命中的 top 2。这个比例可以根据对话阶段动态调整如果用户在询问过去的细节实体和时间命中的比例上调如果用户在表达新需求语义命中的比例上调。这里有个很实际的经验不要试图在每轮对话都带上完整的用户画像。用户画像只适合在“需要连续身份感”的场景中注入比如长期陪伴型对话或角色扮演在单次任务型问答中清晰的任务指令比画像重要得多。5. 实际跑通过程中踩过的坑5.1 记忆重复与冗余最常遇到的问题是记忆库在几周后出现大量重复。用户可能用不同的表达方式讲过同一件事比如“我下周去上海”“下周三我要出差去上海”“上海出差周三出发”。如果没有去重这三条会被当成三条记忆检索时全被召回既浪费 token又让模型困惑。解决办法是写入阶段做一轮语义相似度去重新记忆生成后先在已有记忆中找同一实体下相似度超过阈值的候选如果存在就把新信息合并进旧记忆而不是新增一条。这个阈值我一般设得比较保守比如 0.86 以上才合并避免误伤真正的新事件。5.2 幻觉式记忆污染记忆系统最大的风险不是记不住而是记错。模型在抽取信息时可能“脑补”出用户没说过的话比如把助手的表述当成用户偏好存下来。这种幻觉一旦进入长期库会污染后续所有对话。我后来加了两道防线第一道是抽取阶段只允许从“用户侧输入”抽取强偏好信息助手侧内容只能作为补充背景第二道是写入长期库之前增加一次“事实一致性校验”的调用让模型对比原始输入和抽取结果打出一个一致性分数低于阈值就降权到短期缓存。这道防线能把大部分幻觉式记忆拦截在长期库之外。5.3 隐私与删除控制长期记忆系统天然涉及用户隐私所以删除能力必须从一开始就设计好而不是后期补丁。Mindbase 里每条记忆都有user_id和source_event_id字段支持按会话、按时间范围、按实体维度做级联删除。另外一个容易被忽视的点用户明确提出“不要记住某件事”时系统需要在记忆库中标记删除之外还要把已经聚合到摘要里的相关内容一并剔除。如果摘要里残留旧信息即使原始记忆删了模型还是可能从摘要中“想起来”。所以我给摘要也加了溯源列表删除时会沿溯源链反向清理。5.4 评估怎么知道记忆系统做得“好”长期记忆系统不像普通模型指标那样好评估。我用的最有效的方法是“记忆问答评测集”——构造一组只有靠长期记忆才能回答的问题比如“用户上周说过最想去的城市是哪里”“用户对项目管理工具的最新偏好是什么”。然后跑一轮完整的对话和检索流程计算回答准确率和命中记忆的准确率。除了离线评测线上还要看三个辅助指标记忆写入率每轮对话平均写入几条、记忆召回利用率注入 Prompt 的记忆中被模型实际引用的比例、用户主动修正次数用户是否经常纠正 AI 的错误记忆。这三个指标能反映记忆系统是否“既不过度打扰又真正有用”。6. 常见问题速查与下一步扩展6.1 长期记忆系统常见问题速查问题可能原因建议处理方式模型总是用旧记忆回答新问题时间衰减权重太低或失效记忆未硬过滤检查valid_to字段强制过期记忆不参与排序记忆内容琐碎、不聚焦写入闸门太松调高重要度阈值强化规则层过滤用户明确说“不是这样”冲突检测没生效或摘要残留旧信息检查摘要溯源链及时更新冲突记忆状态记忆库越来越大但命中率降低缺少定期摘要和降权增加每日/每周压缩任务降低冗余事件权重检索结果看起来相关但不解决当前问题只做向量召回缺少行为类约束切换一部分预算给程序性记忆和用户偏好约束6.2 后续可以做的扩展方向Mindbase 目前的基础框架已经能把长期记忆跑通但还有几个方向可以继续深化多模态记忆不只是文本还可以把图片、语音、操作记录纳入记忆单元。很多用户偏好是藏在非文本行为里的。跨设备同步长期记忆如果只存在单机环境价值会受限。设计成云端同步后AI 助手才能在不同场景中保持一致的记忆。主动记忆目前记忆是被动写入和被动检索的。更进阶的玩法是让 AI 在某些场景下主动向用户确认“这个问题涉及你上周说的项目需要我调出当时的细节吗”这会大幅提升用户对记忆系统的信任。记忆可视化做一个记忆面板让用户能查看 AI 记住了什么、修改或删除特定记忆。这既是产品功能也是一种透明化治理手段。6.3 我个人的实操心得设计长期记忆系统时我最大的体会是不要一上来就追求“完美记忆”先跑通最小闭环。把“写入什么、存成什么、怎么拿出来”这三个问题想清楚比堆一堆高级算法重要得多。另外记忆系统不是一个一次就能建成的模块它需要持续调优。每次发现模型因为记忆出错都要能回溯到“是写入错了、检索错了还是更新策略错了”这三条链路中的哪一环。把这三条链路的日志打通排障效率会高很多。如果你也准备给你的 AI 加长期记忆建议先从最简单的分层存储和重要度过滤开始跑通一轮完整对话再逐步加入摘要、冲突检测和知识图谱索引。长期记忆的最终目标不是“记得多”而是“在关键的时候想起来刚刚好”。
