AI Agent 記憶系統設計：短期記憶、長期記憶與向量檢索

很多團隊把「記憶」想成一個單一功能，以為裝上某個記憶模組，Agent 就會「記得」一切，但實際的記憶系統,從來不是一個單一機制，而是短期記憶、長期記憶、向量檢索三種各有不同職責的元件搭配出來的結果。分不清這三者各自解決什麼問題，很容易在設計時把不該記的東西塞進昂貴的上下文視窗，或者把該即時取用的資訊,錯放進檢索速度較慢的長期儲存。讀完這篇，你會知道這三種機制各自的定位，以及該怎麼組合它們。

本質與範圍：記憶系統要解決的問題是什麼

AI Agent 的記憶系統，本質上要解決的是一個資源限制下的取捨問題：模型在單次推理時，能夠直接「看到」的資訊量是有限的，這個限制通常被稱為 context window（上下文視窗）。如果把一個任務需要的所有資訊都塞進這個視窗，視窗很快就會被塞滿,而且塞進去的資訊越多，模型在裡面找出真正相關的部分,也會越困難，這跟人類在資訊過載的會議裡很難抓住重點是類似的道理。

記憶系統存在的目的，就是在「視窗裝得下」與「資訊夠完整」這兩個互相拉扯的需求之間,找到一個可行的折衷方案。短期記憶負責管理視窗內當下最需要的資訊；長期記憶負責把不需要當下立刻用到、但未來可能需要的資訊持久化保存；向量檢索則負責在需要的時候，從長期記憶裡快速找出真正相關的那一小部分,送回視窗裡參與當下的推理。三者分工清楚，才能讓系統既不會因為視窗塞滿而忘記重要資訊，也不會因為什麼都想記住而拖慢速度、提高成本。

值得強調的是，這三者不是技術選型上「選一個就好」的選項，而是同一套記憶系統裡缺一不可的三個分工角色。只有短期記憶,系統會在對話一長就開始遺忘早期的重要設定;只有長期記憶而沒有檢索機制，等於把資訊堆進一個沒有索引的倉庫，需要的時候根本找不回來;只有向量檢索而沒有長期記憶,則沒有可供檢索的內容存在。理解這三者必須協同運作，而不是互相替代，是設計記憶架構時最容易被忽略的第一個前提。

核心架構：三種記憶機制如何協作

下面這張圖，畫出一次對話裡，這三種記憶機制實際協作的路徑。

┌───────────────┐
│   使用者輸入    │
└───────┬───────┘
        ▼
┌───────────────────────┐
│ 短期記憶（Context Window）│ ←── 保留最近幾輪對話內容
└───────┬───────────────┘
        ▼
┌───────────────────────┐
│  是否需要檢索長期記憶？   │
└───────┬───────────────┘
    是  ▼              否 ▼
┌───────────────┐   ┌───────────────┐
│ 向量檢索相關    │   │ 直接用短期記憶  │
│ 的長期記憶內容  │   │ 生成回應       │
└───────┬───────┘   └───────────────┘
        ▼
┌───────────────────────┐
│ 合併檢索結果與短期記憶，  │
│ 一起送進模型生成回應      │
└───────────────────────┘

這張圖裡最關鍵的判斷點，是「是否需要檢索長期記憶」這一步——不是每一次互動都需要動用長期記憶，只有當短期記憶裡的資訊不足以回答當下的問題時，才該觸發檢索。如果每次都不分情況地檢索，會增加不必要的延遲與成本；如果該檢索的時候沒有檢索，則會讓系統看起來「忘記了」其實早就存在的資訊。

短期記憶：context window 的限制與管理

短期記憶,對應的就是模型在單次推理時能直接讀到的內容，通常包含最近幾輪的對話歷史、當前任務的相關指示，以及這一輪推理過程中產生的中間結果。它的特性是讀取速度快、不需要額外的檢索成本，但容量有限——一旦對話輪數累積太多，較早的內容就必須被捨棄或壓縮，否則會超出視窗容量。

管理短期記憶最常見的做法，是設計一套「該留什麼、該丟什麼」的篩選邏輯,而不是單純按時間先後捨棄最舊的內容。舉例來說，使用者在對話開頭設定的核心目標，即使是很久以前說的，重要性通常高於三輪前一個已經處理完的細節，這意味著篩選邏輯該依照資訊的重要性,而不只是新舊程度去決定保留順序。一個只按時間順序捨棄的設計，很容易在長對話中,把最重要的初始目標擠出視窗，反而留下一堆已經不重要的近期細節。

長期記憶與向量檢索：怎麼保存、怎麼找回

長期記憶解決的是「短期記憶容量裝不下,但這份資訊未來還會用到」的問題，做法是把這些資訊持久化保存到視窗之外的儲存空間，例如資料庫或檔案系統，需要的時候再取回。長期記憶本身不直接參與當下的推理，它只是個倉庫,真正決定「現在該從倉庫裡拿什麼」的,是檢索機制。

向量檢索之所以被廣泛用在這個場景，原因在於它能依照「語義相似度」而不是「關鍵字完全相符」去找出相關內容。傳統的關鍵字搜尋，要求查詢詞跟儲存內容裡的文字完全或部分相符，遇到使用者換一種說法描述同一件事，就可能找不到原本相關的記錄;向量檢索把文字內容轉換成數學上可比較相似度的表示形式，即使用詞不同，只要語義相近,依然能被正確找出來。這也是為什麼長期記憶系統,通常會搭配向量資料庫,而不是單純用傳統的全文檢索去管理。

不過向量檢索也有自己的限制，最明顯的一點，是它找出來的內容,是「語義相近」而不保證是「正確或最新」。如果長期記憶裡存放了一筆過時或已經被修正過的資訊，向量檢索依然有可能因為語義相似度高,把這筆過時資訊找出來送進視窗，而檢索機制本身並不會去檢查這筆資訊是否已經過期。這意味著長期記憶的維護,不能只靠檢索機制把關，還需要額外設計資訊更新與淘汰的機制，確保倉庫裡的內容本身是可信的，否則再準確的檢索,也只是把不可信的資訊更精準地找出來而已。

三種記憶機制的關鍵維度對照

下面這張表，把三種記憶機制在企業實際在意的幾個維度上做對照，方便評估時有具體依據。

設想情境：一套客服 Agent 的記憶架構調整

設想一套客服 Agent，原本的設計是把每位顧客過去所有的對話紀錄,全部塞進每次互動的上下文視窗，理由是希望系統「完全了解顧客的歷史」。這個設計上線後，團隊發現兩個問題：一是對於互動頻繁的老顧客，視窗很快被歷史紀錄塞滿，擠掉了當下對話真正需要的資訊；二是因為視窗裡塞了大量不一定相關的舊對話，推理成本明顯上升,但系統的回應品質並沒有對應提升。

團隊後來把架構調整成,短期記憶只保留當前這次互動的對話內容，過去的歷史紀錄全部移到長期記憶,並建立向量索引。當顧客提出的問題,需要參考過去的歷史時（例如「我上次說的那個問題後來怎麼處理」），系統才會觸發向量檢索，從長期記憶裡找出真正相關的那幾筆紀錄,送進當次的上下文視窗，而不是一股腦把所有歷史都帶上。調整後，推理成本明顯下降，而真正需要歷史脈絡的對話，回應品質反而比之前更精準，因為系統不再需要從一大堆不相關的舊紀錄裡，自己摸索出哪些才是真正相關的部分。

這個調整過程中，團隊還補上了一個容易被忽略的細節：他們為長期記憶裡的每一筆紀錄,都加上了時間標記與狀態標記（例如「已結案」或「待追蹤」），這樣即使向量檢索依照語義相似度找出了某筆舊紀錄，系統也能依照狀態標記判斷,這筆資訊是否還具有參考價值，而不是不分新舊地把所有語義相近的內容都當成同等重要的依據。這個小小的補強，後來被證明是減少誤判的關鍵——沒有這層狀態判斷，系統偶爾會把已經結案的舊問題,誤認為跟顧客當下的新問題相關，造成不必要的誤解。

可用 Prompt：評估你的任務該怎麼設計記憶架構

下面這個 Prompt 設計給架構規劃會議使用，協助團隊判斷一項任務的記憶需求，該怎麼在短期、長期、向量檢索三者之間分配。

【角色】你是一位記憶系統架構顧問，協助我規劃一個 AI Agent 任務的記憶設計。

【任務描述】
（請描述這個 Agent 的使用情境、互動頻率，以及是否需要參考久遠的歷史資訊）

【請你協助規劃】
1. 這個任務當下最需要的資訊，預估規模大概多大？是否需要全部留在短期記憶裡？
2. 哪些資訊屬於「現在不一定用得到、但未來可能需要」，適合移到長期記憶？
3. 如果需要參考歷史記憶，建議用什麼方式判斷「現在該不該觸發檢索」？
4. 根據以上分析，請給出短期、長期、向量檢索三者的分工建議，並說明各自預期的成本與效益。

❓ 讀完後，先問自己這個問題

你的 Agent 現在的上下文視窗裡，塞的內容是不是當下任務真正需要的，還是只是把「能拿到的資訊」全部塞進去，沒有經過篩選？

引導思路：

1. 找一次最近的互動紀錄，檢查當時送進視窗的內容,有多少比例是這次對話真正用到的。
2. 想看看有沒有資訊,其實屬於「未來可能用到、但這次根本沒用上」的類型，這類資訊適合移到長期記憶。
3. 評估如果把這些不必要的內容移除,推理成本會降低多少,品質會不會因此受影響。

結語：記憶系統的設計重點，是分工而不是塞滿

AI Agent 的記憶系統,設計得好不好，從來不是看它能塞進多少資訊，而是看短期記憶、長期記憶與向量檢索三者,有沒有各自做好自己該做的事——分工清楚的記憶架構，往往比塞滿一切的記憶架構，更便宜也更準確。