定义¶

开源的 AI Agent 跨会话记忆服务（GitHub: mem0ai/mem0），自我定位为"通用记忆层"——任何 LLM Agent 框架都可以接入，提供 ADD / UPDATE / DELETE / NO-OP 四类记忆操作。是 2024-2026 年 LLM Agent 生态最广泛被采用的第三方记忆方案之一，集成 LangChain / CrewAI / LangGraph 等主流框架。

本词条记录 mem0 的技术形态和它与 Sentino 自研 sentino-memex 的对比——背景：mem0 在 2024-2026 年成为"AI Agent 记忆"的行业代名词，客户 PRD（如 yukai-agora-poc AC-08）常用 mem0 一词描述记忆能力需求。Sentino 销售姿态是用 Memex 替代实现并教育客户区分两者，本词条 + sentino-memex-positioning 销售材料 + Memex 概念页一起构成完整的"我方 vs 第三方"对比体系。

核心机制（基于 mem0 官方公开材料）¶

A.U.D.N. 循环¶

对每条"记忆候选"，运行 Add / Update / Delete / No-op 四类决策。决策由 LLM 输出，写入向量库 + 可选图数据库（Neo4j）。

ADD-only 架构（2026-04 官方承认）¶

mem0 在 2026-04 公开博客《Token-Efficient Memory Algorithm》中明确承认其架构是 ADD-only： - 在 LOCOMO benchmark 表现：preference following / instruction following / knowledge updates 类任务表现良好 - 弱项：temporal reasoning / event ordering / multi-session reasoning——这些任务需要事实之间的时序/超越关系建模，ADD-only 架构原生不支持

UPDATE/DELETE 需配置才生效¶

默认 ADD 路径就能跑，UPDATE 和 DELETE 需要传入 custom_update_memory_prompt 显式指令 LLM 在新事实与旧事实冲突时应做出 ADD/UPDATE/DELETE/NONE 哪个动作。未配置 = 实际是 insert-only，旧事实会一直堆叠。

抗膨胀机制¶

• 自动 filter / decay / 优先级评分（官方文档承诺）
• 1.0.3（2026-01）增加项目级 inclusion / exclusion prompt + memory depth + usecase 配置
• 实战：把 excludes 设为 "small_talk" 是社区报告"最有影响"的单项调整

mem0 自承的 4 大未解问题¶

mem0 官方《State of AI Agent Memory 2026》报告自承：

1. Staleness detection（过期检测）
2. Privacy governance（隐私治理）
3. Consent frameworks（同意框架）
4. Cross-session identity resolution（跨会话身份解析）

这是 mem0 团队自己列出的 4 项尚未解决的领域问题。摄取本页时认为：用 mem0 的客户应当知道 staleness 不是 mem0 没做好，是这个领域目前没解。

2026-04 更新：Google Memory Bank 把这 4 个问题给了部分内置答案¶

2026-04-28 摄取 google-memory-bank 调研后明确：mem0 自承的 4 大未解问题里，Google Memory Bank（Vertex AI 托管路线）至少在 staleness 和 governance 上给了直接内置答案：

对 mem0 作为"行业代名词"的稳定性影响：mem0 在 2024-2026 是 AI Agent 记忆领域的事实参照系（PRD 写 mem0 = 描述能力本身）。Google Memory Bank GA 后，企业客户在选型层会越来越多看到"mem0 没做好 Memory Bank 做了"的对比。短期内（半年到一年）mem0 的代名词地位还在——开源生态 + GitHub stars + 社区文档密度仍领先；长期（2027+）若 Memory Bank 在企业客户案例上跑通，mem0 可能从"代名词"退化为"开源 PoC 选项"。Sentino 销售姿态相应调整：客户 PRD 里看到 mem0 短期仍按"行业代名词"处理，但要预警一年内可能出现"PRD 写 Memory Bank"的客户场景（届时是真技术选型而非代名词，需要不同应对）。

与 Sentino Memex 的对比¶

Sentino 的判断（详见 sentino-memex "对外定位锚点"）： 向量检索方案的 4 个固有问题（拉错 / 不可审计 / 不可编辑 / 不可预期）在 2025-2026 充分暴露，行业判断转向"让模型读全集自判"。Anthropic 在 Claude Code 上做出同样选择是最有说服力的技术背书。

何时用 mem0 是合理选择¶

不是所有场景都该用 Memex 模式。mem0 在以下场景仍是合理选择：

• 通用 Agent 记忆基础设施（开源 / 多 backend / 生态成熟）
• PoC / 演示阶段，无大量真实用户、无长会话累积——staleness 问题不会暴露
• 不希望自建记忆服务的团队（Sentino 选自建是因为记忆是核心资产）

mem0 作为行业代名词的销售含义¶

mem0 在客户文档（PRD/RFP）中出现时，通常不是客户技术选型，而是用来描述"AI Agent 记忆"这个能力本身——mem0 在 2024-2026 是该能力的事实参照系（类比 "Twilio" 之于电话能力、"Stripe" 之于支付能力）。

对 Sentino 销售姿态的含义： - 看到客户 PRD 写 mem0 不要默认"客户已选型"——大概率是借代名词描述能力需求 - 主动承担术语切换工作：用 Memex 实际交付，并提供 mem0 vs Memex 对比材料让客户接受替代 - 配套销售材料 sentino-memex-positioning.md（中英文版）就是这条路径的具体执行 - yukai-agora-poc AC-08 是这一姿态的首次实战：PRD 写"记忆 (mem0)"，Sentino 用 Memex 实现

待观察¶

• mem0 1.0.3 之后的 lifecycle 配置实际效果——能否达到 Memex 4 级 TTL 的"自动遗忘"水平？
• mem0 的图数据库扩展（Neptune Analytics / Neo4j）能否解决 multi-session reasoning？
• 行业对 ADD-only 架构的批评是否会推动 mem0 在 2026 内推出原生 UPDATE/DELETE 路径？

相关概念¶

• sentino-memex — Sentino 自研对照方案，与 mem0 是不同代际的判断
• auto-memory — Claude Code 的本地文件记忆，与 Memex 同路线，与 mem0 反方向
• google-memory-bank — Google 托管路线，把 mem0 自承的 4 大未解问题给了部分内置答案，是 mem0 行业代名词地位被挤压的核心动力
• rag — mem0 本质是 RAG 框架在记忆领域的特化
• yukai-agora-poc — PRD 把 mem0 当能力代名词的首次实战，Sentino 用 Memex 替代实际交付
• sentino-agent — Sentino 默认走 Memex 路线，但平台本身保留对接 mem0 的能力