聊到 AI 应用最常被人吐槽的一点就是没有记性。你和它聊过的事情过几天再问它一脸茫然同一个用户的偏好换个会话就完全归零Agent 执行到一半前面刚确认过的信息转头就忘。这些问题我前后折腾了很久直到后来基于 OpenViking 搭了一套长期记忆系统才算是真正把记忆这件事落到实处。这篇就分享一下我的完整思路和踩坑过程给同样在做 AI 应用、AI Agent 或者个性化对话系统的同学一个可直接参考的落地样本。先交代一下背景OpenViking 是一个偏底层的记忆编排框架核心思路是把记忆从聊天窗口的历史记录中解放出来变成一套可存储、可检索、可更新的独立系统。我拿它做的是面向 AI 对话助手的长期记忆层目标是让机器人能记住用户说过的话、表现出的偏好、历史决策过程并且在后续对话中自动调用这些信息。整个项目跑通了之后对话的连续性和个性化程度提升非常明显而且这套设计方案不绑定具体的大模型供应商换成不同的底座模型都能复用。如果你也在做 AI 助手、个人知识库、Agent 或多轮对话系统正被上下文窗口塞不下模型总是忘记用户偏好这类问题折磨这篇文章值得认真看完。1. 整体设计拆解先想清楚记忆系统要解决什么问题1.1 我遇到的应用瓶颈一开始我做 AI 助手的时候用的还是最朴素的办法把整段对话历史直接拼进 Prompt 里发给模型。试过几种方案窗口长度拉满、只保留最近 N 轮、把超长历史做摘要。效果都一言难尽。窗口长度拉满的问题最直接模型上下文越长单次请求的延迟和成本涨得越快。而且很多场景下真正有用的信息可能只占历史里的很小一部分全量塞进去反而稀释了重点。只保留最近 N 轮就更粗糙了用户一周前来问过的技术方案、表达过的偏好全都丢光。做摘要虽然能缓解一部分但摘要属于压缩压缩必然有损而且摘要丢失的是细节比如用户当时给过的具体数字、明确表达过的排斥项这些恰恰不能丢。1.2 OpenViking 解决这个问题的路子OpenViking 给我的启发在于它把记忆当成一个独立于模型调用的基础设施来设计而不是把希望都押在 Prompt 上。记忆系统的职责是在合适的时机把合适的历史信息捞出来重新组织成模型能直接使用的上下文。这听起来有点像现在常说的 RAG但比 RAG 更进一步。RAG 大多数时候只是从文档库里做语义检索关心的是哪个片段和当前问题相关。而长期记忆系统还要处理另外几个维度这条记忆是谁的什么时候发生的重要性有多高是否需要更新或覆盖以及在当前对话里以什么身份出现。想清楚这些之后我确定了记忆系统的四个核心模块。一是记忆的采集从用户消息中提取值得记住的内容二是记忆的存储把结构化事实和语义向量分开管理三是记忆的检索根据当前对话上下文召回相关的历史记忆四是记忆的组织把召回结果编排成模型友好的上下文块。OpenViking 本身提供了前三块的基础能力第四块需要结合自己的业务场景来调。1.3 选型背后的关键取舍这套方案里最核心的取舍是不要试图记住所有东西。一开始我踩过一个误区想把用户说的每句话都存下来结果存储膨胀得很快检索质量也急剧下降因为无关信息把真正重要的记忆稀释了。后来学乖了记忆系统的核心能力不是存储而是筛选和遗忘。还有一个重要的取舍是冷热分离。高频使用的用户偏好、身份信息属于热记忆几乎每次对话都要用到应该放在能快速读取的位置。低频但重要的历史事件比如用户两个月前提过的一个项目背景属于冷记忆只有在相关话题出现时才需要被召回。OpenViking 的存储分层设计让我可以很方便地做这个区分热记忆走快速查询冷记忆靠向量检索互不干扰。2. 记忆的分层模型与数据生命周期2.1 四层记忆结构在实际搭建时我把记忆分成了四层第一层是身份记忆记录用户是谁包括称呼、职业背景、技术栈偏好、沟通风格。这层信息变化频率极低但每次对话几乎都要用到。第二层是事实记忆记录用户明确说过的、结论性的信息比如我们团队用的是 Java 17 和 Spring Boot服务器是 4C8G 的配置跑不动大模型。这层信息的特征是明确、稳定、可以直接引用的硬事实。第三层是语义记忆记录从对话中提炼出的、带有上下文背景的完整事件或决策过程。比如用户说过上个月我们把推荐服务从单机版迁移到了集群版因为 QPS 涨到 2000 之后单机扛不住了这是一个完整的事件描述里面既有事实也有原因。第四层是工作记忆也就是当前会话中产生、但还没固化到长期记忆里的临时信息。比如用户正在让你帮忙调试一段代码中间提到的临时变量名、局部约束这些属于工作记忆会话结束之后大部分应该被清空只有少数值得沉淀的才提升到长期记忆。2.2 记忆的写入与提炼OpenViking 在这块提供一个很有意思的机制记忆不是原样写入的而是经过一次提炼再写入。我刚开始不太理解为什么要多此一举直接把用户原话存进去不就行了吗后来实测发现差别很大。用户原话往往带着大量噪音。比如用户说我之前部署那台服务器的时候Ubuntu 20.04后来又换成 22.04Nginx 配置折腾了半天如果原样存下来检索时很难命中因为这句话的核心可检索信息散落在多个片段里。经过提炼之后系统会抽出结构化条目服务器系统从 Ubuntu 20.04 迁移到 22.04遇到 Nginx 配置问题。这样一条干净的记录丢进向量库召回效果和原话比完全不在一个量级。提炼的过程我采用的是大模型异步抽取对话结束之后后台跑一个轻量任务把新增对话交给模型做信息抽取抽出来的结构化结果写入记忆库。这里要特别注意一点提炼任务必须设计成幂等的否则同一段对话被重复处理后会产生重复记忆。我后来在存储层加了一个基于对话 ID 去重的机制同一轮的提炼结果只允许写入一次。2.3 记忆的遗忘与冲突处理遗忘机制是我一开始几乎忽略掉、后来发现极其重要的一块。没有遗忘机制的记忆系统会越跑越臃肿检索噪声越来越大。OpenViking 里有一套时间衰减策略每条记忆有一个时间戳和重要度评分超过一定时间没有被命中的记忆重要度会自动下调下调到阈值以下之后就进入归档区不再参与默认检索。如果后续又有相关内容出现归档区的内容可以被重新激活复活。这个设计很像人脑的记忆机制不常用的记忆会模糊但不会彻底消失一旦相关线索出现又能想起来。冲突处理也值得一提。用户可能今天说我平时都用 VS Code 写代码过两周又说最近换了 Cursor感觉 AI 辅助更强。如果系统只做简单的覆盖旧记录直接删了那将来用户偶尔提起某个在 VS Code 时代完成的项目系统就缺少了背景信息。我的做法是保留版本链同一条记忆的多个版本按时间排列检索时优先取最新版本但旧版本作为上下文背景仍然可查。这样既尊重了用户的当前状态又不丢失历史脉络。3. 实操搭建核心实现与关键参数3.1 系统整体架构整个系统的模块划分大概是这样的对话入口 → 前置记忆加载 → 模型推理 → 后置记忆提炼 → 记忆存储 ↑ | └────────── 工作记忆区 ←────────┘前置记忆加载发生在模型调用之前。用户的当前消息进来之后系统先抽取这条消息的关键要素然后去记忆库检索相关的历史记忆把命中的记忆拼进系统提示词里。后置记忆提炼发生在模型返回之后系统分析这一轮对话有没有值得沉淀的新信息如果有就交给提炼任务处理。这两个环节一前一后前置决定模型能用到什么上下文后置决定系统能记住什么新内容缺一不可。3.2 记忆表的存储结构设计我采用的是关系型数据库加向量库的混合存储。结构化记忆身份、事实、事件放在关系表里每条记录带一个向量 ID语义向量存在向量库里。两张表通过一个全局记忆 ID 关联。记忆主表的核心字段字段类型说明memory_idstring全局唯一记忆 IDuser_idstring归属用户memory_typeenum身份/事实/语义/工作contenttext记忆的规范化文本importancefloat重要度0-1hit_countint被检索命中次数last_access_atdatetime最近一次被访问时间versionint版本号冲突更新时递增expired_atdatetime遗忘触发节点其中 importance 和 last_access_at 就是 2.3 节提到的衰减机制的数据基础。每次检索命中时hit_count 加一last_access_at 刷新。系统后台每六个小时跑一次衰减任务把长时间未被访问的记忆的 importance 乘一个小于 1 的衰减因子。3.3 记忆写入流程的关键配置记忆写入的完整链路是新对话产生后先判断是否有延续性。如果当前话题能匹配到已有的记忆条目就走更新路径在原记录上追加新信息并提升版本号。如果匹配不到就走新建路径创建一条新的记忆记录。这里有一个参数很关键匹配阈值。我在实验中发现阈值设得太高会导致更新永远匹配不到旧记忆用户改了个说法就变成两条独立记录设得太低会把不相关的记忆错误关联造成信息串味。我最终把这个参数设为两段制记忆标题匹配用较高的相似度阈值落在 0.86 左右记忆内容语义匹配用稍低的阈值0.78 左右。这样既避免误合并也能容忍用户口语化表达带来的措辞差异。3.4 检索模块的 Top-K 调优过程检索模块直接决定了模型能看到哪些历史记忆是整套系统里对效果影响最大的参数。Top-K 选多少我需要解释一下这个权衡Top-K 设得太小比如只有 3容易漏掉重要的背景信息。用户问之前说的那个方案现在有更好的替代吗如果只召回最近三条记忆很可能没有包含上次讨论方案时的完整背景。Top-K 设得太大比如 20又会把无关的记忆塞进上下文模型面对大量噪音信息时反而容易忽略真正重要的那部分。而且每次请求付出的向量检索时间也在涨。我反复测试后把默认值固定在 8同时加了一个动态调整规则如果用户当前消息属于复杂推理类比如要求做方案对比系统会把召回量上调到 12 到 15如果是简单的问答或闲聊8 条够用如果消息里带有明确否定词比如不要考虑云端方案了会自动增加一条针对排斥项的专项检索。这个规则我是在实际使用中被逼出来的没有这个设计模型经常无视用户新表达的否定意思继续引用旧的推荐方案。3.5 一个最小可运行的检索示例检索这一环用伪代码描述大概是这样的逻辑def recall_memories(user_message, user_id, top_k8): # 1. 从消息中提取查询要素 query_vec embed(user_message) # 2. 组装过滤条件只看当前用户、未过期的记忆 filters { user_id: user_id, expired: False } # 3. 执行混合检索结构化标签过滤 语义向量排序 candidates vector_db.search( query_vec, filtersfilters, top_ktop_k * 2 # 先多召回一些候选 ) # 4. 重要的最后一道关卡精排去重 ranked rerank_by_importance(candidates) # 5. 同主题的记忆合并成段落避免零散 merged merge_related_memories(ranked) return merged[:top_k]这里的前 4 步都好理解重点说说第 5 步合并。如果不做合并召回结果可能有三四条都是围绕服务器迁移这件事的不同片段它们单独看都是有效的塞进上下文里却显得重复啰唆。合并之后系统会把同一主题的多条记录拼接成一段带时间顺序的完整描述模型读起来更顺生成质量也会提升。3.6 记忆注入 Prompt 的模板结构记忆召回到手之后喂给模型的方式也有讲究。我的 Prompt 里专门划出了一块历史记忆区放在用户消息之前用清晰的标记和当前对话区分开。[以下是关于用户的长期记忆基于这些信息来优化你的回复] 1. [2025-06-12] 用户偏好后端技术栈为 Java 17 Spring Boot不喜欢 Python 写业务服务 2. [2025-06-20] 用户环境服务器为 4C8G无法本地运行大模型依赖外部 API 3. [2025-07-01] 项目背景推荐服务因 QPS 2000 从单机迁移到集群 [当前对话开始] 用户帮我评估一下这个服务端 SDK 的选型这样一个结构比把记忆夹杂在对话历史里要清晰得多模型能够明确区分这是系统提供的用户背景和这是用户本次实际说的话不会混淆信息来源。我在括号前面会记得标注记忆产生的时间这对模型理解用户状态的演变有很重要的帮助。4. 结合 Agent 场景记忆如何参与复杂任务的推理与执行4.1 让 Agent 拥有跨会话的任务状态聊到 Agent 场景记忆系统要面临一个比普通对话更复杂的问题。Agent 的执行链条很长中间涉及工具调用、子任务拆分、结果评估每一步都产生中间状态。如果这些状态不能跨会话保留任务一旦中断下次继续时 Agent 就完全失忆了只能从头开始。我在项目里验证了一个思路把 Agent 的执行计划、已完成步骤、关键中间结论都同步写进记忆库并打上 task_id 标签。这样 Agent 每推进一个子任务记忆里就多一条带任务上下文的记录。如果用户中途关掉对话第二天回来说继续昨天的任务系统能通过 task_id 召回整个执行脉络Agent 可以从断点继续而不是推倒重来。4.2 记忆与 Agent 推理的协同机制这里有一个很容易踩的坑就是记忆召回的结果直接当系统提示词丢给 Agent然后期待 Agent 自己聪明的利用。实际上 Agent 同样面临信息过载的问题给得太多反而影响它的规划能力。我的调优方式是给记忆区分必须遵守型和参考了解型。必须遵守型记忆往往是用户的明确约束比如不用考虑 PHP 方案生产环境只能用内网部署这些要以较硬的语气注入提示词告诉模型这是硬性约束。参考了解型记忆属于背景信息比如用户过往的项目经验只作为辅助参考Agent 在执行时可以根据情况弹性使用。区分了这两类之后Agent 在长链路执行时踩用户明确禁忌的次数大幅下降。之前它经常会在某个环节突然提出一个用户早就排除过的方案原因就是这个排除项没有进入检索结果或者虽然进入了但没有被强制标记。4.3 工具调用记忆的沉淀与复用Agent 场景里还有一类特殊的记忆值得沉淀工具调用的经验。比如用户同一个场景下反复让 Agent 调用某套 APIAPI 的认证方式、参数格式、常见报错处理这些信息每次都要临时摸索就很浪费。我的做法是把每次成功的工具调用抽象成一条程序性记忆记录调用的场景特征、入参出参、成功标志。积累到一定量之后新任务到达时先做一次工具记忆匹配如果命中相似度足够高的历史调用经验Agent 可以直接复用之前的参数模板省掉大量试错时间。这个功能的体验很神奇跑上一段时间之后Agent 会越来越熟练用户明显能感觉到它好像越来越懂我。5. 常见问题与排查技巧实录5.1 检索结果经常不相关这是我上线初期最大的困扰。查了半天发现问题出在查询向量的构造上。用户当前消息往往很短比如那个项目后来怎么样了单独拿这句话去做向量化再检索得到的语义向量信息量太少召回质量自然差。解决办法是做一个查询改写在发起检索之前先汇总当前会话已有的上下文生成一个信息量更丰富的查询表述。以上面为例改写后的查询就是用户之前提到的那个项目当前进展如何背景是推荐服务集群化迁移。改写后的查询向量包含的信息量完全不同召回效果提升立竿见影。5.2 记忆重复写入导致存储膨胀这个问题在前面提到过但它的隐蔽性比想象中更强。即使加了对话 ID 去重还是有漏网之鱼。后来定位到原因是提炼任务里的模型调用存在不确定性同一段对话两次提炼产出的文本措辞不同导致去重机制无法通过文本比对识别。后面我换了一种策略去重不再比对提炼后的全文而是比对记忆的核心要素哈希也就是主语加谓语加关键宾语的组合哈希。同一个语义事实即使换了一种说法核心要素是稳定的哈希值也会相同就能被正确识别并合并。这个修好之后同一用户重复记忆的增长率基本降到了零附近。5.3 新旧记忆冲突时模型选错版本用过一段时间后我发现有时候模型引用的还是用户的旧偏好。排查下来是版本链的过滤条件写错了检索时没有强制限定只取最新版本结果把过期信息也返回了。修正方案是两条腿走路。在存储层每次写入新版本时给旧版本打上 superseded 标记默认检索只查未过期的版本。在提示词层面如果某条记忆确实存在版本更新我会主动向模型暴露这个变化过程让模型了解用户偏好发生过转变这在处理用户想法变了这种场景时特别有用。5.4 冷启动期记忆库是空的新用户刚接入时没有任何历史记忆记忆系统的存在感和没有差不多。这个阶段如果什么都不做用户感知不到这个助手有记忆。我在种子记忆上做了一些设计方便冷启动用户首次授权后通过引导式提问让用户快速提供一些基础背景比如擅长的领域、常用的工具链、当前关注的方向。这些回答经过提炼后生成一批高质量初始记忆后续对话的个性化能力立刻就有了不用等系统慢慢积累。还有个实用技巧是在第一轮对话给模型一段提示告诉它当前用户还没有足够的历史记忆在合适的时候可以自然地询问用户偏好而不是生硬地问。这个小细节对用户体验帮助很明显。6. 经验总结与扩展思考6.1 项目整体收益整个项目跑下来我自己的体会是记忆系统的价值不是单点功能能衡量的。它带来的最直接的改善是对话连续性用户不用每次重复背景感觉上这个助手记得我。从更长期来看记忆数据的积累其实就是产品最深的壁垒模型可以换、Prompt 可以调但是这些经过长期沉淀的用户记忆数据是别人拿不走的资产。从工程角度看这套基于 OpenViking 的方案模块边界清晰每一块都能独立测试和替换。将来如果换向量库、换底层模型对记忆系统本身的冲击都很小。6.2 踩坑之后的几点心得体会写到最后分享几条我个人的经验都是真金白银踩出来的别把记忆系统和数据库直接画等号它更像是一套有生命周期的数据治理系统建立合适的遗忘机制和版本管理机制才能长久运行。如果希望优化记忆系统建议先花时间定义清楚什么是值得记住的用一个星期手工标注真实对话把高频出现的信息类型找出来再按这些类型设计提炼规则。记忆的召回质量更多地依赖于查询改写和精排设计而不是单纯增加 Top-K 的数值。我在从 8 调到 20 的过程中召回效果并没有因此变好反而更差了。想继续扩展的话可以考虑在记忆系统里加入用户反馈闭环也就是让用户对记忆进行显式的确认、修改和删除。这个功能看似简单但它一方面能大幅提高记忆质量另一方面也给了用户掌控感消除了隐私层面的顾虑。我下一步正打算往这个方向继续完善。