LongMemEval-V2：測 agent 長期記憶

LongMemEval-V2 用 451 題測試 agent 能否記住 Web 環境經驗，而不只是使用者歷史。

對很多 agent 來說，記憶一直是個卡點。問題不只在於要不要記住使用者說過什麼，而是能不能記住某個 Web 環境的規則、介面變化、常見失誤，還有哪些工作流程真的有用。這篇 LongMemEval-V2: Evaluating Long-Term Agent Memory Toward Experienced Colleagues，就是要把這件事拿來直接測。

它想回答的不是「agent 有沒有記憶功能」，而是更實際的問題：當 agent 在同一個環境裡反覆工作後，記憶系統能不能把那些經驗累積起來，讓它表現得像一個熟悉現場的同事，而不是每次都從零開始。

這篇在解什麼痛點

現有很多 agent 記憶評測，重點都放在使用者歷史、短對話軌跡，或是任務有沒有做完。這種測法有它的價值，但它會漏掉一大塊真實場景裡很重要的東西：環境本身的經驗。

在 Web 工作流程裡，很多成功與失敗不是來自單次對話，而是來自你有沒有記住某個系統的靜態狀態、它會怎麼變、哪種流程比較穩、哪些坑很容易重踩。若 benchmark 沒有把這些納進來，就很容易高估記憶系統的實用性。

LongMemEval-V2 的核心想法很直接：記憶不該只是存資料，而是要把反覆接觸環境後累積的經驗內化進去。也就是說，它評的不是背誦能力，而是經驗沉澱能力。

方法怎麼做

LongMemEval-V2 一共收了 451 題手工整理的問題。這些問題被整理成五種 Web agent 的記憶能力：static state recall、dynamic state tracking、workflow knowledge、environment gotchas、premise awareness。這五類本身就很能反映作者想測的不是單純問答，而是 agent 對環境的整體理解。

每一題都會配上歷史 trajectories，而且這些歷史可以多到 500 條 trajectories、總計 115M tokens。這代表它不是小型回憶題，而是很明顯的長上下文記憶測試。對記憶系統來說，重點不是能不能看懂一段歷史，而是能不能在一大堆歷史裡找出有用的那一段。

作者把這個流程定義成 context gathering formulation。白話一點，就是記憶系統先讀歷史軌跡，再吐出可以用來回答問題的精簡證據。這樣的設計，測的不只是存不存得住，也測取回來的內容是不是對的、是不是剛好夠用。

論文在這個框架下比較了兩種記憶方法：

• AgentRunbook-R：一種效率導向的 RAG 記憶法，分成 raw state observations、events、strategy notes 這幾個知識池
• AgentRunbook-C：把 trajectories 存成檔案，再用 coding agent 在增強 sandbox 裡蒐集證據

這個對比很有意思。它不是只在比兩個模型誰比較會答題，而是在比兩種完全不同的記憶工作流：一種偏向檢索，一種偏向主動蒐證。這對實作端很重要，因為很多團隊現在都在想，單靠 RAG 式記憶到底夠不夠，還是要讓 agent 自己去整理、推敲、抓證據。

結果證明了什麼

摘要裡最明確的數字，是 AgentRunbook-C 的平均準確率達到 72.5%。這個成績高於最強的 RAG baseline，後者是 48.5%，也高於 off-the-shelf coding agent baseline 的 69.3%。

這組結果透露出一個很清楚的訊號：單純把資訊檢索出來，和用 coding agent 去歷史軌跡裡蒐證，能力差距不小。換句話說，對長期 agent 記憶來說，「能找到資料」不等於「能把經驗用對」。

論文也提到，AgentRunbook-C 在 accuracy-latency Pareto frontier 上有進步。這句話的意思很務實：它在準確率上更好，但不是沒有代價。作者同時明講，基於 coding agent 的方法有很高的延遲成本。也就是說，效果更好，不代表部署起來就一定輕鬆。

摘要沒有公開更細的 benchmark breakdown，因此看不到五種記憶能力各自的表現差異。就目前公開資訊來看，我們只能確認整體平均準確率與方法間的落差，還不能進一步判斷哪一類記憶最難、哪一類最容易。

不過，從作者的描述可以看出，LME-V2 被設計成一個有挑戰性的測試。就算最強方法拿到目前的最佳成績，也仍然留有不少改善空間。這代表長期 agent 記憶還不是一個已經被解完的題目。

對開發者有什麼影響

如果你在做的是專門跑 Web 工作流程的 agent，這篇論文很值得放進你的評估清單。它提醒我們，記憶不是單純的資料庫問題，而是「經驗管理」問題。agent 要記的不只是事實，還包括環境狀態、流程習慣、常見陷阱，以及哪些前提在這個系統裡成立。

這對很多架構都會有影響。像是依賴 retrieval 的 agent、用 runbook 管理操作步驟的系統，或是要長期維持操作知識的工作流，都會碰到同一個問題：如果只記住使用者，卻沒記住環境，錯誤還是會一再重演。

LongMemEval-V2 提供了一個比較像真實世界的壓力測試。它逼你回答一個很工程化的問題：你的記憶堆疊，到底只是存檔，還是真的把環境經驗吸收進去。對台灣開發團隊來說，這種測法特別適合拿來檢查內部 agent 是否真的能在固定系統裡越做越順，而不是每次都像第一次上線。

但這篇也有明顯限制。摘要沒有說這些方法能不能泛化到 benchmark 以外的環境，也沒有交代不同環境設定下的敏感度。它也沒有告訴我們，五種記憶能力裡哪一種最難，或是 coding-agent 式蒐證在 production 的嚴格延遲要求下是否仍然可行。

所以，這篇論文更像是一個方向明確的壓力測試，而不是一個已經定案的最佳解。它把討論重心從「agent 會不會記得」往前推了一步，變成「agent 能不能真的學會這個環境，並把學到的東西用在下一次任務裡」。

對現在正在做 agent 的團隊來說，這個問題幾乎就是實戰核心。因為真正有價值的記憶，不是把歷史堆起來，而是讓系統在下一次遇到同樣情境時，少犯一次同樣的錯。