主题
第 20 章 第一梯队系统深度对照
2026 年 9 月，一支做客服 Agent 的团队拿到三份 PoC 结论：一份说图记忆在多跳问题上更好，一份说托管省掉两个人月的 运维，一份说零依赖的本地库能塞进客户的离线环境。三份都不算错，但拼不出一个决定——它们量的不是同一件事。
僵局不是信息不足，而是对照维度不统一。每家的文档都在回答「我擅长什么」，没有一份回答「在同一张尺子上你排第几」。
本章把尺子立起来。20.1 与 20.2 给定位与十维快照，只陈述事实。真正的分歧在 20.3与 20.4：写入范式与检索粒度决定了后面 所有选型判断的方向。20.5 与 20.6 处理最容易被营销话术覆盖的两个维度。20.7 说明矩阵该怎么读。
术语约定：模型上下文协议统一写作 MCP（Model Context Protocol，MCP）。凡称「公开文档」，指截至 2026 年 10 月可访问 的官方文档与仓库 README；无法核实的标注为未见说明，不据此推断能力缺失。
20.1 六种隐喻，六种边界
六个系统各自用一句话介绍自己，但那句话是营销语言。更有信息量的是底层隐喻：它决定了系统把什么问题当作核心问题，也决定了它 何时失效。
| 系统 | 核心隐喻 | 一句话定位 | 最适合 |
|---|---|---|---|
| Mnemosyne OS | 自带账本的文件柜 | 零依赖本地优先记忆服务器 | 离线与主权敏感团队 |
| Mem0 | 可替换的记忆中间件 | 三形态记忆层 | 快速上线对话个性化 |
| Zep + Graphiti | 受治理的时序图 | 统一上下文层与建图框架 | 跨系统上下文治理 |
| Letta | 会整理书桌的 Agent | 有状态 Agent 运行时 | Agent 自主管理记忆 |
| LangMem | 无副作用的状态变换 | LangChain 生态记忆 SDK | 已深度使用 LangGraph |
| CF Agents | 运行时就近的便签墙 | Durable Agent 运行时 | 已在 Workers 生态 |
表 20-1 六个系统的核心隐喻与适用边界（截至 2026 年 10 月）
隐喻同时预告了失效点。文件柜意味着检索是柜内查找，失效点在召回精度而非容量。中间件意味着可替换性优先，失效点是替换成本被 低估：数据模型一旦被上层直接依赖就不再可替换。时序图意味着正确性优先于延迟，失效点是建图成本随本体复杂度而非数据量增长。会整理书桌的 Agent 意味着记忆是行为 副产品，失效点是记忆质量与 Agent 行为耦合、难以单独归因。状态变换函数意味着持久化被推给调用方，InMemoryStore 一重启就丢。 便签墙意味着记忆贴着执行环境，失效点是平台绑定。
20.2 十维能力矩阵（2026 年 10 月快照）
这张表回答：把六个系统放进同一组工程维度，各自的支持程度落在哪里。✅ 原生支持；⚠️ 需额外配置或存在已知限制；❌ 不支持或需自行构建。
| 维度 | Mnemosyne | Mem0 | Zep+Graphiti | Letta | LangMem | CF Agents |
|---|---|---|---|---|---|---|
| 单遍只增写入 | ✅ | ✅ | ⚠️ | ⚠️ | ❌ | ⚠️ |
| 零依赖启动 | ✅ | ❌ | ❌ | ⚠️ | ❌ | ⚠️ |
| 自托管完整功能 | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ❌ |
| 时间感知检索 | ✅ | ⚠️ | ✅ | ⚠️ | ⚠️ | ⚠️ |
| 多信号融合 | ✅ | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ |
| 可审计完整性 | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| 级联删除 | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| 中文检索优化 | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| MCP 工具面 | ✅ | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ |
| 基准可复现脚本 | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
表 20-2 六个系统的十维能力矩阵（截至2026 年 10 月）
⚠️ 分两类，混为一谈会得出错误结论。
第一类，能力存在但需额外配置或有已知限制。 Mem0 的图记忆为 Platform 专属，开源版官方标注该能力已移除，开源侧不存在 可查询的图；Zep 的开源自托管路线由Graphiti 承担，需自行运维图数据库；LangMem 的持久化依赖 LangGraph store； Cloudflare Agents 的长期记忆要在 Workers绑定之上自行组织。
第二类，截至 2026 年 10 月的公开文档中未见说明。 具体为：Letta 的时间感知检索、多信号融合、级联删除、中文检索优化，以及 作为记忆服务而非工具接入的 MCP 面；LangMem 的审计完整性与基准脚本；Cloudflare Agents 的多信号融合、审计完整 性、级联删除与中文检索优化；Zep 与 Mem0的中文分词策略。
第二类不等于能力缺失，只表示无法核实。这一点必须写清，否则整张表会被读成排名——它不是排名，是文档详略与产品边界的一张混合快照。
20.3 写入范式的收敛
这是本章最重要的一节。2026 年发生了一次方向性变化，它直接作废了一大批仍在流传的选型理由。
20.3.1 两阶段写入当年解决了什么
旧范式是两阶段：新事实到来时先检索相似旧记忆，再让模型在 ADD、UPDATE、DELETE、NOOP 之间裁决。它解决的是真问题——当前 状态唯一，库里不会有两条矛盾的偏好。
代价有三项。一次写入要付一次检索加一次裁决调用，成本随写入量线性上升。判错即毁证据：一次错误的 UPDATE 覆盖掉真实事实后 没有回溯路径。并发写入会互相覆盖，需额外的锁或版本号。
20.3.2 2026 年的转向
Mem0 在 2026 年把算法改成四件套：单遍ADD-only 提取（一次 LLM 调用，只增，不覆盖不删除，官方称提取速度约 2 倍，历史 完整保留）、多信号检索（语义、关键词、实体三路并行打分融合）、时序推理（写入时分类）、记忆衰减（近期访问获得软性 排序加权，闲置项随时间衰减，零检索延迟成本，不删除不隐藏）。
Mnemosyne OS 从第一版起就是单遍ADD-only：一次写入一次模型调用，只增不改不删；缺省无模型时用内置 rules 确定性提取 器，因此没有 API key 也能写入。
两者现在在同一范式上。这不是巧合，而是约束收敛的结果：记忆量足够大、写入足够频繁时，两阶段的裁决成本会超过它带来的状态唯一性收益，而覆盖式更新丢失证据的 代价在合规场景里不可接受。
20.3.3 收敛之后的选型含义
「只增不改」不再是差异化卖点，而是行业共识。 正着读：一个设计选择被主流采纳，说明当初的方向判断对。反着读：单靠它无法 构成任何选型理由。2026 年之后用「我们支持ADD-only」去说服评审，会被问一句「然后呢」。
收敛把竞争推到了补偿机制上。 只增不改的代价是明确的：旧事实不被覆盖，矛盾只能靠检索时的排序消解，库本身不会自己变干净。 Mem0 在 Platform 侧用 Dream 做巩固与去重来补这一步，开源侧没有这个能力；Mnemosyne 用 conflict_resolve（六类冲突 判定加四种操作，scope=audit 可全库扫描）、consolidate 与 memory_consolidate 的 三条巩固路径来补。两边都得补，补法不同，而补法差异比范式差异更能说明成熟度。
收敛之后真正剩下的差异在三处。
其一，抽取器在无模型时能否工作。 Mem0的提取是一次 LLM 调用，没有模型就没有记忆形成；Mnemosyne 的 rules 提取器在离线、 无 key、无模型下载时仍可写入，代价是抽取质量受限于规则覆盖面，细粒度不如模型抽取。
其二，当前状态如何表达。 Mem0 用衰减加权加时序重排，让更近的排前面；不删除不隐藏，因此库里同时存在新旧事实，靠排序而 非覆盖表达「现在」。Mnemosyne 用置信度轨迹、分层与版本链，temporal_query 按实体返回版本链。两条路都不覆盖，区别在于 「现在是什么」是排序结果还是可查询结构——前者便宜，后者可解释。
**其三，补偿机制是运维成本而非免费收益。**冲突扫描、去重与巩固都要排进日程才会被执行；不排，库就只是越写越大的日志。
20.4 检索粒度控制的两条路线
控制注入成本是共同难题：召回太少，模型缺上下文；召回太多，token 预算被吃掉且噪声稀释注意力。Zep 与 Mnemosyne 给出 两种结构不同的答案。
20.4.1 路线一：把粒度变成参数
Zep 的 Context MCP Server 暴露 12 个工具，分两组。用户自有图一组 6 个：search_graph、get_user_summary、 get_subgraph、get_node_neighbors、list_episodes、add_memory。共享 Context Graph 一组 6 个：list_graphs、search_graph_in、get_subgraph_in、 get_node_neighbors_in、list_episodes_in、add_memory_to_graph，另提供 zep://graphs/directory 资源。
其中 search_graph 的 scope 可取 auto（默认，优化过的上下文块）、observations （偏好一类的持久模式）、thread_summaries（逐会话摘要）、episodes（原始摄入的消息与文本）、nodes（实体及其 UUID 与 摘要）、edges（实体间的事实）。
这是把「要事实还是要摘要还是要原始片段」变成调用方的显式参数，决策在一次调用内完成，粒度与查询一起指定，不需要往返。get_subgraph 与 get_node_neighbors 则 走连接而非相关性：先用 scope=nodes 拿到实体 UUID，再以它为种子做多跳遍历。
代价是调用方必须懂语义层级。选错 scope不报错，只给错粒度——选 episodes 会拿到原始消息，注入成本立刻失控；选 thread_summaries 会拿到摘要，细节问题答不了。这个知识必须由编排层持有。
20.4.2 路线二：把展开变成第二步
Mnemosyne 走渐进式披露：recall_catalog只返回标题、一行摘要与展开成本，不返回正文；expand_memory 展开 1–2 条，返回 正文、统一信封、图邻居与证据链。注入成本从「全部」降到「目录加少量」。
python
# 第一步：只拿目录，判断哪几条相关
cat = recall_catalog("发票抬头与税率约定", k=10)
# 第二步：只展开 1–2 条，拿正文与邻居
full = expand_memory(cat["results"][0]["memory_id"])这段代码验证的是成本结构：目录调用返回元数据，正文只在第二步产生。第二步返回的图邻居来自知识图谱，因此「这个决定影响了哪些模块」能在展开时一并回答。
代价是两次往返。两次调用之间存在「已看过目录、尚未展开」的中间状态，由调用方维护；若调用方在中间丢失上下文，第二步无从发起。
20.4.3 两条路线怎么选
判据不在系统，在编排形态。编排层是确定性代码（工作流、状态机、固定工具链）时，参数化更合适：一次调用、粒度确定、可测试。 编排层是模型自主循环时，渐进式披露更合适：模型看到目录之后才做决定，而这正是它擅长的事。
反面意见也要写清：如果一次召回就用掉整个预算，渐进式披露的第二次往返是纯损失，目录已经花掉钱而正文还没进来。
20.5 审计与治理：哈希链的独占与代价
20.5.1 能力差异
只有 Mnemosyne 把 SHA-256 哈希链做成产品能力：verify_integrity() 返回{valid, total, first_broken_at}，能指出 具体哪一条被改。账本覆盖写入、更新（mask/unmask）、删除（soft/hard）、导出、导入、claim 七类动作。
其余系统提供的是操作日志或可观测性工具，不是完整性证明。Mem0 的审计日志属 Custom层；Graphiti 提供的是到 episode 的来源追溯 ——每条派生事实都能追回产生它的原始数据，这是溯源，不是防篡改。区别在举证方向：溯源回答「这条从哪来」，哈希链回答「这条 有没有被动过」。
20.5.2 代价：串行化与校验开销
哈希链必须按序追加：每条的哈希依赖前一条的哈希，写入路径无法并行。单机低并发不是问题，多写者高吞吐就是瓶颈。
第二项代价是校验成本随链长线性增长。全量校验在长历史库上会变成一次运维事件而不是一次健康检查，实际部署通常改为定期全量加 日常抽段。第三项是运维负担：链一旦断裂，修复本身就是需要留痕的操作，而留痕又写进新的链——这个循环必须事先设计好。
判据很简单：需要「证明没被改」的场景（合规举证、删除证明、对外审计）值得付这个代价；只需「知道发生了什么」的场景，操作日志更便宜也更灵活。
20.6 部署形态：一条光谱而不是两档
部署形态常被简化成「开源还是云」，实际是一条光谱，每一档的边界都不同。
| 系统 | 托管形态 | 自托管形态 | 关键门槛 |
|---|---|---|---|
| Mnemosyne OS | SaaS 四档（含合规加购） | MIT，不限量 | 无功能付费墙 |
| Mem0 | Free 与 Custom | 开源库或 Docker 栈 | 图记忆属 Platform |
| Zep | 托管云与 BYOC | Graphiti（Apache-2.0） | 自定义 OIDC 需 Enterprise |
| Letta | Letta Cloud | letta server | npm 安装，模型自备 |
| LangMem | 无 | 纯 SDK | 持久化需自备 store |
| CF Agents | Workers 平台 | 无 | 绑定 Durable Objects |
表 20-3 六个系统的部署形态与门槛（截至2026 年 10 月）
Mem0 的两档差别值得单说：Free 提供无限终端用户，前 30 天每月 10,000 次 add 与1,000 次检索且模型调用由 Mem0 承担，自带 LLM key 则提高到 50,000 次 add 与 10,000次检索；Custom 按量报价，含图记忆、用户画像、Dream 巩固、高级分析、SSO/审计 日志/SLA 与本地部署。记忆衰减的 0.3 倍至1.5 倍缩放只在 Platform 侧提供，且为opt-in、默认关闭，作用方式是软排序偏置而 不是过滤器。
Zep 提供托管云与 BYOC 两种部署，自定义OIDC 需 Enterprise；Context MCP Server 按 MCP 席位计费，席位随计划不同，鉴权走客户自己的身份提供方，主体是终端用户而非 Zep账号成员。开源自托管路线由 Graphiti 承担， 代价是图数据库、检索与周边服务都要自己运维。Letta 走 npm 安装加 Letta Cloud，主仓库已迁至 letta-ai/letta-code。 Cloudflare Agents 是运行时形态：Session API（实验性）提供树状会话历史与四类上下文记忆块，检索由开发者自己提供 search()， 内置默认用 FTS5。
20.7 矩阵的正确读法
第一，没有任何系统在所有维度领先。表 20-2每一行都能找到至少一个 ⚠️，这不是制表不认真，而是定位的必然结果——把零依赖做到 极致的系统必然在生态集成上让步，把图治理做到极致的系统必然在启动成本上让步。
第二，⚠️ 的密度与文档详略强相关。开源项目的 README 会写清每个能力，商业产品的文档会写清卖点对应的层级。⚠️ 的数量差异有一 部分来自披露习惯，不来自工程能力。
第三，2026 年的竞争焦点已不在「能不能记住」。六个系统都能记住，LongMemEval 与LoCoMo 上的差距在个位数分。焦点转移到三 个问题：记住的东西是否可被信任（来源、时间、置信度）、是否可被解释（为什么召回这条而不是那条）、是否可被安全地遗忘（删除是否彻底、是否可证明）。这三问在 表 20-2 里分别对应可审计完整性、检索粒度与级联删除三行。
第四，本章最该被记住的一句：能力矩阵用来排除，不用来选择。它能把不满足硬约束的候选砍掉，但选谁取决于第 21 章那五个问题。
20.8 本章小结
本章确立三条判断。
第一，「只增不改」在 2026 年已成为行业共识，因此不再是选型理由。 它成立的条件是写入量足够大、合规要求足够严；在这个 条件下两阶段的裁决成本超过收益。它失效的条件是单机小规模、强一致状态需求——那时覆盖式更新反而更省，因为它不需要在读取时 推断「现在是什么」。共识带来的新竞争点是补偿机制：谁把去重、冲突消解与巩固做成了可执行工序，谁才真的可用。
第二，检索粒度控制有两条结构不同的路线，选择取决于编排形态而非系统强弱。 Zep 的参数化路线适合确定性编排，代价是调用方 必须懂语义层级；Mnemosyne 的渐进式披露适合模型自主循环，代价是多一次往返与调用方维护中间状态。两者解决同一个问题，没有 一条在成本上普遍占优。
**第三，审计能力的差距是本章唯一一处独占，而独占的代价是写入串行化与校验开销。**哈希链能证明未被篡改，但证明不了「已不 存在」——这个空缺留到第 23 章展开。
还有一个未解决的问题悬在这里：表 20-2 的十行里没有一行衡量「用户主动管理记忆时系统的行为」。用户说「把那条删掉」或「这个 记错了」时，系统是配合、是解释、还是沉默地记下新的？六个系统都没把这件事当作可评测能力。这个空缺会在第 22 章以失效点的 形式反复出现，并在第 23 章成为第一个未解问题。