从聊完就忘到动态画像Supermemory如何处理信息冲突与过期记忆【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory大模型最尴尬的时刻不是答错题而是前一秒你还告诉它我上周刚从北京搬到深圳后一秒它就热情推荐你北京本地的餐馆。上下文窗口耗尽后一切归零——这就是困扰整个 Agent 生态的AI 失忆症。围绕这个痛点社区在过去一年里涌现了大量记忆层项目。而 Supermemory 之所以能从 Mem0、Zep 等竞品中杀出靠的不是把对话丢进向量库做相似度检索而是把记忆当作一个有时间维度、有矛盾消解、有自动遗忘的动态系统来建模。官方在 LongMemEval、LoCoMo、ConvoMem 三大记忆基准上均排名第一LongMemEval 上达到 95% 的 Recall15同时只增加约 720 token 上下文99.4% 的上下文压缩。本文不重复官方宣传而是回到仓库源码与文档拆解它回答的三个核心问题对话如何变成可查询的结构化事实、信息冲突与过期记忆如何被裁决、动态画像如何在 Agent 场景真正落地。为什么把记忆做成 RAG注定失败先看文档 memory-vs-rag.mdx 里那个著名的鞋类案例Day 1: I love Adidas sneakers Day 30: My Adidas broke after a month, terrible quality Day 31: Im switching to Puma Day 45: What sneakers should I buy?如果走纯 RAG 路线向量检索命中与 query 语义最接近的文本大概率返回我爱 AdidasAgent 于是推荐 Adidas——它读到了最相似的句子却完全错过时间线偏好已失效和因果链坏了→失望→换品牌。RAG 的本质是无状态检索一份 Python 文档对所有人都是同一份文档它不追踪这条事实什么时候变成真的、什么时候失效。而记忆的本质是有状态理解它需要回答关于这个用户什么才是此刻为真。这正是 README.md 反复强调的一句话——Memory is not RAG两者服务于不同目的RAG 回答我知道什么记忆回答我记得关于你的什么。Supermemory 的做法不是二选一而是在同一个命名空间namespace里同时维护两条通路文档块chunks负责知识兜底供 RAG/SuperRAG 检索提取出的记忆memories进入一张带时间戳的图谱。默认的searchMode: hybrid把两者合并返回见 search.mdx。对话如何变成可查询的记忆提取流水线与做梦阶段Supermemory 没有提供直接写记忆的 API——在 v5 里你只能摄入文档记忆由引擎自动提取见 memory-operations.mdx 的说明v5 has no direct memory-create route. Ingest a document instead and Supermemory extracts the memories from it。一次摄入会经历完整的流水线queued → extracting → chunking → embedding → indexing → done见 how-it-works.mdx。文本、URL、PDFOCR、图片视觉描述、音视频转写、代码AST 感知分块都能进多模态入口见 content-types.mdx。关键在done之后的第二阶段——dreaming做梦。文档分块只保证可检索而记忆图谱里的事实、更新与推导来自 dreaming 阶段内容被交给记忆模型与已有知识合并、编排、关联。两种模式模式行为适用dynamic默认相关文档被分组记忆从连贯单元中形成而非一次孤立写入生产 Agent、连接器、持续会话instant该文档单独立即做梦处理完即可检索/画像演示、快速上手、现在就要图谱这解释了为什么官方反复建议真实应用里对话要用稳定的id提交把整个会话作为一篇文档让引擎看到完整的多轮上下文而不是把每句话当作独立记忆塞进去。quickstart 里那个东京团建的例子最直观——用户从头到尾没有说过一句Sarah 是我的产品副总裁图却是这么连出来的见 quickstart.mdxuser: Just got back from Tokyo — the team offsite went great. user: Sarah presented the Q3 roadmap at the offsite. user: Shes being promoted to VP of Product. user: I need a gift idea for my VP of Product.搜索引擎返回的记忆结果带included.related关联边Sarah is being promoted to VP of Product的父节点是Sarah presented the Q3 roadmap at the Tokyo offsite子节点是User needs a gift idea for their VP of Product, Sarah。一个从未被显式陈述的关系由图谱从散落的会话中推导出来。冲突检测与过期淘汰Updates、Extends、Derives 与遗忘记忆系统最难的不是存进去而是改过来。Supermemory 图谱为每条新事实定义了三种关系见 graph-memory.mdxUpdates更新/矛盾裁决新事实替换旧事实成为检索时的当前真相历史保留用于审计。isLatest字段保证检索永远命中最新状态——Alex works at Google as a software engineer 被 Alex just started at Stripe as a PM 覆盖搜索Alex 在哪工作返回 StripeGoogle 那条沉入历史。Extends丰富新事实为旧事实补充细节而不否定它两者同时有效。Derives推导引擎从跨记忆的模式中推断出你从未在任何一处明说的事实。例如Alex 是 Stripe 的 PM Alex 频繁讨论支付 API 与反欺诈 → 推导出Alex 很可能在做 Stripe 核心支付产品。针对推导inference系统有明确的安全阀推导事实默认标记isInference: true并在搜索中被降权直到有人确认memory-review.mdx。评审队列按parentCount支撑来源数排序提供approve转为正式事实/decline直接遗忘/undo三个动作接口设计成可做滑动卡片评审的形态。过期淘汰则分三层时间失效——临时性事实自动过期exam tomorrow、meeting at 3pm today 这类带时间锚点的事实日期一过即失效矛盾覆盖——更新关系的存在让当前真相始终由最新事实定义噪声过滤——闲聊、无意义的寒暄不容易沉淀为持久记忆。记忆本身也分类型管理事实持久直到被更新、偏好随重复而强化、情节除非重要否则衰减——不同生命周期对应不同遗忘策略这正是 README.md 里 handles temporal changes, contradictions, and automatic forgetting 一句的完整展开。而显式的遗忘控制同样被做成产品能力memories.forget按 ID 软删除从搜索排除但保留memories.forgetMatching按语义批量删除forget everything about Project Titan并且强制要求先dryRun: true预览再执行——批量破坏性操作不允许盲跑。在 MCP 侧add_memory工具的action: forget让 Agent 自己就能在对话中说忘掉这个见 add-memory.ts。动态画像Agent 场景里不用搜就知道的上下文搜索再多也有一个结构性缺陷你必须知道要问什么。用户偏好里最有价值的部分——名字、时区、语气偏好、技术栈——往往与任何具体查询都没有语义关联。文档 user-profiles.mdx 里的例子很说明问题用户入职时说过一句 Call me Dhravya, not my full first name。之后无论他问帮我规划去日本的旅行还是review 这个 PR这条事实都不会出现在搜索结果里——因为向量上它与这些查询毫无相似度。但它应该永远在场。Supermemory 对此的答案是每个命名空间自动维护一份画像profile一次调用、约 50ms 返回分成两段static静态长期稳定事实——Sarah is a senior software engineer at TechCorp、prefers technical docs over video tutorialsdynamic动态近期状态与临时上下文——Sarah is migrating the payment service to microservices、debugging a memory leak in auth service。const { profile } await supermemory.profile(user_123); // profile.static → [Senior engineer at Acme, Prefers dark mode, Uses Vim] // profile.dynamic → [Working on auth migration, Debugging rate limits]这份画像和搜索是互补关系而非替代搜索回答与我这个问题相关的是什么画像回答这个人是谁无论问什么。在每轮对话的系统提示词里注入画像Agent 就有了随叫随到的基础身份而不是每次都先付出一次搜索往返的延迟。文档里的对比图user-profiles-vs-search.png把这个差别画得很清楚搜索是先往返再补上下文画像是免费随行。落地到工程层ai-sdk.mdx 提供了三档模式Profile 模式注入完整画像Query 模式基于用户消息做记忆搜索Full 模式两者叠加。import { withSupermemory } from supermemory/tools/ai-sdk; const model withSupermemory(openai(gpt-5), { namespace: user-123, id: conversation-456, // 同一会话保持同一 id形成连贯文档 mode: full, });而 MCP 侧把这一整套收敛成三个工具search_memory按查询找记忆、get_profile取静态动态画像、add_memory保存/遗忘——分别对应 search-memory.ts、get-profile.ts 与 add-memory.ts。这也是社区教程里opencode-supermemory 插件让编程助手跨会话记住项目偏好、构建命令的实现底座。一个生产级 Agent 的典型回路是读画像 → 搜索相关记忆 → 生成回答 → 把这一轮写回同一个会话文档。quickstart 给出的 harness 示例把整个过程压缩成了三段代码profile()拿基础身份search(question, memories)拿相关事实search(question, chunks)拿知识兜底最后把user/assistant轮次追加回稳定的id。这个读-生成-写回闭环就是记忆系统在 Agent 里真正起作用的形态。小结记忆是状态管理不是检索优化Supermemory 对整个 AI 记忆赛道最大的方法论贡献是坚持把记忆当作带时序的状态机来管理提取层把自由文本变成原子化事实图谱层用 Updates/Extends/Derives 三种关系处理矛盾与推导遗忘层用时间失效、矛盾覆盖、噪声过滤完成淘汰画像层则把当前真相压缩成一次 50ms 的调用。配合isLatest、isInference降权、dryRun语义删除这些工程细节它试图回答的不是如何存更多而是如何让记忆始终为真。对开发者而言接入这套系统的成本确实很低——一行supermemory.add()、一个 namespace、一个 profile 调用。但真正值得借鉴的是它的设计取舍稳定id保证会话连贯、dynamic做梦保证图谱质量、画像与搜索分治保证既快又全。当你的 Agent 下次再面对用户上个月说喜欢 A这个月说换 B的场景时希望你想到的不是换一个更大的向量库而是——记忆系统该有的样子是知道 A 已经过期了。【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从“聊完就忘“到动态画像：Supermemory如何处理信息冲突与过期记忆
从聊完就忘到动态画像Supermemory如何处理信息冲突与过期记忆【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory大模型最尴尬的时刻不是答错题而是前一秒你还告诉它我上周刚从北京搬到深圳后一秒它就热情推荐你北京本地的餐馆。上下文窗口耗尽后一切归零——这就是困扰整个 Agent 生态的AI 失忆症。围绕这个痛点社区在过去一年里涌现了大量记忆层项目。而 Supermemory 之所以能从 Mem0、Zep 等竞品中杀出靠的不是把对话丢进向量库做相似度检索而是把记忆当作一个有时间维度、有矛盾消解、有自动遗忘的动态系统来建模。官方在 LongMemEval、LoCoMo、ConvoMem 三大记忆基准上均排名第一LongMemEval 上达到 95% 的 Recall15同时只增加约 720 token 上下文99.4% 的上下文压缩。本文不重复官方宣传而是回到仓库源码与文档拆解它回答的三个核心问题对话如何变成可查询的结构化事实、信息冲突与过期记忆如何被裁决、动态画像如何在 Agent 场景真正落地。为什么把记忆做成 RAG注定失败先看文档 memory-vs-rag.mdx 里那个著名的鞋类案例Day 1: I love Adidas sneakers Day 30: My Adidas broke after a month, terrible quality Day 31: Im switching to Puma Day 45: What sneakers should I buy?如果走纯 RAG 路线向量检索命中与 query 语义最接近的文本大概率返回我爱 AdidasAgent 于是推荐 Adidas——它读到了最相似的句子却完全错过时间线偏好已失效和因果链坏了→失望→换品牌。RAG 的本质是无状态检索一份 Python 文档对所有人都是同一份文档它不追踪这条事实什么时候变成真的、什么时候失效。而记忆的本质是有状态理解它需要回答关于这个用户什么才是此刻为真。这正是 README.md 反复强调的一句话——Memory is not RAG两者服务于不同目的RAG 回答我知道什么记忆回答我记得关于你的什么。Supermemory 的做法不是二选一而是在同一个命名空间namespace里同时维护两条通路文档块chunks负责知识兜底供 RAG/SuperRAG 检索提取出的记忆memories进入一张带时间戳的图谱。默认的searchMode: hybrid把两者合并返回见 search.mdx。对话如何变成可查询的记忆提取流水线与做梦阶段Supermemory 没有提供直接写记忆的 API——在 v5 里你只能摄入文档记忆由引擎自动提取见 memory-operations.mdx 的说明v5 has no direct memory-create route. Ingest a document instead and Supermemory extracts the memories from it。一次摄入会经历完整的流水线queued → extracting → chunking → embedding → indexing → done见 how-it-works.mdx。文本、URL、PDFOCR、图片视觉描述、音视频转写、代码AST 感知分块都能进多模态入口见 content-types.mdx。关键在done之后的第二阶段——dreaming做梦。文档分块只保证可检索而记忆图谱里的事实、更新与推导来自 dreaming 阶段内容被交给记忆模型与已有知识合并、编排、关联。两种模式模式行为适用dynamic默认相关文档被分组记忆从连贯单元中形成而非一次孤立写入生产 Agent、连接器、持续会话instant该文档单独立即做梦处理完即可检索/画像演示、快速上手、现在就要图谱这解释了为什么官方反复建议真实应用里对话要用稳定的id提交把整个会话作为一篇文档让引擎看到完整的多轮上下文而不是把每句话当作独立记忆塞进去。quickstart 里那个东京团建的例子最直观——用户从头到尾没有说过一句Sarah 是我的产品副总裁图却是这么连出来的见 quickstart.mdxuser: Just got back from Tokyo — the team offsite went great. user: Sarah presented the Q3 roadmap at the offsite. user: Shes being promoted to VP of Product. user: I need a gift idea for my VP of Product.搜索引擎返回的记忆结果带included.related关联边Sarah is being promoted to VP of Product的父节点是Sarah presented the Q3 roadmap at the Tokyo offsite子节点是User needs a gift idea for their VP of Product, Sarah。一个从未被显式陈述的关系由图谱从散落的会话中推导出来。冲突检测与过期淘汰Updates、Extends、Derives 与遗忘记忆系统最难的不是存进去而是改过来。Supermemory 图谱为每条新事实定义了三种关系见 graph-memory.mdxUpdates更新/矛盾裁决新事实替换旧事实成为检索时的当前真相历史保留用于审计。isLatest字段保证检索永远命中最新状态——Alex works at Google as a software engineer 被 Alex just started at Stripe as a PM 覆盖搜索Alex 在哪工作返回 StripeGoogle 那条沉入历史。Extends丰富新事实为旧事实补充细节而不否定它两者同时有效。Derives推导引擎从跨记忆的模式中推断出你从未在任何一处明说的事实。例如Alex 是 Stripe 的 PM Alex 频繁讨论支付 API 与反欺诈 → 推导出Alex 很可能在做 Stripe 核心支付产品。针对推导inference系统有明确的安全阀推导事实默认标记isInference: true并在搜索中被降权直到有人确认memory-review.mdx。评审队列按parentCount支撑来源数排序提供approve转为正式事实/decline直接遗忘/undo三个动作接口设计成可做滑动卡片评审的形态。过期淘汰则分三层时间失效——临时性事实自动过期exam tomorrow、meeting at 3pm today 这类带时间锚点的事实日期一过即失效矛盾覆盖——更新关系的存在让当前真相始终由最新事实定义噪声过滤——闲聊、无意义的寒暄不容易沉淀为持久记忆。记忆本身也分类型管理事实持久直到被更新、偏好随重复而强化、情节除非重要否则衰减——不同生命周期对应不同遗忘策略这正是 README.md 里 handles temporal changes, contradictions, and automatic forgetting 一句的完整展开。而显式的遗忘控制同样被做成产品能力memories.forget按 ID 软删除从搜索排除但保留memories.forgetMatching按语义批量删除forget everything about Project Titan并且强制要求先dryRun: true预览再执行——批量破坏性操作不允许盲跑。在 MCP 侧add_memory工具的action: forget让 Agent 自己就能在对话中说忘掉这个见 add-memory.ts。动态画像Agent 场景里不用搜就知道的上下文搜索再多也有一个结构性缺陷你必须知道要问什么。用户偏好里最有价值的部分——名字、时区、语气偏好、技术栈——往往与任何具体查询都没有语义关联。文档 user-profiles.mdx 里的例子很说明问题用户入职时说过一句 Call me Dhravya, not my full first name。之后无论他问帮我规划去日本的旅行还是review 这个 PR这条事实都不会出现在搜索结果里——因为向量上它与这些查询毫无相似度。但它应该永远在场。Supermemory 对此的答案是每个命名空间自动维护一份画像profile一次调用、约 50ms 返回分成两段static静态长期稳定事实——Sarah is a senior software engineer at TechCorp、prefers technical docs over video tutorialsdynamic动态近期状态与临时上下文——Sarah is migrating the payment service to microservices、debugging a memory leak in auth service。const { profile } await supermemory.profile(user_123); // profile.static → [Senior engineer at Acme, Prefers dark mode, Uses Vim] // profile.dynamic → [Working on auth migration, Debugging rate limits]这份画像和搜索是互补关系而非替代搜索回答与我这个问题相关的是什么画像回答这个人是谁无论问什么。在每轮对话的系统提示词里注入画像Agent 就有了随叫随到的基础身份而不是每次都先付出一次搜索往返的延迟。文档里的对比图user-profiles-vs-search.png把这个差别画得很清楚搜索是先往返再补上下文画像是免费随行。落地到工程层ai-sdk.mdx 提供了三档模式Profile 模式注入完整画像Query 模式基于用户消息做记忆搜索Full 模式两者叠加。import { withSupermemory } from supermemory/tools/ai-sdk; const model withSupermemory(openai(gpt-5), { namespace: user-123, id: conversation-456, // 同一会话保持同一 id形成连贯文档 mode: full, });而 MCP 侧把这一整套收敛成三个工具search_memory按查询找记忆、get_profile取静态动态画像、add_memory保存/遗忘——分别对应 search-memory.ts、get-profile.ts 与 add-memory.ts。这也是社区教程里opencode-supermemory 插件让编程助手跨会话记住项目偏好、构建命令的实现底座。一个生产级 Agent 的典型回路是读画像 → 搜索相关记忆 → 生成回答 → 把这一轮写回同一个会话文档。quickstart 给出的 harness 示例把整个过程压缩成了三段代码profile()拿基础身份search(question, memories)拿相关事实search(question, chunks)拿知识兜底最后把user/assistant轮次追加回稳定的id。这个读-生成-写回闭环就是记忆系统在 Agent 里真正起作用的形态。小结记忆是状态管理不是检索优化Supermemory 对整个 AI 记忆赛道最大的方法论贡献是坚持把记忆当作带时序的状态机来管理提取层把自由文本变成原子化事实图谱层用 Updates/Extends/Derives 三种关系处理矛盾与推导遗忘层用时间失效、矛盾覆盖、噪声过滤完成淘汰画像层则把当前真相压缩成一次 50ms 的调用。配合isLatest、isInference降权、dryRun语义删除这些工程细节它试图回答的不是如何存更多而是如何让记忆始终为真。对开发者而言接入这套系统的成本确实很低——一行supermemory.add()、一个 namespace、一个 profile 调用。但真正值得借鉴的是它的设计取舍稳定id保证会话连贯、dynamic做梦保证图谱质量、画像与搜索分治保证既快又全。当你的 Agent 下次再面对用户上个月说喜欢 A这个月说换 B的场景时希望你想到的不是换一个更大的向量库而是——记忆系统该有的样子是知道 A 已经过期了。【免费下载链接】supermemoryMemory and context engine app that is extremely fast, scalable, and can be run fully locally. The Memory API for the AI era.项目地址: https://gitcode.com/GitHub_Trending/su/supermemory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考