1. 项目缘起与核心定位第一次看到“claude-mem”这个命名我的直觉是这大概率是一个围绕对话记忆管理的工具或中间件。名字里的“mem”几乎可以确定是 memory 的缩写而前缀指向的是对话式 AI 场景。把这两个词拼在一起指向的需求非常明确——让 AI 对话拥有可持久化、可检索、可复用的记忆能力。做过对话类产品的人都知道一个痛点每次开启新会话模型就像失忆一样之前聊过的偏好、上下文、结论全部归零。用户不得不反复重复“我是做后端的”“上次说的那个方案继续往下讲”“别用那种风格回答我”。这种体验在单次问答里还能忍一旦进入长期协作场景比如持续几周的项目讨论、个人知识管理、客服工单跟进重复交代背景的成本就会迅速累积甚至直接劝退用户。claude-mem 要解决的就是这件事。它本质上是一层记忆管理层夹在用户和对话模型之间负责把值得留存的信息抽取出来、结构化存储、在后续对话中按需召回并注入上下文。它不是一个模型也不是一个单纯的数据库而是一套“写入—存储—检索—注入”的完整链路。适合谁来参考这篇内容三类人最相关。第一类是正在做 AI 应用、需要给产品加“长期记忆”能力的开发者第二类是对上下文工程、RAG 检索增强感兴趣的技术人第三类是产品经理或独立开发者想理解记忆机制到底怎么落地、坑在哪里。哪怕你只是好奇“AI 记忆”这件事在工程上长什么样这篇也能给你一个可复现的轮廓。需要提前说明的是下面涉及的具体实现细节是基于这类记忆系统常见工程实践做的合理补全因为原始信息只给了一个标题。我会把“为什么这么设计”讲透让你拿到的是方法论和可抄的作业而不是一堆无法验证的断言。2. 记忆系统的整体架构拆解2.1 为什么不能只靠“把历史全塞进上下文”最朴素的做法是把所有历史对话拼成一个超长 prompt 丢给模型。这个方案在小规模下能跑但很快会撞上三堵墙。第一堵是上下文窗口的物理上限。即便窗口开到很大token 成本也是线性甚至超线性增长的长期对话的账单会失控。第二堵是信噪比问题。历史里大量寒暄、试错、废弃方案会稀释真正有用的信息模型注意力被无关内容分散回答质量反而下降。第三堵是检索精度。全量塞入等于没有筛选模型无法判断哪条信息当前有效容易引用过时结论。所以 claude-mem 这类系统的核心思路一定是不是记住所有而是记住该记的并在需要时精准取回。这就把问题拆成了三个子问题——写什么、怎么存、怎么取。2.2 三层结构抽取层、存储层、召回层我理解的 claude-mem 架构可以拆成三层每层职责清晰。抽取层负责从对话流里识别“值得记忆”的片段。不是每句话都值得存比如“好的”“嗯嗯”这种确认性回复就没有存储价值。真正要抓的是用户的稳定偏好“我习惯用 Python”、事实性信息“项目截止日期是下个月”、决策结论“最终选了方案 B”、以及实体关系“A 模块依赖 B 服务”。存储层负责把这些片段结构化。常见做法是存成带元数据的记录内容本身、类型标签、时间戳、来源会话 ID、置信度、以及可选的向量表示。结构化存储的好处是后续既能做精确过滤按类型、按时间又能做语义检索按向量相似度。召回层负责在下一轮对话时根据当前用户输入去存储层里捞相关记忆排序后注入上下文。这里的关键是相关性判断和数量控制——召回太多会挤占窗口召回太少又不够用。提示三层解耦的最大价值在于可替换。抽取策略可以迭代存储后端可以从本地文件换成向量库召回算法可以从关键词升级到混合检索互不影响。2.3 方案选型背后的取舍逻辑为什么倾向于“抽取结构化按需召回”而不是“全量缓存定期摘要”因为两者的成本曲线完全不同。全量缓存加摘要的方案实现简单但摘要是有损压缩一旦摘要丢掉了关键细节后面再也找不回来。而且摘要的触发时机很难把握——太频繁浪费算力太稀疏又积累太多。抽取式方案前期工程量大但一旦跑通记忆的精度和可控性高得多。你可以精确知道系统记住了什么、没记住什么方便调试和纠偏。对于需要长期运行的产品这种可控性是刚需。另一个取舍点是同步还是异步写入。同步写入会让每轮对话都多一次模型调用用于抽取延迟增加异步写入则把抽取放到后台用户无感知但可能丢失“刚刚说完还没入库”的短暂窗口。多数实践会选异步配合一个短期的会话内缓存兜底。3. 核心细节解析与实操要点3.1 记忆抽取怎么判断“这句话值得记”抽取是整个系统的入口抽错了后面全错。我的经验是不要指望一次模型调用就完美分类而是用规则模型的组合。规则层先做粗筛过滤掉明显无价值的短句、纯确认词、重复内容。比如长度低于一定阈值、且不含实体和动词的句子直接跳过。这一步能砍掉大量噪音省下模型调用。模型层再做精判给候选片段打标签。常见的记忆类型我整理成一张表方便对照设计 prompt记忆类型典型触发存储价值示例用户偏好“我喜欢/我习惯/别用”高长期有效偏好简洁回答不要分点事实信息具体数值、日期、名称高需准确项目代号是 X截止 3 月底决策结论“就选/最终定/采用”高覆盖旧决策数据库选型定为 PostgreSQL实体关系“A 依赖 B”“A 属于 B”中高构建知识网订单服务依赖用户服务临时上下文当前任务、当前话题中会话内有效正在调试登录超时问题情绪态度“太烦了/很满意”低到中看场景对某方案明显抵触实操中我会给每条记忆加一个置信度分数低于阈值的先存但标记为“待确认”后续如果被反复引用就提升权重长期不用就降权甚至清理。这样系统能自我进化而不是越存越乱。注意抽取 prompt 里一定要明确“不要存储用户明确要求保密或临时性的内容”否则容易把敏感信息固化下来后续召回时造成尴尬。3.2 存储设计结构化字段怎么定存储层我建议至少包含这些字段缺一个后面都会难受id唯一标识便于更新和删除content记忆正文保持原始表述不要过度改写type上面表格里的类型标签embedding向量表示用于语义检索created_at/updated_at时间戳用于时效性排序source_session来源会话便于追溯confidence置信度access_count被召回次数用于热度加权statusactive / archived / deleted为什么保留原始表述而不是改写因为改写会引入模型幻觉把“用户说大概下周三”改成“截止日期是下周三”一字之差性质就变了。原始表述加类型标签既保真又可用。向量维度选择上常见的中文 embedding 模型输出 768 或 1024 维都够用。维度不是越高越好高维检索慢、存储贵收益边际递减。实测 768 维在多数记忆检索场景下召回质量已经足够。3.3 召回策略相关性、时效性、重要性的三角平衡召回不是简单的“向量相似度 top-k”。我踩过的坑是纯向量检索会把语义相近但已经过时的记忆也捞出来比如用户三个月前说“暂时用 MySQL”后来改成了 PostgreSQL如果只按相似度旧记忆照样排前面。我的做法是混合打分公式大致是score w1 * 语义相似度 w2 * 时效衰减 w3 * 重要性权重其中时效衰减可以用指数衰减比如exp(-λ * 天数)λ 根据业务定偏好类记忆衰减慢临时上下文衰减快。重要性权重可以用access_count和confidence组合。三个权重的调参没有银弹我的经验值是语义相似度占大头0.6 左右时效和重要性各占 0.2然后根据实际召回效果微调。如果发现旧决策总被翻出来就加大时效权重如果发现重要偏好总被漏掉就加大重要性权重。召回数量上我一般控制在 3 到 8 条。太少覆盖不足太多稀释注意力。可以设一个动态上限当前对话越短召回越少对话越长说明话题深入可以多召回几条。4. 实操过程与核心环节实现4.1 环境与依赖准备假设用 Python 实现一个最小可用的 claude-mem 原型依赖大致如下pip install openai numpy faiss-cpu tiktoken这里用faiss-cpu做向量检索轻量且够用tiktoken用于估算 token 数控制注入量对话模型和 embedding 模型按你实际可用的接口替换。如果记忆量很大可以把 faiss 换成更完整的向量库但原型阶段没必要。目录结构我习惯这样组织claude_mem/ extractor.py # 抽取逻辑 store.py # 存储与检索 recall.py # 召回与打分 memory.json # 简易持久化原型用原型阶段用 JSON 文件存记忆完全够用别一上来就上数据库增加调试成本。等逻辑跑通、记忆量上千条再迁移。4.2 抽取环节的代码骨架抽取的核心是一次模型调用把对话片段转成结构化记忆。prompt 设计是关键我给一个可参考的模板思路EXTRACT_PROMPT 从下面的对话片段中抽取值得长期记忆的信息。 只抽取以下类型用户偏好、事实信息、决策结论、实体关系。 每条记忆输出 JSON{content, type, confidence} 如果没有值得记忆的内容返回空数组。 不要改写原意保持原始表述。 对话片段 {dialog} 调用后解析 JSON过滤掉 confidence 低于 0.5 的剩下的写入存储。这里有个细节批量抽取比逐句抽取效率高。可以把最近 N 轮对话攒一批再抽减少调用次数。实操心得抽取 prompt 里加一句“如果信息与已有记忆冲突标注为 update 类型”能让后续的更新逻辑简单很多。否则新旧记忆会同时存在召回时自相矛盾。4.3 存储与向量化的落地存储环节把抽取结果落盘同时生成 embedding。代码骨架大致是def add_memory(content, mtype, confidence): emb get_embedding(content) record { id: gen_id(), content: content, type: mtype, embedding: emb, confidence: confidence, created_at: now(), access_count: 0, status: active } save(record) index.add(emb, record[id])向量索引和结构化存储分开维护检索时先向量召回候选再用结构化字段做过滤和重排。这种“粗召回精排”的两段式比一次性做完所有判断要快得多。参数上向量召回候选数我一般设成最终召回数的 3 到 5 倍。比如最终要 5 条就先召回 15 到 25 条候选再精排。这样既保证召回率又控制精排成本。4.4 召回注入的完整流程召回发生在每轮对话开始前。流程是拿用户当前输入生成 embedding向量检索候选混合打分排序取 top-k拼成一段“记忆上下文”注入到系统 prompt 里。注入格式我建议明确标注让模型知道这是记忆而非当前指令[相关记忆] - (偏好) 用户喜欢简洁回答不要分点 - (事实) 项目代号 X截止 3 月底 - (决策) 数据库选型定为 PostgreSQL这样模型能区分“记忆”和“当前问题”避免把记忆当成新指令执行。注入后记得更新被召回记忆的access_count为后续重要性加权提供数据。整个链路跑通后你会明显感觉到对话的“连续性”上来了——用户不用重复背景模型能接住几周前的结论。这种体验提升是质变的。5. 常见问题与排查技巧实录5.1 记忆越存越多、召回越来越乱这是最常见的翻车点。根因是缺少清理和合并机制。我的解法是三条一是定期归档长期未召回的低置信度记忆二是对同类型同主题的记忆做合并比如用户三次说“喜欢简洁”合并成一条并提升权重三是设置硬上限超过阈值就触发清理。合并逻辑可以用向量相似度判断相似度高于 0.9 的两条同类型记忆大概率是重复合并保留最新表述。5.2 旧决策覆盖新决策失败用户改了主意但旧记忆还在召回。解法是在抽取阶段识别“更新”意图写入时把旧记忆标记为 archived新记忆标记为 active。召回时只取 active。如果抽取阶段没识别出来可以在召回精排时对同主题记忆做时间排序只保留最新的。5.3 召回的记忆和当前话题不相关多半是纯向量检索的锅。语义相似不等于场景相关。解法是加入类型过滤和会话过滤当前话题是技术讨论就优先召回技术类记忆当前会话有明确主题就优先召回同主题记忆。混合打分里的语义权重可以适当降低给类型匹配留出空间。5.4 常见问题速查表现象可能原因排查方向解决思路记忆不生效抽取漏了 / 召回没命中看存储里有没有 / 看召回分数调抽取 prompt / 调召回权重记忆自相矛盾旧记忆未归档检查同主题记忆状态加更新识别与归档逻辑召回太慢候选太多 / 向量库没索引看候选数和检索耗时减少候选 / 建 ANN 索引注入后回答变差记忆太多稀释注意力看注入 token 占比减少召回数 / 提高精排阈值敏感信息被召回抽取没过滤检查抽取规则加敏感词与保密标记过滤避坑技巧上线前一定要做一轮“记忆审计”人工抽查存储里的记忆看看有没有抽错的、过时的、敏感的。这一步能提前发现 80% 的线上问题。6. 记忆系统的扩展方向跑通基础版之后有几个方向值得继续深挖。一是记忆分层把短期会话记忆和长期用户记忆分开管理短期用滑动窗口长期用结构化存储召回时按需融合。二是记忆图谱把实体关系类记忆连成图支持多跳推理比如“A 依赖 BB 依赖 C”能推出 A 间接依赖 C。三是主动记忆不等用户说系统主动从行为里推断偏好比如用户每次都跳过某类回答就自动降低该类内容的权重。这些扩展不必一次做完按业务需要逐步加。我的建议是先把“抽取—存储—召回”这条主链路打磨稳定再考虑花活。主链路不稳加再多功能都是空中楼阁。我个人在实际操作中的体会是记忆系统的难点从来不在技术选型而在对“什么值得记”的判断。这个判断没有标准答案只能靠不断观察真实对话、调整抽取策略来逼近。每次调完抽取 prompt我都会拿一批真实对话回放一遍看新策略多抽了什么、漏了什么慢慢就摸到感觉了。
1. 项目缘起与核心定位第一次看到“claude-mem”这个命名我的直觉是这大概率是一个围绕对话记忆管理的工具或中间件。名字里的“mem”几乎可以确定是 memory 的缩写而前缀指向的是对话式 AI 场景。把这两个词拼在一起指向的需求非常明确——让 AI 对话拥有可持久化、可检索、可复用的记忆能力。做过对话类产品的人都知道一个痛点每次开启新会话模型就像失忆一样之前聊过的偏好、上下文、结论全部归零。用户不得不反复重复“我是做后端的”“上次说的那个方案继续往下讲”“别用那种风格回答我”。这种体验在单次问答里还能忍一旦进入长期协作场景比如持续几周的项目讨论、个人知识管理、客服工单跟进重复交代背景的成本就会迅速累积甚至直接劝退用户。claude-mem 要解决的就是这件事。它本质上是一层记忆管理层夹在用户和对话模型之间负责把值得留存的信息抽取出来、结构化存储、在后续对话中按需召回并注入上下文。它不是一个模型也不是一个单纯的数据库而是一套“写入—存储—检索—注入”的完整链路。适合谁来参考这篇内容三类人最相关。第一类是正在做 AI 应用、需要给产品加“长期记忆”能力的开发者第二类是对上下文工程、RAG 检索增强感兴趣的技术人第三类是产品经理或独立开发者想理解记忆机制到底怎么落地、坑在哪里。哪怕你只是好奇“AI 记忆”这件事在工程上长什么样这篇也能给你一个可复现的轮廓。需要提前说明的是下面涉及的具体实现细节是基于这类记忆系统常见工程实践做的合理补全因为原始信息只给了一个标题。我会把“为什么这么设计”讲透让你拿到的是方法论和可抄的作业而不是一堆无法验证的断言。2. 记忆系统的整体架构拆解2.1 为什么不能只靠“把历史全塞进上下文”最朴素的做法是把所有历史对话拼成一个超长 prompt 丢给模型。这个方案在小规模下能跑但很快会撞上三堵墙。第一堵是上下文窗口的物理上限。即便窗口开到很大token 成本也是线性甚至超线性增长的长期对话的账单会失控。第二堵是信噪比问题。历史里大量寒暄、试错、废弃方案会稀释真正有用的信息模型注意力被无关内容分散回答质量反而下降。第三堵是检索精度。全量塞入等于没有筛选模型无法判断哪条信息当前有效容易引用过时结论。所以 claude-mem 这类系统的核心思路一定是不是记住所有而是记住该记的并在需要时精准取回。这就把问题拆成了三个子问题——写什么、怎么存、怎么取。2.2 三层结构抽取层、存储层、召回层我理解的 claude-mem 架构可以拆成三层每层职责清晰。抽取层负责从对话流里识别“值得记忆”的片段。不是每句话都值得存比如“好的”“嗯嗯”这种确认性回复就没有存储价值。真正要抓的是用户的稳定偏好“我习惯用 Python”、事实性信息“项目截止日期是下个月”、决策结论“最终选了方案 B”、以及实体关系“A 模块依赖 B 服务”。存储层负责把这些片段结构化。常见做法是存成带元数据的记录内容本身、类型标签、时间戳、来源会话 ID、置信度、以及可选的向量表示。结构化存储的好处是后续既能做精确过滤按类型、按时间又能做语义检索按向量相似度。召回层负责在下一轮对话时根据当前用户输入去存储层里捞相关记忆排序后注入上下文。这里的关键是相关性判断和数量控制——召回太多会挤占窗口召回太少又不够用。提示三层解耦的最大价值在于可替换。抽取策略可以迭代存储后端可以从本地文件换成向量库召回算法可以从关键词升级到混合检索互不影响。2.3 方案选型背后的取舍逻辑为什么倾向于“抽取结构化按需召回”而不是“全量缓存定期摘要”因为两者的成本曲线完全不同。全量缓存加摘要的方案实现简单但摘要是有损压缩一旦摘要丢掉了关键细节后面再也找不回来。而且摘要的触发时机很难把握——太频繁浪费算力太稀疏又积累太多。抽取式方案前期工程量大但一旦跑通记忆的精度和可控性高得多。你可以精确知道系统记住了什么、没记住什么方便调试和纠偏。对于需要长期运行的产品这种可控性是刚需。另一个取舍点是同步还是异步写入。同步写入会让每轮对话都多一次模型调用用于抽取延迟增加异步写入则把抽取放到后台用户无感知但可能丢失“刚刚说完还没入库”的短暂窗口。多数实践会选异步配合一个短期的会话内缓存兜底。3. 核心细节解析与实操要点3.1 记忆抽取怎么判断“这句话值得记”抽取是整个系统的入口抽错了后面全错。我的经验是不要指望一次模型调用就完美分类而是用规则模型的组合。规则层先做粗筛过滤掉明显无价值的短句、纯确认词、重复内容。比如长度低于一定阈值、且不含实体和动词的句子直接跳过。这一步能砍掉大量噪音省下模型调用。模型层再做精判给候选片段打标签。常见的记忆类型我整理成一张表方便对照设计 prompt记忆类型典型触发存储价值示例用户偏好“我喜欢/我习惯/别用”高长期有效偏好简洁回答不要分点事实信息具体数值、日期、名称高需准确项目代号是 X截止 3 月底决策结论“就选/最终定/采用”高覆盖旧决策数据库选型定为 PostgreSQL实体关系“A 依赖 B”“A 属于 B”中高构建知识网订单服务依赖用户服务临时上下文当前任务、当前话题中会话内有效正在调试登录超时问题情绪态度“太烦了/很满意”低到中看场景对某方案明显抵触实操中我会给每条记忆加一个置信度分数低于阈值的先存但标记为“待确认”后续如果被反复引用就提升权重长期不用就降权甚至清理。这样系统能自我进化而不是越存越乱。注意抽取 prompt 里一定要明确“不要存储用户明确要求保密或临时性的内容”否则容易把敏感信息固化下来后续召回时造成尴尬。3.2 存储设计结构化字段怎么定存储层我建议至少包含这些字段缺一个后面都会难受id唯一标识便于更新和删除content记忆正文保持原始表述不要过度改写type上面表格里的类型标签embedding向量表示用于语义检索created_at/updated_at时间戳用于时效性排序source_session来源会话便于追溯confidence置信度access_count被召回次数用于热度加权statusactive / archived / deleted为什么保留原始表述而不是改写因为改写会引入模型幻觉把“用户说大概下周三”改成“截止日期是下周三”一字之差性质就变了。原始表述加类型标签既保真又可用。向量维度选择上常见的中文 embedding 模型输出 768 或 1024 维都够用。维度不是越高越好高维检索慢、存储贵收益边际递减。实测 768 维在多数记忆检索场景下召回质量已经足够。3.3 召回策略相关性、时效性、重要性的三角平衡召回不是简单的“向量相似度 top-k”。我踩过的坑是纯向量检索会把语义相近但已经过时的记忆也捞出来比如用户三个月前说“暂时用 MySQL”后来改成了 PostgreSQL如果只按相似度旧记忆照样排前面。我的做法是混合打分公式大致是score w1 * 语义相似度 w2 * 时效衰减 w3 * 重要性权重其中时效衰减可以用指数衰减比如exp(-λ * 天数)λ 根据业务定偏好类记忆衰减慢临时上下文衰减快。重要性权重可以用access_count和confidence组合。三个权重的调参没有银弹我的经验值是语义相似度占大头0.6 左右时效和重要性各占 0.2然后根据实际召回效果微调。如果发现旧决策总被翻出来就加大时效权重如果发现重要偏好总被漏掉就加大重要性权重。召回数量上我一般控制在 3 到 8 条。太少覆盖不足太多稀释注意力。可以设一个动态上限当前对话越短召回越少对话越长说明话题深入可以多召回几条。4. 实操过程与核心环节实现4.1 环境与依赖准备假设用 Python 实现一个最小可用的 claude-mem 原型依赖大致如下pip install openai numpy faiss-cpu tiktoken这里用faiss-cpu做向量检索轻量且够用tiktoken用于估算 token 数控制注入量对话模型和 embedding 模型按你实际可用的接口替换。如果记忆量很大可以把 faiss 换成更完整的向量库但原型阶段没必要。目录结构我习惯这样组织claude_mem/ extractor.py # 抽取逻辑 store.py # 存储与检索 recall.py # 召回与打分 memory.json # 简易持久化原型用原型阶段用 JSON 文件存记忆完全够用别一上来就上数据库增加调试成本。等逻辑跑通、记忆量上千条再迁移。4.2 抽取环节的代码骨架抽取的核心是一次模型调用把对话片段转成结构化记忆。prompt 设计是关键我给一个可参考的模板思路EXTRACT_PROMPT 从下面的对话片段中抽取值得长期记忆的信息。 只抽取以下类型用户偏好、事实信息、决策结论、实体关系。 每条记忆输出 JSON{content, type, confidence} 如果没有值得记忆的内容返回空数组。 不要改写原意保持原始表述。 对话片段 {dialog} 调用后解析 JSON过滤掉 confidence 低于 0.5 的剩下的写入存储。这里有个细节批量抽取比逐句抽取效率高。可以把最近 N 轮对话攒一批再抽减少调用次数。实操心得抽取 prompt 里加一句“如果信息与已有记忆冲突标注为 update 类型”能让后续的更新逻辑简单很多。否则新旧记忆会同时存在召回时自相矛盾。4.3 存储与向量化的落地存储环节把抽取结果落盘同时生成 embedding。代码骨架大致是def add_memory(content, mtype, confidence): emb get_embedding(content) record { id: gen_id(), content: content, type: mtype, embedding: emb, confidence: confidence, created_at: now(), access_count: 0, status: active } save(record) index.add(emb, record[id])向量索引和结构化存储分开维护检索时先向量召回候选再用结构化字段做过滤和重排。这种“粗召回精排”的两段式比一次性做完所有判断要快得多。参数上向量召回候选数我一般设成最终召回数的 3 到 5 倍。比如最终要 5 条就先召回 15 到 25 条候选再精排。这样既保证召回率又控制精排成本。4.4 召回注入的完整流程召回发生在每轮对话开始前。流程是拿用户当前输入生成 embedding向量检索候选混合打分排序取 top-k拼成一段“记忆上下文”注入到系统 prompt 里。注入格式我建议明确标注让模型知道这是记忆而非当前指令[相关记忆] - (偏好) 用户喜欢简洁回答不要分点 - (事实) 项目代号 X截止 3 月底 - (决策) 数据库选型定为 PostgreSQL这样模型能区分“记忆”和“当前问题”避免把记忆当成新指令执行。注入后记得更新被召回记忆的access_count为后续重要性加权提供数据。整个链路跑通后你会明显感觉到对话的“连续性”上来了——用户不用重复背景模型能接住几周前的结论。这种体验提升是质变的。5. 常见问题与排查技巧实录5.1 记忆越存越多、召回越来越乱这是最常见的翻车点。根因是缺少清理和合并机制。我的解法是三条一是定期归档长期未召回的低置信度记忆二是对同类型同主题的记忆做合并比如用户三次说“喜欢简洁”合并成一条并提升权重三是设置硬上限超过阈值就触发清理。合并逻辑可以用向量相似度判断相似度高于 0.9 的两条同类型记忆大概率是重复合并保留最新表述。5.2 旧决策覆盖新决策失败用户改了主意但旧记忆还在召回。解法是在抽取阶段识别“更新”意图写入时把旧记忆标记为 archived新记忆标记为 active。召回时只取 active。如果抽取阶段没识别出来可以在召回精排时对同主题记忆做时间排序只保留最新的。5.3 召回的记忆和当前话题不相关多半是纯向量检索的锅。语义相似不等于场景相关。解法是加入类型过滤和会话过滤当前话题是技术讨论就优先召回技术类记忆当前会话有明确主题就优先召回同主题记忆。混合打分里的语义权重可以适当降低给类型匹配留出空间。5.4 常见问题速查表现象可能原因排查方向解决思路记忆不生效抽取漏了 / 召回没命中看存储里有没有 / 看召回分数调抽取 prompt / 调召回权重记忆自相矛盾旧记忆未归档检查同主题记忆状态加更新识别与归档逻辑召回太慢候选太多 / 向量库没索引看候选数和检索耗时减少候选 / 建 ANN 索引注入后回答变差记忆太多稀释注意力看注入 token 占比减少召回数 / 提高精排阈值敏感信息被召回抽取没过滤检查抽取规则加敏感词与保密标记过滤避坑技巧上线前一定要做一轮“记忆审计”人工抽查存储里的记忆看看有没有抽错的、过时的、敏感的。这一步能提前发现 80% 的线上问题。6. 记忆系统的扩展方向跑通基础版之后有几个方向值得继续深挖。一是记忆分层把短期会话记忆和长期用户记忆分开管理短期用滑动窗口长期用结构化存储召回时按需融合。二是记忆图谱把实体关系类记忆连成图支持多跳推理比如“A 依赖 BB 依赖 C”能推出 A 间接依赖 C。三是主动记忆不等用户说系统主动从行为里推断偏好比如用户每次都跳过某类回答就自动降低该类内容的权重。这些扩展不必一次做完按业务需要逐步加。我的建议是先把“抽取—存储—召回”这条主链路打磨稳定再考虑花活。主链路不稳加再多功能都是空中楼阁。我个人在实际操作中的体会是记忆系统的难点从来不在技术选型而在对“什么值得记”的判断。这个判断没有标准答案只能靠不断观察真实对话、调整抽取策略来逼近。每次调完抽取 prompt我都会拿一批真实对话回放一遍看新策略多抽了什么、漏了什么慢慢就摸到感觉了。
