Skip to main content

06 - 开源实现横评

前置：02 到 05 篇的机制。本篇把这些机制落到具体项目上。

本篇回答：这八个项目分别是什么形态、要拖多少外部依赖、以及在你按记忆里的印象去选之前，有哪三件事已经变了。

全部数据 gh api 实测于 2026-08-25，许可证逐个打开许可证文件读，依赖从 pyproject.toml / package.json 实读。

一、三个选型陷阱​

这三条不是"细节差异"，是按旧印象动手会直接白花几天的断点。

左边是模型和搜索结果里最常出现的说法，右边是 2026-08-25 实测「Zep 是开源的记忆服务端」docker compose 起 getzep/zep 就能自建该仓库只剩 Zep Cloud 的示例与集成，4,865★README 首句：This repository is not Zep's product or service。开源的是 getzep/graphiti「Letta 是 Python 的记忆服务端」pip install letta，记忆块存在数据库里letta-ai/letta 只剩落地页，V1 退役到 archive 分支当前源码 letta-ai/letta-code，TypeScript，3,116★，记忆是 git 仓库（05 篇第三节）「mem0 开源版自带图记忆」配置里加 graph_store 指向 Neo4j 即可MemoryConfig 里的 graph_store 字段在 2.0.0 被删v1.0.0 还有，v2.0.0 没有；图记忆的文档现在挂在 docs/platform 下
三条的共同点是"开源仓库变成了商业产品的入口"。判断一个记忆项目是不是真能自建，最快的办法是打开它的 pyproject.toml 或 package.json 看核心能力还在不在依赖里，而不是读 README 的功能列表。

第三条可以直接验证：

# v1.0.0 里有 graph_store
curl -s https://raw.githubusercontent.com/mem0ai/mem0/v1.0.0/mem0/configs/base.py | grep -n graph_store
#   47:    graph_store: GraphStoreConfig = Field(

# v2.0.0 里没有了
curl -s https://raw.githubusercontent.com/mem0ai/mem0/v2.0.0/mem0/configs/base.py | grep -n graph_store
#   （无输出）

主分支 MemoryConfig 现在的全部字段是：vector_store / llm / embedder / history_db_path / reranker / version / custom_instructions。仓库里的 examples/graph-db-demo/ 还留着 Neo4j、Memgraph、Kuzu、Neptune 四个 notebook，但它们对应的已经不是当前开源包的能力。

二、八个项目的基础事实​

项目★许可证（实读）语言最新版本最近提交
mem0ai/mem064,007Apache-2.0Pythonmem0ai 2.0.19（2026-08-24）2026-08-25
getzep/graphiti30,291Apache-2.0Pythongraphiti-core 0.29.3（2026-07-27）2026-08-21
topoteretes/cognee30,257Apache-2.0Pythoncognee 1.5.3（2026-08-23）2026-08-25
supermemoryai/supermemory29,056MITTypeScript—2026-08-25
NevaMind-AI/memU14,344Apache-2.0（文件名是 LICENSE.txt，gh 判为 NOASSERTION）Python—2026-08-21
MemTensor/MemOS10,971Apache-2.0TypeScript—2026-08-25
letta-ai/letta-code3,116Apache-2.0TypeScript—2026-08-25
langchain-ai/langmem1,624MITPythonlangmem 0.0.30（2025-10-27）2026-08-11

另外两个经常被列进候选、但值得先看一眼时间的：

项目★最近提交说明
memodb-io/memobase2,8582026-01-11用户画像式记忆（Profile 形态）。已停更七个多月
BAI-LAB/MemoryOS1,5602026-07-07EMNLP 2025 Oral 的配套实现，学术出身，工程完备度低于上表

LangMem 那一行的错位要注意：仓库还在提交（2026-08-11），但 PyPI 最新版停在 2025-10-27 的 0.0.30，也就是十个月没发版，且始终没走出 0.0.x。它作为 LangGraph 生态里的记忆原语可用，但不适合当成独立的记忆基础设施依赖。

三、部署重量：要拖多少外部服务​

这是横评里最有决策价值的一维 —— 它决定了 POC 阶段你要花半天还是三天。

从左到右起步成本递增；能力不严格递增 —— 第一档已经能满足相当一部分需求零外部服务cognee（默认配置）Anthropic memory 工具memUSQLite ＋ 嵌入式向量与图或者干脆就是文件＋ 一个向量库mem0（默认 Qdrant）LangMem ＋ Postgres Storesupermemory（自建）mem0 支持 26 种向量后端已有 pgvector 就不必新增组件＋ 图数据库graphiti（硬依赖 neo4j 驱动）可换 FalkorDB / NeptuneMemOSKuzu 那条路已标记废弃上游项目无人维护只能托管Zep Cloudmem0 的图记忆Letta Cloud开源仓库是入口不是完整实现graphiti 的 pyproject.toml 把 neo4j>=5.26.0 放在必选依赖里，不是 extra —— 即使你打算用 FalkorDB，这个包也会被装上。
第一档的存在感常被低估。cognee 默认配置下是 SQLite ＋ LanceDB ＋ 内嵌 Kuzu，pip install 之后直接能跑；对 POC 阶段来说，这比"先搭一个 Neo4j"快一个数量级。

3.1 存储依赖实读​

项目必选依赖可选后端
mem0qdrant-client、sqlalchemy（history 表）、一个 LLM、一个嵌入模型26 个向量后端：pgvector、Milvus、Elasticsearch、Redis、Valkey、OpenSearch、Weaviate、Chroma、FAISS、MongoDB、Cassandra、S3 Vectors 等
graphitineo4j>=5.26.0（写死在主依赖里）、openaiFalkorDB、Neptune、falkordblite（Python ≥3.12 的嵌入式方案）；Kuzu 那条 extra 已注明上游无人维护、将被移除
cogneesqlalchemy＋aiosqlite、lancedb、内嵌 kuzu、litellm、fastapiNeo4j、Neptune、Postgres、Turso
LangMemLangGraph 的 BaseStoreInMemoryStore（重启即丢）、AsyncPostgresStore（生产）
letta-codegit ＋ 一个 memFS 服务端默认指向 api.letta.com，可用 LETTA_MEMFS_BASE_URL 换成自建

LangMem 的 InMemoryStore 那一行是踩坑高发处：官方 README 的快速开始用的就是它，重启进程记忆全丢。上生产必须换成 AsyncPostgresStore。

四、能力矩阵​

能力mem0graphiticogneeLangMemletta-codememory 工具
抽取式写入✅✅✅✅模型自管模型自管
双时间轴（03 篇）❌✅ 四字段部分❌❌❌
作废而非删除❌ 纯追加✅ 边失效部分❌git 历史❌
图 / 多跳检索仅托管版✅✅❌❌❌
混合检索（向量＋BM25）有 reranker 模块✅ 三路 ＋ 五种重排✅向量为主❌❌
多租户过滤✅ 三维 filters✅ group_id 分区✅命名空间一 agent 一仓库目录隔离
强制注入某条自己实现自己实现自己实现自己实现❌❌
版本 / 回滚history 表靠时间字段回溯❌❌✅ git❌
人可直接读改❌❌❌❌✅✅

两处需要说明：

  • graphiti 的 group_id 是图分区字段，写在 Edge 基类上（group_id: str = Field(description='partition of the graph')）。它是必填的，比 mem0 那种"漏传就退化成全库检索"的可选 filter 结构上更安全
  • "强制注入"全列都要自己实现。04 篇第四节讲的"安全类记忆绕过排序直接注入"，没有任何一个项目提供现成机制，都得在应用层加一次按 user_id 的精确查询

五、判断一个记忆项目还活着的四个信号​

star 数在这个领域尤其不可靠 —— 上表里 star 最少的两个（letta-code 3,116、LangMem 1,624）一个是活跃主力，一个近乎停滞。四个更可靠的信号：

信号怎么看为什么可靠
发版节奏，不是提交节奏PyPI / npm 上最新版本的发布日期仓库有提交但十个月不发版，说明它不是被当成给外部用的库在维护（LangMem）
核心能力在不在依赖里打开 pyproject.toml / package.jsonREADME 的功能列表可能描述的是托管版（mem0 的图记忆）
有没有从主仓库搬走看 README 首段和默认分支的文件列表只剩落地页或示例的仓库，star 数还挂在那儿（zep、letta）
废弃标记依赖注释、extra 的说明文字graphiti 在 Kuzu extra 上直接写了上游无人维护、将被移除 —— 比任何第三方评测都准

六、四条选型路径​

先回答左边那一列，右边就定了 —— 不要从"哪个 star 多"开始单用户 · 长任务 · 记忆条目几十条排查成本最重要，不需要强制注入文件式：memory 工具自己实现，或 letta-code代价：每次读写一个模型轮次；收益：cat 一下就知道它记了什么多用户 · 事实扁平 · 已有向量库用户偏好、禁忌、常用配置这一类mem0 ＋ 你已有的 pgvector 或 Milvus不新增组件；注意图记忆不在开源版里，需要图就别选它事实会变 · 要回溯 · 要多跳「用户当时的负责人是谁」这类问题graphiti ＋ Neo4j 或 FalkorDB代价：多一个图数据库，写入多一次冲突判定调用只想先验证记忆有没有用还没到定架构的阶段cognee 默认配置，或 mem0 ＋ 本地 Qdrant半天能跑通；先拿到"有没有用"的结论，再讨论换不换
第二条和第三条的分界就是 03 篇那张双时间轴图：如果你的记忆里没有"会失效的事实"，图方案带来的那套时间字段是纯成本。

换实现的成本要提前算。00 篇3.2 说过，这一层没有语义约定：mem0 的一条记忆是带 hash 和 metadata 的文本，graphiti 的一条记忆是带四个时间字段的图边，两者之间没有无损转换。把"以后换得掉"当成假设是危险的 —— 更现实的做法是在应用和记忆库之间自己留一层薄接口，只暴露 remember(...) / recall(...) 两个方法，把具体实现挡在后面。

七、小结​

  • 三个断点：Zep 的开源服务端已不存在、Letta 换了仓库换了语言、mem0 的图记忆在 2.0.0 从开源包里删了
  • 判断项目活跃度看发版日期和依赖列表，不看 star —— 这个领域 star 与实际维护状态严重脱钩
  • 部署重量分四档，第一档（零外部服务）能覆盖的场景比通常以为的多
  • "强制注入安全类记忆"没有任何项目提供现成机制，都要在应用层自己加
  • 没有跨实现的数据格式，自己留一层薄接口是唯一现实的解耦手段

下一篇：07 - 失败模式、评测与选型，记忆怎么被污染、榜单数字为什么互相打架，以及一套落地顺序。

← 回到 专题索引