你有沒有想過一件事：你的手機里，其實存著一份比你自己記得還清楚的人生檔案。
去年春節你去了哪些親戚家、什麼時候訂的票、跟誰吃了年夜飯、拍了哪些照片、備忘錄里寫過什麼心事，這些碎片散落在通訊錄、相冊、日曆、筆記、購物記錄里，誰也沒把它們拼起來過。
現在，OPPO和OpenKG聯合團隊做了一件事，他們想搞清楚：一個裝在手機里的AI助手，能不能真正記住你這一整年發生的事，並且在你需要的時候，把這些碎片拼成一個完整的答案？
這就是他們發布的MobileMem
，一個專門為「手機記憶」設計的評測基準和框架。
先說說這件事有多難。
大模型早就能聊天答題了，但聊天和答題是一次性的事。你問一句它答一句，問完就忘。真正難的是讓AI變成一個**長期陪伴你的助手**，它得記住你三個月前提過的過敏藥物，記住你上周搜索過的旅行攻略，還得知道你的偏好是會變的，去年愛吃辣，今年可能因為胃不好戒辣了。
這種能力現在有個名字，叫「持續性個人智能」。行業里已經在往這個方向走，AI手機、AI眼鏡、車載助手、具身機器人，都在朝著「陪伴型AI」演化。但這些系統的智能程度，將來不再單純看它懂多少知識，而是看它**記得什麼、從經歷中學到了什麼、怎麼跟著你一起變化**。
為什麼現有的記憶研究，在手機上根本不管用
這裡有個容易被忽略的事實：幾乎所有關於AI長期記憶的研究，都是按「雲端場景」設計的。
雲端記憶研究默認儲存空間無限大、計算能力隨便用、資料庫集中管理。這套假設放在伺服器上沒問題，但放到手機上，立刻就崩了。
手機每天要生成幾千條事件記錄、幾百張照片、長時間的語音和影片，這些數據量對手機有限的儲存和頻寬來說，是持續不斷的壓力。而且這些數據天生是碎片化的，散落在不同App里，缺乏統一的結構。更麻煩的是，你的興趣、習慣、生活狀態一直在變，記憶系統得能識別哪些資訊已經過時，同時又不能因為學了新東西就把老的忘乾淨。手機的計算和電力也有限，直接把雲端那套方案搬過來是行不通的。最後還有隱私問題，這些數據太私密了，傳到雲端本身就是風險，必須在本地處理。
論文裡有句話說得挺直接：**當基礎模型越來越同質化的時候，真正的差異化不再是模型本身，而是它是否理解自己服務的這個人。**
這句話背後藏著一個判斷：未來每個人都會有自己的AI，每個AI都需要自己的本地記憶。這不是錦上添花的功能，而是智能體運作的地基，就像今天的雲計算和資料庫是數字基礎設施一樣，本地記憶會成為數字經濟時代的新生產要素。
那問題來了，現有的長期記憶評測基準，比如之前學術界常用的一些數據集，為什麼不能直接拿來測手機場景？
答案很簡單，它們大多是人機對話記錄，乾淨、結構單一，跟真實手機上亂糟糟的多模態、跨App、持續演變的數據完全是兩碼事。MobileMem就是為了填這個空而生的。
手機記憶系統該長什麼樣
在講MobileMem的評測方法之前，得先說說論文裡對「手機記憶架構」的一個設想，這個設想挺有意思，值得單獨講講。
論文作者觀察到一件事：很多App本身其實已經是一個個小型記憶系統了。
瀏覽器會記錄瀏覽歷史並支持關鍵詞搜索，這跟檢索系統里的BM25算法幾乎是一回事。記賬App會把交易記錄匯總成月度收支報表，這跟記憶系統里的「記憶鞏固」過程本質相同，都是把零散的原始經歷壓縮成更精煉的表達。
**引用塊**：BM25*：一種經典的文本檢索算法，根據關鍵詞匹配程度給文檔評分排序，是很多搜尋引擎背後的基礎技術。
如果每個App都是一個專業的小記憶庫，那為什麼還要有一個統一的系統層記憶？
論文提出了一個「兩層架構」的設想。第一層是系統級記憶層，就像OPPO的Breeno或者蘋果的Siri，它負責儲存跨App的用戶畫像、偏好和行為模式。第二層是應用級記憶，每個App管理自己領域內的資訊。這兩層通過標準化協議交換資訊。
這個設計借用了一個很老的概念，叫「黑板架構」。
**引用塊**：黑板架構（Blackboard Architecture）*：一種協同計算模式，多個專業模組把各自的處理結果寫到一塊共享的「黑板」上，再由一個統籌者讀取黑板資訊來做決策，最早用於人工智慧領域的複雜問題求解。
在這個架構里，系統層記憶就是那塊黑板，各個App是往黑板上貼便利貼的專家。比如理財App發現你經常半夜下單燒烤外賣，它把這條行為規律寫到黑板上，助手看到後就能在合適的時候主動提醒你或做推薦。反過來，當你問助手「幫我訂今晚市中心的酒店」時，助手先看黑板了解你的整體狀況，再去查地圖App和訂房App里的具體細節，最後把結果整合起來回答你。
這裡還有一個概念叫「認知卸載」。
**引用塊**：認知卸載（Cognitive Offloading）*：指把原本需要大腦自己處理和記住的資訊，轉移給外部工具或系統去承擔，減輕大腦的負擔。
論文認為應用級記憶就是系統層記憶的認知卸載機制。手機上的交互太瑣碎了，如果每一次滑動、每一次翻頁都要往系統層記憶里塞，系統很快就會被垃圾資訊淹沒。所以App要學會自己過濾，只把有價值的事件往上報。比如你保存了一條非空的筆記，筆記App才會把標題、內容、時間戳打包發給系統層記憶；但你劃了一下螢幕，這種操作沒必要上報。
這就好比一個公司里，如果每個基層員工每天做的每件小事都要直接匯報給CEO，CEO根本沒時間做真正重要的決策。真正高效的組織是，基層先把瑣碎的事情自己處理消化，只把關鍵資訊和結論上報給上層。**如果不做這層過濾，會發生什麼？**系統層記憶會被大量轉瞬即逝的界面操作淹沒，真正重要的長期偏好和行為模式反而被噪音蓋住，找不出來了。
不過這套兩層架構目前還是一個長遠願景，MobileMem目前先做了兩個簡化但有代表性的評測場景。
兩種評測場景，一個測文本一個測圖片
第一個場景叫MobileMem，模擬的是App跟系統助手深度集成的情況。這裡聚焦的是筆記、文檔編輯、語音備忘錄這類天生會保存用戶記錄的App，用戶一旦創建新記錄，App就自動把內容抽取出來，按預定義模板發給記憶層。
第二個場景叫MobileMem-Omni，情況更複雜一些，App跟系統記憶層沒有直接打通，用戶得靠截圖把重要的應用交互分享給助手。這引入了一個新挑戰，資訊現在同時分布在文字和圖像兩種模態里，助手得學會看圖理解。
**引用塊**：MLLM（Multimodal Large Language Model，多模態大語言模型）*：能同時處理文字、圖片等多種資訊類型的大模型，比如能看懂截圖內容並結合文字對話理解上下文。
這兩個場景怎麼造出來的？這是整篇論文裡我覺得最巧妙的部分。
數據從哪來：不能憑空造，得有「錨點」
評測長期記憶能力，最大的難題是沒數據。真實用戶一年的手機使用記錄，涉及嚴重的隱私問題，根本沒法大規模收集。但如果完全靠大模型瞎編，生成的數據又會顯得千篇一律，缺乏真實的個性化細節。
論文團隊想出的解法是：**先收集真實但「乾淨」的用戶先驗知識，再讓AI圍繞這些先驗知識去演繹出完整的故事。**
具體來說，他們招募了志願者，通過訪談收集用戶畫像，同時從志願者的OPPO手機上採集App使用統計和元數據，比如地理位置、藍牙連接、網路狀態這些上下文信號，但嚴格避免採集原始交互內容本身，以此保護隱私合規。
這些真實但零散的資訊被稱為「先驗知識」，團隊專門設計了一套引擎，叫KEME，來把這些先驗知識組織成一段連貫的長時間軌跡。
**引用塊**：KEME（Knowledge-guided Experience synthesis for evolving MEmory）*：一套知識引導的經驗合成引擎，核心思路是拿真實的用戶背景資訊當骨架，再用AI往骨架上長出完整的、時間線自洽的用戶經歷。
這裡有個關鍵概念叫「知識錨點」。
**引用塊**：知識錨點（Knowledge Anchor）*：那些已經真實發生過、必須原樣保留在最終故事線里的資訊片段，比如用戶先前收集到的App交互記錄，AI合成故事時不能改寫或忽略這些內容，只能圍繞它們展開。
這就好比寫一部基於真實歷史的小說，作者可以自由發揮人物對話和細節，但一些歷史事實是不能改的，比如某場戰役發生在哪一年、誰贏了。如果連這些錨點都能隨便改，那生成出來的故事就徹底失去了可信度，評測出來的結果也沒有意義。**如果沒有錨點約束**，AI生成的「用戶經歷」很容易變成完全脫離現實的幻想，測出來的記憶能力其實測的是AI編故事的能力，而不是真正處理現實數據的能力。
KEME具體怎麼工作的？它用了一套「自上而下規劃、自下而上演化」的循環機制，由四個AI角色分工完成。
第一個角色叫知識引導的規劃者，它根據用戶畫像和時間範圍，先畫出一個粗略的「人生事件圖」，把整個時間跨度切成幾個大的生活階段。這個圖可以不斷往下細分，比如「上半年」可以分成「春節假期」「換工作」「搬家」，每個小事件又能再往下拆成具體的一次次交互。
第二個角色叫知識錨點定位者，負責把已有的真實交互塞進對應的事件節點裡，確保時間上說得通。
第三個角色叫經歷實現者，負責把每個具體事件寫成真實的人機對話內容。
第四個角色叫經歷驅動的修訂者，每次生成新內容後，它會回頭檢查還沒展開的部分，看看有沒有因為剛才新加的情節產生了矛盾，需要的話就調整未來的事件走向。
這四個角色輪番工作，就像劇本的疊代打磨過程。寫小說的人都知道，故事寫到後面往往會發現前面埋的伏筆跟後續情節衝突了，得回頭改。KEME用這種「邊寫邊改」的方式，保證一整年的故事線始終自洽，不會出現用戶上午說自己吃素、下午又在燒烤店打卡的荒謬情況。
除了生成故事本身，KEME還得基於這段故事生成用來測試AI記憶能力的問答對。這一步同樣是自下而上的，從最底層具體的一次對話開始生成簡單問題，再往上層層組合，生成需要跨越多個事件才能回答的複雜問題。團隊還專門設了質量檢查環節，人工抽樣核對，發現絕大多數問答對是準確且有依據的，只是少數多跳問題顯得有點生硬，像是把兩個獨立的問題硬拼在一起，但答案依然是清晰可驗證的。
MobileMem數據集實測：誰記得住，誰記不住
現在到了真正見分曉的環節，團隊拿這套合成數據，測了市面上主流的多種記憶系統。
參與測試的系統五花八門，有最簡單的長上下文方案，就是把整段歷史塞進模型的上下文窗口裡讓它自己找資訊；有基於檢索的RAG系統，包括NaiveRAG、HippoRAG2、A-MEM；還有更複雜的記憶框架，比如LangMem、MemOS、EverMemOS、Mem0。
**引用塊**：RAG（Retrieval-Augmented Generation，檢索增強生成）*：先從儲存的資料里檢索出相關內容，再交給大模型參考著生成答案，而不是讓模型憑空回答，能有效減少模型編造內容的情況。
結果挺有意思。表現最好的是A-MEM和HippoRAG2，無論用哪個大模型當後端都穩居前列。團隊分析發現，這兩個方法有個共同點：它們不會對原始對話資訊做激進的壓縮、覆寫或刪除，而是把細節儘量完整地保留下來。
這個結果乍一看有點反直覺。因為NaiveRAG同樣保留了原始對話，理論上應該表現類似，但實際上NaiveRAG的成績相當差。團隊進一步分析發現，問題出在檢索環節，A-MEM給每條記憶額外抽取了關鍵詞和標籤，這些額外資訊在檢索時能幫系統更精準地區分相似的記憶片段。HippoRAG2則引入了實體關係圖和個性化PageRank算法，專門優化多跳檢索，也就是需要串聯多條線索才能回答的問題。而MobileMem里的干擾項特別多，真正需要的證據經常被大量看起來相關但其實無關的內容包圍，這種情況下這類精細檢索機制的優勢就凸顯出來了。
再看不同類型問題的表現，一個清晰的規律是：**問題需要串聯的證據越多，系統表現就越差**。單跳問題（一句話就能查到答案）表現最好，多跳問題（需要拼接多條資訊）明顯下降，需要總結歸納的查詢式摘要問題最難，因為它不光要找到證據，還得把內容濃縮成簡潔的回答。時序推理類問題普遍表現薄弱，說明現有系統還不太擅長記住「這件事發生在那件事之前還是之後」這種時間關係。
有個特別反直覺的發現是關於對抗性問題的，也就是那種壓根沒有答案、正確回應應該是「我不知道」的問題。表現最弱的LangMem，在這類問題上反而拿了最高分。研究團隊解釋說，越強的記憶系統越容易檢索到一些看起來相關、實際上是干擾項的內容，這會讓模型誤以為答案確實存在，從而更加自信地給出一個錯誤答案，反而是那些檢索能力弱的系統，因為找不到什麼相關內容，更容易正確地說「我不知道」。這個發現其實挺值得警惕的：**記憶系統越強，有時候反而越容易在不該回答的時候強行給出答案**。
團隊還專門拆解了四種系統各自最典型的出錯原因。長上下文方案最大的問題出在「記憶更新」環節，因為它受限於上下文窗口長度。NaiveRAG最常見的問題是壓根沒檢索到目標證據。Mem0的問題多出在事實抽取階段，它的抽取提示詞主要盯著用戶說的話，容易漏掉App或助手消息里的關鍵資訊。而EverMemOS的記憶構建和檢索環節整體表現不錯，問題主要出在最後一步的答案生成上，也就是就算給它正確的證據，它有時候還是會理解錯或答偏。
這幾個系統有個共同點，都會出現「答案生成」階段的錯誤，模型可能被無關記憶干擾，或者忽略了關鍵證據，又或者把精確的事實過度概括，丟失了重要細節。
KEME還能幹什麼：製造更難的測試題
論文裡還有一個特別有意思的延伸實驗，展示了KEME這套合成引擎不只能用來造評測數據，還能用來給現有的評測數據集「加難度」。
團隊拿了一個已有的公開評測集LongMemEval，這個數據集原本增加難度的方式很簡單粗暴，就是從別的對話語料庫里隨機抽一些不相關的會話塞進去，當作干擾項。
團隊想驗證一件事：能不能讓KEME生成一批更「聰明」的干擾內容，讓記憶系統更難找到正確答案，同時保證答案本身不變？
他們選了10個問題，找GPT提煉出問題需要的核心事實，讓KEME在這些事實周圍重新生成一段跟原故事兼容的用戶背景，再刻意引導它生成一些語義上更接近、更容易混淆檢索的干擾內容。
結果顯示，合成出來的軌跡通常比原來的LongMemEval軌跡更短，但檢索難度反而更高了。NaiveRAG在只檢索前5條結果時，正確率從40%掉到20%；檢索前10條時，從50%掉到40%。EverMemOS也從90%降到80%（前5條）、從100%降到90%（前10條）。
這說明什麼？**難度的來源不是軌跡變長了，而是干擾內容變得更「像真的」了。**
有個具體案例特別能說明問題。有個問題問的是「我之前在美聯航的常客等級是什麼，在升到現在的等級之前」。真實軌跡里藏著兩條關鍵線索：一條說用戶剛攢夠20000英里，達到了銀卡資格；另一條說幾個月後，用戶升級成了金卡。團隊檢查發現，EverMemOS的記憶庫里其實存著這兩條資訊，但檢索環節沒能撈出精確的等級證據，反而撈出了一堆語義相近但內容模糊的干擾內容，比如「穩穩處在聯合航空的中端精英段位」，還有希爾頓、運通、萬豪這些完全不相關的金卡提及。因為這些干擾項在向量空間裡跟查詢語句長得太像，檢索系統反覆撈回這些似是而非的內容，最終沒能定位到確切的等級變化，答錯了。
這個案例其實揭示了一個更深的道理：**記憶系統的短板，很多時候不在於記沒記住，而在於檢索時能不能從一堆看似相關的噪音里，把真正精確的那條資訊挑出來。**這就像你的手機相冊里存了幾千張照片，你想找去年生日聚會那張合影，結果因為背景音樂App、聚會App、外賣App都留下了跟「生日」相關的記錄，你翻半天，翻出來的全是差不多但不對的那張，真正想要的那張反而被淹沒在這些相似結果里。
MobileMem-Omni：當記憶開始「看圖」
如果說MobileMem測的是文字記憶，那MobileMem-Omni測的就是更貼近真實生活的多模態記憶，因為現實中我們分享給助手的很多資訊，壓根不是文字，而是截圖。
這套數據集的規模相當可觀：16位用戶的完整軌跡，19060張圖片，7415道問答題。
用戶里一半說英語一半說中文，覆蓋了1589個事件。平均每個用戶的上下文長度高達172萬個token，平均每人有202.6個會話，每個會話平均48.2輪對話，平均每個會話配5.88張圖片。
**引用塊**：Token*：大模型處理文本時的最小計量單位，大致可以理解為一個詞或一個字符片段，172萬token大概相當於一部長篇小說的資訊量。
問題類型分了七大類：單跳、多跳、知識更新、時序推理、隱性偏好、拒答（也就是要識別出無法回答的問題）、以及視覺推理。
圖片是怎麼生成的？這塊也挺講究。團隊用了三種方式：手機App截圖用HTML模板渲染，涉及用戶和熟人合照的場景，會先從人物關係圖譜里取出對應人物的肖像照，再用這些肖像去合成帶人物的照片，保證同一個人在不同照片裡長得一致；其他場景比如美食、風景照，直接用文字描述生成。為了保證質量，團隊還用了人臉識別工具，去校驗合成出來的人臉跟參考肖像是不是同一個人，相似度不夠就重新生成。
這裡想說個細節，為了保證長期軌跡里「這個人一直是這個人」，團隊專門給每個用戶建了一個以用戶為中心的社交關係圖，每個節點是一個人，每條邊是一段關係描述。這個設計其實挺重要的，如果沒有這套一致性保障，你會發現同一個「表姐」在三月的照片裡是一張臉，到了八月的照片裡變成了另一張臉，整個測試的真實感就崩了。
測試結果同樣出現了明顯的分層。專業記憶框架整體上跑贏了長上下文和簡單RAG方案，其中EverMemOS配合GPT系列後端表現最突出，達到39.41%的綜合評分，遠超同一方法換成Qwen3-VL後端時的24.76%，說明底層大模型的能力對最終效果影響巨大。
有個特別值得琢磨的現象：把圖片轉成文字描述（也就是配上字幕）再輸入模型，跟直接把圖片餵給模型比，效果居然是文字描述更好。M2A這個多模態記憶框架，配文字字幕的版本明顯優於直接處理原始圖像的版本。這說明當前的視覺理解能力，在處理長期記憶場景里的細節圖像時，還不如先轉成文字來得可靠，圖像里的關鍵資訊，模型未必真的「看懂」了，用文字提前濃縮概括一遍，反而更穩。
不過字幕這條路也不是萬能的。團隊做了個對比實驗，往檢索系統里加入圖片字幕後，視覺推理類問題的表現提升了3.5個百分點，但其他文字類問題的表現卻下降了4.43個百分點。這個結果挺微妙的，視覺資訊對圖像相關問題是養分，對純文字問題卻成了噪音。這就像你本來在專心看一份合同文本，旁邊突然多了一堆無關的配圖說明，反而分散了你對文字細節的注意力。**這說明有效的多模態記憶系統，需要更精細的視覺表示方式，而不能簡單粗暴地把圖片一律轉成字幕塞進去。**
另外還發現兩個規律：事件跨度越長，記憶系統表現反而越好，因為更長的事件提供了更豐富的上下文幫助定位；而中文問題的表現普遍低於英文問題，這大概率是因為現有的記憶機制和方法主要是圍繞英語設計和優化的，對中文的語義對齊和檢索質量還沒跟上。
落地的場景：這套系統到底能幹嘛
論文裡舉了幾個具體場景，讀完你大概能感受到這套系統真正要解決的問題是什麼。
比如一位老人長期記錄血壓血糖，把每次複診的下次預約時間存進日曆，醫囑寫進筆記，檢驗報告拍照存進相冊。有一天早上感到頭暈，問助手「我之前對什麼藥過敏，檢查一下我現在吃的藥里有沒有這個成分」，助手需要跨越日曆、筆記、相冊這幾個完全不同的數據源，把過敏史和當前用藥清單對上，及時給出風險提示。這背後考驗的正是跨來源記憶關聯、多模態資訊融合、長期事實記憶和複雜檢索能力。
再比如一位遊客提前收藏了不少成都旅遊攻略，出發前一晚問助手「根據我收藏的內容，幫我規劃一個兩日游」，助手不能只給出泛泛的寬窄巷子、錦里這種標準答案，而要結合用戶此前搜索過的交通方式和住宿偏好，給出一份真正個性化的行程。這測的是跨來源知識整合、用戶偏好建模、多跳推理和長期個性化規劃的綜合能力。
還有一位職場人準備年中總結，過去半年開了無數次會、反覆改方案、讀了大量行業文章，卻感覺學到的東西很散亂。助手需要整合日曆里的會議和項目時間線、文檔里的修訂歷史、筆記里的零散想法，梳理出一條清晰的學習軌跡，指出反覆卡殼的瓶頸在哪。
這些場景背後共同的訴求是，長期記憶不該只是被動的資訊檢索，而應該支持跨來源知識整合、用戶偏好建模、多跳推理這些更高階的能力。
寫在後面
看完這篇論文，最讓我意外的一點是那個反直覺的實驗結果：記憶系統越強，越容易在該說「不知道」的時候強行給出答案。這跟我們直覺里「越聰明的系統越可靠」是矛盾的。原因也說得通，檢索能力越強的系統，撈回來的干擾項越像真的，模型反而更自信地把一個錯誤答案說出口。這提醒我一件事，評測AI系統光看正確率是不夠的，還得看它面對不確定性時的表現，一個誠實地說「我不知道」的系統，有時候比一個自信地說錯的系統更值得信任。
另一個讓我反覆琢磨的地方是KEME那個「合成更難數據」的實驗。團隊沒有靠拉長軌跡增加難度，而是靠往軌跡里塞進語義上更接近答案證據的干擾內容，就讓原本正確率90%以上的系統掉到80%。這說明檢索的真正難點從來不是資訊量大小，而是干擾項跟正確答案有多像。這個思路其實可以用在別的地方，任何評測系統的「壓力測試」，本質上都該往這個方向走：不是讓題目變長變複雜，而是讓干擾項變得更狡猾。
論文裡還沒解決的一個問題是中英文表現差距，這個問題被提到了但沒深挖原因。如果記憶系統本質上是圍繞英語語料訓練和優化的，那隨著更多語言的用戶加入，這個差距會不會持續放大，值得後續追問。
Q&A
Q1：MobileMem是什麼？
A：MobileMem是OPPO和OpenKG團隊推出的一套評測基準和框架，專門用來測試AI助手在手機場景下的長期記憶能力，包括文本設置的MobileMem和多模態設置的MobileMem-Omni兩部分。
Q2：MobileMem的數據是怎麼來的，會不會涉及隱私泄露？
A：數據通過KEME合成引擎生成，團隊先收集志願者真實但脫敏的App使用統計和用戶畫像，再由AI圍繞這些"知識錨點"演繹出完整故事，全程避免採集原始交互內容，並對涉及真實用戶的資訊做了匿名化處理。
Q3：測試下來哪種記憶系統表現最好？
A：在文本場景下，A-MEM和HippoRAG2表現最優，因為它們能保留豐富的原始資訊並配合精細的檢索機制；在多模態場景下，EverMemOS配合GPT系列大模型表現最突出。不過所有系統在多跳推理、拒答識別、視覺推理這幾類任務上普遍表現較弱。
