claude-mem 记忆系统设计：从提炼、存储到检索注入的工程实践

1. 从"聊完就忘"说起：claude-mem 到底想解决什么

如果你用 Claude 这类对话式 AI 做过稍微长一点的项目，大概率遇到过这种尴尬：昨天花了两个小时跟它把一套数据清洗逻辑捋得清清楚楚，今天开个新会话，它一脸无辜地问你"请问你想处理什么数据"。你只能把昨天的上下文重新贴一遍，贴到一半发现 token 快满了，于是又得删删减减。这种"每次都要从头解释"的体验，是很多人对 AI 助手又爱又恨的根源。

claude-mem这个项目，从名字就能看出它的野心——给 Claude 加一层"记忆"。它不是官方功能，而是社区里有人实在受不了这种重复劳动，自己动手做的一套记忆管理方案。核心思路很朴素：把对话里值得留存的信息抽出来，存到一个外部的地方，下次需要的时候再按需塞回上下文。听起来简单，但真正做起来，涉及的问题一大堆——存什么、怎么存、什么时候取、取多少、怎么保证不把上下文撑爆，每一个都是坑。

这篇文章适合三类人看：一是天天跟 Claude 打交道、被上下文长度折磨的开发者；二是想给自己的 AI 工作流加一层持久化记忆的技术爱好者；三是单纯好奇"AI 记忆"这件事到底怎么落地的人。我会从设计动机讲起，把存储结构、检索策略、上下文注入这几个核心环节拆开讲透，再分享一些实测中踩过的坑和调优经验。全文基于社区里常见的实现思路和我自己的实践补充，不涉及任何官方未公开的东西。

先说结论：claude-mem这类方案的价值，不在于它用了多高深的技术，而在于它把"记忆"这件事拆成了几个可以独立优化的模块，让你能根据自己的使用习惯去调。理解了这个拆解逻辑，你就算不用这个具体项目，也能自己搭一套顺手的。

2. 记忆的存储结构：为什么不能简单存聊天记录

2.1 原始对话直接存的问题

很多人第一反应是：记忆嘛，把聊天记录存下来不就行了？下次全贴回去。这个思路在会话很短的时候能用，但稍微长一点就崩了。原因有三个。

第一是冗余。一段对话里，真正有信息量的可能就那几句结论，剩下的都是"好的""我明白了""那我们来试试"这类填充。全存下来，检索的时候噪音极大。第二是上下文预算。Claude 的上下文窗口虽然不小，但你还要留空间给当前任务、给工具调用结果、给系统提示，真正能分给"历史记忆"的可能就几千 token。全量贴回去，两次就满了。第三是时效性混乱。三个月前的一个临时决定，和昨天刚确认的方案，如果混在一起没有优先级，AI 很容易被旧信息带偏。

所以claude-mem这类项目的第一个设计决策，就是不存原始对话，存提炼后的记忆条目。这个决策看起来理所当然，但执行起来有个关键问题：谁来提炼？用规则还是用模型？

2.2 记忆条目的字段设计

社区里常见的做法是定义一套结构化的记忆条目，每条至少包含这几个字段：

这套字段不是拍脑袋定的。type决定了检索时的权重——比如preference（用户偏好）通常比fact（事实）更稳定，应该优先保留；last_used_at和use_count用来做衰减，长期没被用到的记忆可以降权甚至归档；tags是检索的第一道过滤网，比全文搜索快得多。

我自己的实践里还加了一个confidence字段，取值 0 到 1，表示这条记忆的可信度。为什么需要这个？因为 AI 提炼记忆的时候会出错。比如你随口说"要不试试 Redis"，它可能记成"用户决定用 Redis"。加个置信度，低置信度的记忆在注入前会二次确认，避免把试探性的话当成定论。

2.3 提炼环节的两种实现路线

提炼记忆有两条路：规则驱动和模型驱动。

规则驱动就是写一堆正则和关键词匹配，比如检测到"我用的是""我们决定""记住"这类触发词，就把后面的句子抽出来。优点是快、便宜、可控；缺点是死板，稍微换个说法就漏了。模型驱动则是把对话片段丢给一个小模型（或者 Claude 自己），让它输出结构化的记忆条目。优点是灵活、能理解语义；缺点是慢、有成本、可能产生幻觉。

实际项目里，claude-mem这类方案通常是混合的：先用规则做粗筛，把明显是闲聊的部分过滤掉，剩下的候选片段再交给模型提炼。这样既控制了成本，又保证了质量。我实测下来，纯规则方案的召回率大概在 60% 左右，加上模型提炼能到 85% 以上，但成本会翻几倍。如果你的使用频率不高，纯模型方案更省心；如果每天几百轮对话，混合方案更划算。

提示：提炼环节一定要做去重。同一个事实在多次对话里被反复提到是常态，如果不去重，记忆库会迅速膨胀，检索质量断崖式下跌。常见的去重策略是算语义相似度，超过阈值就合并，保留最新的那条并累加 use_count。

3. 检索策略：怎么在正确的时候捞出正确的记忆

3.1 全量注入为什么行不通

假设你攒了 500 条记忆，每次对话都全塞进去，会怎样？首先是 token 爆炸，500 条按每条 30 token 算就是 15000 token，还没开始干活上下文就去了大半。其次是注意力稀释，AI 面对一大堆不相关的信息，反而容易忽略真正重要的那几条。这跟人一样，你给同事甩一份 50 页的文档让他找一句话，他大概率找不到；你直接告诉他"看第 3 页第 2 段"，他秒懂。

所以检索的核心目标是：在有限的 token 预算内，捞出与当前对话最相关的 N 条记忆。这个 N 通常控制在 5 到 15 之间，具体看你的上下文窗口和任务复杂度。

3.2 多路召回的组合拳

单一检索方式都有短板，实践中常用的是多路召回再融合。常见的几路：

• 标签匹配：当前对话如果提到了"数据库"，就把 tags 里含 database 的记忆全捞出来。快，但依赖标签质量。
• 关键词匹配：用 BM25 这类算法做全文检索。对专有名词、代码标识符效果好。
• 向量检索：把记忆和当前对话都转成向量，算余弦相似度。对语义相近但用词不同的情况效果好。
• 时间衰减：最近创建或最近使用的记忆加权。适合"我昨天刚说过"这类场景。
• 类型优先：preference 和 decision 类型的记忆默认加权，因为这两类一旦确定，后续大概率还用得上。

把这几路的得分归一化后加权求和，取 top N。权重怎么定？我的经验是：向量检索占 0.4，关键词占 0.2，标签占 0.2，时间衰减占 0.1，类型优先占 0.1。这个比例不是金科玉律，你可以根据自己的使用场景调。比如你做的是代码项目，关键词匹配的权重可以调高，因为变量名、函数名这类东西向量检索经常抓不准。

3.3 检索触发的时机

什么时候触发检索？有两种模式：每轮都检索和按需检索。

每轮都检索简单粗暴，但有个问题：有些对话轮次根本不需要历史记忆，比如你只是说"继续"，这时候检索出来的记忆纯属浪费。按需检索则是先判断当前输入是否包含"指代"或"延续"信号，比如出现"刚才说的""那个方案""继续"这类词，才触发检索。

我自己的做法是折中：默认每轮都做一次轻量检索（只算标签和关键词，不算向量），如果轻量检索的得分低于阈值，再决定要不要做完整的向量检索。这样大部分轮次的开销都很小，只有真正需要的时候才动用重武器。

注意：检索结果注入上下文时，一定要带上来源和时间。比如"（3 天前，来自数据库设计讨论）用户决定主键用 bigint"。不带来源，AI 可能会把记忆和当前对话混淆；不带时间，AI 无法判断信息的时效性。

4. 上下文注入：把记忆"喂"给 Claude 的正确姿势

4.1 注入位置的选择

记忆注入的位置很讲究。常见的有三个位置：系统提示之后、用户消息之前、用户消息之后。

放在系统提示之后，记忆会被当成"背景设定"，AI 会默认这些是长期有效的信息。适合放 preference 和长期 fact。放在用户消息之前，记忆会被当成"当前任务的上下文"，AI 会更积极地使用。适合放与当前任务直接相关的 decision 和 todo。放在用户消息之后，效果最弱，AI 可能忽略，一般不推荐。

claude-mem这类项目通常的做法是：把记忆分成"常驻"和"临时"两批。常驻的（比如用户偏好、项目基本信息）放在系统提示之后，每轮都带；临时的（与当前任务相关的）放在用户消息之前，按需带。这样既保证了基础背景的稳定，又避免了无关信息干扰。

4.2 注入格式的设计

格式设计的目标是让 AI 一眼就能区分"这是记忆"和"这是当前对话"。常见的做法是用 XML 标签或 Markdown 分隔符包起来。比如：

<memory> <item type="preference" time="2024-01-15"> 用户偏好使用 Python 而非 JavaScript 做数据处理 </item> <item type="decision" time="2024-01-20"> 项目数据库选型确定为 PostgreSQL 15 </item> </memory>

用 XML 标签的好处是结构清晰，Claude 对这类标签的识别很稳。注意每条记忆都要带 type 和 time，这两个信息对 AI 判断如何使用记忆至关重要。

4.3 注入数量的动态控制

前面说 N 控制在 5 到 15，但具体取多少，最好动态决定。判断依据可以是：当前对话的复杂度、剩余上下文预算、检索得分的分布。

如果检索得分前 5 条都很高，后面断崖式下跌，那就只取 5 条。如果得分比较平均，说明可能有多条都相关，可以多取几条。剩余上下文预算少的时候，优先保证当前任务的空间，记忆少带几条。

我自己的实现里有个简单的规则：先按得分排序，取前 15 条候选，然后从高到低累加 token 数，直到达到记忆预算上限（比如 2000 token）或者候选用完。这样既保证了相关性，又不会撑爆上下文。

提示：记忆注入后，最好在系统提示里加一句"以上记忆仅供参考，如与当前对话冲突，以当前对话为准"。这句话能有效避免 AI 被过时记忆带偏。

5. 实测中踩过的坑与调优经验

5.1 记忆污染：AI 把猜测当事实

这是最常见也最头疼的问题。你随口说"要不试试用 Redis 做缓存"，AI 提炼成"用户决定用 Redis 做缓存"，下次对话它就开始按 Redis 方案给你写代码。等你发现不对，已经浪费了好几轮。

解决办法有两个。一是前面提到的confidence字段，低置信度的记忆注入时标注"（待确认）"，让 AI 知道这条不确定。二是在提炼环节加一道判断，把"要不""也许""可以考虑"这类试探性词汇识别出来，降低置信度。我实测下来，加了这道判断后，记忆污染的概率能降一半以上。

5.2 检索漂移：越用越不准

用了一段时间后，你可能会发现检索出来的记忆越来越不相关。原因通常是记忆库膨胀后，向量检索的区分度下降。500 条记忆和 5000 条记忆，同样的检索算法，效果天差地别。

对策是定期归档。把 use_count 为 0 且超过 30 天没被检索的记忆移到归档区，不参与常规检索。归档区可以保留，需要的时候手动查。我一般每个月做一次归档，归档后检索准确率能明显回升。

5.3 上下文冲突：新旧记忆打架

同一个事实，不同时间可能有不同版本。比如你上个月说"用 MySQL"，这个月改成了"用 PostgreSQL"。如果两条记忆都在库里，检索时可能都捞出来，AI 就懵了。

解决办法是记忆更新机制。当新记忆与旧记忆语义相似度超过阈值时，不是简单新增，而是把旧记忆标记为 superseded，新记忆继承旧记忆的 use_count 和 tags。检索时默认只返回未被 superseded 的记忆。这样既保留了历史，又避免了冲突。

5.4 成本控制：别让记忆系统比对话本身还贵

提炼和检索都要调用模型或算向量，这些都是成本。如果每轮对话都做完整的提炼加检索，成本可能比对话本身还高。

我的做法是分级处理。提炼只在会话结束时做一次，而不是每轮都做。检索用轻量方式做粗筛，只有粗筛结果不理想时才动用向量检索。向量计算可以本地做，用开源的小模型，避免调用 API。这样整体成本能控制在对话成本的 10% 到 20%，大部分人都能接受。

5.5 隐私与数据安全

记忆库里存的是你的项目信息、偏好、决策，这些东西的敏感度不低。如果记忆库存在云端，要注意加密和访问控制。如果存在本地，注意备份，别哪天硬盘挂了记忆全丢。

我自己的方案是本地 SQLite 存记忆，定期导出加密备份。向量索引也放本地，用文件存储。这样数据完全在自己手里，不用担心第三方泄露。代价是换设备时要手动迁移，但我觉得这个代价值得。

6. 从 claude-mem 延伸出去：记忆系统的通用设计思路

把claude-mem拆完，你会发现它的设计思路其实很通用，换成任何对话式 AI 都能套用。核心就四步：提炼、存储、检索、注入。每一步都有明确的输入输出和优化空间。

提炼环节的关键是平衡召回率和准确率，规则和模型混合是性价比最高的方案。存储环节的关键是结构化，字段设计决定了后续检索的天花板。检索环节的关键是多路召回加融合排序，单一方式都有短板。注入环节的关键是位置和格式，让 AI 能清晰区分记忆和当前对话。

这套思路不只适用于 Claude，你用它给任何 AI 助手加记忆都行。甚至不限于 AI，你做个人知识管理，把笔记当成记忆条目，用同样的检索策略去捞，效果也不错。我有个朋友就用类似的逻辑管理他的读书笔记，找资料比以前快多了。

最后分享一个我自己的小技巧：记忆条目的 content 字段，尽量写成完整的、自包含的句子，而不是关键词堆砌。比如写"用户的项目使用 PostgreSQL 15，主键类型为 bigint"，而不是"PostgreSQL 15, bigint, 主键"。自包含的句子在向量检索时效果更好，注入后 AI 也更容易理解。这个细节看起来小，但对整体效果的影响不小，我调了很久才意识到。