先交代背景。我一直在做 AI 辅助日常工作的落地桌面端、Web 端、手机端、编辑器插件轮着用。用了半年多最烦的一个问题就是同一个 AI 服务在这个客户端里聊过的上下文换到另一个客户端就全断了。比如我在电脑上让 AI 梳理了一份项目的技术方案转头在手机上问“那个方案里的数据库选型定了没有”它一脸茫然。这种“记忆断裂”在 AI Agent 场景下尤其致命因为 Agent 的连续推理、多步任务执行都依赖上下文而上下文一旦散落在多个客户端里等于没有上下文。后来我去调研了 mem0业内很火的开源记忆层方案理念很吸引人把每次对话提取成结构化记忆用向量和图混合存储查询时做智能重排。但我把它接入到真实的多客户端工作流里跑了两周之后还是决定自己写一套跨客户端 AI 记忆共享系统。这篇文章把我当时的对比过程、踩过的坑、最终的自研设计和关键参数完整记录下来给同样在折腾 AI Agent 记忆层的朋友做个参考。1. 我为什么放弃了 mem0不是它不够好而是场景不匹配先说结论mem0 本身是个好项目但它的默认设计是为“单客户端、单 Agent、以查询为核心”的场景服务的。而我实际面对的是“多个客户端、多个 Agent、以同步为核心”的场景这两者对架构的要求完全不一样。1.1 先说我的实际场景多客户端共享的真正困境我的日常使用方式是这样的电脑上的浏览器插件负责长文阅读和资料整理手机上的 AI 助手负责碎片化记录和语音问答IDE 里的 AI 插件负责代码生成和项目理解还有一个跑批任务的脚本会定期和 AI 交互生成日报。这些客户端理论上都在服务同一个“我”但它们各自的对话历史、用户画像、项目知识是完全割裂的。这意味着什么我在 Web 端告诉 AI“我项目 A 的技术栈是 Python FastAPI PostgreSQL”换到手机端去问“项目 A 的部署脚本在哪”它回答不了。它连项目 A 是什么都不知道。更麻烦的是如果两个客户端同时问我同一个问题它们的回答会基于完全不同的上下文给出两个互相矛盾的结论。所以跨客户端记忆共享的第一步不是把记忆“存起来”而是把记忆“从单机私有状态变成多端一致的公共状态”。这个从“私有”到“公共”的转变是架构层面的大改动而不是在现有框架上打个补丁。mem0 在我的场景里吃亏就吃亏在这一点。1.2 mem0 的设计优势以及它在我这里的三个硬伤必须客观说mem0 的理念和模块划分是漂亮的。它把 memory 抽象成三类用户记忆、会话记忆、Agent 记忆底层用向量库做语义召回用图数据库存实体关系查询时会做一种“来自不同来源的智能重排”把最相关的记忆优先拿出来。这种设计在“单 Agent 连续对话”的场景下表现很好我单独测试时也确实觉得它有灵气。但放到多客户端共享场景里三个硬伤立刻暴露第一mem0 本质上是“库”而不是“服务”。默认用法是每个客户端进程内初始化一个 Memory 实例各自独立工作。虽然官方也提供了服务化和自托管方案但客户端要共享记忆必须自己解决登录态、用户映射、会话归属等一系列问题。这部分官方给的引导偏少集成时基本靠猜。第二记忆提取和查询重排都重度依赖 LLM。每轮对话要调用多次模型接口做提取、打分、重排。在我每天几十条消息的体量下账单不至于吓人但一旦有多个客户端同时在线又都往同一个记忆服务上写成本翻倍波动很明显。而且 LLM 调用是有延迟的提取一次记忆平均 300-600 毫秒这个延迟会直接叠加在用户可感知的响应路径上。第三数据模型偏“单用户单 AI”。它设计了一套以 person_id 和 memory 为核心的简单结构但我的场景里需要给不同项目、不同 Agent、不同客户端做隔离和权限控制。比如公司项目的记忆不应该出现在个人闲聊的上下文里这个需求用 mem0 的默认数据模型得自行扩展很多字段和过滤逻辑等于在别人设计的骨架上做二次重构。1.3 成本、延迟、集成度我跑的一组对比数据为了让“放弃 mem0”这个决定不是凭感觉我专门做了一组对照测试。测试环境是同一台 8 核 16G 的服务器记忆条目数控制在 3000 条客户端接了 3 个模拟连续对话 100 轮。对比维度mem0自托管 云端 LLM我的自研方案本地模型 混合检索单次查询平均延迟620ms包含 LLM 重排96ms词法 向量融合单次记忆提取成本约 0.01-0.02 元API 调用几乎为 0本地 embedding 本地小模型多客户端同步需要自行搭同步层服务端原生支持客户端接 API 即同步客户端接入耗时约 1-2 天登录态 同步逻辑约 2 小时一个 SDK 搞定数据隔离粒度粗需要自行扩展细namespace client 双维度这组数据说明了一个朴素的问题在单机、单客户端、数据量几千条的场景里mem0 完全够用。但我的核心诉求是“多端一致”和“可控成本”这两点它给不了。所以我决定自己写一个哪怕牺牲掉一些花哨的重排能力也要先把跨客户端记忆同步这个地基打牢。2. 动手前先想清楚记忆系统的边界条件和设计取舍说实话一开始我也想“上一个完整的记忆系统”做了几天之后发现方向偏了。记忆系统的目标不是“记住所有东西”而是“在需要的时候把恰好相关的信息准确找出来”。想明白这一点很多功能都可以砍掉架构也会简单很多。2.1 跨客户端记忆到底要解决哪三个问题我把需求压缩成三个问题后续所有设计都是围绕它们展开的。第一是写入一致性。客户端 A 写入一条记忆客户端 B 必须能立刻看到。这里的关键不是“最终一致”而是“低延迟一致”。因为 AI 对话是交互式的如果手机端问了问题却拿到的是桌面端 1 小时前的记忆快照用户立刻会感觉到不对。第二是检索准确性。记忆库里可能存了用户几个月以来的对话摘要、项目信息、偏好设置。用户问“上次说好的接口返回格式是什么”系统要能准确找到那一条而不是把所有含“接口”两个字的记忆都倒出来。这要求检索不能只靠语义相似度还要有词法匹配、时间衰减、重要性加权等多重信号。第三是隔离与安全。多个客户端共用一个记忆库不代表所有客户端可以看所有记忆。我明确要求公司项目的记忆只对工作客户端可见个人偏好只对个人助手可见。这个隔离必须在系统层面做好不能靠每个客户端自觉。2.2 记忆分层短期、长期、全局、局部的设计思路我参考了认知科学里工作记忆和长期记忆的区分把记忆分成四个池子。短期记忆池保存的是最近若干轮对话的摘要TTL 很短可能是 2 小时或者一个会话的生命周期。它解决的是“同一会话内的连续性”比如你刚才让 AI 写了一段代码现在问它“这个代码里为什么用了异步”它得记得刚才的上下文。长期记忆池保存的是跨会话的稳定信息比如用户的偏好、项目背景、技术选型、做事习惯。这类记忆的 TTL 很长重要性高是检索时的重点对象。全局记忆池保存的是关于用户身份的基础信息比如“这个用户是一名后端开发者”“他倾向于先写测试再写实现”。全局记忆会被所有客户端共享所有 Agent 在首次交互时都会先读取它。局部记忆池则带 namespace 隔离比如某个具体项目的记忆归到 project:xxx 命名空间下只有处理这个项目的 Agent 才能访问。这四个池子不是物理上分开存储的而是同一份数据带上不同标签在写入时通过标签分类在检索时通过标签过滤。这样存储层保持简洁逻辑层的灵活性也够。2.3 存储选型为什么我选了词法 向量混合而不是纯向量很多人一想到“AI 记忆”就默认得用向量数据库。我一开始也这么想但做了实验之后改变了主意。纯向量检索有个隐蔽的缺陷语义相近不代表因果相关。用户问“明天早上提醒我开会”向量检索很可能召回“他每天早上有跑步习惯”这种语义上挨得着、实际上没用的记忆因为两者的向量距离确实不远。所以我的存储层没有走“单一向量库”路线而是做了混合检索。对每一次写入既生成 embedding 向量存入向量索引也把原文做分词后存入全文索引。查询的时候两路检索并行执行再通过一个融合算法把结果合并排序。这样既保留了语义召回对“同义不同词”的泛化能力也保住了词法匹配对准确关键词的精确命中。生产环境我用了 PostgreSQL 加 pgvector单机开发环境直接用 SQLite 加 FTS5 和内置向量扩展。SQLite 版本在我测试 5000 条记忆时混合检索的耗时大概在 50-80 毫秒完全够用不用一上来就想着上分布式。3. 自研跨客户端 AI 记忆共享系统的整体架构这一章讲清楚系统长什么样、数据怎么流动、各模块之间怎么配合。3.1 核心组件与数据流我的系统分成四个核心组件记忆服务端、客户端 SDK、维护脚本、LLM 提取模块。记忆服务端是中心所有读写请求都经过它。客户端 SDK 是一个轻量 HTTP 封装负责把各端的对话上下文快照发送到服务端并拉取相关记忆。维护脚本负责定时做记忆衰减、归档、一致性校验。LLM 提取模块是从对话中抽取结构化记忆的关键环节但它被设计成独立服务可以随时降级或替换。完整的数据流是这样的用户在某个客户端里说了一句话客户端先把这句话作为查询条件调用记忆服务的检索接口拿到与当前语境最相关的历史记忆拼接到 Prompt 里再发给大模型。模型返回回答后客户端把这一轮对话发送到记忆服务的写入接口。写入接口先做一轮隐私过滤把明显的身份证号、手机号、密钥打码或剔除然后交给 LLM 提取模块抽取出偏好、事实、决策等结构化记忆再生成 embedding最后落库。落库成功后会通过消息队列广播一个“记忆更新”事件其他在线客户端收到事件后自动刷新本地记忆缓存。这个流程的核心原则是“读优先、写异步”。用户发出的查询必须尽快返回所以检索路径一定要短写入可以放到异步队列里慢慢处理不阻塞用户的对话响应。3.2 记忆条目的数据结构设计数据结构是在传统键值对基础上扩展出来的核心字段如下字段类型说明idstring全局唯一记忆 IDnamespacestring隔离域如 project:alpha / personal:generalclientstring写入客户端标识如 web / mobile / idetypestring记忆类型preference / fact / decision / entitycontentstring记忆正文通常是一句完整的话embeddingvector向量化的内容表示importancefloat重要性分数 0-1影响检索排序ttlint过期时间默认 -1 表示永久created_atdatetime创建时间updated_atdatetime更新时间versionint版本号用于冲突合并metajson扩展元信息如来源对话 ID、关联实体列表这个结构里最有用的是 namespace 和 type 两个字段。namespace 解决隔离问题type 解决记忆多样化问题。比如 typedecision 的记忆在排序时权重会高一些因为“用户拍板过的决定”比“随便说过的一句话”更值得被记住。3.3 API 设计与客户端接入方式客户端只需要对接两个核心接口一个是检索一个是写入。检索接口接收 query、namespace、client、top_k 等参数。服务端把 query 做词法检索和向量检索混合排序后返回命中的记忆列表。写入接口接收 session_id、client、messages 数组服务端自行完成提取和落库。还有一个可选的订阅接口客户端通过 WebSocket 订阅某个 namespace 的记忆变更事件用于实时刷新本地缓存。这样的接口设计让客户端接入成本降到很低。我现在的做法是每个客户端集成一个 200 行左右的 SDK封装好这三个接口其他什么都不用管。实测下来接入一个新客户端从开发到联调半天能完事。对比之前用 mem0 时自己搭同步层的 1-2 天效率提升非常明显。4. 核心模块的实操实现与关键参数接下来是重点我会把每个模块的具体实现方式、关键参数、以及我当时怎么调优的细节都写出来。4.1 记忆写入管线从对话到结构化记忆写入管线是整个系统里最复杂的一环也是直接决定记忆质量的一环。它的核心工作是把一段自由对话压缩成几条结构化的记忆条目同时过滤掉噪音和隐私信息。我用的 LLM 提取 Prompt 模板大概是这样的你是记忆提取助手。从下面的对话中提取值得长期记住的信息。 只提取以下四类 1. preference用户的偏好、习惯、禁忌 2. fact客观事实、项目背景、技术选型 3. decision用户做出的决策、拍板过的结论 4. entity重要的人、项目、工具、时间节点 输出 JSON 数组每个元素包含 type, content, importance0到1, expires_in小时-1表示永久。 如果没有可提取的内容输出空数组。这个模板看似简单但它起到的作用非常关键。它强制 LLM 用固定格式输出方便程序解析分类别提取又方便后续按类型做权重排序。我在实际使用中给 importance 做了一个启发式修正如果对话里出现了“我总是”“我从不”“一定不要”这类强偏好词importance 就自动加 0.2如果记忆内容涉及用户明确给出的项目代号或时间节点importance 也会上调。embedding 生成我一开始用的是云端接口后来为了降延迟和成本换成了本地部署的 embedding 模型单条文本的向量化时间约 10-20 毫秒。提取用的 LLM 则用了一个量化到 4bit 的 7B 开源模型跑在 GPU 上单次提取延迟约 400 毫秒。因为是异步处理这个延迟不会暴露给用户客户端。写入有一个重要细节不是每一轮对话都需要提取记忆。我把消息按“是否触发新信息”做了过滤高频的寒暄、重复提问、简单确认语都不会进入提取流程。这个过滤规则让 LLM 的调用量减少了约 70%成本下降非常明显。4.2 记忆检索管线混合检索和重排的权衡检索管线是用户感知最强的部分我把目标定在 150 毫秒内返回结果。第一步是词法检索。用全文索引的 BM25 算法把 query 分词后匹配命中的就带上一路候选集。第二步是向量检索。用 embedding 模型把 query 向量化在向量索引里按余弦相似度取 top 50。第三步是融合排序。我用的是经典 RRFReciprocal Rank Fusion公式score sum(1 / (k rank_i))其中 k 设成 60rank_i 是该条记忆在某一检索路中的排名。融合后取 top 20再做过滤和重排。过滤规则按顺序执行先过滤掉 namespace 不匹配的记忆再过滤超过 TTL 的过期记忆最后过滤掉带隐私标签的记忆。重排规则用线性加权最终分 0.5 x 融合分 0.3 x importance 0.2 x 时间衰减权重。时间衰减权重的公式是 exp(-age_days / 180)即 180 天半衰期。这样设计的结果是近期的重要决定排在前面陈旧且不重要的记忆自然沉底语义相关但实际无用的噪音也有机会被压下去。4.3 跨客户端同步与冲突合并我在这里踩过一个深坑跨客户端同步是整个系统的招牌功能也是踩坑最多的部分。我最初的方案很简单每次写入直接改数据库客户端查询时实时读库。结果发现一个问题——客户端为了降低延迟会在本地做缓存而缓存更新的触发条件如果设计得不好就会出现“桌面端已经更新了记忆手机端还在用旧数据”的同步延迟甚至因为两边同时写同一条记忆出现版本互相覆盖的冲突。后来我把同步机制改成“服务端推送 本地缓存失效”。服务端每次写入成功后通过消息队列向订阅了该 namespace 的在线客户端推送一条变更通知。客户端收到通知后把本地缓存里的对应记忆标记为过期下次查询时强制回源。本地缓存用 LRU 策略热点记忆 TTL 设为 15 分钟普通记忆 2 小时。冲突合并策略则用“版本号 时间戳”双管齐下。每条记忆带 version 字段客户端读取一下版本再写入。服务端比较版本号只接受高于当前版本的写入。如果两个客户端同时基于同一版本修改了同一条记忆则取 updated_at 更新的一条为准。为了唯一性每次写入都配一个全局唯一的 request_id服务端用这个 ID 做幂等避免网络重试导致重复写入。这个方案在内存条款里牺牲了一些精细合并能力但它简单可靠尤其适合记忆这种“取最新有效版本即可”的数据类型。4.4 记忆衰减、过期和冷热分层记忆不是越多越好存得太多反而会拉低检索准确性。我专门加了衰减和归档机制。维护脚本每隔 6 小时跑一次扫描对 TTL 到期且 importance 低于 0.3 的记忆直接标记为“已归档”从主索引里移除但保留在冷存储里可追溯。对 TTL 到期但 importance 较高或 typedecision 的记忆则延长 TTL例如再续 180 天。对超过 90 天没有命中的记忆即便没有过期也会降权处理避免陈旧记忆持续影响检索排序。冷热分层不是一开始就做的。我最初把所有记忆都放在同一个索引里结果数据量到了 8 万条时检索耗时明显上升约 400 毫秒。后来把“最近 30 天活跃记忆”放入热索引其余放到冷索引查询时先查热索引未命中再降级查冷索引。这样一个简单的改动让 95% 的查询都停在热索引阶段耗时回落到了 80 毫秒以内。5. 性能、成本与稳定性的一线实测技术方案不能只停留在理念上我把上线以来的实测数据整理出来这些数字基本可以复现。5.1 性能数据常规量级和多租户情况场景记忆总量单次查询耗时单次写入耗时异步摊分个人日常5000 条60-90ms约 300ms项目知识库2 万条100-120ms约 350ms多 Agent 共享8 万条180-250ms约 400ms这里关键的一条优化是批量写入。原来我一条一条提取、一条一条落库效率低。后来把同一会话中连续的 5-10 轮对话合并成一个大请求批量提取、批量写入写入吞吐提升了大概 3 倍LLM 调用次数也显著下降。5.2 成本对比自研和 mem0 的账单差异成本是我决定自研的最现实原因之一。我按每月 30 万条消息的规模粗略算过一笔账。用 mem0 加云端 LLM 方案假设 30% 的消息触发记忆提取每次提取消耗约 500 token大约要花掉 15 万次 LLM 调用按当前市场价算一个月光提取费用就在 100-200 元。如果查询时开启 LLM 重排这个数字还要再涨 30%。自研方案里LLM 提取用的是本地开源模型embedding 也走本地电费和 GPU 折旧摊下来每个月大概 30 元。两个方案差了一个数量级。这还是不谈数据隐私的代价。云端 LLM 要把对话原文传出去做提取这一条在我们处理项目文档时是不能接受的。5.3 稳定性设计和容灾方案我最担心的是本地 LLM 提取服务挂了之后整个系统会不会跟着挂。后来做了降级设计提取服务不可用时写入接口自动降级为“不提取结构化记忆只保留原始对话摘要”检索时靠词法匹配和向量检索兜底系统仍然可用。也就是说AI 提取是增强项不是必需项。消息队列也做了持久化。即使服务端在写入后、广播同步通知前崩溃客户端下次主动查询时也能从数据库拿到最新数据只是同步延迟从毫秒级变成秒级。我的容灾目标不是“零丢失”而是“关键记忆不丢、服务不整体不可用”。6. 我从这套系统上线前后踩过的坑这篇内容如果只说设计不说坑价值少一半。下面这几个问题都是我真实遇到过、花时间排查过的按典型程度排列。6.1 语义搜索并不万能召回偏差的典型案例有一次用户我自己在手机端问“明天开会材料准备了吗”系统召回的三条记忆里有一条是“用户每天早上有晨跑的习惯”理由是“明天早上”和“晨跑”语义相近。这属于召回偏差。单纯靠向量距离无法区分“明天早上开会”和“平时早上跑步”的关系。后来我加了两个修正一是对包含明确时间词的查询加时间过滤二是把词法检索结果在融合中的权重调高确保精确匹配不会输给语义泛化。6.2 同步风暴多个客户端同时写同一条记忆多客户端同时在线的场景里最恐怖的问题就是同步风暴。桌面端和手机端同时编辑同一条项目记忆两个客户端各自基于旧版本生成新版本造成持续互相覆盖日志里反复出现 version conflict。我最后靠“读取时带上版本号、写入时校验版本号”解决另外在客户端 SDK 里加了 200 毫秒的写入去抖同一客户端在 200 毫秒内对同一条记忆的多次修改只提交最后一次。这个去抖大大减少了冲突发生频率。6.3 隐私与安全在跨客户端场景下的具体要求跨客户端意味着数据会从多个入口进来权限边界必须清晰。我的处理是每个客户端启动时向服务端申请一个 client_tokentoken 绑定 namespace 列表。Web 端可以读写 project:xxx 和 personal:general手机端默认只能读写 personal:generalIDE 插件额外可读写 project:codebase。服务端在每条读写请求里校验 token 与 namespace 的对应关系不匹配直接拒绝。这种做法的好处是即使某个客户端的数据泄露了被波及的记忆也限定在它被授权的范围内不会把整个记忆库拖下水。6.4 一点关于 token 开销的教训刚上线时我把每一轮对话都交给 LLM 提取记忆成本飙升到让人心疼。后来加了一个“信息增量”判断如果当前消息和上一轮提取过的记忆语义重复度过高就跳过提取只更新原记忆的时间戳和权重。这个判断用向量相似度实现超过 0.9 就跳过。效果是提取次数下降了约 70%几乎感觉不到对比度差异。所以对于记忆系统真正省钱的不是选更便宜的模型而是减少无效提取。7. 这套系统的工程化扩展方向写完自研系统之后我并没有停下来。有几个方向是我已经在做或准备做的对同场景的人可能有参考价值。第一个是支持多 Agent 协作。现在多个客户端共享记忆本质上还是一个用户和一个 AI 服务之间的记忆。下一步我想把这个系统扩展成多个 Agent 之间的共享黑板让不同的 Agent 能够读取彼此的中间状态、任务进度、决策记录真正实现多体协作。第二个是更精细的记忆权限。现在的 namespace 隔离是粗粒度的。未来想做成类似“记忆级 ACL”每条记忆单独标注可见的 Agent 列表或用户组列表。第三个是记忆闭环反馈。系统目前只做存取没有做“记忆是否真的帮助了后续回答”的效果回传。我准备在检索接口里加入一个 feedback 字段客户端在回答结束之后回传哪些记忆被用到系统据此调整记忆的重要性权重让高价值记忆越用越靠前。还有一个现实问题需要提一下如果你也想自研记忆系统不必从零开始造所有轮子。我在实现中发现大部分存储和检索能力用现成的 SQLite、PostgreSQL 加开源 embedding 模型就能搞定真正需要自己写的只有三个点读取和写入的结构化提取、跨客户端的同步冲突逻辑、以及贴合自己业务场景的重排规则。把这三块想清楚系统就成功了一大半。我在这套系统的开发过程中最大的体会是不要被“AI 记忆”这个概念吓住本质上它就是一个带有语义检索能力的数据库难点不在存储而在“知道什么该被记住、什么该被忘掉”。mem0 在很多场景下确实值得一试尤其是单客户端、数据量不大、对延迟不敏感的项目但如果你像我一样需要多客户端共享、数据可控、成本敏感自己写一套轻量级的记忆服务反而是一条更踏实、更可控的路。
先交代背景。我一直在做 AI 辅助日常工作的落地桌面端、Web 端、手机端、编辑器插件轮着用。用了半年多最烦的一个问题就是同一个 AI 服务在这个客户端里聊过的上下文换到另一个客户端就全断了。比如我在电脑上让 AI 梳理了一份项目的技术方案转头在手机上问“那个方案里的数据库选型定了没有”它一脸茫然。这种“记忆断裂”在 AI Agent 场景下尤其致命因为 Agent 的连续推理、多步任务执行都依赖上下文而上下文一旦散落在多个客户端里等于没有上下文。后来我去调研了 mem0业内很火的开源记忆层方案理念很吸引人把每次对话提取成结构化记忆用向量和图混合存储查询时做智能重排。但我把它接入到真实的多客户端工作流里跑了两周之后还是决定自己写一套跨客户端 AI 记忆共享系统。这篇文章把我当时的对比过程、踩过的坑、最终的自研设计和关键参数完整记录下来给同样在折腾 AI Agent 记忆层的朋友做个参考。1. 我为什么放弃了 mem0不是它不够好而是场景不匹配先说结论mem0 本身是个好项目但它的默认设计是为“单客户端、单 Agent、以查询为核心”的场景服务的。而我实际面对的是“多个客户端、多个 Agent、以同步为核心”的场景这两者对架构的要求完全不一样。1.1 先说我的实际场景多客户端共享的真正困境我的日常使用方式是这样的电脑上的浏览器插件负责长文阅读和资料整理手机上的 AI 助手负责碎片化记录和语音问答IDE 里的 AI 插件负责代码生成和项目理解还有一个跑批任务的脚本会定期和 AI 交互生成日报。这些客户端理论上都在服务同一个“我”但它们各自的对话历史、用户画像、项目知识是完全割裂的。这意味着什么我在 Web 端告诉 AI“我项目 A 的技术栈是 Python FastAPI PostgreSQL”换到手机端去问“项目 A 的部署脚本在哪”它回答不了。它连项目 A 是什么都不知道。更麻烦的是如果两个客户端同时问我同一个问题它们的回答会基于完全不同的上下文给出两个互相矛盾的结论。所以跨客户端记忆共享的第一步不是把记忆“存起来”而是把记忆“从单机私有状态变成多端一致的公共状态”。这个从“私有”到“公共”的转变是架构层面的大改动而不是在现有框架上打个补丁。mem0 在我的场景里吃亏就吃亏在这一点。1.2 mem0 的设计优势以及它在我这里的三个硬伤必须客观说mem0 的理念和模块划分是漂亮的。它把 memory 抽象成三类用户记忆、会话记忆、Agent 记忆底层用向量库做语义召回用图数据库存实体关系查询时会做一种“来自不同来源的智能重排”把最相关的记忆优先拿出来。这种设计在“单 Agent 连续对话”的场景下表现很好我单独测试时也确实觉得它有灵气。但放到多客户端共享场景里三个硬伤立刻暴露第一mem0 本质上是“库”而不是“服务”。默认用法是每个客户端进程内初始化一个 Memory 实例各自独立工作。虽然官方也提供了服务化和自托管方案但客户端要共享记忆必须自己解决登录态、用户映射、会话归属等一系列问题。这部分官方给的引导偏少集成时基本靠猜。第二记忆提取和查询重排都重度依赖 LLM。每轮对话要调用多次模型接口做提取、打分、重排。在我每天几十条消息的体量下账单不至于吓人但一旦有多个客户端同时在线又都往同一个记忆服务上写成本翻倍波动很明显。而且 LLM 调用是有延迟的提取一次记忆平均 300-600 毫秒这个延迟会直接叠加在用户可感知的响应路径上。第三数据模型偏“单用户单 AI”。它设计了一套以 person_id 和 memory 为核心的简单结构但我的场景里需要给不同项目、不同 Agent、不同客户端做隔离和权限控制。比如公司项目的记忆不应该出现在个人闲聊的上下文里这个需求用 mem0 的默认数据模型得自行扩展很多字段和过滤逻辑等于在别人设计的骨架上做二次重构。1.3 成本、延迟、集成度我跑的一组对比数据为了让“放弃 mem0”这个决定不是凭感觉我专门做了一组对照测试。测试环境是同一台 8 核 16G 的服务器记忆条目数控制在 3000 条客户端接了 3 个模拟连续对话 100 轮。对比维度mem0自托管 云端 LLM我的自研方案本地模型 混合检索单次查询平均延迟620ms包含 LLM 重排96ms词法 向量融合单次记忆提取成本约 0.01-0.02 元API 调用几乎为 0本地 embedding 本地小模型多客户端同步需要自行搭同步层服务端原生支持客户端接 API 即同步客户端接入耗时约 1-2 天登录态 同步逻辑约 2 小时一个 SDK 搞定数据隔离粒度粗需要自行扩展细namespace client 双维度这组数据说明了一个朴素的问题在单机、单客户端、数据量几千条的场景里mem0 完全够用。但我的核心诉求是“多端一致”和“可控成本”这两点它给不了。所以我决定自己写一个哪怕牺牲掉一些花哨的重排能力也要先把跨客户端记忆同步这个地基打牢。2. 动手前先想清楚记忆系统的边界条件和设计取舍说实话一开始我也想“上一个完整的记忆系统”做了几天之后发现方向偏了。记忆系统的目标不是“记住所有东西”而是“在需要的时候把恰好相关的信息准确找出来”。想明白这一点很多功能都可以砍掉架构也会简单很多。2.1 跨客户端记忆到底要解决哪三个问题我把需求压缩成三个问题后续所有设计都是围绕它们展开的。第一是写入一致性。客户端 A 写入一条记忆客户端 B 必须能立刻看到。这里的关键不是“最终一致”而是“低延迟一致”。因为 AI 对话是交互式的如果手机端问了问题却拿到的是桌面端 1 小时前的记忆快照用户立刻会感觉到不对。第二是检索准确性。记忆库里可能存了用户几个月以来的对话摘要、项目信息、偏好设置。用户问“上次说好的接口返回格式是什么”系统要能准确找到那一条而不是把所有含“接口”两个字的记忆都倒出来。这要求检索不能只靠语义相似度还要有词法匹配、时间衰减、重要性加权等多重信号。第三是隔离与安全。多个客户端共用一个记忆库不代表所有客户端可以看所有记忆。我明确要求公司项目的记忆只对工作客户端可见个人偏好只对个人助手可见。这个隔离必须在系统层面做好不能靠每个客户端自觉。2.2 记忆分层短期、长期、全局、局部的设计思路我参考了认知科学里工作记忆和长期记忆的区分把记忆分成四个池子。短期记忆池保存的是最近若干轮对话的摘要TTL 很短可能是 2 小时或者一个会话的生命周期。它解决的是“同一会话内的连续性”比如你刚才让 AI 写了一段代码现在问它“这个代码里为什么用了异步”它得记得刚才的上下文。长期记忆池保存的是跨会话的稳定信息比如用户的偏好、项目背景、技术选型、做事习惯。这类记忆的 TTL 很长重要性高是检索时的重点对象。全局记忆池保存的是关于用户身份的基础信息比如“这个用户是一名后端开发者”“他倾向于先写测试再写实现”。全局记忆会被所有客户端共享所有 Agent 在首次交互时都会先读取它。局部记忆池则带 namespace 隔离比如某个具体项目的记忆归到 project:xxx 命名空间下只有处理这个项目的 Agent 才能访问。这四个池子不是物理上分开存储的而是同一份数据带上不同标签在写入时通过标签分类在检索时通过标签过滤。这样存储层保持简洁逻辑层的灵活性也够。2.3 存储选型为什么我选了词法 向量混合而不是纯向量很多人一想到“AI 记忆”就默认得用向量数据库。我一开始也这么想但做了实验之后改变了主意。纯向量检索有个隐蔽的缺陷语义相近不代表因果相关。用户问“明天早上提醒我开会”向量检索很可能召回“他每天早上有跑步习惯”这种语义上挨得着、实际上没用的记忆因为两者的向量距离确实不远。所以我的存储层没有走“单一向量库”路线而是做了混合检索。对每一次写入既生成 embedding 向量存入向量索引也把原文做分词后存入全文索引。查询的时候两路检索并行执行再通过一个融合算法把结果合并排序。这样既保留了语义召回对“同义不同词”的泛化能力也保住了词法匹配对准确关键词的精确命中。生产环境我用了 PostgreSQL 加 pgvector单机开发环境直接用 SQLite 加 FTS5 和内置向量扩展。SQLite 版本在我测试 5000 条记忆时混合检索的耗时大概在 50-80 毫秒完全够用不用一上来就想着上分布式。3. 自研跨客户端 AI 记忆共享系统的整体架构这一章讲清楚系统长什么样、数据怎么流动、各模块之间怎么配合。3.1 核心组件与数据流我的系统分成四个核心组件记忆服务端、客户端 SDK、维护脚本、LLM 提取模块。记忆服务端是中心所有读写请求都经过它。客户端 SDK 是一个轻量 HTTP 封装负责把各端的对话上下文快照发送到服务端并拉取相关记忆。维护脚本负责定时做记忆衰减、归档、一致性校验。LLM 提取模块是从对话中抽取结构化记忆的关键环节但它被设计成独立服务可以随时降级或替换。完整的数据流是这样的用户在某个客户端里说了一句话客户端先把这句话作为查询条件调用记忆服务的检索接口拿到与当前语境最相关的历史记忆拼接到 Prompt 里再发给大模型。模型返回回答后客户端把这一轮对话发送到记忆服务的写入接口。写入接口先做一轮隐私过滤把明显的身份证号、手机号、密钥打码或剔除然后交给 LLM 提取模块抽取出偏好、事实、决策等结构化记忆再生成 embedding最后落库。落库成功后会通过消息队列广播一个“记忆更新”事件其他在线客户端收到事件后自动刷新本地记忆缓存。这个流程的核心原则是“读优先、写异步”。用户发出的查询必须尽快返回所以检索路径一定要短写入可以放到异步队列里慢慢处理不阻塞用户的对话响应。3.2 记忆条目的数据结构设计数据结构是在传统键值对基础上扩展出来的核心字段如下字段类型说明idstring全局唯一记忆 IDnamespacestring隔离域如 project:alpha / personal:generalclientstring写入客户端标识如 web / mobile / idetypestring记忆类型preference / fact / decision / entitycontentstring记忆正文通常是一句完整的话embeddingvector向量化的内容表示importancefloat重要性分数 0-1影响检索排序ttlint过期时间默认 -1 表示永久created_atdatetime创建时间updated_atdatetime更新时间versionint版本号用于冲突合并metajson扩展元信息如来源对话 ID、关联实体列表这个结构里最有用的是 namespace 和 type 两个字段。namespace 解决隔离问题type 解决记忆多样化问题。比如 typedecision 的记忆在排序时权重会高一些因为“用户拍板过的决定”比“随便说过的一句话”更值得被记住。3.3 API 设计与客户端接入方式客户端只需要对接两个核心接口一个是检索一个是写入。检索接口接收 query、namespace、client、top_k 等参数。服务端把 query 做词法检索和向量检索混合排序后返回命中的记忆列表。写入接口接收 session_id、client、messages 数组服务端自行完成提取和落库。还有一个可选的订阅接口客户端通过 WebSocket 订阅某个 namespace 的记忆变更事件用于实时刷新本地缓存。这样的接口设计让客户端接入成本降到很低。我现在的做法是每个客户端集成一个 200 行左右的 SDK封装好这三个接口其他什么都不用管。实测下来接入一个新客户端从开发到联调半天能完事。对比之前用 mem0 时自己搭同步层的 1-2 天效率提升非常明显。4. 核心模块的实操实现与关键参数接下来是重点我会把每个模块的具体实现方式、关键参数、以及我当时怎么调优的细节都写出来。4.1 记忆写入管线从对话到结构化记忆写入管线是整个系统里最复杂的一环也是直接决定记忆质量的一环。它的核心工作是把一段自由对话压缩成几条结构化的记忆条目同时过滤掉噪音和隐私信息。我用的 LLM 提取 Prompt 模板大概是这样的你是记忆提取助手。从下面的对话中提取值得长期记住的信息。 只提取以下四类 1. preference用户的偏好、习惯、禁忌 2. fact客观事实、项目背景、技术选型 3. decision用户做出的决策、拍板过的结论 4. entity重要的人、项目、工具、时间节点 输出 JSON 数组每个元素包含 type, content, importance0到1, expires_in小时-1表示永久。 如果没有可提取的内容输出空数组。这个模板看似简单但它起到的作用非常关键。它强制 LLM 用固定格式输出方便程序解析分类别提取又方便后续按类型做权重排序。我在实际使用中给 importance 做了一个启发式修正如果对话里出现了“我总是”“我从不”“一定不要”这类强偏好词importance 就自动加 0.2如果记忆内容涉及用户明确给出的项目代号或时间节点importance 也会上调。embedding 生成我一开始用的是云端接口后来为了降延迟和成本换成了本地部署的 embedding 模型单条文本的向量化时间约 10-20 毫秒。提取用的 LLM 则用了一个量化到 4bit 的 7B 开源模型跑在 GPU 上单次提取延迟约 400 毫秒。因为是异步处理这个延迟不会暴露给用户客户端。写入有一个重要细节不是每一轮对话都需要提取记忆。我把消息按“是否触发新信息”做了过滤高频的寒暄、重复提问、简单确认语都不会进入提取流程。这个过滤规则让 LLM 的调用量减少了约 70%成本下降非常明显。4.2 记忆检索管线混合检索和重排的权衡检索管线是用户感知最强的部分我把目标定在 150 毫秒内返回结果。第一步是词法检索。用全文索引的 BM25 算法把 query 分词后匹配命中的就带上一路候选集。第二步是向量检索。用 embedding 模型把 query 向量化在向量索引里按余弦相似度取 top 50。第三步是融合排序。我用的是经典 RRFReciprocal Rank Fusion公式score sum(1 / (k rank_i))其中 k 设成 60rank_i 是该条记忆在某一检索路中的排名。融合后取 top 20再做过滤和重排。过滤规则按顺序执行先过滤掉 namespace 不匹配的记忆再过滤超过 TTL 的过期记忆最后过滤掉带隐私标签的记忆。重排规则用线性加权最终分 0.5 x 融合分 0.3 x importance 0.2 x 时间衰减权重。时间衰减权重的公式是 exp(-age_days / 180)即 180 天半衰期。这样设计的结果是近期的重要决定排在前面陈旧且不重要的记忆自然沉底语义相关但实际无用的噪音也有机会被压下去。4.3 跨客户端同步与冲突合并我在这里踩过一个深坑跨客户端同步是整个系统的招牌功能也是踩坑最多的部分。我最初的方案很简单每次写入直接改数据库客户端查询时实时读库。结果发现一个问题——客户端为了降低延迟会在本地做缓存而缓存更新的触发条件如果设计得不好就会出现“桌面端已经更新了记忆手机端还在用旧数据”的同步延迟甚至因为两边同时写同一条记忆出现版本互相覆盖的冲突。后来我把同步机制改成“服务端推送 本地缓存失效”。服务端每次写入成功后通过消息队列向订阅了该 namespace 的在线客户端推送一条变更通知。客户端收到通知后把本地缓存里的对应记忆标记为过期下次查询时强制回源。本地缓存用 LRU 策略热点记忆 TTL 设为 15 分钟普通记忆 2 小时。冲突合并策略则用“版本号 时间戳”双管齐下。每条记忆带 version 字段客户端读取一下版本再写入。服务端比较版本号只接受高于当前版本的写入。如果两个客户端同时基于同一版本修改了同一条记忆则取 updated_at 更新的一条为准。为了唯一性每次写入都配一个全局唯一的 request_id服务端用这个 ID 做幂等避免网络重试导致重复写入。这个方案在内存条款里牺牲了一些精细合并能力但它简单可靠尤其适合记忆这种“取最新有效版本即可”的数据类型。4.4 记忆衰减、过期和冷热分层记忆不是越多越好存得太多反而会拉低检索准确性。我专门加了衰减和归档机制。维护脚本每隔 6 小时跑一次扫描对 TTL 到期且 importance 低于 0.3 的记忆直接标记为“已归档”从主索引里移除但保留在冷存储里可追溯。对 TTL 到期但 importance 较高或 typedecision 的记忆则延长 TTL例如再续 180 天。对超过 90 天没有命中的记忆即便没有过期也会降权处理避免陈旧记忆持续影响检索排序。冷热分层不是一开始就做的。我最初把所有记忆都放在同一个索引里结果数据量到了 8 万条时检索耗时明显上升约 400 毫秒。后来把“最近 30 天活跃记忆”放入热索引其余放到冷索引查询时先查热索引未命中再降级查冷索引。这样一个简单的改动让 95% 的查询都停在热索引阶段耗时回落到了 80 毫秒以内。5. 性能、成本与稳定性的一线实测技术方案不能只停留在理念上我把上线以来的实测数据整理出来这些数字基本可以复现。5.1 性能数据常规量级和多租户情况场景记忆总量单次查询耗时单次写入耗时异步摊分个人日常5000 条60-90ms约 300ms项目知识库2 万条100-120ms约 350ms多 Agent 共享8 万条180-250ms约 400ms这里关键的一条优化是批量写入。原来我一条一条提取、一条一条落库效率低。后来把同一会话中连续的 5-10 轮对话合并成一个大请求批量提取、批量写入写入吞吐提升了大概 3 倍LLM 调用次数也显著下降。5.2 成本对比自研和 mem0 的账单差异成本是我决定自研的最现实原因之一。我按每月 30 万条消息的规模粗略算过一笔账。用 mem0 加云端 LLM 方案假设 30% 的消息触发记忆提取每次提取消耗约 500 token大约要花掉 15 万次 LLM 调用按当前市场价算一个月光提取费用就在 100-200 元。如果查询时开启 LLM 重排这个数字还要再涨 30%。自研方案里LLM 提取用的是本地开源模型embedding 也走本地电费和 GPU 折旧摊下来每个月大概 30 元。两个方案差了一个数量级。这还是不谈数据隐私的代价。云端 LLM 要把对话原文传出去做提取这一条在我们处理项目文档时是不能接受的。5.3 稳定性设计和容灾方案我最担心的是本地 LLM 提取服务挂了之后整个系统会不会跟着挂。后来做了降级设计提取服务不可用时写入接口自动降级为“不提取结构化记忆只保留原始对话摘要”检索时靠词法匹配和向量检索兜底系统仍然可用。也就是说AI 提取是增强项不是必需项。消息队列也做了持久化。即使服务端在写入后、广播同步通知前崩溃客户端下次主动查询时也能从数据库拿到最新数据只是同步延迟从毫秒级变成秒级。我的容灾目标不是“零丢失”而是“关键记忆不丢、服务不整体不可用”。6. 我从这套系统上线前后踩过的坑这篇内容如果只说设计不说坑价值少一半。下面这几个问题都是我真实遇到过、花时间排查过的按典型程度排列。6.1 语义搜索并不万能召回偏差的典型案例有一次用户我自己在手机端问“明天开会材料准备了吗”系统召回的三条记忆里有一条是“用户每天早上有晨跑的习惯”理由是“明天早上”和“晨跑”语义相近。这属于召回偏差。单纯靠向量距离无法区分“明天早上开会”和“平时早上跑步”的关系。后来我加了两个修正一是对包含明确时间词的查询加时间过滤二是把词法检索结果在融合中的权重调高确保精确匹配不会输给语义泛化。6.2 同步风暴多个客户端同时写同一条记忆多客户端同时在线的场景里最恐怖的问题就是同步风暴。桌面端和手机端同时编辑同一条项目记忆两个客户端各自基于旧版本生成新版本造成持续互相覆盖日志里反复出现 version conflict。我最后靠“读取时带上版本号、写入时校验版本号”解决另外在客户端 SDK 里加了 200 毫秒的写入去抖同一客户端在 200 毫秒内对同一条记忆的多次修改只提交最后一次。这个去抖大大减少了冲突发生频率。6.3 隐私与安全在跨客户端场景下的具体要求跨客户端意味着数据会从多个入口进来权限边界必须清晰。我的处理是每个客户端启动时向服务端申请一个 client_tokentoken 绑定 namespace 列表。Web 端可以读写 project:xxx 和 personal:general手机端默认只能读写 personal:generalIDE 插件额外可读写 project:codebase。服务端在每条读写请求里校验 token 与 namespace 的对应关系不匹配直接拒绝。这种做法的好处是即使某个客户端的数据泄露了被波及的记忆也限定在它被授权的范围内不会把整个记忆库拖下水。6.4 一点关于 token 开销的教训刚上线时我把每一轮对话都交给 LLM 提取记忆成本飙升到让人心疼。后来加了一个“信息增量”判断如果当前消息和上一轮提取过的记忆语义重复度过高就跳过提取只更新原记忆的时间戳和权重。这个判断用向量相似度实现超过 0.9 就跳过。效果是提取次数下降了约 70%几乎感觉不到对比度差异。所以对于记忆系统真正省钱的不是选更便宜的模型而是减少无效提取。7. 这套系统的工程化扩展方向写完自研系统之后我并没有停下来。有几个方向是我已经在做或准备做的对同场景的人可能有参考价值。第一个是支持多 Agent 协作。现在多个客户端共享记忆本质上还是一个用户和一个 AI 服务之间的记忆。下一步我想把这个系统扩展成多个 Agent 之间的共享黑板让不同的 Agent 能够读取彼此的中间状态、任务进度、决策记录真正实现多体协作。第二个是更精细的记忆权限。现在的 namespace 隔离是粗粒度的。未来想做成类似“记忆级 ACL”每条记忆单独标注可见的 Agent 列表或用户组列表。第三个是记忆闭环反馈。系统目前只做存取没有做“记忆是否真的帮助了后续回答”的效果回传。我准备在检索接口里加入一个 feedback 字段客户端在回答结束之后回传哪些记忆被用到系统据此调整记忆的重要性权重让高价值记忆越用越靠前。还有一个现实问题需要提一下如果你也想自研记忆系统不必从零开始造所有轮子。我在实现中发现大部分存储和检索能力用现成的 SQLite、PostgreSQL 加开源 embedding 模型就能搞定真正需要自己写的只有三个点读取和写入的结构化提取、跨客户端的同步冲突逻辑、以及贴合自己业务场景的重排规则。把这三块想清楚系统就成功了一大半。我在这套系统的开发过程中最大的体会是不要被“AI 记忆”这个概念吓住本质上它就是一个带有语义检索能力的数据库难点不在存储而在“知道什么该被记住、什么该被忘掉”。mem0 在很多场景下确实值得一试尤其是单客户端、数据量不大、对延迟不敏感的项目但如果你像我一样需要多客户端共享、数据可控、成本敏感自己写一套轻量级的记忆服务反而是一条更踏实、更可控的路。
