編按：本文綜合整理自 Zero-Mem 原始論文、論文 HTML 全文與 Hacker News 討論，並加入 Siami 編輯部觀點與數據解讀。論文目前為 arXiv 預印本，尚不能把 benchmark 結果視為所有產品部署的保證。
AI agent 要記得幾週前的對話、工具結果與任務狀態，通常不只是把資料存進資料庫。許多記憶系統會再呼叫語言模型，把歷史內容摘要、分類、合併或改寫成記憶條目；每次更新與檢索都可能新增 token、延遲與推論費用，也可能在摘要時遺失原始細節。
Zero-Mem 提出另一條路：記憶建立、組織、路由、檢索、證據補全與校準都不呼叫 LLM，也不消耗 LLM 的輸入或輸出 token。系統保留原始互動軌跡，直到最後根據檢索證據回答問題時，才讓 reader LLM 上場。
不是把所有對話塞回 context
「零 token 記憶操作」不等於讓模型吞下全部歷史。Zero-Mem 先把原始互動整理成兩個不需要生成式改寫的結構，再針對問題取回證據：
- 實體—上下文關係圖：連接分散在不同互動中的人物、事件、屬性與相鄰線索，適合需要跨紀錄追關係的查詢。
- 時間階層：依 turn、局部窗口、episode 與 session 保存先後順序，避免把不同時間的狀態混為一談。
- 查詢條件路由：分析問題需要較多關係證據，還是較多局部與時間脈絡，再調整兩種檢索視角的權重。
- 證據閉包與校準：補回圖中的橋接節點和時間鄰近內容，並以確定性規則排除不符人物、時間或答案類型的候選。
這個設計與「先請 LLM 寫摘要，再搜尋摘要」的差異，在於原始軌跡始終是 source of record。檢索結果可以回到哪一段對話、哪一次 session，而不是只能相信模型先前寫下的二手記憶。
實驗怎麼做
研究團隊使用兩類 benchmark。LoCoMo 測試跨多個 session 的長期對話記憶，包括單跳、多跳、時間推理與開放式問題；HotpotQA 的記憶評估變體則混入干擾文章，將 context 拉長到 56K、224K 與 448K token，測試系統能否在很長的資料中連接分散證據。
為了讓比較聚焦在記憶管線，Zero-Mem 與各基線使用相同的最終 reader 與相近的 context 預算，並分別測試 GPT-4o-mini 和 Qwen2.5-14B-Instruct。實驗硬體為 NVIDIA RTX 4090，主要比較的 retrieval budget 統一限制為 top-5。
在統一的 GPT-4o-mini 效率設定中，論文列出的結果如下：
- Zero-Mem：F1 59.15、BLEU-1 52.96，記憶操作 token 為 0。
- LightMem：F1 38.44、BLEU-1 34.36，記憶操作使用 877,086 token。
- GAM：F1 53.75、BLEU-1 47.51，記憶操作使用 28,570,674 token。
- Zero-Mem 的記憶操作總時間為 334.77 秒、每次查詢 0.22 秒，相較最快的比較基線 LightMem 減少 57.6% 延遲。
數據解讀：57.6% 不是「整個 agent 快 57.6%」
這個百分比只比較最終問答之前的記憶操作，而且是在共同硬體、相同並行設定與指定 benchmark 下得出。最後 reader LLM 的推論時間不在這項減幅裡，實際產品還會受到資料庫、網路、索引規模、更新頻率與查詢型態影響。因此，正確說法是「論文設定下，記憶操作延遲比最快基線低 57.6%」，不能延伸成整個 agent、任何工作負載或雲端帳單都會等比例下降。
HotpotQA 結果提供另一個觀察：Zero-Mem 在 GPT-4o-mini 下，56K、224K、448K context 的 F1 分別為 72.07、66.43、65.04；使用 Qwen2.5-14B 時則為 68.58、65.47、61.02。context 越長仍會掉分，但論文表格中，Zero-Mem 在兩種 reader 與三種長度都高於列出的基線。這表示優勢不只來自「不花 token」，雙視角證據選擇本身也可能改善長資料中的定位能力。
消融實驗進一步顯示，完整模型在 HotpotQA 56K 設定的 F1 為 72.07；只留關係圖降至 62.50，只留時間階層則降至 54.88。移除 evidence closure 後為 67.90，移除 calibration 後為 70.13。至少在這個測試中，關係圖、時間脈絡、證據補全與校準不是可隨意刪除的裝飾模組。
為什麼這件事重要
Agent 記憶的核心風險不只是費用，而是證據被改寫後還能不能追溯。假設使用者先說住在台北，數月後搬到台中；生成式記憶若把兩段對話合併成一句摘要，可能留下舊地址、覆蓋新狀態，或混成不確定描述。之後的 agent 即使忠實引用摘要，也可能在一開始就站在錯誤證據上。
Zero-Mem 保留原始軌跡，再以關係與時間結構選證據，讓「目前答案根據哪一次互動」有機會被檢查。這對客服、醫療行政、企業知識庫、長期個人助理與自動化開發 agent 都很關鍵：錯誤記憶往往會跨 session 累積，並影響後續工具操作，而不是只產生一句無傷大雅的幻覺。
另一個重要意義是成本結構。當記憶更新也必須呼叫 LLM，高頻互動服務會在使用者尚未提問前就持續產生推論費。若建立索引、路由與校準能改用 encoder 和確定性程序，團隊便可把昂貴的生成模型集中在真正需要語言推理的最後一步。論文尚未證明所有場景都適合這種取捨，卻清楚提出了一個值得工程團隊量測的方向：不要預設「記憶一定需要另一個 LLM 來管理」。
質疑與限制：zero-token 不等於 zero-compute
論文明確提醒，Zero-Mem 仍需 encoder 推論、圖與階層索引、檢索、證據排序和確定性校準。這些工作消耗 CPU／GPU、記憶體、儲存空間與維護時間，只是不會出現在 LLM token 帳單中。若資料更新非常頻繁、圖結構龐大或 encoder 很重，總持有成本仍需以 production telemetry 驗證。
Hacker News 討論也提出更難的測試：當同一實體跨 session 發生矛盾、屬性變更或遭惡意植入錯誤紀錄時，系統能否同時保留新舊狀態、指出衝突，並揭露哪一段來源支持最後答案？除了 F1 與 BLEU-1，實務部署還應追蹤 unsupported-answer rate、evidence recall、過期資訊誤用率與對抗性 trace 下的可靠度。
目前論文是 2026 年 7 月 31 日提交的 arXiv v1 預印本。作者表示會在同行評審後公開程式碼與實作細節；在獨立團隊完成重現之前，最穩健的結論是：Zero-Mem 展示了不靠生成式中介記憶也能取得有競爭力結果的可能性，而不是已經證明它能取代所有既有 agent memory 架構。
網路技術社群怎麼看
Hacker News 的回應大致分成三條線。第一類認為真正突破是「不再生成式重寫記憶」，因為這改善稽核與來源追溯；第二類開發者正在嘗試以 KV cache、attention 或較簡化的 NER 做相似檢索；第三類則提醒，zero-token 容易被誤讀為免費，encoder 與索引成本必須一起呈現。
討論串在本文整理時由 Hacker News API 顯示 62 分、10 則後代留言。這些留言反映早期開發者觀察，不是經過同儕審查的證據；但它們指出下一輪實驗值得補上的問題，尤其是跨 session 狀態突變、衝突證據與實際維運成本。
延伸影片：IBM Technology 介紹工作、語義、程序與情節等 agent memory 類型，可作為理解記憶系統的概念背景；這不是 Zero-Mem 團隊的官方發表影片。
接下來看什麼
判斷 Zero-Mem 能否從論文走向實際 agent，可持續追蹤以下項目：
- 作者承諾的程式碼儲存庫何時提供可重現版本與完整設定。
- 第三方是否能在 LoCoMo、LongMemEval 與真實長期 agent 日誌重現品質和延遲數據。
- 對矛盾、過期、跨使用者污染與 prompt injection 記憶的防禦表現。
- encoder、索引更新、儲存與查詢的完整成本，是否真的低於生成式記憶管線。
- provenance 能否在 UI 或 API 中清楚呈現，讓開發者與使用者查核每個答案的來源。
Zero-Mem 把問題從「要用哪個模型幫 agent 寫摘要」往前推了一步：記憶是否可以先是一套可追溯的證據系統，只有在真正需要回答時才使用生成模型。這個命題即使最後需要混合式方案，也足以改變團隊評估 agent memory 的方式。
網友熱門留言 (3)