AI Agent 記憶怎麼設計

說真的，AI agent 不是只會聊天就夠。OpenAI、Anthropic、Google 都在推 agent 工作流。問題也很直接：模型能答一次，不代表它能記住上一次做了什麼。

這件事很現實。LLM 可以很會講，但一旦要跨工具、跨步驟、跨時間維持狀態，記憶就變成核心能力。沒有記憶，agent 每次都像重開機。你叫它接著做，它卻像失憶一樣。

講白了，agent memory 就是讓系統記住任務。它要記使用者偏好，也要記工具輸出，還要記中間狀態。這不是花俏功能。這是 agent 能不能真的幹活的分水嶺。

為什麼 agent 記憶這麼重要

單輪聊天和多步驟 agent，需求完全不同。前者只要回一句像樣的答案。後者要記得前面查了什麼、失敗過什麼、還剩哪些步驟沒做完。這種差異，直接改變架構設計。

如果沒有記憶，agent 每次都從零開始。它可能剛剛才讀過文件，下一輪又問一次。它可能已經抓到 API 回應，下一步卻把資料忘光。這種行為在 demo 很可愛，在正式產品就很煩。

所以現在很多團隊都把記憶當成系統設計的一部分。不是加個聊天紀錄就算數。你要想清楚，哪些資料只活 30 秒，哪些要留 30 天，哪些甚至要永久保存。這才像真的在做產品。

• 短期上下文：目前對話與最近工具呼叫
• 工作狀態：目標、子任務、暫存變數
• 長期記憶：偏好、歷史決策、穩定事實
• 外部記憶：資料庫、向量庫、檔案、log

這四層很重要，因為它們用途不同。你不會把所有東西都塞進 prompt。那樣 Token 很快爆掉。你也不會把所有東西都丟進向量庫。那樣你很難保證精準狀態。

我覺得，真正成熟的 agent，第一個能力不是會推理。是會管理記憶。它知道什麼該留，什麼該丟，什麼該查。這比單純把模型換大，還更接近實戰。

記憶層怎麼分工

大多數 agent 架構都會拆成多層記憶。原因很簡單。沒有一種儲存方式可以同時處理即時上下文、精準狀態、語意回憶，還有跨 session 持久化。想一次全包，通常只會做得很痛苦。

短期上下文最直接。它就是 prompt window，速度快，實作也簡單。缺點也很明顯，Token 有上限。你如果一直塞工具輸出，最後不是成本爆，就是模型開始漏看重點。

長期記憶則比較像資料層。它可以存使用者偏好、任務結果、歷史紀錄。這類資訊通常要結構化，不然之後很難查，也很難除錯。說白了，能查才有救。

“The future of AI does not belong to those who build the biggest models, but to those who learn how to make them useful.” — Fei-Fei Li

這句話很貼切。模型再大，忘東忘西還是沒用。真正有價值的是它能把事情做完。記憶就是把「會講」變成「會做」的那條線。

另一個常見做法是把記憶按時間切。秒級記憶放在上下文。分鐘級記憶放在工作狀態。天級或月級記憶放到資料庫。這種分層很土，但很實用。工程上常常就是土法最穩。

現在主流框架怎麼做

現在很多框架都開始把記憶做成一等公民。LangChain 有記憶相關抽象，Microsoft AutoGen 走多 agent 協作，LlamaIndex 則偏向外部知識檢索。

它們都在解同一題，但解法不同。有的保留聊天紀錄後再摘要。有的把狀態寫進結構化儲存。有的只在需要時才抓回舊資料。差別在於，你要的是連貫感，還是可追蹤性，或是低延遲。

實務上，框架常見的不是單一記憶，而是混搭。這很正常。因為 agent 的任務本來就混雜。它既要即時反應，也要記住長期偏好，還要能回頭查歷史事件。單一方法很難全扛。

• Prompt memory：快，但受 context window 限制
• Summary memory：省 Token，但容易丟細節
• Vector memory：適合語意回憶，但不保證順序
• Structured memory：精準可查，但要先設 schema

這裡的取捨很像選資料庫。你要查詢快，還是要寫入簡單。你要可追溯，還是要語意相似。沒有免費午餐。每種方案都在不同地方付錢。

還有一個現實問題是延遲。每多一次檢索，就多一段等待。每多一層儲存，就多一點維護成本。產品團隊最常犯的錯，就是把記憶想得太浪漫，最後把伺服器搞得很累。

用數字看記憶取捨

先看模型本身的限制。GPT-4.1 文件提到，部分版本支援 100 萬 token context window。這數字很大，但你一旦把工具輸出、文件、歷史對話都放進去，空間還是會被吃掉。

再看 Claude。它也有很大的 context window。可是一個 session 結束後，狀態還是會消失。你如果沒把資料寫到外部記憶，下一次進來還是得重來。

這就是外部記憶的價值。資料庫可以永久保存。向量庫可以做相似檢索。log 可以保留完整操作序列。這三種東西看起來老派，但在 agent 系統裡很管用。

• Context window：適合即時推理，但受 Token 上限約束
• Summary store：跨 session 省空間，但會壓縮細節
• Vector database：適合模糊回憶，依賴 embedding 品質
• SQL 或文件庫：適合精準狀態與稽核

如果你做客服 agent，這個差異更明顯。最近幾輪對話放 prompt。帳號資訊放資料庫。相似案件放向量庫。這樣做不華麗，但很好 debug。工程團隊最愛這種東西，因為出事時知道去哪裡查。

我也會直接講結論。記憶設計不是看誰最會塞資料。是看誰能把資料分層，還能證明自己記對了。這才是可上線的系統，不是只會 demo 的玩具。

產業脈絡與實作現實

agent memory 之所以最近很熱，是因為大家都卡到同一個瓶頸。模型會說話，但流程不會自己延續。你要它做訂票、查資料、寫報告、跑工作流，它就得記住前一步做了什麼。

這也解釋了為什麼很多團隊開始重視 state machine、資料表、事件 log。說穿了，很多 agent 問題根本不是 NLP 問題，而是軟體工程問題。你要的是可靠性，不是漂亮句子。

台灣開發者如果要做這類系統，我會建議先從最簡單的做法開始。先把工作狀態寫進明確的欄位。再決定哪些欄位需要檢索。最後才考慮摘要或語意記憶。順序反過來，很容易把系統做得很玄，卻不好維護。

接下來該怎麼做

如果你現在在做 agent，我的建議很直接。先定義三件事：哪些資料要短期保存，哪些要長期保存，哪些根本不該記。這比一開始就追求更大的 context window 實際多了。

下一步，再決定每一層記憶要放哪裡。prompt、資料庫、向量庫、log，各有用途。不要把所有東西都交給 LLM。那樣成本高，還很難查錯。講白了，記憶越清楚，agent 越像產品。

我自己的判斷是，接下來 12 個月，做得好的 agent 框架會更像資料系統，而不是純聊天框架。你如果現在就把記憶層拆好，之後換模型、換供應商、換工具，會輕鬆很多。你可能會想問：那第一步是什麼？答案很簡單，先把 state 寫清楚。