尧图网站建设 
1. 从零认识 claude-mem它到底解决什么问题第一次看到claude-mem这个名字很多人会以为它又是一个“给 AI 加记忆”的玩具项目。但真正用过一段时间之后你会发现它解决的是一个非常具体、非常痛的工程问题如何让 Claude 这类大模型在跨会话、跨项目的长期协作中记住那些真正重要的上下文而不是每次都从零开始。我自己的使用场景很典型。手上有三四个并行推进的项目每个项目都有自己的技术栈、命名习惯、历史决策和踩过的坑。以前每次开新会话我都要花十几分钟把背景重新讲一遍讲完还要担心模型有没有理解偏。更麻烦的是有些决策是几周前定的我自己都记不清细节模型更不可能知道。claude-mem就是冲着这个痛点来的——它把“记忆”从模型内部剥离出来变成一个可管理、可检索、可迁移的外部层。从定位上说claude-mem属于AI 协作工作流中的记忆管理层。它不训练模型不改模型权重而是通过一套结构化的存储和检索机制在每次对话开始前把相关记忆注入上下文在对话结束后把新的关键信息沉淀下来。这个思路和人类团队协作很像我们不指望某个人记住所有事而是靠文档、会议纪要、决策记录来承载集体记忆。适合读这篇内容的人有三类。第一类是重度使用 Claude 做开发或写作的从业者每天要开很多会话上下文切换成本高。第二类是需要长期维护复杂项目的人比如独立开发者、技术负责人、内容创作者项目周期长、决策链条多。第三类是对 AI 工作流优化感兴趣的人想搞清楚“记忆”这件事在工程上到底怎么落地而不是停留在概念层面。需要提前说明的是claude-mem不是一个开箱即用的商业产品它更像一套可自建、可定制的记忆方案。网上关于它的讨论比较零散很多细节需要自己动手验证。我接下来会结合自己的实操经验把它的核心思路、关键实现、常见坑和排查方法讲清楚尽量让不同基础的人都能照着做。2. 核心设计思路拆解为什么是“外部记忆”而不是“更长上下文”2.1 长上下文方案的三个硬伤很多人第一反应是现在模型上下文窗口不是越来越大吗直接塞进去不就行了我一开始也这么想实测下来发现三个问题绕不过去。第一是成本。上下文越长每次请求的 token 消耗越大。如果你每次会话都塞几万 token 的历史记录费用会线性上涨。我算过一笔账按每天 20 次会话、每次多消耗 8000 token 来算一个月下来多出来的成本相当可观。而claude-mem的思路是只注入相关的记忆可能只有几百到一两千 token差距很明显。第二是注意力稀释。上下文里信息太多模型反而容易抓不住重点。这是大模型的通病塞进去的内容越多关键信息被“淹没”的概率越高。我做过对比测试同样一个问题塞 5000 token 无关历史 vs 只塞 500 token 精准记忆后者的回答质量明显更稳。第三是不可控。长上下文是“黑盒”你不知道模型到底用了哪些信息、忽略了哪些。而外部记忆是白盒每条记忆都能看到、能编辑、能删除。出了问题可以追溯这对工程场景非常重要。2.2 记忆分层短期、长期、项目级claude-mem的设计里记忆不是一坨而是分层的。我把它归纳为三层这个划分方式在实操中很好用。短期记忆是当前会话内的上下文随会话结束而消失。这部分不需要额外管理模型自己会处理。长期记忆是跨会话的通用信息比如你的技术偏好、常用工具、写作风格、沟通习惯。这些信息相对稳定变化慢适合放在一个全局的记忆库里。项目级记忆是绑定到具体项目的上下文比如项目架构、关键决策、待办事项、已知问题。这部分变化快需要频繁更新而且不同项目之间要隔离不能串味。提示三层记忆的边界不是绝对的。有些信息一开始是项目级的后来发现通用性很强可以提升为长期记忆。关键是养成定期整理的习惯别让记忆库变成垃圾场。2.3 检索策略关键词、向量还是混合记忆存下来之后怎么在需要的时候找出来这是claude-mem最核心的技术点。常见方案有三种。关键词检索最简单靠字符串匹配。优点是快、可解释、零依赖。缺点是同义词、近义表达覆盖不到。比如你记的是“数据库连接池”问的是“DB pool”可能就匹配不上。向量检索靠语义相似度能解决同义词问题。但需要嵌入模型有额外成本而且相似度阈值不好调。阈值太低会召回一堆无关记忆太高又漏掉关键信息。混合检索是我实测下来最稳的方案。先用关键词做粗筛再用向量做精排两者结合。claude-mem的很多实现都走这条路。具体做法是关键词命中给一个基础分向量相似度给一个加权分最后按总分排序取 Top-K。我自己的配置是关键词权重 0.4向量权重 0.6Top-K 取 5 到 8 条。这个参数不是固定的要根据记忆库大小调整。记忆库小的时候可以多召回几条大了就要收紧否则注入的上下文又会变长。2.4 为什么选择“注入”而不是“微调”有人会问为什么不直接微调模型把记忆写进权重里这个问题我认真考虑过结论是不划算。微调的成本高每次记忆更新都要重新训练周期长、费用大。而且微调后的模型是“冻结”的想改一条记忆就得重来。更麻烦的是微调会把记忆和模型能力耦合在一起出了问题很难定位是记忆错了还是模型本身的问题。注入方案则灵活得多。记忆存在外部改一条就是改一条即时生效。模型还是那个模型能力不受影响。记忆出问题直接看存储内容就能排查。这种解耦设计是claude-mem这类方案的核心优势。3. 核心细节解析与实操要点3.1 记忆的存储结构怎么设计存储结构决定了后续检索和管理的难易程度。我试过几种方案最后稳定下来的结构包含这几个字段。字段类型说明id字符串唯一标识建议用时间戳加随机串content文本记忆正文控制在 200 字以内tags数组标签用于分类和粗筛project字符串所属项目全局记忆留空type枚举决策、事实、偏好、待办created_at时间创建时间updated_at时间更新时间weight数值权重用于排序加权这个结构的关键在于type 字段。把记忆分成“决策、事实、偏好、待办”四类检索时可以根据场景过滤。比如你在做技术选型就优先召回“决策”类记忆在写代码就优先召回“事实”和“偏好”类。这个分类看起来简单但实际用起来能大幅提升召回精准度。注意content 字段一定要控制长度。我见过有人把整段文档塞进去结果检索出来一大坨注入上下文后反而干扰模型。单条记忆最好只讲一件事超过 200 字就拆成多条。3.2 记忆写入的时机和触发条件什么时候写记忆比怎么写记忆更重要。写得太频繁记忆库全是噪音写得太少关键信息又漏掉。我总结了几条触发规则。显式触发对话中明确出现“记住这个”“以后都这样”“这个决策很重要”之类的信号立刻写入。这是最可靠的来源。决策触发当对话产生了一个明确的技术选型、方案取舍、架构决定时写入。比如“我们决定用 PostgreSQL 而不是 MySQL”这种信息价值很高。纠错触发当模型犯错、你纠正了它把纠正内容写入。这类记忆能防止同样的错误反复出现。会话结束触发会话结束时让模型自己总结本次对话的关键信息你审核后写入。这个方式效率高但需要人工把关否则容易写入一堆废话。我自己的习惯是前三条自动触发第四条手动确认。这样既不会漏也不会让记忆库失控。3.3 检索时的排序算法细节检索排序是claude-mem的技术核心值得展开讲。我用的排序公式大致是这样score w1 * keyword_score w2 * vector_score w3 * recency_score w4 * weight_score四个分量的含义分别是关键词匹配度、向量相似度、时间新鲜度、记忆自身权重。权重系数 w1 到 w4 需要根据实际场景调。时间新鲜度这一项容易被忽略但很重要。项目级记忆里最近的决策往往比几个月前的更相关。我用的是指数衰减半衰期设 30 天。也就是说30 天前的记忆新鲜度分数减半。记忆自身权重是手动调的。有些记忆是“铁律”比如“这个项目禁止用某类库”权重设高一点保证每次都能召回。有些是“参考信息”权重低一点有需要才召回。调参这件事没有标准答案我的建议是先用默认值跑一段时间观察召回结果再针对性调整。别一上来就追求完美参数那是浪费时间。3.4 记忆冲突和过期怎么处理记忆库用久了一定会出现冲突和过期。比如三个月前决定用方案 A上个月改成了方案 B两条记忆都在库里检索时可能同时召回模型就懵了。处理办法有两个。一是版本标记同一条记忆的更新不覆盖旧版而是新增一条并标记supersedes字段指向旧版。检索时如果召回了旧版检查它是否被新版取代是则丢弃。二是定期清理每隔一段时间 review 一次记忆库手动删除过期内容。我倾向于两者结合。自动版本标记保证不漏定期清理保证不臃肿。清理频率看使用强度我一般两周一次每次花十几分钟。4. 实操过程与核心环节实现4.1 环境准备与依赖安装假设你已经有一个能调用 Claude API 的环境接下来要搭的是记忆层。我用的是 Python 技术栈核心依赖就几个。pip install anthropic chromadb sentence-transformersanthropic是官方 SDKchromadb做向量存储sentence-transformers提供嵌入模型。如果你不想用 Chroma也可以用 FAISS 或 SQLite 加向量扩展看个人偏好。嵌入模型我选的是all-MiniLM-L6-v2体积小、速度快、效果够用。如果你对语义精度要求高可以换更大的模型但推理成本会上升。这个取舍要看你的记忆库规模和查询频率。提示嵌入模型一旦选定就不要随便换。换了之后所有历史记忆的向量都要重新计算否则新旧向量不在同一空间检索会乱套。4.2 记忆库的初始化代码先建一个记忆管理类把增删查改封装起来。核心代码如下。import chromadb from sentence_transformers import SentenceTransformer import time import uuid class MemoryStore: def __init__(self, path./memory_db): self.client chromadb.PersistentClient(pathpath) self.collection self.client.get_or_create_collection(claude_mem) self.encoder SentenceTransformer(all-MiniLM-L6-v2) def add(self, content, tags, project, mtypefact, weight1.0): mem_id f{int(time.time())}_{uuid.uuid4().hex[:8]} embedding self.encoder.encode(content).tolist() self.collection.add( ids[mem_id], embeddings[embedding], documents[content], metadatas[{ tags: ,.join(tags), project: project, type: mtype, weight: weight, created_at: time.time() }] ) return mem_id这段代码的关键点是metadatas里存了标签、项目、类型、权重、时间。这些字段在检索时用来做过滤和加权。ids用时间戳加随机串保证唯一且有序。4.3 检索函数的实现与参数调优检索函数要把关键词、向量、时间、权重四个因素综合起来。实现如下。def search(self, query, project, top_k5, w_kw0.4, w_vec0.6, w_time0.2): query_emb self.encoder.encode(query).tolist() results self.collection.query( query_embeddings[query_emb], n_resultstop_k * 3, where{project: project} if project else None ) scored [] now time.time() for i, doc in enumerate(results[documents][0]): meta results[metadatas][0][i] vec_score 1 - results[distances][0][i] kw_score sum(1 for w in query.lower().split() if w in doc.lower()) / max(len(query.split()), 1) days_old (now - meta[created_at]) / 86400 time_score 0.5 ** (days_old / 30) weight_score meta.get(weight, 1.0) total (w_kw * kw_score w_vec * vec_score w_time * time_score 0.1 * weight_score) scored.append((total, doc, meta)) scored.sort(reverseTrue, keylambda x: x[0]) return scored[:top_k]这里有几个细节值得说。n_results取top_k * 3是为了先多召回一些再精排避免粗筛阶段漏掉好结果。where条件做项目隔离全局记忆不传 project 就能召回。时间衰减用0.5 ** (days_old / 30)30 天半衰期。调参的时候我建议先固定w_time和权重项重点调w_kw和w_vec的比例。如果你的查询词和记忆内容用词比较一致提高w_kw如果表达差异大提高w_vec。4.4 与 Claude 对话的集成方式记忆层搭好之后要把它接到对话流程里。核心逻辑是对话前检索注入对话后总结写入。def chat_with_memory(user_input, project, storeNone): memories store.search(user_input, projectproject, top_k5) memory_text \n.join([f- {m[1]} for m in memories]) system_prompt f你是一个有记忆的助手。以下是相关历史记忆 {memory_text} 请结合这些记忆回答用户问题。 response call_claude(system_prompt, user_input) return response, memories注入的时候记忆以列表形式放在 system prompt 里简洁明了。不要塞太多条5 条左右比较合适。太多会稀释注意力太少又可能漏关键信息。对话结束后用一个单独的总结 prompt 让模型提炼本次对话的关键信息你审核后调用store.add()写入。这一步不要全自动人工把关能大幅提升记忆质量。4.5 一次完整的实操记录我拿一个真实场景走一遍。假设我在做一个数据分析项目之前定过“用 Pandas 而不是 Polars”的决策。第一步写入决策记忆。内容“数据分析项目决定用 Pandas原因是团队熟悉度高生态成熟。”标签[技术选型, 数据分析]项目> claude-mem 实战：构建大模型外部记忆层，解决跨会话上下文管理难题
1. 从零认识 claude-mem它到底解决什么问题第一次看到claude-mem这个名字很多人会以为它又是一个“给 AI 加记忆”的玩具项目。但真正用过一段时间之后你会发现它解决的是一个非常具体、非常痛的工程问题如何让 Claude 这类大模型在跨会话、跨项目的长期协作中记住那些真正重要的上下文而不是每次都从零开始。我自己的使用场景很典型。手上有三四个并行推进的项目每个项目都有自己的技术栈、命名习惯、历史决策和踩过的坑。以前每次开新会话我都要花十几分钟把背景重新讲一遍讲完还要担心模型有没有理解偏。更麻烦的是有些决策是几周前定的我自己都记不清细节模型更不可能知道。claude-mem就是冲着这个痛点来的——它把“记忆”从模型内部剥离出来变成一个可管理、可检索、可迁移的外部层。从定位上说claude-mem属于AI 协作工作流中的记忆管理层。它不训练模型不改模型权重而是通过一套结构化的存储和检索机制在每次对话开始前把相关记忆注入上下文在对话结束后把新的关键信息沉淀下来。这个思路和人类团队协作很像我们不指望某个人记住所有事而是靠文档、会议纪要、决策记录来承载集体记忆。适合读这篇内容的人有三类。第一类是重度使用 Claude 做开发或写作的从业者每天要开很多会话上下文切换成本高。第二类是需要长期维护复杂项目的人比如独立开发者、技术负责人、内容创作者项目周期长、决策链条多。第三类是对 AI 工作流优化感兴趣的人想搞清楚“记忆”这件事在工程上到底怎么落地而不是停留在概念层面。需要提前说明的是claude-mem不是一个开箱即用的商业产品它更像一套可自建、可定制的记忆方案。网上关于它的讨论比较零散很多细节需要自己动手验证。我接下来会结合自己的实操经验把它的核心思路、关键实现、常见坑和排查方法讲清楚尽量让不同基础的人都能照着做。2. 核心设计思路拆解为什么是“外部记忆”而不是“更长上下文”2.1 长上下文方案的三个硬伤很多人第一反应是现在模型上下文窗口不是越来越大吗直接塞进去不就行了我一开始也这么想实测下来发现三个问题绕不过去。第一是成本。上下文越长每次请求的 token 消耗越大。如果你每次会话都塞几万 token 的历史记录费用会线性上涨。我算过一笔账按每天 20 次会话、每次多消耗 8000 token 来算一个月下来多出来的成本相当可观。而claude-mem的思路是只注入相关的记忆可能只有几百到一两千 token差距很明显。第二是注意力稀释。上下文里信息太多模型反而容易抓不住重点。这是大模型的通病塞进去的内容越多关键信息被“淹没”的概率越高。我做过对比测试同样一个问题塞 5000 token 无关历史 vs 只塞 500 token 精准记忆后者的回答质量明显更稳。第三是不可控。长上下文是“黑盒”你不知道模型到底用了哪些信息、忽略了哪些。而外部记忆是白盒每条记忆都能看到、能编辑、能删除。出了问题可以追溯这对工程场景非常重要。2.2 记忆分层短期、长期、项目级claude-mem的设计里记忆不是一坨而是分层的。我把它归纳为三层这个划分方式在实操中很好用。短期记忆是当前会话内的上下文随会话结束而消失。这部分不需要额外管理模型自己会处理。长期记忆是跨会话的通用信息比如你的技术偏好、常用工具、写作风格、沟通习惯。这些信息相对稳定变化慢适合放在一个全局的记忆库里。项目级记忆是绑定到具体项目的上下文比如项目架构、关键决策、待办事项、已知问题。这部分变化快需要频繁更新而且不同项目之间要隔离不能串味。提示三层记忆的边界不是绝对的。有些信息一开始是项目级的后来发现通用性很强可以提升为长期记忆。关键是养成定期整理的习惯别让记忆库变成垃圾场。2.3 检索策略关键词、向量还是混合记忆存下来之后怎么在需要的时候找出来这是claude-mem最核心的技术点。常见方案有三种。关键词检索最简单靠字符串匹配。优点是快、可解释、零依赖。缺点是同义词、近义表达覆盖不到。比如你记的是“数据库连接池”问的是“DB pool”可能就匹配不上。向量检索靠语义相似度能解决同义词问题。但需要嵌入模型有额外成本而且相似度阈值不好调。阈值太低会召回一堆无关记忆太高又漏掉关键信息。混合检索是我实测下来最稳的方案。先用关键词做粗筛再用向量做精排两者结合。claude-mem的很多实现都走这条路。具体做法是关键词命中给一个基础分向量相似度给一个加权分最后按总分排序取 Top-K。我自己的配置是关键词权重 0.4向量权重 0.6Top-K 取 5 到 8 条。这个参数不是固定的要根据记忆库大小调整。记忆库小的时候可以多召回几条大了就要收紧否则注入的上下文又会变长。2.4 为什么选择“注入”而不是“微调”有人会问为什么不直接微调模型把记忆写进权重里这个问题我认真考虑过结论是不划算。微调的成本高每次记忆更新都要重新训练周期长、费用大。而且微调后的模型是“冻结”的想改一条记忆就得重来。更麻烦的是微调会把记忆和模型能力耦合在一起出了问题很难定位是记忆错了还是模型本身的问题。注入方案则灵活得多。记忆存在外部改一条就是改一条即时生效。模型还是那个模型能力不受影响。记忆出问题直接看存储内容就能排查。这种解耦设计是claude-mem这类方案的核心优势。3. 核心细节解析与实操要点3.1 记忆的存储结构怎么设计存储结构决定了后续检索和管理的难易程度。我试过几种方案最后稳定下来的结构包含这几个字段。字段类型说明id字符串唯一标识建议用时间戳加随机串content文本记忆正文控制在 200 字以内tags数组标签用于分类和粗筛project字符串所属项目全局记忆留空type枚举决策、事实、偏好、待办created_at时间创建时间updated_at时间更新时间weight数值权重用于排序加权这个结构的关键在于type 字段。把记忆分成“决策、事实、偏好、待办”四类检索时可以根据场景过滤。比如你在做技术选型就优先召回“决策”类记忆在写代码就优先召回“事实”和“偏好”类。这个分类看起来简单但实际用起来能大幅提升召回精准度。注意content 字段一定要控制长度。我见过有人把整段文档塞进去结果检索出来一大坨注入上下文后反而干扰模型。单条记忆最好只讲一件事超过 200 字就拆成多条。3.2 记忆写入的时机和触发条件什么时候写记忆比怎么写记忆更重要。写得太频繁记忆库全是噪音写得太少关键信息又漏掉。我总结了几条触发规则。显式触发对话中明确出现“记住这个”“以后都这样”“这个决策很重要”之类的信号立刻写入。这是最可靠的来源。决策触发当对话产生了一个明确的技术选型、方案取舍、架构决定时写入。比如“我们决定用 PostgreSQL 而不是 MySQL”这种信息价值很高。纠错触发当模型犯错、你纠正了它把纠正内容写入。这类记忆能防止同样的错误反复出现。会话结束触发会话结束时让模型自己总结本次对话的关键信息你审核后写入。这个方式效率高但需要人工把关否则容易写入一堆废话。我自己的习惯是前三条自动触发第四条手动确认。这样既不会漏也不会让记忆库失控。3.3 检索时的排序算法细节检索排序是claude-mem的技术核心值得展开讲。我用的排序公式大致是这样score w1 * keyword_score w2 * vector_score w3 * recency_score w4 * weight_score四个分量的含义分别是关键词匹配度、向量相似度、时间新鲜度、记忆自身权重。权重系数 w1 到 w4 需要根据实际场景调。时间新鲜度这一项容易被忽略但很重要。项目级记忆里最近的决策往往比几个月前的更相关。我用的是指数衰减半衰期设 30 天。也就是说30 天前的记忆新鲜度分数减半。记忆自身权重是手动调的。有些记忆是“铁律”比如“这个项目禁止用某类库”权重设高一点保证每次都能召回。有些是“参考信息”权重低一点有需要才召回。调参这件事没有标准答案我的建议是先用默认值跑一段时间观察召回结果再针对性调整。别一上来就追求完美参数那是浪费时间。3.4 记忆冲突和过期怎么处理记忆库用久了一定会出现冲突和过期。比如三个月前决定用方案 A上个月改成了方案 B两条记忆都在库里检索时可能同时召回模型就懵了。处理办法有两个。一是版本标记同一条记忆的更新不覆盖旧版而是新增一条并标记supersedes字段指向旧版。检索时如果召回了旧版检查它是否被新版取代是则丢弃。二是定期清理每隔一段时间 review 一次记忆库手动删除过期内容。我倾向于两者结合。自动版本标记保证不漏定期清理保证不臃肿。清理频率看使用强度我一般两周一次每次花十几分钟。4. 实操过程与核心环节实现4.1 环境准备与依赖安装假设你已经有一个能调用 Claude API 的环境接下来要搭的是记忆层。我用的是 Python 技术栈核心依赖就几个。pip install anthropic chromadb sentence-transformersanthropic是官方 SDKchromadb做向量存储sentence-transformers提供嵌入模型。如果你不想用 Chroma也可以用 FAISS 或 SQLite 加向量扩展看个人偏好。嵌入模型我选的是all-MiniLM-L6-v2体积小、速度快、效果够用。如果你对语义精度要求高可以换更大的模型但推理成本会上升。这个取舍要看你的记忆库规模和查询频率。提示嵌入模型一旦选定就不要随便换。换了之后所有历史记忆的向量都要重新计算否则新旧向量不在同一空间检索会乱套。4.2 记忆库的初始化代码先建一个记忆管理类把增删查改封装起来。核心代码如下。import chromadb from sentence_transformers import SentenceTransformer import time import uuid class MemoryStore: def __init__(self, path./memory_db): self.client chromadb.PersistentClient(pathpath) self.collection self.client.get_or_create_collection(claude_mem) self.encoder SentenceTransformer(all-MiniLM-L6-v2) def add(self, content, tags, project, mtypefact, weight1.0): mem_id f{int(time.time())}_{uuid.uuid4().hex[:8]} embedding self.encoder.encode(content).tolist() self.collection.add( ids[mem_id], embeddings[embedding], documents[content], metadatas[{ tags: ,.join(tags), project: project, type: mtype, weight: weight, created_at: time.time() }] ) return mem_id这段代码的关键点是metadatas里存了标签、项目、类型、权重、时间。这些字段在检索时用来做过滤和加权。ids用时间戳加随机串保证唯一且有序。4.3 检索函数的实现与参数调优检索函数要把关键词、向量、时间、权重四个因素综合起来。实现如下。def search(self, query, project, top_k5, w_kw0.4, w_vec0.6, w_time0.2): query_emb self.encoder.encode(query).tolist() results self.collection.query( query_embeddings[query_emb], n_resultstop_k * 3, where{project: project} if project else None ) scored [] now time.time() for i, doc in enumerate(results[documents][0]): meta results[metadatas][0][i] vec_score 1 - results[distances][0][i] kw_score sum(1 for w in query.lower().split() if w in doc.lower()) / max(len(query.split()), 1) days_old (now - meta[created_at]) / 86400 time_score 0.5 ** (days_old / 30) weight_score meta.get(weight, 1.0) total (w_kw * kw_score w_vec * vec_score w_time * time_score 0.1 * weight_score) scored.append((total, doc, meta)) scored.sort(reverseTrue, keylambda x: x[0]) return scored[:top_k]这里有几个细节值得说。n_results取top_k * 3是为了先多召回一些再精排避免粗筛阶段漏掉好结果。where条件做项目隔离全局记忆不传 project 就能召回。时间衰减用0.5 ** (days_old / 30)30 天半衰期。调参的时候我建议先固定w_time和权重项重点调w_kw和w_vec的比例。如果你的查询词和记忆内容用词比较一致提高w_kw如果表达差异大提高w_vec。4.4 与 Claude 对话的集成方式记忆层搭好之后要把它接到对话流程里。核心逻辑是对话前检索注入对话后总结写入。def chat_with_memory(user_input, project, storeNone): memories store.search(user_input, projectproject, top_k5) memory_text \n.join([f- {m[1]} for m in memories]) system_prompt f你是一个有记忆的助手。以下是相关历史记忆 {memory_text} 请结合这些记忆回答用户问题。 response call_claude(system_prompt, user_input) return response, memories注入的时候记忆以列表形式放在 system prompt 里简洁明了。不要塞太多条5 条左右比较合适。太多会稀释注意力太少又可能漏关键信息。对话结束后用一个单独的总结 prompt 让模型提炼本次对话的关键信息你审核后调用store.add()写入。这一步不要全自动人工把关能大幅提升记忆质量。4.5 一次完整的实操记录我拿一个真实场景走一遍。假设我在做一个数据分析项目之前定过“用 Pandas 而不是 Polars”的决策。第一步写入决策记忆。内容“数据分析项目决定用 Pandas原因是团队熟悉度高生态成熟。”标签[技术选型, 数据分析]项目>