使用者曾經因颱風造成物流中斷，獲得一次特殊的全額退款。幾個月後，他為另一筆普通訂單申請退款，客服 Agent 從歷史紀錄中找到了上次的結果：

customer_id: 456
refund_result: full_refund_approved
reason: exceptional_weather_disruption

如果系統只追求「記得越多越好」，很可能把這段經驗整理成：

這位客戶可以全額退款。

這句話和歷史紀錄很接近，卻刪掉了最重要的限制：那是特定訂單、特定原因下的一次例外，不是永久政策，也不是使用者偏好。

上一篇談的是 Agent 中斷後如何從可信的 Checkpoint 繼續。這一篇把時間拉得更長：一項資訊離開原任務之後，憑什麼繼續影響未來決策？

Memory 的價值不是永遠記得，而是讓仍然有用、範圍正確、可以被修正的過去，在適當時機影響現在。

這篇會討論到

• Agent Memory 需要哪些核心角色
• 寫入、取回、修正與停止影響，分別要做什麼決策
• 如何讓 Memory 不只可用，還能更快、更省地被使用
• 最新的 VoiceMem 有哪些設計值得非語音 Agent 借鏡

左邊的 Agent：「放心，我全部都記住了。」
右邊的 Agent：「等一下，真正重要的是哪一筆？」

Memory 不是更長的對話紀錄

Agent 系統裡有很多會被保存的資料，但保存不代表它們具有相同權力。

例如，上一次退款紀錄是原始事件；目前訂單是否符合退款條件，仍由最新訂單狀態與政策決定。Memory 可以提醒 Agent「曾有一次颱風例外」，卻不能直接把新訂單的 refund_eligible 改成 true。

CoALA 原始論文把工作記憶與長期記憶分開，也把讀寫記憶視為 Agent 的內部動作。這個分類最值得借鏡的地方不是名詞，而是責任邊界：對話紀錄、任務進度、跨任務經驗與本輪輸入，本來就不該是同一份資料。

完整的 Memory System 因此不只是一個資料庫，而是一個持續做四次判斷的循環。

設計 Memory，要守住四個節點

從原始事件到未來決策，可以把 Memory 簡化成四個節點：

1. 寫入：哪些資訊值得離開原任務，長期留下？
2. 取回：面對新任務，怎麼用最少成本找到真正相關的記憶？
3. 修正：新證據出現時，舊記憶要補充、改寫，還是退出？
4. 停止影響：哪些內容已過期、被撤回，或不該再被使用？

這四個節點形成閉環。寫入決定未來有什麼可以被找到；取回品質反過來暴露分類與索引是否合理；修正與停止影響則避免系統只進不出，讓錯誤與過期內容一直累積。

接下來不從產品功能出發，而是沿著 customer 456 的退款案例，逐一看每個節點需要做什麼決策。

第一個節點：哪些過去值得留下？

最容易實作的方案，是每段對話結束後都產生摘要，再全部寫進向量資料庫。問題是「發生過」和「未來值得使用」並不是同一件事。

一筆候選記憶至少要回答：

• 未來效用：跨過這次任務後，它仍可能幫助決策嗎？
• 持久性：這是長期事實，還是一次例外與暫時狀態？
• 證據來源：來自使用者明說、可靠工具，還是模型推測？
• 適用範圍：只屬於這筆訂單、這位使用者，還是整個組織？
• 敏感性與期限：真的有必要保存嗎？要保存多久？

這就是升格規則（Promotion Policy）：原始事件先是候選，通過門檻後才成為長期記憶。AWS 公開的 User Preference Memory Strategy Prompt就是一個具體案例，它把候選分成新增、更新與略過，並要求略過一次性事件、暫時狀態、重複、過度推測與敏感內容。這不是通用標準，卻證明「值得記住」可以被寫成可測試的規則。

同一份資料也可能因用途不同而有不同表示：

• 情節記憶保存特定事件：某日因颱風物流中斷，主管核准 order A 一次例外。
• 語意記憶保存經確認的事實或偏好：使用者明確偏好退回原付款方式。
• 程序記憶保存做事規則：退款前必須查詢最新訂單與政策，超過門檻須重新核准。

三者是用途分類，不一定要分成三套資料庫。真正重要的是每筆紀錄保留來源、對象、範圍、觀察時間、可信程度與有效狀態。否則一次 Episode 經過摘要後，就可能悄悄變成永久 Rule。

第二個節點：怎麼又快又準地找回來？

Memory 寫得正確，還不代表用得有效率。資料跨過幾百個 Session 後，如果每次都對全部紀錄做相似度搜尋、取回數十筆結果，再交給模型判斷，延遲、Token 與干擾內容會一起增加。

向量搜尋只回答「哪些文字在語意上相近」。完整的取回路徑還需要：

1. 先用使用者、Tenant、任務、類型、時間與有效狀態縮小範圍；
2. 再依 Entity、主題或關係找到較密集的候選集合；
3. 在候選中排序，只取回足以完成任務的少量內容；
4. 注入 Context 前檢查來源、時間、衝突與目前用途。

AWS 的 RetrieveMemoryRecords回傳的是語意查詢候選，Structured Metadata則能先限制搜尋範圍。兩者放在一起看，正好說明：相似度負責找候選，Metadata 與應用規則負責縮小問題，權威來源才負責確認現在是否仍為真。

下次 customer 456 申請退款時，系統可以取回上次颱風事件，但在真正影響決策前，仍要重新查詢目前訂單、政策版本與核准狀態。取回的是線索，不是授權。

效率也不只是把資料庫查詢從 200 ms 降到 100 ms。更大的改善常來自：不要讓不可能相關的記憶進入昂貴的排序與模型 Context。 2026 年 8 月 26 日發布的 VoiceMem，正好提供了一個最新案例。

最新案例：VoiceMem 如何用更少候選維持品質？

VoiceMem: Streaming Dual-Brain Memory for Real-Time Interaction是一篇 2026 年 8 月 26 日發布的 arXiv v1 preprint。它以即時語音為場景，但最值得借鏡的不是語音，而是它如何重新組織候選空間。

VoiceMem 沒有直接把 Query 丟進整個 Memory Store，而是在底層記憶引擎之上加入一層輕量結構：

• 資訊路徑用 Schema 與 Entity 先定位主題、人物與事件，再把相關紀錄送進最後搜尋。
• Persona 路徑分開管理較穩定的個人特徵，以及「對某個人或事件的態度」，避免所有資訊擠進同一種排序。
• 高密度候選池先排除大量無關資料，讓較小的 top-K 仍能取得足夠資訊。
• 非同步更新在每輪互動後處理新增、修改、刪除或保留，不把所有整理工作都放在回覆關鍵路徑。
• 上層與 Backend 解耦：Routing 與 Index 負責組織候選，底層則保留儲存與相似度搜尋介面。

作者在 LoCoMo 的一個 K=5 設定中，報告分數 91.2、平均 430 個 Memory Token，以及約 134 ms 的 Retrieval Latency。這些不是通用準確率或 Production SLA：論文仍是 preprint，主要表格使用 LLM-as-a-Judge，134 ms 也只是作者環境中的 Retrieval，不含完整 ASR、網路、生成與語音合成。

不過，比單一數字更值得注意的是它的 Ablation：移除上層 Index，在相同 K=5 下 LoCoMo 分數下降 9.9；作者也把同一層 Index 套到 Mem0、LangMem 與 Zep，三個 Backend 都有提升，但提升後的分數仍不同。這表示上層組織具有可移植價值，卻不代表換任何 Backend 都會得到相同效果。

它也可以延伸到非語音場景。論文本身就使用 LoCoMo、LongMemEval、Memora 等文字記憶評估；而在架構上，語音專屬的 Partial Transcript、Speaker ID 與 VAD 可以被替換：

• Chat Agent 在訊息送出後，先依使用者與 Entity 預取候選；
• Coding Agent 讀到 Repository、檔案與錯誤類型時，先定位相關經驗；
• Workflow Agent 進入特定 State 時，先載入該步驟需要的程序與案例；
• Batch 任務先依 Tenant、Task Type 與 Entity 建立候選池，再平行處理。

這些是從 VoiceMem 的解耦架構做出的工程延伸，不是論文已逐一驗證的產品能力。真正能通用的原則是：先組織與縮小候選空間，再做昂貴搜尋；把可非同步的更新移出回應路徑；讓上層記憶管理不綁死單一儲存引擎。

第三個節點：新證據如何改變舊記憶？

假設事後調查發現，order A 並不是因颱風獲得全額退款，而是商品本身有瑕疵。最危險的做法，是新增一筆相反紀錄，卻讓舊記憶繼續正常被取回。下一次查詢可能同時看到兩個版本，最後又把衝突交給模型猜。

新資訊出現時，系統至少要分辨：

因此，衝突不能只靠「最新的贏」。使用者明確陳述通常應高於模型從單次行為做出的推測；正式系統的即時結果，也應高於幾個月前的摘要。修正機制必須比較來源權威性、適用範圍、發生時間與可信程度。

這也是為什麼 Memory Write Path 不該永遠只有 Insert。它還要能定位相關紀錄、合併重複、建立版本關係，並讓一般 Retrieval 預設排除已失效內容。

第四個節點：何時不該再影響未來？

一筆記憶不再影響未來，可能有不同原因：它已過期、使用者撤回、來源被證明錯誤，或系統只想降低低價值內容的取回機率。讀者不需要先背四組英文名詞，只要先問兩件事：

1. 這筆資料是否仍然存在？
2. 它是否仍可能被取回並影響 Agent？

「不再主動召回」不一定代表資料已刪除；「清除聊天」也不一定會同步移除由聊天抽取的偏好、摘要、Embedding、Index 與 Cache。AWS DeleteEvent 文件就明確提醒：刪除 Short-term Event，不會自動刪除由它產生的 Long-term Record，後者需要另外處理。

所以產品若提供「忘記這件事」，至少要說清楚：刪除的是原始對話、長期記憶，還是兩者；索引與衍生副本如何失效；使用者能否查看、修正與逐筆移除。對敏感資料，還應提高寫入門檻、縮短期限，或要求明確同意。

最後一定要做行為驗證：刪除或使紀錄失效後，用相同 Query 再查一次，確認它不會進入 Context，也不再改變 Agent 的回答。API 回傳成功，只能證明一次操作完成；它不能替你證明系統真的忘了。

用同一個案例，跑完四個節點

上線前，可以用 customer 456 做一個最小閉環測試：

1. 完成一次颱風例外退款，確認系統只建立範圍限定在 order A 的事件記憶；
2. 開啟新 Session，確認系統能找到它，但不會直接改變新訂單 State；
3. 檢查取回流程是否先限制使用者、任務、時間與有效狀態，再搜尋少量候選；
4. 修改退款原因，確認舊內容退出一般 Retrieval，新版本保留來源與時間；
5. 要求系統忘記這次事件，確認原始紀錄、衍生 Memory 與 Index 按產品承諾處理；
6. 重跑相同查詢，確認它不再進入 Context，也不再影響退款決策。

如果系統只能證明「資料可以寫入與搜尋」，它完成的是一個歷史資料庫。只有當它能回答「為什麼留下、如何有效找到、怎麼隨新證據改變、何時停止影響未來」，才真正具備可治理的 Agent Memory。

下一篇會沿著最後一道邊界繼續：即使 Agent 想起了正確資訊，它仍可能在錯誤狀態下使用正確工具。Tool Schema 只能檢查參數形狀；可靠執行還需要完整的 Tool Contract。

AI 你怎麼看？