AI Agent Arxiv Digest — 2026-08-28

🌏 English version

今日總覽

今天三篇論文從三個不同的技術層次,同時在攻同一件事:「Agent 記憶」早就不是「怎麼把歷史塞進 prompt」這麼簡單。Scroll 說,別再序列化歷史了,把整個 session 變成一個可以寫程式操作的執行環境,原始記錄全部留著,要用的時候用 Python 去查;EARM 說,檢索器自己也該有記憶,把過去打過的相關性分數存下來,靠矩陣補全去猜還沒打分的候選,省下大半重排序的推理成本;PolyMemDB 則從資料庫工程的角度說,記憶資料本來就是異質的(實體關係、機率信心、時空座標),硬塞進一種儲存格式才是問題根源,該用對的資料庫存對的資料類型,再用機率推論去化解記憶裡的矛盾。三篇合起來,勾勒出「Agent 記憶」正在從一個提示工程問題,變成一個真正的系統設計問題。

讀這篇前該知道的詞

論文一｜把上下文變成一個環境:Scroll 讓 Agent 自己寫程式管理長期記憶

Context as an Environment: Programmatic Context Management for Long-Horizon Agents Yin Lin, Elaine Ang, Erkang Zhu et al.(Alibaba Group;Elaine Ang 任職於 Columbia University)　·　arxiv: 2608.21690

連結: arxiv · alphaxiv

TL;DR

Scroll 不把歷史序列化進 prompt,而是把整個 agent session 變成一個常駐的 Python 執行環境,模型用寫程式的方式去查、算、篩歷史;在 Qwen3.8-Max 上,LongMemEvalS 拿下 94.8%、BEAM10M 73.1%(比最佳已發表記憶系統高 5.1 分)、LOCA 256K 86.7%(比最佳已發表長程 agent 高 37.4 分)。

Read Priority

必讀 — 幾乎所有做長程任務的 agent 平台都在跟「歷史太長塞不進 context」搏鬥,Scroll 給出一個具體、已經被真實框架採用的解法方向,不是停留在論文裡的概念驗證。

領域背景

現有的長程 agent 記憶方案,大多是在寫入時就決定要保留什麼——壓縮成摘要,或抽取關鍵資訊塞進固定的記憶格式。問題是,寫入當下不知道未來會需要什麼,壓縮或摘要一旦發生,細節就回不來了。RAG 式的向量檢索則是把歷史當成獨立文件庫,但 agent 的 session 其實是一條高度相關、前後呼應的連續事件流,跟一般 RAG 假設的異質文件庫不一樣。

中階導讀

• 問題:想像一個 agent 跑了幾百輪的複雜任務,第 10 輪你告訴它一個限制條件,到第 200 輪它要做決策時,這個限制早就被摘要掉、或者根本沒被檢索回來。
• 方法:Scroll 把整個 session 歷史存進一個 append-only 的 Event Log,同時開一個常駐、跨模型呼叫都不會重置的 Python kernel。模型不是被動接收摘要,而是主動寫程式(exec)去搜尋、篩選、聚合這個 kernel 裡的歷史資料,只有明確 print 出來的結果才會進入下一輪的 prompt。當「工作視野」快滿的時候,舊的內容會被移出視野但不會被丟掉,系統留一個「淘汰索引」記錄它們原本在 Event Log 的確切位置,之後要用可以直接定位取回,不用整份重新搜尋。
• 為什麼重要:上下文管理從「工程師手動設計要記什麼」變成「模型自己寫程式去查」,直接繼承了 LLM 越來越強的程式能力,而且原始記錄永遠不丟——這對需要精確數值、時序、或事實更新的任務特別關鍵。

深入要點

• 主結果(Qwen3.8-Max):LongMemEvalS 94.8%、BEAM10M 73.1%(比最佳已發表記憶系統高 5.1 分)、LOCA 128K 89.3%／256K 86.7%(比對照的 MiniMax M3 + ReAct 在 256K 的 49.3% 高出 37.4 分)⚠️(基準線多取自各系統文獻裡的最佳公開結果,並非同一套環境下的受控重現)
• 消融實驗最傷的一刀:把 Event Log 換成「寫入時就摘要、丟棄原文」,整體分數從 73.1 崩到 19.9,尤其是需要精確數值的資訊擷取、時序推理、事實更新類任務幾乎歸零
• 拿掉常駐 kernel、把查詢改成一般工具呼叫,掉 7.3 分——序列化過的工具結果沒辦法在 kernel 裡再篩選、合併、聚合
• 反例:在「寫入時先做好摘要」反而有利的任務(對話摘要、偏好追蹤)上,Scroll 輸給專門的記憶系統,例如摘要類分數 70.5 分,不敵 Exabase M-1 的 91.9 分
• 模型能力越弱,受益越少:35B 開源模型在 LongMemEvalS 上還能拿 88.8(只差最佳 6 分),但在 LOCA 256K 差距被拉到 64 分(86.7 vs 22.7)——顯示 Scroll 的效果上限跟著模型的多步驟程式規劃能力走
• 落地訊號:GitHub 上可查到開源 agent 框架 QwenPaw(AgentScope 系）已把類似 scroll 的策略合併進生產程式碼,並經過完整 code review(含 sandbox 安全性、SQL injection 防護等修正),不是純學術概念
• Limitation:所有跟其他記憶系統的比較都是「文獻裡的最佳公開結果」,不是同一套環境下的受控比較 ⚠️

Reviewer 一句話評

把 context management 直接變成寫程式這件事做得很扎實,消融實驗清楚證明「保留原始記錄」比「寫入時摘要」重要得多;但基準線比較沒有受控環境,且效果明顯跟著模型的程式規劃能力走,換成程式能力弱的模型效益會大打折扣。

給你的 take-away

• 如果你的 agent 平台有長程任務(需要跨很多輪保留精確資訊):Scroll「歷史不進 prompt、留在可執行環境裡查」的設計值得直接參考,尤其如果你的框架本來就支援 code execution(CodeAct 類架構)
• 如果你在評估要不要導入類似機制:先確認你的 backbone 模型本身程式規劃能力夠不夠強,弱模型上收益有限,甚至可能因為執行錯誤而更差

論文二｜檢索器也該有記憶:EARM 用檢索經驗攤提重排序成本

The Retriever Should Remember: Experience-Amortized Reranking for Long-Term Agent Memory Qi Feng, Chris Ding, Jicong Fan(香港中文大學(深圳)資料科學學院 School of Data Science, CUHK-Shenzhen)　·　arxiv: 2608.22767

連結: arxiv · alphaxiv

TL;DR

EARM 把 LLM 打過的相關性分數當成可重複利用的「檢索經驗」存進線上矩陣,靠因果矩陣補全去猜還沒打分的候選,在只需直接評分 17.5% 候選的情況下,答案準確率仍比純語意檢索最多提升 6.62%。

Read Priority

略讀 — 對已經有穩定記憶庫、查詢量大的長期記憶系統(個人助理、客服)有直接的成本節省價值,但方法本身建立在矩陣補全上,數學門檻比工程門檻高。

領域背景

長期 agent 會累積大量記憶,但檢索器通常是無狀態的:語意向量檢索快但不準,LLM 重排序準但每次都要重新對一大批候選打分,分數用完即丟,完全不會累積。這篇論文指出一個此前被忽略的現象:同一個記憶庫被重複查詢時,檢索器打過的分數其實藏著可以重複利用的結構。

中階導讀

• 問題:想像一個檢索器每次查詢都要對 200 個候選記憶重新打分,查了一千次就打了二十萬次分,但其實很多記憶反覆被同樣類型的問題檢索到,這些歷史分數卻從來沒被記下來。
• 方法:EARM 把每次查詢-記憶配對的 LLM 相關性分數存進一個持續累積的稀疏矩陣(查詢為欄、記憶為列),用「因果矩陣補全」學出這個矩陣的共享結構,再用少量新打的分數加上估計分數,一起排序其餘候選。隨著累積的經驗變多,需要直接打分的候選比例會逐步下降。
• 為什麼重要:把「記得内容」和「記得怎麼檢索」這兩件事分開看——一個長壽命的 agent 不該只記住經歷過什麼,還該記住哪些記憶對哪些問題有用過,讓重排序從每次查詢都要付的固定成本,變成隨 agent 生命週期累積的能力。

深入要點

• 核心數字:只用實際打過分的候選(Observed-only)比純語意檢索提升 1.36–3.83%;疊加補全分數後再提升 0.78–2.79%,在 rank=8、Top-10 的設定下合計提升達 6.62%
• 效率驗證:直接評分比例從一開始的 100% 一路降到 17.5% 候選,仍能維持優於純語意檢索的準確率
• 測試集:LoCoMo 長期對話記憶資料集,涵蓋 multi-hop、open-domain、single-hop、temporal 四類問題;打分模型用 Qwen3.5-4B-Q8_0,答案生成與評分都用 GPT-4o-mini
• 落地門檻:需要維護一個隨時間增長的「查詢-記憶相關性矩陣」並持續做線上矩陣補全,對已經有穩定記憶庫、查詢量大的系統效益最明顯;記憶庫一直換、查詢主題高度變動的場景效益有限
• Limitation(作者自陳三點):① 評分預算是照查詢順序固定排程,不會因模型不確定性或 cold-start 動態調整;② 矩陣補全假設有可重複利用的低維結構,查詢分佈太異質就會失效;③ LLM 打分本身有雜訊、可能對 prompt 敏感,補全可能把打分器的錯誤一起放大而非只是省成本

Reviewer 一句話評

把「檢索器自己也該累積經驗」講成一個乾淨的矩陣補全問題,17.5% 打分預算還能維持效果是很實際的成本節省;但目前只在單一資料集驗證,作者自己也承認查詢分佈一旦不穩定,補全反而會把打分器的雜訊放大。

給你的 take-away

• 如果你的系統有穩定記憶庫、大量重複性查詢(客服、個人助理累積使用者資料):EARM「把打分結果存起來重複利用」的思路可以直接省下重排序的推理成本
• 如果你的記憶庫或查詢分佈一直在變(新使用者、新主題不斷出現):這篇方法的前提假設不成立,先別急著導入

論文三｜記憶不該只有一種資料庫:PolyMemDB 用機率推論化解矛盾記憶

PolyMemDB: A Polyglot Database System for AI Memory Management Yu Wang, Jiaheng Lu(University of Helsinki)　·　arxiv: 2608.25577

連結: arxiv · alphaxiv

TL;DR

PolyMemDB 用五種不同資料庫分別存記憶的不同面向(圖、向量、機率、時空、原始內容),並把機率資料庫的 semiring 推論延伸到記憶事實上,對每個事實依時間衰減算出信心分數,讓 agent 面對互相矛盾的記憶時能給出有可信度分數而非非黑即白的答案。

Read Priority

略讀 — 這是系統展示(demo track)論文,沒有大規模量化評測,適合當「記憶資料異質性該怎麼分流存放」的架構參考,不是拿數字來比較效能的論文。

領域背景

多數記憶系統仍用單一儲存範式(純文字或單一向量庫)硬塞所有型態的記憶資料,導致實體關係、時空限制、事件信心這些完全不同性質的資訊被迫擠進同一種格式。長期互動下事實會被修正、推翻,但多數系統只會粗暴地覆寫舊值,既沒有留下溯源紀錄,也讓 LLM 在面對矛盾記憶時只能做二選一的判斷,容易產生幻覺。

中階導讀

• 問題:想像使用者十個月前說喜歡跑步,五個月前抱怨膝蓋痛,上週才剛完成一場馬拉松——「這個人喜歡跑步嗎?」不該是一個簡單的是非題,而是需要把不同時間點、互相衝突的證據一起納入考量。
• 方法:PolyMemDB 把記憶拆成不同型態分別路由:實體關係圖存進 Neo4j、事件信心存進機率資料庫 ProvSQL、時空限制交給 MobilityDB、向量與原始內容分別進 ChromaDB 與物件儲存。查詢採三層 fallback:先查圖(低延遲),查不到才進向量檢索,還是不夠才回頭翻原始內容。面對矛盾事實,系統把每筆觀察依時間做指數衰減,算出正向驅動、負向抑制、證據衝突、證據不足四個機率狀態,合成一個 [-1, 1] 的「淨證據可信度」分數。
• 為什麼重要:記憶資料本來就是異質的,把不同性質的資料塞進同一種資料庫,問題根源不會消失,只是被藏起來;用對的資料庫存對的資料類型,再讓機率推論處理矛盾,LLM 才有機會給出「有幾分把握」的答案而不是硬猜。

深入要點

• 展示案例:LongMemEval 一則 48-session 對話,PolyMemDB 建出 229 個實體、221 條關係的記憶圖,能追出「最愛作者的書打幾折」這類需要長距離依賴的答案,並附上完整證據鏈
• 第二個展示場景:從長對話裡自動抽取「畢業旅行」行程,並用時空地圖視覺化,依時間視窗篩掉不相關地點(例如把整趟旅程精確篩到 5 個義大利城市)
• 信心計算範例:針對「Alice 喜歡跑步嗎」,近期完成馬拉松帶來的正向驅動只有 47.2%,但歷史上的膝蓋痛與熱衰竭事件讓「證據衝突」高達 52.3%,最終淨可信度只有約 0.22——系統據此讓 LLM 給出「投入但過程受挫」的細緻回答,而非簡單的「喜歡」或「不喜歡」
• Limitation:這是系統展示(demo track)論文,沒有大規模量化評測跟 baseline 比較,只有三個質化的展示場景 ⚠️
• 落地門檻:同時維運 Neo4j、ProvSQL、MobilityDB、ChromaDB 加物件儲存五套異質資料庫,對小團隊是不小的基礎設施成本
• 原始碼已開源:github.com/wangyu-1999/PolyMemDB

Reviewer 一句話評

用資料庫工程的視角拆解記憶碎片化問題,機率推論處理事實衝突的想法紮實且可解釋;但這是系統展示論文而非量化評測,五套資料庫的維運複雜度也是現實部署要付出的代價,適合當架構參考而非直接照搬的解法。

給你的 take-away

• 如果你在設計企業知識庫、或需要處理「長期記憶裡互相矛盾的事實」:PolyMemDB 用機率分數取代二元判斷的做法值得參考,尤其是需要對答案附可信度、可追溯證據鏈的場景
• 如果你的團隊資源有限:不用照抄五套資料庫的架構,可以先把「機率信心 + 資料溯源」這個子系統的想法,套用到現有的單一資料庫上

今日收穫

之前以為記憶系統的優化空間主要在「壓縮演算法」和「檢索模型」,今天發現真正的槓桿點分散在三個完全不同的工程層次——上下文該被「環境化」而不是「序列化」、檢索器自己要不要也有記憶、以及記憶資料本身該用什麼資料庫存。這三層任何一層沒顧到,長期記憶系統的「準確率數字」都只是暫時領先。

參考資料

• Scroll 論文(Context as an Environment: Programmatic Context Management for Long-Horizon Agents):arxiv 2608.21690、程式碼參考 QwenPaw scroll 分支
• EARM 論文(The Retriever Should Remember: Experience-Amortized Reranking for Long-Term Agent Memory):arxiv 2608.22767
• PolyMemDB 論文(PolyMemDB: A Polyglot Database System for AI Memory Management):arxiv 2608.25577、程式碼 GitHub