第二大脑三国杀Supermemory vs Quivr vs Mem030k星的它凭什么后来居上【免费下载链接】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/supermemoryAI 圈一直在争论一个朴素的问题大模型聊完就忘到底谁来替它记住围绕这个痛点三类开源项目先后登场——Quivr 想做你的文档第二大脑Mem0 想当 Agent 的对话记忆插件而 Suprimemory 则从网页记忆浏览器插件起家一步步把触角伸向了整个上下文栈。当它的 GitHub Star 数一路逼近 30k在 LongMemEval、LoCoMo、ConvoMem 三大 AI 记忆基准测试上全部登顶时这场第二大脑的竞争格局已经悄然改写。本文不吹捧、不站队只从定位差异、源码架构、实测数据三个层面拆解它凭什么后来居上。一、三个项目的定位分野网页记忆、文档知识库与对话记忆记忆是一个被过度使用的词。把三个项目放在一起比较之前必须先厘清它们各自解决的问题否则就是拿苹果比橙子。Quivr文档知识库解决知识检索Quivr 的原始定位是给大模型用的第二个大脑Your Second Brain核心是把你的 PDF、Markdown、网页等文档切片、向量化然后通过 RAG 问答。它解决的问题是我的知识散落在文件里AI 怎么帮我查。本质上这是一个带聊天界面的向量数据库封装——数据是静态的同一个文档对所有人返回同样的结果。Mem0对话记忆解决跨会话遗忘Mem0 的定位更接近 Agent 的长期记忆层它监听对话用 LLM 抽取用户喜欢 TypeScript正在做 API 集成这类事实存入向量库在下一次对话时检索注入。它切中的痛点是会话上下文窗口有限、Agent 重启即失忆。但它的抽象相对单薄——记忆被当作一条条独立的文本事实处理缺乏对时间线、矛盾关系和实体网络的建模。Supermemory从网页书签起家成长为上下文引擎Supermemory 的前身是一款主打把浏览过的网页记住、能和 Twitter 书签聊天的工具这也是中文社区最早介绍它时的形象。但今天仓库里的定位已经完全不同——README 开篇写着Memory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.见 README.md它把三个层次做成了统一的 APIMemory记忆引擎从对话中抽取事实、处理时间变化、消解矛盾、自动遗忘过期信息SuperRAG检索文档知识库的语义检索且与记忆合并成一次混合搜索User Profiles用户画像自动维护每个用户的静态事实 近期动态上下文一次调用、约 50ms 返回。一句话总结三者分野Quivr 管文档Mem0 管对话而 Supermemory 管人——谁在什么时间说过什么、哪些事实已失效、此刻最需要什么上下文。这个差异在后文会反复体现。二、后来居上30k 星背后的四条路径Star 数只是表象。从仓库结构和文档体系可以看出Supermemory 的后来居上不是靠单一爆点而是四条路径叠加的结果。1. 重新定义问题记忆不是 RAGSupermemory 在 apps/docs/concepts/memory-vs-rag.mdx 里给出了一个非常犀利的论断把 RAG 当记忆用正是你的 Agent 一直在遗忘的原因。文档里的例子值得细读用户第 1 天说我超爱 Adidas 运动鞋第 30 天说Adidas 穿一个月就坏了质量太差第 31 天说我准备换 Puma。当第 45 天问该买什么鞋时——RAG 的做法是向量相似度检索命中的大概率还是我超爱 Adidas于是 Agent 继续推荐 Adidas记忆系统的做法是追踪时间线Adidas 偏好已过期 → 坏鞋导致失望 → 已切换 Puma最终正确推荐 Puma。这背后的架构差异是RAG 是查询 → 向量检索 → Top-K → LLM的无状态链路Supermemory 的记忆引擎则是查询 → 实体识别 → 图谱遍历 → 时间过滤 → 上下文组装的有状态链路。仓库把它概括为Memory is not RAG并把两者同时默认开启——RAG 负责知识库文档记忆负责个性化上下文一次查询同时返回见 README.md 的 Search modes 一节。2. 架构升级知识图谱 用户画像 混合搜索如果只把记忆做成事实清单Mem0 就够了。Supermemory 的护城河在于把记忆建模成一张随时间演化的知识图谱并围绕它做了三层产品化。图谱化的记忆检索。在 MCP 服务端memory-graph工具会把一个空间space的文档与其记忆条目渲染成交互式图谱视图供用户直接可视化浏览实体之间的关系见 apps/mcp/src/server/tools/memory-graph.ts自动维护的用户画像。传统记忆依赖你想起来才去搜Supermemory 则自动为每个用户维护画像分为static长期稳定事实如资深工程师偏好深色模式和dynamic近期动态如正在做认证迁移在排查限流问题两部分。一次profile调用约 50ms直接注入系统提示词见 apps/docs/recall/user-profiles.mdx混合搜索。v4 版本的search接口支持searchMode: memories | documents | hybrid默认 hybrid 一次同时返回文档命中与记忆命中文档见 apps/docs/api-reference/search.mdx。3. 生态卡位MCP 服务器 框架全家桶30k 星背后的另一个关键变量是生态卡位。Supermemory 没有把能力锁死在自家 Web 应用里而是做成了一层可被任何工具消费的上下文层MCP 服务器提供https://mcp.supermemory.ai/mcp标准端点原生支持 Claude Desktop、Cursor、VS Code、Codex、OpenCode 等客户端工具集包含memory保存/遗忘、recall按查询检索 画像、context会话开始注入全量画像、memory-graph图谱可视化等 20 个工具见 apps/mcp/src/server/tools编程助手插件为 Claude Code、Muse Code、Cursor、Codex、OpenCode 等定制插件。以 OpenCode 插件为例见 apps/docs/integrations/opencode.mdx它实现了会话启动时自动注入上下文、关键词触发记忆存储、上下文用到 80% 时智能压缩摘要、private标签内容永不持久化等机制并把记忆按user/project作用域隔离Agent 框架全家桶Vercel AI SDK、LangChain、LangGraph、OpenAI Agents SDK、Mastra、Agno、n8n、Zapier 等一网打尽甚至为 Pipecat、LiveKit 这类语音 Agent 单独做了 SDK。这种一条 API 通吃记忆 RAG 画像 连接器 文件处理的整合加上 MCP 这个 2025 年的标准协议窗口让它在开发者社区里获得了远高于同类项目的传播半径。4. 用开源基准测试终结自说自话记忆系统最难的就是评估——每家都宣称自己最强却各用各的数据集和评分方式。Supermemory 的回应是把评估本身开源基准成绩在 LongMemEval、LoCoMo、ConvoMem 三大主流 AI 记忆基准上均排名第一。以 LongMemEval 为例达到95% Recall15 的同时只增加约 720 token 上下文上下文压缩率 99.4%按类别拆解Knowledge Updates 99%、User recall 97%、Temporal Reasoning 91%见 README.md 的 Benchmarks 一节MemoryBench开源了一套标准化、可复现的记忆系统评测框架同一个数据集、同一套评分管线、同一个裁判模型跑所有厂商Supermemory、Mem0、Zep 及你自己的实现并按 INGEST → SEARCH → ANSWER → EVALUATE → REPORT 分阶段断点续跑见 apps/docs/memorybench/overview.mdx。这套把评测工具也开源的组合拳把竞争从谁更会说拉回到了谁更能跑也让第三方开发者能亲手验证而非听信宣传。三、从代码看它的后来居上底气看定位不如看实现。仓库里几个细节能直观体现工程深度。一是忘得快的能力。多数记忆系统只解决了记住Supermemory 明确把遗忘做进了引擎临时性事实我明天有考试在日期过后自动过期矛盾信息自动消解噪声永远不会沉淀成长期记忆见 README.md。二是连接器的实时性。知识库不是靠手动上传而是靠连接器自动同步Google Drive、Gmail、Notion、OneDrive、GitHub、Granola 及 Web Crawlerwebhook 实时增量同步见 apps/docs/connectors/overview.mdx三是多租户与隔离设计的认真程度。文档 apps/docs/concepts/multi-tenancy.mdx 把隔离namespace硬边界越界返回 403和筛选metadata软标签两个机制分得很清楚并提供user_{id}、org_{id}、org:{id}:user:{id}等成熟的租户建模模式。对一个要从单体应用走向企业级的产品来说这种基础设计直接决定了天花板。四是自托管与多云解耦。本地版一个二进制、零配置即可运行完整 Memory API 跑在http://localhost:6767数据全部落在./.supermemory单目录方便备份迁移见 apps/docs/self-hosting/quickstart.mdx。LLM 侧可接 OpenAI、Anthropic、Gemini、Groq 或任意 OpenAI 兼容端点甚至用 Ollama 完全离线跑embedding 默认本地Xenova/bge-base-en-v1.5768 维无需任何 embedding API key还能通过SUPERMEMORY_EMBEDDING_POOL_SIZE、SUPERMEMORY_EMBEDDING_BATCH_SIZE等变量调吞吐见 apps/docs/self-hosting/configuration.mdx。云端与本地 API 完全一致原型在本地起、生产切baseURL即可上线。五是迁移工具已经备好。仓库专门提供了 Mem0 迁移脚本 apps/docs/migration/mem0-migration-script.py通过 Mem0 的导出 API 拉取全部记忆、本地备份 JSON 后批量add到 Supermemory并配套了图文迁移指南 apps/docs/migration/from-mem0.mdx。在一个以 Mem0 为对手的文章里看到官方迁移脚本本身就说明了市场格局的变化——后发者用搬家成本归零来抢存量用户。四、选型指南个人、团队、企业分别怎么选回到落地场景三者并非简单的替代关系而是适用边界的差异。个人用户想要懂你的 AI 助手选 Supermemory 或 Quivr 取决于你的内容形态。如果主要诉求是把收藏的网页、书签、文章变成可对话的知识库两者都能胜任但要注意 Quivr 侧重文档问答Supermemory 的浏览器插件式采集 自动记忆抽取体验更接近冲浪即记录如果你重度使用 Claude Code、Cursor、Codex 这类编程助手Supermemory 的 MCP 与插件生态是决定性优势——装一个插件AI 就能跨会话记住你的项目偏好、架构决策和踩坑记录且支持完全本地部署npx supermemory local即可。团队/创业团队给多 Agent 产品加记忆层优先评估 Supermemory 的多租户与混合搜索。一次add、一次profile、一次hybrid搜索就能覆盖知识库检索 用户画像 个性化三个需求不用自己拼向量库、embedding 管线与切分策略namespace 隔离模型直接映射到每用户 / 每租户 / 每项目配合 metadata 做细粒度筛选做 B2B 多客户产品时数据边界清晰免费额度与按量计费模式下taskType: superrag这类仅检索不记忆的写入路径还能进一步降本。企业/高合规场景考虑自托管与模型自由度Supermemory 本地版与 Quivr 自托管均可但侧重点不同。Quivr 的开源历史更长、社区部署文档更成熟适合纯文档知识库的轻量私有化Supermemory 本地版的优势是同一个 API 原型即生产、本地 embedding 免 key、可对接任意 OpenAI 兼容端点还能用 Ollama 做到完全离线关闭遥测后仅 URL 抓取需要托管读取服务。需要注意其文档中明确提示当前本地版 v0.0.8 默认绑定所有网卡且隐式鉴权不适合直接暴露到不可信网络生产环境需防火墙隔离或等下一版本回环绑定若你已在 Mem0 上沉淀了大量记忆Supermemory 的官方迁移脚本 apps/docs/migration/mem0-migration-script.py 可以把迁移成本压到几乎为零这是切换决策中不可忽视的因素。结语Supermemory 的后来居上本质上是一次问题重新定义的胜利当 Quivr 和 Mem0 还在分别解决文档检索和对话不遗忘时它把问题升级为如何让 AI 持续理解一个人——并为此构建了图谱记忆、自动画像、混合搜索、连接器与 MCP 生态这一整套上下文栈再用开源基准测试把更强变成可验证的事实。这场三国杀的终局尚未落定但方向已经很清楚记忆能力正在从可选项变成 AI 应用的默认基础设施而谁能把记忆做得又准、又省 token、又容易迁移谁就拿到了通往下一波 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考