你是不是也有这种感觉跟AI助手聊了几个月它却连你的名字都记不住。每次新开一个会话它都像第一天上班那样客客气气你被迫把项目背景、代码规范、个人偏好从头到尾再讲一遍。我这次做的这个小项目claude-mem就是想解决这个真正的痛点——给Claude装上一层可持续累积的长期记忆让它不再是每次对话都失忆的打工人。claude-mem名字已经说明了一切它就是Claude的memory。它不是去改动Claude模型本身而是作为一层外部记忆系统在Claude和你的真实会话之间搭一座桥。它只做三件核心的事把对话里值得长期保存的信息自动抽出来、存好下次你提问时把相关的历史记忆打捞回来塞进上下文然后持续更新和整理自己的记忆库让它越用越顺手、越用越懂你。这个项目最适合三类人一是重度使用Claude做编码和架构设计的开发者告别每次都要重新介绍项目结构的尴尬二是长期跟踪同一课题的研究型用户需要让AI记住阅读进度和关键结论三是所有被AI需要重复交代背景折磨过的普通使用者。这篇博客我会从设计思路、技术选型、核心实现到踩坑实录把整个项目从头到尾拆开讲清楚。1. 项目起源与核心设计思路1.1 AI对话的失忆症到底有多痛先说痛点。Claude这类大模型本质上是无状态的——每次调用都是独立的模型只看到你这次提交的上下文除此之外它对你是谁、你做过什么、你上次讨论到哪一概不知。这不怪模型而是它的工作方式决定的注意力机制的窗口就那么大不可能把人类几个月的历史对话都装进去。但工作场景下的真实需求恰恰相反。我维护一个中大型开源项目时每天要问Claude的问题至少有几十个涉及模块设计、接口规范、历史决策理由。如果每次对话前都要先把之前两三个小时的讨论结论复述一遍这个时间成本几乎等于没用AI。更崩溃的是有时候你讲完背景它给出的答案和你上次已经确认过的结论刚好冲突——因为它根本不知道你已经排除了那个方案。我尝试过一些替代方案比如开一个超长会话不关闭把历史全堆在上下文里。但很快发现token开销大得离谱回答变慢费用也直线上升。会话一旦达到长度上限前面早讨论出的结论照样被截断和失忆没区别。后来又试过手工维护一个背景文档每次提问前人工复制粘贴——效果还行但太累而且文档经常忘记更新过几天就过期了。claude-mem的灵感正是来自这种反复碰壁。与其靠人的自律去维护记忆不如让系统在对话过程中自动沉淀记忆再在合适的时机自动召回。这个方向做下来效果比我预想的好得多。1.2 设计目标像一个贴身助理而不是一个数据库这个项目立项时我给自己定了三条原则后来每一步决策都在向这三条靠拢。第一条记忆必须自动沉淀。用户不应该有保存记忆这个额外动作。只要对话在正常进行系统就应当悄无声息地把值得记录的信息抽出来。我后来实现时采用了对话轮次触发 会话结束扫描双保险机制确保不遗漏关键信息。第二条记忆必须精准召回。塞进上下文的东西不是越多越好而是越准越好。每条多余的记忆都是对模型注意力的浪费甚至会造成混淆。所以召回质量是整个系统的生命线我在相似度阈值、排序策略、数量上限上花了大量功夫。第三条记忆必须可管理。用户要能查看系统记住了什么、随时删掉不该记的东西。记忆是隐私的延伸不能变成一个黑盒。我提供了CLI查询和可视化面板两个入口后面会详细讲。这三条原则其实对应了记忆系统的三个核心环节写入Memory Write、存储Memory Store、召回Memory Recall。我在设计架构的时候也坚持把这三个环节彻底解耦每一层都可以单独替换。这样做的好处是如果以后有更好的向量模型我只需要换掉召回模块完全不影响其他部分。2. 整体架构与技术选型解析2.1 记忆分层的思路一开始我曾想做一个通用的全局记忆库所有信息都堆在一起需要时统一检索。但这个方向很快就翻车了——不同类型的记忆生命周期和重要性差异极大混在一起既污染检索结果也不便于管理。举个例子用户叫张伟、偏好TypeScript、讨厌代码里出现any这类信息是长期稳定的属于用户画像层几乎每次对话都该被考虑。某某模块尚未完成、上轮讨论决定采用事件驱动架构这类是项目状态层会随项目推进而变化。昨天你让我先跑一遍测试再提PR这类是临时任务层可能一天后就失效了。我把记忆分成四层用户画像层Profile、项目语义层Semantic、任务状态层Task和对话摘要层Episode。每层有不同的保留策略——用户画像永久保留项目语义按有效性衰减任务状态完成后标记归档对话摘要则定期压缩合并成更上层的长期记忆。这个设计类似人的记忆机制短期记忆经过睡眠巩固变成长期记忆而不是把所有鸡毛蒜皮都原样保存。这个分层后来被证明是项目成功的关键之一。没有分层时检索路由是个大难题——你问上次那个bug后来怎么修的结果系统把用户喜欢喝美式咖啡也当相似内容返回了因为它们的向量空间可能恰好接近。分层之后每一层单独建索引、单独召回语义干扰小了非常多。2.2 存储选型为什么是SQLite加向量索引存储层的选型我在三个方案之间权衡了很久纯JSON文件、SQLite、专门的向量数据库如Chroma、Qdrant。纯JSON文件最轻量但检索完全靠暴力遍历记忆一多就扛不住。向量数据库检索很强但对本地单机场景来说太重了还得单独跑一个服务进程依赖太多。最后我选了SQLite作为主存储配合一个可选的外部向量索引。SQLite是单文件数据库不需要额外服务进程部署成本几乎为零事务能力强悍还支持全文搜索扩展FTS5。我的记忆条目由结构化字段和长文内容组成用SQLite管理再合适不过。向量索引这部分我默认使用本地运行的sentence-transformers/all-MiniLM-L6-v2模型把记忆内容转成384维向量直接序列化存在同一张表的embedding字段里。检索时用余弦相似度在内存里做粗排再用关键词匹配做精排。这个组合方案既保证了一定的语义召回能力又没有任何外部服务依赖单机跑起来非常顺。如果你有更大的语料规模或更高的精度要求我也预留了适配层可以对接Chroma或pgvector。接口我已经定义好了切换只是改配置的事。2.3 上下文注入1%的上下文80%的体验提升Claude的上下文窗口不管多大本质上是稀缺资源。把记忆无脑全塞进去不但浪费token还会稀释模型对当前问题的注意力。我在设计上下文注入策略时给自己定的纪律是注入的记忆总量控制在当前上下文token上限的1%到2%以内。具体策略分三步第一步根据当前用户问题做向量召回拿到Top-30候选记忆第二步用规则和轻量模型做重排剔除与当前问题无关的、过期的、互相矛盾的记忆第三步按类型配额选择最终注入条目——通常用户画像层最多2条项目语义层最多2条任务状态层最多1条对话摘要层最多1条。总条数上限默认5条超出就压缩合并。这个少量精准的策略在实际体验中效果远好过大量覆盖。你给模型灌一百条背景它反而不知道重点在哪。但只给五条最相关的记忆它会非常明确地围绕你当前的问题行动。这也是整个项目里投入产出比最高的一项优化。3. 核心功能拆解与实现细节3.1 记忆写入什么时候提取、怎么提取记忆的写入是整个系统最容易出问题的环节。写得太勤会存一堆噪声写得太懒又漏掉关键信息。我最后采用的是双触发策略每满6轮对话自动做一次增量提取会话结束时再补一次全面扫描。提取过程分两段。第一段是规则筛选——先从句式特征上判断哪些对话值得进入记忆。比如出现我喜欢我习惯我们决定注意千万别以后不要这类带长期语义的信号词就直接标记为高优先级候选。第二段是LLM抽取——把候选对话和已有记忆库一起交给模型让它输出结构化记忆条目每条包含内容、类型、重要性和有效性四个字段并和已有记忆做去重。提取提示词的模板大致长这样 从下面的对话中提取值得长期记忆的信息。 只提取对将来对话有实际帮助的内容忽略寒暄和临时情绪。 输出JSON数组每个元素包含 - content: 记忆内容保留具体细节 - memory_type: user_profile / project_semantic / task_state / episode_summary - importance: 0-10的整数10为极重要 - valid_until: 过期时间永久留空 对话内容 ... 已有记忆供去重参考 ...这里有一个我踩过的坑如果让模型自由提取它倾向于把用户今天心情不好也写成长期记忆因为情感信息在LLM看来很有记下来的价值。但实际上这类情绪碎片对长期工作毫无帮助反而会干扰判断。我的对策是在提示词里加了反向说明明确忽略情绪性、临时性、闲聊性内容。做了这个调整之后记忆库的噪声水平直线下降。3.2 记忆存储表结构设计与降噪机制存储层的表结构并不复杂但也远比一张表存所有要精细。核心表memory_items包含几个关键字段字段类型说明idTEXT主键UUIDuser_idTEXT用户标识支持多用户隔离session_idTEXT来源会话memory_typeTEXT记忆分层类型contentTEXT记忆正文metadataTEXTJSON存标签、实体名等辅助信息embeddingBLOB384维向量序列化importanceINTEGER0-10created_atINTEGER创建时间戳last_hit_atINTEGER最近一次被召回的时间hit_countINTEGER累计召回次数is_activeINTEGER0/1软删除标记last_hit_at和hit_count这两个字段一开始我并没打算加后来发现它们是记忆健康度的晴雨表。我写了一个定期清理任务超过90天没有被召回过的低重要度记忆自动标记为不活跃超过180天没有被召回过的直接软删除。这保证了记忆库长期保持精炼不会越积越满、检索越来越慢。去重方面除了写入时做语义相似度判断合并新内容外我还会对同类型记忆做版本化处理。比如用户的偏好从喜欢JavaScript变成优先TypeScript旧条目不会直接删掉而是标记deprecated并引用新条目查询时只返回最新版本。这样即使记忆更新了历史的变更有迹可循不会因为错误合并而丢失信息。3.3 记忆召回从相关到有用的最后一公里召回环节最微妙的一点是模型判断相关和我们判断有用往往是两码事。向量相似度高不一定真的有用尤其是当问题里带了很多通用词汇时容易召回到一堆泛泛而谈的记忆。我的召回链路是四段式召回→重排→配额→格式化。召回阶段用当前用户消息的向量和记忆库里所有活跃条目做余弦相似度计算取出Top-30。这里的相似度阈值默认0.35低于这个的干脆不取。阈值太高容易漏太低容易噪这个0.35是我在本地测试集上调出来的你的场景可能不一样后面会讲怎么调。重排阶段按三要素打分向量相似度占50%、记忆新鲜度last_hit_at距离现在越近分越高占30%、记忆重要性占20%。这样即使一条记忆向量得分稍低但如果它昨天刚被用过且很重要也会排在前面。格式化阶段把选中的记忆拼装成语义自然的前缀追加到用户消息之前。这步很关键——直接用JSON格式灌给模型它也能理解但理解效率差不少。我用模板块拼装出下面这种形式[长期记忆参考] 以下是从历史对话中提取的与本问题相关的信息 - 用户偏好后端使用Python/FastAPI数据库使用PostgreSQL不接受在核心链路引入Redis。 - 项目状态订单服务模块尚未完成已确定事件驱动方案消息队列选用RabbitMQ。 - 近期任务用户今天要求先完善接口文档再开始写单元测试。用自然语言而不是原始JSON模型可以更快把记忆内容融入到回答逻辑中。这个小改动让回答的贴切感提升了一个档次。4. 实操过程从零接入claude-mem4.1 安装与初始化配置claude-mem的安装很简单。如果你只想快速体验直接通过包管理器装pip install claude-mem如果你打算改代码、用自己的记忆模型就Clone源码git clone https://github.com/yourname/claude-mem.git cd claude-mem pip install -e .安装完后第一次启动要跑初始化命令它会自动创建数据目录和配置文件claude-mem init默认数据目录在~/.claude-mem/下包含config.yaml和memory.db。第一次运行建议打开config.yaml确认几个关键参数因为它们决定了系统的记忆行为memory: max_inject_count: 5 # 单次最大注入条数 similarity_threshold: 0.35 # 召回相似度阈值 extract_interval_rounds: 6 # 对话轮次触发间隔 importance_min: 4 # 写入最低重要度 enable_auto_extract: true # 是否开启自动提取 vector: model_name: sentence-transformers/all-MiniLM-L6-v2 dimension: 384 storage: db_path: ~/.claude-mem/memory.db enable_fts: true # 启用全文搜索 retention_days: 180 # 未命中保留天数importance_min这个参数很容易被忽略但特别重要。它设定了记忆写入的重要度门槛只有模型评估为4分以上的信息才允许入库。调高它可以让记忆库更精炼调低则更完整、但噪声更多。我自己的配置是4你可以根据自己的容忍度调整。4.2 接入对话流程的两种方式claude-mem接入实际对话流程我支持两种方式。第一种作为MCP工具接入。如果你用的是Claude桌面端可以在配置文件里添加MCP Server注册{ mcpServers: { claude-mem: { command: claude-mem, args: [mcp-server], env: { CLAUDE_MEM_CONFIG: ~/.claude-mem/config.yaml } } } }这样Claude在每次对话中会自动调用claude-mem提供的工具——search_memory、save_memory、update_memory、delete_memory。模型会在它认为合适的时候调用这些工具来查询或写入记忆。这是最省心的方式用户完全无感知。第二种代理模式接入。如果你没有桌面端或者想在命令行或者自己的脚本中接入可以用代理模式claude-mem proxy --api-key $ANTHROPIC_API_KEY --port 8080启动后你的API请求发给本地8080端口代理会自动做记忆注入和提取再转发给Claude。这个模式更灵活适合放在自己的自动化流程里。我平时写代码用的就是这种模式因为可以精确控制哪些消息流经记忆层。4.3 验证记忆效果一次真实的测试接入完成后我建议照着下面这个流程测试你的记忆层是否正常工作。第一步在第一个会话里说几条明显的偏好性信息我以后写Python函数都要加类型注解。本项目数据库统一用PostgreSQL。这个模块的接口变更必须要更新OpenAPI文档。第二步等对话超过6轮或者直接说请记住这些确保记忆被提取。然后查看记忆库claude-mem list --type user_profile此时应该能看到三条独立的记忆条目并且内容基本准确。第三步新开一个会话问一句和第一条偏好相关的问题给我一个用户登录的函数注意结合我的编码习惯。如果没有记忆层Claude会给出一个普普通通的函数。有了记忆层它应当主动生成带完整类型注解、用PostgreSQL风格SQL的示例。如果它做到了说明记忆注入这条链路是通的。第四步检查召回日志claude-mem stats这个命令会显示每次召回命中了哪几条记忆、相似度得分多少、注入消耗了多少token。实测下来我自己的项目注入成本大约占单次对话token总量的1.2%左右完全可接受。5. 常见问题与排查技巧实录5.1 记忆完全不生效排查链路长什么样最常遇到的问题就是我设置了记忆但新会话里Claude完全没反应。遇到这种情况别慌按照下面这条链路逐层排查。第一层确认记忆真的写入了。运行claude-mem list --all看有没有条目。如果没有问题在前面检查提取触发条件——是不是对话轮次不够6轮重要度是否低于4被过滤了信号词规则是不是没触发第二层确认召回真的执行了。开启调试日志claude-mem proxy --debug然后重新提问。看日志里有没有recall操作、命中了几条记忆、相似度得分是多少。如果相似度全部低于0.35阈值说明你的提问方式和记忆内容差异太大需要适当降低阈值。第三层确认记忆真的注入进了上下文。在调试日志里查看最终的请求体看系统消息或者用户消息前面有没有长期记忆参考段落。如果没有可能是注入模块被enable_inject: false关掉了或者上下文配额已经满了。这一套排查下来90%的问题都能定位到。核心思路是记忆写入、召回、注入是三个独立环节哪个环节断了就在哪个环节查日志。别一上来就改模型、换数据库。5.2 上下文超限和token成本失控有段时间我贪心把max_inject_count调到了15结果对话质量反而下降token成本翻倍甚至偶尔触发上下文超限。后来我意识到记忆注入和对话本身是在抢占同一份上下文预算必须给记忆设一个显式的预算上限。我最终的策略是固定配额 动态压缩单个记忆条目内容超过200字符的自动用LLM压缩成不超过80字符的关键信息摘要再注入所有注入记忆的总字符数不超过800字符。这样既控制了token又保证了信息的广度。实测中800字符的记忆注入对对话质量提升最明显再往上就是边际递减了。如果确实有大量历史知识需要模型参考别走记忆注入这条路而是把详细内容写入一个单独的知识库文件在需要时让模型用工具读取。这是记忆层和知识库的分工记忆层管高频、轻量、跨会话的上下文知识库管低频、重量、文档化的信息。5.3 记忆串台和过时信息干扰记忆系统用久了一定会遇到记忆串台——几个项目的信息混在一起或者旧决策和新决策打架。比如用户在不同项目里用过不同的技术栈模型可能把A项目的经验搬到B项目上。串台问题的根源是记忆库里不同实体的区分度不够。我的解决方案是引入项目命名空间Project Namespace。给每条记忆打上project标签召回时优先检索当前激活项目的记忆只有当前项目为空时才回退到全局记忆。这个改动极大降低了串台概率。过时信息干扰则是另一个问题。项目状态变了旧记忆还在库里模型参考到旧信息就可能给出错误建议。我的对策是主动失效机制如果新记忆和旧记忆在同一类型下冲突写入新记忆时自动将旧记忆标记为conflicted并设置deprecated_at。同时定期运行claude-mem prune把已弃用的记忆归档到历史表不再参与召回。5.4 隐私与数据隔离隐私问题我放在最后说因为它最容易被忽略、但真的出事最麻烦。claude-mem默认把数据库文件放在用户目录下权限设置为仅当前用户可读写。如果你处理的是敏感数据建议开启SQLite加密扩展或者直接把数据库放到加密卷里。多用户共用一台机器时务必给每个用户单独的数据库文件并通过user_id字段隔离数据。我见过有人直接把全公司的记忆库混在一个库文件里结果A同事问技术问题被注入了一条属于B同事的项目决策记忆场面相当尴尬。另外claude-mem的记忆写入和召回都是本地完成的不会把记忆内容发给第三方。但如果你的Claude API请求本身要发到远端执行那么注入进上下文的记忆会随请求一起发送——这个要在隐私要求极高的场景下特别注意。我给系统的设计里保留了--no-inject-sensitive开关开启后涉及敏感标签的记忆条目会被拦截不参与任何注入。6. 进阶玩法与后续规划6.1 多代理共享记忆和长期Agentclaude-mem目前的定位是单用户、跨会话的记忆层。但我在接口设计时预留了user_id维度这为多代理共享记忆铺了路。想象这样一个场景你有三个Agent一个负责代码审查一个负责文档维护一个负责CI/CD配置。它们各自和Claude交互但共享同一个项目记忆库。这样代码审查Agent作出的技术决策文档Agent在下一次更新文档时能自然参考到。实现上只需要给每个Agent分配不同的session_id和agent_id记忆召回时按项目命名空间过滤即可。目前agent_id字段已经在表结构中预留下一步我会把它做成正式的一等公民。6.2 记忆可视化与管理面板记忆系统跑久了用户一定需要定期审视AI到底记住了我什么。命令行工具虽然强大但对非技术用户不够友好。我目前正在开发一个本地Web面板用gradio或streamlit实现展示所有记忆条目、召回热度热力图、冲突记忆提示并提供一键删除和导出功能。这个面板加上后台自动清理任务就能形成一个完整的记忆生命周期管理闭环自动写入、精准召回、定期清理、用户可查。我的目标是可以完全做到让用户忘了记忆层的存在但它一直在正确工作。6.3 关于这个项目的一些真心话做完claude-mem之后我有个很明显的感受给AI加记忆这件事技术挑战其实不在模型而在工程——怎么判断哪些信息值得记怎么平衡召回精度和成本怎么避免旧信息干扰新决策。这个过程里我试过把所有历史暴力塞进上下文token爆炸、试过只依赖向量召回串台严重、试过让模型每次对话都提炼记忆噪声爆棚最后才沉淀出现在这套分层、配额、双触发提取的方案。如果你也打算做一个类似的记忆层我想给你三个在我实际使用中被验证过的建议第一记忆一定要分层没有分层的记忆库就是一锅粥第二注入宁可少而精也不要多而杂给窗口留白第三尽早考虑记忆的清理和隐私问题这两个问题越晚处理越被动。claude-mem目前已经能稳定支撑我的日常开发工作流最近一次连续使用已经超过一个月记忆库积累了两千多条条目对话注入的token开销稳定控制在2%以内。后面我会继续完善多代理共享和可视化面板让这个记忆层真正变成所有AI交互的基础设施。你如果也在被AI失忆症困扰不妨照着这篇文章的思路搭一套自己的记忆层用起来你就能体会到——一个真正记得住你的AI和普通的AI完全是两个物种。
你是不是也有这种感觉跟AI助手聊了几个月它却连你的名字都记不住。每次新开一个会话它都像第一天上班那样客客气气你被迫把项目背景、代码规范、个人偏好从头到尾再讲一遍。我这次做的这个小项目claude-mem就是想解决这个真正的痛点——给Claude装上一层可持续累积的长期记忆让它不再是每次对话都失忆的打工人。claude-mem名字已经说明了一切它就是Claude的memory。它不是去改动Claude模型本身而是作为一层外部记忆系统在Claude和你的真实会话之间搭一座桥。它只做三件核心的事把对话里值得长期保存的信息自动抽出来、存好下次你提问时把相关的历史记忆打捞回来塞进上下文然后持续更新和整理自己的记忆库让它越用越顺手、越用越懂你。这个项目最适合三类人一是重度使用Claude做编码和架构设计的开发者告别每次都要重新介绍项目结构的尴尬二是长期跟踪同一课题的研究型用户需要让AI记住阅读进度和关键结论三是所有被AI需要重复交代背景折磨过的普通使用者。这篇博客我会从设计思路、技术选型、核心实现到踩坑实录把整个项目从头到尾拆开讲清楚。1. 项目起源与核心设计思路1.1 AI对话的失忆症到底有多痛先说痛点。Claude这类大模型本质上是无状态的——每次调用都是独立的模型只看到你这次提交的上下文除此之外它对你是谁、你做过什么、你上次讨论到哪一概不知。这不怪模型而是它的工作方式决定的注意力机制的窗口就那么大不可能把人类几个月的历史对话都装进去。但工作场景下的真实需求恰恰相反。我维护一个中大型开源项目时每天要问Claude的问题至少有几十个涉及模块设计、接口规范、历史决策理由。如果每次对话前都要先把之前两三个小时的讨论结论复述一遍这个时间成本几乎等于没用AI。更崩溃的是有时候你讲完背景它给出的答案和你上次已经确认过的结论刚好冲突——因为它根本不知道你已经排除了那个方案。我尝试过一些替代方案比如开一个超长会话不关闭把历史全堆在上下文里。但很快发现token开销大得离谱回答变慢费用也直线上升。会话一旦达到长度上限前面早讨论出的结论照样被截断和失忆没区别。后来又试过手工维护一个背景文档每次提问前人工复制粘贴——效果还行但太累而且文档经常忘记更新过几天就过期了。claude-mem的灵感正是来自这种反复碰壁。与其靠人的自律去维护记忆不如让系统在对话过程中自动沉淀记忆再在合适的时机自动召回。这个方向做下来效果比我预想的好得多。1.2 设计目标像一个贴身助理而不是一个数据库这个项目立项时我给自己定了三条原则后来每一步决策都在向这三条靠拢。第一条记忆必须自动沉淀。用户不应该有保存记忆这个额外动作。只要对话在正常进行系统就应当悄无声息地把值得记录的信息抽出来。我后来实现时采用了对话轮次触发 会话结束扫描双保险机制确保不遗漏关键信息。第二条记忆必须精准召回。塞进上下文的东西不是越多越好而是越准越好。每条多余的记忆都是对模型注意力的浪费甚至会造成混淆。所以召回质量是整个系统的生命线我在相似度阈值、排序策略、数量上限上花了大量功夫。第三条记忆必须可管理。用户要能查看系统记住了什么、随时删掉不该记的东西。记忆是隐私的延伸不能变成一个黑盒。我提供了CLI查询和可视化面板两个入口后面会详细讲。这三条原则其实对应了记忆系统的三个核心环节写入Memory Write、存储Memory Store、召回Memory Recall。我在设计架构的时候也坚持把这三个环节彻底解耦每一层都可以单独替换。这样做的好处是如果以后有更好的向量模型我只需要换掉召回模块完全不影响其他部分。2. 整体架构与技术选型解析2.1 记忆分层的思路一开始我曾想做一个通用的全局记忆库所有信息都堆在一起需要时统一检索。但这个方向很快就翻车了——不同类型的记忆生命周期和重要性差异极大混在一起既污染检索结果也不便于管理。举个例子用户叫张伟、偏好TypeScript、讨厌代码里出现any这类信息是长期稳定的属于用户画像层几乎每次对话都该被考虑。某某模块尚未完成、上轮讨论决定采用事件驱动架构这类是项目状态层会随项目推进而变化。昨天你让我先跑一遍测试再提PR这类是临时任务层可能一天后就失效了。我把记忆分成四层用户画像层Profile、项目语义层Semantic、任务状态层Task和对话摘要层Episode。每层有不同的保留策略——用户画像永久保留项目语义按有效性衰减任务状态完成后标记归档对话摘要则定期压缩合并成更上层的长期记忆。这个设计类似人的记忆机制短期记忆经过睡眠巩固变成长期记忆而不是把所有鸡毛蒜皮都原样保存。这个分层后来被证明是项目成功的关键之一。没有分层时检索路由是个大难题——你问上次那个bug后来怎么修的结果系统把用户喜欢喝美式咖啡也当相似内容返回了因为它们的向量空间可能恰好接近。分层之后每一层单独建索引、单独召回语义干扰小了非常多。2.2 存储选型为什么是SQLite加向量索引存储层的选型我在三个方案之间权衡了很久纯JSON文件、SQLite、专门的向量数据库如Chroma、Qdrant。纯JSON文件最轻量但检索完全靠暴力遍历记忆一多就扛不住。向量数据库检索很强但对本地单机场景来说太重了还得单独跑一个服务进程依赖太多。最后我选了SQLite作为主存储配合一个可选的外部向量索引。SQLite是单文件数据库不需要额外服务进程部署成本几乎为零事务能力强悍还支持全文搜索扩展FTS5。我的记忆条目由结构化字段和长文内容组成用SQLite管理再合适不过。向量索引这部分我默认使用本地运行的sentence-transformers/all-MiniLM-L6-v2模型把记忆内容转成384维向量直接序列化存在同一张表的embedding字段里。检索时用余弦相似度在内存里做粗排再用关键词匹配做精排。这个组合方案既保证了一定的语义召回能力又没有任何外部服务依赖单机跑起来非常顺。如果你有更大的语料规模或更高的精度要求我也预留了适配层可以对接Chroma或pgvector。接口我已经定义好了切换只是改配置的事。2.3 上下文注入1%的上下文80%的体验提升Claude的上下文窗口不管多大本质上是稀缺资源。把记忆无脑全塞进去不但浪费token还会稀释模型对当前问题的注意力。我在设计上下文注入策略时给自己定的纪律是注入的记忆总量控制在当前上下文token上限的1%到2%以内。具体策略分三步第一步根据当前用户问题做向量召回拿到Top-30候选记忆第二步用规则和轻量模型做重排剔除与当前问题无关的、过期的、互相矛盾的记忆第三步按类型配额选择最终注入条目——通常用户画像层最多2条项目语义层最多2条任务状态层最多1条对话摘要层最多1条。总条数上限默认5条超出就压缩合并。这个少量精准的策略在实际体验中效果远好过大量覆盖。你给模型灌一百条背景它反而不知道重点在哪。但只给五条最相关的记忆它会非常明确地围绕你当前的问题行动。这也是整个项目里投入产出比最高的一项优化。3. 核心功能拆解与实现细节3.1 记忆写入什么时候提取、怎么提取记忆的写入是整个系统最容易出问题的环节。写得太勤会存一堆噪声写得太懒又漏掉关键信息。我最后采用的是双触发策略每满6轮对话自动做一次增量提取会话结束时再补一次全面扫描。提取过程分两段。第一段是规则筛选——先从句式特征上判断哪些对话值得进入记忆。比如出现我喜欢我习惯我们决定注意千万别以后不要这类带长期语义的信号词就直接标记为高优先级候选。第二段是LLM抽取——把候选对话和已有记忆库一起交给模型让它输出结构化记忆条目每条包含内容、类型、重要性和有效性四个字段并和已有记忆做去重。提取提示词的模板大致长这样 从下面的对话中提取值得长期记忆的信息。 只提取对将来对话有实际帮助的内容忽略寒暄和临时情绪。 输出JSON数组每个元素包含 - content: 记忆内容保留具体细节 - memory_type: user_profile / project_semantic / task_state / episode_summary - importance: 0-10的整数10为极重要 - valid_until: 过期时间永久留空 对话内容 ... 已有记忆供去重参考 ...这里有一个我踩过的坑如果让模型自由提取它倾向于把用户今天心情不好也写成长期记忆因为情感信息在LLM看来很有记下来的价值。但实际上这类情绪碎片对长期工作毫无帮助反而会干扰判断。我的对策是在提示词里加了反向说明明确忽略情绪性、临时性、闲聊性内容。做了这个调整之后记忆库的噪声水平直线下降。3.2 记忆存储表结构设计与降噪机制存储层的表结构并不复杂但也远比一张表存所有要精细。核心表memory_items包含几个关键字段字段类型说明idTEXT主键UUIDuser_idTEXT用户标识支持多用户隔离session_idTEXT来源会话memory_typeTEXT记忆分层类型contentTEXT记忆正文metadataTEXTJSON存标签、实体名等辅助信息embeddingBLOB384维向量序列化importanceINTEGER0-10created_atINTEGER创建时间戳last_hit_atINTEGER最近一次被召回的时间hit_countINTEGER累计召回次数is_activeINTEGER0/1软删除标记last_hit_at和hit_count这两个字段一开始我并没打算加后来发现它们是记忆健康度的晴雨表。我写了一个定期清理任务超过90天没有被召回过的低重要度记忆自动标记为不活跃超过180天没有被召回过的直接软删除。这保证了记忆库长期保持精炼不会越积越满、检索越来越慢。去重方面除了写入时做语义相似度判断合并新内容外我还会对同类型记忆做版本化处理。比如用户的偏好从喜欢JavaScript变成优先TypeScript旧条目不会直接删掉而是标记deprecated并引用新条目查询时只返回最新版本。这样即使记忆更新了历史的变更有迹可循不会因为错误合并而丢失信息。3.3 记忆召回从相关到有用的最后一公里召回环节最微妙的一点是模型判断相关和我们判断有用往往是两码事。向量相似度高不一定真的有用尤其是当问题里带了很多通用词汇时容易召回到一堆泛泛而谈的记忆。我的召回链路是四段式召回→重排→配额→格式化。召回阶段用当前用户消息的向量和记忆库里所有活跃条目做余弦相似度计算取出Top-30。这里的相似度阈值默认0.35低于这个的干脆不取。阈值太高容易漏太低容易噪这个0.35是我在本地测试集上调出来的你的场景可能不一样后面会讲怎么调。重排阶段按三要素打分向量相似度占50%、记忆新鲜度last_hit_at距离现在越近分越高占30%、记忆重要性占20%。这样即使一条记忆向量得分稍低但如果它昨天刚被用过且很重要也会排在前面。格式化阶段把选中的记忆拼装成语义自然的前缀追加到用户消息之前。这步很关键——直接用JSON格式灌给模型它也能理解但理解效率差不少。我用模板块拼装出下面这种形式[长期记忆参考] 以下是从历史对话中提取的与本问题相关的信息 - 用户偏好后端使用Python/FastAPI数据库使用PostgreSQL不接受在核心链路引入Redis。 - 项目状态订单服务模块尚未完成已确定事件驱动方案消息队列选用RabbitMQ。 - 近期任务用户今天要求先完善接口文档再开始写单元测试。用自然语言而不是原始JSON模型可以更快把记忆内容融入到回答逻辑中。这个小改动让回答的贴切感提升了一个档次。4. 实操过程从零接入claude-mem4.1 安装与初始化配置claude-mem的安装很简单。如果你只想快速体验直接通过包管理器装pip install claude-mem如果你打算改代码、用自己的记忆模型就Clone源码git clone https://github.com/yourname/claude-mem.git cd claude-mem pip install -e .安装完后第一次启动要跑初始化命令它会自动创建数据目录和配置文件claude-mem init默认数据目录在~/.claude-mem/下包含config.yaml和memory.db。第一次运行建议打开config.yaml确认几个关键参数因为它们决定了系统的记忆行为memory: max_inject_count: 5 # 单次最大注入条数 similarity_threshold: 0.35 # 召回相似度阈值 extract_interval_rounds: 6 # 对话轮次触发间隔 importance_min: 4 # 写入最低重要度 enable_auto_extract: true # 是否开启自动提取 vector: model_name: sentence-transformers/all-MiniLM-L6-v2 dimension: 384 storage: db_path: ~/.claude-mem/memory.db enable_fts: true # 启用全文搜索 retention_days: 180 # 未命中保留天数importance_min这个参数很容易被忽略但特别重要。它设定了记忆写入的重要度门槛只有模型评估为4分以上的信息才允许入库。调高它可以让记忆库更精炼调低则更完整、但噪声更多。我自己的配置是4你可以根据自己的容忍度调整。4.2 接入对话流程的两种方式claude-mem接入实际对话流程我支持两种方式。第一种作为MCP工具接入。如果你用的是Claude桌面端可以在配置文件里添加MCP Server注册{ mcpServers: { claude-mem: { command: claude-mem, args: [mcp-server], env: { CLAUDE_MEM_CONFIG: ~/.claude-mem/config.yaml } } } }这样Claude在每次对话中会自动调用claude-mem提供的工具——search_memory、save_memory、update_memory、delete_memory。模型会在它认为合适的时候调用这些工具来查询或写入记忆。这是最省心的方式用户完全无感知。第二种代理模式接入。如果你没有桌面端或者想在命令行或者自己的脚本中接入可以用代理模式claude-mem proxy --api-key $ANTHROPIC_API_KEY --port 8080启动后你的API请求发给本地8080端口代理会自动做记忆注入和提取再转发给Claude。这个模式更灵活适合放在自己的自动化流程里。我平时写代码用的就是这种模式因为可以精确控制哪些消息流经记忆层。4.3 验证记忆效果一次真实的测试接入完成后我建议照着下面这个流程测试你的记忆层是否正常工作。第一步在第一个会话里说几条明显的偏好性信息我以后写Python函数都要加类型注解。本项目数据库统一用PostgreSQL。这个模块的接口变更必须要更新OpenAPI文档。第二步等对话超过6轮或者直接说请记住这些确保记忆被提取。然后查看记忆库claude-mem list --type user_profile此时应该能看到三条独立的记忆条目并且内容基本准确。第三步新开一个会话问一句和第一条偏好相关的问题给我一个用户登录的函数注意结合我的编码习惯。如果没有记忆层Claude会给出一个普普通通的函数。有了记忆层它应当主动生成带完整类型注解、用PostgreSQL风格SQL的示例。如果它做到了说明记忆注入这条链路是通的。第四步检查召回日志claude-mem stats这个命令会显示每次召回命中了哪几条记忆、相似度得分多少、注入消耗了多少token。实测下来我自己的项目注入成本大约占单次对话token总量的1.2%左右完全可接受。5. 常见问题与排查技巧实录5.1 记忆完全不生效排查链路长什么样最常遇到的问题就是我设置了记忆但新会话里Claude完全没反应。遇到这种情况别慌按照下面这条链路逐层排查。第一层确认记忆真的写入了。运行claude-mem list --all看有没有条目。如果没有问题在前面检查提取触发条件——是不是对话轮次不够6轮重要度是否低于4被过滤了信号词规则是不是没触发第二层确认召回真的执行了。开启调试日志claude-mem proxy --debug然后重新提问。看日志里有没有recall操作、命中了几条记忆、相似度得分是多少。如果相似度全部低于0.35阈值说明你的提问方式和记忆内容差异太大需要适当降低阈值。第三层确认记忆真的注入进了上下文。在调试日志里查看最终的请求体看系统消息或者用户消息前面有没有长期记忆参考段落。如果没有可能是注入模块被enable_inject: false关掉了或者上下文配额已经满了。这一套排查下来90%的问题都能定位到。核心思路是记忆写入、召回、注入是三个独立环节哪个环节断了就在哪个环节查日志。别一上来就改模型、换数据库。5.2 上下文超限和token成本失控有段时间我贪心把max_inject_count调到了15结果对话质量反而下降token成本翻倍甚至偶尔触发上下文超限。后来我意识到记忆注入和对话本身是在抢占同一份上下文预算必须给记忆设一个显式的预算上限。我最终的策略是固定配额 动态压缩单个记忆条目内容超过200字符的自动用LLM压缩成不超过80字符的关键信息摘要再注入所有注入记忆的总字符数不超过800字符。这样既控制了token又保证了信息的广度。实测中800字符的记忆注入对对话质量提升最明显再往上就是边际递减了。如果确实有大量历史知识需要模型参考别走记忆注入这条路而是把详细内容写入一个单独的知识库文件在需要时让模型用工具读取。这是记忆层和知识库的分工记忆层管高频、轻量、跨会话的上下文知识库管低频、重量、文档化的信息。5.3 记忆串台和过时信息干扰记忆系统用久了一定会遇到记忆串台——几个项目的信息混在一起或者旧决策和新决策打架。比如用户在不同项目里用过不同的技术栈模型可能把A项目的经验搬到B项目上。串台问题的根源是记忆库里不同实体的区分度不够。我的解决方案是引入项目命名空间Project Namespace。给每条记忆打上project标签召回时优先检索当前激活项目的记忆只有当前项目为空时才回退到全局记忆。这个改动极大降低了串台概率。过时信息干扰则是另一个问题。项目状态变了旧记忆还在库里模型参考到旧信息就可能给出错误建议。我的对策是主动失效机制如果新记忆和旧记忆在同一类型下冲突写入新记忆时自动将旧记忆标记为conflicted并设置deprecated_at。同时定期运行claude-mem prune把已弃用的记忆归档到历史表不再参与召回。5.4 隐私与数据隔离隐私问题我放在最后说因为它最容易被忽略、但真的出事最麻烦。claude-mem默认把数据库文件放在用户目录下权限设置为仅当前用户可读写。如果你处理的是敏感数据建议开启SQLite加密扩展或者直接把数据库放到加密卷里。多用户共用一台机器时务必给每个用户单独的数据库文件并通过user_id字段隔离数据。我见过有人直接把全公司的记忆库混在一个库文件里结果A同事问技术问题被注入了一条属于B同事的项目决策记忆场面相当尴尬。另外claude-mem的记忆写入和召回都是本地完成的不会把记忆内容发给第三方。但如果你的Claude API请求本身要发到远端执行那么注入进上下文的记忆会随请求一起发送——这个要在隐私要求极高的场景下特别注意。我给系统的设计里保留了--no-inject-sensitive开关开启后涉及敏感标签的记忆条目会被拦截不参与任何注入。6. 进阶玩法与后续规划6.1 多代理共享记忆和长期Agentclaude-mem目前的定位是单用户、跨会话的记忆层。但我在接口设计时预留了user_id维度这为多代理共享记忆铺了路。想象这样一个场景你有三个Agent一个负责代码审查一个负责文档维护一个负责CI/CD配置。它们各自和Claude交互但共享同一个项目记忆库。这样代码审查Agent作出的技术决策文档Agent在下一次更新文档时能自然参考到。实现上只需要给每个Agent分配不同的session_id和agent_id记忆召回时按项目命名空间过滤即可。目前agent_id字段已经在表结构中预留下一步我会把它做成正式的一等公民。6.2 记忆可视化与管理面板记忆系统跑久了用户一定需要定期审视AI到底记住了我什么。命令行工具虽然强大但对非技术用户不够友好。我目前正在开发一个本地Web面板用gradio或streamlit实现展示所有记忆条目、召回热度热力图、冲突记忆提示并提供一键删除和导出功能。这个面板加上后台自动清理任务就能形成一个完整的记忆生命周期管理闭环自动写入、精准召回、定期清理、用户可查。我的目标是可以完全做到让用户忘了记忆层的存在但它一直在正确工作。6.3 关于这个项目的一些真心话做完claude-mem之后我有个很明显的感受给AI加记忆这件事技术挑战其实不在模型而在工程——怎么判断哪些信息值得记怎么平衡召回精度和成本怎么避免旧信息干扰新决策。这个过程里我试过把所有历史暴力塞进上下文token爆炸、试过只依赖向量召回串台严重、试过让模型每次对话都提炼记忆噪声爆棚最后才沉淀出现在这套分层、配额、双触发提取的方案。如果你也打算做一个类似的记忆层我想给你三个在我实际使用中被验证过的建议第一记忆一定要分层没有分层的记忆库就是一锅粥第二注入宁可少而精也不要多而杂给窗口留白第三尽早考虑记忆的清理和隐私问题这两个问题越晚处理越被动。claude-mem目前已经能稳定支撑我的日常开发工作流最近一次连续使用已经超过一个月记忆库积累了两千多条条目对话注入的token开销稳定控制在2%以内。后面我会继续完善多代理共享和可视化面板让这个记忆层真正变成所有AI交互的基础设施。你如果也在被AI失忆症困扰不妨照着这篇文章的思路搭一套自己的记忆层用起来你就能体会到——一个真正记得住你的AI和普通的AI完全是两个物种。
