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

SupermemoryAI 时代的 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 骨架。版本矩阵模块 / 能力状态说明Memory APIadd / search / profile / documents / connectors✅ 已验证官方文档 docs.supermemory.ai 提供完整端点2026 年 6 月仍在迭代Hybrid SearchMemory Document Chunks 同查✅ 已验证官方 README 明确支持 RAG Memory in a single queryUser Profilestatic dynamic✅ 已验证官方描述“Auto-maintained user context — stable facts recent activity. One call, ~50ms”Graph Memoryupdate / extends 关系✅ 已验证官方强调 “handles temporal changes, contradictions, and automatic forgetting”ConnectorsNotion / Google Drive / GitHub / Gmail 等✅ 已验证官方与第三方文章均列出多源连接器生态MCP 集成含 Claude Code / OpenCode✅ 已验证官方 app 展示 “Claude Code / OpenCode / Hermes” 等入口CLAUDE.md 出现 “supermemory MCP 4.0” 记录JS / Python / AI SDK / LangChain / LangGraph / Mastra / n8n 集成✅ 已验证官方 README 与生态文档明确列出LongMemEval 81.6%、sub-300ms 召回⚠️ 待独立复现来自第三方测评文章cloud.tencent.com建议自行跑 benchmark生产级隐私 / 多租户隔离 / 审计⚠️ 待项目方文档确认涉及企业合规建议在 PoC 阶段拉测试租户验证中文内容抽取 / 中文 RAG 效果⚠️ 待项目方文档确认项目生态以英文为主README 含 zh-CN 版本但内容深度需自行评估文章正文SupermemoryAI 时代的 Memory API不只是另一个向量数据库TL;DRSupermemory 的定位是 “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你要先知道该问什么才能查到什么。但用户提出的问题经常不会显式包含所有背景条件。比如用户问“帮我看看这个设计有没有问题。”如果没有 profileAI 只知道当前这句话。它不知道用户的技术水平不知道用户最近在做哪个项目不知道用户偏好详细分析还是短结论不知道用户使用 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。每次用户对话时流程如下根据 userId 和 projectId 构造 container tag。调用 profile 获取用户长期背景和近期动态。调用 search 做 hybrid search。把 profile、memories、documents 组合成上下文。调用 LLM 生成回答。从本轮交互中抽取重要新事实。把新 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 GitHubSupermemory Documentation错误速查卡症状根因定位修复推荐/回答使用了过时的旧偏好如 AdidasMemory 没有处理偏好更新关系把历史偏好当成当前偏好检索结果里同时出现新/旧两条记忆时看 model 是否被旧记录带偏在 prompt 里显式要求优先使用最新事实让 Supermemory 走 update 关系而不是平铺记忆用户问帮我看看这个设计有没有问题时答得很泛缺少 User Profile模型不知道用户身份、项目、偏好检索请求是否只调了 search没调 profile流程中先profile拿 static dynamic再做 hybrid search用户上周反馈的问题客服机器人还要重新解释Memory 没接住跨会话状态每次都从 FAQ 起步是否调用了 add / memory.write 把历史会话写入关键节点反馈、进展、偏好显式写入 memory用 container tag 按用户隔离企业内部知识答错或答不全把企业知识库完全当成 Memory 处理文档更新没体现输入来源是 Notion / Drive 文档还是对话/偏好区分 RAG文档知识和 Memory人/项目状态用 hybrid search 联合召回项目代码改了三轮后AI 还按老架构提建议Coding agent 每次冷启动是否在每次会话都重新做 profile memory 召回把 userId projectId 作为 container tag每次进会话先拉 profile hybrid searchMemory 把哈哈好的这类噪音也写进去了抽取层没区分事实 / 偏好 / 临时计划 / 噪音看写入的 memory 内容是否包含无意义短句接入层做轻量预过滤写前让 LLM 做是否值得长期保留判定多个相似用户之间记忆串了缺少 container tag 或租户隔离写 / 读请求是否带 userId / projectId / orgId所有 API 调用强制带 container tag并在后端做硬隔离旧偏好已迁移的事实反复污染回答历史记忆没被标记为历史新事实没走 update看同一概念是否同时存在多条 active 记忆明确 update / extends 关系写入时让 Supermemory 处理冲突用户要求忘记 / 删除某条记忆但系统还在用没有删除 / 隔离接口或删除接口未生效走删除 API 后再 search看是否还能召回接入 delete API 用户可见的我的记忆管理面板迁移到自建 / 另一家 Memory 方案时数据导出困难早期把所有数据完全托管给外部 API评估 schema 导出能力、API 兼容性、灾备关键记忆落库前在自己侧做一份镜像定期导出做灾备中文场景下记忆抽取或检索效果差项目生态和抽取器以英文为主单独跑中文语料的抽取 / 检索 / 评测中文语料独立做 benchmark必要时在抽取前加中文预处理或自建 embedding 通道Memory 召回的上下文把上下文窗口撑爆一次性塞入过多 memories documents看 prompt 长度和召回数量召回后做 rerank 截断用 profile 做摘要压缩长期使用后 memory 库越来越大延迟变高缺少过期 / 遗忘策略和分层存储监控 memory 数量、检索 P95 延迟设计 TTL、显式 forget 动作冷热分层老记忆降级为低频存储评估时无法判断Memory 真的让回答变好了没有 baseline 和评估集同一组问题开/关 Memory 各跑一遍构造 LongMemEval 风格的评估集跟踪 recallK、事实更新准确率、冲突处理等指标prompt 里把 memory 直接当事实用忽视冲突没要求模型指出冲突回答中遇到多版本事实时是否被静默合并在 system prompt 里加 “If memories conflict, point it out, do not silently merge”作者武子康的个人博客