1. 从“聊完就忘”说起claude-mem 到底想解决什么如果你用 Claude 这类对话式 AI 做过稍微长一点的项目大概率遇到过这种尴尬昨天聊了三个小时把需求、架构、命名规范、踩过的坑都对齐了今天开个新会话它一脸无辜地问你“请问你想做什么”。你只能把昨天的上下文再贴一遍贴到后面自己都嫌烦。这不是模型不聪明而是对话式 AI 的默认记忆边界就是单次会话——会话一关上下文清零。claude-mem这个项目从名字就能看出来它瞄准的就是这个痛点给 Claude 加一层“记忆”。注意它不是去改模型本身而是在模型外面套一层记忆管理层把跨会话需要保留的信息存下来在合适的时候再喂回给模型。你可以把它理解成给一个记忆力只有七秒的人配了一个随身笔记本笔记本怎么记、记什么、什么时候翻出来看才是这个项目真正的技术含量所在。这篇文章适合几类人看一是天天和 Claude 打交道、被上下文长度折磨的开发者二是想给自己的 AI 工作流加持久化记忆的工程师三是对“AI 记忆系统”这个方向好奇、想动手复现一个最小可用版本的人。我会从记忆到底该怎么分层、存储怎么选、检索怎么召回、上下文怎么拼装这几个角度把 claude-mem 这类方案拆开讲透并且给出可以直接抄的实操思路。全程不吹概念只讲能落地的东西。先说一个反直觉的结论给 AI 加记忆难点从来不是“存”而是“取”和“忘”。存谁都会存写个文件、塞个数据库就完事。但你要在几千条记忆里在用户提问的那一瞬间精准捞出真正相关的那三五条还不能把上下文撑爆这才是真正决定体验的地方。claude-mem 的价值八成都在这个“取”和“忘”上。2. 记忆不是一坨拆解 claude-mem 的分层设计思路很多人第一次做 AI 记忆思路特别朴素把所有对话历史存成一个不断追加的大文件每次提问就把整个文件塞进上下文。这个方案在头几天能用一旦记录超过几万字你就会发现两个致命问题——上下文超限和信噪比崩塌。模型被一大堆无关的旧对话淹没回答质量反而下降。claude-mem 这类成熟方案不会这么干它一定会做分层。2.1 短期记忆、长期记忆与工作记忆的三层划分从认知科学借来的一个经典划分在工程上非常好用。短期记忆对应当前会话的原始对话流保留最近若干轮保证对话连贯长期记忆是跨会话沉淀下来的、经过提炼的事实和结论比如“这个项目用 PostgreSQL 而不是 MySQL”“用户偏好简洁回答”工作记忆则是针对当前任务临时组装起来的一小块上下文用完即弃。为什么要这么分因为这三类信息的生命周期和访问频率完全不同。短期记忆读写频繁但存活时间短适合放内存长期记忆写入少、读取多、要求持久适合放数据库工作记忆是每次请求临时拼的根本不需要存。如果你把三者混在一起存就会出现“为了查一条长期事实把整个短期对话也捞出来”的浪费。分层之后每一层用最适合它的存储和检索策略效率立刻不一样。我在实际项目里踩过的一个坑是早期把所有东西都塞进向量库结果短期对话的语义相似度检索经常把几天前的闲聊捞出来干扰当前回答。后来把短期记忆单独用队列管理只按时间顺序取最近 N 轮问题就消失了。分层不是为了好看是为了让每类数据走它该走的路。2.2 为什么“提炼”比“全量存储”更关键claude-mem 这类系统里有一个环节特别容易被新手忽略就是记忆提炼。原始对话里 90% 是废话——“好的”“明白了”“那我再想想”。真正值得长期保留的可能就一两句结论。如果全量存长期记忆库很快就会被垃圾撑满检索质量断崖式下跌。提炼的常见做法是在会话结束或达到一定轮次时触发一次“总结”调用让模型自己从这段对话里抽出事实性结论、决策、偏好、待办这几类信息结构化后写入长期记忆。这里有个经验提炼时一定要给模型明确的输出 schema比如要求它输出 JSON字段固定为fact、category、confidence。否则模型会给你写一段散文后面根本没法结构化检索。提示提炼这一步不要追求“一次到位”。我试过让模型一次性总结整段长对话结果它经常漏掉中间的关键决策。后来改成滑动窗口分段提炼再合并去重召回率明显提升。2.3 记忆的“遗忘机制”主动删除比被动堆积更重要这是最反直觉的一点。大多数人做记忆系统只想着怎么加从不想怎么减。但一个健康的记忆系统必须有遗忘机制。原因很简单过时的信息比没有信息更危险。用户三个月前说“我们暂时用 SQLite”现在早就换成 PostgreSQL 了如果旧记忆还在模型就会给出错误建议。claude-mem 这类方案通常用几种方式实现遗忘一是时间衰减越老的记忆权重越低检索时排后面二是冲突覆盖当新记忆和旧记忆在同一主题上矛盾时标记旧记忆为失效三是容量淘汰长期记忆库超过阈值时淘汰置信度最低、最久未被访问的条目。我个人的偏好是给每条记忆加一个last_accessed和access_count字段检索命中就更新淘汰时优先干掉“又老又没人用”的。3. 存储选型向量库、关系库还是文件别选错记忆存哪里是 claude-mem 落地时第一个要拍板的技术决策。我见过太多人一上来就无脑上向量数据库结果发现一半的查询根本用不上语义检索纯属给自己加复杂度。选型的关键是搞清楚你的记忆主要靠什么方式被查出来。3.1 三种存储方案的适用边界对比存储方案擅长场景不擅长场景典型代表关系型数据库结构化事实、精确条件查询、事务语义模糊匹配SQLite、PostgreSQL向量数据库语义相似检索、模糊召回精确过滤、复杂条件组合各类向量库本地文件小规模、可读性要求高、零依赖并发、大规模检索JSON、Markdown我的实际经验是混合使用才是正解。结构化的事实用户偏好、项目配置、明确决策放关系库用精确查询非结构化的经验、讨论片段放向量库用语义检索两者用一个统一的memory_id关联。查询时先走关系库拿硬事实再走向量库补充相关背景最后合并去重。3.2 为什么小项目优先选 SQLite 而不是重型方案如果你只是个人用或者项目早期我强烈建议从SQLite 起步。理由有三第一零运维一个文件搞定不用起服务第二它现在原生支持向量扩展做小规模语义检索完全够用第三SQL 查询能力完整结构化过滤和语义检索能在同一个引擎里完成省掉跨库关联的麻烦。我见过有人为了“显得专业”上来就部署一套分布式向量库集群结果数据量才几千条纯属杀鸡用牛刀还引入了网络延迟和运维负担。记忆系统的瓶颈在检索策略不在存储引擎的性能。等你真的到了百万级记忆、QPS 扛不住的时候再换一点都不晚。3.3 记忆条目的字段设计一张表说清楚不管用什么存储记忆条目的字段设计是通用的。下面这张表是我在多个项目里迭代出来的可以直接参考字段类型作用id主键唯一标识content文本记忆正文category枚举fact/preference/decision/todoembedding向量语义检索用confidence浮点置信度0-1created_at时间戳创建时间用于衰减last_accessed时间戳最近命中时间用于淘汰access_count整数命中次数用于热度排序source_session字符串来源会话便于溯源status枚举active/superseded/deleted这张表里confidence、last_accessed、access_count这三个字段是很多人会漏掉的但它们恰恰是遗忘机制和排序策略的基础。没有它们你的记忆库就是一个只进不出的黑洞。4. 检索与召回决定体验的临门一脚存储搞定了真正的硬仗在检索。用户提问的那一刻你要在毫秒级时间内从成千上万条记忆里挑出最该进上下文的那几条。挑多了撑爆上下文挑少了信息不全挑错了直接误导模型。这一节讲的就是怎么把这一步做稳。4.1 混合检索语义相似度只是其中一路只靠向量相似度检索是最常见的错误。向量检索有个天然缺陷它对精确匹配不敏感。用户问“上次说的那个端口号是多少”向量检索可能给你捞出一堆关于“端口”的泛泛讨论却漏掉那条写着“端口 8080”的精确记忆。所以成熟的方案一定是混合检索。具体做法是并行跑几路召回再融合排序第一路是向量语义检索负责模糊相关第二路是关键词/全文检索负责精确命中第三路是结构化过滤比如按 category 或时间范围筛。三路结果用类似 RRF倒数排名融合的算法合并取综合排名靠前的若干条。我实测下来混合检索相比纯向量在“精确事实类”问题上的召回率能提升一大截。4.2 重排序把真正相关的顶上来召回阶段追求的是“不漏”通常会多捞一些候选比如先取 20 条。但真正进上下文的可能只有 5 条这中间的筛选就靠重排序。最简单的重排是用一个交叉编码器模型把 query 和每条候选记忆拼在一起打分比单纯的向量点积准得多。如果不想引入额外模型也有轻量做法给每条记忆算一个综合分公式大致是score 语义相似度 * w1 时间新鲜度 * w2 访问热度 * w3 置信度 * w4。权重怎么定我的经验是语义相似度占大头0.5 左右新鲜度和热度各占 0.2置信度占 0.1。这个配比不是拍脑袋是反复调出来的——语义相关永远是第一位的但新鲜度能有效压制过时信息。4.3 上下文预算给记忆留多少 token 才合理这是个特别实际的问题。模型的上下文窗口是有限的你不能把检索到的记忆全塞进去。我的做法是给记忆分配一个固定预算比如总窗口的 20% 到 30%剩下的留给当前对话和系统提示。然后按重排分数从高到低往预算里填填满为止。这里有个细节记忆条目要按重要性排序后拼接而不是按时间。因为模型对上下文开头和结尾的内容注意力更强所谓的“中间遗忘”现象所以最关键的记忆应该放在最前面。我一般会把置信度最高、最相关的那条放开头其余按分数递减排列。这个小小的顺序调整实测对回答准确率有肉眼可见的影响。注意拼接记忆时一定要加清晰的分隔标记比如用[记忆]和[/记忆]包起来并明确告诉模型“以下是历史记忆供参考”。否则模型可能把记忆内容当成用户当前说的话产生混淆。5. 落地实操搭一个最小可用的 claude-mem前面讲的都是原理和选型这一节直接上干货讲怎么从零搭一个能跑的最小版本。我不追求功能大而全目标是两三百行代码能跑通“存-取-用”闭环你先跑起来再按需扩展。5.1 环境准备与依赖选择技术栈我建议这样选Python 3.10SQLite 做存储开sqlite-vec扩展做向量sentence-transformers做本地 embedding避免依赖外部 API。这样整套系统零外部服务一个脚本就能跑。如果你已经在用某个向量库也可以替换但初期真没必要。安装依赖就三条命令的事pip install sqlite-vec sentence-transformers pip install numpy选本地 embedding 模型而不是调 API理由是记忆写入是高频操作每次会话结束都要提炼、嵌入如果走 API成本和延迟都受不了。本地模型虽然效果略逊但对记忆检索这种场景完全够用而且隐私可控。5.2 记忆写入从对话到结构化条目写入流程分三步。第一步触发提炼会话轮次达到阈值我设的是 10 轮或用户主动结束会话时触发。第二步调用模型提炼给模型一段 prompt要求它输出 JSON 数组每条包含content、category、confidence。第三步嵌入并入库对每条 content 算 embedding连同其他字段写入 SQLite。提炼的 prompt 是关键我给你一个我调了很久的模板思路明确告诉模型“只提取值得跨会话保留的信息忽略寒暄和过程性讨论”并给出几个正例反例。反例特别重要能显著减少模型把废话也提炼出来的情况。比如反例可以是“好的我明白了”这种正例是“项目数据库确定为 PostgreSQL 15”。5.3 记忆读取一次完整查询的代码骨架读取流程是写入的逆过程。用户提问后先用同一个 embedding 模型把 query 向量化然后并行跑向量检索和关键词检索合并重排取 top-k最后拼进上下文。核心代码骨架大概长这样def retrieve_memories(query, top_k5, budget_tokens1500): q_vec embed(query) vec_hits vector_search(q_vec, limit20) kw_hits keyword_search(query, limit20) merged rrf_merge(vec_hits, kw_hits) reranked rerank(query, merged) selected fill_budget(reranked, budget_tokens) return selectedfill_budget这个函数负责按 token 预算截断别小看它它是防止上下文爆炸的最后一道闸。我一般用 tiktoken 之类的库精确算 token而不是按字符数估算因为中英文混排时字符数估算误差很大。5.4 实测中的三个意外情况第一个意外提炼出的记忆会重复。同一件事在多次会话里被反复提到就存了多条。解决办法是在写入前做一次相似度去重如果新记忆和已有记忆相似度超过 0.9就更新旧的而不是新增。第二个意外向量检索对短 query 效果差。用户问“端口多少”就四个字向量化后信息量太少召回不准。我的应对是查询改写先用模型把短 query 扩写成一句完整的话再检索比如扩成“之前讨论的项目服务端口号是多少”召回率立刻上来。第三个意外记忆污染。有次模型提炼时把一句玩笑话当成了真实决策存了进去后面一直误导回答。后来我在提炼 prompt 里加了“只提取陈述性、确定性信息忽略假设和玩笑”并给低置信度记忆加了人工复核入口。记忆系统一定要有纠错通道不能只进不出。6. 那些文档不会告诉你的经验与坑做到这里一个能用的 claude-mem 基本成型了。但真正让它从“能用”到“好用”靠的是一堆细节经验。这一节我把踩过的坑和总结的技巧集中倒出来都是实打实换来的。6.1 记忆的“冷启动”问题怎么破新系统上线时记忆库是空的检索什么都捞不到体验和没有记忆一样。这时候别急着让用户等它慢慢积累。我的做法是预置一批种子记忆把项目的 README、常用配置、团队约定这些整理成结构化条目一次性导入。这样从第一天起模型就有基本的背景知识体验立刻不一样。种子记忆的 category 我一般标成fact置信度给高一点。6.2 多用户场景下的记忆隔离如果你做的是多人共用的系统记忆隔离是必须的。最简单的做法是每条记忆加一个user_id字段所有查询强制带上这个过滤条件。但要注意有些记忆是团队共享的比如项目架构决策有些是个人私有的比如个人偏好。我一般用scope字段区分personal和shared查询时取两者的并集。这个设计能避免“A 用户的偏好污染了 B 用户”的尴尬。6.3 怎么评估记忆系统到底有没有用别凭感觉说“好像变聪明了”。要量化就得有评估集。我的做法是构造一批需要跨会话记忆才能答对的问题比如“我们上次定的缓存方案是什么”然后对比开记忆和关记忆两种情况下的回答准确率。这个评估集不用大二三十条就够看出趋势。我实测下来好的记忆系统能把这类问题的准确率从 30% 左右拉到 80% 以上差距非常明显。6.4 性能与成本的平衡点最后说成本。记忆系统的主要开销在两块提炼时的模型调用和检索时的 embedding 计算。提炼可以异步做不阻塞用户所以延迟不敏感可以用便宜模型embedding 如果本地做基本零成本。真正要控制的是检索频率——别每次对话都全量检索可以缓存最近用过的记忆或者对简单问题跳过检索。我一般设一个规则只有当 query 长度超过一定阈值或者包含“上次”“之前”“我们说过”这类指代词时才触发记忆检索。这个简单的启发式能省掉一大半无谓的检索开销。这套东西我从零搭到稳定运行前后迭代了大概两个月最大的体会是记忆系统的复杂度不在技术而在对“什么值得记、什么时候该忘”的判断。技术方案网上到处都是但真正决定体验的是你对业务场景的理解和对细节的打磨。先把最小闭环跑通然后在真实使用中一点点调比一开始就设计一个完美架构要靠谱得多。 
长河君 · 2026/10/9 14:44:33 · 阅读 1.2k 给Claude加记忆：claude-mem分层存储与混合检索实战
1. 从“聊完就忘”说起claude-mem 到底想解决什么如果你用 Claude 这类对话式 AI 做过稍微长一点的项目大概率遇到过这种尴尬昨天聊了三个小时把需求、架构、命名规范、踩过的坑都对齐了今天开个新会话它一脸无辜地问你“请问你想做什么”。你只能把昨天的上下文再贴一遍贴到后面自己都嫌烦。这不是模型不聪明而是对话式 AI 的默认记忆边界就是单次会话——会话一关上下文清零。claude-mem这个项目从名字就能看出来它瞄准的就是这个痛点给 Claude 加一层“记忆”。注意它不是去改模型本身而是在模型外面套一层记忆管理层把跨会话需要保留的信息存下来在合适的时候再喂回给模型。你可以把它理解成给一个记忆力只有七秒的人配了一个随身笔记本笔记本怎么记、记什么、什么时候翻出来看才是这个项目真正的技术含量所在。这篇文章适合几类人看一是天天和 Claude 打交道、被上下文长度折磨的开发者二是想给自己的 AI 工作流加持久化记忆的工程师三是对“AI 记忆系统”这个方向好奇、想动手复现一个最小可用版本的人。我会从记忆到底该怎么分层、存储怎么选、检索怎么召回、上下文怎么拼装这几个角度把 claude-mem 这类方案拆开讲透并且给出可以直接抄的实操思路。全程不吹概念只讲能落地的东西。先说一个反直觉的结论给 AI 加记忆难点从来不是“存”而是“取”和“忘”。存谁都会存写个文件、塞个数据库就完事。但你要在几千条记忆里在用户提问的那一瞬间精准捞出真正相关的那三五条还不能把上下文撑爆这才是真正决定体验的地方。claude-mem 的价值八成都在这个“取”和“忘”上。2. 记忆不是一坨拆解 claude-mem 的分层设计思路很多人第一次做 AI 记忆思路特别朴素把所有对话历史存成一个不断追加的大文件每次提问就把整个文件塞进上下文。这个方案在头几天能用一旦记录超过几万字你就会发现两个致命问题——上下文超限和信噪比崩塌。模型被一大堆无关的旧对话淹没回答质量反而下降。claude-mem 这类成熟方案不会这么干它一定会做分层。2.1 短期记忆、长期记忆与工作记忆的三层划分从认知科学借来的一个经典划分在工程上非常好用。短期记忆对应当前会话的原始对话流保留最近若干轮保证对话连贯长期记忆是跨会话沉淀下来的、经过提炼的事实和结论比如“这个项目用 PostgreSQL 而不是 MySQL”“用户偏好简洁回答”工作记忆则是针对当前任务临时组装起来的一小块上下文用完即弃。为什么要这么分因为这三类信息的生命周期和访问频率完全不同。短期记忆读写频繁但存活时间短适合放内存长期记忆写入少、读取多、要求持久适合放数据库工作记忆是每次请求临时拼的根本不需要存。如果你把三者混在一起存就会出现“为了查一条长期事实把整个短期对话也捞出来”的浪费。分层之后每一层用最适合它的存储和检索策略效率立刻不一样。我在实际项目里踩过的一个坑是早期把所有东西都塞进向量库结果短期对话的语义相似度检索经常把几天前的闲聊捞出来干扰当前回答。后来把短期记忆单独用队列管理只按时间顺序取最近 N 轮问题就消失了。分层不是为了好看是为了让每类数据走它该走的路。2.2 为什么“提炼”比“全量存储”更关键claude-mem 这类系统里有一个环节特别容易被新手忽略就是记忆提炼。原始对话里 90% 是废话——“好的”“明白了”“那我再想想”。真正值得长期保留的可能就一两句结论。如果全量存长期记忆库很快就会被垃圾撑满检索质量断崖式下跌。提炼的常见做法是在会话结束或达到一定轮次时触发一次“总结”调用让模型自己从这段对话里抽出事实性结论、决策、偏好、待办这几类信息结构化后写入长期记忆。这里有个经验提炼时一定要给模型明确的输出 schema比如要求它输出 JSON字段固定为fact、category、confidence。否则模型会给你写一段散文后面根本没法结构化检索。提示提炼这一步不要追求“一次到位”。我试过让模型一次性总结整段长对话结果它经常漏掉中间的关键决策。后来改成滑动窗口分段提炼再合并去重召回率明显提升。2.3 记忆的“遗忘机制”主动删除比被动堆积更重要这是最反直觉的一点。大多数人做记忆系统只想着怎么加从不想怎么减。但一个健康的记忆系统必须有遗忘机制。原因很简单过时的信息比没有信息更危险。用户三个月前说“我们暂时用 SQLite”现在早就换成 PostgreSQL 了如果旧记忆还在模型就会给出错误建议。claude-mem 这类方案通常用几种方式实现遗忘一是时间衰减越老的记忆权重越低检索时排后面二是冲突覆盖当新记忆和旧记忆在同一主题上矛盾时标记旧记忆为失效三是容量淘汰长期记忆库超过阈值时淘汰置信度最低、最久未被访问的条目。我个人的偏好是给每条记忆加一个last_accessed和access_count字段检索命中就更新淘汰时优先干掉“又老又没人用”的。3. 存储选型向量库、关系库还是文件别选错记忆存哪里是 claude-mem 落地时第一个要拍板的技术决策。我见过太多人一上来就无脑上向量数据库结果发现一半的查询根本用不上语义检索纯属给自己加复杂度。选型的关键是搞清楚你的记忆主要靠什么方式被查出来。3.1 三种存储方案的适用边界对比存储方案擅长场景不擅长场景典型代表关系型数据库结构化事实、精确条件查询、事务语义模糊匹配SQLite、PostgreSQL向量数据库语义相似检索、模糊召回精确过滤、复杂条件组合各类向量库本地文件小规模、可读性要求高、零依赖并发、大规模检索JSON、Markdown我的实际经验是混合使用才是正解。结构化的事实用户偏好、项目配置、明确决策放关系库用精确查询非结构化的经验、讨论片段放向量库用语义检索两者用一个统一的memory_id关联。查询时先走关系库拿硬事实再走向量库补充相关背景最后合并去重。3.2 为什么小项目优先选 SQLite 而不是重型方案如果你只是个人用或者项目早期我强烈建议从SQLite 起步。理由有三第一零运维一个文件搞定不用起服务第二它现在原生支持向量扩展做小规模语义检索完全够用第三SQL 查询能力完整结构化过滤和语义检索能在同一个引擎里完成省掉跨库关联的麻烦。我见过有人为了“显得专业”上来就部署一套分布式向量库集群结果数据量才几千条纯属杀鸡用牛刀还引入了网络延迟和运维负担。记忆系统的瓶颈在检索策略不在存储引擎的性能。等你真的到了百万级记忆、QPS 扛不住的时候再换一点都不晚。3.3 记忆条目的字段设计一张表说清楚不管用什么存储记忆条目的字段设计是通用的。下面这张表是我在多个项目里迭代出来的可以直接参考字段类型作用id主键唯一标识content文本记忆正文category枚举fact/preference/decision/todoembedding向量语义检索用confidence浮点置信度0-1created_at时间戳创建时间用于衰减last_accessed时间戳最近命中时间用于淘汰access_count整数命中次数用于热度排序source_session字符串来源会话便于溯源status枚举active/superseded/deleted这张表里confidence、last_accessed、access_count这三个字段是很多人会漏掉的但它们恰恰是遗忘机制和排序策略的基础。没有它们你的记忆库就是一个只进不出的黑洞。4. 检索与召回决定体验的临门一脚存储搞定了真正的硬仗在检索。用户提问的那一刻你要在毫秒级时间内从成千上万条记忆里挑出最该进上下文的那几条。挑多了撑爆上下文挑少了信息不全挑错了直接误导模型。这一节讲的就是怎么把这一步做稳。4.1 混合检索语义相似度只是其中一路只靠向量相似度检索是最常见的错误。向量检索有个天然缺陷它对精确匹配不敏感。用户问“上次说的那个端口号是多少”向量检索可能给你捞出一堆关于“端口”的泛泛讨论却漏掉那条写着“端口 8080”的精确记忆。所以成熟的方案一定是混合检索。具体做法是并行跑几路召回再融合排序第一路是向量语义检索负责模糊相关第二路是关键词/全文检索负责精确命中第三路是结构化过滤比如按 category 或时间范围筛。三路结果用类似 RRF倒数排名融合的算法合并取综合排名靠前的若干条。我实测下来混合检索相比纯向量在“精确事实类”问题上的召回率能提升一大截。4.2 重排序把真正相关的顶上来召回阶段追求的是“不漏”通常会多捞一些候选比如先取 20 条。但真正进上下文的可能只有 5 条这中间的筛选就靠重排序。最简单的重排是用一个交叉编码器模型把 query 和每条候选记忆拼在一起打分比单纯的向量点积准得多。如果不想引入额外模型也有轻量做法给每条记忆算一个综合分公式大致是score 语义相似度 * w1 时间新鲜度 * w2 访问热度 * w3 置信度 * w4。权重怎么定我的经验是语义相似度占大头0.5 左右新鲜度和热度各占 0.2置信度占 0.1。这个配比不是拍脑袋是反复调出来的——语义相关永远是第一位的但新鲜度能有效压制过时信息。4.3 上下文预算给记忆留多少 token 才合理这是个特别实际的问题。模型的上下文窗口是有限的你不能把检索到的记忆全塞进去。我的做法是给记忆分配一个固定预算比如总窗口的 20% 到 30%剩下的留给当前对话和系统提示。然后按重排分数从高到低往预算里填填满为止。这里有个细节记忆条目要按重要性排序后拼接而不是按时间。因为模型对上下文开头和结尾的内容注意力更强所谓的“中间遗忘”现象所以最关键的记忆应该放在最前面。我一般会把置信度最高、最相关的那条放开头其余按分数递减排列。这个小小的顺序调整实测对回答准确率有肉眼可见的影响。注意拼接记忆时一定要加清晰的分隔标记比如用[记忆]和[/记忆]包起来并明确告诉模型“以下是历史记忆供参考”。否则模型可能把记忆内容当成用户当前说的话产生混淆。5. 落地实操搭一个最小可用的 claude-mem前面讲的都是原理和选型这一节直接上干货讲怎么从零搭一个能跑的最小版本。我不追求功能大而全目标是两三百行代码能跑通“存-取-用”闭环你先跑起来再按需扩展。5.1 环境准备与依赖选择技术栈我建议这样选Python 3.10SQLite 做存储开sqlite-vec扩展做向量sentence-transformers做本地 embedding避免依赖外部 API。这样整套系统零外部服务一个脚本就能跑。如果你已经在用某个向量库也可以替换但初期真没必要。安装依赖就三条命令的事pip install sqlite-vec sentence-transformers pip install numpy选本地 embedding 模型而不是调 API理由是记忆写入是高频操作每次会话结束都要提炼、嵌入如果走 API成本和延迟都受不了。本地模型虽然效果略逊但对记忆检索这种场景完全够用而且隐私可控。5.2 记忆写入从对话到结构化条目写入流程分三步。第一步触发提炼会话轮次达到阈值我设的是 10 轮或用户主动结束会话时触发。第二步调用模型提炼给模型一段 prompt要求它输出 JSON 数组每条包含content、category、confidence。第三步嵌入并入库对每条 content 算 embedding连同其他字段写入 SQLite。提炼的 prompt 是关键我给你一个我调了很久的模板思路明确告诉模型“只提取值得跨会话保留的信息忽略寒暄和过程性讨论”并给出几个正例反例。反例特别重要能显著减少模型把废话也提炼出来的情况。比如反例可以是“好的我明白了”这种正例是“项目数据库确定为 PostgreSQL 15”。5.3 记忆读取一次完整查询的代码骨架读取流程是写入的逆过程。用户提问后先用同一个 embedding 模型把 query 向量化然后并行跑向量检索和关键词检索合并重排取 top-k最后拼进上下文。核心代码骨架大概长这样def retrieve_memories(query, top_k5, budget_tokens1500): q_vec embed(query) vec_hits vector_search(q_vec, limit20) kw_hits keyword_search(query, limit20) merged rrf_merge(vec_hits, kw_hits) reranked rerank(query, merged) selected fill_budget(reranked, budget_tokens) return selectedfill_budget这个函数负责按 token 预算截断别小看它它是防止上下文爆炸的最后一道闸。我一般用 tiktoken 之类的库精确算 token而不是按字符数估算因为中英文混排时字符数估算误差很大。5.4 实测中的三个意外情况第一个意外提炼出的记忆会重复。同一件事在多次会话里被反复提到就存了多条。解决办法是在写入前做一次相似度去重如果新记忆和已有记忆相似度超过 0.9就更新旧的而不是新增。第二个意外向量检索对短 query 效果差。用户问“端口多少”就四个字向量化后信息量太少召回不准。我的应对是查询改写先用模型把短 query 扩写成一句完整的话再检索比如扩成“之前讨论的项目服务端口号是多少”召回率立刻上来。第三个意外记忆污染。有次模型提炼时把一句玩笑话当成了真实决策存了进去后面一直误导回答。后来我在提炼 prompt 里加了“只提取陈述性、确定性信息忽略假设和玩笑”并给低置信度记忆加了人工复核入口。记忆系统一定要有纠错通道不能只进不出。6. 那些文档不会告诉你的经验与坑做到这里一个能用的 claude-mem 基本成型了。但真正让它从“能用”到“好用”靠的是一堆细节经验。这一节我把踩过的坑和总结的技巧集中倒出来都是实打实换来的。6.1 记忆的“冷启动”问题怎么破新系统上线时记忆库是空的检索什么都捞不到体验和没有记忆一样。这时候别急着让用户等它慢慢积累。我的做法是预置一批种子记忆把项目的 README、常用配置、团队约定这些整理成结构化条目一次性导入。这样从第一天起模型就有基本的背景知识体验立刻不一样。种子记忆的 category 我一般标成fact置信度给高一点。6.2 多用户场景下的记忆隔离如果你做的是多人共用的系统记忆隔离是必须的。最简单的做法是每条记忆加一个user_id字段所有查询强制带上这个过滤条件。但要注意有些记忆是团队共享的比如项目架构决策有些是个人私有的比如个人偏好。我一般用scope字段区分personal和shared查询时取两者的并集。这个设计能避免“A 用户的偏好污染了 B 用户”的尴尬。6.3 怎么评估记忆系统到底有没有用别凭感觉说“好像变聪明了”。要量化就得有评估集。我的做法是构造一批需要跨会话记忆才能答对的问题比如“我们上次定的缓存方案是什么”然后对比开记忆和关记忆两种情况下的回答准确率。这个评估集不用大二三十条就够看出趋势。我实测下来好的记忆系统能把这类问题的准确率从 30% 左右拉到 80% 以上差距非常明显。6.4 性能与成本的平衡点最后说成本。记忆系统的主要开销在两块提炼时的模型调用和检索时的 embedding 计算。提炼可以异步做不阻塞用户所以延迟不敏感可以用便宜模型embedding 如果本地做基本零成本。真正要控制的是检索频率——别每次对话都全量检索可以缓存最近用过的记忆或者对简单问题跳过检索。我一般设一个规则只有当 query 长度超过一定阈值或者包含“上次”“之前”“我们说过”这类指代词时才触发记忆检索。这个简单的启发式能省掉一大半无谓的检索开销。这套东西我从零搭到稳定运行前后迭代了大概两个月最大的体会是记忆系统的复杂度不在技术而在对“什么值得记、什么时候该忘”的判断。技术方案网上到处都是但真正决定体验的是你对业务场景的理解和对细节的打磨。先把最小闭环跑通然后在真实使用中一点点调比一开始就设计一个完美架构要靠谱得多。