企业官网建设流程全解析

我做基于Claude 的 Agent 项目时，第一个被逼疯的问题不是 Prompt 写不好，而是：Claude 记不住东西。上一轮刚确认过的用户偏好，下一轮再问，它就跟失忆一样重新问你一遍。这个现象在长对话、客服机器人、个人知识助理这类场景里尤其致命。后来我在社区看到一个叫claude-mem的项目，专门给 Claude 加长期记忆，把对话里的重要信息抽出来、存起来、再在下次对话时自动找回来。这篇文章就围绕 claude-mem 聊聊它的设计思路、核心细节、实操步骤和我在接入过程中踩过的坑。

1. 项目概述与核心需求解析

1.1 claude-mem 是什么

claude-mem字面意思是 Claude Memory，也就是 Cluade 的长期记忆组件。它不是某个大厂出的产品，本质上是开源社区里用来解决“大模型无状态”问题的一类中间件：在 Claude 的请求/响应链路外面包一层记忆读取和记忆写入逻辑。对话时，系统先把用户的历史关键信息从存储中捞出来，以 system prompt 或上下文片段的形式塞给 Claude；等 Claude 回复之后，再把这一轮对话中值得记住的信息抽取、向量化、写回存储。

这个组件能解决的问题非常具体：Claude API 本身是无状态的，每次调用都是一次全新对话，上下文窗口再大也只是“临时记忆”，关掉连接就没了。而 claude-mem 把记忆从上下文窗口搬到了外部存储，让“记得住”变成一个可以持久化的能力。适合谁用？一句话，只要你用 Claude API 做多轮对话、Agent、客服、笔记助理、角色扮演这类产品，而且用户会对“它居然不记得我说过什么”感到崩溃，那你就需要它。

1.2 为什么会有这种“失忆”项目

先讲清楚一个容易被忽略的前提：Claude 有上下文窗口，比如 200K token，看起来很大，但它只是在当前请求里“看得到”而已。每个请求传进去的 messages 都是独立计算的，服务端不会把你业务数据库里的历史存下来。也就是说，Claude 的“记忆”完全靠调用端每次把旧消息重新塞进上下文，塞不下的、没塞的，就是彻底忘记。

这就带来三个场景难题：

• 长对话越长越贵：所有历史消息都发一次，Token 消耗线性增长，聊到第一百轮时，单次请求成本已经高到离谱。
• 跨会话彻底失忆：用户今天聊的需求，明天再打开同一个号码的对话，Claude 什么都不记得，业务方要自己把前缀拼上去。
• 有效信息被淹没：即便你把 200K 的历史全塞进去，中间大量寒暄、无关细节也会稀释重点，模型反而更难提取关键偏好。

claude-mem这一类项目就是基于这些痛点出现的：它不是让你把每句话都记住，而是只保留真正有长期价值的片段，并在合适的时候精准召回。通俗点说，这不像是“大象的记忆”，更像是你手机里那张经过整理的备忘清单，而非一句不落的录音笔。

2. 整体设计与方案选型

2.1 记忆方案的三条常见技术路线

在真正上手claude-mem之前，我其实自己先试过几个土办法，这里先做个横向对比，方便你理解这个项目为什么会选择当前的设计。

第一种方案是历史全量回放。也就是每次请求前把该用户所有历史消息拼成一个巨大的 system prompt。优点是零额外组件、调用一次就能生效；缺点是 Token 费用暴涨、上下文一旦超限直接报错，而且 Claude 被淹没在噪声里，效果反而下降。这个方案只适合几十轮以内的轻量场景，一旦规模上来就撑不住。

第二种方案是摘要压缩。每次对话结束后，用一次单独的 Claude 调用把整轮聊天压缩成 200 字的摘要，存进数据库或 Redis。下次对话时把摘要放回 prompt。优点是很省 Token，缺点是会丢失高频细节，比如用户可能在第 3 轮说过“不要发邮件”，摘要里没记，第 4 轮就坑了。而且多轮摘要的逐级压缩会出现信息衰减，类似“传话游戏”。

第三种方案是向量化检索记忆，也就是claude-mem的核心思路。对话过程中把关键信息拆成一条条独立记忆，比如“用户偏好使用 Markdown 格式输出”“用户所在时区为 UTC+8”“用户不喜欢拟人化称呼”，每条记忆用 embedding 模型转成向量，存入向量数据库。新对话开始时，把当前用户输入也转成向量，做相似度检索，取回最相关的 top-k 条记忆，再拼进 system prompt。

从工程角度看，第三种方案最接近一个合格的记忆系统：取用时是“按需加载”，不是“全量灌输”；写入时是“结构化沉淀”，不是“原文堆砌”。claude-mem走的就是这条路线，并且在实现上额外混合了摘要层和记忆条目层，尽量避免纯向量方案可能出现的碎片化问题。

2.2 为什么选向量检索而不是纯规则匹配

有人可能会问，直接用关键词匹配或者数据库 LIKE 查询不是更简单吗？这里有一个很关键的体验差异：用户表达是口语化、多义词、模糊指代满天飞的。比如用户第一轮说“我每周三下午开例会”，第三十轮说“那以后会议纪要帮我放在周三的日程前面”，“会议纪要”和“例会”在字面上几乎没有任何重合，关键词匹配直接漏掉，但向量检索可以基于语义相似度把这两条关联起来。

claude-mem在实际检索时并不只是孤看一条记忆，它会做几件事：

• 将历史记忆切分为语义完整的短句，而不是整段对话原文；
• 对每条记忆做 embedding 向量化并存入向量库；
• 将查询请求（比如用户最新一条消息 + 业务场景描述）也向量化，计算余弦相似度；
• 设置相似度阈值，低于阈值的记忆不返回，避免噪声注入；
• 返回结果会按相似度排序，并且在注入 prompt 时附带来源上下文，让 Claude 知道这条记忆是怎么来的。

这套逻辑决定了它对模糊指代、语义相关、跨话题关联的召回效果，远好于规则匹配。它在牺牲一点点延迟（embedding 调用 + 向量检索通常 100ms 内完成）的基础上，换来的是对话体验的大幅提升，这个取舍非常值得。

2.3 记忆生命周期：不只是存进去和取出来

很多人第一反应是“记忆系统 = 存进去 + 查出来”，实际操作后才会发现，真正麻烦的是记忆该怎么更新、怎么过期、怎么清理。claude-mem在设计上把记忆生命周期拆成四个阶段：

写入阶段，系统决定哪些信息值得记。这个动作通常有两种方式：一是基于规则抽取，比如用户明确说了“我喜欢”“我不喜欢”“以后请”这类关键词，就抽取为记忆；二是用单独一次轻量模型调用，让 Claude 自己把这一轮对话压缩成 1 到 3 条记忆。claude-mem的默认偏好是后者，因为它能理解上下文，提取出的记忆质量明显更高。

存储阶段，每条记忆会记录三个层面的属性：内容本身（文本）、向量表示（embedding）、元数据（用户 ID、会话 ID、时间戳、来源消息 ID、过期时间）。元数据的作用在后续阶段才会体现：它决定了这条记忆属于谁、什么时候产生的、什么时候应该失效。

召回阶段，需要区分“活跃记忆”和“休眠记忆”。活跃记忆是近期被频繁命中的，召回时会被上调权重；休眠记忆是长期没使用、或已经过期的，系统会在后台归档甚至删除。否则记忆库会越滚越大，垃圾信息也会越来越多，最终反而淹没真正有用的偏好。

遗忘阶段，这是很多自建记忆系统最忽略的部分。claude-mem支持给记忆设置 TTL（生存时间），比如用户常住城市这种长期稳定的信息可以设为 90 天，而“正在进行的菜鸟教程进度”可能 7 天就过期。做过隐私或合规项目的朋友应该一眼就明白，这个设计除了让记忆更精准，也是一个非常务实的合规需求。

3. 核心细节解析与实操要点

3.1 记忆数据结构的设计考量

真正接入claude-mem之后，你会发现它的存储模型并不复杂，核心就落在几条关键字段上。我根据自己的使用经验，整理了一个典型的数据结构，如下表所示：

有几个细节值得重点说明。

namespace必须隔离。如果你是多用户产品，那每条记忆都必须归属到一个用户维度，否则用户 A 的记忆会被用户 B 的查询召回，这就是事故了。所以claude-mem把 namespace 做成强制参数，而不是可选参数，这是我认为它比较严谨的地方。

content必须是完整短句。这里非常关键：不要存“用户说：今天下雨”，而是存“用户所在城市今天下雨，出行需要注意带伞”。因为召回后这些内容会直接注入给 Claude 的 system prompt，太碎的内容会导致模型理解不了上下文，甚至把“今天下雨”当成自己当前收到的实时天气。

access_count和last_access_at是用来做热更新排序的。每次召回时，系统会增加这两个字段，并在后续写入时根据它们动态调整记忆权重。这个机制能让高频使用的记忆排在检索结果前面，实现一种粗糙但有效的“重要性自学习”。

3.2 位置决定成败：记忆要注入到哪里

这是我在实操中感受最深的一点。很多人以为记忆注入就是把查出来的文本拼在 system prompt 末尾，其实不是，位置和格式都会影响效果。claude-mem的默认做法是构建一个专门的记忆区块，放在 system prompt 靠前的位置，并给 Claude 一条明确的指令：

你是用户熟悉的私人助手。以下是关于用户的长期记忆，请在所有回答中自然遵循其中提到的偏好和已知信息。 [记忆区] - 用户偏好 Markdown 格式的简洁回复（来源：会话 0142 第 3 轮） - 用户所在时区为 UTC+8（来源：会话 0177 第 12 轮）

有两个细节我特别想强调：

第一，记忆要标注来源会话和轮次。这个设计的价值在于，当 Claude 引用某条记忆时，用户可以知道这条信息是哪来的，避免“默默影响对话”的违和感。更重要的是，这些来源信息还能用来做记忆溯源排查——如果某条记忆明显是错的，可以循着来源去修改或删除它。

第二，注入位置要在“系统设定之后、用户消息之前”。Claude 对 prompt 不同位置的敏感度不一样，放在中间甚至末尾的记忆很容易被长上下文淹没。放在开头的记忆区块，会让模型把“遵循记忆”当作一个高优先级的系统指令来对待。如果你自己写集成，注意把记忆区块放在 messages 数组中 system 角色的 content 开头位置，而不是挂在 user 消息后面。

3.3 核心参数：阈值、top-k 与 TTL

任何记忆系统都需要调参，claude-mem也一样。以下是我实测下来最影响效果的三个参数。

相似度阈值（score_threshold）。这个参数决定一条历史记忆与当前查询有多少相似时才被拉出来。设得太低（比如 0.5），召回的都是一些“沾边但无关”的记忆，注入后反而带偏对话；设得太高（比如 0.9），绝大多数记忆都被过滤掉，等于没加记忆。我自己的经验是文本 embedding 模型的相似度分数普遍偏高，0.72 到 0.78 是一个比较舒服的区间，具体还得看你用的 embedding 模型和业务领域。

召回数量（top_k）。默认值通常 3 到 5。注意，这里不要贪多。我一开始把 top_k 设成 20，以为记忆越多越有助于对话，结果 Claude 的回答反而变得很奇怪——它会把 20 条记忆里的陈年旧事当成当前语境，在无关话题上频繁回头解释。后来我把 top_k 降到 4，再配合阈值过滤，回答质量明显回升。

TTL（生存时间）。这个参数要按业务区分。用户所在地区、职业、语言偏好这类稳定信息可以设 90 天甚至更长；而像“用户正在学习 Python 的 to-do”这种阶段型信息，设 7 天就够了。如果所有记忆都无脑设 30 天，你会发现很多失效的旧记忆还在发挥作用，比如告诉用户“上次你提到在学 Flask”——其实那个项目早就结束了。

3.4 我在写记忆时踩过的几个原则

说来惭愧，这些原则大多是我犯了错之后才总结出来的，这里直接当避坑清单给你：

• 不要存情绪化原文。用户说“这个功能太烂了”，不表示他要表达“功能烂”是他的长期偏好，更可能是产品本身该改。这类话语要过滤掉，只有“用户希望功能 X 有 Y 效果”这种指令型信息才值得入库。
• 不要存动态临时信息。“用户今天网不好”这种话明天就失效了，存了就是在制造过期垃圾。动态信息直接留在对话上下文里，别进长期记忆。
• 每轮对话不要无脑写入。如果每轮都把整段对话压缩成一条记忆，记忆库会迅速膨胀，最后检索噪声大得没法看。应该先做一次“是否值得记”的判断，或者合并多条相近记忆，再入库。
• 记忆必须可以被删除。不要以为系统有遗忘机制就可以不提供人工清理入口。实际业务里，用户会主动说“忘掉我刚才说的地址”，如果你的系统没有即时删除能力，这个体验就是假的。

4. 实操过程与核心环节实现

4.1 安装与环境准备

claude-mem发布在 PyPI，安装方式很常规：

pip install claude-mem

环境方面需要准备三项：一个 Claude API Key（用于调用 Claude 本体做对话与摘要抽取）、一个 embedding 模型服务或本地模型路径、一个向量数据库连接配置。前两项可以合并：如果你使用 OpenAI 的 text-embedding-3-small 作为嵌入模型，那就需要额外配一个 OpenAI API Key；如果你用本地模型，比如 bge-m3，那就不需要外网依赖，但本地推理需要 GPU 或较新的 CPU。

我建议新手在前期直接用云端的 embedding 服务，等整个链路跑通了再切换本地模型。为什么？因为刚开始你大概率会遇到各种问题，如果 embedding 也挂在本地、向量库也本机跑，排查范围会被拉得很大；先用托管服务把链路简化，后续逐步替换，能省下不少调错时间。

安装后可以用命令行验证是否装好：

claude-mem --version

能看到版本号就说明基础环境 OK。接下来需要初始化配置目录，claude-mem会在你的用户目录下生成一个配置文件，用来保存向量库连接信息、embedding 模型名、默认阈值等：

claude-mem init

初始化时它会交互式地询问几个问题：使用哪个向量数据库（SQLite/Chroma/Qdrant）、embedding 模型是什么、默认 top_k 是多少。如果只想快速体验，选 SQLite 模式最方便，因为零依赖，一个二进制文件就搞定了所有记忆存储。

4.2 配置注入：环境变量与配置文件

claude-mem的核心配置集中在环境变量和配置文件两处。配置文件在初始化后生成，我以实际为准展示一下关键字段的含义：

memory: backend: sqlite # 可选 sqlite / chroma / qdrant embedding_model: text-embedding-3-small score_threshold: 0.75 top_k: 4 default_ttl_days: 30 retrieval: max_query_length: 500 include_source: true logger: level: INFO

其中embedding_model字段决定了记忆怎么向量化。如果你用 OpenAI 的 embedding 接口，需要保证环境变量里已有 API Key：

export ANTHROPIC_API_KEY="你的Claude密钥" export OPENAI_API_KEY="你的embedding密钥"

这里有个小细节：Claude 的调用和 embedding 的调用是两条独立的链路，很多新手一开始只配了ANTHROPIC_API_KEY，结果到记忆写入环节一直报 401 错误，排查半天才发现是 embedding 服务的 KEY 没配。建议配置完成后先跑一次诊断命令：

claude-mem doctor

这个命令会检查配置、API Key、向量库连通性，并给出三色状态提示。我接入时靠它快速定位了三个问题：SQLite 路径不可写、embedding 模型名拼写错误、环境变量没有 export 到当前 shell。强烈建议正式使用前先跑一次。

4.3 与 Claude 对话循环的接入

接下来是核心环节：把claude-mem接入到 Claude 的对话循环中。我用一段最小可运行代码来演示。

import os from claude_mem import ClaudeMem, MemoryConfig from anthropic import Anthropic # 1. 初始化记忆组件 config = MemoryConfig.from_file("mem_config.yaml") mem = ClaudeMem(config) # 2. 初始化 Claude 客户端 client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"]) namespace = "user_42" # 多用户产品中记住用 namespace 隔离 def ask_claude(user_input: str) -> str: # 第一步：基于当前输入检索相关记忆 memories = mem.recall(user_input, namespace=namespace) memory_block = mem.build_memory_prompt(memories) # 第二步：组装 messages，记忆区块放在 system 开头 system_prompt = memory_block + "\n你是用户的私人助手，请自然遵循上述记忆。" messages = [ {"role": "user", "content": user_input} ] # 第三步：调用 Claude response = client.messages.create( model="claude-3-5-sonnet-20241022", system=system_prompt, messages=messages, max_tokens=1024, ) reply = response.content[0].text # 第四步：异步/同步执行记忆写入 mem.remember( user_input=user_input, assistant_reply=reply, session_id="session_88", namespace=namespace, ) return reply

这个流程说起来只有四步，但每一步都有值得展开的细节：

mem.recall内部会先把 user_input 向量化，再到向量库做 top-k 相似度检索。它在返回前已经按相似度过滤过一轮，所以你拿到的基本都是“当前问题相关的长期记忆”。

mem.build_memory_prompt是专门负责格式化输出的函数。它不会把结果拧成一行，而是按- 记忆内容（来源：会话ID 第N轮）的格式排好，注入位置也帮你留好了。这段输出的排版不用再自己动手处理。

mem.remember内部会先调用一次 Claude 完成“抽取压缩”，也就是把这一轮对话压缩成一条或几条记忆文本，然后再调用 embedding 模型生成向量，最后写库。这里是耗时最明显的一步，我建议用异步任务处理，或者至少不要阻塞主对话流程。如果用户的对话响应速度要求很高，可以考虑把 remember 放进后台队列，等 Claude 回复后离开主线程再执行。

4.4 实战验证：一个带记忆的多轮问答

为了验证claude-mem是否真的有效，我搭了一个非常简单的实验：让 Claude 充当个人购物助手，第一轮先告诉它“我不喝咖啡因，所有饮品推荐都排除咖啡”。过了十分钟，开启一个全新会话，也就是完全不带历史消息，只带上claude-mem检索出的记忆，再问它“推荐个工作间隙的饮品”。

第一轮对话写入记忆后，第二次全新会话里，claude-mem的 recall 成功召回了“用户不喝咖啡因”这条记忆，Claude 给出的回复是“推荐洋甘菊茶、无因咖啡或柠檬水”，并且主动补充了一句“因为你提到要避开咖啡因”。整个过程我没有手动拼接任何历史消息，效果上就完成了“跨会话记忆”。而对照组——不带 claude-mem 的普通 Claude 调用——则直接推荐了美式和拿铁，结果相当有说服力。

从这个实验可以看出，记忆注入对结果的影响不是“锦上添花”，而是“直接改变回答内容”。尤其是偏主观偏好的场景，比如饮食习惯、风格偏好、思考方式，有没有记忆的差别非常大。

4.5 性能优化与缓存策略

claude-mem接入之后，最常见的性能瓶颈在两条链路：embedding 模型推理耗时和向量数据库查询耗时。

对于 embedding，如果使用云端 API，单次调用通常 100 到 300ms，这在每轮对话都要写入记忆的场景下会拖慢整体延迟。我的优化办法是引入简单的结果缓存：对相同或高度相似的记忆文本，短时间内复用已有的 embedding 向量，不重复请求。具体可以用 Redis 或内存字典做一层 key-value 缓存，key 是文本的 hash，value 是向量数组。

对于向量库，SQLite 后端在数据量低于十万条时性能都很好，但如果你的记忆表增长到了百万级，就需要考虑换用 Qdrant 这类专门的向量数据库，并对命名空间字段建索引。Qdrant 支持 payload 字段过滤，可以把 namespace 过滤和向量检索放在同一个查询里完成，延迟比“先全量查再过滤”低一个数量级。

还有一个容易被忽略的点：如果你在服务端做了类似 LangChain 的 Agent 编排，那么 claude-mem 的 recall 调用最好放在 Agent 开始规划之前，而不是每次工具调用时都触发一次。记忆是一次性的“上下文补给”，不是每步都要重复查询的数据库。

5. 常见问题与排查技巧实录

5.1 问题速查表

这里我把实际用claude-mem时高频遇到的问题整理成了一张速查表。这些问题我基本都遇到过，或者帮别人排查过，含金量不低。

5.2 排查思路：我一般按什么顺序定位问题

如果你跟大多数人一样，一开始加入claude-mem后发现效果不对，我的排查建议是倒着查：从结果端倒推到输入链路。

先看召回结果对不对。直接写段测试脚本，调用mem.recall("用户平时喜欢喝什么")，看打印出来的记忆列表。如果召回的结果与问题毫无相关性，问题大概率在 embedding 模型的语义理解，或者 score_threshold 参数上，而不是 Claude 层。

再看写入链路是否完整。很多“记忆没用”的案例其实是写入失败或写入为空。打开日志查看一下 remember 后的响应内容，看看 Claude 抽取出来的记忆文本是否为 null，或者是否直接返回了“没有值得记住的内容”。这种时候一般需要调抽取 Prompt，让它更积极地提取用户偏好类信息。

最后看注入格式是否生效。有时召回没问题，写入也没问题，但 Claude 就是不响应记忆，这时候大概率是注入的 memory_block 被放在了 messages 的错误位置，或者与内置 system 指令冲突。把build_memory_prompt的输出打印到控制台，肉眼检查一遍格式和顺序，基本都能找到问题。

5.3 两个容易忽略的“坑”

第一个坑是命名空间大小写不一致。我做过一个多租户系统，用户 ID 一段来自路径参数，一段来自数据库主键，一个是大写 UID，一个是小写 uid，结果两边写入和读取的 namespace 不一致，导致记忆互相不认。这个问题当时排查了很久，因为从单条链路看没有任何报错，只有把 namespace 打印出来才暴露。建议在入口处统一做一次namespace.lower()或 hash 处理，避免这种低级歧义。

第二个坑是Claude 的 system 指令与记忆内容的隐性冲突。比如你原本在 system 里写了“你是一个严谨的金融顾问，不要给用户任何非专业建议”，但如果用户记忆里有“用户喜欢幽默的段子式表达”，这两条指令可能让 Claude 在每次回答时都陷入矛盾状态，输出变得犹豫、反复、甚至自我纠正。说实话这个问题很难在技术层面完全自动解决，我的做法是在写入记忆时加一个“指令冲突检测”，如果新记忆含有“用户偏好”类指令，且与现有 system 的强约束关键词重叠，就把它降级为“上下文提示”，而不是“必须遵守”级指令。

5.4 中文本地化与模型调优经验

最后专门聊聊中文场景。很多开源记忆项目默认基于英文 embedding 模型调参，直接搬到中文场景后效果打折扣。我试过两套方案：一是把 embedding 换成 bge-m3，这个模型对中文的支持明显优于默认的开源小模型，语义相似度打分也更稳定；二是对记忆文本做轻量预清洗，比如把用户口语化表达里的语气词、重复短语去掉再入库。

还有一个实用的技巧：在记忆抽取阶段，明确告诉 Claude“这是中文环境，请输出精简的中文记忆条目”。claude-mem的抽取逻辑依赖模型的总结能力，如果你在 system 里没做语言限定，Claude 可能会混着英文输出记忆，导致 embedding 向量空间不匹配，中文查询召回英文记忆时语义失真。加上这一句限定之后，召回准确率提升非常明显。

另外，中文用户经常会出现“口语片段”和“书面表达”的语义鸿沟，比如用户说“我这人不太能吃辣”，而查询时说的是“推荐个不辣的凉菜”。英文场景下这两个文本的相似度可能较高，中文场景下就需要 embedding 模型对饮食偏好有更强的泛化能力。如果你发现这类语义关联召回不出来，试试把默认阈值下调 0.03 到 0.05，通常能缓解。

6. 写在最后的一些建议

我记得第一次把claude-mem完整跑通时，心里唯一的感受是“早该用这个东西了”。它不算复杂，但解决的问题非常实质——大模型应用的体验上限，很多时候不取决于模型多聪明，而取决于它能不能记住用户是谁。这里想给准备上手的读者三个来自实践的忠告：

第一，先想清楚你的产品里什么值得记。不要一股脑把所有对话都塞进记忆系统。一个健康的记忆体系，应该是大部分内容自然遗忘、小部分关键信息长期稳定的状态。你越早确定“哪些信息有长期价值”，记忆系统的效果就越可控。

第二，把记忆视为产品功能，而不是底层技术。记忆的写入、召回、遗忘都应该有产品化的入口，让用户能看到“它记得我什么”、能主动清除某些记忆。claude-mem提供了底层的删除和遗忘接口，但真正把它变成用户可感知的信任感，还是需要业务层去设计交互。

第三，定期审查记忆库的内容。我在项目的生产环境中保留了每周一次的记忆健康度检查：统计记忆条数、过期率、重复率、零访问率。这个习惯帮我早发现了两类隐患：一是某条记忆的高频访问集中在非常窄的话题上，说明检索逻辑过于偏重单点；二是大量中低热度记忆累积导致召回精度下降，后来直接调大了 TTL 淘汰幅度。这种数据驱动的工作方式，比单纯调参数靠谱得多。

claude-mem不是一个万能钥匙，但在“给 Claude 加上长期记忆”这件事上，它提供了一个足够顺手、足够透明的起点。如果你的项目也卡在“模型很强但记不住用户”的困境里，拿它当底座改造，比自己从零折腾向量库、写抽取逻辑要快得多。