智能体持久化记忆：基于mem0与COS Vectors的工程实践

我们内部孵化的“小龙虾”项目是个跑在OpenClaw框架上的智能体，最初只是想做一个能长期陪用户深聊的助手——聊行业、聊偏好、聊项目计划。早期demo阶段一切正常，结果一进入连续对话就原形毕露：用户上周明确说了“不要用太正式的口气”，这周它又端起来了；用户前几天提过自己在做跨境电商，今天问它“我之前说过我做什么的吗”，它一脸茫然。说到底，大模型没有长期记忆，对话一旦超出上下文窗口，过去的信息就被冲走了。

于是我们决定给“小龙虾”加一层真正能落盘的持久化记忆。技术选型最终敲定为：用mem0处理记忆的管理和组织，用对象存储自带的向量检索能力（也就是云控制台里的COS Vectors）做底层存储与语义召回。整套方案从设计到落地大概花了两周，中间踩了不少坑。这篇就把我们为什么这么选、怎么接、以及遇到的各种问题一次性讲清楚。

1. 先搞明白：对话模型为什么天生“记不住”

1.1 上下文窗口不是记忆，只是一张临时草稿纸

想理解为什么要单独做记忆层，得先理解大模型对话的底层机制。每一次请求，我们都要把历史对话、用户信息、系统指令全部拼进提示词里发给模型。模型并不是“记得”你之前说过什么，它只是“看到”了这次你塞给它的内容。

这个机制带来两个问题：第一，上下文窗口是有上限的，几千到几万token不等，对话一长，最前面的内容就被挤出去了；第二，就算窗口能放下，每次请求都要把所有历史重新编码一遍，重复计算KV Cache，延迟和费用都扛不住。所以“对话即记忆”这条路，在产品化阶段基本走不通。

1.2 持久化记忆层到底要解决什么问题

回到“小龙虾”的具体需求。我们要的不是把全部对话原封不动存下来，而是只记录那些值得被长期记住的信息，并且能在合适的时机把相关信息找回来。我们当时列了四个硬性要求：

• 能记住用户的事实性信息，比如职业、偏好、正在做的项目；
• 能跨会话检索，也就是今天聊的内容和两周前聊的内容要能关联上；
• 记忆要支持更新和淘汰，用户改变想法后旧记忆不能继续捣乱；
• 接入方式对上层尽量透明，OpenClaw框架这边只需要调用接口，不需要关心底层怎么存储、怎么检索。

这四点直接决定了方案走向：记忆管理逻辑要自己掌控，存储层必须具备批量写入和相似度召回能力。

1.3 为什么Redis或关系数据库解决不了

有人提过：用户偏好不就是键值对吗，用Redis存一下不是很简单？确实，最粗暴的场景可以这么做。但实际操作你会发现几个坎：第一，从对话里抽取出来的信息是自然语言，很难结构化地塞进关系表；第二，也是最关键的，检索没法做。用户问“我上次提到的对某个行业的看法”，你用SQL根本写不出一个能精准匹配语义的查询。这类问题的本质是语义相似度匹配，而这个是向量检索的地盘。

向量检索的基本思路是：把文本转成高维向量表示，查询时同样转成向量，然后算两个向量的距离，距离近的就是语义相近的内容。这比关键词匹配强在“懂意思”——用户说“日常安排”，也能召回之前提到的“作息时间、带娃、健身”这些表述不同的相关内容。

2. 整体架构：mem0管“怎么记”，COS Vectors管“存在哪”

2.1 三层架构与一次完整的数据流

落地后的记忆系统分成三层：

• 应用层：OpenClaw框架，负责对话和工具调用；
• 管理逻辑层：mem0，负责记忆提取、分类、更新、淘汰；
• 存储层：对象存储的向量检索能力（COS Vectors），负责向量写入、索引和相似度查询。

一次完整的记忆处理流程是这样的：

1. 用户和“小龙虾”对话，OpenClaw把对话记录传给mem0；
2. mem0调用大模型从对话中抽取值得记住的信息，比如“用户偏好Markdown格式记录日志”；
3. 每条记忆经过Embedding模型转成向量，写入COS Vectors，同时附带用户ID、时间戳、来源会话等元数据；
4. 用户发起新一轮对话时，mem0基于当前问题生成查询向量，从COS Vectors召回最相关的Top-K条记忆；
5. 召回的文本格式化后注入OpenClaw的上下文，模型回答时就能“想起来”。

流程看起来不复杂，但每一步都有细节要处理，后面实操部分会展开讲。

2.2 mem0在这个链路里到底做了什么

mem0本身不负责向量索引的底层实现，它解决的三个问题恰恰是我们自己写容易翻车的：

• 记忆的自动抽取：输入一段对话文本，它调用LLM把其中值得记住的信息结构化，生成记忆条目；
• 记忆的类型组织：区分用户事实、偏好、对话片段等不同性质，便于后续处理；
• 记忆的更新机制：如果一条新记忆和已有旧记忆冲突，它用LLM判断两者是否在说同一件事，是的话就用新信息覆盖旧信息，同步更新向量库里的内容。

我们选mem0最核心的原因就是第三点。自己实现记忆更新逻辑太容易写蹦了，因为“两条记忆描述的是不是同一件事”本质上是语义判断，直接在向量相似度层面处理精度不够。mem0把这一步放到LLM层做，准确率高很多。

2.3 向量检索解决了关键词匹配搞不定的问题

在接向量检索之前，我们先用关键词匹配做了一版原型，效果可以用“惨烈”形容。用户问“你对我的工作节奏了解多少”，关键词匹配根本不知道“工作节奏”和用户之前提的“每天早上先处理消息，下午集中写方案”有什么关系。

换成向量检索之后就顺多了。文本先做语义编码再算相似度，哪怕用户换了一种问法，也能把语义一致的内容捞出来。这也是目前绝大多数AI记忆系统选向量检索作为存储底座的原因。

2.4 为什么选对象存储自带的向量检索，而不是自建向量库

调研阶段我们对比过三条路线，当时列了一个对比表：

核心原因很实际，团队没有专职运维，能少一个独立服务就少一个出问题的地方。对象存储本来就在用，数据和向量放同一个桶、用同一套鉴权，接入成本最低。对于“小龙虾”这种实验性质的项目，把精力放在业务逻辑上比花在基础设施上划算得多。

3. 实操：在OpenClaw里把mem0和COS Vectors接起来

3.1 环境准备与依赖安装

运行环境是一个普通的Linux容器，Python 3.10，OpenClaw通过Docker部署。需要装的Python依赖并不多：

pip install mem0ai pip install cos-vectors-sdk pip install openai

这里有一个安装细节值得单独说：mem0ai默认依赖比较多，会拉一堆我们用不上的包。后来我们改用pip install mem0ai --no-deps，再手动补缺的依赖，容器体积小了不少，安装时间也短了。

3.2 初始化COS Vectors客户端和集合

COS Vectors的基本操作逻辑是：先创建集合（Collection），相当于关系数据库里的表；集合里可以写向量、原始文本、标量字段（比如用户ID、时间戳）；查询时既可以用向量相似度，也可以叠加标量过滤条件。

from cos_vectors import Client client = Client( region="ap-guangzhou", # 替换成你的地域 bucket="claw-memory-1250000000", # 替换成你的存储桶 secret_id=os.getenv("COS_SECRET_ID"), secret_key=os.getenv("COS_SECRET_KEY") ) collection_name = "claw_memories" if not client.collection_exists(collection_name): client.create_collection( collection_name=collection_name, dimension=1024, # 必须和Embedding模型输出维度一致 metric="COSINE" )

dimension这个参数是第一个大坑。它必须和你选的Embedding模型输出维度完全一致。我们一开始用了一个384维的Embedding模型，后来想升级成精度更高的1024维模型，结果旧数据全部作废，只能重新生成向量。这个事后面在问题排查部分展开讲。

3.3 写一个适配器，让mem0指向COS Vectors

mem0通过一个store接口对接不同后端。默认它支持很多主流向量库，但像COS Vectors这种云厂商方案就需要自己写适配器。好在接口设计得比较薄，核心就是add、search、delete三个方法。

from mem0 import Memory class CosVectorsStore: def add(self, vectors, payloads, ids): # 批量写入向量、文本内容和标量字段 client.upsert_vectors( collection_name="claw_memories", vectors=vectors, ids=ids, payloads=payloads ) def search(self, query_vector, top_k=10, filters=None): results = client.query_vectors( collection_name="claw_memories", vector=query_vector, top_k=top_k, filter=filters ) return [ {"id": r.id, "score": r.score, "metadata": r.payload} for r in results ] def delete(self, ids): client.delete_vectors( collection_name="claw_memories", ids=ids ) memory = Memory.from_config({ "llm": { "provider": "openai", "model": "gpt-4o-mini" }, "embedder": { "provider": "openai", "model": "text-embedding-3-small" }, "vector_store": { "provider": "custom", "store": CosVectorsStore() } })

这段代码是整套接入过程的骨架。网上讲mem0的教程不少，但大多数只介绍它默认支持的那几个向量库，很少有讲怎么对接云服务商方案的。我们当时对着源码翻了一遍，才确认store接口抽象得这么薄，拾掇一下就能接上。

3.4 在OpenClaw工具层挂上记忆能力

OpenClaw支持给智能体注册自定义工具，我们就把记忆能力封装成了两个工具：memory_search和memory_save。

@tool("memory_search") def memory_search(query: str, user_id: str) -> str: """Search user memories for the given query.""" results = memory.search(query, user_id=user_id, limit=6) return format_memories_for_prompt(results) @tool("memory_save") def memory_save(conversation: str, user_id: str) -> str: """Save important information from conversation.""" messages = [{"role": "user", "content": conversation}] memory.add(messages, user_id=user_id) return "ok"

这里有一个重要的设计取舍：我们刻意把memory_save定义成显式工具调用，而不是把每一轮对话都自动喂给记忆层。原因很简单，全量自动抽取会产生大量无价值的记忆，比如“用户今天吃了午饭”这种，同时还会让模型调用成本翻倍。让模型自己判断“这段对话里有没有值得记下来的信息”再调用保存工具，是性价比最高的做法。

3.5 验证：一次跨会话召回

接入完成后，我们跑了一个最基础的验证场景。

第一轮对话，用户说：“我特别喜欢用Markdown格式写工作日志，你帮我整理一下今天的记录。”模型正常回答，同时触发memory_save，把用户的格式偏好写入了记忆库。

隔了一个多小时，用户第二轮发来消息：“你怎么又给我输出普通段落了？我之前说过的呀。”这时候memory_search触发，检索出“用户偏好Markdown格式记录日志”这条记忆并注入上下文，模型立刻调整输出格式，把内容转成了Markdown。

这个场景看着简单，但没加记忆层之前，模型第二次几乎必错。我们之前测试过太多次了。

4. 常见问题与排查心得

4.1 向量维度不一致，写入直接报错

我们升级Embedding模型的时候踩过一次大坑。之前用的模型输出384维向量，后来换成更高精度的1024维模型，但集合是之前建的，dimension参数没改。结果批量写入时报错dimension mismatch，排查起来倒是很快——对比一下集合定义和当前embedding输出的维度就能定位。

真正麻烦的是已经写入的历史向量和新向量维度不同，无法在同一个集合里做相似度计算。最后只能重新建集合，把所有原始文本重新过一遍Embedding再写入。这个教训让我定了一条铁律：Embedding模型在项目早期就要定下来，尽量别换。如果实在要换，务必保留原始文本，方便重新向量化。

4.2 召回内容太杂，旧记忆“带偏”模型

接入初期还有一个很头疼的现象：模型经常被不相关的旧记忆带偏。比如用户两个月前提过“我想学做菜”，今天问“帮我推荐几款效率工具”，模型回答里居然先聊起了烹饪。

排查后定位到两个原因：一是top_k设得太宽，默认拉了10条，里面混了不少低相关度的记忆；二是没有做重排和阈值过滤。

我们的调整方案：

• 把top_k从默认10收敛到6；
• 在查询时增加user_id过滤，保证每个人的记忆之间不会互相串场；
• 在mem0配置里加上相关性阈值，低于阈值的记忆直接不返回。

另外，如果场景对时效性要求高，还应该在Filter里加上时间范围条件。比如需要“最近一个月的记忆”时，把时间字段作为过滤条件传进去，能显著降低噪声。原理很简单，向量相似度管的是“像不像”，但“像”的不一定都是当前需要的。

4.3 记忆冲突：当“喜欢简洁”遇上“喜欢详细”

mem0的更新机制理论上能覆盖旧的记忆，但前提是LLM能判断出新旧记忆描述的是同一件事。我们在实际使用中见过不少判定失败的情况，比如“用户喜欢简洁回答”和“用户倾向给出详细分析的报告”这两条记忆，LLM认为不是同一维度的事情，两条都保留了。结果模型一会儿简洁一会儿详细，表现飘忽。

我们最后用了工程上的折中方案：在保存记忆时强制附带主题标签，比如work_style、project_info、personal_pref。查询时先按标签粗筛一次，再在标签内部做语义排序。同时写了一个定期清理任务，对同一标签下的记忆做合并，把过时的旧记忆标记删除。这个方案执行了一个月，效果稳定了很多。

4.4 记忆注入导致上下文膨胀

每次检索召回6条记忆，每条平均200字左右，初看不多。但多轮对话里，每轮都注入同样规模的记忆，上下文还是会明显膨胀。如果记忆内容里包含大段原始对话原文，问题会更加严重。

我们的解决办法是在注入之前加一道“记忆摘要”环节：召回的原始记忆先让LLM压成一句话，再拼到上下文中。虽然多了一次模型调用，但上下文占用显著下降，而且模型看到的记忆信息更凝练，反而更容易抓住重点。对“小龙虾”这种需要保持长时间连续对话的项目来说，这一步基本必做。

4.5 成本与性能：记忆不是免费午餐

接入记忆层之后，成本明显上涨。我们统计过，一次完整对话平均会额外产生两到三次模型调用——抽取记忆一次、可能触发更新一次、可选摘要一次，再加上向量化的费用，整体开销比纯对话多了20%到30%。

控制成本的经验有三条：

• Embedding模型尽量选small版本，记忆检索场景对向量精度要求没想象中高；
• 更新记忆时设置相似度阈值，只有高置信度的新旧记忆匹配才触发更新，减少无效调用；
• 对话文本不要全量喂给记忆层，先做一轮“是否值得记住”的预判，不值得的直接跳过。

性能方面也有个容易被忽略的点：向量写入和Embedding生成都有网络IO，如果memory_save同步执行，会明显拖慢对话响应。我们把memory_save改成了后台任务，对话不等记忆落盘完成就返回；memory_search则保持同步调用，因为它直接影响回答质量，值得等。

最后说点实操体会

给“小龙虾”加上这套持久化记忆层之后，我最大的体感变化不是模型单轮回答变聪明，而是整个对话过程从“断片式”变成了“连续式”。用户能明确感受到AI“记得”自己，这种连续体验带来的信任感，是单纯堆模型参数换不来的。

但我更想提醒一句：记忆系统不是存得越多越好。存了一堆低质量记忆，反而会干扰模型判断。好的记忆系统应该会做减法——定期清理、合并、合适的“遗忘”。我们后续正在给mem0的更新逻辑加一个基于时间衰减的权重，让旧记忆逐步让位给新信息。说到底，AI的记忆和人的记忆一样，不是一块硬盘，而是一个需要持续新陈代谢的系统。