mem0 曾经最容易被记住的设计，是让模型在 ADD、UPDATE、DELETE、NOOP 之间判断怎样处理新事实。这个模型很直观，也很像人在维护一张“用户真相表”。但当前 2026 版主路径已经换了方向：一次 LLM 调用，只抽取需要新增的事实。
这不是功能倒退，而是承认模型不适合在写入瞬间重写历史。
ADD-only 写入怎样工作
Memory.add 的新批处理路径先拿到本轮消息，再检索一小组既有事实作为上下文。为了减少模型在长 UUID 上编造引用，代码把已有记忆临时映射成小整数 ID。随后只进行一次抽取：模型可以参考旧事实，但输出的是 additive facts，而不是更新或删除指令。
后续步骤尽量交给确定性代码：
- 为新事实批量生成 embedding；
- 以内容 hash 去重；
- 批量写入 memory 与 ADD history；
- 再做实体链接。
旧信息没有被当场擦掉，因此一次错误判断不会静默改写用户档案。代价是矛盾会同时存在，检索层必须更聪明地决定当前问题该看哪条。
复杂度从写入移到了读取
新版 search 不只看向量相似度。查询先做词形归一和实体识别，然后并行获得三类信号：semantic 相似度、BM25 关键词分数、entity boost。
代码先用 semantic threshold 挡掉完全不相关的候选，再把 BM25 经过归一化，与实体加分一起纳入总分。这个顺序很关键：关键词命中不能把语义上无关的同名文本硬抬到榜首，实体信息也只是助推，不是裁决。
所以 mem0 现在更像“事件记录 + 证据排序”，而不是一张持续被覆盖的 profile 表。时间推理与更高级的 managed 优化在托管平台上还有额外实现，不能把平台 benchmark 的全部收益都算到 OSS 这段算法头上。
ADD-only 也不是免费午餐
追加能保留历史，却会制造增长、冲突和过期问题。“用户住在北京”和“用户搬到上海”都是真的，只是有效时间不同。若没有时间范围、来源可信度和遗忘策略，检索器只能用相关性近似判断“现在”。
因此我认为写入算法收敛以后，mem0 下一类难题会是 memory lifecycle：什么时候过期、谁能确认、删除如何传播到向量和图后端、合规请求能否真正清除衍生数据。
我的思考
mem0 会与客服、个性化产品、销售辅助和跨会话助手的开发者最有共鸣，因为它把记忆做成可嵌入的基础设施，而不是完整 agent 产品。
对社会和市场来说，append-only 是一种难得的机器谦逊：系统先记录证据，不急着宣布哪一个版本的你才是真的。这对合规审计很友好，也可能催生记忆观察平台——企业会像监控数据库变更一样监控 profile 是怎样形成的。
但我还想补一层：保留一切并不天然尊重用户。人有改变主意、过期和被遗忘的权利。最好的记忆系统既不能随便重写过去，也不能用“append-only”拒绝真正的删除。技术上最难的平衡，恰好也是社会最在意的平衡：历史应当可追溯，身份不该被历史永久锁死。