AI Agent 可以在單次對話裡展現很強的推理能力，卻不代表它真正擁有「過去」。只要 session 結束、context 被壓縮，或工作轉交給另一個 Agent，先前談過的偏好、限制與決策便可能一起消失。
直覺上的解法，是把更多歷史紀錄塞回 context window。但 @0xWast3 在〈Memory Engineering〉提出一個更準確的切入點：記憶不是保存完整對話，而是決定哪些資訊值得跨對話延續、如何更新，以及何時應該被遺忘。
這也讓 Memory Engineering 成為不同於 Prompt Engineering 的獨立工程問題。
更長的 Context Window 為什麼不是記憶
把完整對話反覆交給模型，至少有三個結構性問題：
- 成本會持續增加：歷史愈長，每次請求都必須重新處理更多 token；
- 資訊沒有輕重之分：隨口提到的午餐，可能與安全限制占據相同篇幅；
- 舊事實不會自動失效：當使用者改變偏好，舊答案與新答案可能同時留在 context 裡。
因此，context window 比較像工作桌面：放置這次任務需要的材料。記憶系統則像檔案管理制度，負責判斷什麼該歸檔、哪些版本有效，以及這次應該取出哪幾份資料。
| 工程範圍 | 解決的問題 | 主要時間尺度 |
|---|---|---|
| Prompt Engineering | 模型這次應該如何回答 | 單次指令 |
| Context Engineering | 模型這次應該看到哪些資訊 | 單次請求或任務 |
| Memory Engineering | 哪些資訊應該延續、更新與退出 | 跨 session、跨任務 |
Memory Engineering 的重點不是「存得更多」，而是維持記憶的品質與生命週期。
記憶不是資料庫，而是一條五階段管線
原文把記憶系統拆成五個階段：Capture、Consolidate、Retrieve、Reconcile 與 Decay。這五步分別控制記憶的進場、整理、使用、更新與退場。
1. Capture：先拒絕不值得保存的資訊
Capture 決定哪些內容能進入長期記憶。最實用的判斷題不是「這句話看起來重要嗎」，而是：三個月後，它仍然可能成立或有用嗎？
例如「我現在被這個 bug 搞得很煩」通常是一次性的情緒；「Code Review 請直接指出問題，不需要寒暄」則是可重複使用的偏好。前者留在當次 context 即可，後者才值得跨 session 保存。
因此 Capture 首先是一套拒絕機制。沒有這層過濾，記憶庫很快就會變成另一份完整聊天紀錄。
2. Consolidate：把重複訊號合成一條可信記憶
相同偏好可能在不同對話中以不同句子出現。若每次都新增一筆，不只浪費空間，也會讓檢索結果充滿近似內容。
Consolidate 要做的是把重複、近似或零碎的訊號合併，並保留來源與強度。例如三次出現「回覆請簡潔」，應該提高同一筆偏好的可信度，而不是產生三條彼此競爭的記憶。
但合併不能只看文字相似度。「我偏好簡潔的 Code Review」與「架構提案需要完整說明」並不衝突；它們的適用情境不同。生產系統至少還要比較主體、範圍與時間，不能只靠單一相似度閾值判斷。
3. Retrieve：只取回這次真正需要的部分
記憶只有在正確時機被取回，才會產生價值。每次把整個記憶庫注入 prompt，只是把 context window 的問題搬到另一個地方。
較合理的檢索會同時考慮：
- 與當前任務的語意相關性；
- 記憶的新鮮度與有效期限；
- 過去被確認或使用的次數；
- 記憶本身的可信度；
- 這次請求允許使用的 token 預算。
最後只回傳少量、附帶來源的記憶。目標不是召回所有可能相關內容，而是避免無關記憶稀釋模型注意力。
4. Reconcile：新舊事實衝突時，不要默默猜答案
真正困難的不是保存事實，而是事實會改變。
假設記憶庫原本寫著「部署區域是東京」，新訊息卻說「已遷移到新加坡」。系統至少需要三種處理結果：
- Supersede：新事實明確取代舊事實；
- Coexist：兩者適用於不同專案、環境或時間；
- Flag conflict：證據不足，保留衝突並要求確認。
關鍵是不要讓模型在背景中自行挑一個答案。對部署設定、法規要求或客戶資料這類高風險資訊，衝突狀態本身就是必須被看見的資料。
5. Decay：遺忘是功能，不是故障
如果記憶只能增加，系統終究會被過期偏好、已完成任務與失效限制填滿。Decay 會依照時間、使用頻率、再次確認與有效期限，逐步降低記憶權重。
低於門檻的資料可以先封存，而不是直接刪除。這樣既能避免它繼續影響回覆，也保留追查錯誤與恢復資料的可能。
遺忘的目的不是節省硬碟，而是降低陳舊資訊對決策的污染。
最小可用的記憶資料模型
向量只是找相似內容的索引，不是完整的記憶模型。若要支援上述生命週期，一筆記憶至少需要這些欄位：
| 欄位 | 用途 |
|---|---|
content | 經過整理、可直接使用的事實或偏好 |
scope | 適用的使用者、專案、環境或任務 |
source | 原始對話、文件或事件，供追溯與審查 |
confidence | 目前的可信程度 |
valid_from / valid_until | 事實的有效期間 |
supersedes | 被這筆記憶取代的舊版本 |
last_reinforced_at | 最近一次被確認的時間 |
status | 啟用、衝突、失效或封存 |
這裡刻意不先設計複雜的 class hierarchy，也不綁定特定向量資料庫。先讓「來源、範圍、版本與狀態」成為可查詢資料，通常比先調 embedding 模型更重要。
從原型走向正式系統，應該驗證什麼
原文也明確提醒：程式碼只作架構示意，正式系統仍需要持久化儲存、embedding 基礎設施，並依領域調整衰減率與 consolidation thresholds。這些參數應該由實際資料與失敗案例校準。
最小的評估集合可以先回答五個問題：
- Capture 是否把短暫雜訊誤存成長期記憶？
- Consolidate 是否把不同情境的資訊錯誤合併？
- Retrieve 的前幾筆結果，是否真的足以支持當前任務？
- Reconcile 是否能辨識知識更新，並在不確定時停止猜測？
- Decay 是否封存了仍在使用的關鍵限制？
LongMemEval 將長期對話記憶拆成資訊擷取、跨 session 推理、時間推理、知識更新與拒答等能力；它也顯示，單靠 long-context 模型並不能消除長期互動中的記憶落差。這類評估比「資料庫裡存了幾筆」更接近真正的產品品質。
若任務涉及帳務、醫療、法規或基礎設施設定，還應加入人工覆核、租戶隔離、敏感資料刪除與完整 audit log。記憶提高便利性，也同時擴大資料治理的責任。
結語：好的記憶系統，知道什麼不該記得
更大的 context window 可以讓模型一次讀更多內容，卻不會替系統判斷哪些資訊值得延續，也不會自動解決重複、衝突與過期問題。
Memory Engineering 真正管理的是一條生命週期：Capture 控制進場、Consolidate 降低重複、Retrieve 控制注意力、Reconcile 處理變更、Decay 負責退場。
對多 session、長任務或多人協作的 Agent 而言，是否擁有「過去」，不是由模型參數量決定，而是由這條管線是否可靠決定。