1. 从聊完就忘说起claude-mem 到底想解决什么如果你用 Claude 这类对话式 AI 做过稍微长期一点的事情比如连续几天跟进一个项目、反复迭代一份方案、或者让它在同一个代码库里帮你改东西你大概率遇到过这种尴尬昨天刚跟它讲清楚的项目背景、命名规范、目录结构今天开一个新会话它又一脸茫然地从头问起。你不得不把之前说过的话再复述一遍甚至把整段上下文重新粘贴进去。这种每次都要重新自我介绍的体验是当前对话式 AI 最影响效率的痛点之一。claude-mem这个项目从名字就能看出它的野心——给 Claude 加一层记忆。它不是官方功能而是社区里为了解决会话之间上下文丢失这个问题而衍生出来的思路和工具集合。核心目标很朴素让 AI 在跨会话、跨时间的协作中能记住你是谁、你在做什么、之前定过哪些约定从而把每一次对话从从零开始变成接着上次继续。这篇文章适合几类人看一是长期用 Claude 做开发、写作、研究被上下文丢失折磨过的重度用户二是对 AI 记忆机制、上下文管理感兴趣想自己动手搭一套方案的技术人三是想理解AI 记忆这件事到底难在哪、有哪些坑的产品和运营同学。我会从记忆的本质问题讲起拆解几种主流实现思路给出可落地的操作步骤再重点分享我在实际搭建和使用过程中踩过的坑——这些坑官方文档里基本不会写。先说一个反直觉的结论给 AI 加记忆难点从来不在存而在取和忘。存东西谁都会写个文件、建个数据库就行。但当你存了几百条记忆之后怎么在正确的时候把正确的那几条捞出来塞进上下文怎么判断哪些记忆已经过时该清理掉这才是真正决定这套方案好不好用的关键。后面几个章节我会围绕这个核心矛盾展开。2. 拆解记忆这件事短期上下文、长期记忆与检索层2.1 为什么模型本身记不住要理解 claude-mem 这类方案的价值得先搞清楚一个基础事实大语言模型本身是无状态的。每次你发一条消息模型看到的只是这一次请求里带上的全部文本它不会自动记得上一次请求说过什么。我们平时感觉它能记住对话内容是因为客户端在每次请求时把之前的对话历史一起打包发给了模型。换句话说记忆是客户端喂进去的不是模型长出来的。这就带来两个硬约束。第一上下文窗口有上限。哪怕现在窗口已经很大塞进几十万 token但对话越长成本越高、速度越慢而且模型对超长上下文中间部分的注意力会衰减——业内俗称lost in the middle。第二会话一旦关闭那段历史就散了除非你手动保存。所以跨会话记忆本质上是一个工程问题你得在模型之外自己维护一套存储和检索系统。2.2 三层记忆结构工作记忆、情景记忆、语义记忆我在实际搭建时习惯把记忆分成三层来设计这个划分借鉴了认知科学的思路落地时非常好用工作记忆Working Memory就是当前这次会话的上下文。它容量有限随会话结束而消失。对应到实现上就是每次请求拼进去的那段对话历史。情景记忆Episodic Memory记录什么时候发生了什么。比如2024年3月用户决定把项目从 A 框架迁移到 B 框架。它带时间戳有事件性。语义记忆Semantic Memory沉淀下来的、相对稳定的知识。比如用户偏好用 TypeScript缩进用 2 空格提交信息用中文。它不带具体时间是长期有效的约定。为什么要分三层因为它们的生命周期和检索方式完全不同。工作记忆用完即弃情景记忆需要按时间线检索回答上次我们聊到哪了语义记忆需要按相关性检索回答这个项目的规范是什么。如果你把所有东西一股脑塞进一个表里检索时就会互相干扰捞出来的东西又杂又不准。2.3 检索层才是真正的技术核心存储层用 SQLite、JSON 文件、向量数据库都行这部分没什么技术含量。真正拉开差距的是检索层。我见过太多人兴冲冲搭了个记忆库结果用起来发现它记是记住了但该用的时候想不起来问题全出在检索上。检索要解决三个问题相关性、时效性、优先级。相关性靠语义相似度embedding 向量检索或者关键词匹配时效性靠时间衰减越久远的记忆权重越低优先级靠人工标注或使用频率统计重要的记忆永远优先召回。一个成熟的 claude-mem 方案通常会把这三者加权组合而不是单纯依赖向量相似度。我后面会给出一个具体的加权公式和参数建议。3. 几种主流实现路线从手动粘贴到自动记忆库3.1 最土但最稳的办法结构化项目文档在动手写代码之前我想先泼一盆冷水如果你的需求没那么高频最靠谱的记忆其实是一份维护良好的项目文档。我早期就是这么干的——在项目根目录放一个CONTEXT.md里面写清楚项目背景、技术栈、命名规范、当前进度、待办事项。每次开新会话第一件事就是把这个文件内容贴进去。这个办法听起来很笨但它有几个不可替代的优点完全可控、零技术门槛、不会检索错、不会泄露隐私。缺点是手动、容易忘、文件会越来越长。我的经验是当你的记忆条目少于 50 条时手动文档的性价比远高于任何自动化方案。别一上来就追求智能记忆先把手动流程跑顺你才会真正理解自己需要自动化的到底是什么。3.2 半自动路线会话摘要 本地存储当你觉得手动粘贴太累就可以进入半自动阶段。核心思路是每次会话结束时让 Claude 自己把这次对话的要点总结成一段结构化文本你确认后存到本地文件或数据库。下次开新会话时把最近几条摘要拼进上下文。这里的关键是摘要的格式要固定。我用的模板是这样的## 会话摘要 [日期] - 主题 - 关键决策 - 待办事项 - 涉及文件/资源 - 下次继续时需要注意固定格式的好处是后续无论是人工翻阅还是程序解析都很方便。我实测下来让模型按固定模板输出比让它自由发挥的摘要质量稳定得多因为它不用每次纠结该用什么结构。3.3 全自动路线向量检索 自动召回再往上就是全自动方案把每条记忆转成向量存进向量库每次新会话开始时用当前问题去检索最相关的若干条记忆自动拼进上下文。这条路听起来最高级但坑也最多。我见过不少人搭完之后发现检索出来的记忆经常驴唇不对马嘴反而干扰了模型判断。全自动方案能不能用好取决于三个细节分块粒度、召回数量、注入位置。分块太粗一条记忆里混了太多信息检索时匹配不准分块太细一条完整的信息被拆散召回后拼不回去。召回数量太多上下文被无关记忆占满太少关键信息漏掉。注入位置也有讲究放在系统提示里还是放在用户消息前效果不一样。这些细节我在第 5 章会展开讲。3.4 三条路线的对比与选型建议路线技术门槛维护成本适用场景我的推荐度结构化文档极低中手动低频、单项目、隐私敏感强烈推荐入门会话摘要本地存储低中中频、多项目、想省事推荐向量检索自动召回高高高频、多项目、追求自动化谨慎推荐我的建议很明确从第一条路线开始用一两周记录下你每次手动粘贴时到底在粘贴什么。这份记录就是你后续自动化的需求清单。跳过这一步直接上向量库的人十有八九会做出一个看起来很智能但实际不好用的东西。4. 动手搭一套最小可用的记忆系统4.1 环境与依赖准备下面这套方案是我目前自己在用的基于 Python存储用 SQLite轻量、无需额外服务检索用简单的关键词时间加权不依赖向量库跑起来零成本。如果你后面想升级到向量检索替换检索模块即可存储层不用动。先装依赖pip install sqlite3 # 标准库自带通常无需单独安装 pip install python-dateutil pip install jieba # 中文分词用于关键词提取这里我特意没上向量库原因是对于个人使用场景关键词检索的效果往往被低估了。你的记忆条目通常就几百条关键词匹配加上时间加权召回准确率已经够用而且完全可解释——你能清楚知道为什么某条记忆被召回调试起来非常轻松。向量检索的黑盒感在调试阶段是很大的负担。4.2 数据库表结构设计我设计了三张表对应第 2 章讲的三层记忆里的后两层-- 情景记忆带时间戳的事件 CREATE TABLE episodic ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT NOT NULL, -- ISO 格式时间 project TEXT, -- 所属项目便于隔离 summary TEXT NOT NULL, -- 事件摘要 keywords TEXT, -- 逗号分隔的关键词 importance INTEGER DEFAULT 3 -- 1-5人工或自动标注 ); -- 语义记忆稳定的知识/约定 CREATE TABLE semantic ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT NOT NULL, project TEXT, content TEXT NOT NULL, -- 具体内容 keywords TEXT, importance INTEGER DEFAULT 3, last_used_at TEXT -- 上次被召回的时间 ); -- 召回日志用于分析和调优 CREATE TABLE recall_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, query TEXT, recalled_ids TEXT, -- 本次召回了哪些记忆 created_at TEXT );recall_log这张表很多人会忽略但它极其重要。没有召回日志你根本不知道你的检索到底准不准。我靠这张表发现了好几个召回错误比如某条关于数据库选型的记忆因为关键词里有数据两个字被大量无关查询召回后来我把它拆成了更精确的关键词才解决。4.3 记忆写入什么时候该记记什么写入时机很关键。我的做法是不自动记录每一句话只在两个时机触发写入。一是会话结束时让模型总结二是用户显式说记住这个时立即写入。前者保证不漏后者保证重要信息第一时间落库。写入时的摘要生成我用的提示词大致是这样请把本次对话总结为一条情景记忆严格按以下格式输出 - 摘要一句话不超过50字 - 关键词3-5个逗号分隔用于后续检索 - 重要度1-55为最重要 - 类型episodic 或 semantic这里有个小技巧让模型自己判断是情景记忆还是语义记忆。它判断得意外地准——带时间、带事件性的它归为 episodic稳定的约定它归为 semantic。你只需要在写入时按类型分表即可。4.4 记忆召回加权打分公式这是整套系统的核心。每次新会话开始用用户的第一条消息作为 query去两张表里检索按下面的公式打分score 0.5 * 关键词匹配度 0.3 * 时间衰减因子 0.2 * 重要度归一化值关键词匹配度query 分词后与记忆关键词的交集比例0 到 1。时间衰减因子exp(-天数 / 30)即 30 天衰减到约 37%。这个半衰期我调过几次30 天对大多数项目节奏比较合适。重要度归一化importance / 5。召回时取分数最高的 5 条拼成一段文本注入上下文。为什么是 5 条因为实测下来超过 5 条之后边际收益急剧下降反而挤占了本该留给当前对话的上下文空间。这个数字你可以根据自己的记忆密度调整但建议从 5 开始。4.5 把召回结果注入上下文召回之后怎么喂给模型也有讲究。我的做法是把它放在系统提示的末尾用明确的分隔标记包起来以下是来自历史记忆的参考信息可能与你当前的任务相关 请结合使用但不要盲目相信过时的内容 [记忆开始] 1. 2024-03-15项目从 A 框架迁移到 B 框架原因是... 2. 语义用户偏好 TypeScript缩进 2 空格... [记忆结束]加一句不要盲目相信过时的内容很重要。记忆是死的情况是活的。如果不加这句提醒模型有时会死板地套用一条已经过时的记忆反而帮倒忙。这个细节是我踩过坑之后才加上的后面会细说。5. 实测踩坑那些让我返工三次的细节5.1 坑一记忆污染——错误信息被反复强化这是我遇到的第一个大坑也是最隐蔽的。有一次我在会话里随口说了一句这个项目暂时用 MySQL 吧模型把它记成了语义记忆。后来项目实际改用了 PostgreSQL但那条 MySQL 的记忆一直躺在库里每次召回都被带出来模型就反复在回答里提 MySQL搞得我很长一段时间以为是自己记错了。根因记忆只增不删且没有更新机制。错误或过时的信息一旦入库就会持续污染后续所有对话。解法我给语义记忆加了版本概念。同一主题的新记忆写入时自动把旧记忆标记为superseded检索时直接过滤掉。具体做法是给 semantic 表加一个status字段active / superseded写入新记忆时用关键词匹配找出同主题的旧记忆把它们的 status 改成 superseded。这个改动不大但效果立竿见影。5.2 坑二召回噪音——关键词撞车导致的误召回前面提过数据这个词的撞车问题。类似的情况还有很多一个项目叫星火结果所有带火字的查询都会召回它一条记忆里有用户两个字结果所有提到用户的查询都把它捞出来。排查过程我是靠recall_log表发现的。具体做法是定期跑一个脚本统计每条记忆被召回的次数以及召回后是否真的被用上这个可以人工抽查。召回次数异常高但实际很少被用上的记忆基本就是噪音源。解法一是关键词去停用词把用户数据项目这类高频泛词从关键词里剔除二是提高关键词匹配的阈值要求至少匹配 2 个关键词才算命中而不是匹配 1 个就召回。这个阈值调整后误召回率下降了一大截。5.3 坑三上下文挤占——记忆太多反而变笨有一段时间我贪心把召回数量调到了 15 条想着多给点信息总没坏处。结果发现模型反而变迟钝了回答经常跑题还老是把记忆里的旧信息当成当前任务。根因上下文窗口是稀缺资源。塞进去的记忆越多留给当前对话的空间越少而且模型对长上下文中间部分的注意力会衰减等于把关键信息埋进了噪音里。解法把召回数量降回 5 条并且给每条记忆加了长度上限摘要不超过 50 字语义记忆不超过 100 字。宁可多召回几次、每次少给点也不要一次塞一大堆。这个少食多餐的原则是我调优过程中最重要的心得。5.4 坑四跨项目串味——记忆没有隔离我同时维护好几个项目一开始所有记忆都混在一个库里。结果做 A 项目时B 项目的记忆被召回进来模型就开始张冠李戴。比如 A 项目用的是 ReactB 项目用的是 Vue模型经常把两者搞混。解法给所有记忆加project字段检索时先按项目过滤只召回当前项目的记忆外加少量标记为全局的通用偏好比如代码风格。这个改动很简单但如果你不做多项目场景下基本没法用。记忆隔离是刚需不是可选项。5.5 坑五隐私与敏感信息无意入库这个坑最需要警惕。有一次我让模型帮忙处理一段包含个人信息的文本会话总结时这些信息被摘要进了记忆库。虽然存在本地但每次召回都会把它带进上下文等于反复暴露。解法我在写入前加了一道过滤用正则匹配常见的敏感模式手机号、身份证号、邮箱、密钥等命中就拒绝写入或脱敏后再写。同时会话总结的提示词里明确要求不要包含任何个人身份信息、密钥、密码。这道防线必须前置事后清理成本极高。6. 让记忆系统真正好用的几个进阶思路6.1 记忆的遗忘曲线主动清理比无限堆积更重要人的记忆会自然遗忘AI 的记忆系统也应该有。我现在的做法是语义记忆如果 90 天没有被召回自动降级为归档状态不再参与检索情景记忆如果超过 180 天且重要度低于 3直接删除。这个策略听起来有点激进但实测下来清理掉 30% 的陈旧记忆后召回准确率反而提升了。因为噪音少了真正有用的记忆更容易被捞出来。6.2 用记忆摘要做二次压缩当情景记忆积累到一定数量可以定期做一次记忆摘要把同一项目、同一主题下的多条情景记忆压缩成一条更高层的语义记忆。比如把3月1日决定用 A 方案3月5日 A 方案遇到问题3月8日改用 B 方案这三条压缩成项目初期尝试 A 方案失败3月8日改用 B 方案。这样既保留了结论又大幅减少了条目数。我一般一个月做一次用模型批量处理。6.3 人工干预接口随时能改能删再智能的自动记忆也需要人工兜底。我给自己留了几个命令/mem list列出最近记忆/mem del id删除某条/mem pin id把某条标记为永久保留不参与遗忘清理。这几个命令实现起来很简单但用起来非常安心——知道随时能改才敢放心让它自动记。6.4 效果评估怎么知道记忆系统有没有用最后说一个容易被忽略的问题你怎么判断这套系统到底有没有提升效率我的做法是记录两个指标一是重复解释次数即每次开新会话时你需要重新说明背景的次数二是任务接续顺畅度用 1-5 分主观打分。搭好系统前后各记录两周对比一下。我自己实测下来重复解释次数从平均每次会话 3 次降到了 0.5 次这个提升是实打实的。7. 关于 claude-mem 这类方案我最后想说的搭这套东西的过程中我最大的体会是AI 记忆的本质不是技术问题而是信息管理问题。你需要的不是最先进的向量库而是一套清晰的什么该记、什么该忘、什么时候取的规则。技术只是把这些规则固化下来而已。如果你现在就想动手我的建议是从第 3 章的第一条路线开始先手动维护一份CONTEXT.md坚持两周。等你真正摸清自己的记忆需求再决定要不要上自动化。别被向量检索语义记忆这些词唬住工具是为需求服务的不是反过来。还有一个我反复强调的点记忆系统一定要可解释、可干预。你能随时看到它记了什么、为什么召回某条、随时能删能改这套系统才敢长期用下去。黑盒式的自动记忆短期看着酷长期一定出问题。这套方案我还在持续迭代最近在尝试把召回日志做成一个简单的可视化面板方便一眼看出哪些记忆是高频有用、哪些是高频噪音。等跑顺了再找机会分享。如果你也在折腾类似的东西欢迎交流踩坑经验——这个领域没有标准答案多一个人踩坑就少一个人返工。
1. 从聊完就忘说起claude-mem 到底想解决什么如果你用 Claude 这类对话式 AI 做过稍微长期一点的事情比如连续几天跟进一个项目、反复迭代一份方案、或者让它在同一个代码库里帮你改东西你大概率遇到过这种尴尬昨天刚跟它讲清楚的项目背景、命名规范、目录结构今天开一个新会话它又一脸茫然地从头问起。你不得不把之前说过的话再复述一遍甚至把整段上下文重新粘贴进去。这种每次都要重新自我介绍的体验是当前对话式 AI 最影响效率的痛点之一。claude-mem这个项目从名字就能看出它的野心——给 Claude 加一层记忆。它不是官方功能而是社区里为了解决会话之间上下文丢失这个问题而衍生出来的思路和工具集合。核心目标很朴素让 AI 在跨会话、跨时间的协作中能记住你是谁、你在做什么、之前定过哪些约定从而把每一次对话从从零开始变成接着上次继续。这篇文章适合几类人看一是长期用 Claude 做开发、写作、研究被上下文丢失折磨过的重度用户二是对 AI 记忆机制、上下文管理感兴趣想自己动手搭一套方案的技术人三是想理解AI 记忆这件事到底难在哪、有哪些坑的产品和运营同学。我会从记忆的本质问题讲起拆解几种主流实现思路给出可落地的操作步骤再重点分享我在实际搭建和使用过程中踩过的坑——这些坑官方文档里基本不会写。先说一个反直觉的结论给 AI 加记忆难点从来不在存而在取和忘。存东西谁都会写个文件、建个数据库就行。但当你存了几百条记忆之后怎么在正确的时候把正确的那几条捞出来塞进上下文怎么判断哪些记忆已经过时该清理掉这才是真正决定这套方案好不好用的关键。后面几个章节我会围绕这个核心矛盾展开。2. 拆解记忆这件事短期上下文、长期记忆与检索层2.1 为什么模型本身记不住要理解 claude-mem 这类方案的价值得先搞清楚一个基础事实大语言模型本身是无状态的。每次你发一条消息模型看到的只是这一次请求里带上的全部文本它不会自动记得上一次请求说过什么。我们平时感觉它能记住对话内容是因为客户端在每次请求时把之前的对话历史一起打包发给了模型。换句话说记忆是客户端喂进去的不是模型长出来的。这就带来两个硬约束。第一上下文窗口有上限。哪怕现在窗口已经很大塞进几十万 token但对话越长成本越高、速度越慢而且模型对超长上下文中间部分的注意力会衰减——业内俗称lost in the middle。第二会话一旦关闭那段历史就散了除非你手动保存。所以跨会话记忆本质上是一个工程问题你得在模型之外自己维护一套存储和检索系统。2.2 三层记忆结构工作记忆、情景记忆、语义记忆我在实际搭建时习惯把记忆分成三层来设计这个划分借鉴了认知科学的思路落地时非常好用工作记忆Working Memory就是当前这次会话的上下文。它容量有限随会话结束而消失。对应到实现上就是每次请求拼进去的那段对话历史。情景记忆Episodic Memory记录什么时候发生了什么。比如2024年3月用户决定把项目从 A 框架迁移到 B 框架。它带时间戳有事件性。语义记忆Semantic Memory沉淀下来的、相对稳定的知识。比如用户偏好用 TypeScript缩进用 2 空格提交信息用中文。它不带具体时间是长期有效的约定。为什么要分三层因为它们的生命周期和检索方式完全不同。工作记忆用完即弃情景记忆需要按时间线检索回答上次我们聊到哪了语义记忆需要按相关性检索回答这个项目的规范是什么。如果你把所有东西一股脑塞进一个表里检索时就会互相干扰捞出来的东西又杂又不准。2.3 检索层才是真正的技术核心存储层用 SQLite、JSON 文件、向量数据库都行这部分没什么技术含量。真正拉开差距的是检索层。我见过太多人兴冲冲搭了个记忆库结果用起来发现它记是记住了但该用的时候想不起来问题全出在检索上。检索要解决三个问题相关性、时效性、优先级。相关性靠语义相似度embedding 向量检索或者关键词匹配时效性靠时间衰减越久远的记忆权重越低优先级靠人工标注或使用频率统计重要的记忆永远优先召回。一个成熟的 claude-mem 方案通常会把这三者加权组合而不是单纯依赖向量相似度。我后面会给出一个具体的加权公式和参数建议。3. 几种主流实现路线从手动粘贴到自动记忆库3.1 最土但最稳的办法结构化项目文档在动手写代码之前我想先泼一盆冷水如果你的需求没那么高频最靠谱的记忆其实是一份维护良好的项目文档。我早期就是这么干的——在项目根目录放一个CONTEXT.md里面写清楚项目背景、技术栈、命名规范、当前进度、待办事项。每次开新会话第一件事就是把这个文件内容贴进去。这个办法听起来很笨但它有几个不可替代的优点完全可控、零技术门槛、不会检索错、不会泄露隐私。缺点是手动、容易忘、文件会越来越长。我的经验是当你的记忆条目少于 50 条时手动文档的性价比远高于任何自动化方案。别一上来就追求智能记忆先把手动流程跑顺你才会真正理解自己需要自动化的到底是什么。3.2 半自动路线会话摘要 本地存储当你觉得手动粘贴太累就可以进入半自动阶段。核心思路是每次会话结束时让 Claude 自己把这次对话的要点总结成一段结构化文本你确认后存到本地文件或数据库。下次开新会话时把最近几条摘要拼进上下文。这里的关键是摘要的格式要固定。我用的模板是这样的## 会话摘要 [日期] - 主题 - 关键决策 - 待办事项 - 涉及文件/资源 - 下次继续时需要注意固定格式的好处是后续无论是人工翻阅还是程序解析都很方便。我实测下来让模型按固定模板输出比让它自由发挥的摘要质量稳定得多因为它不用每次纠结该用什么结构。3.3 全自动路线向量检索 自动召回再往上就是全自动方案把每条记忆转成向量存进向量库每次新会话开始时用当前问题去检索最相关的若干条记忆自动拼进上下文。这条路听起来最高级但坑也最多。我见过不少人搭完之后发现检索出来的记忆经常驴唇不对马嘴反而干扰了模型判断。全自动方案能不能用好取决于三个细节分块粒度、召回数量、注入位置。分块太粗一条记忆里混了太多信息检索时匹配不准分块太细一条完整的信息被拆散召回后拼不回去。召回数量太多上下文被无关记忆占满太少关键信息漏掉。注入位置也有讲究放在系统提示里还是放在用户消息前效果不一样。这些细节我在第 5 章会展开讲。3.4 三条路线的对比与选型建议路线技术门槛维护成本适用场景我的推荐度结构化文档极低中手动低频、单项目、隐私敏感强烈推荐入门会话摘要本地存储低中中频、多项目、想省事推荐向量检索自动召回高高高频、多项目、追求自动化谨慎推荐我的建议很明确从第一条路线开始用一两周记录下你每次手动粘贴时到底在粘贴什么。这份记录就是你后续自动化的需求清单。跳过这一步直接上向量库的人十有八九会做出一个看起来很智能但实际不好用的东西。4. 动手搭一套最小可用的记忆系统4.1 环境与依赖准备下面这套方案是我目前自己在用的基于 Python存储用 SQLite轻量、无需额外服务检索用简单的关键词时间加权不依赖向量库跑起来零成本。如果你后面想升级到向量检索替换检索模块即可存储层不用动。先装依赖pip install sqlite3 # 标准库自带通常无需单独安装 pip install python-dateutil pip install jieba # 中文分词用于关键词提取这里我特意没上向量库原因是对于个人使用场景关键词检索的效果往往被低估了。你的记忆条目通常就几百条关键词匹配加上时间加权召回准确率已经够用而且完全可解释——你能清楚知道为什么某条记忆被召回调试起来非常轻松。向量检索的黑盒感在调试阶段是很大的负担。4.2 数据库表结构设计我设计了三张表对应第 2 章讲的三层记忆里的后两层-- 情景记忆带时间戳的事件 CREATE TABLE episodic ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT NOT NULL, -- ISO 格式时间 project TEXT, -- 所属项目便于隔离 summary TEXT NOT NULL, -- 事件摘要 keywords TEXT, -- 逗号分隔的关键词 importance INTEGER DEFAULT 3 -- 1-5人工或自动标注 ); -- 语义记忆稳定的知识/约定 CREATE TABLE semantic ( id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT NOT NULL, project TEXT, content TEXT NOT NULL, -- 具体内容 keywords TEXT, importance INTEGER DEFAULT 3, last_used_at TEXT -- 上次被召回的时间 ); -- 召回日志用于分析和调优 CREATE TABLE recall_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, query TEXT, recalled_ids TEXT, -- 本次召回了哪些记忆 created_at TEXT );recall_log这张表很多人会忽略但它极其重要。没有召回日志你根本不知道你的检索到底准不准。我靠这张表发现了好几个召回错误比如某条关于数据库选型的记忆因为关键词里有数据两个字被大量无关查询召回后来我把它拆成了更精确的关键词才解决。4.3 记忆写入什么时候该记记什么写入时机很关键。我的做法是不自动记录每一句话只在两个时机触发写入。一是会话结束时让模型总结二是用户显式说记住这个时立即写入。前者保证不漏后者保证重要信息第一时间落库。写入时的摘要生成我用的提示词大致是这样请把本次对话总结为一条情景记忆严格按以下格式输出 - 摘要一句话不超过50字 - 关键词3-5个逗号分隔用于后续检索 - 重要度1-55为最重要 - 类型episodic 或 semantic这里有个小技巧让模型自己判断是情景记忆还是语义记忆。它判断得意外地准——带时间、带事件性的它归为 episodic稳定的约定它归为 semantic。你只需要在写入时按类型分表即可。4.4 记忆召回加权打分公式这是整套系统的核心。每次新会话开始用用户的第一条消息作为 query去两张表里检索按下面的公式打分score 0.5 * 关键词匹配度 0.3 * 时间衰减因子 0.2 * 重要度归一化值关键词匹配度query 分词后与记忆关键词的交集比例0 到 1。时间衰减因子exp(-天数 / 30)即 30 天衰减到约 37%。这个半衰期我调过几次30 天对大多数项目节奏比较合适。重要度归一化importance / 5。召回时取分数最高的 5 条拼成一段文本注入上下文。为什么是 5 条因为实测下来超过 5 条之后边际收益急剧下降反而挤占了本该留给当前对话的上下文空间。这个数字你可以根据自己的记忆密度调整但建议从 5 开始。4.5 把召回结果注入上下文召回之后怎么喂给模型也有讲究。我的做法是把它放在系统提示的末尾用明确的分隔标记包起来以下是来自历史记忆的参考信息可能与你当前的任务相关 请结合使用但不要盲目相信过时的内容 [记忆开始] 1. 2024-03-15项目从 A 框架迁移到 B 框架原因是... 2. 语义用户偏好 TypeScript缩进 2 空格... [记忆结束]加一句不要盲目相信过时的内容很重要。记忆是死的情况是活的。如果不加这句提醒模型有时会死板地套用一条已经过时的记忆反而帮倒忙。这个细节是我踩过坑之后才加上的后面会细说。5. 实测踩坑那些让我返工三次的细节5.1 坑一记忆污染——错误信息被反复强化这是我遇到的第一个大坑也是最隐蔽的。有一次我在会话里随口说了一句这个项目暂时用 MySQL 吧模型把它记成了语义记忆。后来项目实际改用了 PostgreSQL但那条 MySQL 的记忆一直躺在库里每次召回都被带出来模型就反复在回答里提 MySQL搞得我很长一段时间以为是自己记错了。根因记忆只增不删且没有更新机制。错误或过时的信息一旦入库就会持续污染后续所有对话。解法我给语义记忆加了版本概念。同一主题的新记忆写入时自动把旧记忆标记为superseded检索时直接过滤掉。具体做法是给 semantic 表加一个status字段active / superseded写入新记忆时用关键词匹配找出同主题的旧记忆把它们的 status 改成 superseded。这个改动不大但效果立竿见影。5.2 坑二召回噪音——关键词撞车导致的误召回前面提过数据这个词的撞车问题。类似的情况还有很多一个项目叫星火结果所有带火字的查询都会召回它一条记忆里有用户两个字结果所有提到用户的查询都把它捞出来。排查过程我是靠recall_log表发现的。具体做法是定期跑一个脚本统计每条记忆被召回的次数以及召回后是否真的被用上这个可以人工抽查。召回次数异常高但实际很少被用上的记忆基本就是噪音源。解法一是关键词去停用词把用户数据项目这类高频泛词从关键词里剔除二是提高关键词匹配的阈值要求至少匹配 2 个关键词才算命中而不是匹配 1 个就召回。这个阈值调整后误召回率下降了一大截。5.3 坑三上下文挤占——记忆太多反而变笨有一段时间我贪心把召回数量调到了 15 条想着多给点信息总没坏处。结果发现模型反而变迟钝了回答经常跑题还老是把记忆里的旧信息当成当前任务。根因上下文窗口是稀缺资源。塞进去的记忆越多留给当前对话的空间越少而且模型对长上下文中间部分的注意力会衰减等于把关键信息埋进了噪音里。解法把召回数量降回 5 条并且给每条记忆加了长度上限摘要不超过 50 字语义记忆不超过 100 字。宁可多召回几次、每次少给点也不要一次塞一大堆。这个少食多餐的原则是我调优过程中最重要的心得。5.4 坑四跨项目串味——记忆没有隔离我同时维护好几个项目一开始所有记忆都混在一个库里。结果做 A 项目时B 项目的记忆被召回进来模型就开始张冠李戴。比如 A 项目用的是 ReactB 项目用的是 Vue模型经常把两者搞混。解法给所有记忆加project字段检索时先按项目过滤只召回当前项目的记忆外加少量标记为全局的通用偏好比如代码风格。这个改动很简单但如果你不做多项目场景下基本没法用。记忆隔离是刚需不是可选项。5.5 坑五隐私与敏感信息无意入库这个坑最需要警惕。有一次我让模型帮忙处理一段包含个人信息的文本会话总结时这些信息被摘要进了记忆库。虽然存在本地但每次召回都会把它带进上下文等于反复暴露。解法我在写入前加了一道过滤用正则匹配常见的敏感模式手机号、身份证号、邮箱、密钥等命中就拒绝写入或脱敏后再写。同时会话总结的提示词里明确要求不要包含任何个人身份信息、密钥、密码。这道防线必须前置事后清理成本极高。6. 让记忆系统真正好用的几个进阶思路6.1 记忆的遗忘曲线主动清理比无限堆积更重要人的记忆会自然遗忘AI 的记忆系统也应该有。我现在的做法是语义记忆如果 90 天没有被召回自动降级为归档状态不再参与检索情景记忆如果超过 180 天且重要度低于 3直接删除。这个策略听起来有点激进但实测下来清理掉 30% 的陈旧记忆后召回准确率反而提升了。因为噪音少了真正有用的记忆更容易被捞出来。6.2 用记忆摘要做二次压缩当情景记忆积累到一定数量可以定期做一次记忆摘要把同一项目、同一主题下的多条情景记忆压缩成一条更高层的语义记忆。比如把3月1日决定用 A 方案3月5日 A 方案遇到问题3月8日改用 B 方案这三条压缩成项目初期尝试 A 方案失败3月8日改用 B 方案。这样既保留了结论又大幅减少了条目数。我一般一个月做一次用模型批量处理。6.3 人工干预接口随时能改能删再智能的自动记忆也需要人工兜底。我给自己留了几个命令/mem list列出最近记忆/mem del id删除某条/mem pin id把某条标记为永久保留不参与遗忘清理。这几个命令实现起来很简单但用起来非常安心——知道随时能改才敢放心让它自动记。6.4 效果评估怎么知道记忆系统有没有用最后说一个容易被忽略的问题你怎么判断这套系统到底有没有提升效率我的做法是记录两个指标一是重复解释次数即每次开新会话时你需要重新说明背景的次数二是任务接续顺畅度用 1-5 分主观打分。搭好系统前后各记录两周对比一下。我自己实测下来重复解释次数从平均每次会话 3 次降到了 0.5 次这个提升是实打实的。7. 关于 claude-mem 这类方案我最后想说的搭这套东西的过程中我最大的体会是AI 记忆的本质不是技术问题而是信息管理问题。你需要的不是最先进的向量库而是一套清晰的什么该记、什么该忘、什么时候取的规则。技术只是把这些规则固化下来而已。如果你现在就想动手我的建议是从第 3 章的第一条路线开始先手动维护一份CONTEXT.md坚持两周。等你真正摸清自己的记忆需求再决定要不要上自动化。别被向量检索语义记忆这些词唬住工具是为需求服务的不是反过来。还有一个我反复强调的点记忆系统一定要可解释、可干预。你能随时看到它记了什么、为什么召回某条、随时能删能改这套系统才敢长期用下去。黑盒式的自动记忆短期看着酷长期一定出问题。这套方案我还在持续迭代最近在尝试把召回日志做成一个简单的可视化面板方便一眼看出哪些记忆是高频有用、哪些是高频噪音。等跑顺了再找机会分享。如果你也在折腾类似的东西欢迎交流踩坑经验——这个领域没有标准答案多一个人踩坑就少一个人返工。
