调查研究-175 Supermemory：AI 时代的 Memory API，不只是另一个向量数据库

Supermemory：AI 时代的 Memory API，不只是另一个向量数据库

TL;DR

• 场景：长期使用的 AI 助手、编程 Agent、客服机器人、教育产品和企业知识系统，对跨时间、跨会话、跨工具的"上下文连续性"有刚性需求。
• 结论：Supermemory 的核心不是"又造一个向量数据库"，而是把 Memory、RAG、User Profile、Connectors、Graph、文件处理、Hybrid Search 和 MCP 集成收敛成一层"上下文基础设施"，代表 AI 应用架构里"Memory Layer"这一层的代表性实现。
• 产出：可落地的六层架构理解（接入/抽取/Graph/Profile/检索/集成）、个人助手 / 编程 Agent / 客服 / 教育 / 企业知识库五类典型场景、与自建向量库的差异分析、五条生产环境必须警惕的风险点，以及一个可参考的"用户 → 后端 → LLM + RAG + Supermemory"落地架构与 system prompt 骨架。

版本矩阵

文章正文

Supermemory：AI 时代的 Memory API，不只是另一个向量数据库

TL;DR

• Supermemory 的定位是 “Memory API for the AI era”，核心不是再造一个向量数据库，而是给 AI 应用提供长期上下文基础设施。
• RAG 解决的是"从文档里找相关材料"，Memory 解决的是"跨时间之后，系统还记不记得用户、项目、偏好和状态变化"。
• Supermemory 把 memory、RAG、user profile、connectors、文件处理、hybrid search、MCP/Claude Code/OpenCode 等集成放在同一层。
• 对长期使用的 AI 助手、编程 Agent、客服、教育产品和企业知识系统来说，Memory Layer 会越来越像标准基础设施。
• 但 Memory 不是魔法：隐私、租户隔离、旧记忆污染、事实冲突、中文效果、供应商锁定和评估体系都要认真处理。

为什么 AI 应用需要 Memory API

过去几年，AI 应用的主线一直围绕模型能力展开：更大的模型、更长的上下文窗口、更强的推理能力、更低的推理成本。很多开发者会默认认为，只要模型足够强、上下文足够长，AI 应用就会自然变聪明。

这个判断只对了一半。

模型能力解决的是"当前这一次对话如何回答得更好"。Memory 解决的是另一个问题：跨时间、跨会话、跨工具、跨项目之后，AI 是否还知道你是谁、你在做什么、你偏好什么、之前发生过什么。

这不是一个问题。

一个没有 Memory 的 AI 应用，本质上每次对话都是从零开始。它可能能读懂当前输入，也可能能通过 RAG 检索到相关文档，但它并不真正拥有持续的用户状态。

你今天告诉它你正在重构支付系统，明天告诉它你改用 Go 写服务，后天问它"继续帮我看昨天那个方案"，如果没有记忆层，它只能依赖当前上下文或聊天历史拼凑答案。

这就是 Supermemory 这类项目出现的背景。

Supermemory 官方把它定义为 Memory API for the AI era。它试图把 AI 应用里最难处理的一层抽象出来：长期记忆、短期记忆、用户画像、RAG、连接器、文件处理、上下文检索、矛盾更新和自动遗忘。

换句话说，它不是简单帮你存几段文本，也不是单纯封装一个向量数据库，而是在提供一套上下文基础设施。

Supermemory 是什么

Supermemory 是一个开源 Memory Engine 和应用，主要代码使用 TypeScript 编写，目标是让开发者通过 API 给 AI Agent 或 AI 产品接入持久记忆能力。

从开发者视角看，它最核心的能力可以概括为一句话：

你把用户对话、文档、链接、文件、代码、图片、音频、视频等内容交给 Supermemory，它负责抽取、索引、组织、更新和检索，然后在模型需要回答问题时，把最相关的上下文返回给你。

传统实现通常需要自己搭很多东西：embedding 模型、chunk 策略、向量数据库、metadata 过滤、rerank、用户隔离、过期信息处理、事实冲突处理、用户画像生成、连接器和文档解析。

Supermemory 试图把这些脏活累活收敛成几个应用层概念：add、search、profile、documents、connectors。

这里的关键不在代码短，而在抽象层级变了。

开发者不再直接面对"我该如何切块、如何向量化、如何召回、如何更新事实"这些底层问题，而是面对"我要给哪个用户、哪个项目、哪个组织维护一组可演化的上下文"。

这就是 Memory API 和普通 RAG API 的差别。

Memory 不是 RAG

很多开发者会把 Memory 和 RAG 混在一起。这个误区很常见。

RAG 的核心问题是：在一堆静态或半静态知识中，找到与当前问题最相关的内容，然后塞给模型。

Memory 的核心问题是：在一个持续变化的用户、项目、组织或任务状态中，理解哪些事实仍然有效，哪些事实已经过期，哪些事实互相补充，哪些事实互相矛盾。

举个例子。

用户第一天说：“我喜欢 Adidas 跑鞋。”

一个月后他说：“这双 Adidas 一个月就坏了，体验很差。”

又过一天他说：“我准备换 Puma。”

再过两周，他问 AI：“我应该买什么跑鞋？”

如果你只做普通 RAG，系统可能通过语义相似度找回"我喜欢 Adidas 跑鞋"，然后模型给出错误建议。因为向量检索擅长找相似文本，但它本身不理解时间变化、因果关系和状态更新。

Memory 系统要处理的是另一件事：Adidas 这个偏好是否已经失效？"坏了"是否导致偏好变化？"准备换 Puma"是否代表当前状态？旧信息是否应该保留为历史，而不是作为当前事实参与决策？

RAG 回答的是：“我知道哪些材料？”

Memory 回答的是：“我现在记得关于你的什么？”

所以 Supermemory 的价值不在于它能不能做向量检索，而在于它把 RAG 和 Memory 放在同一套上下文基础设施里。静态文档可以通过 RAG 检索，用户偏好和项目状态则通过 Memory 管理。真正的 AI 应用通常两者都需要。

Supermemory 的核心架构

可以把 Supermemory 理解成六层。

第一层是内容接入层。

它可以接收文本、对话、URL、PDF、Office 文档、Google Workspace 文件、Markdown、代码、图片、音频、视频、JSON、CSV 等内容。真实 AI 产品一旦进入用户场景，就一定会遇到多种内容来源：聊天记录、产品文档、会议纪要、邮件、代码仓库、工单、知识库、截图、录音、视频演示。Memory 系统如果只能处理纯文本，价值会被限制得很死。

第二层是抽取和索引层。

Supermemory 不是简单保存原文，而是要从输入内容中提取可记忆的信息。用户随口一句"哈哈"不应该进入长期记忆；用户说"我更喜欢 TypeScript，不太喜欢 Python 的动态类型风格"，这可能是长期偏好；用户说"我明天下午三点有个面试"，这是短期、带时间边界的事实。

第三层是 Graph Memory 层。

这是它区别于普通向量库的重要部分。新记忆可能更新旧记忆，也可能扩展旧记忆，也可能从多个事实中推导出新的上下文。

比如：

• “Alex 在 Google 做软件工程师。”
• “Alex 刚加入 Stripe 做 PM。”

后者应该 update 前者。旧事实可以保留为历史，但当前回答要优先使用最新事实。

再比如：

• “Alex 在 Stripe 做 PM。”
• “Alex 负责支付基础设施，带 5 人团队。”

这不是替换，而是 extends。新事实扩展了原有事实，使上下文更丰富。

第四层是用户画像层。

User Profile 是 Supermemory 的关键设计。传统 memory 系统通常依赖 search：你要先知道该问什么，才能查到什么。但用户提出的问题经常不会显式包含所有背景条件。

比如用户问：“帮我看看这个设计有没有问题。”

如果没有 profile，AI 只知道当前这句话。它不知道用户的技术水平，不知道用户最近在做哪个项目，不知道用户偏好详细分析还是短结论，不知道用户使用 Java、Go 还是 TypeScript。

User Profile 的作用是维护一个持续更新的"关于这个用户的上下文摘要"。它通常包含长期稳定的 static profile 和近期状态的 dynamic profile。前者记录长期偏好和背景，后者记录近期任务和动态。

第五层是检索层。

Supermemory 支持 hybrid search，也就是同时搜索 memories 和 document chunks。这个设计很合理，因为真实 AI 应用的问题往往不是纯 Memory，也不是纯 RAG。

用户问：“按照我之前的偏好，帮我推荐一个部署方案。”

这里至少需要两类上下文：一类是用户偏好，比如喜欢简单稳定还是极限性能；另一类是技术文档，比如不同部署方式的限制、项目 README、基础设施规范。只靠 Memory 不够，只靠 RAG 也不够。

第六层是集成层。

Supermemory 提供 JS/Python SDK，也有 AI SDK、OpenAI SDK、LangChain、LangGraph、Mastra、n8n、MCP、Claude Code、OpenCode 等集成方向。尤其是 MCP 值得注意。Memory 如果只能绑定某一个应用，价值会被削弱；真正的用户记忆应该可以跨工具存在。

哪些场景适合用 Supermemory

第一类是个人 AI 助手。

个人 AI 助手如果没有记忆，本质上只是一个会聊天的模型。真正有价值的助手必须知道用户的长期偏好、工作背景、当前项目、表达习惯、常用工具、过往决策。

这些信息如果每次都靠用户重复，体验会很差。如果全部塞进 system prompt，又会越来越臃肿。Memory API 的价值就在于动态维护和按需注入。

第二类是 AI 编程助手。

编程助手对 Memory 的需求很强。软件项目有明显上下文连续性：架构约束、目录结构、编码规范、技术债、历史决策、未完成任务、团队约定、部署方式、数据库结构、异常处理风格。

一个好用的 coding agent 不应该每次打开项目都重新理解一遍。它应该记得这个项目为什么选择这个框架、哪些模块不能随便改、某个 bug 上次排查到哪里、哪些测试容易失败、用户偏好直接改代码还是先给方案。

第三类是客户支持和销售助手。

客服机器人最常见的问题是缺乏连续性。用户上周已经反馈过一次问题，今天再来问，机器人如果还从标准 FAQ 开始，会非常糟糕。Memory 可以保存用户历史问题、产品版本、账号状态、偏好语言和之前的处理进展；RAG 负责检索政策文档、产品说明、故障排查手册。

第四类是教育产品。

教育类 AI 需要知道学生的学习历史、薄弱点、已掌握内容、偏好的讲解方式和近期目标。单纯 RAG 能回答知识点，但无法持续建模学生状态。

第五类是企业知识库和 Agent 平台。

企业内部数据分散在 Google Drive、Notion、GitHub、Gmail、OneDrive、网页、文档系统和会议记录里。Supermemory 的 connectors 和文件处理能力适合做统一上下文层。

但要注意：企业知识库不等于 Memory。企业制度、API 文档、产品手册更偏 RAG；员工偏好、项目进展、客户历史、工单状态更偏 Memory。架构上应该区分静态知识和动态记忆。

它和自己搭向量库有什么区别

自己搭向量库当然可以，而且很多场景值得自己搭。

典型技术栈是 PostgreSQL/pgvector 或 Qdrant/Milvus、embedding 模型、文档解析器、chunk 策略、metadata schema、rerank、query rewrite、权限过滤、定时同步、用户画像生成、记忆冲突处理、过期策略和评估集。

如果只是做简单知识库问答，自己搭 RAG 足够。

但如果要做"用户长期记忆"，复杂度会明显上升。你要处理的不是文档检索，而是状态演化：

• 如何判断一句话是否值得长期保存？
• 如何区分事实、偏好、临时计划、情绪表达和噪音？
• 如何处理"我以前喜欢 A，但现在不喜欢了"？
• 如何保存历史，但不让旧历史污染当前回答？
• 如何让不同工具共享同一套记忆？
• 如何让用户可以删除、隔离、导出自己的记忆？
• 如何评估 memory 是否真的提高回答质量？

Supermemory 的价值就是把这些问题产品化、API 化。它更像托管的 memory layer，而不是普通数据库。

需要警惕的问题

第一，不要把 Memory 神化。

Memory 不是让 AI 永远正确。它只是提高上下文连续性。错误记忆、过期记忆、隐私边界和召回偏差仍然会存在。

第二，隐私和数据合规是核心风险。

Memory 存的是用户长期上下文，敏感性比普通日志更高。用户偏好、工作内容、邮件、文档、聊天记录、项目代码都可能进入系统。接入之前必须明确数据范围、删除机制、用户授权、租户隔离、加密和审计。

第三，供应商锁定要评估。

如果 AI 产品把所有长期记忆都交给外部 Memory API，迁移成本会逐渐升高。尤其是 B 端产品，需要考虑数据导出、schema 可控性、灾备、可用性和成本模型。

第四，Memory 质量必须评估。

不能只看 demo。一个 memory 系统进入生产，需要评估它会不会记住不该记的内容，会不会忘掉该记的内容，能不能正确处理事实更新，能不能隔离多个相似用户或项目，是否会把旧偏好当成当前偏好，长期使用后是否上下文污染。

第五，中文场景需要单独验证。

项目文档和生态主要面向英文开发者。中文内容抽取、中文语义检索、多语言混合、中文代码注释、中文会议纪要、中文用户画像，都应该单独做测试。

一个可能的落地架构

假设要做一个面向程序员的 AI 助手，可以这样设计：

• 前端是 Web 或 IDE 插件。
• 后端维护用户、项目、会话、权限。
• 模型层使用 OpenAI、Anthropic、Qwen、DeepSeek 或本地模型。
• RAG 层负责项目文档、README、API 文档、代码片段。
• Memory 层接 Supermemory。

每次用户对话时，流程如下：

1. 根据 userId 和 projectId 构造 container tag。
2. 调用 profile 获取用户长期背景和近期动态。
3. 调用 search 做 hybrid search。
4. 把 profile、memories、documents 组合成上下文。
5. 调用 LLM 生成回答。
6. 从本轮交互中抽取重要新事实。
7. 把新 memory 写回 Supermemory。

系统 prompt 可以这样组织：

你是用户的 AI 编程助手。 用户长期背景： {profile.static} 用户近期状态： {profile.dynamic} 与当前问题相关的记忆： {memories} 与当前问题相关的文档： {documents} 回答时遵守用户偏好，并优先使用最新事实。 如果记忆之间存在冲突，指出冲突，不要武断合并。

这个架构的重点是：Memory 不是直接替代数据库，也不是替代业务系统。它应该作为 LLM 上下文层存在，负责让模型"知道该知道的东西"。

我的判断

Supermemory 是一个值得关注的 AI 基础设施项目。

它的价值不在于"又封装了一个向量库"，而在于它抓住了 AI Agent 产品化中的一个关键矛盾：模型越来越强，但应用仍然缺乏连续记忆；上下文窗口越来越长，但长期状态管理仍然混乱；RAG 越来越普及，但用户偏好、时间变化、事实冲突、动态画像并不能靠普通 RAG 解决。

从架构上看，Supermemory 把 Memory、RAG、Profile、Graph、Connectors、SDK 集成放在同一层，是一个比较完整的上下文工程方案。

从产品上看，它适合 AI 助手、编程 Agent、客服机器人、教育产品、企业知识库、个人知识管理、跨工具记忆等场景。

从风险上看，它仍然要面对隐私、锁定、中文效果、长期记忆污染、评估体系和生产稳定性问题。

所以，对这个项目最准确的判断是：

Supermemory 不应该被看作一个普通工具，而应该被看作 AI 应用架构里 “Memory Layer” 这一层的代表性实现。

如果你正在做一次性 AI 工具，它可能不是刚需。如果你正在做长期使用的 AI 助手、Agent 平台、编程助手、个人知识系统或企业上下文系统，它就非常值得研究。

AI 应用的下一阶段，不只是让模型更会回答，而是让系统真的记得、会更新、能遗忘、能区分历史与当前状态。

参考资料

• Supermemory 官方网站
• Supermemory GitHub
• Supermemory Documentation

错误速查卡

作者：武子康的个人博客