mk-brain

超越短期記憶：如何為 Long-Running Agent 設計分層狀態架構？

當 AI Agent 的工作從單次任務轉向長期專案時，記憶管理就成為了成敗關鍵。許多開發者嘗試用單一檔案記錄所有歷程，卻發現 Agent 很快就陷入混亂。本文將深入探討為何這種方法註定失敗，並提出一個更穩健的分層狀態架構，讓 Agent 能夠真正跨越 session 限制，維持協作的連續性，從而成為您可靠的長期夥伴。

江中喬

19 8月 2026 • 7 min read

要讓 AI Agent 能夠跨越 session 限制、進行長期協作，關鍵不在於無限擴充 context window 或依賴單一的記憶文件。真正的挑戰是建立一套分層的狀態管理架構，將即時的工作記憶、專案層級的狀態，以及可長期累積的知識庫明確分離。若缺乏這種設計，Agent 只要遭遇 context reset 或系統重啟，就會失去協作的連續性，無法成為可靠的長期夥伴，更遑論達成真正的自主運作。

為什麼把所有狀態塞進一個檔案是個壞主意？

在開發能夠長時間運作的 AI Agent 時，我們很快就會遇到一個核心難題：狀態管理。當一個任務需要橫跨數小時甚至數天，歷經多次 session 重啟時，Agent 如何記得「我是誰」、「我正在做什麼」以及「下一步該往哪走」？

一個直覺、但最終會導致失敗的做法，是將所有互動歷史、中間產出、思考過程全部寫入一個巨大的文字檔（例如，一個不斷增長的 history.md）。開發者期望在每次重啟時，Agent 只要讀取這個檔案，就能無縫接軌。然而，這種「單一文件式記憶」很快就會面臨瓶頸。

單一文件記憶會導致哪些問題？

首先，這會造成嚴重的「脈絡污染」（context pollution）。當檔案膨脹到數十萬 tokens，裡面充滿了過時的決策、已解決的錯誤和無關的對話。Agent 在每次啟動時，都必須處理這些大量噪音，導致其注意力被稀釋，難以聚焦在當前最重要的任務上。研究也證實，當重要資訊被埋藏在冗長脈絡的中間時，大型語言模型的表現會顯著下降，這種現象被稱為「Lost in the Middle」。

其次，即使我們擁有像 Claude 3 的 200K token 甚至更大的 context window，單純依賴它也非長久之計。這就像試圖靠短期記憶來處理一輩子的經歷，不僅成本高昂，而且效率低下。Agent 的運作不該是每次都從頭「閱讀」整個專案史，而應是快速「回憶」起相關的狀態。

在我將一個自律開發系統維持 24 小時不間斷運作的經驗中，這個問題尤其突出。單一文件的做法在幾次 session 循環後就開始出現狀態不一致，Agent 會重複已經完成的工作，或忘記關鍵的專案限制。這證明了我們需要的不是更大的記憶容器，而是一個更好的記憶結構。

如何設計分層的 Agent 狀態架構？

一個更穩健、更具擴展性的解決方案，是參考認知科學中的記憶模型，為 Agent 建立一套分層的狀態管理架構。我們可以將 Agent 的「記憶」區分為三個層次，各自有不同的生命週期、儲存格式與讀取機制。

真正的長期記憶不是把所有東西記下來，而是知道什麼該忘掉，以及如何快速提取最重要的部分。

這種分層設計的核心精神是「關注點分離」（Separation of Concerns），確保不同時間尺度的狀態資訊不會互相干擾。以下是一個可行的三層架構：

第一層：工作記憶 (Working Memory)

這是最即時、最易變的記憶層。它儲存當前 session 的執行緒、最近幾次的對話、API 回應、暫存變數等。它的生命週期僅限於單次任務執行，任務結束或 session 中斷後即可拋棄。在實作上，它可以是記憶體中的一個 JSON 物件或一個暫存檔，追求的是高速的讀寫而非持久性。

第二層：專案狀態 (Project State)

這是跨 session 的核心，負責維持專案的連續性。它儲存的是特定專案的「快照」，例如目前的程式碼檔案結構、待辦事項清單 (TODO list)、已完成的任務、下一個明確的目標等。當 Agent 重啟時，它會優先載入這一層的狀態，以確保能從上次中斷的地方繼續。這層的資訊應該是結構化的（如 JSON、YAML 或小型資料庫），確保 Agent 能精確解析，避免語義模糊。

第三層：知識庫 (Knowledge Base)

這是 Agent 的長期記憶，負責累積可跨專案重用的知識。這包括通用的程式碼片段、解決特定問題的模式、對特定領域的理解、過去專案的成功經驗與失敗教訓等。與專案狀態不同，知識庫是可累積且全域性的。實作上，它通常會與檢索增強生成 (RAG) 技術結合，儲存在向量資料庫或知識圖譜中，讓 Agent 在需要時能透過語義搜尋來「請教」自己的知識庫。

分層架構如何提升 Agent 的實務表現？

將 Agent 的狀態管理拆分為這三層，帶來的好處是顯而易見的。讓我們以一個「自主編寫程式碼」的 Agent 為例，看看這個架構如何運作：

當 Agent 開始一個新功能開發時，它的專案狀態 (Layer 2) 可能會記錄：「目標：實現使用者登入 API。目前檔案：user_routes.py、models.py。待辦事項：1. 建立 User model。2. 撰寫註冊 route。」

在撰寫 user_routes.py 的過程中，最近的幾行程式碼、終端機的錯誤訊息、與使用者確認的需求細節，都存放在工作記憶 (Layer 1) 中。如果此時系統崩潰，這部分記憶會遺失，但無傷大雅，因為它只是暫時的。

重啟後，Agent 載入專案狀態，立刻知道自己要繼續處理 user_routes.py。當它需要實作密碼雜湊時，它可能會查詢自己的知識庫 (Layer 3)，找到之前學到的「使用 bcrypt 函式庫處理密碼的最佳實踐」，而不是每次都重新上網搜尋或從頭摸索。

這種設計讓 Agent 變得更有韌性、更有效率，也更具擴展性。它不再是一個只有龐大短期記憶的語言模型，而更像一個具備不同記憶系統的認知實體，這也是許多經典認知架構如 Soar 的核心思想。正如許多 Agent 框架（如 LangChain 的 Memory 機制）所探索的，有效的記憶管理是從「玩具」走向「工具」的關鍵一步。

最終，建立能夠長期可靠運作的 AI Agent，其挑戰不僅在於模型能力，更在於系統架構。放棄單一文件的幻想，轉而設計一個分層、結構化的狀態管理系統，才是讓 Agent 從短跑選手蛻變為馬拉松跑者的正確道路。