你先告訴一個 AI：「報告裡不要用表情符號。」五分鐘後，它還記得。隔天開同一個任務，它也還記得做到哪裡。再過一週，你開了一個全新的對話，它甚至知道你偏好繁體中文。這三種體驗都很容易被叫做「AI 有記憶」，但系統背後不一定使用同一種機制。
AI Agent 的 memory，可以先理解成：系統把過去產生的資訊保存起來，並在之後需要時重新提供給 Agent 使用的機制。 這份資訊可能只是目前對話中的 message history，也可能是跨 session 保存的偏好、過去任務的摘要、某次工具執行結果，甚至是一整套可搜尋的外部記憶庫。
先記一句：「AI 記得」不等於「模型參數被改了」。很多 Agent Memory 本質上是外部儲存 + 之後重新取回，再把內容放回模型當下的 context。
最短的記憶，其實就是這次對話的狀態
最常見的一層是 short-term memory，也可以叫 thread-scoped memory 或 conversation state。當你問「那第二點呢？」模型之所以知道你說的「第二點」是什麼，通常不是因為它永久記住了，而是系統把前面的對話歷史一起帶進這次推理。LangChain 的現行文件就把 short-term memory 定義成單一 thread 裡維持的 message history 與 agent state。
這層記憶和 Context Window 關係很直接：模型真正能使用的，仍然是這一次 inference 被送進去的內容。當對話變得很長，系統可能必須截斷舊訊息、做摘要，或只保留重要狀態。也就是說，聊天紀錄「存在」和模型「這一輪真的看得到」不是同一件事。
跨對話還記得，通常已經是 Long-term Memory
如果你關掉這次 session，隔幾天開另一個對話，Agent 還能知道某個資訊，那就進入 long-term memory 的範圍。這種記憶必須存在某個持久化位置：可能是關聯式資料庫、文件儲存、key-value store，或支援向量搜尋的資料系統。LangChain 也把 long-term memory 定義成能跨不同 conversation 和 session 保存、之後再取回的資料。
例如一個專案 Agent 可以保存「目前版本是 v0.8」、「上次測試失敗在登入流程」、「使用者偏好 TypeScript」。下一次啟動時，應用程式先讀出這些資料，再決定哪些值得帶回 prompt。模型之所以像是「想起來」，很可能只是系統在它回答前先查了一次資料庫。
這裡也能看出 memory 和 RAG 有一部分相似：兩者都可能先從外部資料取回內容，再放進 context。不過 RAG 通常在找外部知識；Agent Memory 更常保存與這個使用者、任務或 Agent 過去經驗直接相關的狀態。實際系統裡兩者可以共用同一套 retrieval 技術。
「記得你」可能只是 Profile，不是把整段聊天存起來
有些系統不會把每一句對話永久保存，而是抽取少量穩定資訊，整理成 user profile。例如語言偏好、常用單位、專案名稱、工作方式，或明確要求長期保留的設定。下一次對話時，系統讀取 profile，再把相關欄位加進 context。
這種做法和保存完整 transcript 的目的不同。完整紀錄適合追查「當時到底發生什麼」；profile 則適合回答「之後通常應該怎麼配合這個使用者」。如果系統把兩者混在一起，舊資訊很容易越積越多，甚至把一次性的情境誤當成永久偏好。
所以「記憶」至少要問兩件事：系統到底保存了什麼？之後又用什麼規則把哪些內容取回來？只知道「有存」還不夠。
Agent 還需要記得「事情做到哪裡」
對能執行多步任務的 AI Agent 來說，memory 不只是在記使用者。它還可能要保存 task state：已經呼叫過哪些工具、哪個步驟成功、哪個步驟失敗、下一個待辦是什麼、外部系統回傳了哪個 ID。如果這些狀態沒有持久化，程序一中斷，Agent 就可能從頭重做，甚至重複執行有副作用的操作。
這類記憶比較像工作流程的 checkpoint，而不是人類意義上的回憶。它的價值是讓系統可以 resume、retry、audit。對長時間 Agent 而言，「記得自己剛剛做了什麼」往往比「記得使用者喜歡什麼」更關鍵。
記憶不一定每次都全部塞回 Prompt
如果 long-term memory 有幾千筆內容，把全部資料都塞進 prompt 幾乎一定會出問題：context 變長、成本上升、不相關資訊增加，而且真正重要的內容可能反而被淹沒。因此實際 Agent 常會先做 retrieval，只挑這次任務最相關的幾筆記憶。
這時就可能用到 Semantic Search、metadata filter、時間排序，或更簡單的 key lookup。例如問「上次部署為什麼失敗？」系統可以先用專案 ID 限定範圍，再搜尋和 deployment failure 最接近的事件。Memory 的品質因此不只取決於「存了多少」，也取決於 write、retrieve、update、delete 這幾個步驟設計得好不好。
Memory 最大的問題，常常不是忘記，而是記錯
如果 Agent 把一個暫時假設寫進 long-term memory，之後每次都取回它，錯誤就可能被持續放大。另一個常見問題是 stale memory：資料原本是真的，但後來已經改變；例如專案名稱、負責人或某項規則已經更新，舊記憶卻仍被系統取回。
因此長期記憶通常需要來源、時間、作用範圍與更新規則。系統最好能知道「這句資訊從哪裡來」、「什麼時候記下來」、「適用哪個使用者 / 專案」、「後來有沒有被新資料取代」。如果 memory 只是沒有版本的文字堆，Agent 很容易把舊事實當成現在的事實。
隱私也是同一個工程問題。既然 long-term memory 代表資料跨 session 持續存在，就需要回答保存多久、誰能讀、怎麼刪除、不同使用者是否隔離，以及敏感資訊是否真的有必要被保存。Memory 做得越強，資料治理的重要性就越高。
Memory 和 Training 最後還是要分開
上一章提過，Training / fine-tuning 會透過最佳化程序更新模型參數。Agent Memory 則通常不需要碰模型權重：它把資訊存在模型外面，之後在 inference 時重新取回。兩者都能讓系統「之後表現不一樣」，但原因完全不同。
因此，一個 Agent 今天知道你昨天做到哪裡，不代表它昨天晚上拿你的對話重新訓練了模型。它可能只是有一個 database row、一份 JSON、一段摘要，或一筆可搜尋的 memory record。真正判斷系統怎麼記憶，要看資料被寫去哪裡、何時取回，以及有沒有進入參數更新流程。
把幾種「記得」放在一起看：
Conversation / short-term memory：記得目前 thread 發生什麼。
Long-term memory：跨 session 保存使用者或應用資料。
Profile memory：保存少量穩定偏好與設定。
Task state / checkpoint：記得 Agent 的工作做到哪裡。
Retrieval memory：需要時從大量舊資料挑出相關內容。
Training：直接改模型參數，和上面幾種不是同一層。
所以真正好的 Agent Memory，不是「什麼都記住」。它應該知道什麼值得留下、保存在哪裡、什麼時候取回、何時更新，以及什麼應該忘掉。記憶的核心不是容量，而是讓過去的資訊在正確的時間，以正確的形式重新成為現在可用的 context。