畫像：Supermemory如何處理信息沖突與過期記憶)
從聊完就忘到動態(tài)畫像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 生態(tài)的AI 失憶癥。圍繞這個痛點社區(qū)在過去一年里涌現(xiàn)了大量記憶層項目。而 Supermemory 之所以能從 Mem0、Zep 等競品中殺出靠的不是把對話丟進向量庫做相似度檢索而是把記憶當作一個有時間維度、有矛盾消解、有自動遺忘的動態(tài)系統(tǒng)來建模。官方在 LongMemEval、LoCoMo、ConvoMem 三大記憶基準上均排名第一LongMemEval 上達到 95% 的 Recall15同時只增加約 720 token 上下文99.4% 的上下文壓縮。本文不重復官方宣傳而是回到倉庫源碼與文檔拆解它回答的三個核心問題對話如何變成可查詢的結構化事實、信息沖突與過期記憶如何被裁決、動態(tài)畫像如何在 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 的本質(zhì)是無狀態(tài)檢索一份 Python 文檔對所有人都是同一份文檔它不追蹤這條事實什么時候變成真的、什么時候失效。而記憶的本質(zhì)是有狀態(tài)理解它需要回答關于這個用戶什么才是此刻為真。這正是 README.md 反復強調(diào)的一句話——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。一次攝入會經(jīng)歷完整的流水線queued → extracting → chunking → embedding → indexing → done見 how-it-works.mdx。文本、URL、PDFOCR、圖片視覺描述、音視頻轉寫、代碼AST 感知分塊都能進多模態(tài)入口見 content-types.mdx。關鍵在done之后的第二階段——dreaming做夢。文檔分塊只保證可檢索而記憶圖譜里的事實、更新與推導來自 dreaming 階段內(nèi)容被交給記憶模型與已有知識合并、編排、關聯(lián)。兩種模式模式行為適用dynamic默認相關文檔被分組記憶從連貫單元中形成而非一次孤立寫入生產(chǎn) Agent、連接器、持續(xù)會話instant該文檔單獨立即做夢處理完即可檢索/畫像演示、快速上手、現(xiàn)在就要圖譜這解釋了為什么官方反復建議真實應用里對話要用穩(wěn)定的id提交把整個會話作為一篇文檔讓引擎看到完整的多輪上下文而不是把每句話當作獨立記憶塞進去。quickstart 里那個東京團建的例子最直觀——用戶從頭到尾沒有說過一句Sarah 是我的產(chǎn)品副總裁圖卻是這么連出來的見 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關聯(lián)邊Sarah is being promoted to VP of Product的父節(jié)點是Sarah presented the Q3 roadmap at the Tokyo offsite子節(jié)點是User needs a gift idea for their VP of Product, Sarah。一個從未被顯式陳述的關系由圖譜從散落的會話中推導出來。沖突檢測與過期淘汰Updates、Extends、Derives 與遺忘記憶系統(tǒng)最難的不是存進去而是改過來。Supermemory 圖譜為每條新事實定義了三種關系見 graph-memory.mdxUpdates更新/矛盾裁決新事實替換舊事實成為檢索時的當前真相歷史保留用于審計。isLatest字段保證檢索永遠命中最新狀態(tài)——Alex works at Google as a software engineer 被 Alex just started at Stripe as a PM 覆蓋搜索Alex 在哪工作返回 StripeGoogle 那條沉入歷史。Extends豐富新事實為舊事實補充細節(jié)而不否定它兩者同時有效。Derives推導引擎從跨記憶的模式中推斷出你從未在任何一處明說的事實。例如Alex 是 Stripe 的 PM Alex 頻繁討論支付 API 與反欺詐 → 推導出Alex 很可能在做 Stripe 核心支付產(chǎn)品。針對推導inference系統(tǒng)有明確的安全閥推導事實默認標記isInference: true并在搜索中被降權直到有人確認memory-review.mdx。評審隊列按parentCount支撐來源數(shù)排序提供approve轉為正式事實/decline直接遺忘/undo三個動作接口設計成可做滑動卡片評審的形態(tài)。過期淘汰則分三層時間失效——臨時性事實自動過期exam tomorrow、meeting at 3pm today 這類帶時間錨點的事實日期一過即失效矛盾覆蓋——更新關系的存在讓當前真相始終由最新事實定義噪聲過濾——閑聊、無意義的寒暄不容易沉淀為持久記憶。記憶本身也分類型管理事實持久直到被更新、偏好隨重復而強化、情節(jié)除非重要否則衰減——不同生命周期對應不同遺忘策略這正是 README.md 里 handles temporal changes, contradictions, and automatic forgetting 一句的完整展開。而顯式的遺忘控制同樣被做成產(chǎn)品能力memories.forget按 ID 軟刪除從搜索排除但保留memories.forgetMatching按語義批量刪除forget everything about Project Titan并且強制要求先dryRun: true預覽再執(zhí)行——批量破壞性操作不允許盲跑。在 MCP 側add_memory工具的action: forget讓 Agent 自己就能在對話中說忘掉這個見 add-memory.ts。動態(tài)畫像Agent 場景里不用搜就知道的上下文搜索再多也有一個結構性缺陷你必須知道要問什么。用戶偏好里最有價值的部分——名字、時區(qū)、語氣偏好、技術棧——往往與任何具體查詢都沒有語義關聯(lián)。文檔 user-profiles.mdx 里的例子很說明問題用戶入職時說過一句 Call me Dhravya, not my full first name。之后無論他問幫我規(guī)劃去日本的旅行還是review 這個 PR這條事實都不會出現(xiàn)在搜索結果里——因為向量上它與這些查詢毫無相似度。但它應該永遠在場。Supermemory 對此的答案是每個命名空間自動維護一份畫像profile一次調(diào)用、約 50ms 返回分成兩段static靜態(tài)長期穩(wěn)定事實——Sarah is a senior software engineer at TechCorp、prefers technical docs over video tutorialsdynamic動態(tài)近期狀態(tài)與臨時上下文——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]這份畫像和搜索是互補關系而非替代搜索回答與我這個問題相關的是什么畫像回答這個人是誰無論問什么。在每輪對話的系統(tǒng)提示詞里注入畫像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取靜態(tài)動態(tài)畫像、add_memory保存/遺忘——分別對應 search-memory.ts、get-profile.ts 與 add-memory.ts。這也是社區(qū)教程里opencode-supermemory 插件讓編程助手跨會話記住項目偏好、構建命令的實現(xiàn)底座。一個生產(chǎn)級 Agent 的典型回路是讀畫像 → 搜索相關記憶 → 生成回答 → 把這一輪寫回同一個會話文檔。quickstart 給出的 harness 示例把整個過程壓縮成了三段代碼profile()拿基礎身份search(question, memories)拿相關事實search(question, chunks)拿知識兜底最后把user/assistant輪次追加回穩(wěn)定的id。這個讀-生成-寫回閉環(huán)就是記憶系統(tǒng)在 Agent 里真正起作用的形態(tài)。小結記憶是狀態(tài)管理不是檢索優(yōu)化Supermemory 對整個 AI 記憶賽道最大的方法論貢獻是堅持把記憶當作帶時序的狀態(tài)機來管理提取層把自由文本變成原子化事實圖譜層用 Updates/Extends/Derives 三種關系處理矛盾與推導遺忘層用時間失效、矛盾覆蓋、噪聲過濾完成淘汰畫像層則把當前真相壓縮成一次 50ms 的調(diào)用。配合isLatest、isInference降權、dryRun語義刪除這些工程細節(jié)它試圖回答的不是如何存更多而是如何讓記憶始終為真。對開發(fā)者而言接入這套系統(tǒng)的成本確實很低——一行supermemory.add()、一個 namespace、一個 profile 調(diào)用。但真正值得借鑒的是它的設計取舍穩(wěn)定id保證會話連貫、dynamic做夢保證圖譜質(zhì)量、畫像與搜索分治保證既快又全。當你的 Agent 下次再面對用戶上個月說喜歡 A這個月說換 B的場景時希望你想到的不是換一個更大的向量庫而是——記憶系統(tǒng)該有的樣子是知道 A 已經(jīng)過期了。【免費下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 從“聊完就忘“到動態(tài)畫像：Supermemory如何處理信息沖突與過期記憶
從聊完就忘到動態(tài)畫像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 生態(tài)的AI 失憶癥。圍繞這個痛點社區(qū)在過去一年里涌現(xiàn)了大量記憶層項目。而 Supermemory 之所以能從 Mem0、Zep 等競品中殺出靠的不是把對話丟進向量庫做相似度檢索而是把記憶當作一個有時間維度、有矛盾消解、有自動遺忘的動態(tài)系統(tǒng)來建模。官方在 LongMemEval、LoCoMo、ConvoMem 三大記憶基準上均排名第一LongMemEval 上達到 95% 的 Recall15同時只增加約 720 token 上下文99.4% 的上下文壓縮。本文不重復官方宣傳而是回到倉庫源碼與文檔拆解它回答的三個核心問題對話如何變成可查詢的結構化事實、信息沖突與過期記憶如何被裁決、動態(tài)畫像如何在 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 的本質(zhì)是無狀態(tài)檢索一份 Python 文檔對所有人都是同一份文檔它不追蹤這條事實什么時候變成真的、什么時候失效。而記憶的本質(zhì)是有狀態(tài)理解它需要回答關于這個用戶什么才是此刻為真。這正是 README.md 反復強調(diào)的一句話——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。一次攝入會經(jīng)歷完整的流水線queued → extracting → chunking → embedding → indexing → done見 how-it-works.mdx。文本、URL、PDFOCR、圖片視覺描述、音視頻轉寫、代碼AST 感知分塊都能進多模態(tài)入口見 content-types.mdx。關鍵在done之后的第二階段——dreaming做夢。文檔分塊只保證可檢索而記憶圖譜里的事實、更新與推導來自 dreaming 階段內(nèi)容被交給記憶模型與已有知識合并、編排、關聯(lián)。兩種模式模式行為適用dynamic默認相關文檔被分組記憶從連貫單元中形成而非一次孤立寫入生產(chǎn) Agent、連接器、持續(xù)會話instant該文檔單獨立即做夢處理完即可檢索/畫像演示、快速上手、現(xiàn)在就要圖譜這解釋了為什么官方反復建議真實應用里對話要用穩(wěn)定的id提交把整個會話作為一篇文檔讓引擎看到完整的多輪上下文而不是把每句話當作獨立記憶塞進去。quickstart 里那個東京團建的例子最直觀——用戶從頭到尾沒有說過一句Sarah 是我的產(chǎn)品副總裁圖卻是這么連出來的見 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關聯(lián)邊Sarah is being promoted to VP of Product的父節(jié)點是Sarah presented the Q3 roadmap at the Tokyo offsite子節(jié)點是User needs a gift idea for their VP of Product, Sarah。一個從未被顯式陳述的關系由圖譜從散落的會話中推導出來。沖突檢測與過期淘汰Updates、Extends、Derives 與遺忘記憶系統(tǒng)最難的不是存進去而是改過來。Supermemory 圖譜為每條新事實定義了三種關系見 graph-memory.mdxUpdates更新/矛盾裁決新事實替換舊事實成為檢索時的當前真相歷史保留用于審計。isLatest字段保證檢索永遠命中最新狀態(tài)——Alex works at Google as a software engineer 被 Alex just started at Stripe as a PM 覆蓋搜索Alex 在哪工作返回 StripeGoogle 那條沉入歷史。Extends豐富新事實為舊事實補充細節(jié)而不否定它兩者同時有效。Derives推導引擎從跨記憶的模式中推斷出你從未在任何一處明說的事實。例如Alex 是 Stripe 的 PM Alex 頻繁討論支付 API 與反欺詐 → 推導出Alex 很可能在做 Stripe 核心支付產(chǎn)品。針對推導inference系統(tǒng)有明確的安全閥推導事實默認標記isInference: true并在搜索中被降權直到有人確認memory-review.mdx。評審隊列按parentCount支撐來源數(shù)排序提供approve轉為正式事實/decline直接遺忘/undo三個動作接口設計成可做滑動卡片評審的形態(tài)。過期淘汰則分三層時間失效——臨時性事實自動過期exam tomorrow、meeting at 3pm today 這類帶時間錨點的事實日期一過即失效矛盾覆蓋——更新關系的存在讓當前真相始終由最新事實定義噪聲過濾——閑聊、無意義的寒暄不容易沉淀為持久記憶。記憶本身也分類型管理事實持久直到被更新、偏好隨重復而強化、情節(jié)除非重要否則衰減——不同生命周期對應不同遺忘策略這正是 README.md 里 handles temporal changes, contradictions, and automatic forgetting 一句的完整展開。而顯式的遺忘控制同樣被做成產(chǎn)品能力memories.forget按 ID 軟刪除從搜索排除但保留memories.forgetMatching按語義批量刪除forget everything about Project Titan并且強制要求先dryRun: true預覽再執(zhí)行——批量破壞性操作不允許盲跑。在 MCP 側add_memory工具的action: forget讓 Agent 自己就能在對話中說忘掉這個見 add-memory.ts。動態(tài)畫像Agent 場景里不用搜就知道的上下文搜索再多也有一個結構性缺陷你必須知道要問什么。用戶偏好里最有價值的部分——名字、時區(qū)、語氣偏好、技術棧——往往與任何具體查詢都沒有語義關聯(lián)。文檔 user-profiles.mdx 里的例子很說明問題用戶入職時說過一句 Call me Dhravya, not my full first name。之后無論他問幫我規(guī)劃去日本的旅行還是review 這個 PR這條事實都不會出現(xiàn)在搜索結果里——因為向量上它與這些查詢毫無相似度。但它應該永遠在場。Supermemory 對此的答案是每個命名空間自動維護一份畫像profile一次調(diào)用、約 50ms 返回分成兩段static靜態(tài)長期穩(wěn)定事實——Sarah is a senior software engineer at TechCorp、prefers technical docs over video tutorialsdynamic動態(tài)近期狀態(tài)與臨時上下文——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]這份畫像和搜索是互補關系而非替代搜索回答與我這個問題相關的是什么畫像回答這個人是誰無論問什么。在每輪對話的系統(tǒng)提示詞里注入畫像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取靜態(tài)動態(tài)畫像、add_memory保存/遺忘——分別對應 search-memory.ts、get-profile.ts 與 add-memory.ts。這也是社區(qū)教程里opencode-supermemory 插件讓編程助手跨會話記住項目偏好、構建命令的實現(xiàn)底座。一個生產(chǎn)級 Agent 的典型回路是讀畫像 → 搜索相關記憶 → 生成回答 → 把這一輪寫回同一個會話文檔。quickstart 給出的 harness 示例把整個過程壓縮成了三段代碼profile()拿基礎身份search(question, memories)拿相關事實search(question, chunks)拿知識兜底最后把user/assistant輪次追加回穩(wěn)定的id。這個讀-生成-寫回閉環(huán)就是記憶系統(tǒng)在 Agent 里真正起作用的形態(tài)。小結記憶是狀態(tài)管理不是檢索優(yōu)化Supermemory 對整個 AI 記憶賽道最大的方法論貢獻是堅持把記憶當作帶時序的狀態(tài)機來管理提取層把自由文本變成原子化事實圖譜層用 Updates/Extends/Derives 三種關系處理矛盾與推導遺忘層用時間失效、矛盾覆蓋、噪聲過濾完成淘汰畫像層則把當前真相壓縮成一次 50ms 的調(diào)用。配合isLatest、isInference降權、dryRun語義刪除這些工程細節(jié)它試圖回答的不是如何存更多而是如何讓記憶始終為真。對開發(fā)者而言接入這套系統(tǒng)的成本確實很低——一行supermemory.add()、一個 namespace、一個 profile 調(diào)用。但真正值得借鑒的是它的設計取舍穩(wěn)定id保證會話連貫、dynamic做夢保證圖譜質(zhì)量、畫像與搜索分治保證既快又全。當你的 Agent 下次再面對用戶上個月說喜歡 A這個月說換 B的場景時希望你想到的不是換一個更大的向量庫而是——記憶系統(tǒng)該有的樣子是知道 A 已經(jīng)過期了。【免費下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考