AI记忆赛道群雄并起：Mem0、Zep、Supermemory、ASMR谁能成为下一个“安卓“

AI记忆赛道群雄并起：Mem0、Zep、Supermemory、ASMR谁能成为下一个"安卓"

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory

大模型什么都会，唯独记不住。上下文窗口再长，关掉会话一切归零；向量数据库存再多分块，也无法回答"用户昨天为什么改主意了"。当"聊完就忘"从段子变成产品痛点，AI 记忆（Memory）就从一个辅助功能升级为独立赛道——过去一年里，这条赛道密集出现了一批明星玩家：论文刷爆 SOTA、号称"抛弃向量数据库"的 ASMR；创始人 19 岁创业、获 Jeff Dean 等名人投资的 Mem0；深耕会话记忆多年的 Zep；以及在三项主流记忆基准测试上均排名第一的开源项目 Supermemory。

这篇文章不做营销式盘点。我们将以 Supermemory 仓库的真实源码和文档为解剖样本，回答三个更实际的问题：赛道玩家各自押注了什么技术路线；Supermemory 为什么把自己定位成"模型与 Agent 之间的中间层"；以及这场竞争的本质——谁先定义长期记忆的"事实格式"，谁就握住了下一代 Agent 生态的入口。

一、赛道全景：从"存储聊天记录"到"记忆操作系统"

记忆赛道的爆发，有一个清晰的技术分水岭：早期玩家把"记忆"当作检索问题——对话文本向量化、塞进向量库、查询时做相似度匹配。Zep 是最典型的代表，其数据模型围绕 Session 与 Message 展开，本质上仍是"带检索的聊天记录存储"。

随后 Mem0 把这一层做成了轻量 API：开发者传入对话，它用 LLM 抽取"事实列表"，存进向量库，检索时再提示词注入。它押中了两个趋势——Agent 化开发需要零门槛接入，以及"抽取事实"比"存原文"更接近记忆的语义。这也是它能在 2024 年迅速成为 memory layer 明星、吸引顶级资本的原因。

2025 年起赛道进入第二阶段，技术路线开始分化。ASMR 的核心主张是"用 Agent 完全替代向量数据库"：不再用 embedding 做最近邻检索，而是让模型在检索时自主筛选、推理，在长对话记忆任务上把准确率推到 99% 量级并刷爆多项 SOTA——它用结果证明了一个判断：embedding 相似度根本承载不了"时间先后、因果演变、立场翻转"这类记忆语义。

Supermemory 走的是另一条更重的路线：自己训练抽取模型，自研时态向量-图谱引擎，把"对话→事实→关系→画像"整条管线做成一个封闭引擎，再通过 API、MCP、SDK、插件把能力分发出去。仓库 README 给出的成绩单是：在 LongMemEval、LoCoMo、ConvoMem 三大主流 AI 记忆基准上均排名第一，95% Recall@15 的同时实现 99.4% 的上下文压缩，用户画像单次调用约 50ms。

把四家放在一起看，赛道其实只剩两条路线：以 Mem0 为代表的"向量库 + 提示词抽取"轻封装，和以 Supermemory 为代表的**"专有抽取模型 + 时态知识图谱"重引擎**。ASMR 则像是一份对前者的檄文，也是对后者的背书——记忆不能靠相似度检索，这一点行业正在达成共识。

二、Supermemory 的生态位：不做模型，做记忆基础设施的"中间层"

Supermemory 一个值得注意的选择是：它不绑定任何模型。托管平台用自研模型做抽取，自托管版本则完全交给用户指定——OpenAI、Anthropic、Gemini、Groq，乃至 Ollama、vLLM 等本地端点都可以，官方文档甚至给出了gpt-oss:20b离线运行的完整配置。这种"引擎中立、模型可插拔"的姿态，是它作为中间层的第一块基石。

2.1 MCP：一个端点，服务所有 AI 助手

中间层策略最直接的落点是 MCP（Model Context Protocol）。仓库中apps/mcp实现了完整的 Supermemory MCP 服务器，托管地址是一个标准 JSON 配置即可接入：

{ "mcpServers": { "supermemory": { "url": "https://mcp.supermemory.ai/mcp" } } }

按 MCP 服务器说明 的描述，该实现基于 MCP SDK v2，每次 HTTP 请求都做 OAuth 鉴权，并暴露 8 个模型可见工具——search_memory、get_profile、list_documents、get_document、list_memories、list_spaces、who_am_i、add_memory——外加select-space、memory-graph、guided-save、upload-file四个可在对话内直接打开的交互式 App。这意味着 Claude Desktop、ChatGPT Web 乃至任何兼容 MCP 的客户端，连上同一端点就共享了同一份记忆，团队可以跨助手协作而上下文不散。

2.2 插件矩阵：给编程助手装上记忆

比 MCP 更"贴身"的，是围绕 IDE/CLI Agent 的插件矩阵。仓库文档列出的插件覆盖 Claude Code、Muse Code、Cursor、Codex、OpenCode、OpenClaw、Hermes 等主流编程助手。以 OpenCode 集成文档 为例，插件的记忆机制包含四层：会话启动时自动注入相关记忆（用户画像、项目知识、语义匹配）、"remember/save this"关键词触发即时存储、上下文用到 80% 时自动压缩并沉淀为记忆、<private>标签内的内容永不落盘。

这条产品线直接对应社区里热度最高的使用场景——中文技术社区多篇上手教程都在解决"AI 编程助手跨会话失忆"的痛点，而 Supermemory 把方案做成了"装一个插件"级别的体验。

2.3 SDK 中间件：侵入框架而非等待框架

对应用开发者，Supermemory 没有停留在"教你怎么调 API"，而是直接寄生进主流推理框架。以 OpenAI SDK 中间件 为例，with_supermemory()包装chat.completions.create：请求发出前，中间件从 Supermemory 拉取静态画像、动态上下文和与当前消息相关的记忆，去重后注入 system/developer 消息；响应返回的同时，后台任务异步把这段对话存入记忆库，主请求零额外延迟。

Agent Framework 上下文提供器 走的是另一套协议：实现BaseContextProvider的before_run/after_run钩子，支持profile、query、full三种检索模式，与框架内置的 Mem0 集成保持同一用法。而 Pipecat、LiveKit 的 Python SDK 则把记忆接到了语音 Agent 的帧处理流程上，实现"会话中拦截→检索→注入→存储"的闭环。

加上仓库中已实现的 LangChain、LangGraph、AI SDK、Mastra、CrewAI、VoltAgent、Convex 等集成，Supermemory 实质上铺设了一张覆盖"推理框架 + Agent 框架 + 语音管线 + 编程助手"的接入网——这正是一个中间层该有的姿态：让记忆能力以每个生态的原生方式出现。

2.4 一条管线，同时输出 RAG 与记忆

中间层策略的另一个支撑点，是把"记忆"和"RAG"塞进同一个引擎。按 How it works 文档，任何一份文档（文本、PDF、图片 OCR、视频转写、URL、代码）进入管线后，会产出三样东西：Document chunks（用于 RAG 检索的原文分块）、Memories（抽取出的图谱事实）、Profile（随时可取的静态 + 动态画像）。SDK 侧只是几个方法：

import { Supermemory } from "supermemory"; const supermemory = new Supermemory({ apiKey: "sm_..." }); // 写入：对话或文档自动进入抽取管线 await supermemory.add("user_123", { content: "The user loves Paris.", dreaming: "instant", }); // 读取：记忆 + 画像一次取回 const { profile } = await supermemory.profile("user_123"); const { results } = await supermemory.search("user_123", { query: "where does the user want to travel?", });

这也是它区别于"纯 RAG 产品"和"纯记忆产品"的地方：开发者的知识库和个人化状态不再需要两套系统、两个供应商。文档对比页给出的判断很直接——RAG 回答"我知道什么"，记忆回答"我记得关于你的什么"。而这两者在 Supermemory 中共享同一命名空间、同一检索入口，这正是它试图卡住的生态位：做整个上下文栈的默认底座。

2.5 从托管云到单二进制：部署形态的"全都要"

中间层要成为默认选项，还必须回答"数据主权"问题。仓库的自托管方案给了一条极简路径：

curl -fsSL https://supermemory.ai/install | bash

单二进制、零配置、内置本地 embedding（默认Xenova/bge-base-en-v1.5，768 维），首次启动自动生成 API Key，指向 Ollama/LM Studio 即可完全离线运行。SDK 切换只需改一个baseUrl，所有 API 语义不变。托管平台则提供 SOC 2、GDPR、HIPAA BAA 等合规能力。"云上一条 API、本地一个二进制"，让不同隐私诉求的团队都能把记忆层放在自己信任的边界内——这一点对争夺开发者心智至关重要。

三、标准之争：谁先定义长期记忆的"事实格式"

如果说前两节讨论的是"接入广度"，那这一节才是赛道胜负手：记忆不是存下来就完了，关键是存成什么结构。不同结构决定了检索能答对什么问题，也决定了上层生态要不要围绕你的格式重写。

3.1 事实格式的分野：向量相似 vs 时态图谱

Supermemory 的图谱模型在 Graph memory 文档 里被定义得很明确。事实之间只有三种关系：

• Updates（更新）：新事实替换旧事实，"Alex 在 Google 做工程师"被"Alex 刚入职 Stripe 做 PM"覆盖，检索命中当前事实，历史保留可审计；
• Extends（扩展）：新事实补充细节而不推翻旧事实，"负责支付业务"扩展"Stripe PM"；
• Derives（推导）：系统从多条记忆的模式中推断出从未被直接陈述的事实。

Memory 1: "Alex is a PM at Stripe" Memory 2: "Alex frequently discusses payment APIs and fraud detection" → Derived: "Alex likely works on Stripe's core payments product"

配合三种记忆类型（事实 Facts 持久、偏好 Preferences 随重复强化、事件 Episodes 随时间衰减），以及时间衰减、矛盾覆盖、噪声过滤三套自动遗忘机制，这套模型回答了一个向量库永远答不对的问题——"用户上周说喜欢阿迪，今天应该推荐什么？"文档用这个经典场景做了演示：RAG 按相似度会召回"我爱阿迪达斯"这条过时事实，而图谱会沿着"鞋坏了→失望→换品牌"的因果链，把当前状态"现在偏好 Puma"捞出来。

画像（Profile）是这套格式的直接产物：每个命名空间自动维护一份static（长期稳定事实：职业、偏好）+dynamic（近期动态：正在做的项目、最近的学习）的压缩摘要，单次调用即取即用——它本质上就是"记忆格式"对上层 LLM 的最终呈现形态。可以毫不夸张地说：谁的事实格式更接近真实的人类记忆状态机，谁的 Agent 就更"懂人"。

3.2 隔离即标准：命名空间成为多租户原语

记忆格式的另一个维度是隔离。Supermemory 把隔离做成了 URL 路径的一部分（v3/v4 的containerTag升级为 v5 的/ns/{namespace}），且每个命名空间对应独立的向量索引，检索物理上不会跨边界泄漏。命名规则甚至允许org:acme:user:john这样的分层结构。对开发者而言，这意味着"每个用户一个命名空间 + 一把 scoped key"就能实现严格的多租户——而 GDPR 式的数据删除，也随之简化为"删掉一个命名空间"。隔离机制成为 SDK 的默认参数，就会反过来约束上层应用的架构习惯，这是标准之争里隐蔽但真实的一环。

3.3 API 同构化：迁移文档暴露的"标准前夜"

这场标准之争最有趣的证据，藏在仓库的迁移文档里。从 Mem0 迁移指南 给出了逐行 API 映射：mem0.add(messages, user_id)对应client.add("user_alice", { content })，client.search(query, user_id)对应client.search("user_alice", { query, searchMode: "memories" })；从 Zep 迁移指南 则把session.create()、memory.add(session_id, ...)映射为命名空间参数。社区生态中甚至出现了 OpenMemory 这类第三方迁移工具，声明可一键从 Mem0、Zep、Supermemory 平滑迁移。

这个现象值得玩味：当各家开始互相提供迁移通道时，说明 API 表层已经在趋同——add、search、namespace正在成为行业通用动词。表层趋同意味着竞争上移到深层：抽取模型的精度、图谱语义的完备度、时态推理的正确率、延迟与成本。Mem0 有先发与流量，Zep 有会话场景的沉淀，ASMR 有"免向量库"的范式冲击，而 Supermemory 手里是三项基准第一的成绩单 + 完全开源的接入栈。

3.4 "安卓"类比：谁有资格成为记忆层的开放系统

回到标题的问题。安卓赢下移动生态，靠的不是最强硬件，而是三样东西的组合：开放的内核、免费的授权、庞大的分发生态——它定义了"手机操作系统"这个层，让上面的厂商和下面的开发者都默认站在它的语义之上。

记忆赛道的"安卓"同样需要三样东西：一个标准的事实格式（图谱语义、时态规则、画像结构），一套跨生态的分发协议（MCP、SDK 中间件、编程助手插件），以及一个可自托管的开放引擎（数据主权不再成为采用障碍）。按这个框架审视四家：ASMR 贡献了"抛弃向量库"的范式，Mem0 跑通了"轻量接入"的体验，Zep 守住了会话记忆的基本盘，而 Supermemory 是目前唯一同时押注"自研引擎 + 标准 API + MCP 分发 + 插件矩阵 + 单二进制自托管"的选手——它的生态位，恰好就是安卓当年站过的那个位置：做一个所有人都绕不开的中间层，而不是某个应用、某个模型的一部分。

这场竞赛远未到终局。基准可以刷，SOTA 可以赶，但决定胜负的最终变量，是开发者是否愿意把"记忆"当作一个可信赖的默认基础设施来使用——换句话说，谁能先让整个 Agent 生态围绕自己的事实格式生长，谁就拿到了下一代智能体的"安装底座"。

【免费下载链接】supermemoryMemory and context engine + app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory