Claude 的记忆确实不行这个开源项目让它脱胎换骨过去一年里我把 Claude 当成日常写作、编程和数据分析的主力工具说实话它的单次对话能力很强但有个问题一直很让人头疼你上午跟它确认了写作风格偏好下午新开一个会话它又完全不记得了。每次都要重新介绍背景、重新贴规则、重新强调“别用列表开头”——这种重复劳动消耗的耐心比模型本身偶尔的“幻觉”更让人崩溃。所以当我在 GitHub 上刷到 claude-mem 这个项目时第一反应是终于有人对“Claude 的失忆症”下手了。claude-mem 的核心思路非常直接——给 Claude 装一个长期记忆层让它在跨会话场景下还能记住你的偏好、项目背景、常用术语甚至是之前的决定和推理过程。它不是 OpenAI 那种官方记忆功能的平替而是针对 Claude 的使用场景做的社区方案。这篇文章会把它拆开来讲清楚它是怎么设计的、底层存储和提取逻辑是什么、我实际跑下来踩了哪些坑、以及如果你也想给 Claude 加一份“长期记忆”参考什么方案最靠谱。无论你是 Claude 的重度用户还是平时只拿它写写周报只要被“每次都要重复交代背景”折磨过这个项目都值得了解一下。1. 整体设计思路为什么 Claude 需要外挂记忆层先搞清楚一个问题Claude 原生为什么“记不住”这跟模型架构有关大语言模型本身是无状态的每次对话都是独立推理上下文窗口结束之后之前的 token 就彻底被丢弃了。所以不管你多用心地跟它聊了几千字的背景“新会话”对它来说就是一场全新的初遇。商业产品比如 ChatGPT 做了官方记忆功能但那是封闭系统里的黑盒实现用户无法控制记忆的内容、格式和存储位置。而很多用 API 或第三方客户端重度使用 Claude 的人需要的恰恰是“让我自己来管记忆”的方案——比如记忆存本地、按项目隔离、能随时编辑和删除。claude-mem 就是顺着这个需求走的。它把“记忆”拆成了三层事实层用户告诉它的稳定信息比如“我是后端工程师”“项目名是 X”“数据库用的是 PostgreSQL”。偏好层关于回答方式和输出风格的规则比如“代码示例要带注释”“回复控制在 300 字以内”“不要使用 emoji”。经验层过去对话中产生的决定、结论和约定比如“上轮讨论确定用 Redis 做缓存不再考虑 Memcached”。这个分层设计是关键。因为如果只做“把历史对话原文合并进下一次请求”那很快会把上下文撑爆而且大量无关信息还会干扰 Claude 的回答质量。claude-mem 的做法是每次对话结束后做一次“记忆提取”把有价值的稳定信息提炼成结构化条目存进本地数据库下一次开新会话时再把这些条目注入系统提示词。这样既保留了长期记忆又不至于让记忆变成噪音。这也是它和其他“会话记录保存”类工具最大的区别——它的重点不是“回放历史”而是“提炼并复用”。从工程角度看这就是一个典型的 ETL 流程从非结构化对话中抽取信息转换格式加载到存储再在恰当的时机反向注入。结构清晰各环节职责分明后面不管是查问题还是加功能思路都比较顺畅。2. 核心模块拆解记忆提取、存储与注入的配合逻辑2.1 记忆提取怎么判断哪句话值得记住在整个流程里“提取”这一步的难度系数最高因为对话中 90% 的内容其实都构不成长期记忆。比如“帮我看看这段代码哪里有问题”这是临时请求不是记忆“我习惯用 Go 写后端服务”这才是值得沉淀的信息。claude-mem 的处理方式是用一个专门的小模型或同一模型的低参数版本来做信息抽取通过结构化提示词引导模型输出“事实、偏好、决定”三类条目。常见的做法是给模型一个 JSON 输出模板让它从对话中抽取出候选记忆条目同时附上置信度评分。低于阈值的条目直接丢弃高于阈值的才写入存储。实际操作上有两种实现路线同步抽取每次对话结束后立刻对完整上下文做一次抽取。好处是上下文信息最完整抽取准确率高坏处是需要额外消耗一次模型调用增加延迟和费用。异步抽取对话结束先把原始记录存起来后台任务慢慢做抽取。对用户无感知但需要处理“记录刚存还没抽完”的边界情况。我自己的项目里采用的是同步加异步结合的模式每次会话结束后先做一次轻量抽取只提取置信度最高的条目入库等到累计一定量后再用更精细的模型对历史记录做重扫补充漏掉的条目。如果你只是个人使用同步抽取就够用了异步重扫属于锦上添花。2.2 存储层不是所有数据库都适合干这个活记忆条目的存储其实不复杂一个本地文件、一张 SQLite 表、一个 JSON 文档都能胜任。但真正决定体验的是几个细节检索速度、去重能力、命名空间隔离。claude-mem 默认的存储方案是 SQLite这个选择很务实。SQLite 不需要单独部署服务一个文件搞定全部数据对个人项目和轻量部署非常友好支持 SQL 查询后续按关键词、时间、类型过滤都很方便。如果你部署在多用户环境也可以换成 PostgreSQL表结构几乎不用改。存储层最关键的设计是命名空间。Claude 可能同时服务多个项目每个项目的记忆理应互相隔离。最简单的做法是给记忆表加一个namespace字段每个项目或会话组一个独立命名空间注入时只取当前命名空间的条目。否则你写博客用的风格偏好可能会污染写代码会话的内容这会很尴尬。另外去重逻辑也不可忽视。用户可能在不同会话里多次表达类似偏好如果不做去重记忆库里会堆满重复条目注入提示词时不仅浪费 token还可能让模型无所适从。去重策略通常基于哈希或文本相似度新条目入库前先和历史条目做比对相似度超过阈值的直接合并或丢弃。2.3 注入策略记忆怎么才能不喧宾夺主记忆提取和存储做得再好如果注入时机或方式不对效果会大打折扣。注入环节的核心矛盾是记忆信息太少Claude 依然“失忆”注入太多上下文窗口被挤占对话质量下降而且费用上升提示词 token 可是要计费的。claude-mem 的做法是把记忆注入到 System Prompt 和首次用户消息之间的位置严格说来属于“上下文注入”的一种。这样模型在一开始就能看到记忆并且因为 System Prompt 的权重较高记忆的影响力也相对更强。常见做法的长这样在 Claude 的 API 调用中系统指令system field里预留一块区域动态拼接记忆条目。你甚至可以给记忆加一个时间戳让模型知道这是几个月前记下的偏好可能已经失效了需要向用户确认而不是盲目遵循。注入量大小需要自己找一个平衡点。结合我的实测经验除非你的项目特别复杂、需要长期维护的细节特别多否则单个会话注入的记忆条目建议控制在 20 到 30 条以内每条尽量控制在 100 个 token 内同时用一行纯文本或一个 JSON 块的方式组织不要让你的记忆层变成一份又臭又长的说明书。3. 实操落地手把手给 Claude 配一个可复用的记忆服务原理说完了重点还是落地。下面是我实际跑通的一套 claude-mem 搭配方案实现方式非常轻量你可以直接在自己的项目里做定制。3.1 准备一个可运行的本地记忆服务首先需要一套后端服务来承接“记忆存取”的职责。用 Python FastAPI 写一个轻量接口SQLite 作为底层存储。核心是三个接口写入记忆、读取记忆、删除记忆。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import sqlite3 import time import uuid app FastAPI() class MemoryItem(BaseModel): namespace: str content: str category: str fact # fact / preference / decision source_id: str class MemoryQuery(BaseModel): namespace: str limit: int 30 def get_db(): conn sqlite3.connect(claude_mem.db) conn.execute( CREATE TABLE IF NOT EXISTS memories ( mem_id TEXT PRIMARY KEY, namespace TEXT, content TEXT, category TEXT, source_id TEXT, created_at REAL ) ) conn.execute(CREATE INDEX IF NOT EXISTS idx_namespace ON memories(namespace)) return conn app.post(/memories) def add_memory(item: MemoryItem): conn get_db() mem_id str(uuid.uuid4()) conn.execute( INSERT INTO memories VALUES (?, ?, ?, ?, ?, ?), (mem_id, item.namespace, item.content, item.category, item.source_id, time.time()) ) conn.commit() conn.close() return {mem_id: mem_id} app.post(/memories/query) def query_memory(q: MemoryQuery): conn get_db() rows conn.execute( SELECT content, category, created_at FROM memories WHERE namespace ? ORDER BY created_at DESC LIMIT ?, (q.namespace, q.limit) ).fetchall() conn.close() return {memories: [{content: r[0], category: r[1], created_at: r[2]} for r in rows]} app.delete(/memories/{mem_id}) def delete_memory(mem_id: str): conn get_db() conn.execute(DELETE FROM memories WHERE mem_id ?, (mem_id,)) conn.commit() conn.close() return {status: deleted}要点是namespace字段它承担了所有项目隔离的职责。我自己会把 namespace 命名为blog-writing、go-project这种格式一个项目一套记忆互相不干扰。SQLite 的索引也很重要如果数据量大了不加索引每次查询全表扫描接口延迟会涨得很快。3.2 把记忆服务和 Claude 的 API 请求串起来接下来是在调用 Claude API 之前先查一次记忆服务把结果拼到 system prompt 里。这段代码展示的是核心注入逻辑注意其中很重要的一点是记忆内容拼接到 System Prompt 的末尾。import requests from anthropic import Anthropic ANTHROPIC_API_KEY your-api-key MEMORY_SERVICE_URL http://localhost:8000 NAMESPACE go-project def build_memory_block(): resp requests.post(f{MEMORY_SERVICE_URL}/memories/query, json{ namespace: NAMESPACE, limit: 30 }) if resp.status_code ! 200: return memories resp.json().get(memories, []) if not memories: return lines [ 以下是与当前项目相关的长期记忆请根据这些信息判断如何回答用户, - m[content] for m in memories ] return \n.join(lines) def chat_with_memory(user_message): memory_block build_memory_block() client Anthropic(api_keyANTHROPIC_API_KEY) system_prompt f你是一个乐于助人的助手。 {memory_block} resp client.messages.create( modelclaude-sonnet-4-20250514, max_tokens2048, systemsystem_prompt, messages[{role: user, content: user_message}] ) return resp.content上面这个示例使用了 Anthropic 官方 Python SDK实际跑的时候把 API Key 换成自己的就行。每次调用前先查记忆库查询结果为空就返回空字符串拼进 system prompt 时也不会有任何副作用。这里有一个我自己踩过的坑memory block 的格式不要用过于复杂的结构化标记比如“yaml”之类的代码块包起来Claude 有时候会把整个代码块当成一个“待处理指令”反而花大力气去解析它浪费了很多上下文。最简单的“MEMORY: 内容”前缀逐行摆开效果往往更稳定。3.3 先手动填充一批基础记忆再做自动提取很多人拿到这种工具第一步就想“让 AI 自己学习”但我的经验恰恰相反初始记忆先手动填。趁项目刚开始、记忆库还是空的时候把你所有稳定偏好一次性写进去效果最好。因为第一阶段的信息最准确不确定性最小而且这些“种子记忆”会成为后续自动提取时的参照告诉我系统“什么样的信息值得记”。之后再考虑自动提取先保证提取的结果和手动沉淀的偏好风格一致。手填的方式就是调用刚写的接口curl -X POST http://localhost:8000/memories \ -H Content-Type: application/json \ -d {namespace: go-project, content: 用户偏好使用 Go 1.22 版本特性尤其喜欢用泛型简化代码结构, category: preference}自动提取的逻辑则是每次对话结束后把整段对话文本交给模型做一次 JSON 抽取。这一步可以用 Claude 自己去干比如给它一段对话、让它返回一个 JSON 数组结构是{content: ..., category: fact|preference|decision}然后把内容写入记忆服务。抽取提示词要写得明确一些防止它把“临时问题”也当成记忆。import json from anthropic import Anthropic def extract_memories_from_conversation(conversation_text): client Anthropic(api_keyANTHROPIC_API_KEY) resp client.messages.create( modelclaude-sonnet-4-20250514, max_tokens1024, system你是记忆提取引擎。从用户的对话中抽取值得长期记住的稳定信息。只输出 JSON 数组格式为 [{\content\: \...\, \category\: \fact|preference|decision\}]。不要输出其他文字。, messages[{role: user, content: conversation_text}] ) raw resp.content[0].text try: items json.loads(raw) for item in items: requests.post(f{MEMORY_SERVICE_URL}/memories, json{ namespace: NAMESPACE, content: item[content], category: item[category] }) except json.JSONDecodeError: print(记忆提取解析失败)这个自动提取方案并不完美初次跑的时候会抓进来不少“伪记忆”比如把某个技术方案的临时选择当成了长期偏好。但不要急着删先观察一段时间你会发现它的提取规律——是更偏向事实还是更偏向结论然后你用提示词微调它。这个过程其实就是你和这套记忆系统磨合的过程最终它会越来越懂你的习惯。4. 实测经验常见问题、坑和排查方法附速查表跑了大概一个月各种问题也都差不多遇了个遍挑几条最典型的记录在这里。这些问题具有一定的共性你大概率也会碰上类似场景。问题一记忆注入之后Claude 开始“过度迁就”记忆不敢反驳过时的信息。有一次我三个月前写了“项目使用 MySQL”后来已经全部迁到 PostgreSQL但记忆库里那条旧记录还在。结果新会话里 Claude 把 MySQL 当成前提无视我对 PostgreSQL 的提问答得驴唇不对马嘴。排查后发现是记忆注入时没有做时效判断。现在的处理方式给每条记忆加created_at字段注入时在每行前面带上“记录时间xxxx-xx-xx”让模型有意识地判断这条信息的新旧。更彻底的办法是在 query 接口里加一个days_threshold参数只返回最近 N 天的记忆。问题二记忆条目越来越多token 消耗明显上升。项目跑了三周后命名空间下积累了 200 多条记忆每次注入 30 条每条平均 80 token也就是每轮对话光记忆就要花掉 2400 token。如果你用的是长上下文模型还好普通模型会很心痛。我的解法是给 query 接口加分类过滤比如“写代码”的场景只需要fact和decision类记忆preference类记忆只保留与管理操作相关的“写作”场景则反过来。这样每次注入量就能控制在 1500 token 以内。问题三自动提取出来的记忆吵杂度太高。“用户说他今天吃了午饭”这种废话也会被模型当成记忆。解决办法是给提取提示词加“排除规则”比如排除陈述性、具体时间点和对项目无关的信息。另外可以加一层后置过滤对内容做关键词匹配如果发现包含“今天”“明天”“昨天”等时间词就自动降权不作为候选记忆。问题四多个项目的记忆串了。如果你不把 namespace 管好几个项目共用一套记忆那基本等于没记。我建议用用户名/项目名作为单条记忆的 namespace 格式比如zhang/blog和zhang/go-tool就不会串。对于 API 调用路径的约束也应考虑至少在查询接口强制要求 namespace 不是空字符串。症状可能原因快速排查方法解决方案新会话里 Claude 不认旧偏好记忆未注入查看记忆服务日志确认 query 是否返回了条目检查 system prompt 拼接逻辑是否生效回答风格和记忆明显矛盾记忆过时未标记查看记忆条目时间戳判断旧条目是否还在注入给记忆条目加时间戳提示或按时间过滤token 消耗激增注入条目过多或单条过长统计平均每次注入的 token 数分类过滤限制单条长度限制条目数量对话中频繁出现无关偏好命名空间混用检查 memory 表 namespace 分布看是不是有重复命名统一命名空间规则定期清理自动提取记忆质量差抽取提示词约束不足手工查看抽取结果里有多少条明显是废话强化抽取提示词增加排除规则服务重启后记忆丢失SQLite 文件路径问题检查数据库文件是否在临时目录将 SQLite 文件固定到持久化目录另外再说一个容易被忽略的体验优化点记忆服务的响应时间直接关系到用户等不等得起。如果每次开新会话都要等记忆接口查询完才能调 Claude API那几十毫秒的延迟也就算了但若查询逻辑复杂、数据量上来了很容易超过几百毫秒。稳妥的做法是给 query 接口做本地缓存或者直接在注入前异步把常用的 namespace 预加载到内存里。这个缓存失效策略也不难“ namespace 对应的记忆表有写入就让缓存作废”。实际跑下来这个优化能把整个链路的延迟观感降到“无感”状态。5. 这套方案还能怎么扩展claude-mem 这类思路并不只局限在 Claude 上用。只要模型支持自定义 system prompt这套记忆层完全可以平移到其他大模型平台上换一个 API 接入层就行。我后来在自己项目里把记忆层同时接到了本地跑的模型上验证过没问题。比较有价值的扩展方向有两个其一是基于记忆的主动建议。记忆库里存了大量偏好和项目背景完全可以在对话开始前先跑一次简单的分类判断“这次会话大概要干什么”然后针对性地调整注入的记忆比例。比如用户上线了“后端任务”的命名空间就不要注入一大堆写作风格的偏好而是集中注入项目技术栈和决策记录效果比平均分配好得多。其二是记忆的自动清理与归档。运行久了之后记忆库里的内容会越来越杂很多旧条目其实已经没有参考价值。可以写一个定时任务每天把三个月前的记忆条目扫描一遍注入模型让它判断“这条还有用吗”没用的自动归档到冷存储。这样既保证了活跃记忆的精简又不至于彻底丢失历史背景。我自己的经验是这套记忆层方案和 Claude 配合得比较顺手核心原因在于它的设计抽象得恰到好处存储用简单 SQLite 承载提取用模型自行判断注入在任意调用层都能动态拼装。抽象层级少意味着复用成本低也意味着出问题时好排查——你永远知道去哪看、改哪里。最后再分享一个很小的技巧写记忆条目的时候尽量用第三人称、稳定的口吻比如“用户偏好……”而不是“我偏好……”。因为在多轮对话里模型很多时候是站在“助手”视角而不是“用户”视角如果记忆条目里用了第一人称模型可能搞不清“我”到底指的是谁。多花十秒钟改几个字能省掉后面很多解释的麻烦。