一个 128K token 的上下文窗口，在前一千个 token 之后就开始衰减，会话一结束更是荡然无存。就是这一个事实催生了一整个市场：智能体记忆基础设施如今真的成了技术栈中的一层，因为"全塞进上下文里"那条路已经不再 scale。四个框架就该怎么办这件事下了架构上彻底相反的注——Mem0 依赖一条抽取流水线加多存储扇出，Letta 把 MemGPT 的记忆层级产品化为 agent-as-a-server，Zep 把全部筹码押在名为 Graphiti 的时序知识图谱上，Cognee 则从你喂给它的任何东西里构建一张本体感知的图谱。贯穿四者的同一条线：存储不是壁垒，排序才是。截至 2026 年 6 月下旬，选其一就是在选你的智能体将会生活在哪一种检索形态之内。
速览
四个框架，对同一个问题给出四种答案——智能体在两次回合之间、两次会话之间、两个用户之间分别需要记住什么，以及下一条 prompt 到来时这份记忆怎么排序。下表只列基本盘；紧随其后的图表和矩阵会告诉你各自最用力的方向。
| 框架 | 方法 | 可自托管？ | 头号长项 |
|---|---|---|---|
| Mem0 | 抽取流水线把抽出的事实扇出到向量 + KV + 图谱存储 | 是——Apache-2.0 开源，外加托管云 | 默认按用户分域的记忆；对聊天应用即插即用 |
Letta（原名 MemGPT） |
Agent-as-a-server，配以分层的 working / archival 记忆层级 | 是——自托管服务器，外加 Letta Cloud | 跨进程按 ID 寻址的有状态智能体 |
| Zep | 时序知识图谱（Graphiti），带双时态事实有效性 |
社区版可自托管；托管版 Zep Cloud | 时间感知检索——事实知道自己何时不再为真 |
| Cognee | "任何东西到图谱"的 ETL 流水线，产出本体感知的知识图谱 | 是——Apache-2.0 开源，自带图谱 + 向量库 | 受 schema 约束、从非结构化语料构建的图谱 |
快照：2026-06-23。这一领域的 star 数和功能边界变化很快——评估部署规模前请重新核对各项目的仓库和文档。
Mem0
抽取流水线
Mem0 最具决定性的取舍是：被持久化的不是对话，而是对话产出的事实。一条消息到来时，一个 LLM 抽取步骤会拉出若干原子断言——"用户偏好素食"、"用户住在柏林"、"用户的女儿对花生过敏"——然后写下的是这些事实，而不是底下的对话回合。智能体的记忆是以一组去重的陈述、而非一段不断变长的对话稿在增长。代价是前置的：每次写入都额外要一次 LLM 调用来做抽取，在消息量大的时候这是实打实的成本。回报是检索永远不必从闲谈中淘出信号。
多存储检索（向量 + KV + 图谱）
每一条抽取出来的事实都会并行扇出到三个后端。向量存储对事实的 embedding 建立索引以做相似度搜索；键值存储按规范化的键保留它以做精确查找；图谱存储记录实体之间的关系，让一次查询能沿着 user → child → allergies 走下去。查询时三者各返回候选，Mem0 再合并——向量给你措辞上的模糊召回，KV 给你结构化提问的精确答案，图谱给你实体之间的推理路径。之所以要折腾三种存储，是因为没有任何单一存储能对这三种检索形态都排出好结果：向量错过精确键，KV 错过同义改写，图谱错过非结构化边。这里的混合不是一项特性——它就是架构。
默认按用户分域
Mem0 里的每一条记忆都会被标上 user_id（可选还带 session_id 和 agent_id），作为 API 的一等公民原语。你不是在 Mem0 之上再去搭建多租户故事；它本身就是多租户故事。对于面向千百个用户的 to-C 智能体——聊天应用、教练机器人、个性化助手——这种分域模型是阻力最小的路径：每一次记忆操作都自动隔离到正确的用户名下，而无需你在每个调用里把租户 ID 穿来串去。代价是：不符合"按用户分域"形态的工作负载（比如一个智能体在共享语料上做推理），就会与 API 的纹理逆着走。
Letta（原名 MemGPT）
Agent-as-a-server 架构
Letta 把大多数记忆库回答的问题反了过来。其他三个框架是把一个记忆后端发给你，让你的智能体代码去调用。Letta 发给你的是智能体本身，作为一个长期存在的服务端资源，你按 ID 寻址。你不必在自己进程里实例化一个智能体、然后操心如何让它的状态跨请求保留——你在 Letta 服务器里创建一个智能体，拿回它的 ID，之后每一次调用（通过 HTTP、SDK 或 MCP）都会接上同一个有状态的智能体，记忆、工具、对话历史一概在原位。这就是把当年那篇 MemGPT 论文做成产品：记忆不是要往一次无状态的对话补全上焊接的特性，它是智能体所运行其中的那个操作系统。
MemGPT 的 working / archival 记忆层级
服务器之下，记忆模型就是 MemGPT 的分层层级。有一块 core memory——很小，始终在上下文里，由智能体自己随着 persona 和用户的关键事实变化而编辑。有一层 recall memory，保存最近的对话历史，当智能体认为需要回头看时通过工具调用翻阅。还有一层 archival memory——容量无界的长期存储，在智能体发出明确的搜索调用时用向量检索召回。智能体通过调用自己的记忆管理函数在层之间搬移数据，这意味着升级和降级是模型自己做的决策，而不是你写出来的流水线步骤。OS 这个隐喻是承重的：core memory 是 RAM，archival 是磁盘，智能体在自己的上下文窗口上跑缺页中断。
这次改名释放的信号
MemGPT 是 Berkeley 团队的研究项目和最初的开源代码库。Letta 是同一批研究者围绕它建立的商业实体（以及改名后的框架）。代码库没有 fork——它被重命名，MemGPT 的仓库如今会重定向到 Letta。这次改名释放的是定位上的位移：从一个记忆管理研究成果，转向一个有服务器、有 ADE（Agent Development Environment）、有云端服务的生产级智能体平台。如果你读到一篇 2023 年提到 MemGPT 的论文，想找今天的项目——它就是 Letta：同一套层级、同一批作者，名字不同，产品面要大得多。
Zep
Graphiti 层会给每一条抽取事实打上两个时间戳：事实何时在现实世界为真，以及智能体何时学到它。检索会同时尊重两者。Graphiti 时序知识图谱
Zep 建立在 Graphiti 之上，这是同一团队另行发布的一个开源时序知识图谱引擎。存储的最小单位不是一条聊天消息，也不是一个 embedding——而是从一条消息中抽取出来、作为一条边插入图谱中的事实。"Alice 在 Acme 工作"成了从 Alice 节点指向 Acme 节点的一条边，类型为 works_at。后续的消息要么加强这条边、要么反驳它（Alice 换工作了）、要么扩展它（Alice 在 Acme 的角色变了）。图谱是事实之源；聊天历史只是图谱据以构建的那条流。查询记忆意味着遍历边，而不是搜索文档。
时间感知检索
Graphiti 里的每一条边都带两个时间戳：valid_at（事实何时在现实世界变为真）和 created_at（系统何时学到它）。这就是学术文献自 1990 年代就在主张的双时态模型，终于被应用到智能体记忆上。一个像"用户做什么工作"的查询，不会只匹配节点——它会筛到有效性窗口覆盖当下的边。关于 Acme 的那条过时事实仍然在图谱里（历史并未丢失），但它不会出现在当前的答案中。对任何"世界在智能体脚下移动"的领域——CRM、客服、排程，任何牵涉到状况会变的人的场景——那道过滤器就是一个有用的智能体和一个自信地重复昨日真相的智能体之间的差别。
事实有效性（而非衰减）
大多数"记忆衰减"实现是个 hack：按时近性给检索加权，让旧事实褪色。Zep 拒绝这种 hack。一个事实不会因为旧了就变得不那么真——它是被一条新的、与之矛盾的事实所废止，而这次废止被记录为图谱的一次变更，而非相似度分数的一次调整。前一条边的有效性窗口关闭，新一条边打开。查询历史状态（"用户去年做什么工作"）是一等公民操作，因为图谱记得那些被关闭的边。靠加权来衰减会抹掉这个区分；双时态废止则保留它。这正是 Zep 对这个领域其他人提出的核心架构论点：按时近性排序是个代理；追踪有效性才是正本。
Cognee
"任何东西到图谱"的流水线
Cognee 是这一组里唯一一个以摄入作为主要表面来构建的框架。你把它指向一个语料——PDF、网页、转录稿、数据库、代码仓——它就跑一条 ETL 流水线：切块、嵌入、抽取实体和关系，再把结果写进一个知识图谱外加一个向量索引。它的取景更接近"给我这堆材料造一个可查询的表示"，而不是"记住用户说过什么"。对那些需要在一份相当可观的既有语料上做推理、而非从对话中累积事实的智能体来说，这种"先摄入"的姿态正合适。这条流水线被设计成由若干任务组成的 DAG，所以你可以插入自己的抽取或清洗步骤，而无需重写编排器。
本体感知的摄入
Cognee 流水线内部的区分点在于：抽取受一份本体的约束——一份声明的 schema，列明实体类型、关系类型，以及它们之间合法的边。你可以用 Cognee 默认的本体，也可以自带一份。如果没有这道约束，由 LLM 驱动的抽取每跑一次就产出一张不同的图——实体类型漂移、关系被重命名、同一个概念以三种标签出现。有了本体在场，抽取就贴着 schema 走："Person"节点永远是同一个意思，"works_at"边永远指向同一个方向。这一取舍与结构化数据工程的其余部分一致：schema 是力气活，但正是它让数据在多次运行、多种查询、多个下游智能体之间可以拼装。
图谱 + RAG 混合检索
查询时，Cognee 把问题同时跑过向量索引（RAG 风格的块召回）和知识图谱（实体-关系遍历），再把结果合并。图谱擅长结构性查询——"哪些人和哪些产品相连"——向量索引擅长在底层文本上做语义召回。这里的混合检索意味着智能体不必做单选：问题各取所需，要么是一段证据，要么是一次图谱漫步。这与 Mem0 用多存储扇出做的架构动作其实是同一招，只是落在不同的写入路径上——Cognee 从文档构建图谱，Mem0 从对话构建图谱。
横向对比
到底存下了什么
四者在"消息到来后什么会被写入磁盘"上分得很干净。Mem0 存的是抽取出来的事实——由一次 LLM 抽取从对话中蒸馏出来的原子陈述，原始的对话回合大体被丢弃。Letta 把对话保留为分层结构（working set、recall、archival），并让智能体自己决定哪些片段被晋升进始终在上下文里的 core memory 块。Zep 既不存原始文本，也不存扁平的事实，而是图谱的边——实体之间带类型的关系，每条都带有有效性时间戳。Cognee 把这个问题反过来：存的是你摄入的任何东西（文档、转录稿、结构化记录），并经由本体投射成一个实体-关系图谱外加一个 embedding 索引。实际影响在于事后你能审计什么：Mem0 给你看一份事实清单，Letta 给你看一卷对话录音带，Zep 给你看一串图谱变更，Cognee 既给你看源块也给你看本体投影。
检索如何排序
排序是四者真正分化的地方。Mem0 并行跑三个排序器——向量相似度做同义改写，键值查找做规范化问题，图谱遍历做关系查询——再合并，于是主导信号是哪个存储匹配得最好。Letta 的检索由智能体驱动：何时发起一次召回查询、查什么、把哪些结果拉进上下文，都由模型决定，所以排序就是模型决定要问的内容，而不是一个固定的打分函数。Zep 按时序图谱里的遍历代价排序，并筛到有效性覆盖查询参照时间的边——这个排序器先是结构性的、时序的，然后才是语义的。Cognee 跑一种向量召回（在块上）与图谱遍历（在本体上）的混合，在查询时合并。要点是：只有 Zep 把时间当作一等公民的排序信号；只有 Letta 让智能体自己驱动搜索；Mem0 和 Cognee 都是多存储排序器，差别在于它们摄入的是什么，而不在于怎么排序。
记忆存放在哪里
运维归属把这片场地切开。Mem0 两条腿都支持：Apache-2.0 的开源自托管路线（你自带向量库、KV，可选自带图谱库），以及一个由它替你跑同一套表面的托管 Mem0 Platform。Letta 在"是服务器"这件事上态度鲜明——你可以自己跑那个服务器（Docker、Kubernetes），也可以用 Letta Cloud，但无论哪种路径，记忆都活在 Letta 服务器的状态里，而不是你应用数据库里的一行行记录。Zep 发布一个跑在 Neo4j 或 FalkorDB 上自托管的社区版，外加一个托管的 Zep Cloud；如果你只想要图谱引擎，Graphiti 本身是独立开源的。Cognee 是 Apache-2.0 开源，作为 Python 库跑在你的进程里，把数据写进任何你交给它的图谱库（Neo4j、Memgraph、Kuzu）和向量库（Weaviate、Qdrant、LanceDB、pgvector）——四者中最轻的运维占用，代价是这些后端要你自己运维。这个决定常常坍缩成一个问题：你想让你的记忆躺在自家数据库里，还是别人家的服务里。
schema 纪律
schema 是这几个框架在"LLM 该被允许凭空生造什么"上分歧最大的轴。Mem0 是自由形式的：抽取出来的事实是自然语言串、不是带类型的记录，于是同一个意思在存储里可能以各种措辞出现——好写，不易精确查询。Letta 是结构化分层的（core / recall / archival 是真实的层、有真实的 API），但每一层内部的内容是智能体放进去的什么就是什么，所以语义 schema 是智能体的责任。Zep 强加一张带类型的图：节点有类型、边有类型，抽取步骤被约束在那套词汇之内，这就是为什么同一领域的两段对话会产出可比较的图。Cognee 走得最远——一份显式的、用户提供或默认的本体掌管每一次抽取，于是同一个概念永远落在同一个节点类型下。四者构成一条干净的谱系：从"让模型说它想说的"（Mem0）到"模型必须遵从你的 schema"（Cognee），Letta 和 Zep 停在两个不同的中间点。
该选哪一个
| 使用场景 | 选 Mem0，当…… | 选 Letta，当…… | 选 Zep，当…… | 选 Cognee，当…… |
|---|---|---|---|---|
| 带按用户历史的 to-C 智能体 | 按用户分域的记忆是一等 API 原语；对聊天应用即插即用。 | 你想让每个用户的智能体都是一个跨会话按 ID 寻址的、长期存在的服务端资源。 | 可行，但若你的事实很少过期，那套时序图谱机制就有点杀鸡用牛刀。 | 过度——Cognee 的摄入流水线是为文档构建的，不是为对话回合。 |
| 企业级多租户 SaaS | user_id / agent_id 的分域让按租户隔离是默认值，而不是事后加装的。 |
一台 Letta 服务器可承载许多可寻址的智能体；再叠加你自己的租户边界。 | 社区版给你按租户的自托管图谱；Zep Cloud 按项目隔离。 | 你在自己运维的图谱 + 向量后端里自行构建多租户边界。 |
| 时间敏感的事实（CRM、客服、排程） | 向量 + KV 排序不会告诉你某个事实过期了——这得你自己建模。 | 可行，但有效性追踪是你写的应用代码，而不是框架行为。 | 为此而生——双时态边、有效性窗口、as-of 查询都是一等公民。 | 本体有助于一致性，但时序推理不是其招牌。 |
| 从既有语料（文档、转录稿、代码）出发构建 | 形态不对——Mem0 要的是对话，不是文档。 | 形态不对——Letta 要的是一个有状态的智能体，而不是一次性把语料摄入。 | 直接走 Graphiti 也可以，但 Zep 是为流式聊天优化的。 |
正合适——"任何东西到图谱"的摄入加本体约束本就是它的全部卖点。 |
| 从一条裸 RAG 流水线迁移过来 | 阻力最小的升级：保留你的向量库，在前面加上 Mem0 做抽取与 KV/图谱扇出。 | 更大的迁移——你是在把智能体本身搬到一台服务器之后，而不只是升级检索。 | 你换到 RAG 加时序推理，但要承诺去运维你过去并不运维的图谱库。 | 天然契合——Cognee 用一条图谱感知的摄入流水线替换 RAG 的索引步骤。 |
| 低运维的自托管占用 | Python 库 + 你既有的向量库；小规模下占用最轻。 | 你要运维一台 Letta 服务器加一个数据库——开源部署中四者里最重。 | 自托管需要 Neo4j 或 FalkorDB，加上 Zep 服务器——一笔实打实的运维投入。 | Python 库，对接你早就在跑的后端；没有额外服务需要照看。 |
常见问题
用了其中之一，我还需要一个向量库吗？
通常需要，但不一定由你自己跑。Mem0、Zep 和 Cognee 都把向量索引作为检索的一部分——Mem0 支持 Qdrant、pgvector、Weaviate 等；Cognee 支持 Weaviate、Qdrant、LanceDB、pgvector 等；Zep Cloud 自管。Letta 在 archival 记忆层用一个向量存储。所以向量库还在那儿，只是常被抽象掉了：要么你把框架指向自己运维的一个，要么让托管服务把它藏起来。要看选型权衡的话，pgvector vs Pinecone vs Weaviate vs Qdrant 是配套阅读。
多用户 SaaS 用哪个最好？
如果"多用户、按用户历史"是主导形态，选 Mem0——API 就是围绕 user_id 分域构建的，你不用把租户 ID 在每次调用里穿来串去。如果你想让每个用户的智能体成为一个可寻址的、长期存在的资源，选 Letta——一个用户、一个智能体 ID，跨会话与进程持久存在。Zep 和 Cognee 在这种形态下也能用，但你得花更多时间自己搭租户边界；它们是为不同的问题优化的。
它们能取代 RAG 流水线吗？
部分能，前提是你把"RAG"框得足够准。Cognee 可以直接取代一条 RAG 流水线里"索引-召回"的那两半——它摄入语料，构建一个图谱加一个向量索引，对两者作答结构化问题。Mem0 用"抽取加多存储召回"替换在对话历史上的 RAG 风格检索。Zep 用时序图谱遍历替换在聊天上的 RAG。Letta 用它的记忆层级替换"记住聊过什么"那一半，但它并不摄入一份静态语料。没有谁能在第一天就替换掉在百万级企业知识库上的 RAG——那仍然主要是向量库加切块器加 reranker，其中 Cognee 是最接近图谱感知替代品的那一个。
那 MemGPT 呢——Letta 是 fork 还是改名？
是同一团队的改名。MemGPT 是 Berkeley 那批人最初的研究项目和开源代码库，他们也发表了 MemGPT 论文。Letta 是同一批作者为商业化与运营该框架而成立的公司；代码库没有被 fork——它被改了品牌，项目仓库如今挂在 Letta 名下。论文里那套记忆层级（由智能体自己管理的 working / recall / archival 三层）就是 Letta 今天发布的同一套层级，只是围绕它有了大得多的产品面（一台服务器、一个 ADE、托管云、各 SDK）。
事实矛盾怎么处理？
每个框架的答法都不同，而这个答案对任何"事实会变"的场景都是承重的。Mem0 的抽取流水线在写入时执行一次去重与冲突解析：当新事实与既有事实矛盾时，旧事实会被更新或替换，而不是被追加。Letta 让智能体自己重写 core memory 块，所以矛盾处理就是智能体怎么决定——灵活，但好坏全看 prompt 的质量。Zep 是最有原则的：一条矛盾的事实会关闭前一条边的有效性窗口、开启新一条边，于是两个版本都保留在图谱里、各自有时间区间。Cognee 倚靠本体——如果两条抽取出来的关系会违反 schema 的基数规则，会在摄入时被拒绝或合并。如果矛盾处理是硬指标，Zep 的双时态模型是最干净的答案。
Supermemory 和 Cogito 怎么样？
两者都在同一邻近区域，按你优化的方向不同值得一看。Supermemory 是一个托管记忆层，重点在 API 工效与跨应用记忆共享——它更接近 Mem0 托管版的竞争者，而不是这里这几个自托管框架。Cogito 更年轻，围绕"个人智能体记忆"展开，强调本地优先存储。没把这两者挤掉这次的四选其一，是因为这里展示的四个更利落地覆盖了架构谱系（抽取 vs 层级 vs 时序图谱 vs 本体感知 ETL），但如果你的约束是"只能托管"或"本地优先"，那两者都值得单独评估。
延伸阅读
本站相关内容：
- pgvector vs Pinecone vs Weaviate vs Qdrant——这几个框架其中三个底下的那一层向量库的配套对比；先选索引，再选包裹它的记忆框架。
- 短期 vs 长期记忆——上下文里的工作集与外部存储之间的概念切分，以及把这四者都串成不同实现的那一套晋升-降级循环。
- 记忆存储：向量、KV、图谱与驱逐——为什么不同种类的记忆要不同的后端，统一接口的模式，以及决定什么被遗忘的驱逐策略。
- 上下文窗口详解——有限的共享 token 预算，以及让外部记忆成为必需的三种失败模式。
项目来源：
- Mem0 on GitHub——Apache-2.0 源码、多存储后端矩阵、抽取流水线文档以及
user_id分域 API。 - Mem0 文档——托管平台参考、向量 / KV / 图谱后端配置以及集成范例。
- Letta on GitHub——服务器源码、working / recall / archival 记忆三层以及 agent-as-a-server 的 API 表面。
- Letta 文档与
MemGPT→ Letta 改名说明——官方声明 Letta 即同一团队改名后的MemGPT项目。 - Zep on GitHub——社区版源码、时序图谱的设计说明以及双时态有效性模型。
Graphition GitHub——独立的时序知识图谱引擎，为 Zep 提供动力。- Cognee on GitHub——Apache-2.0 源码、"任何东西到图谱"的流水线、本体配置以及支持的图谱 + 向量后端。
- Lost in the Middle: How Language Models Use Long Contexts (Liu et al., 2023)——本文开篇"上下文窗口在前一千个 token 之后就开始衰减"那一论断的主要出处。
MemGPT: Towards LLMs as Operating Systems (Packer et al., 2023)——Letta 那套分层记忆背后的原始论文。