因為 LLM 本身本質上是「無狀態（Stateless）」的，加上工程架構在 context 管理、記憶提取與衰減機制上遇到瓶頸。

從系統層面拆解，Agent 的失憶主要由以下 5 個核心機制漏洞 導致：

1. Context Window（工作記憶）被強制「裁切」或「滾動」

LLM 的 Context Window 就像人類的「短暫專注力視窗」。一旦對話輪次變多或工具回傳（Observation）的文字量太大，超過 Token 限制時，工程架構通常會採用以下策略處理：

• Hard Truncation（硬性裁切）：直接丟棄最早的 $N$ 條 Message。如果使用者的核心需求（如：「這份報告請用日文撰寫」）放在第一句話，幾輪工具呼叫下來，這句話就會被直接切掉，Agent 隨即失憶。
• Sliding Window（滑動視窗）：只保留最近的幾輪歷史。這會導致 Agent 忘記任務最初的「大目標」，變成只看眼前步驟的「短視近利盲目執行者」。

2. 「中間遺忘」效應（Lost in the Middle Phenomenon）

即使 Context Window 足夠大（例如 128k 或 1M Tokens），「能塞進去」不等於「能精準注意到」。

研究證明，當上下文長度拉長時，LLM 對 Prompt 開頭與結尾的資訊關注度最高，而放在中間區域的記憶（例如第 5 輪工具呼叫得到的關鍵參數）注意力會呈 U 型大幅下降。 Agent 雖然「看得到」這段歷史，但推理時卻像忘了一樣忽視它。

3. RAG 檢索失敗（長期記憶「撈不出來」）

當 Agent 將經驗或偏好存入向量資料庫（Vector DB）作為長期記憶時，失憶往往發生在 「檢索（Retrieval）」 階段：

• 語意斷層（Semantic Gap）：當前的 Query 與當初存入記憶時的 Embedding 向量距離太遠。例如當初存的是 user.prefer_tech = "Python"，現在問「適合寫自動化指令碼嗎？」，RAG 可能無法拉回這條記憶。
• Top-K 數量限制：為了控制 Token 費用與回應速度，RAG 每次通常只撈 Top 3~5 條記憶。如果真正關鍵的記憶落在第 6 條，Agent 就等同於失憶。

4. 記憶摘要（Summarization）過程中的資訊失真

為了避免 Context 爆掉，許多系統會定期用一個小模型（如 GPT-4o-mini）將舊的對話紀錄「壓縮成摘要」。

在這個壓縮過程中，容易發生 資訊蒸發與幻覺：

• 原始細節：「請把伺服器設定在 192.168.1.100，PORT 為 8080。」
• 摘要結果：「使用者提供了一組內部伺服器 IP 與 Port。」
• 失憶結果：Agent 知道有 IP 這回事，但真正的數字與細節已經在摘要時被抹掉了。

5. 跨 Session 的「記憶寫入機制」缺失（無寫入機制）

許多 Agent 系統根本沒有設計 Memory Consolidation（記憶固化/回寫機制）。

在單次對話（Session）中，Agent 聽懂了你的風格偏好，但當你關掉視窗重新開啟新對話時：

• 短期記憶（Message List）被清空。
• 背景程式沒有在上一輪結束時將重要資訊寫入長期資料庫。
• Agent 在新對話中直接回歸初始狀態，呈現徹底的「開新視窗即失憶」。

💡 如何解決 Agent 的失憶問題？