一、先搞清楚：Agent 为什么会"失忆"

1. 不是智商问题，是没地方记

你让一个没带纸笔的人背圆周率，他背不下来，不是因为他傻，是因为他手里没有纸。

模型也一样。一次请求结束，状态就清空了。它连你叫什么都记不住，更别说你前天说过的话了。这不是态度问题，是硬件问题。

2. 上下文窗口再大，也是临时工

有人要抬杠了：现在上下文窗口不是越来越大吗？几百万 token 都有。

大是大了，但那是"临时工"，不是"正式工"。窗口一关，什么都留不下。它只是让你一次看得多，不是让你一直记得住。两码事。

3. 所以真正要解决的是四个问题

什么信息值得记？用什么结构存？需要的时候怎么找回来？由谁来负责写入和更新？

这四个问题，就是今天六个项目的分水岭。

二、四条路线，四个门派

先把六个项目摆一起，看个全景：

四条路线的区别，一句话总结：

Mem0 关心"记哪些事实、怎么找回"；Zep 和 Graphiti 关心"事实之间啥关系、啥时候有效"；OpenViking 关心"怎么分层组织、按需读多少"；MemGPT 和 Letta 关心"谁在 Agent 整个生命周期里管记忆"。

三、Mem0：给老应用装个外 挂硬盘

1. 它到底是啥

Mem0 就是一层独立的长期记忆层，放在应用和大模型中间。你手上已经有一套 Agent 或聊天应用，只想让它记住用户偏好和历史决策？好办，加个 Mem0。

这操作，像不像给你家那台老电脑加了一块固态硬盘？不用换机，插上就能用，开机速度立竿见影。

2. 它怎么工作的

3. 举个例子

用户说：

Mem0 不存整段原话，而是提炼成类似这样的记忆：

下次用户让 Agent 订机票，应用调用 Mem0 搜索相关记忆，再把这条偏好塞进 Prompt。

你看，AI 终于记住你是个"过道爱好者"了。这体验，比它第三次问你座位要求舒服一百倍。

4. 主要特点

• 接入相对简单：对话后调用 add，模型调用前执行 search。
• 默认保存经过 LLM 提炼、去重的事实，而不是完整聊天记录。
• 可以按 user_id、agent_id、run_id 等维度隔离记忆。
• 擅长保存用户偏好、项目决策、个人资料和跨会话信息。
• Agent Runtime 仍由 LangGraph、CrewAI 或应用自己的代码负责。

所以，把 Mem0 归为"轻量提取式记忆"比较合适。注意，这并不代表它只能用向量检索——它也提供 Graph Memory 来表达人物、事件和关系，但从整体产品形态看，它更像一个可以嵌入现有 Agent 的记忆组件。

5. 适合谁

客服记住用户偏好、教育助手记住学生掌握情况、个人助手记住日程习惯……场景简单，够用。

但一旦信息开始牵扯复杂关系、连续变化或历史状态，光靠一条条事实加语义搜索，就不一定精确了。这时候，得看下一位。

四、Zep：别人记"你爱啥"，它记"你为啥爱、啥时候不爱了"

1. 思路差异

Mem0 擅长记一条条事实，Zep 更关心事实之间的关系，以及这些关系如何随时间变化。Zep 早期常被介绍为"给聊天机器人用的长期记忆服务"，现在更强调 Context Engineering 和 Context Graph。

它不仅保存"用户喜欢什么"，还会把对话、业务数据和文档转换成一张图，里面包含：

• 实体：用户、公司、产品、项目
• 关系：就职于、购买过、负责、依赖
• 事件或原始数据片段
• 事实成立与失效的时间
• 事实来自哪段原始数据

2. 经典例子

系统先后收到两条信息：

普通向量记忆会把两条都搜出来，但说不清哪条现在有效。Zep 的时间图会保留历史，同时标记关系的有效时间，于是它能回答：

这就跟查户口一样：不仅知道你现在住哪，还知道你啥时候搬的家、以前住哪儿。 

3. 定位

可以把 Zep 理解为一个围绕时间上下文图构建的生产级平台。除了保存和查询图数据，它还负责托管、扩展、低延迟检索、上下文组装和治理。

五、Graphiti：Zep 的开源亲儿子

1. 关系先搞清楚

Graphiti 不是 Zep 的竞品，而是由 Zep 团队开发、构成 Zep 技术基础的开源框架。一句话理清：

2. 三类核心信息

Graphiti 会把持续进入的数据组织成三类信息：

• Entity：人、产品、组织、概念等实体
• Fact/Edge：实体之间的事实和关系
• Episode：产生这些事实的原始对话、文档或事件

3. 时间语义才是灵魂

普通知识图谱：知道 A 认识 B。

Graphiti：知道 A 从哪天开始认识 B、哪天绝交了、系统是啥时候知道这事儿的。

它会区分：事实什么时候开始成立、什么时候不再成立、系统什么时候得知这条事实、系统什么时候得知它失效。每条推导出的事实，还能追溯到原始 Episode。检索时可以向量搜索、全文搜索、图遍历三管齐下。

4. 适合谁

• 客户关系、组织关系经常变化
• 需要理解人物、项目、文件之间的多跳关系
• 需要回答"当时是什么状态"
• 需要追踪事实来源
• 企业数据持续更新，不能每次整体重建知识图谱

不过话说回来，结构越强，成本越高。部署、数据建模、日常维护，全是活儿。这就是"结构自由的价格"。你要是没那个精力伺候它，它分分钟教你做人。

六、OpenViking：把记忆做成文件夹

1. 思路

前面几位都在搞"记忆"，OpenViking 干脆把记忆、外部知识和可复用能力全塞进同一个上下文空间，做成一个面向 AI Agent 的上下文数据库。

它的核心结构长这样：

2. 和普通向量库的区别

普通向量库：全部平铺，一锅烩，检索全靠相似度硬捞。

OpenViking：每个 Context 有稳定的 viking:// URI，保留目录、范围和上下级关系。向量检索负责找到相关区域，目录树负责限定搜索范围，Agent 再沿目录读取真正需要的内容。

这操作像什么？像你家 AI 终于从"在垃圾桶里翻文件"升级成"会用电脑了"。进步，实打实的进步。

3. L0/L1/L2 控制读取深度

所以它的典型检索过程，不是直接挑出几个相似片段塞进 Prompt，而是先定位区域，再逐层深入：

4. 适合谁

知识和记忆天然有目录结构、需要按作用域隔离、或者想让 Agent 像逛文件系统一样逐步探索上下文的场景。

它不像 Graphiti 那样重点表达实体关系和时间变化，也不像 Letta 那样接管整个 Agent Runtime。它更接近 Agent 下方的一层统一上下文基础设施——位置摆得很清楚，不抢戏。

七、MemGPT：让 AI 自己当记忆管理员

1. 灵感来源

MemGPT 是 UC Berkeley 团队 2023 年提出的研究项目。灵感来自操作系统的虚拟内存。

操作系统能在内存和磁盘之间调度数据，让程序感觉自己拥有很大的内存。那 Agent 能不能在有限上下文窗口和外部存储之间搬运信息？

能。这就是 MemGPT 干的事。理论上讲，这就是给 AI 装了套"虚拟内存"，只不过它搬的不是数据页，是记忆。

2. 记忆分层

3. 关键区别

重点不是"应用在调用模型前检索一次"，而是 Agent 本身拥有记忆工具，自己决定：

• 哪些信息该写入长期记忆
• 哪些核心记忆需要更新
• 什么时候检索旧信息
• 上下文空间不够时移出什么
• 是否需要继续执行下一轮 操作

想象你雇了个助理，这助理不光会干活，还自己记笔记、自己整理工位、自己决定旧文件扔哪。MemGPT 就是这个助理。

也就是说，MemGPT 把记忆管理变成了 Agent 推理循环的一部分，而不只是外围的 RAG 插件。这套方法在论文里被称为"虚拟上下文管理"。

八、Letta：MemGPT 的正式出道版

1. 别搞混了

MemGPT 和 Letta 关系很近，但指向的对象并不完全一样：MemGPT 更偏向原始研究和 Agent 设计模式，Letta 则是从这套思想发展出来的框架与平台。

2024 年，原团队把开源框架改名为 Letta，把"MemGPT"这个名字留给论文中的原始设计模式。

这就好比：论文是原稿，Letta 是出版版。同一个作者，同一个灵魂，只是 title 更响了。

2. Letta 管什么

• Agent 的持久化状态
• 上下文窗口的组装方式
• 可编辑的记忆块
• 工具调用和执行循环
• 文件、数据源和技能
• 多次运行之间的身份延续
• 本地或云端部署
• Agent 的调试与观察

所以用 Letta，通常不只是"给现有 Agent 接个记忆组件"，而是在 Letta Runtime 中创建并运行一个 Agent。当前的 Letta 已经超出原始 MemGPT 架构，提供多种 Agent 类型和更现代的执行循环，但"有状态 Agent"和"记忆属于 Runtime 核心能力"的思想一直没变。

九、同一个例子，四个门派各显神通

概念说再多，不如落到数据上。假设用户说：

1. Mem0 的玩法

调用方负责在推荐活动前搜出这些记忆。简单直接，任务完成。

2. Graphiti 和 Zep 的玩法

系统既能回答现在的位置，也能回答过去的位置，还知道关系啥时候变的。妥妥的"搬家档案管理员"。

3. OpenViking 的玩法

目录摘要负责说明这儿存了位置变化和活动城市偏好，向量检索负责找到目录，Agent 再按需读具体记忆。原始会话留在 Session 里当详细上下文，不必每次请求都背着全部历史。轻装上阵，舒服。

4. MemGPT 和 Letta 的玩法

重点不再是某一种存储结构，而是"谁负责管理记忆"：由 Agent Runtime 和 Agent 自己共同完成。

十、怎么选：对号入座

这四条路线没有绝对的优劣，关键看你缺的是记忆组件、数据结构、上下文基础设施，还是完整的 Agent Runtime。

最后说两句实在的。实际系统不一定只能选一个：你可以用 Letta 管理 Agent 的执行与状态，再挂一个知识图谱或上下文数据库。

真正要理清楚的是职责边界：谁决定写入什么？谁处理更新和冲突？谁负责检索？最终哪些内容进入模型上下文？

Agent 记忆不是"加个向量数据库"就完事。它更像一组逐层展开的工程问题：先决定记什么，再决定怎么组织和找回，最后决定谁来管理整个记忆生命周期。

把这几个层次想明白，这六个项目之间的差异，你心里基本就有数了。

毕竟，你总不希望自己养了个比金鱼还健忘的 AI 吧？