写作现场：2026 年 7 月 10 日。 mem0 新算法将自动抽取阶段限制为 ADD。旧流程允许模型在 ADD、UPDATE、DELETE 与 NOOP 之间生成数据库 diff；新流程只追加候选事实，显式更新和删除继续由应用调用 update() 与 delete()。这不是消除冲突，而是把高风险决策从写入路径移动到检索和治理路径。

ADD-only 写入链与冲突迁移

主路径可以概括为：

消息与身份范围
→ 近期对话与相关旧记忆
→ LLM 抽取长期事实
→ embedding 与精确文本去重
→ 主向量库
→ SQLite history
→ 实体索引

user_id、agent_id、run_id 至少提供一个，并同时参与写入作用域和检索过滤。这里的隔离错误比召回质量错误更严重：过滤条件绑定不正确，会把另一主体的长期记忆注入当前回答。

抽取 prompt 同时读取当前消息、近期上下文和相关旧记忆。旧记忆被替换为短 ID，模型可以通过 linked_memory_ids 声明关联；新文本随后生成向量，并用内容 hash 删除完全相同的候选。hash 只处理字节级重复，无法判断“喜欢黑咖啡”和“咖啡不加糖”是否表达同一偏好，也无法建立时效关系。

用户从北京搬到上海时，ADD-only 允许两条记录并存。下一次读取必须依据发生时间、有效时间、当前上下文或用户确认决定哪条可用。向量相似度与关键词信号只能回答“哪些记录相关”，不能回答“哪条仍然有效”。实体索引也只是实体到 memory ID 的关联，不是自动推理时间与因果的知识图谱。

因此，算法减少了模型在写入时执行不可逆修改的机会，却提高了读取端要求。可用的长期记忆至少需要 valid_from、valid_to、supersedes 关系、来源消息和禁用状态，而不能只依赖相似度分数。

多存储一致性与删除语义

一次新增会触及主向量库、SQLite history 和实体集合。这些存储没有共享跨后端事务，可能出现主记录成功而 history 失败，或主写入失败但派生索引已经留下内容。接入方需要幂等 operation ID、读后确认、outbox 或定期 reconciliation，而不能把一次 API 成功直接解释为所有投影一致。

删除同样需要分层验证：

  • 默认检索是否不再返回；
  • 主向量记录是否物理或逻辑删除；
  • history 与实体引用是否同步更新；
  • 备份、分析系统和缓存是否完成传播。

对住址、健康、关系或工作评价等个人数据，“搜索不到”与“已经删除”不是同一保证。ADD-only 保留旧事实有利于审计，也会增加数据最小化、过期和用户纠错的责任。

项目方报告了 LoCoMo、LongMemEval 等基准成绩和 token 降幅，这些结果说明该方向值得复测，但不能替代具体语言、领域和冲突样本上的独立评估。更有价值的测试集应覆盖否定、反悔、同名实体、临时偏好和“过去成立、现在失效”。

mem0 的设计适合需要跨会话个性化的 SaaS 和 Agent 产品。它将长期记忆包装成可接入 API，同时也使 memory observability 成为独立需求：开发者要解释记忆从哪句话产生、为何被召回、何时失效，用户则需要查看、修正和禁止派生状态继续影响决策。

版本与源码

信息边界：本文写于 2026 年 7 月 10 日的发布现场，只使用当日可见资料；数字均按项目方公开口径表述，未当作独立复现实验。