Context Rot：為什麼更大的 Context Window 不是答案

Context window 已達百萬 token，但這並沒有解決記憶問題，反而引出了一個新名詞：context rot。當你把所有對話塞進一個超長 context，模型的注意力品質會下降——越來越多的 token 競爭注意力，早期的關鍵指令被壓在雜訊之下，事實上被「遺忘」了，即使它仍然在 context 裡。

另一條路是積極修剪：每隔一段時間把舊對話刪掉。但修剪是有損的。「用 pnpm 而非 npm」、「這個 API 的 rate limit 在四月事件後改了」、「他們的 on-call 流程是這樣的」——這些細節被刪掉就是刪掉了，下次 session 再也找不回來。

Agent Memory 是第三條路：在壓縮時不是刪除，而是萃取。把對話中真正重要的知識——偏好、事實、流程、進行中的任務——以結構化的方式儲存起來，等需要時再精準取回，而不是讓它永遠佔用 context window。

關鍵洞察

Agent Memory 不取代 context，而是讓 context 只包含當下任務需要的內容。過去的知識不是刪除，是分類儲存，等待被呼叫。結果是：更乾淨的 context、更準確的模型回應、跨 session 和跨重啟的持續知識積累。

API 設計：Profile 是記憶的基本單位

Agent Memory 的設計圍繞一個核心概念：Profile。Profile 以名稱定址，代表一個記憶空間——可以是一個使用者、一個 agent、或一個團隊。不同 profile 之間的記憶完全隔離，防止跨用戶洩漏。

四個核心操作構成了整個 API：

ingest()
批次擷取對話 通常在壓縮時呼叫，把即將被丟棄的對話片段送進記憶管道。Agent Memory 的擷取是冪等的——重複送入同一段對話不會產生重複記憶。
remember()
模型主動儲存 讓模型（或應用程式碼）主動記住單筆重要事實，不需要走完整擷取管道。適合即時捕捉用戶明確告知的關鍵資訊。
recall()
全管道檢索 輸入一個自然語言問題，Agent Memory 同時觸發五條檢索管道，用 RRF 融合結果，回傳一段自然語言摘要。調用方不需要知道記憶是如何儲存的。
forget()
標記過時記憶 把某條記憶標記為不再真實或過時，而不是直接刪除。過時的記憶仍保留在 supersession chain 中，確保歷史可追溯。
Agent Memory API 基本用法 
const profile = await env.MEMORY.getProfile("my-project");

// 壓縮時批次擷取
await profile.ingest([
  { role: "user", content: "用 pnpm，不要 npm。深色模式預設開啟。" },
  { role: "assistant", content: "好，已記錄 pnpm 和深色模式設定。" },
], { sessionId: "session-001" });

// 模型主動記住
await profile.remember({
  content: "API rate limit 在 4 月 10 日事件後提升至 10,000 req/s。",
  sessionId: "session-001",
});

// 檢索
const result = await profile.recall("用戶偏好哪個套件管理器？");
console.log(result.result); // "用戶偏好 pnpm 而非 npm。"

這個 API 設計的哲學是：把記憶的複雜性封裝在服務內部。調用方只需要問「我記得什麼？」，不需要知道底下有多少條管道、向量空間是怎麼索引的，或者哪條記憶比哪條新。

三種使用場景

Agent Memory 設計成可以接在任何 agent 框架上，不需要改動 agent 的核心迴圈。Cloudflare 描述了三個主要場景，彼此的記憶需求截然不同：

1
個人 Agent 記憶 coding agents（Claude Code、OpenCode）、自托管框架（OpenClaw）、Anthropic Managed Agents 都能掛接 Agent Memory，不改 agent 核心迴圈。agent 累積的偏好設定、最常用工具、project 特定知識，跨 session 持續存在。你重開 terminal、重啟 agent——它還記得你上次說的一切。
2
共享團隊記憶 一個 profile 對應整個團隊，A 的 coding agent 學到的 coding conventions，B 的 agent 也能用。更進一步：code review bot 和 coding agent 可以共用同一個 profile，review 意見自動影響下次的程式生成。這讓團隊的工程實踐能夠從個人習慣自動沉澱為組織知識。
3
長期運行的 Background Agent Ramp、Stripe、Spotify 等公司正在構建跑數週的 background agent——財務分析 agent、事件監控 agent、客戶對話 agent。這些 agent 橫跨多個 session 和系統重啟，傳統的 context window 根本無法承載它們需要的歷史深度。Agent Memory 讓知識在 agent 的整個生命週期中持續積累。
為什麼不用資料庫？

你當然可以自己用 PostgreSQL 或 Redis 存記憶。但問題在於：怎麼知道要存什麼？怎麼決定什麼是「重要的事實」而不是閒聊？怎麼做到同一件事更新後舊版本被取代？怎麼搜尋一句話找到相關記憶？Agent Memory 把這些問題都封裝掉了——工程師不需要自己設計知識萃取、分類、版本管理和多模態檢索的完整系統。

擷取管道：四類記憶的生命週期

當你呼叫 ingest()，對話進入一條五階段的處理管道。這條管道的設計目標是：在壓縮時把知識萃取出來，而不是只做摘要。

Step 1
確定性 ID 生成 對每條訊息計算 SHA-256 content-addressed ID。相同內容的重複擷取自動冪等，不產生重複記憶，也不需要外部去重機制。
Step 2
兩路並行萃取 同時跑兩條萃取 pass：完整 pass 對 10K token chunks 做整體理解；detail pass 在對話超過 9 則訊息時啟動，專門針對具體數值、日期、精確名稱做二次抽取，確保細節不在摘要中被泛化掉。
Step 3
八點驗證 萃取出的候選記憶要通過八個維度的驗證：實體完整性、位置正確性、時間一致性、組織關係、跨記憶一致性、因果關係、可驗證性、重要性評估。每條記憶會被標記為通過、修正後通過，或丟棄。
Step 4
四類分類與 Supersession 通過驗證的記憶被分入四類：Facts（穩定事實，如偏好設定）、Events（特定時間點發生的事，如某次事件）、Instructions（流程、runbook、操作程序）、Tasks（進行中的任務，具短暫性）。Facts 和 Instructions 有 key——同 key 的新記憶不會並存，而是形成 supersession chain：舊記憶被標記為 superseded，新記憶取代其位置，歷史保留可追溯。
Step 5
非同步向量化 最終步驟在背景非同步進行：為每條記憶生成 embedding，並預先加入 3–5 個搜尋問題（hypothetical questions）。這橋接了「記憶的寫法（陳述句）」與「搜尋的問法（疑問句）」之間的語意差距，讓向量搜尋更精準。

這個管道的設計考量在於：記憶的品質比數量更重要。每條進入儲存的記憶都是通過多個關卡驗證的，而不是把所有對話摘要直接堆進向量資料庫。

檢索管道：五管道 + RRF 融合

當你呼叫 recall()，Agent Memory 同時觸發五條並行的檢索管道，最後用 Reciprocal Rank Fusion（RRF）把結果融合成一個排序清單，再交給合成模型生成自然語言摘要。

FTS — Porter Stemming
全文搜尋

基於 Porter stemming 演算法的全文搜尋，適合精確關鍵字匹配。「pnpm」、「rate limit」、「Stripe webhook」這類術語用 FTS 最可靠，不受向量語意漂移影響。

Exact Fact-Key
精確 key 匹配

直接命中已知 topic key 的最新有效記憶。當查詢問「用戶的套件管理器偏好」，如果系統已知這是一個 Fact key，直接拿最新版本，不需要向量搜尋。Fact-key 匹配在 RRF 中擁有最高權重。

Raw Message Search
原始訊息全文搜尋

搜尋原始訊息內容，而不只是萃取後的記憶。補捉萃取管道可能泛化掉的細節——例如某段對話中提到的具體 URL、精確的錯誤訊息、逐字的用戶引述。

Direct Vector
直接向量搜尋

對查詢做 embedding，在記憶向量空間中找語意相似的記憶。適合語意查詢——「我們討論過的部署方式」不一定包含任何精確關鍵字，但向量搜尋能找到相關記憶。

HyDE Vector
假設答案向量搜尋

Hypothetical Document Embeddings：把問題先轉成「假設的答案文字」，再對這段答案做 embedding 去搜尋。特別適合抽象或高層次查詢，因為假設答案的 embedding 空間和記憶的 embedding 空間更接近。

Temporal Query
時間查詢

包含時間語意的查詢（「最近」、「上週」、「2026-04-10 之後」）由 regex + 算術處理，而不是讓 LLM 做日期數學。確保時間範圍精準，不因模型的日期推算不穩定而遺漏記憶。

為什麼不只用向量搜尋

「用戶偏好哪種深色主題？」和「dark mode preference」這類查詢用向量搜得到。但「2026-04-10 rate limit 事件的具體數值」用向量搜尋可能找到語意相近但數值錯誤的記憶。FTS 抓得到精確術語，Exact Fact-key 直接命中最新版本，Temporal 查詢確保日期不偏移。五管道融合的本質是：沒有一種搜尋方法在所有情境下都最優，用多管道互補才能讓 recall 準確率最大化。

RRF 融合時，Exact Fact-key 命中的記憶獲得最高排名加成。最終結果交給合成模型生成自然語言摘要，recall() 回傳的 result.result 是一段可直接注入 system prompt 的文字，不需要調用方自行處理原始記憶清單。

技術架構：Cloudflare 平台的自我應用

Agent Memory 是 Cloudflare 把自己的平台能力拼裝成一個服務的典型例子——不是專用硬體，而是 Durable Objects、Vectorize、Workers AI 三者的組合，透過設計決策讓它們協同運作。

DO
Durable Objects — 記憶的核心 每個 profile 對應一個獨立的 Durable Object，內建 SQLite。DO 負責：FTS 索引（Porter stemming）、supersession chain 管理（舊記憶標記、新記憶指向、版本追蹤）、四類記憶的結構化儲存。DO 的強租戶隔離確保不同 profile 的記憶永遠不會互相干擾。
Vectorize
Vectorize — 語意搜尋索引 Cloudflare 的托管向量資料庫。存放每條記憶的 embedding（包含預生成的 3–5 個搜尋問題的 embedding）。當記憶被 superseded（取代），對應的向量同步從 Vectorize 中刪除，確保向量索引不累積過時記憶。
Workers AI
Workers AI — 兩個不同規模的模型 擷取管道用 Llama 4 Scout（17B 參數，16-expert Mixture of Experts）做萃取、分類和查詢分析——MoE 架構讓它在速度和能力之間取得好平衡，適合高頻的批次處理任務。recall() 的最終合成步驟用 Nemotron 3（120B MoE，12B active）——這是整個管道中唯一真正需要更大模型的步驟，因為合成摘要需要更強的語言理解和生成能力。

這個架構選擇有一個有趣的含義：Agent Memory 的核心狀態完全在 Durable Objects 中，向量索引是輔助的可重建結構。如果 Vectorize 索引出問題，只需要重新 embed 並重建索引，不會丟失任何記憶的原始內容。

OAO Studio 觀點

Agent Memory 最有意思的地方不是 API 設計，而是 shared team memory 的想像：團隊裡每個人的 coding agent 學到的東西，都能沉澱成可被所有人查詢的知識庫。code review bot 的每一條 review 意見，都可能影響所有隊員的 coding agent 下次怎麼寫程式。這把「context 清空後就消失的對話歷史」轉成了一個持續成長的機構資產——像一個從來不會忘記東西的技術文件系統，而且是自動寫入、自動更新的。

Agent Memory 目前在 Private Beta 階段，有興趣的開發者可以前往 developers.cloudflare.com/agents 申請早期存取。Cloudflare 表示 GA 後將納入 Workers 付費方案，定價尚未公布。

← 返回 AI 知識庫