AI 記憶體管理：從金魚到大象的進化之路

假設你有個老朋友，每次見面都要重新自我介紹，還要幫他回顧上次聊到哪裡。這聽起來很荒謬，但這就是目前 AI 的日常——每次開啟新對話，對 AI 來說就是一個全新的宇宙誕生。在工程上我們稱之為無狀態（stateless）。大部分的 AI 模型就像只有七秒記憶的金魚，對過去的一切一無所知。本文要來聊聊 AI 記憶是怎麼運作的，以及工程師如何在系統層級為 AI 裝上類似人類的海馬迴。

短期記憶與長期記憶

AI 的記憶機制和人類非常相似，主要分為兩種：短期記憶和長期記憶。

短期記憶：辦公桌

在 AI 領域，短期記憶通常稱為情境記憶（contextual memory），全部塞在一個叫做情境視窗（context window） 的空間裡。這個視窗包含了：

• 你和 AI 之間來回的所有對話記錄
• AI 使用工具（例如搜尋網頁）得到的結果
• AI 當下的自我對話或思考過程

所有這些文字資訊會被打包起來，當做下一次回答的前提，整個餵給模型。可以把它想像成辦公桌上的桌面空間——空間有限，只能把眼前立刻要處理的公文或參考資料攤在桌上。

長期記憶：檔案櫃

長期記憶（或稱持久記憶）獨立於 AI 即時處理環境之外，通常儲存在外部的資料庫中。現在最主流的做法是存進向量資料庫，搭配語義搜尋（semantic search） 來讀取。

語義搜尋和傳統的關鍵字搜尋不一樣。關鍵字搜尋是找一模一樣的字，但語義搜尋會把所有的文字資訊轉換成向量數字，這些數字代表了這段文字的概念與意義。當 AI 需要回應某件事的時候，它會把你的問題也轉成向量，去資料庫找意義最相近的幾筆資料，只把最關鍵的幾份檔案抽出來放到辦公桌上。

這樣既節省了桌面空間，又保留了近乎無限的記憶容量。

為什麼不能用超大情境視窗取代長期記憶？

我們可能會想：現在很多 AI 模型都主打超長情境視窗，號稱支援幾百萬個 tokens。如果辦公桌大到像足球場，把檔案櫃全部搬上桌不就好了？

問題出在成本與效率。幾百萬個 tokens 大約等於好幾本厚厚的原文小說。每次只是問一句「今天天氣如何」，AI 都必須把這幾本小說從頭到尾重新閱讀、重新運算一次才能回答。這在運算資源和 API 成本上極度昂貴且低效。而且無論情境視窗多大，它本質上還是短暫的。一旦關閉對話或系統重啟，視窗裡的資料就會消失。長期記憶還是不可或缺。

Google ADK 的記憶管理

Google 的 Agent Development Kit (ADK) 提供了一套結構化的基礎建設來管理記憶，主要包含三個核心概念。

Session：對話軌跡

Session 是我們和 AI 之間的單一對話軌跡。ADK 提供了三種服務來管理：

• InMemorySessionService：適合開發測試，程式一關資料就沒了
• DatabaseSessionService：上線用，把對話軌跡存進實體資料庫
• VertexAiSessionService：部署在 Google Cloud 上的生產環境使用

State：臨時變數

在對話進行中，AI 需要記住一些正在處理的變數，例如「幫我訂兩張去東京的機票」。在程式碼裡寫作 session.state，本質上是一個字典（dictionary），用鍵值對的方式儲存資料。

ADK 使用字首機制來管理變數：

更新 State 的兩種方式

有一個非常重要的守則：絕對不要直接修改 session.state 這個字典。

為什麼？如果繞過標準的事件機制直接去硬改變數，ADK 的底層系統就完全無法追蹤這個變更——不會留下時間記錄，也不知道是哪個工具修改的。更嚴重的是，當 AI 代理同時處理多個任務時，直接修改會引發資料競爭，導致系統崩潰。就像是偷溜進檔案室，直接在合約正本上塗改數字，沒有經過公證人蓋章，也沒有留下記錄。

正確的作法有兩種，依情境選擇：

1. 簡單更新：使用 outputKey

如果只是要儲存代理的最終文字回應，在 LlmAgent 上設定 outputKey 即可。Runner 會自動把回應存進 state。

const greetingAgent = new LlmAgent({
  name: "Greeter",
  model: "gemini-2.0-flash",
  instruction: "Generate a short, friendly greeting.",
  outputKey: "last_greeting",
});

2. 複雜更新：使用 State Delta

如果需要一次更新多個鍵、指定特定範圍（如 user: 或 app:），就要手動建一個 state delta 字典，包在事件的 EventActions 裡提交。例如記錄使用者登入的邏輯，不是直接在主程式裡把登入次數加一，而是寫成一個獨立的工具來產生 State Delta：

function logUserLogin(toolContext: ToolContext): Record<string, unknown> {
  const state = toolContext.state;
  const loginCount = (state.get("user:login_count") as number ?? 0) + 1;

  state.set("user:login_count", loginCount);
  state.set("task_status", "active");
  state.set("user:last_login_ts", Date.now());
  state.set("temp:validation_needed", true);

  return {
    status: "success",
    message: `User login tracked. Total logins: ${loginCount}.`,
  };
}

所有的狀態變更都被安全封裝在工具裡面，主程式碼看起來乾淨，而且絕對不會發生資料衝突。

記憶的三大擬人分類

前面討論的是資料層級的記憶管理。但如果希望 AI 真的表現得像個人類，就必須進入心理學的維度。LangChain 和 LangGraph 這些框架把長期記憶分為三種擬人化型別。

語意記憶（Semantic Memory）

對應人類記住客觀事實的能力，例如「你是一個軟體工程師」、「你喜歡深色模式」、「你對海鮮過敏」。在技術實作上，這些事實通常被整理成 JSON 格式的使用者設定檔。JSON 有非常明確的欄位和標籤，大型語言模型可以瞬間看懂並應用在對話中。

情景記憶（Episodic Memory）

關乎記住經驗和過程。舉例來說，你上週和 AI 一起除錯花了半小時，情景記憶不只是記住最後的程式碼，還記住當初是怎麼一步步解決問題的。這項技術靠少樣本提示（few-shot prompting） 實現。當你又遇到類似的 bug 時，系統會去情景記憶裡把上次成功除錯的對話抽出來當做範本，偷偷塞進提示詞裡。AI 看到這個範本就能回憶起解決問題的最佳路徑。

程式記憶（Procedural Memory）

這是目前 AI 代理最尖端的領域，代表 AI 記住了規則，也就是它的核心指令和行為準則。最酷的技術應用在於反思機制（Reflection）。

舉例來說，我們請 AI 寫一篇社群貼文，結果內容充滿生硬的企業術語。你糾正它說「太老派了，我喜歡輕鬆幽默的語氣」。傳統的 AI 這次會幫你改，但下次就忘了。但具備程式記憶的 AI 會在背後觸發一個反思迴圈：評估剛剛的失敗 → 自己寫下一條新規則（「這個使用者討厭企業術語，必須永遠使用輕鬆幽默的語氣」）→ 把這條規則儲存到特定名稱空間，覆蓋掉原本的系統預設提示詞。這就像每次主持完節目，覺得自己講話太快，就寫一份檢討報告植入大腦神經元，下次自動放慢語速。當然，這種自主修改也有風險。為了解決這個問題，目前的系統設計通常會將反思後的新規則限制在特定的使用者名稱空間內，只對該使用者生效，不會汙染核心系統。同時許多企業級應用仍保留人工複核機制。

雲端託管記憶：Vertex AI Memory Bank

要手動維護這麼多記憶分類、處理資料庫衝突，對開發者來說是極其浩大且容易出錯的工作。這也是為什麼 Google Cloud 推出了 Vertex AI Memory Bank 這樣的雲端託管服務。Memory Bank 的運作方式是非同步的智慧分析，背後直接整合 Gemini 語言模型。當使用者在跟 AI 聊天的同時，Gemini 默默閱讀每一句話，具備強大的自然語言理解能力。

最厲害的是它處理人類矛盾的能力。例如：

• 星期一：「我超愛喝咖啡，每天都要來三杯」
• 星期五：「我已經完全戒掉咖啡因了，以後別再跟我提咖啡」

傳統做法需要開發者寫一堆複雜的 if 條件判斷去比對時間戳記，甚至人工介入清理資料。但 Memory Bank 理解「戒掉」這個動詞代表狀態的根本性改變，會自動比對時間線、識別因果關係，在背景自動更新使用者偏好，用最新的事實覆蓋舊的記錄。

開發者一行邏輯判斷都不用寫。Memory Bank 不只與 Google ADK 原生整合，也提供 API 讓 LangGraph、CrewAI 等其他框架使用。

對 UI/UX 的影響

記憶管理對使用者來說，最明顯的差異是連續對話的流暢度。

有記憶的 AI 知道你是誰。 當使用者隔天回來繼續對話，系統記得他的偏好（深色模式、對海鮮過敏）和上一次聊到的進度（昨天履歷改到第三版），使用者不需要重新自我介紹。這種連續感是 AI 從工具變成夥伴的關鍵一步。沒有記憶的 AI 每次都是第一次見面，使用者很快就會覺得「算了，每次都從頭來，好累」。

個人化的邊際效益。 語意記憶讓 AI 記住事實（「你是前端工程師」），情景記憶讓 AI 記住經驗（「上次我們一起除錯的方法是⋯」），程式記憶讓 AI 記住規則（「這個使用者喜歡輕鬆的語氣」）。每一層記憶都讓回應更貼近使用者的期待，但每一層也帶來隱私顧慮——使用者需要知道 AI 記住了什麼、能忘記什麼。

記憶管理的介面挑戰。 如果 AI 記錯了，使用者要怎麼修正？目前大部分產品沒有提供「編輯 AI 記憶」的介面，使用者只能靠對話糾正（「不對，我上次說的是⋯」）。未來可以考慮提供一個記憶管理頁面，讓使用者像瀏覽通訊錄一樣，查看、編輯、刪除 AI 對自己的記憶——這會是 AI 產品的一個重要的 UX 差異點。

反射機制的雙面刃。 程式記憶讓 AI 能根據使用者的糾正自我調整規則，這是強大的個人化能力。但如果 AI 記錯了規則（例如使用者只是臨時心情不好說「以後別提咖啡」，隔天又後悔了），它可能會固執地遵守錯誤的規則。Memory Bank 這類服務能透過時間線分析解決這個矛盾，但使用者不一定知道這個機制存在——當 AI 拒絕推薦咖啡時，使用者需要理解「為什麼」以及「怎麼改回來」。

解法

記憶管理的 UI/UX 解法核心是讓使用者看得見、管得著 AI 的記憶：

• 記憶管理頁面。提供一個頁面讓使用者像瀏覽通訊錄一樣，查看 AI 記住了哪些關於自己的資訊、編輯錯誤的記憶、刪除不需要的記錄。這是 AI 產品的一個重要的 UX 差異點。
• 對話中修正機制。使用者說「不對，我上次說的是⋯」時，系統應該理解這是記憶修正而不是一般對話，即時更新儲存的記憶，並且在回應中確認變更已生效。
• 記憶變更通知。當 AI 根據反射機制自己更新了規則（例如「這個使用者喜歡輕鬆的語氣」），可以在回應中附帶說明，讓使用者知道他的回饋被記住了，而不是默默在後端修改。
• 時間線解決矛盾。Memory Bank 這類服務能自動比對時間線，用最新的事實覆蓋舊的記錄。使用者不需要手動處理「星期一說愛咖啡、星期五說戒咖啡」的矛盾——但也需要一個機制讓使用者查看歷史版本，確保 AI 沒有誤解。

結語

AI 的記憶進化，是一場從金魚變成大象的旅程。

• 情境視窗提供短期記憶，應付眼前運算
• 向量資料庫與語義搜尋建立長期記憶，克服成本與對話重置問題
• Google ADK 告訴我們永遠用 State Delta 更新狀態，避免資料競爭
• 三大擬人記憶讓 AI 不僅記住事實，還能記住過程、甚至自我修正規則
• Memory Bank 這樣的管理服務能自動解決記憶矛盾，開發者不用寫一行邏輯

下次使用 AI 聊天機器人時，可以試著測試他的記憶力——幾天後不經意問他一個你們之前聊過的私人小細節，看看他到底是那隻只有七秒記憶的金魚，還是已經在幕後默默為你建立了一個龐大的長期檔案櫃。

參考資料

• 第 8 章：記憶體管理 - Agentic Design Patterns