我比較了 12 種 AI 程式碼代理記憶體，發現多數只記得「做了什麼」，而非「為何如此」

你的代理程式並沒有記憶問題，它有的是「為何如此」的問題。本文中提到的每個工具都能讓代理程式記住某些東西。Markdown 檔案能記住你輸入的內容，記憶層能記住從聊天中提取的事實，而會話記錄器則能記住執行了哪些工具。然而，很少有工具能記住真正耗費你時間的關鍵：為什麼某個修復方案會成功，以及哪三個看似明顯的修復方案已經嘗試過但失敗了。

過去幾週，我閱讀了所有能找到的代理程式記憶體選項的文件和原始碼，並向開發團隊發送了約 400 封陌生開發信，詢問他們如何處理 Claude Code、Cursor 和 Codex 的記憶體問題。大多數團隊不認為他們需要任何新東西，其中一些團隊的看法是正確的。這篇文章正是我希望在開始之前就能擁有的指南：每個選項實際儲存了什麼、由誰寫入、如何檢索、團隊是否能共享，以及它會在何處失效。

事先聲明：我開發了本次比較中的其中一個工具（palace-rs，以及其上的 Palace 團隊伺服器）。我已盡力以與其他工具相同的規則來描述它：只根據儲存庫和文件確認的內容，並包含其缺點。你可以據此權衡我的意見。

週一：Alice 的代理程式在支付 webhook 中遇到一個不穩定的測試。它嘗試使用重試包裝器（結果讓情況更糟），然後設定更長的逾時時間（只是掩蓋了問題）。接著，它找到了真正的原因：測試夾具在不同工作者之間共享資料庫連線。她修復了這個夾具。提交訊息寫道：「fix: isolate webhook fixture connection」。

週四：Bob 的代理程式在同一區域發現另一個不穩定的測試。它讀取 CLAUDE.md，但裡面沒有關於 webhook 的內容。它查看 Git 日誌並找到 Alice 的提交，但提交訊息並未說明「重試和逾時在這裡是陷阱」。因此，Bob 的代理程式嘗試使用重試包裝器，然後設定更長的逾時時間。四十分鐘後，它最終還是找到了相同的夾具修復方案。

這個故事中沒有任何奇特之處。它只是三個獨立的失敗堆疊在一起：代理程式會遺忘。每個會話都從一個空的上下文視窗開始。代理程式會重複走死胡同。成功的修復方案會被記錄下來（在提交中），但失敗的嘗試卻沒有被記錄。隊友的代理程式不共享記憶。即使 Alice 的代理程式記住了，那個記憶也只存在於 Alice 的筆記型電腦上。請記住這三點。下面的每個選項都解決了其中一些問題，但忽略了其餘問題。

「記憶體」一詞至少用於七種不同的事物。將它們混淆是這些比較無法得出結論的主要原因。

指令檔案（靜態上下文）：CLAUDE.md、AGENTS.md、Cursor rules、.github/copilot-instructions.md。這些是由人類（或在被要求時由代理程式）編寫的文字，並在每個會話中載入。

結構化儲存庫文件：記憶庫、ADR（架構決策記錄）、提交訊息、Allium 等規格檔案。這些仍然是 Git 中的檔案，但具有特定的架構或使用規範。

內建助理記憶體：Claude Code auto memory、Codex memories、Copilot Memory。供應商的工具會為自己寫筆記。

會話記錄器：claude-mem。它會監控代理程式的行為，將其壓縮成觀察結果，並在下次注入。

個人記憶層：Mem0、Supermemory、palace-rs、官方 MCP 知識圖譜伺服器、Basic Memory。這是一個 API、MCP 伺服器或本地引擎，為單一使用者的代理程式儲存事實或記錄。

圖形與代理程式管理記憶體：Zep/Graphiti（時間知識圖譜）、Cognee（圖形加向量）、Letta（代理程式編輯自己的記憶區塊）、LangMem（用於建構上述任何一種的函式庫），以及再次提到的 palace-rs（一個時間知識圖譜、一個房間圖譜，以及工作代理程式透過 MCP 工具管理的記憶體）。

palace-rs 不只屬於單一類別：它是一個個人記憶層、一個時間圖譜和代理程式管理記憶體，全部整合在一個本地引擎中。它仍然是單機運作；相同模型的團隊版本是 Palace Server，屬於第七類。

共享團隊記憶體：一個多個開發者代理程式可以讀寫並具有權限的儲存庫：Palace Server、Copilot 的儲存庫級事實，以及自建的團隊設定。很少有產品真正屬於這一類。

這張表格涵蓋了 19 個現有的選項（加上已不存在的 Cursor Memories）。表格後面的網格則比較了 12 個最常見的選項。表格之所以很長，是因為差異都藏在細節中。「誰寫入」和「能否使其失效」是程式碼代理程式最重要的兩個欄位，而這些正是行銷頁面經常跳過的部分。

該表格詳細列出了 19 種記憶體選項，其中「誰寫入」和「能否使其失效」是程式碼代理程式最關鍵的兩個指標。這些選項從由人類編寫的簡單指令檔案（如 CLAUDE.md），其失效僅能透過手動編輯達成，到更複雜的系統。

內建助理記憶體（例如 Claude Code auto memory、Codex memories、Copilot Memory）通常由供應商工具自動寫入。例如，Copilot Memory 在引文衝突時能儲存修正後的記憶，且未使用的條目會在 28 天後過期。

個人記憶層（例如 Mem0、Supermemory、palace-rs）和圖形/代理程式管理記憶體（例如 Zep、Cognee、Letta）通常涉及大型語言模型提取或代理程式管理的區塊。其中許多提供了明確的更新/刪除機制或雙時間失效功能，允許將錯誤或過時的資訊標記出來。

共享團隊記憶體解決方案，如 Palace Server，雖然稀有但對協同開發至關重要。它允許多個代理程式在權限控制下讀寫，並提供稽核日誌，支援團隊範圍的失效機制。作者自己的工具 palace-rs 被描述為一個多功能的本地引擎，結合了個人記憶、時間圖譜和代理程式管理記憶體，其團隊版本 Palace Server 則提供共享功能。

CLAUDE.md、AGENTS.md、.cursor/rules/*.mdc 和 .github/copilot-instructions.md 是放置規則的正確位置。例如，建構指令可以是「使用 pnpm，而非 npm」，或是「絕不要動生成的客戶端程式碼」。

Codex 預設會將儲存庫根目錄到當前目錄下的 AGENTS.md 檔案串聯起來，並在 32 KiB 處停止。Claude Code 在每次對話開始時載入 CLAUDE.md 檔案，也可以讀取 AGENTS.md 來替代。Cursor 規則可以是始終開啟、依 glob 範圍設定、由代理程式選擇或手動設定。

優點：這些檔案與程式碼一起版本控制，在 PR 中審查，並可供整個團隊免費共享。它們無需任何基礎設施，不會出錯，且具有確定性，讓你知道代理程式確切看到什麼。

缺點：每一行都會在每個會話中佔用上下文，因此人們會盡量縮短它們，這意味著歷史資訊首先被刪除。它們儲存的是結論，而非過程。「使用隔離的夾具」是一條規則，但「重試和逾時會隱藏這個錯誤」則是歷史，而歷史不應該放在每次提示時都會載入的規則檔案中。沒有人會在經過兩小時的偵錯後，在晚上六點去編寫這些檔案。

最有價值的知識往往出現在人們最沒有耐心的時刻。即使是供應商也劃清了這條界線。OpenAI 的 Codex 文件指出，必要的團隊指南應保留在 AGENTS.md 中，並將記憶體視為「有用的回憶層」。Anthropic 的文件則將 CLAUDE.md 描述為你編寫的指令，而自動記憶體則是 Claude 自己寫的筆記。指令檔案是配置，它們不是記憶體，也從未被設計為記憶體。