Claude 每次对话都像金鱼记忆这事儿用过的人应该都深有体会上午聊完的项目方案下午换个会话窗口再问它一脸茫然好像你们从没认识过。我自己被这个问题折磨了挺长时间直到折腾出一个叫 claude-mem 的记忆增强方案才算是把 Claude 真正变成了记得住事的长期伙伴。这篇博文就把我完整实现 claude-mem 的过程、原理、踩过的坑全部摊开来讲适合那些把 Claude 当日常生产力工具、又苦于它记性差的深度用户也适合刚开始接触 AI 记忆增强思路、想搞明白这套机制到底怎么运转的新手朋友。1. 项目概述claude-mem 到底解决了什么痛点1.1 先看清 Claude 原生记忆的天花板Claude 本身不是完全没有记忆能力——它在单个对话上下文窗口里能记住你前面聊过的所有内容这也是它能承接复杂多轮任务的基础。但问题恰恰出在单个对话这四个字上。一旦你关闭会话、开启新对话或者上下文窗口被撑满之前的所有信息就像被格式化了一样全部归零。这带来的实际困扰是很具体的。我做技术调研的时候经常是上午让 Claude 分析了一组架构方案下午想让它基于上午的结论继续深化设计结果它完全不记得上午聊过什么我只能把关键结论重新粘贴一遍。更烦的是有些背景信息是长期稳定的比如我用的技术栈是前后端分离我负责的是电商业务线我不喜欢过于激进的方案这些内容每次新对话都得重新交代一遍极其消耗耐心。我现在做的这套 claude-mem 方案目标非常明确给 Claude 装上一种长期记忆能力让它跨会话记住关键信息和历史对话摘要。这不是修改 Claude 本身的模型权重而是在外层加一套记忆的读写机制——对话结束后自动沉淀记忆新对话开始时自动召回相关记忆再喂给 Claude。模型还是那个模型但它的知识起点变了从一无所知变成带着历史认知上场。1.2 claude-mem 能做什么适合谁用claude-mem 这个名字我自己的理解是 Claude Memory 的缩写本质是一个记忆管理层。它做的事情可以拆成三条第一自动沉淀。每次对话跑完它会把对话内容做摘要和关键信息抽取变成可检索的记忆条目存进本地不用你手动整理。第二智能召回。新对话开启时它会根据当前对话的主题和上下文从记忆库里筛出相关的历史信息自动注入到 Claude 的系统提示词或首轮消息里。第三持续进化。随着使用次数增加记忆库越来越丰富Claude 对你的了解也越来越深体验上的表现就是它越来越懂你了。适合用这套方案的人画像很清晰高频使用 Claude 做复杂工作的人比如程序员让它写代码、做架构设计产品经理让它整理需求、写 PRD研究者让它读文献、梳理思路以及所有对 AI 助手连续性有要求的人。反过来如果你只是偶尔用 Claude 聊聊天、问几个百科问题那记忆增强对你来说性价比不高因为每次对话都是独立任务没必要维护一个长期记忆库。2. 核心机制拆解记忆是怎么存得下、找得着、用得上的2.1 整体架构夹在 Claude 外层的记忆读写层claude-mem 不修改 Claude 本身而是在中间加了一个处理层。我把它理解成三个模块沉淀器、存储器和召回器。沉淀器负责读对话。它监听你和 Claude 的对话过程在对话结束或达到一定节点时把这段对话的完整文本提取出来交给摘要模型做压缩提炼出用户偏好项目背景决定结论待办事项这些有长期价值的信息。存储器负责写记忆。经过提炼的信息不能被随便一堆就完事它需要有结构。我在实际实现里用的是混合方案重要条目以结构化文本存成 Markdown 或 JSON 文件同时给每一条做向量化处理生成 embedding 向量存进本地向量数据库这样后面才能做语义检索。召回器负责读记忆——但它不是把所有记忆都一股脑扔给 Claude那样会撑爆上下文而是根据当前对话的主题做相关性排序只挑最相关的几条拼接成一段记忆上下文注入到 Claude 的对话信息里。这套架构最关键的一点是记忆只作为输入存在。Claude 看到的是系统提示词 记忆上下文 你的新问题所有对话还是正常走但它的回答会被记忆影响。这也是它安全的根本原因——记忆不是改模型只是影响模型的输入。2.2 为什么用向量检索关键词匹配根本不够用这里要展开讲讲检索方式的选择因为这是很多人做记忆功能最容易翻车的地方。最开始我想得比较简单把记忆条目存成文本文件用户新提问时直接在文件里做关键词匹配把含有关键词的条目召回。比如用户问上次说的那个支付方案我就匹配支付方案四个字。听起来可行实际一用就露馅——Claude 对话里的表达太灵活了同样一个意思上午说支付方案下午可能说结算流程再往后说交易链路。关键词匹配只能命中字面相同的条目语义相近但表述不同的内容全部漏掉。所以 claude-mem 的检索层必须走语义向量这条路。做法是每条记忆文本先用 embedding 模型转成一个高维向量存在向量数据库里用户的新问题也用同一个 embedding 模型转成向量然后计算用户问题向量和每一条记忆向量的余弦相似度相似度高的记忆条目就被召回来。用个生活类比可能更好懂关键词匹配是按标题找书你得知道书名里有那几个字才能找到向量检索是按内容意思找书你说我想看一本讲怎么把菜做得不那么咸的书系统能找到那本标题是《低钠饮食入门》的册子因为意思相近。这就是语义检索的核心优势。2.3 摘要这一步决定了记忆质量的上限记忆不是把原始对话全文存下来全文存下来既占空间又难检索。我在 claude-mem 里做了两层提炼。第一层是对话级摘要。一次完整的对话结束后把整个对话文本交给摘要模型产出三块内容对话核心讨论了什么、得出了什么结论、有哪些关键决定。这相当于给一次会话写一个会议纪要。第二层是实体级记忆抽取。从对话里找到那些跨会话稳定的信息比如用户负责的是某某系统的后端开发用户偏好 TypeScript用户上次提到有个截止日期是月底。这些都是长期稳定的背景信息属于最有价值的记忆类型。这里有个实操体会实体抽取比摘要更重要。因为摘要描述的是某一次对话发生了什么但实体积淀下来的是用户是谁、偏好什么、项目背景是什么后者才是跨会话真正需要复用的东西。我自己在写提示词模板的时候会把实体抽取的权重放得很高输出格式强制要求 JSON 结构化确保每一条记忆都带标签、带时间戳、带过期标记方便后续管理。3. 实操落地完整部署 claude-mem 的步骤细节3.1 环境准备与依赖选型先交代环境。我是在 macOS 上跑的整条链路用的是 Python 3.11因为生态里的向量库和 embedding 工具对 3.10 以上版本支持更稳。如果你要用 Windows道理一样就是文件路径和终端命令有差异。依赖清单我列一下核心的sqlite-vec 或者 ChromaDB二选一做向量存储。我用的 ChromaDB它轻量、嵌入式、不需要单独跑服务对个人工具来说非常友好一个pip install chromadb就搞定。sentence-transformers做 embedding 向量化。我用的是all-MiniLM-L6-v2这个模型体积小、速度快、中文效果虽然谈不上顶尖但够用关键是本地跑不花钱。如果对中文语义要求高可以换BAAI/bge-small-zh-v1.5效果更好但模型文件大一些。anthropic 官方 SDK用来和 Claude API 交互这是整个链路里的消息出入口。安装的命令我实测下来比较顺的是pip install anthropic chromadb sentence-transformers装完之后建议先做一个最小验证跑一段 Python确认能成功导入 anthropic 客户端、能加载 embedding 模型、能创建 Chroma 集合。这一步提前排掉依赖冲突后面就不会手忙脚乱。提示如果你在用某个国内镜像源注意确认 chromadb 依赖的 onnxruntime 能正确安装这玩意儿在部分 Python 版本上容易出编译问题。遇到就直接换 Python 3.11 的干净虚拟环境别在旧环境里硬磨。3.2 配置项精心设计记忆库不是越大越好claude-mem 的配置文件我用的 YAML核心参数就这么几组memory: storage_path: ./memory_store collection_name: claude_mem max_recall_items: 5 embedding: model_name: BAAI/bge-small-zh-v1.5 device: cpu claude: model: claude-sonnet-4-20250514 system_prompt: 你是一个有长期记忆的AI助手... temperature: 0.7这里有几个配置是我反复调过的值得单独讲讲。max_recall_items指的是每次会话最多召回几条记忆。我一开始设的是 10结果 Claude 的回答经常被一堆旧记忆干扰显得啰嗦后来调到 5信息密度刚好既不丢关键背景也不淹没问题本身。这个参数是个典型的不是越大越好的配置它取决于你召回的准度而不是数量。temperature我建议在记忆场景下保持 0.3-0.7 区间。因为 Claude 的输入里多了一段记忆上下文如果参数太高它容易把记忆内容和当前问题混在一起发挥产生幻觉。我长期保持在 0.5稳中有创意。storage_path建议放在一个独立目录不要和项目代码混在一起这样既方便备份也方便查问题——你随时可以打开目录看里面的记忆文件长什么样。3.3 核心实现沉淀、存储、召回三段代码这部分我直接把代码骨架写出来你拿去改改就能跑。沉淀模块对话结束后提取记忆import json from anthropic import Anthropic client Anthropic(api_key你的Key) def extract_memories(conversation_text: str) - dict: prompt f 你是一个记忆提炼助手。阅读下面的对话提取出跨会话有价值的信息。 输出JSON格式包含两个字段 1. summary: 对话摘要不超过3句话 2. entities: 数组每个元素包含「type」(用户偏好/项目背景/决定结论/待办事项)、「content」、「timestamp」 对话内容 {conversation_text} resp client.messages.create( modelclaude-sonnet-4-20250514, max_tokens1500, messages[{role: user, content: prompt}] ) return json.loads(resp.content[0].text)这一段就是沉淀器的全部逻辑。我用自己的真实对话测过把一段两千字的对话压成摘要加几条实体效果非常理想尤其决定结论和待办事项这些实体后续召回的价值极高。存储模块写入向量库import chromadb from sentence_transformers import SentenceTransformer encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) chroma_client chromadb.PersistentClient(path./memory_store) collection chroma_client.get_or_create_collection(claude_mem) def store_memories(entities: list[str]): vectors encoder.encode(entities).tolist() ids [fmem_{i}_{hash(e) % 10000} for i, e in enumerate(entities)] collection.add(idsids, documentsentities, embeddingsvectors) print(f已存储 {len(entities)} 条记忆)我在这里踩过一个坑第一次跑的时候没有把 embedding 向量显式传进去结果 Chroma 默认用它的内置 embedding 函数重新算和我召回时用的句子模型不一致导致召回结果一团糟。后来统一在 add 和 query 两端都显式传同一个编码器的向量问题立刻解决。召回模块根据新问题找记忆def recall_memories(query: str, top_k: int 5): q_vec encoder.encode(query).tolist() results collection.query(query_embeddings[q_vec], n_resultstop_k) return results[documents][0]召回的核心就是这五行代码。拿到召回文本之后拼一段系统提示词再发起真正的 Claude 请求。我实际使用的系统提示词模板是这样你是一个具备长期记忆能力的AI助手。以下是你记忆中与当前对话相关的历史信息 {recalled_memories_str} 请结合这些记忆回答用户当前的问题。如果记忆与问题无关请忽略记忆直接回答。那个如果记忆与问题无关则忽略是非常关键的护栏。它给了 Claude 一个明确的记忆仅供参考的定位避免模型因为上下文里有旧信息就强行往上面靠。3.4 与 Claude 对接的完整链路完整链路只需要三步。第一步用户发起新对话系统先拿用户的首条问题去查询记忆库。第二步把召回的记忆拼到系统提示词里连问题一起发给 Claude。第三步Claude 返回回答后把整段对话输入沉淀模块抽出新记忆存进库。这三步里第一步和第三步很容易被忽略但恰好是记忆闭环最关键的两端。没有第一步记忆只存不取纯属浪费没有第三步每次对话都是单发模式记忆库永远不会变厚。把这三步串起来跑才是完整的 claude-mem。我实际用下来单次对话的额外耗时主要花在向量化上一个查询文本的向量化大约几十到一百毫秒加一次数据库查询整体体感几乎无延迟。沉淀模块因为要再调一次 Claude 做摘要会慢一些但它是异步在后台跑的不影响用户主流程。4. 使用场景与调优实践让记忆真正服务你的工作流4.1 三个典型场景编程、写作、项目管理我给自己配置好 claude-mem 之后最先感受到的变化在编程场景。之前让 Claude 维护一个项目的代码每次新会话它都要重新读一遍项目结构、技术栈、代码风格现在这些信息早就沉淀在记忆库里了新会话一开始它就带着你用的是 FastAPI React前端组件偏好函数式写法后端接口风格是 RESTful这些背景直接干活省掉了大量重复交代。写作场景的效果同样明显。我让 Claude 帮我写技术文章之前它经常把语气写得过于正式、术语堆砌、没有个人风格后来记忆库里沉淀了作者偏好短句、喜欢用生活化类比、讨厌空话套话这些偏好之后产出的文字风格贴合度明显提升。这就相当于写作前先给 Claude 开了一个风格定调会。项目管理场景是 claude-mem 的进阶用法。我把每周的项目复盘对话都沉淀下来记忆库会持续累积项目背景、决策原因、待办事项。到第六周的时候我可以直接问我们这六周踩过哪些坑Claude 能基于召回的历史记忆给出一个跨周汇总结论这在没有记忆机制的时候是完全做不到的。4.2 记忆的生命周期管理会过期、会废弃、手动整理不要以为记忆存进去就能永远用不管理的话记忆库过几个月就会变成一团混乱。我自己制定了一套记忆清理规范分享给你们。第一实体层记忆要做过期标记。比如项目的上线时间是下周五这条记忆到周六就失效了如果不做过期标记Claude 会一直把已经过去的时间当作未来时间。我的做法是在实体提取时就让它输出一个expires字段没有明确过期时间的就写 null召回时系统自动过滤掉已过期的条目。第二要对记忆做去重和合并。同一个事实可能被沉淀出多条相似记录比如用户偏好使用 pnpm这句话在不同对话里出现三次。我跑了一个定期清理脚本按 embedding 向量算相似度相似度高于 0.9 的就合并成一条保留最新时间戳。这个脚本一个月跑一次就够了不用很频繁。第三手动维护必需。自动沉淀的准确率不是 100%总会有一些内容偏离真实情况。我建议每两周打开记忆库目录看一眼把明显不准确的条目删掉。这不是技术活但非常重要相当于隔一段时间给 AI 的记忆做一次体检。4.3 效果调优的三个关键旋钮如果你觉得 claude-mem 的表现不如预期大概率是下面三个旋钮没有调到合适的档位。第一个是召回数量max_recall_items。回答显得啰嗦就往下调回答缺乏上下文就往上调。我前面说了 5 是个好起点但你要是做跨周复盘这种需要大量历史信息的任务临时调到 8 也没问题。第二个是 embedding 模型的选型。本地小模型速度快但语义理解弱云端大模型效果好但每个请求都有额外延时和成本。我的建议是先跑本地小模型如果中文场景下明显召回不相关的内容再换更好的本地中文模型比如 bge 系列。不要一上来就上最大的模型先用最简单的链路跑通再逐步优化效果。第三个是把召回条目的时间加权加进去。同样的相似度得分最近发生的记忆应该排更前面。实现方式也很简单在查询结果的 score 上做一个时间衰减比如final_score similarity * 0.9 recency_score * 0.1就能让新记忆更容易被召回老记忆在相似度不足时自然沉底。5. 常见问题与排查实录我踩过的坑全记录5.1 最经典的三个问题与解决办法第一个高频问题召回结果完全不相关。我复盘过很多次原因十有八九是 embedding 不一致——存储时用 A 模型算向量查询时用 B 模型算向量两边的向量空间都不一样语义匹配当然失效。解决方式就一句话存储和查询必须用同一个编码器而且要在 Chroma 的add和query两端都显式传向量不要依赖它内置的默认向量化逻辑。第二个高频问题Claude 的回答被记忆带偏。表现出来就是记忆里有一条不相关的旧信息Claude 却硬往上面扯回答文不对题。我在系统提示词里加了一句如果记忆与当前问题无关请直接忽略记忆效果立竿见影。这其实是提示工程的问题模型本身没有错是你没有给它足够的决策自由度。第三个高频问题记忆库文件越攒越大越来越慢。Chroma 的本地文件经过长期写入确实会膨胀。我的做法是定期重建集合把全部记忆导出成 JSON 文本备份然后删掉旧集合重新建一个再重新写进去。这个过程半个小时能跑完之后检索速度能快一倍。5.2 容易被忽略的三个细节教训我还要特别提醒三个不说没人告诉你的细节。第一个API 的 max_tokens 别设太小。沉淀模块要调 Claude 生成 JSON 摘要一次生成的内容可能超过一千 token如果你 max_tokens 设的 500它会在 JSON 没写完时就被截断然后json.loads直接报错。我第一次跑就栽在这上面排查了半天才明白是截断问题。记住沉淀模块的 max_tokens 至少给 1500。第二个向量化放后台跑。沉淀模块涉及一次完整的 Claude API 调用耗时可能三五秒如果放在用户等待的主流程里体验会很崩。我把沉淀改成异步任务对话结束之后它自己在后台跑用户无感知这是 claude-mem 做成正常工具的必备设计。第三个本地记忆库注意备份。它存的是你工作历史上最核心的信息比代码仓库还值钱。我已经养成了每周 tar 一次整个 memory_store 目录的习惯扔到网盘或 NAS 里成本几秒钟但万一哪天磁盘炸了AI 的记忆也不会丢。5.3 从金鱼到象脑子claude-mem 后续还能怎么扩展这个项目做到现在我觉得它只是一个起点。往上至少还有两个方向值得折腾一是让记忆库支持多用户隔离团队场景下每个人的记忆互不干扰但项目共享记忆可以互通这会把它从个人工具变成团队协作的基础设施二是把记忆召回的决策流从相似度排序升级成可配置的规则引擎比如最近三天内的记忆优先用户主动标记为重要的记忆永远置顶这样记忆管理就从被动变成主动了。我一直觉得AI 助手离真正的助手还差两步第一步是它记得住你第二步是它懂你。claude-mem 这套方案解决的问题是第一步但它搭出来的架构完全可以朝着第二步继续长。我自己接下来的计划是让记忆库里的实体信息形成一个用户画像文件每个季度自动更新一次然后把画像注入到系统提示词里让 Claude 在每个新对话的起点就知道它面对的是一个怎样的人。这件事做成了AI 助手的体验会再上一个台阶那已经不是金鱼和象的区别而是一个真正贴心的搭档了。