TLDR：大多數 Agent 會重置並遺忘一切。以下是我建立的精確記憶堆疊，讓我的 Agent 能夠在重啟後共享上下文、協作時不互相干擾，並將決策保留數月之久。
無人解決的問題
這是典型的 AI Agent 記憶設定。把重要事項塞進系統提示詞。祈禱上下文視窗不會耗盡。重啟後一切歸零。
過去 6 個月，我在數百個工作階段中運行了兩個協作 Agent（Ella 在 OpenClaw 上，Lyra 在 Hermes 上）。讓它們真正有用的關鍵，不是模型或工具，而是記憶架構。
當 Lyra 在凌晨 2 點修復了一個問題，Ella 早上就會知道。當我在 1 月決定好密碼的儲存方式，兩個 Agent 在 7 月仍會遵循這個決定。當一個工作階段在任務中途崩潰，下一個工作階段會從中斷處精確接續。
以下是精確的 4 層系統。
第 1 層：工作階段內上下文
每個工作階段從讀取兩個檔案開始。身份檔案是 Agent 的固定身份。不是埋在設定檔中的系統提示詞，而是一個我可以編輯的實際 Markdown 檔案。它記錄了 Agent 應有的行為模式、優先事項、未經詢問絕不執行的事項，以及它與其他 Agent 的關係。
記憶索引檔案是跨工作階段所有值得記住事項的索引。不是向量資料庫，也不是嵌入向量。它是一個純文字目錄，指向各個獨立的記憶檔案。每個記憶檔案都是一則簡短的筆記，包含名稱、描述、類型和簡短內容。索引始終會被載入。個別檔案則在相關時按需讀取。
為什麼用 Markdown？因為我可以閱讀、編輯和除錯。當 Agent 行為異常時，我打開索引就能找到錯誤的指令。當我想改變某個行為時，我編輯檔案。不需要 API、儀表板或重新訓練。
第 2 層：工作階段後保留（Hindsight）
純 Markdown 記憶的問題在於：它只能捕捉明確寫下的內容。而最有價值的上下文往往是隱性的。例如執行期間做出的決定、從任務中推斷出的事實、以及後來證明很重要的事情。
Hindsight 是一個運行在 localhost 上的本地事實保留後端。在每個重要工作階段結束時，Agent 會自動將一組精選的保留事實推送到一個命名的儲存庫中。每個 Agent 都有自己的儲存庫。
保留的內容包括：工作階段期間做出的決定、關於使用者或專案的非顯而易見的事實、失敗模式及我們採用的修復方案，以及使用者確認或修正過的偏好設定。
當新工作階段開始時，Agent 在回答前會先查詢 Hindsight 以獲取相關上下文。這不是對完整對話記錄進行全文搜尋，而是經過策劃、按類型標記的事實，是 Agent 學到值得延續的內容。
推薦路徑：Hindsight 事實 → 人工審查 → 記憶索引條目。自動保留搭配人工審核關卡。
第 3 層：共享長期狀態（Nexus）
當你加入第二個 Agent 時，單一 Agent 的記憶就會失效。它們會產生分歧。一個認為 X 是目前的專案狀態，另一個認為是 Y。不到一週，它們就會互相矛盾。
解決方案是一個共享且可檢查的狀態檔案，兩個 Agent 都能讀寫。我們使用一個我稱之為 Nexus 的 Obsidian 筆記庫。它包含一個即時上下文日誌（兩個 Agent 在每次有意義的互動後都會追加內容）、一個專案狀態檔案、一個決策日誌，以及每個 Agent 的工作上下文檢查點（在長時間任務中每隔幾次工具呼叫就會更新）。
即時上下文檔案是即時握手機制。不變原則：每次回覆前先讀取它。每次有意義的互動後，追加內容到其中。
當 Lyra 在凌晨 2 點完成一個 PR，而 Ella 正在回答我早上的問題時，Ella 已經知道了。她讀取了日誌。不需要訊息傳遞、跨 Agent API 或輪詢。一個共享檔案、兩個 Agent、僅追加的日誌。
第 4 層：可搜尋的知識（gbrain）
前三層處理的是情節記憶：發生過什麼、決定了什麼、哪些值得延續。gbrain 是語意層。它是一個編譯過的 Wiki，作為 MCP 伺服器運行在 Nexus 筆記庫之上。對所有已記錄的內容進行全文和語意搜尋。
當 Agent 需要回答研究問題、尋找先前的綜合分析，或查詢我們過去如何處理某類問題時，它會查詢 gbrain，而不是重新讀取每個檔案。輸出結果是按相關性排序的頁面列表，並附有來源。Agent 只讀取相關的內容，不會將整個筆記庫都載入到上下文中。
這就是記憶與回憶的區別。第 1 到第 3 層處理 Agent 攜帶的內容。第 4 層處理 Agent 可以查詢的內容。
跨 Agent 同步不變原則
兩個 Agent，一個即時上下文檔案。風險在於：它們會互相覆蓋，或錯過彼此的條目。我們運行的不變原則是：每個條目都帶有 Agent 名稱、頻道、類型和一行摘要的簽名。僅追加。絕不編輯他人的條目。如果 Lyra 記錄了相關事項，Ella 會在下一次回覆中明確確認。對於重大決策，兩個 Agent 還會將帶有時間戳和理由的內容寫入決策日誌。
這個機制已經運行了數百個工作階段。我們只遇到過一次衝突：在交接過程中，兩個 Agent 在同一分鐘內追加了內容。解決方案：讀取兩個條目，在下一次互動中進行協調。不需要自動合併。
這取代了什麼
在這個架構之前：五個斷開連線的聊天工作階段，每個都有自己過時的上下文。Agent 互相矛盾，因為彼此都看不到對方知道什麼。三週前給的指令被遺忘。決策只存在於我的腦海裡，而不是檔案中。
之後：兩個 Agent 在每次回覆前都會先簡報自己。一個共享的狀態日誌，雙方都無法否認。保留的決策能經得起數月的上下文重置。每個行為偏好都存在一個我可以編輯和驗證的檔案中。
誠實的代價：這個系統需要紀律。你必須記錄下來。你必須維護這些檔案。你必須在保留內容成為永久記錄之前進行審查。它不是一個神奇的永遠在線系統。它是有結構的手動紀律加上自動化輔助。
如何開始
你不需要兩個 Agent 或一個完整的筆記庫來運行第一版。
步驟 1：一個身份檔案加上一個記憶索引。建立它們。在工作階段開始時讀取它們。當你第二次為了同一件事糾正 Agent 時，將該行為偏好寫入索引。
步驟 2：一個共享狀態檔案。如果你運行超過一個 Agent，或者在多個視窗中使用 Claude，請建立一個即時上下文檔案。每個工作階段在結束時追加內容，並在開始時讀取它。
步驟 3：一個保留規則。當一個工作階段產生了應該保留的決策時，手動將其寫入索引。先手動執行，直到你信任這個模式。然後再自動化標記流程。
步驟 4：每個事實一個檔案，而不是一個大文件。索引指向各個獨立的檔案。這使得刪除過時的記憶變得容易，而不會影響其他內容。
完整的 4 層堆疊大約花了 6 個月才穩定下來。第 1 層和第 3 層花了一個週末。從那裡開始。
重點總結
大多數 Agent 記憶設定不過是帶有額外步驟的上下文視窗管理。它們在視窗重置或你加入第二個 Agent 時就會失效。
持久的 Agent 記憶是一個基礎設施問題，而不是提示詞工程問題。答案是具有不同時間範圍的多層架構：工作階段內上下文、跨工作階段事實、共享狀態、可搜尋的知識。
我們所有的記憶都是純 Markdown。沒有向量資料庫、嵌入向量或重新訓練。只有我可以打開、編輯和除錯的檔案。
真正有用的 Agent，不是那些擁有最大上下文視窗的，而是那些記住重要的事、忘記不重要的事的。
如果你正在建立你想要信任來處理實際工作的 Agent，請先從記憶架構開始，然後再添加更多工具。
參考工具
Hindsight（本地記憶保留）：https://github.com/vectorize-io/hindsight
gbrain（編譯 Wiki / 語意搜尋）：https://github.com/garrytan/gbrain
OpenClaw（Agent 運行時）：https://openclaw.ai
Hermes（Agent 運行時）：hermes-agent.nousresearch.com
