深入解析 AI 代理記憶：大型語言模型代理的狀態管理與實作

這篇由 Cognee（一個開源代理記憶體平台）的 FDE 主管 Veljko Kovac 撰寫的客座文章，將帶您了解 AI 代理記憶體的工作原理。

每個大型語言模型（LLM）的呼叫都是從零開始的。LLM 本身沒有記憶體，每個請求都是獨立的：模型讀取提示詞，返回回應，然後不保留任何資訊。發送第二個請求時，模型會認為第一個請求從未發生過。

對於單次提問來說，這沒有問題。但當您建構需要長時間運作的系統時，這種模式就會失效。例如，處理後續問題的客服代理、為續約電話做準備的銷售助理，或者每小時運行一次且應知曉上次操作的自動化流程，這些系統都需要狀態，而模型無法為它們保存。

因此，當人們詢問 LLM 記憶體如何運作時，誠實的答案是記憶體存在於模型之外。代理將其學到的內容儲存在其他地方，在每次呼叫之前檢索相關部分，然後將其回傳到提示詞中。這個外部層就是我們所稱的 AI 代理記憶體，而您如何設計它，將決定您的代理是記住正確的資訊，還是被錯誤的資訊淹沒。

本文將解釋這個層如何運作、主要的建構方式，以及如何在 n8n 中使用它，無論是作為工作流程可以查詢的共享「公司大腦」，還是作為單一代理工作流程內部的記憶體。

代理記憶體通常在兩個時間尺度上運作，並且通常建構為兩個獨立的組件。

短期記憶體追蹤當前發生的事情：最近的訊息、中間推理、工具輸出、任務狀態。它存在於代理附近，通常在代理框架內部。當上下文視窗填滿時，一個常見的技巧是總結到目前為止的歷史，然後將摘要回傳。這在某些情況下有效，但摘要會丟失細節，而且某些輸出（例如中間草稿或昂貴計算的結果）根本不應被壓縮。

長期記憶體則跨會話存活。它保存用戶偏好、過去任務的結果、關於哪些方法有效的經驗，以及越來越多的、代理本身沒有生成的公司知識：文件、工單、客戶關係管理（CRM）記錄。這幾乎從一開始就需要一個專用的外部層，因為必須有東西來決定什麼被保留、如何組織，以及每次請求時回傳什麼。

無論哪種方式，傳遞機制都不會改變。模型仍然接收一個提示詞。記憶體只是改變了這個提示詞的組裝方式：新的用戶訊息，加上正在運行的會話，再加上當前相關的任何長期記憶。

這四個術語經常互換使用，但它們描述了知識存在於不同位置。一個真實的系統通常會同時使用所有這些方法。

LLM 記憶體（模型權重）：知識存在於模型內部，由訓練或微調更新，適用於一般知識和技能。

上下文工程：知識存在於當前提示詞中，由代理框架或應用程式碼在每次呼叫時更新，適用於將正確資料帶入當前請求。

RAG（檢索增強生成）：知識存在於外部、大多靜態的語料庫中，由撰寫文件的人員或系統更新，適用於將答案建立在現有知識基礎上。

代理記憶體：知識存在於一個不斷演進的外部記憶體層中，由人員、資料管線和代理本身更新，適用於跨任務、會話和來源的連續性。

嚴格意義上的 LLM 記憶體是模型在訓練期間吸收的內容。它是壓縮的模式，而不是查找表，這就是為什麼模型可以自信地重複一些過時的資訊。微調可以增加領域知識，但它速度慢、成本高、難以檢查，而且無法從即時會話中捕捉任何內容。

上下文工程是選擇在此特定呼叫的上下文視窗中包含哪些內容。更大的視窗有幫助，但它們不能解決記憶體問題：會話結束時上下文會消失，長提示詞成本更高，而且模型不會平等地關注非常長輸入中的所有內容。

RAG 從現有知識來源（文件、資料庫、API）中檢索資訊，並將結果添加到提示詞中。其主要限制是方向性：RAG 只能讀取，但不能寫回。它不會記住用戶上週問了什麼，或者哪個修復已經失敗了。

代理記憶體從代理寫回開始。它在工作時捕捉新的事實、偏好和結果，並在以後檢索它們。想像一個銷售助理，它透過 RAG 提取本季度的數字，但也從先前的對話中記住該用戶希望以歐元顯示歐盟數據，並按國家細分。

從高層次來看，任何記憶體系統都需要三個部分：持久化記憶體的資料儲存庫、決定儲存內容和方式的寫入邏輯，以及讓代理找到相關記憶體的檢索介面。您選擇的儲存庫對其他兩個部分有很大影響：哪些寫入邏輯有意義，以及檢索能做什麼。以下是主要的架構，依儲存類型分類。

向量資料庫：記憶體被轉換為嵌入向量，並透過語義相似度找到。優點是設定簡單、可擴展且工具成熟，但缺點是缺乏實體概念、對精確 ID 支援較弱，且沒有時間先後順序。

純文字檔案：代理維護一個 MEMORY.md（或類似檔案），讀取並編輯它。優點是透明、版本控制且無需基礎設施，但缺點是無法良好擴展或共享。

知識圖譜：事實成為實體和關係：銷售報告涵蓋歐盟交易，歐盟交易以歐元計價，數字來自帳單匯出。檢索會找到一個入口點，然後沿著邊緣追蹤，因此代理會獲得邏輯上與問題相關的事實，而不僅僅是聽起來相似的事實。缺點是在資料攝取時需要更多工作。

混合系統：在實踐中，沒有單一的儲存庫可以涵蓋所有內容。精確的 ID 需要結構化索引，關係需要圖譜，模糊匹配需要向量，而「客戶去年三月喜歡什麼？」則需要時間戳。生產環境中的記憶體層結合了多個儲存庫，並在其之上放置邏輯，決定什麼內容去哪裡。

這也是為什麼記憶體層不僅僅是一個資料庫：儲存庫只是資料存在的地方，而記憶體層位於它們之上。它決定了什麼被儲存以及以何種形式儲存，並公開了代理用於寫入、檢索、更新和遺忘的操作。

一個只會增長的記憶體層會隨著時間推移而變差。事實會改變，偏好會轉移，過時的條目會開始與正確的條目競爭。好的記憶體系統除了儲存之外，還處理幾個過程。主要有三個：

整合：原始條目堆積的速度比它們變得有用更快。系統應定期將它們轉化為更少、更高層次的記錄（摘要、衍生事實），同時保留追溯到原始記錄的線索。

更新：當一個事實改變時，盲目覆寫會丟失歷史：之前什麼是真的，以及它何時改變。在事實上保留時間資訊可以讓代理回答「現在什麼是真的？」和「我們三月時相信什麼？」這兩個問題。

遺忘：某些資料必須刪除：過時的資料集、更正、刪除請求。這應該是一個明確、有意的操作，與讓較不有用的記憶體逐漸淡出相關性的較軟性工作分開。

最好的系統還會從使用中學習。如果一個答案得到確認，其背後的記憶體會增加權重；如果它被糾正，誤導性的記憶體會下降。經過數週後，檢索應該會變得更精準，而不是更嘈雜。

您如何知道您的記憶體是否有效？公開基準測試提供了一個有用的初步信號。大多數遵循相同的兩階段模式：將長歷史輸入記憶體系統，然後提出問題，其答案取決於儲存和檢索正確的事實，包括後來更新或矛盾的事實。

大小比人們預期的更重要。如果基準測試的整個歷史都適合現代上下文視窗，您可以完全跳過記憶體，將所有內容貼到提示詞中，這樣測試更多地說明模型而不是記憶體。然而，這並不意味著模型會完美回答：模型不會均勻地使用長上下文，埋藏在長提示詞中間的細節可能會受到較少的關注。

LoCoMo 對話約為 26k 詞元；LongMemEval 的常見變體約為 115k。BEAM 是這三者中最嚴苛的，它測試十種記憶能力，對話長度可達 10M 詞元，這才是外部記憶體真正需要發揮作用的地方。Cognee 在 BEAM 上報告的最新技術水準是 100K 詞元時達到 79%，10M 詞元時達到 67%，高於之前最佳的 73.4% 和 64.1%。

但基準測試主要檢查最終答案。它們不查看記憶體實際儲存了什麼、經過數週更新後表現如何，或者當許多代理共享它時的行為。有關每個基準測試的完整測量內容及其不足之處，請參閱這份 AI 記憶體基準測試指南。

最重要的測試是您自己的測試：在開啟和關閉記憶體的情況下運行相同的工作流程，並測量您關心的結果，例如解決的工單數量、重複問題的減少，或正確的後續行動。

n8n 工作流程與 LLM 有一個共通點：預設情況下，每次執行都是從頭開始的。因此，一個在週一草擬了修復方案的支援工作流程，在週三收到後續問題時，不會自動知道這件事。許多團隊透過 PostgreSQL 資料表或 Airtable 資料庫來處理這個問題，這雖然有效，但每個工作流程都需要自己的儲存設定和自己的保留規則。

最簡單地說，記憶體讓任何工作流程都能從上次運行結束的地方繼續。一個節點儲存工作流程學到的內容；另一個節點在下次運行時查找它。而且由於記憶體存在於任何單一工作流程之外，許多工作流程可以共享它。

最大的好處是一個集中式的「大腦」：一個所有工作流程都可以寫入和讀取的共享記憶體。將其擴展到整個公司，您就得到了一個「公司知識庫」。大多數有用的上下文已經存在於公司內部：Slack 對話、工單、文件、CRM 筆記、通話記錄。n8n 可以從所有這些工具中收集資料，而記憶體層可以對其進行結構化和連接，這樣每個工作流程都能利用公司所知曉的相同資訊。

模式很簡單：收集器工作流程使用 n8n 的觸發器和應用程式整合來獲取新出現的資料，例如已關閉的工單、通話摘要或表單提交，並將其發送到記憶體層，由記憶體層進行結構化和連接。執行器工作流程在執行某些操作之前查詢相同的記憶體：草擬回覆、路由升級、準備銷售簡報。它們可以用自然語言提問，例如「Acme 目前的狀態如何，我們向他們承諾了什麼？」，然後將答案傳遞給下一個節點。

由於雙方都指向相同的記憶體，工作流程可以在不共享實作細節的情況下共享上下文。當記憶體保留實體之間的關係時，執行器工作流程會獲得相互關聯的答案，例如哪些合約將在下個季度到期，或者哪些帳戶具有相同的根本原因，這不是純粹的相似度搜尋能做到的。