Agent 记忆选型应先匹配数据与查询需求

Agent 跨会话记忆该怎么选，不能只看谁的榜单分数高。原文比较了 Mem0、Zep、Letta 三条路线，结论是：记忆层首先解决历史信息的保存和调用成本，准确率是否提高，要看任务。

对做 AI 应用的前端和全栈开发者，这篇最有用的地方，是把选型问题拆成了调用轮数、事实关系、细节需求和删除机制。文中的数字也提醒我们：把历史压缩成记忆，有时省了 token，也丢了答案。

三种记忆架构，接入后承担的责任不同

Mem0 是一个可以单独调用的层：add() 从对话中提取事实，search() 在下一轮检索相关内容。它适合偏好、用户画像这类信息，接入负担较小。但按原文的描述，这种事实组织方式偏平，信息之间的关系复杂后，就容易碰到限制。

下面这段代码展示了它最直接的用途：记住用户偏好的编程语言，随后按主题检索。

from mem0 import MemoryClient

client = MemoryClient(api_key="...")

client.add("I prefer Python over JavaScript", user_id="martin")
hits = client.search("programming language preferences", user_id="martin")

要留意两次调用里的 user_id="martin"：写入和检索都带着用户标识。这段示例只演示基本调用，没有交代身份校验、事实更新和删除流程。

Zep 押注的是时态知识图谱（temporal knowledge graph）。底层 Graphiti 给关系记录有效时间，区分某条事实何时成立、何时被新事实替代。例如，客户今天用什么套餐，上季度又是什么套餐，可以分别查询，不必让模型从冲突描述里猜。

这里还有部署成本。原文指出，自托管需要 Graphiti 加图数据库，旧的 Zep Community Edition 已于 2025 年 4 月停止维护，不能沿用过去的部署印象做判断。

Letta 源自 MemGPT，把记忆管理放进 Agent 运行时。Agent 自己决定哪些信息进入长期存储，并使用 core、recall、archive 三类存储。采用它，相当于接受一套运行环境，改动范围比增加一个 API 大得多。

选型首先是在选信息怎么组织，以及应用愿意接管多少记忆管理工作。

分数很高，为什么仍然证明不了长期记忆好用

原文列出的测试各有侧重。LoCoMo 用跨会话的 1,540 个问题，覆盖 Single-Hop、Multi-Hop、Temporal、Open-Domain；LongMemEval 用 500 个问题考查知识更新和跨会话检索。BEAM 把历史规模推到 100 万和 1,000 万 token，更能拉开与单纯扩大上下文窗口的距离。DolphinBench、STATE-Bench 则进一步看任务是否完成。

据原文转述，Mem0 在 2026 年 4 月公布的算法，在 LoCoMo、LongMemEval 上分别得到 92.5、94.4 分，平均每次查询约用 6,900 token。但到了 BEAM，100 万 token 下是 64.1 分，1,000 万 token 下降到 48.6 分。小规模测得好，不代表历史不断累积后仍然可靠。

更麻烦的是，评测接法本身就有争议。

Zep 对 Mem0 的 2025 年评测提出多项批评：LoCoMo 对话只有几万 token，缺少知识更新类别，数据存在说话人和标准答案错误；Zep 的接入还出现角色交换、时间戳处理不当，以及把并行搜索做成串行等问题。按 Zep 自己的修正结果，它得到 75.14%，Mem0 最好的图配置为 68.44%。

这些是竞品提出的结果，不能直接当成中立裁决，也不能拿来与 2026 年的分数横向排名。

另一处反例来自 Mem0 自己的 2025 年表格：完整上下文基线约为 73%，高于当时报告的记忆方案。至少在那组测试里，把历史全部交给模型，比提炼后检索更准确。作者因此质疑，这类短历史测试是否真的测到了长期记忆能力。

省钱和答得准，可能需要分别优化

原文引用的 2026 年 3 月研究，把基于 Mem0 的事实记忆层，与 GPT-5-mini 的长上下文推理进行比较，测试包括 LongMemEval、LoCoMo 和 PersonaMem v2。

在其中两项测试中，完整上下文的准确率高出约 33 至 35 个百分点；在关注人格特征一致性的 PersonaMem v2 上，两者相当，记忆层在一组比较中略好。

原因并不神秘。偏好可以压成一句事实，复杂问题需要的证据却可能藏在原话、时间顺序和多条信息之间。提取阶段一旦漏掉，后面再精准的检索也找不回来。

记忆层的优势出现在另一张账单上。完整上下文每轮都要处理历史，即使 prompt caching 让输入 token 费用降低 90%，仍然有持续成本。事实记忆则先支付写入和提取费用，随后读取成本相对稳定。

原文给出的测算是：历史达到 100,000 token 时，大约十次交互后开始回本；问到 20 个问题时，节省约 26%。历史越长，回本可能越早。这些数字依赖研究里的模型价格、调用方式和工作负载，不能直接套成所有项目的预算公式。

完整上下文也有可靠性问题。原文引用 Chroma 在 2025 年 7 月对十八个模型的测试：输入变长后，模型表现会逐渐、且不均匀地下降，简单检索也会受影响。标称窗口装得下，不等于模型能稳定利用全部内容。

我的判断

我认同作者把记忆层视为成本与延迟基础设施的方向，但文中成本证据比延迟证据更具体，没有给出足够的延迟对照数据。至于准确率，现有结果更支持按任务判断，无法推出统一赢家。

作者提出的混合方案有实际价值：稳定画像放记忆层，当前会话保留在上下文中。它避免每轮携带所有历史，也能保留眼前任务的细节。不过，哪些事实算稳定、更新后如何覆盖、检索漏了怎么办，仍然需要应用自己定义。

记忆层能降低重复处理历史的成本，却不能自动保证证据完整。

和直接使用完整上下文相比，记忆层增加了提取、更新、检索、删除等环节；和时态图谱相比，简单事实层更容易接入，却不擅长回答历史状态问题。团队应该为确实存在的需求付出复杂度。原文也没有提供统一条件下三款产品的完整对照，产品优劣仍带有架构分析和经验判断的成分。

能拿来做什么

• 给跨会话 AI 助手整理 100 至 200 个真实用户问题和预期答案，分别测完整上下文、事实记忆和混合方案，记录准确率、token 成本与延迟，再决定是否接入。
• 为日常 AI 编程助手保存稳定的语言偏好、项目约定时，可以先尝试事实记忆；当前报错、代码片段和本轮修改要求继续保留在会话上下文中，并检查提取过程有没有丢失限制条件。
• 如果应用需要区分用户当前套餐与历史套餐，先明确事实的有效时间和替代关系，再评估时态图谱；不要仅靠多存几条文本来处理冲突。
• 在接入记忆 API 时同步设计保留期限和删除路径，把提取出的用户事实也纳入删除范围，并用同一段历史会被反复查询多少次来核算成本。