Supermemory 设计、品味与借鉴

Supermemory 设计、品味与借鉴调研对象https://github.com/supermemoryai/supermemory/tree/main核心判断Supermemory 开源仓库没有完整暴露记忆引擎的算法实现。它最值得学习的不是 embedding、抽取、冲突判断这些内部细节而是它把“长期记忆”设计成了一套可操作、可复现、可修正的产品协议。一句话记住长期记忆不是把内容存起来而是保证下一次相关场景里它会以正确形式重新出现。更好理解的方式记忆飞轮Supermemory 可以理解成一个“记忆飞轮”而不是一个向量库。输入内容 - 绑定边界 - 提炼成记忆 - 下一次自动注入 - 使用后继续沉淀 - 过期、更新、遗忘 - 用图谱解释来源这比普通 RAG 更深一层。RAG 解决的是“资料在哪里”。Memory 解决的是“什么应该在未来再次影响我”。它真正提供的操作1.remember不是保存文本而是保存未来上下文Supermemory 写入时不只是接收content还强调containerTag这条记忆属于谁、哪个项目、哪个 Agent。entityContext系统应该用什么语境理解这段内容。metadata来源、类型、补充信息。可借鉴点remember({content,containerTag,entityContext,metadata,});深层观点没有边界的记忆只是堆积有边界的记忆才会成为长期状态。2.profile比搜索更重要普通搜索返回片段profile返回“适合注入模型的上下文”。它通常包含稳定偏好。长期事实。近期变化。与当前问题相关的记忆。这是真正有产品感的地方。因为长期记忆不能依赖模型临时想起来要不要搜索而应该在回答前自动进入上下文。可借鉴接口profile(containerTag, query?) - prompt-ready context深层观点真正可靠的记忆不是“可被查到”而是“该出现时会出现”。3.inject把记忆变成默认前提Supermemory 的 SDK wrapper 会在模型调用前做三件事取 profile/search context - 注入 system prompt - 再调用模型这比提供一个searchMemorytool 更稳。Tool 需要模型主动调用注入则把关键记忆变成回答的默认前提。源码里现在的插入方式比较直接Vercel AI SDK wrapper如果已有 system prompt就把 memories 追加到 system 内容后面如果没有就新建一个 system message 放在最前面。OpenAI Chat wrapper同样追加到已有 system prompt或者创建新的 system message。OpenAI Responses wrapper把 memories 追加到instructions。Python / Agent Framework wrapper逻辑类似都是优先修改 system message。这说明 Supermemory 的产品判断是对的记忆应该在回答前出现而不是等模型主动调用工具。但工程上也有一个问题如果每一轮都把动态 memory 追加进 system promptsystem 前缀就会频繁变化可能降低 LLM 的 prefix cache 命中。更理想的插入协议应该是稳定 system 指令 - 稳定格式的 memory block - 当前问题相关的短记忆 - 用户问题关键不是“不要注入”而是“低扰动注入”稳定 system 指令放在最前面尽量不变。memory block 的标题、顺序、格式保持稳定。动态 search memory 尽量短只放和当前问题相关的内容。不要在 memory block 里加入时间戳、随机摘要、顺序不稳定的列表。如果模型或框架支持独立 context / tool result / cached prompt segment优先把动态记忆放到不会破坏稳定前缀的位置。深层观点长期记忆要成为思考环境而不是可选工具但好的思考环境应该稳定不能每轮都重写模型的前缀。4.saveConversation形成闭环模型回答后conversation 会被异步保存回记忆系统。历史记忆影响当前回答 当前对话沉淀为未来记忆这就是记忆飞轮的闭环。这里的好设计是异步保存记忆服务失败时不阻塞主回答但仍尽量沉淀长期状态。5.update / forget防止记忆变脏长期记忆最大的问题不是记不住而是越记越脏。这里容易误解下面这些不是说每次recall都会完整返回这些字段。它们主要是底层MemoryEntry的状态字段表示 Supermemory 的记忆模型支持“版本链”和“关系图”。profile往往只返回可注入 prompt 的文本搜索结果可能带version和context.parents / context.children图谱和文档接口才更接近完整 memory 对象。Supermemory 的 schema 里保留了这些语义isLatestisForgottenforgetAfterparentMemoryIdrootMemoryIdmemoryRelations可以用一个例子理解m1: 用户正在做 React 项目 m2: 用户现在主要在做 Agent 记忆系统 m2.parentMemoryId m1 m2.rootMemoryId m1 m2.memoryRelations { m1: updates } m2.isLatest true m1.isLatest falseparentMemoryId表示“这条记忆直接接在哪条旧记忆后面”。它像链表里的上一环用来形成m1 - m2 - m3这样的版本链。rootMemoryId表示“这一整条版本链最早从哪条记忆开始”。不管当前是m2还是m3它都能指回最初的m1。memoryRelations表示“这条记忆和其他记忆是什么关系”。目前关系类型主要有updates新事实更新旧事实例如“用户以前做 React现在做 Agent 记忆系统”。extends新事实补充旧事实例如“用户做 Agent 记忆系统”之后补充“重点关注 prefix cache”。derives新事实从某段内容推导出来例如从会议记录推导出“用户重视长期记忆设计”。这说明它把记忆看成会变化、会互相修正的状态而不是静态文本。深层观点没有遗忘机制的长期记忆最后会变成长期污染。6.memory graph让记忆可解释图谱不是炫技而是信任机制。它让用户能看到这条记忆从哪里来。它更新了哪条旧记忆。它扩展了什么事实。它是否仍然有效。深层观点不能解释来源的记忆很难被长期信任。最值得学的设计锚点containerTagcontainerTag是 Supermemory 最关键的抽象。它同时是状态边界记忆属于哪个用户、项目或 Agent。权限边界谁能读写这批记忆。产品边界记忆如何被组织和复用。可以这样理解没有 containerTag记忆是一堆全局文本。 有 containerTag记忆成为可控的长期状态。如果我们做自己的系统第一优先级不是先做复杂图谱而是先确定这个边界字段。代价与不足这些不足是借鉴时必须看清的边界。自动注入会放大脏记忆风险。profile / inject让记忆“该出现时出现”但旧事实、错误偏好、过度个性化也会更稳定地污染回答。containerTag是好边界也是高要求。边界划错记忆就会串场边界切太碎长期记忆又无法复用。图谱解释来源不等于证明正确。它能提升信任感但不能替代记忆质量评估。最缺的是评估闭环什么叫该出现时出现什么叫不该出现时不出现这比 embedding 命中率更难测。所以 Supermemory 值得学的是“长期记忆协议”不是直接相信它已经解决了长期记忆质量。最终借鉴Supermemory 的真正品味是它把 memory 从“检索能力”升级成“长期状态管理”。如果要借鉴只需要先抓住这条主线长期记忆 边界 语境 自动再出现 更新遗忘 可解释这也是写文档、做产品、做 Agent 记忆都共通的原则深刻不是信息更多而是读者或系统在未来遇到相关场景时还能重新调出那个关键判断。参考源码https://github.com/supermemoryai/supermemory/blob/main/apps/mcp/src/server.tshttps://github.com/supermemoryai/supermemory/blob/main/packages/tools/src/shared/memory-client.tshttps://github.com/supermemoryai/supermemory/blob/main/packages/tools/src/vercel/memory-prompt.tshttps://github.com/supermemoryai/supermemory/blob/main/packages/tools/src/openai/middleware.tshttps://github.com/supermemoryai/supermemory/blob/main/packages/validation/schemas.tshttps://github.com/supermemoryai/supermemory/blob/main/packages/memory-graph/src/hooks/use-graph-data.ts