# 16K 到 128K，Agent 記憶增益從 +18 縮至 +6：EvoMemBench 子集複測與 Token 成本解剖 > Canonical: https://vxi.me/zh-tw/posts/evomembench-agent-memory-budget-replication/ > Locale: zh-tw > Published: 2026-11-02 > Updated: 2026-11-02 > Markdown: https://vxi.me/zh-tw/posts/evomembench-agent-memory-budget-replication.md
EvoMemBench 增益審查圖：左側為論文口徑（作者自報），Finding 3 報告 16K 檔最佳記憶增益 +14.5 分；中間是預註冊探針，只把上下文預算從 16K 放大到 128K，並把 token 按用途拆開；右側為我方在 Gorilla File System、每格 50 題上的複測，BM25 增益 +4.0 蒸發到 0.0，ACE 增益 +18.0 收窄到 +6.0，ACE 記憶模組佔其自身輸入的 36.5%，輸出約為無記憶基線的 7.4 倍。複合判讀 PARTIAL，僅適用於單環境、閘道器標註端點與單次運行，Finding 5 未測。
在 Gorilla File System 子集上檢查記憶增益對上下文預算的依賴，以及記憶模組自身的成本。數值來自一手複測；不裁定論文在其 DeepSeek-V3.2 原口徑下的結果。
給 Agent 加記憶的系統越來越多，每個都說自己會越用越聰明。但有一個問題很少被正面回答：上下文視窗也在變大。如果模型一次能讀下的東西越來越多，提前存好的記憶還值多少錢？ EvoMemBench 恰好給了這條曲線一個數字。它把 15 種記憶方法放進同一套評測協議，報告說：上下文預算從 16K 放大到 128K，記憶方法相對無記憶基線的最佳增益從 +14.5 分縮到 +8.5 分，而且在 128K 檔，已經有記憶方法掉到無記憶基線以下。 我關心的是，這條曲線換一個骨幹還成不成立——尤其是換成最便宜的那一檔。理由很實際：這種實驗的量級（128K 檔要一遍遍回放長上下文）用旗艦價根本跑不起，選骨幹時先被價格篩掉一輪；而我關心的部署場景裡，用量最大的主要也是便宜檔位。所以我沒有複刻論文的全套設定，而是預先註冊了一個縮減版問題：在閘道器能拿到的最便宜的 GPT 檔位上、單個執行環境裡，增益隨預算收窄的方向還在不在？ 結論先放這裡：**方向在。** 我跑出的最佳增益從 16K 的 +18.0 分縮到 128K 的 +6.0 分，兩種記憶方法同向收窄。但論文裡最尖銳的那一幕——記憶在 128K 跌破基線——沒有出現：檢索記憶的增益只是歸零，程序型記憶還留在基線之上。複合判讀是 PARTIAL，證據邊界見文末。 ## 先把證據等級分清 這篇論文（arXiv:2605.18421，香港科技大學廣州等機構）2026 年 5 月發 v1，10 月 30 日更新到 v3，不是一篇新論文。它做的事，是給"Agent 的記性到底幫不幫忙"這個問題立座標系：一條軸是記憶的作用範圍（單個任務之內 / 跨任務），另一條軸是內容型別（知識 / 執行），構成四象限；六個資料集按 Table 2 共 2,954 條評測樣本，分別落進四個象限；15 種記憶方法歸為六個家族，在統一協議下與長上下文基線對比。有一個條件必須隨時帶上：**論文裡所有記憶方法共用同一個骨幹 DeepSeek-V3.2**，它的排名是這個骨幹下的排名，脫離骨幹談排名沒有意義。 論文的八條結論裡，與本文直接相關的有三條半。長上下文基線依然很強，在知識保持與修訂上居首（Finding 1）；記憶的瓶頸在修訂而非檢索，方法們擅長把資訊存下來，不擅長在證據變化時改掉舊知識（Finding 2）；再深一層，瓶頸是把存下的資訊形成可複用的知識，而不只是存得更多（Finding 6）；程序型記憶最適配執行類任務（Finding 4）；還有難度翻轉：易題上記憶是負增益，難題上只有記憶能得分（Finding 5）——這半條我沒能測，原因在文末交代。 以上全部是作者自報。我的複測只碰了其中一條：Finding 3 的增益—預算曲線，而且只在一個象限的一個環境裡。 ## 我的複測設計：最便宜的骨幹，只測一條曲線 這次實驗預註冊過，設定在開跑前就全部定死，如下。子集取四象限中的 InEp-Exec（同一回合內的執行任務），只跑其中的 Gorilla File System 一個環境——它是一組多輪工具呼叫任務，任務成功與否由官方 runner 自帶的檢查器判定，不需要額外裁判。三臂：A0 無記憶基線；A1 是 BM25 檢索記憶；A2 是程序型記憶 ACE。兩檔上下文預算：16K 與 128K。每格 50 條，共 300 個 episode，官方協議參數（函式呼叫模式、長上下文雜訊、記憶作用域）照官方指令碼原樣。 骨幹用第三方 OpenAI 相容閘道器上標註為 gpt-6-luna 的端點，全程固定不換。這裡有一條身份邊界必須先說：**標註是閘道器給的，它實際服務的模型無法從我這一側獨立核驗**。所以下文所有我方數字，都只對"這個標註端點"成立，是論文 DeepSeek 口徑的一個變體口徑，不是同一張表。 與論文設定的出入與版本細節，開跑前就寫進了實驗計劃，先交代三件： - **樣本數：v3 與倉庫一致，每環境 50 條。** 這篇論文 v1 的 Table 2 曾寫每環境 200 條，v3 已改成 50 條，官方倉庫實發的也是 50 條，我跑的就是這 50 條。這同時意味著：每環境 50 條就是論文自己的評測規模，後文 ±14 點的統計區間，論文的單環境數字同樣揹著。 - **程序型記憶換了實現。** 計劃裡原定 ReasoningBank，但它隨倉庫釋出的實現硬性依賴另一家供應商的嵌入金鑰，我只有閘道器這一條接入，於是換成同為程序型家族、且是論文另一頭條方法的 ACE。這不是同一個方法，判讀時只能按家族方向看，不能按方法對位看。 - **記憶臂換了一層傳輸。** 作者給記憶方法準備的呼叫通道是另一家雲端廠商的批次介面，其 OpenAI 相容後端又拒絕記憶型別；我在本機工作副本裡只替換了傳輸層，協議、提示、記憶邏輯、截斷與評分全部用固定提交的官方程式碼。順帶交代一處上游自帶的不對稱：作者的 OpenAI 後端給 A0 臂的呼叫帶了 temperature 1，記憶臂走的路徑不傳這個參數——我原樣保留了它，沒有為了對齊去改程式碼，所以三臂之間除了記憶，還隔著這一層生成參數差異。 ## 結果：收窄複現，跌破沒有出現 六格成功率如下（每格 n=50，官方成功判定）： | 臂 | 16K | 128K | 增益（對同檔 A0） | |---|---|---|---| | A0 無記憶 | 38%（19/50） | 44%（22/50） | — | | A1 BM25 檢索 | 42%（21/50） | 44%（22/50） | +4.0 → 0.0 | | A2 ACE 程序型 | 56%（28/50） | 50%（25/50） | +18.0 → +6.0 | 兩種記憶的增益都在預算放大時收窄，最佳增益從 +18.0 縮到 +6.0。論文在 DeepSeek 口徑、四個環境上報告的是 +14.5 → +8.5（中間並不單調：64K 檔曾低到 +7.8，128K 檔又回升到 +8.5）。量級同階，方向一致——但這兩組數字不是同一張表的格子，不能並排比大小。 128K 檔的細節值得單獨說。論文說這一檔已有方法跌破基線；我這裡沒有。BM25 的增益恰好蒸發到零（44% 對 44%），停在"跌破"的門檻上，沒有邁過去；ACE 還在基線之上 6 分。這個結果既不證實也不反駁論文的子句：我只測了 15 種方法裡的 2 種、4 個環境裡的 1 個，而且選的恰是譜系兩端——最簡單的檢索記憶，與論文執行象限裡最強的那一類程序型記憶；論文點名在 128K 跌破的 MemAgent、MemoBrain 都不在其中，所以“沒有跌破”有一部分是選擇本身決定的。能說的是，在這個子集和這個骨幹上，"記憶在 128K 變成負資產"沒有發生，發生的只是"便宜的記憶先失效"——檢索記憶的增益對預算最敏感，程序型記憶的增益更耐久。把 ACE 那 12 個點的收窄拆開看：一半來自基線自己變強（A0 多對了 3 條任務），另一半來自 ACE 回落（少對了 3 條）——兩個變動都只有 3 條的量級，合起來是圖形，拆開講不成故事。這一格也與論文 Finding 4 同向：三臂裡唯一的程序型方法 ACE，兩檔都是最強的那一個。 統計上要潑一盆冷水：每格只有 50 條，一格 95% 區間大約 ±14 個點，4 分的差距不過兩條任務。好在六格跑的是同一批 50 條任務，可以配對著看成敗翻轉：16K 檔，ACE 比基線多對 9 條、少對 0 條；但把收窄幅度本身拿去做配對 bootstrap，ACE 那 12 個點的 95% 區間下限正好壓在 0 上，BM25 的收窄與零無法區分。所以本文的方向判讀是描述性的：圖形與論文同向，ACE 一臂有配對證據墊底；單看某一格去爭輸贏，是在雜訊裡找結論。 ## 記憶要交的租金：成本解剖 論文報告了分數，也報告了各方法的總 token——但那是任務執行與記憶模組合併的總數（見其附錄效率表）。它沒有把記憶模組自身的呼叫單獨拆出來。這次我按用途拆開，得到一組論文裡沒有的數字。 300 個 episode 共消耗約 1517 萬輸入 token、54 萬輸出 token。ACE 在自己的 100 個 episode 裡，記憶模組——每輪之後的反思與經驗策展呼叫——吃掉 266 萬 token：只算 ACE 自己的輸入，記憶模組佔約 36.5%；攤到全程 300 個 episode 的總輸入，則是 17.6%。它的輸出 token 約為無記憶臂的 7.4 倍，因為反思和策展都是生成型呼叫；而輸出單價是輸入的 6 倍，按金額算，這 7.4 倍比輸入端的佔比更傷帳單。換句話說，ACE 每花 100 個輸入 token，約 36.5 個花在了維護記憶上，而不是推進任務本身。BM25 不產生記憶維護呼叫：索引與檢索都在本機做，不呼叫模型；但檢索出的文字仍要進上下文，那部分輸入 token 記在它自己的任務帳上——它省的是維護呼叫，不是上下文。 量級感可以和論文自己的效率表對一下：DeepSeek 口徑、128K 檔，ACE 的總 token 約為無記憶基線的 1.8 倍，多出的部分約佔 ACE 總量的 43.5%——與我這裡拆出的 36.5% 是同一個量級（口徑不同：論文是總 token 對基線之比，我的是 ACE 輸入內部的用途拆分）。 這組數字改變了"記憶值不值"的演算法。+18 分的增益不是免費的，光 ACE 一家的租金就是自身輸入的三分之一還多，外加七倍多的輸出量；而且這筆租金與預算檔無關地存在——128K 檔增益縮到 +6 分時，ACE 的記憶模組仍然吃掉了幾乎同樣多的 token（16K 檔 134 萬、128K 檔 132 萬）。評估一個記憶方法時，記憶自身的呼叫應該計入方法成本，不能藏在基礎設施裡一筆帶過。按 Luna 檔的公開標價（輸入 0.20 美元、輸出 1.20 美元，均按每百萬 token）折算，這次 300 條任務的總價約 3.7 美元（閘道器帳戶的實際計價以其自身為準，我看不到）——便宜的是骨幹，貴的是結構。 ## 沒測的部分 - **Finding 5（難度翻轉）未測。** 預註冊裡留了一個次級探針，用作者自帶的難度分檔在 CrossEp-Know 象限上測"易題記憶為負、難題記憶為正"。探針跑到試點階段，閘道器帳戶額度耗盡，我把它叫停了，沒有取得可判讀的資料。所以本文對 Finding 5 不下任何結論，它在上文出現時只是作者自報。 - 論文的長上下文對照（Gemini-3-Flash、GPT-5-mini 等專有模型）我無法複跑，其分數按作者自報引用。 - 其餘三個象限、另外十三種方法、論文的 DeepSeek-V3.2 原口徑，都不在本文證據範圍內。 這與本部落格此前的 Beacon 跨工具記憶實測正好接上。那次的結論是：記憶只對"倉庫本身推導不出的知識"有增量，自動捕獲與蒸餾層脆弱。兩次證據形態不同——那次是單系統深挖，這次是橫評協議下的子集複測——但指向同一件事：**記憶的增益從來不是預設存在的，它是一組條件的函式**。這次補上的條件是預算：上下文越便宜、越大，預先存好的記憶就越不值錢；先失效的，是只做檢索的那一類。 ## 結論 如果你在給 Agent 選記憶方案，這次複測能支援的用法只有三條。第一，先報預算再談增益：任何記憶方法宣稱的提升，都要問一句是在多大上下文預算下測的，預算放大一檔，增益可能就蒸發過半。第二，把記憶模組自己的 token 寫進成本表：生成型記憶（反思、策展、總結）的租金可以達到其自身輸入的三分之一還多（本例 36.5%），它不隨增益收窄而減少。第三，在這類工具呼叫任務上，程序型記憶（本例的 ACE）兩檔都更強，但要為它的呼叫成本付費；純檢索記憶在預算充足時增益最先歸零，只適合預算真正受限的場景。出了這個環境先別急著搬：論文 Finding 7 顯示，網頁搜尋、具身等其他執行領域最適配的記憶形式並不相同。 至於這篇基準本身，我的判讀是：Finding 3 的收窄模式，換了一個端點、縮到一個子集，方向仍然對得上，這是它最有用的部分；只是端點身份無法獨立核驗，這算跨端點的探索性複測，不構成跨骨幹的證明。128K 跌破基線的更尖銳說法，在我的子集裡沒有出現，要判斷它對更多方法是否成立，需要有人在原口徑上跑完剩下的十三種方法。那不是本文的結論，是本文留下的作業。 --- *證據邊界：論文數字均為 arXiv:2605.18421 v3 作者自報；我方數字只對上述子集、三臂兩檔與閘道器標註端點成立，單次運行。完整回執（含六格原始計數、token 拆分、偏差登記與統計限制）、逐題資料與配對分析指令碼已隨本文公開（見文首 publicRepository），可逐檔案校驗 SHA256SUMS。* ## Verification context - Level: first-party - Verified: 2026-11-02T00:00:00.000Z - Environment: 官方倉庫 DSAIL-Memory/EvoMemBench @5f550e0c，InEp-Exec 子集（BFCL multi_turn_ours）官方 runner 與評分 - Environment: Gorilla File System 環境，倉庫實發的全部 50 條樣本，三臂 × 兩檔預算共 300 個 episode - Environment: 骨幹為第三方閘道器標註為 gpt-6-luna 的端點（標註身份無法獨立核驗，判讀以該標註端點為界） - Evidence mode: mixed - Public repository: https://github.com/vxime/evomembench-agent-memory-replication - Evidence commit: 7e31af44c93fa88fb130e9417d36951b5ca1ac9d - Evidence receipt: https://vxi.me/evidence/evomembench-agent-memory-budget-replication.json