夜雨聆风
AI Agent 记忆 圈子里一个叫 Supermemory 的开源项目很难绕开。
它不是又一个“把聊天记录塞进向量库”的小工具，而是把记忆、RAG、用户画像、连接器、MCP、自托管服务揉到一起，做成了一套面向 Agent 的上下文基础设施。
截至 7 月 23 日，supermemoryai/supermemory 在 GitHub 上已经有 2.85 万+ Stars 、 2400+ Forks ，最新 release server-v0.0.6 发布于 7 月 19 日 ，距现在约 4 天 。这个热度不算偶然，它踩中的正是 Agent 产品绕不开的一块硬骨头：上下文到底怎么长期保存、怎么召回、怎么随时间更新。
它想解决的不是“存下来”，而是“记得对”
很多 Agent 的第一版记忆系统，基本都是这个思路：把历史对话切块，做 embedding，用户问问题时向量搜索 Top-K，再塞回 prompt。
这套办法做知识库问答还行，但做“人的记忆”很容易翻车。
比如用户第一天说“我喜欢 Adidas”，一个月后说“这鞋质量太差，我换 Puma 了”。如果系统只按语义相似度找历史片段，下一次问“我该买什么鞋”，它可能还会把旧偏好捞出来。
Supermemory 的观点很明确： RAG 回答的是“我知道什么”，Memory 回答的是“我记得你现在是什么状态” 。这两个东西相关，但不是一回事。
记忆被拆成三层：文档、事实、画像
Supermemory 的接口看起来很轻：开发者可以直接 client.add() 写入聊天、文件、URL、HTML，也可以通过 /v4/conversations 写入结构化多轮对话。
但进入系统后，它不是只保存原文。
文档会先经过提取、分块、embedding 和索引，成为可搜索的 RAG 语料。随后进入一个叫 “dreaming” 的阶段，从内容里抽取事实、更新关系、建立边，并把一部分信息沉淀成 Profile。
这就形成了三个输出：
这里最有价值的是 Profile 这一层。
向量搜索需要你问对问题，才可能找回相关上下文。Profile 则是默认带在身边的上下文，比如称呼、语气偏好、所在项目、近期目标。这类信息不一定和当前问题语义相似，但它会影响每一次回答。
Supermemory 文档里把 Profile 分成 static 和 dynamic ：前者保存长期稳定事实，后者保存近期状态。官方给出的延迟目标是 约 50ms 级别，意思是它更像 prompt 前置上下文，而不是每轮都重做一次重搜索。
Graph memory 的重点在“事实会变”
Supermemory 的记忆不是一堆孤立卡片，而是一个事实图谱。
官方文档里把关系分成三类：
这个设计直接影响检索质量。
旧事实不一定要被物理删除，因为它仍然有审计和背景价值；但在回答“现在是什么情况”时，系统应该优先拿 isLatest 这类当前有效事实，而不是把新旧信息平铺到模型面前让它猜。
这也是 Supermemory 和普通向量库包装层的差别：它承认记忆有时间、有状态、有冲突，还会过期。
containerTag 是很朴素但关键的隔离边界
Supermemory 里所有记忆都可以挂在 containerTag 下。这个标签可以是用户、项目、团队、Agent，或者一个更细的层级结构，比如 org:acme:user:john。
它不是普通 metadata 过滤，而是更硬的命名空间边界。官方文档里写到，每个 container tag 会映射到独立的 vector namespace，请求、搜索、更新、删除都围绕这个边界进行。
这个设计对多租户 Agent 很实用。
个人助手可以按用户隔离，开发工具可以按 repo 或 project 隔离，企业产品可以按 organization / workspace 隔离。再配合 scoped API keys，调用方可以被限制在某些 container 内，避免“靠应用层 if 判断”来防止记忆串库。
它不是单点能力，而是在铺“上下文入口”
Supermemory 仓库的结构也能看出它的路线。
apps/web 是面向用户的 Web 应用；apps/mcp 是 MCP Server，支持 memory、recall、listMemories、whoAmI、memory-graph 等工具；packages/memory-graph 提供记忆图谱可视化组件；还有 Python/TypeScript SDK、Vercel AI SDK、OpenAI Agents SDK、LangGraph 等集成包。
它的野心不止于一个数据库 API，而是在抢 Agent 生态里的“上下文入口”。
MCP 这层尤其关键。对 Claude Desktop、Cursor、Windsurf、VS Code、Claude Code、OpenCode、OpenClaw 这类客户端来说，MCP 是最容易接入的记忆通道。Supermemory 把保存、召回、画像注入、项目隔离都封在 MCP 工具里，开发者不需要从零设计记忆协议。
自托管也是一个加分项。README 里提到它可以通过单 binary 或 npx supermemory local 本地运行，API 仍然保持一致；本地 embeddings 默认可用，也可以接 OpenAI、Gemini、Ollama。对不愿意把记忆数据交给第三方云服务的团队，这一点会直接影响能不能试用。
亮点很明显，边界也要看清
Supermemory 对外给出的 benchmark 很漂亮：LongMemEval、LoCoMo、ConvoMem 都标称 #1 ，README 里还写了 95% Recall@15 和 99.4% context reduction 。这些数字说明它在长程记忆评测上有明显野心。
但工程上不能只看数字。
第一，图谱记忆的质量高度依赖抽取模型。它能处理更新、推导、遗忘，但每一步都有误判空间。尤其是 derives 这类推断事实，用得好是理解力，用不好就是幻觉长期化。
第二，Profile 很适合作为默认上下文，但默认上下文也有污染风险。某个临时状态如果被错误归入长期画像，Agent 后面会持续带着偏见回答。
第三，containerTag 解决的是隔离边界，不自动解决治理问题。记忆什么时候写入、谁能审阅、哪些事实需要确认、如何回滚错误记忆，这些仍然要在产品层设计清楚。
所以它不是“接上就万事大吉”的万能记忆层，更像一套已经把关键问题抽象好的基础设施。
一个更现实的判断
Supermemory 最值得看的地方，不是它说自己比 RAG 更聪明，而是它把 Agent 记忆拆成了几个工程上可操作的部件：原始文档、抽取事实、时间关系、用户画像、隔离命名空间、MCP 接入、自托管部署。
这套组合拳很务实。
如果你在做 Agent 产品，最该借鉴的不是某个 API 名字，而是它背后的分层：不要把所有历史都当成 Top-K 文本片段，也不要把所有偏好都塞进一个手写 memory.md。短期上下文、长期事实、默认画像、可审计原文，应该是不同层。
记忆系统真正难的地方，从来不是“让 AI 记住更多”。
难的是：它什么时候该记，什么时候该忘，什么时候该相信，什么时候该承认自己不确定。
附链接
GitHub: https://github.com/supermemoryai/supermemory Docs: https://supermemory.ai/docs What is Supermemory: https://supermemory.ai/docs/overview/what-is-supermemory How Supermemory Works: https://supermemory.ai/docs/concepts/how-it-works Graph memory: https://supermemory.ai/docs/concepts/graph-memory Memory vs RAG: https://supermemory.ai/docs/concepts/memory-vs-rag User Profiles: https://supermemory.ai/docs/concepts/user-profiles Container Tags: https://supermemory.ai/docs/concepts/container-tags