Ch13: supermemory——产品化记忆与多源捕获

Part 3: 七大开源项目精读 前置章节：Ch12: cognee——本体论驱动的认知管线 后续章节：Ch14: MemOS——记忆操作系统与 Dream Pipeline

1. 一句话定位

supermemory 是面向终端用户的”让 AI 记住你”产品，在 LongMemEval / LoCoMo / ConvoMem 三大 benchmark 排名第一，走产品路线而非技术深度路线——核心是 Profile API + Browser Extension + MCP 集成，解决的是”普通人如何让 AI 记住自己”而不是”开发者如何给 Agent 加记忆”。

2. 设计哲学——私人秘书类比

想象你请了一位私人秘书。好的秘书不只听你说什么——他还会观察你的行为。

你说”我喜欢喝咖啡”，秘书记住了——这是对话来源的记忆。

你每次路过星巴克都会多看两眼，秘书注意到了——这是行为来源的记忆。

你在网上搜索”手冲咖啡器具推荐”，秘书帮你把相关文章收藏了——这是阅读来源的记忆。

三种来源的记忆合在一起，秘书对你的理解远比”只听你说什么”更全面。

supermemory 就是这位私人秘书。它和其他六个项目的根本区别在于：其他项目问的是”开发者如何给 Agent 加记忆”，supermemory 问的是”普通用户如何让自己的 AI 记住自己”。这个定位差异决定了它的每一个设计选择。

其他六个项目的记忆来源只有一个——对话。用户说了什么，系统提取什么。但人每天的对话只是生活的一小部分——更多的信息藏在阅读、浏览、搜索等日常活动中。如果你只用对话来建立对一个人的了解，你会错过大量重要信息。

supermemory 的 Browser Extension 就是用来捕获这些”对话之外”的信息的。用户在浏览器里看到一篇文章、一段对话、一个灵感，一键保存到 supermemory——不需要”告诉 AI”，只需要”让 AI 看到”。

这个类比有一条边界需要说明：私人秘书观察你”路过星巴克多看两眼”是被动的、无感知的，supermemory 的 Browser Extension 是主动的、需要用户手动点击保存。它更像”把文章剪报贴到笔记本上”而不是”秘书偷偷观察你”——用户始终知道哪些信息被保存了。

2.1 产品化 vs 引擎化的根本区别

理解 supermemory 需要先理解”产品”和”引擎”的区别。

DB-Agent-Memory、mem0、Graphiti、cognee 都是引擎——它们提供 API 和 SDK，开发者把它们嵌入到自己的 Agent 应用中。终端用户不会直接和这些引擎交互——他们交互的是使用这些引擎的 Agent 应用。

supermemory 是产品——终端用户直接和它交互。用户安装浏览器扩展、保存网页内容、查看和编辑自己的 Profile、在 Claude/Cursor 等 AI 工具中调用 supermemory 的记忆。整个流程中，用户是主动参与者，不是被动的数据源。

这个区别的影响是深远的：

• 用户体验优先级不同：引擎优先考虑 API 的灵活性和性能，产品优先考虑交互的简单性和直觉性。supermemory 会为”一键保存”优化体验，DB-Agent-Memory 会为”检索精度”优化算法。
• 成功指标不同：引擎的成功指标是开发者满意度（API 好不好用、文档齐不齐全），产品的成功指标是用户满意度（好不好上手、有没有用）。supermemory 在 benchmark 上排名第一，更可能是产品体验好（记忆来源丰富 + Profile 可编辑），而不是算法创新。
• 技术深度不同：引擎追求技术深度——更精细的检索、更智能的提炼、更完善的冲突处理。产品追求”够用就好”——简单的检索 + 直觉的交互 + 丰富的入口就是最好的方案。

3. Browser Extension——被忽视的捕获入口

Browser Extension 是 supermemory 最独特的功能，也是其他六个项目都没做的”捕获入口”设计。

3.1 工作原理

Browser Extension 是一个标准的 Chrome 扩展（也支持 Firefox 等其他浏览器）。当用户在浏览器中阅读网页时，点击扩展图标，当前页面的内容就会被提取并保存到 supermemory。

提取不是简单地保存整个页面 HTML。supermemory 会做内容清洗——去掉导航栏、广告、页脚等无关内容，只保留正文文本。然后对清洗后的文本做摘要和关键信息提取，以结构化的形式存储。

3.2 解决了什么问题

大多数人的信息获取并不只来自和 AI 的对话——更多来自阅读。你在 Hacker News 上读了一篇关于 Rust 的深度文章，在 GitHub 上浏览了一个有趣的项目的 README，在 Twitter 上看到了一段关于系统设计的讨论。这些信息都可能影响你希望 AI 如何帮助你——但如果你不主动告诉 AI，它就不知道。

supermemory 的 Browser Extension 让”告诉 AI”的成本降到了一次点击。对比其他项目的做法：

• mem0：只能从对话中提取事实。你想让 AI 知道你读了一篇关于 Rust 的文章，得在对话中说”我读了一篇关于 Rust 的文章”——这很不自然。
• Letta：Agent 自己管理记忆，但记忆来源也只有对话。Archival memory 可以手动插入信息，但需要开发者调用 API。
• Graphiti / cognee：都从对话或文档中提取信息，但没有”从浏览器阅读中捕获”的低门槛入口。

3.3 工程实现

Browser Extension 的实现包括：

• Content Script：注入到用户访问的每个网页中，负责提取页面内容
• Background Script：管理扩展的状态和与 supermemory 后端的通信
• Popup UI：用户点击扩展图标时弹出的界面，显示保存状态和快速操作

提取的内容通过 supermemory 的 API 保存到后端。API 调用是异步的——用户点击保存后可以立即继续浏览，不需要等待处理完成。

3.4 局限性

Browser Extension 有几个局限：

• 需要用户主动操作：不会自动捕获浏览历史——用户必须手动点击保存。这降低了隐私风险，但也降低了捕获覆盖率。
• 内容提取质量参差不齐：对于结构良好的文章（新闻、博客），提取效果好；对于复杂页面（社交媒体、代码仓库），提取质量下降。
• 只能捕获文本：图片、视频、交互式内容无法有效提取。用户在 YouTube 看了一个教程视频，Browser Extension 无法捕获视频内容。

4. Profile API——从事实集合到用户画像

supermemory 的 Profile API 把用户的记忆组织为结构化的用户画像，而不是”一堆事实的集合”。

4.1 Profile 的数据结构

Profile 是一个结构化的 JSON 对象，包含用户的各个维度信息：

{
  "name": "小明",
  "interests": ["Rust", "系统编程", "开源"],
  "preferences": {
    "programming_language": "Rust",
    "editor": "Vim",
    "os": "macOS"
  },
  "work": {
    "company": "某互联网公司",
    "role": "后端工程师"
  },
  "communication_style": "简洁直接，不喜欢客套"
}

这和 mem0 的扁平事实列表（”用户喜欢 Rust”、”用户用 Vim”、”用户在互联网公司工作”）有本质区别——Profile 把相关信息聚合在一起，形成了对用户的整体理解，而不是零散的事实碎片。

4.2 和 DB-Agent-Memory L3 画像的对比

两者代表了两种”画像构建”哲学：

• supermemory 是”用户驱动”——用户决定哪些信息进入画像、哪些不进。好处是精准（用户最了解自己），坏处是需要用户持续参与（画像可能过时）。
• DB-Agent-Memory 是”系统驱动”——系统从对话中自动提炼画像。好处是自动（不需要用户参与），坏处是可能有偏差（LLM 的理解可能不完全准确）。

4.3 Profile 的可编辑性为什么重要

Profile 可编辑在以下场景中特别有价值：

• 隐私控制：用户可以删除不想让 AI 知道的信息。比如用户曾经提过自己的健康状况，后来不想让 AI 在推荐时考虑这个因素——直接从 Profile 中删除即可。
• 精准纠正：如果 AI 记错了某个信息（把”喜欢 TypeScript”记成了”喜欢 JavaScript”），用户可以直接修正，而不是通过对话”纠正 AI”。
• 主动设置偏好：用户可以在第一次使用时就设置好偏好，而不需要等 AI 从多次对话中”学到”——这减少了冷启动问题。

DB-Agent-Memory 的 L3 画像目前不支持用户直接编辑——画像内容完全由系统提炼。从产品角度，增加用户编辑入口是一个低风险高价值的改进——既能提升用户控制感，又能通过用户编辑反馈提升画像质量。

5. 三流检索融合——BM25 + 向量 + 图遍历

supermemory 的检索架构是三流融合——同时利用 BM25 关键词检索、向量语义检索和 Memory Graph 图遍历，融合后在 sub-300ms 延迟内返回结果。

5.1 三条检索流

BM25（关键词检索）：传统的关键词匹配检索。查询”Rust 编程”时，BM25 找到包含”Rust”和”编程”关键词的记忆条目。BM25 的优势是精确——如果用户用了特定术语（函数名、API 名、产品名），BM25 能直接匹配。向量检索在精确术语匹配上反而不如 BM25——因为 embedding 把”Rust”映射到一个高维向量，可能和”C++”的向量接近，导致语义近似但术语不匹配的结果排在前面。

向量语义检索：查询文本被嵌入为向量，在向量数据库中做相似度搜索。向量检索的优势是”理解语义”——查询”如何处理并发”能找到”多线程同步策略”相关的记忆，即使两者没有共同的关键词。

Memory Graph 图遍历：supermemory 维护一个内建的 Memory Graph，节点是记忆条目，边是记忆之间的关联关系。图遍历从查询中识别的实体出发，沿着关联边获取相关的其他记忆。和 Graphiti / cognee 的图遍历类似，但 supermemory 的图结构更轻量——不需要外部图数据库，图数据存在 SQLite 中。

5.2 融合策略

三条流的检索结果通过加权融合合并：

最终分数 = w1 * BM25分数 + w2 * 向量分数 + w3 * 图遍历分数

权重 w1/w2/w3 可以根据查询类型动态调整——精确术语查询时增大 BM25 权重，语义查询时增大向量权重，关系查询时增大图遍历权重。

5.3 在七个项目中的位置

supermemory 是七个项目中唯一同时做了 BM25 + 向量 + 图的项目。DB-Agent-Memory 做了 BM25 + 向量但没有图，Graphiti 做了向量 + 图但没有 BM25。三流融合的覆盖面最广——任何类型的查询都能被至少一条流很好地处理。

但三流融合也有代价——每多一条流，就多一倍的索引维护开销。BM25 需要倒排索引，向量需要向量索引，图需要邻接表。三条流的索引更新需要保持一致性——一条新记忆保存后，三个索引都需要更新。如果某个索引更新失败，检索结果可能不一致。

5.4 sub-300ms 延迟

supermemory 宣称检索延迟在 300ms 以内。这个数字需要上下文理解：

• 三条流可以并行执行——BM25、向量、图遍历同时开始，结果合并只需要几毫秒
• supermemory 使用 SQLite 作为存储后端——本地文件访问，没有网络延迟
• 图遍历的图规模通常较小（个人用户的记忆图谱不会太大），遍历速度快

对比：Graphiti 的 Neo4j 网络往返 + Cross-Encoder 精排可能消耗 300-500ms；cognee 的三步管线需要串行执行 Retrieve → Rerank → Filter，可能消耗 500ms+。supermemory 的”三流并行 + 无精排”策略牺牲了检索精度换取了延迟优势。

6. MCP Server——标准化的记忆接入

supermemory 提供了 MCP（Model Context Protocol）Server，任何支持 MCP 的 AI 工具都可以直接调用 supermemory 的记忆能力。

6.1 MCP 是什么

MCP 是 Anthropic 在 2024 年底推出的协议，定义了 AI 工具和外部服务之间的标准化通信接口。一个 MCP Server 暴露一组”工具”（tools），AI 工具（如 Claude、Cursor、Windsurf）可以通过 MCP 协议调用这些工具。

类比：MCP 就像餐厅的统一外卖平台。各家餐厅（各种外部服务）在平台上注册自己的菜单（工具列表），用户（AI 工具）可以在一个平台上浏览和下单（调用工具），不需要分别下载每家餐厅的 app（单独集成每个服务）。

6.2 supermemory 的 MCP 工具

supermemory 的 MCP Server 暴露以下工具：

• save_memory：保存一条新记忆
• search_memory：搜索相关记忆
• get_profile：获取用户的完整画像
• update_profile：更新用户画像

AI 工具（比如 Claude Code）可以在对话中自动调用这些工具——用户不需要手动操作。当用户在 Claude 中说”帮我回忆一下上次我们讨论的数据库方案”，Claude 可以通过 MCP 调用 supermemory 的 search_memory 工具来获取相关记忆。

6.3 MCP 集成的价值

MCP 集成的价值在于”一次接入，处处可用”——supermemory 只需要实现一个 MCP Server，就能被所有支持 MCP 的 AI 工具使用，不需要为每个工具单独做集成。

这在当前的 AI 工具生态中特别有价值——用户可能同时使用 Claude Code（写后端）、Cursor（写前端）、ChatGPT（做研究），每个工具都有自己的记忆系统，互不相通。通过 MCP，supermemory 可以成为跨工具的统一记忆层——所有 AI 工具共享同一份用户记忆。

但 MCP 目前只定义了通信协议，没有定义记忆的数据模型。一个 MCP 记忆服务返回的 JSON 结构在不同 AI 工具中的解释可能不同。supermemory 返回的 Profile JSON 在 Claude 中被正确理解，在 Cursor 中可能只被当作普通文本——因为两个工具对”用户画像”的内部表示不同。

7. 局限性——技术深度有限

supermemory 的产品化路线带来了几个技术层面的局限。

7.1 没有四层金字塔

supermemory 的记忆组织只有两层——Profile（结构化画像）和 Memory（扁平记忆条目）。没有 DB-Agent-Memory 的 L0-L3 逐层提炼——无法从原始对话中提炼出摘要和画像，只能存储和检索原始事实。

这意味着 supermemory 不能做”信息压缩”——1000 条记忆就是 1000 条，检索时需要从 1000 条中找到相关的。DB-Agent-Memory 的金字塔把这 1000 条压缩成 10 个场景块和 1 个画像，检索时只需要在压缩后的数据中搜索，效率和信噪比都更高。

7.2 没有时序失效机制

supermemory 没有类似 Graphiti 的 invalid_at 时间戳。当用户信息变化时（搬家、换工作），旧记忆不会自动标记为过时——它仍然存在于记忆库中，检索时可能返回过时的信息。

Profile 的手动编辑部分弥补了这个缺陷——用户可以主动更新 Profile 中的过期信息。但 Memory 条目没有时间感知——如果你三年前保存了一篇关于 Python 2 的文章，今天搜索”Python”时它仍然可能返回。

7.3 没有 Ontology

supermemory 没有类似 cognee 的 Ontology 系统。记忆之间的关系是 Memory Graph 中的简单关联，没有领域特定的类型约束。这意味着 supermemory 不能做结构化的多跳推理——”小明的同事的公司在哪个城市”这类查询超出了它的能力范围。

7.4 TypeScript 项目的生态差异

supermemory 是 TypeScript 项目。这和 DB-Agent-Memory（TypeScript）在语言生态上直接竞争，和 mem0 / Letta / Graphiti / cognee / MemOS（Python）不同。

TypeScript 在 AI Agent 领域的生态比 Python 弱——大多数 AI 框架（LangChain、LlamaIndex、AutoGen）都是 Python 优先的。TypeScript 项目在集成这些框架时需要额外的适配工作。

但从产品角度，TypeScript 也有优势——Browser Extension 只能用 JavaScript/TypeScript 开发，supermemory 的前后端统一用 TypeScript 减少了开发成本。

7.5 Benchmark 第一不等于技术最强

supermemory 在三大 benchmark（LongMemEval / LoCoMo / ConvoMem）排名第一，但这不意味着它的技术架构最先进。Benchmark 评估的是端到端效果——用户提出记忆相关问题，系统返回正确答案的比例。

supermemory 的优势可能来自三个非架构因素：

1. 记忆来源更丰富——Browser Extension 捕获了对话之外的阅读内容，更多的信息 = 更高的召回率
2. 三流融合覆盖面广——BM25 + 向量 + 图，任何类型的查询都有至少一条流擅长处理
3. Profile 可编辑——用户主动设置的偏好比系统自动提取的更准确

这三个优势都是”产品层面”的，不是”算法层面”的。如果把 supermemory 的检索算法单独拿出来和 Graphiti 的两阶段 + Cross-Encoder 精排比较，supermemory 的精度可能不如 Graphiti。但 supermemory 的产品体验弥补了算法的不足。

8. 和 DB-Agent-Memory 的详细对比

8.1 产品化 vs 引擎化

两者的定位差异决定了它们在技术选型上的不同偏好。supermemory 优先考虑”好不好用”——一键保存、sub-300ms 响应、可编辑 Profile。DB-Agent-Memory 优先考虑”强不强”——四层提炼、MMD 注入优化、零依赖设计。

8.2 多入口 vs 对话入口

多入口是 supermemory 的核心竞争优势。对于个人 AI 助手场景，只从对话中获取信息严重限制了记忆的覆盖面——大多数人每天和 AI 的对话只占信息获取的一小部分。

DB-Agent-Memory 作为 Coding Agent 的记忆引擎，对话入口是合理的——Coding Agent 的信息来源就是编码对话。但如果 DB-Agent-Memory 要扩展到通用 AI 助手场景，增加更多记忆入口是需要考虑的。

8.3 TypeScript vs Python

两个项目都是 TypeScript，在 AI 生态中面临相同的挑战——Python 框架更成熟、模型绑定更方便。但 DB-Agent-Memory 作为引擎，Python 绑定可能是未来的需求——很多 AI 开发者更习惯用 Python。

9. 竞赛启发——产品思维可以借鉴

supermemory 对 DB-Agent-Memory 的启发不是技术层面的（两者架构差异太大），而是产品思维层面的。

9.1 记忆来源多样性

DB-Agent-Memory 目前只从对话中提取记忆。借鉴 supermemory 的多入口思路，可以考虑：

• 代码仓库入口：从项目的 README、.editorconfig、tsconfig.json 等配置文件中提取项目偏好
• Git 提交入口：从 commit message 和 PR 描述中提取项目决策和变更原因
• 文档入口：从项目的 API 文档、设计文档中提取技术栈和架构信息

这些入口不需要 Browser Extension 那样的用户交互——可以通过文件系统监听和 Git hook 自动触发。比如，当 .prettierrc 文件变更时，自动更新 L3 画像中的”代码格式偏好”。

9.2 Profile 可编辑性

DB-Agent-Memory 的 L3 画像目前不支持用户直接编辑。借鉴 supermemory 的 Profile API，可以考虑：

• 增加 L3 画像的编辑 API——用户可以主动修正画像中的错误信息
• 用户编辑行为可以作为反馈信号——如果用户频繁修正某个字段，说明系统提炼的准确率需要提升
• 编辑后的画像变更可以通过 MMD 的稳定区立即生效，而不需要等下一次批量提炼

9.3 MCP 集成

DB-Agent-Memory 已经有 MCP Adapter，但可以做得更深入——不仅暴露读写接口，还暴露画像查询和记忆统计接口。这能让 AI 工具更好地理解用户——不只是”记住用户说了什么”，而是”理解用户是什么样的人”。

10. 本章小结

回顾本章的核心要点：

• supermemory 是面向终端用户的”让 AI 记住你”产品，三大 benchmark 排名第一，走产品路线而非技术深度路线
• 设计哲学是”私人秘书类比”——不只听你说什么，还看你浏览什么；Browser Extension 是其他项目都没做的捕获入口
• Profile API 把记忆组织为结构化用户画像，用户可 curate/编辑——和 DB-Agent-Memory 的系统自动提炼画像形成对比
• 三流检索融合（BM25 + 向量 + 图遍历），sub-300ms 延迟——七个项目中覆盖面最广的检索策略
• MCP Server 提供标准化记忆接入——任何支持 MCP 的 AI 工具都可以调用
• 局限：技术深度有限（没有四层金字塔/时序失效/Ontology），TypeScript 项目，benchmark 第一更多来自产品优势而非算法创新
• 和 DB-Agent-Memory 对比：产品化 vs 引擎化、多入口 vs 对话入口、TypeScript vs TypeScript（同生态）
• 竞赛启发：产品思维可以借鉴——记忆来源多样性（代码仓库/Git 提交入口）、Profile 可编辑性、MCP 深度集成

下一章我们看 MemOS——抽象层次最高的记忆系统，把记忆类比为操作系统的一级资源。

导读目录：README.md 上一章：Ch12: cognee——本体论驱动的认知管线 下一章：Ch14: MemOS——记忆操作系统与 Dream Pipeline