# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：mem0 (@mem0ai) · 平台：X (Twitter) · 日期：2026-06-03

> 原始來源：https://x.com/mem0ai/status/2061822612398014782

## 中文摘要

# Agent Harness 中的記憶體現狀

Agent harness 是 AI 軟體實際運作的地方。Cursor、Devin、Claude Code、Codex：這些環境負責處理 context、編排工具、協調 Agent，且越來越多地開始管理「記憶」。Harness 而非模型，正逐漸成為交付軟體的產品核心。

記憶體正是 harness 設計中最困難的部分。

它該放在哪裡？當對話結束時，什麼資料會被保留？這基本上是一個尚未解決的問題，每個主要的 harness 都在以不同的方式嘗試解決它。

這篇文章將涵蓋各個 harness 實際交付的功能、它們的不足之處，以及這些差距反映出記憶體基礎設施還需要具備哪些能力。

---

## Agent 的記憶究竟是什麼？

有三種不同的東西被稱為「記憶」，區分它們至關重要，因為每一種都有不同的失效模式。

1. **工作記憶 (Working memory)**：指在對話期間存在於 context window 中的內容。它會在對話結束時重置；壓縮問題（當視窗填滿時保留什麼）屬於這一類。

2. **外部記憶 (External memory)**：指權重之外任何被持久化的內容：向量資料庫 (vector stores)、知識圖譜、檔案。它能跨越對話存續；模型權重不會改變。這基本上是 2026 年所有生產環境記憶體存在的地方。

3. **參數記憶 (Parametric memory)**：指透過梯度下降編碼進權重中的知識，由 harness 提供的訓練迴圈所塑造。它透過應用規則而非檢索範例來進行泛化。2026 年尚未有任何生產部署採用此技術。

（認知科學中的分類：語意記憶 / 情節記憶 / 程序記憶，描述的是儲存的「資訊類型」；上述三個層級則描述了它「存在哪裡」。）

論文《Contextual Agentic Memory is a Memo, Not True Memory》(arXiv:2604.27707) 將其上限形式化：檢索需要 Ω(k²) 個儲存範例，才能達到參數記憶透過 O(d) 權重更新所能達到的效果。以下所有系統都在此限制內運作。

---

## 主要 Harness 的交付成果 [概覽]

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465835157-diaHJ0MFa6b0AAsANjpg.jpg)

---

### 1. @AnthropicAI: Claude Code

分為兩條路徑。`CLAUDE.md` 是人類編寫的設定（慣例、指令），在對話開始時讀取。`Auto-memory` 則是 Claude 從背景提取 Agent 所寫的筆記，儲存在 `~/.claude/projects/<repo>/memory/` 下，並圍繞一個 `MEMORY.md` 索引，限制為 200 行 / 25KB，分為四類：使用者、回饋、專案、參考。

檢索方式決定了其限制：每次對話時，Claude Code 都會呼叫一個較小的模型，並附上檔案名稱與描述清單，由模型挑選要載入的檔案。沒有使用 embeddings，每次對話最多載入五個檔案，且超過上限後會進行無提示的截斷（被丟棄的檔案不會收到警告，因為它根本沒被載入）。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465835217-iaHJ0MTs9bYAEUR4Ojpg.jpg)

**缺點**：選擇方式是基於檔案名稱，而非語意搜尋，因此名稱相關的檔案會勝過內容相關的檔案。雖然透過 `TEAMMEM` 旗標可以進行團隊共享，但底層仍是區域性、以專案為範圍的 Markdown，且沒有語意索引。

---

### 2. @AnthropicAI: Managed Agents

Managed Agents 是 Anthropic 的託管 Agent 執行環境，而非像 Claude Code 那樣的本地產品。對話是一個「僅能附加 (append-only)」的事件日誌，永遠不會被修改，因此復原與稽核是架構內建的，而非事後外掛。記憶體儲存掛載在 `/mnt/memory/` 作為檔案系統（每個 workspace 最多 8 個，每個約 100KB）；每次寫入都是不可變的版本，多個 Agent 可以同時共享一個儲存區，並擁有可稽核的歷史記錄，而非發生衝突。

**缺點**：它是為 workspace 規模的多 Agent 協調而建，而非長期的個人記憶。每個儲存區 100KB 的上限和 workspace 範圍的限制，意味著跨對話的個人 context 需要在其之上建立一套機制。

---

### 3. @OpenAI Codex

Codex 的記憶體是一個 Markdown 目錄，`~/.codex/memories/`（沒有 SQLite，沒有 embeddings）：首先讀取 `memory_summary.md`，按需 grep `MEMORY.md`，外加 `raw_memories.md`、`skills/` 和 `rollout_summaries/`。預設為關閉，需透過 `features.memories` 旗標啟用。

寫入路徑分為兩階段。階段 1，針對每個 rollout：在對話閒置六小時後，Codex 會根據嚴格的 schema 進行提取、遮蔽敏感資訊，並寫入本地狀態資料庫（尚未寫入記憶體目錄）。階段 2，全域：在鎖定狀態下，合併子 Agent 會進行合併、修補或刪除，並寫入差異檔。它是有邊界的（256 個 rollouts）、有年齡刪除機制（30 天），且具備速率限制感知。讀取路徑是非語意的：摘要被截斷在固定的 5,000 token 預算內，其他內容則透過 `grep` 搜尋 `MEMORY.md`。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465834826-diaHJ0ML7awAAzJh5jpg.jpg)

**缺點**：5,000 token 的摘要會無提示地截斷；grep 僅限於子字串搜尋，因此改寫過的事實會無法被搜尋到；六小時閒置的門檻意味著連續的對話可能永遠不會進行合併；狀態僅限本地；且發布時該功能在 EEA、英國和瑞士無法使用。

---

### 4. @github Copilot

Copilot 的獨特之處在於「即時引用驗證 (just-in-time citation verification)」。記憶項目是結構化物件（主題、事實內容、檔案與行號引用、推理），在使用前，Agent 會針對當前分支驗證引用，並重寫程式碼現在已矛盾的記憶。記憶也會在 28 天後自動過期。

這是目前唯一有發布成效資料的陳舊性處理機制：經 A/B 測試 (p<0.00001)，開啟記憶功能後，PR 合併率從 83% 上升至 90%，程式碼審查精確度提升 3%，召回率提升 4%。這 7 個百分點的提升是目前唯一關於程式設計 Agent 記憶的真實生產環境指標；其他人報告的都是基準測試。

**缺點**：引用 schema 無法妥善處理無法驗證或基於偏好的事實（例如「偏好最小化抽象」），且嚴格限制在專案範圍內。

---

### 5. @openclaw

OpenClaw 的原生記憶體比看起來更強大：位於 `~/.openclaw/workspace` 的 Markdown（一個精選的 `MEMORY.md` 加上帶有日期的每日日誌），並由每個 Agent 的 SQLite 索引支援，包含 embeddings 和混合檢索（70% 向量，30% BM25）。因此它原生具備語意搜尋功能。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465834610-iaHJ0NY4sbUAAskVPjpg.jpg)

問題在於什麼會被保留。當視窗填滿時，OpenClaw 會觸發一個「靜默內部對話」，要求模型在清除前將重要內容寫入磁碟。寫入的內容取決於模型在那一次對話中決定的內容，因此長期記憶是選擇性且不一致的。Mem0 plugin (@mem0/openclaw-mem0) 移除了這種依賴：`Auto-Recall` 在每次對話前注入相關記憶，而 `Auto-Capture` 在每次交換後持久化它（儲存新事實、更新舊事實、合併重複項），並以對話 `run_id` 和長期 `userId` 為範圍。其 247,000 顆星的採用率很大程度上是由於這個缺口所推動的。

---

### 6. @NousResearch: Hermes Agent

Hermes（135,000 顆星，200+ 模型）內建三層架構加上八個可插拔的提供者。第 1 層，工作記憶：`MEMORY.md` (2,200 字元) 和 `USER.md` (1,375 字元)，合計約 1,300 tokens，以 `§` 分隔，具備利用率監控，並在 80% 容量時進行合併。寫入會存入磁碟，但系統提示詞會保留一個凍結的快照直到下次對話，以維持 prefix cache。第 2 層，skill：在 5 次以上工具呼叫任務後編寫的程序文件，按排程整理。第 3 層，對話搜尋：對所有對話進行 SQLite FTS5 搜尋，按需總結。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465834605-iaHJ0NpK1bsAA09yVjpg.jpg)

**缺點**：上限極小（約 800 tokens 的持久記憶），FTS5 僅限關鍵字（「429 errors」無法匹配「rate limiting」），且是本地的。這就是為什麼 Hermes 提供了一個提供者插槽：使用 Mem0 後，上限消失，檢索變為語意化，提取在伺服器端執行，寫入由 `MEM0_USER_ID` 限制範圍，且若服務中斷，斷路器會確保內建層仍能運作。

---

### 7. @awscloud Bedrock AgentCore

AgentCore 是 AWS 的託管 Agent 平台：其 `Runtime` 是 harness 層（AWS 對 Managed Agents 的類比），而 `Memory` 是其託管服務。記憶體執行三種非同步提取策略（語意事實、偏好、敘事摘要），提取需約 20–40 秒，檢索需約 200 毫秒；變更的事實會被標記為 INVALID 而非刪除，以保留血緣關係。已發布指標：LoCoMo 70.58，PrefEval 79，PolyBench-QA 83.02。

**缺點**：它是 AWS 專有的（生態系統鎖定），且其發布的 LoCoMo 分數遠低於領先的記憶體系統。

---

### 8. @windsurf

Windsurf 的記憶體由其引擎 Cascade 生成與管理，無需開發者工作流程：在 `~/.codeium/windsurf/memories/` 下的本地、專案範圍檔案，捕捉程式碼庫的模式與慣例。

**缺點**：捕捉到的是 Cascade 的呼叫，而非開發者的；記憶體僅限專案範圍（跨專案不可見）且是本地的（無跨裝置或團隊共享）。

---

### 9. Cognition Devin

Devin 將記憶一分為二。`Knowledge` 是人類策劃的觸發內容事實（無自動捕捉）；`DeepWiki` 是參考文件（30 頁，100 則筆記，每則 10,000 字元）。Devin 會在對話後建議 Knowledge，但必須由人類核准後才會儲存。

**缺點**：核准機制保持了高品質，但也造成了摩擦：不進行審查的團隊最終什麼也沒累積。限制適中，且 Knowledge 是為 Devin 策劃的，因此無法轉移到其他工具。

---

## 記憶體基準測試是薄弱環節

業界用來衡量記憶體的基準測試大多很糟糕。它們測試的是對過去對話中事實的召回，且接近飽和，高分並不能預測更好的決策。

LoCoMo 是常見基準中最差的一個。十次對話使得比較不可靠，許多問題不需要記憶（簡單的 grep 基線就能達到約 74%），且對抗性問題與目標存在表面相似性，因此模型透過模式匹配獲勝。`LongMemEval` 還算可以：在五種能力（資訊提取、多對話推理、時間推理、知識更新、拒絕回答）中測試 500 個策劃問題，規模擴展至 150 萬 tokens；雖然仍以召回為中心，但算是一個真正的測試。

更深層的問題是它們都沒有測量到什麼。`MemoryArena` (arXiv:2602.16313) 測試的是必須「引導行動」的記憶，而那些在 LoCoMo 和 LongMemEval 中接近飽和的系統卻在該測試中失敗；《Anatomy of Agentic Memory》(arXiv:2602.19320) 將此批評形式化（接近飽和，測量的是相似度而非任務效用）。

且沒有一個是在生產規模下測試的：標準基準測試上限接近 150 萬 tokens，而生產環境的 Agent 則達到 1,000 萬 tokens 以上。BEAM (ICLR 2026) 是唯一為該範圍建構的基準。誠實的結論是：該領域需要一個新的記憶體基準測試，排行榜分數應持懷疑態度，包括下方的分數。

---

## 研究顯示仍存在的問題

穩定性與可塑性困境 (stability-plasticity dilemma) 轉移了。轉向外部記憶並沒有終止災難性遺忘。《When Continual Learning Moves to Memory》(arXiv:2604.27003) 顯示新舊記憶在爭奪檢索槽位，正如它們曾經爭奪權重一樣；來自簡單任務的原始軌跡會損害更困難的任務（前向遷移 −9.5%）。

選擇性遺忘尚未解決。`MemoryAgentBench` (arXiv:2507.05257) 列出了四種能力；系統能處理檢索，但無法處理選擇性遺忘（在保留周圍結構的同時遺忘一個陳舊的事實）。

記憶體是一個攻擊面。「No Attacker Needed」(arXiv:2604.01350) 測量到在正常使用下有 57–71% 的跨使用者污染；中毒攻擊的成功率為 6–38% (arXiv:2601.05504)。

---

## 缺點中的模式

同樣的差距反覆出現。儲存是**有邊界且本地化**的（Claude Code 25KB，Hermes 2,200 字元，Codex 的 5,000 token 負載）。檢索**大多是關鍵字**（Claude Code 按檔案名稱，Codex 按 grep，Hermes 按 FTS5）；唯二進行語意搜尋的系統，要麼是本地且受壓縮限制 (OpenClaw)，要麼是雲端鎖定 (AgentCore)。記憶體是**以 harness 為範圍**的，所以 Claude Code 的記憶對 Codex 毫無意義。**陳舊性處理**幾乎不存在（Copilot 除外）。而**隔離性**是事後才考慮的，因此才會有污染數據。這些都是 harness 邊界的限制。

---

## Mem0

Mem0 是為 harness 邊界並非問題終點的情況而建。其架構是混合式的：用於語意檢索的向量儲存、用於關係推理的知識圖譜，以及用於快速元資料的鍵值對儲存。

v3 演算法（2026 年 4 月）轉向單次 ADD-only 提取、多訊號檢索（一次傳遞中結合語意 + BM25 + 實體連結），以及向量儲存內的實體連結，放棄了 v2 的外部圖資料庫。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780465834967-iaHJ0ObSnaUAANlKHjpg.jpg)

它在每次查詢約 6,900 tokens 和 1.44 秒內完成，而全 context 檢索則需要約 26,000 tokens 和 17.12 秒。

針對上述差距：一個**無上限**的外部儲存；**多訊號檢索**，即使措辭不同也能找到上個月關於 auth-endpoint 的討論；**以身分為範圍**的記憶，確保一個使用者的命名空間不會洩漏，針對 57–71% 的污染率。這並非理論：Mem0 為上述每個 harness 提供支援，包括 Claude Code plugin、Codex MCP 伺服器、Hermes 和 OpenClaw 的一級提供者、原生的 AWS Strands 整合，跨越 21 個框架和 20 個向量儲存。記憶體成為了基礎設施，而非每個 harness 的個別功能。

---

## 現狀總結

記憶體現在是基礎設施：每個主要的 harness 都交付了它，因為一個在對話內有能力，但在對話間卻患有失憶症的 Agent，本質上是受限的。

Harness 原生的實作取得了實質進展，但它們在同樣的邊界上崩潰：有邊界的本地儲存、關鍵字檢索、harness 範圍限制、薄弱的陳舊性處理以及隔離性差距。

旨在衡量這一切的基準測試本身就很薄弱，而唯一測試生產規模的基準 (BEAM) 卻是大多數系統不報告的。

總體而言，這些正是 Mem0 努力填補的差距：可攜帶、可語意搜尋、跨 Agent，並能擴展到生產環境 Agent 所累積的 token 量的記憶體。

---

## In Context #11

本部落格是 In Context 的一部分，這是 @mem0ai 的系列部落格，涵蓋 AI Agent 記憶與 context 工程。

Mem0 是一個智慧、開源的記憶層，專為 LLM 和 AI Agent 設計，旨在提供跨對話的長期、個人化且具備 context 感知的互動。

- 在此取得免費 API Key：app.mem0.ai
- 或從我們的開源 GitHub 儲存庫自行託管 mem0

---

## 參考文獻

- Contextual Agentic Memory is a Memo, Not True Memory (2026 年 4 月)
- MemoryArena (2026 年 2 月, Stanford/UCSD/Princeton)
- Anatomy of Agentic Memory (2026 年 2 月)
- When Continual Learning Moves to Memory (2026 年 4 月)
- MemoryAgentBench, ICLR 2026
- No Attacker Needed: Cross-User Contamination (2026 年 4 月)
- Memory Poisoning Attack and Defense (2025 年 1 月)
- Anthropic Engineering: Scaling Managed Agents (2026 年 4 月)
- OpenAI: Codex memories documentation
- AWS: Amazon Bedrock AgentCore Memory
- NousResearch: Hermes Agent
- Mem0: Token-Efficient Memory Algorithm (2026 年 4 月)
- Mem0: BEAM Benchmark
- Mem0: How Memory Works in Claude Code
- Mem0: Codex CLI Memory
- Mem0: How Memory Works in Hermes Agent
- Mem0: OpenClaw Memory System
- AWS and Mem0 Partner to Bring Persistent Memory to Strands

## 標籤

Agent, Harness, 記憶系統, 產業趨勢, Cursor, Devin, Claude Code, Codex