# 如何成為 Memory Engineer：從 Stanford、Microsoft、Anthropic 與 Nvidia 的觀點出發 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：NO1ennn (@N01ennn) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥 · 日期：2026-08-04 > 原始來源：https://x.com/n01ennn/status/2083971749079581120 ## 證據與延伸閱讀 - [如何成為 Memory Engineer：從 Stanford、Microsoft、Anthropic 與 Nvidia 的觀點出發](https://x.com/n01ennn/status/2083971749079581120) — 一手來源 - [Nvidia硬體層效能數據](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/470befaa15ed3362.png) - [Agent Memory：長期 Agent 工作負載研究](https://arxiv.org/abs/2606.06448) — 一手來源 - [PlugMem：將 Agent 互動轉為可重用知識](https://www.microsoft.com/en-us/research/blog/from-raw-interaction-to-reusable-knowledge-rethinking-memory-for-ai-agents/) — 官方文件 - [MEMENTO：讓模型管理自己的上下文](https://arxiv.org/abs/2604.09852) — 一手來源 - [Microsoft Research 的 Memento 說明](https://www.microsoft.com/en-us/research/articles/memento-teaching-llms-to-manage-their-own-context/) — 官方文件 - [Claude Managed Agents 內建記憶說明](https://claude.com/blog/claude-managed-agents-memory) — 官方文件 - [Memento 作者技術說明：B200 服務效能](https://vkonton.github.io/blog/memento/) — 二手分析 - [X 文章原始封面圖](https://pbs.twimg.com/media/HOvBNunXMAA3pVd.jpg) — 一手來源 ## 中文摘要 # 如何成為 Memory Engineer：從 Stanford、Microsoft、Anthropic 與 Nvidia 的觀點出發 ![LLM Agent 的記憶架構與工作流程圖，展示從 Generation、Ingestion 到 Construction + Storage、Retrieval + Prompt Assembly 的完整循環，並將其抽象化為兩層記憶階層。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/470befaa15ed3362.png)
展開畫面重點
畫面左側為 LLM Agent 與 Environment 的互動架構圖，包含以下區塊與文字： - 左上方繪製一代表使用者的圖示，標示「User query」，向右傳遞至「LLM Agent」。 - LLM Agent 包含一組虛線框內的循環流程：「Observe」、「Reason」、「Act」，並透過「Feedback」與下方的「Environment」進行雙向互動。 - 從 LLM Agent 延伸出「Generation」標籤，流向「Interaction stream」（包含 `<user>`、`<assistant>`、`<tool output>` 的對話記錄區塊）。 - 接著經由「Ingestion」轉為「memory construction units (eg. chunks / conversation turns)」，進入「Construction + Storage (Write Path)」階段，寫入中央的「Agent Memory」資料庫。 - 從「Agent Memory」出發的「Retrieval + Prompt Assembly (Read Path)」讀取 memory entries，回傳至 LLM Agent。 - 「Agent Memory」下方帶有「Maintenance」標籤與循環箭頭，說明「Memory systems may organize entries by type, though most use a homogeneous store.」，並列出三種記憶類型： - 「Semantic / Facts / Knowledge」（搭配資料庫圖示） - 「Episodic / Past experiences」（搭配大腦圖示） - 「Procedural / skills / strategies」（搭配齒輪圖示） - 畫面右側區塊標示：「This pipeline can be abstracted as a two-tier memory hierarchy:」，並繪製一個兩層記憶階層： - 上方為「LLM」，連接至「Short-term memory (current context and retrieved memories)」，可執行「Forget」。 - 與下方「Long-term memory (Persisted agent memory)」之間可進行「Construct & store」、「Retrieve & Assemble」，Long-term memory 亦有「Forget」與「Maintain」機制。
--- 你的 Agent 使用記憶時，最昂貴的部分往往是你從未觀察的那一段。你調整了檢索，測量了準確率，卻從未計算寫入路徑的成本，也從未注意到你的儲存區什麼都不會忘記。 所有打造 Agent 記憶系統的人，都在最佳化 Agent 記得什麼。幾乎沒有人在設計：建立這些記憶要付出什麼代價、哪些內容值得保留、誰可以刪除它們，以及它們會在哪裡衝擊硬體。這個落差，就是這份工作的核心。 以下就是這份工作拆解後的步驟。六個主題、十五個步驟、四個研究團隊。從頭讀到尾，你就不再只是儲存資料的人。 --- ## 看清記憶的本質 步驟 1：別再把儲存空間叫作「記憶」 你現在就能為 Agent 加上記憶。啟用向量資料庫，把歷史紀錄灌進去，檢索 top-k，完成。這套方法一直有效，直到歷史紀錄超出 context window、寫入路徑的成本高於查詢成本，而且儲存區塞滿了沒有人清理的過時狀態。 真正的記憶不是儲存區，而是一個具備代謝能力的系統。它在資料進入時消耗能源，每個工作階段都會持續成長；如果沒有定期修剪，就會腐敗；最後還可能提供一段六個月前為真的記憶，但今天已經錯了。第一步，是停止把它當成一個桶子，而要開始把它視為一個具有成本與生命週期的系統。 步驟 2：學會用四種視角看待記憶 四個研究團隊，各自回答這個系統中的一個棘手問題。你必須同時掌握這四個問題。 - Stanford：記住一件事要付出什麼代價？ - Microsoft：哪些內容值得保留？ - Anthropic：誰能控制它保留的內容？ - Nvidia：它會在哪裡衝擊硬體？ 它們沒有任何一個是錯的。真正的能力，在於拒絕只選其中一個。 ![依 Paradigm、Agent Memory System、Construction Pipeline、Agent DB、Retrieval Pipeline 與 Mutability 分類並比較多種 Agent 記憶系統與架構機制的表格](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/60409a99d4bec169.png)
展開畫面重點
這是一張以表格形式呈現的 Agent 記憶系統與架構比較圖，橫向欄位包含 Paradigm、Agent Memory System、Construction Pipeline（子欄位包含 Agent Ctrl.、LLM、Embed、Struct.）、Agent DB（子欄位包含 Struct.、Store）、Retrieval Pipeline（子欄位包含 LLM、Flow）以及 Mutability。 表格內容完整轉錄如下： - **I: Long-context memory** - Agent Memory System: `long_context` - Construction Pipeline: Agent Ctrl. ✗, LLM ✗, Embed ✗, Struct. ✗ - Agent DB: Struct. —, Store: `raw context` - Retrieval Pipeline: LLM ✗, Flow: `passthrough` - Mutability: `append` - **II: Flat RAG memory** - Agent Memory System: `BM25` - Construction Pipeline: Agent Ctrl. ✗, LLM ✗, Embed ✗, Struct. ✗ - Agent DB: Struct. —, Store: `inverted index` - Retrieval Pipeline: LLM ✗, Flow: `lexical top-k` - Mutability: `append` - Agent Memory System: `embedRAG` - Construction Pipeline: Agent Ctrl. ✗, LLM ✗, Embed ✓, Struct. ✗ - Agent DB: Struct. —, Store: `dense store` - Retrieval Pipeline: LLM ✗, Flow: `dense top-k` - Mutability: `append` - **III.a: Structure-aug. RAG append-only** - Agent Memory System: `GraphRAG` - Construction Pipeline: Agent Ctrl. ✗, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `graph store` - Retrieval Pipeline: LLM `optional`, Flow: `graph expand` - Mutability: `append` - Agent Memory System: `HippoRAG v2` - Construction Pipeline: Agent Ctrl. ✗, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `multi-view graph` - Retrieval Pipeline: LLM `optional`, Flow: `PPR rerank` - Mutability: `append` - **III.b: Structure-aug. RAG consolidating** - Agent Memory System: Mem0 - Construction Pipeline: Agent Ctrl. ✗, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `dense store` - Retrieval Pipeline: LLM ✗, Flow: `fact top-k` - Mutability: `consolidate` - Agent Memory System: `SimpleMem` - Construction Pipeline: Agent Ctrl. ✗, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `hybrid store` - Retrieval Pipeline: LLM ✓, Flow: `iterative hybrid` - Mutability: `consolidate` - **IV: Agentic control flow** - Agent Memory System: `A-Mem` - Construction Pipeline: Agent Ctrl. ✓, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `graph store` - Retrieval Pipeline: LLM ✗, Flow: `graph-structured map-reduce` - Mutability: `mutate` - Agent Memory System: `Letta` - Construction Pipeline: Agent Ctrl. ✓, LLM ✓, Embed `optional`, Struct. ✓ - Agent DB: Struct. —, Store: `blocks+archive` - Retrieval Pipeline: LLM ✓, Flow: `tool calls` - Mutability: `mutate` - Agent Memory System: `MIRIX` - Construction Pipeline: Agent Ctrl. ✓, LLM ✓, Embed ✓, Struct. ✓ - Agent DB: Struct. —, Store: `multi-store DB` - Retrieval Pipeline: LLM ✓, Flow: `routed typed-memory search` - Mutability: `mutate`
--- # 在建置前先計算成本（Stanford） 步驟 3：把注意力移到寫入路徑 Stanford 進行了第一個真正針對 Agent 記憶的系統研究，而研究結果令人不太舒服：成本並不在你關注的地方。 所有人都在看查詢時間，也就是使用者能感受到的延遲。真正的帳單是在建置階段支付的：寫入路徑把原始歷史紀錄轉換成儲存記錄，而這整段過程使用者完全看不到。 ``` COST OF A MEMORY SYSTEM construction LLM prefill + embedding, paid once, invisible to users query retrieval + generation, paid every time, the part you watch maintenance dedup, compaction, forgetting, usually missing entirely FINDING: for LLM-mediated systems, construction burns more energy than answering 300 queries against the memory afterward ``` 步驟 4：測量每次正確回答的能源消耗，而不是準確率 準確率會掩蓋帳單。以正確回答數量對能源消耗進行標準化後，兩個準確率完全相同的系統，成本相差 47 倍。 相同的工作、相同的 GPU，卻有 47 倍的差距，而任何準確率基準測試都不會讓你看到這件事。從現在開始，每個記憶系統都要有兩個數字：品質，以及每次正確回答的成本。沒有第二個數字，就不要只引用第一個。 步驟 5：選擇你要支付的成本，沒有最好的系統 Stanford 將記憶分成四個家族：原始 context、扁平檢索、結構化擷取，以及完全 Agentic 的系統。沒有任何一種能同時在建置成本、查詢速度與準確率上勝出。 像 Mem0 這類系統可以在不到十分之一秒內回答，但建置時卻要付出數千秒的成本。詞彙索引可以立即完成建置，但查詢時更慢，也更粗略。因此，Memory Engineer 不會挑選最好的系統，而是有意識地選擇要支付哪一種成本。 --- # 決定哪些內容值得保留（Microsoft） 步驟 6：儲存事實與 skill，而不是日誌 Microsoft 的 PlugMem 工作從一個應該讓你感到不安的結果開始：給 Agent 更多原始記憶，可能反而讓它變得更糟。因為歷史紀錄會不斷堆積，檢索結果會被淹沒，而 Agent 得花費注意力在逐字稿中跋涉，只為找出那句真正重要的話。 修正方式是借鑑人類記憶。我們不會重新播放每一個事件，而是保留從事件中提取出的事實與 skill。 ``` DON'T STORE THIS "May 12, user said: yeah I always ship through GitHub Actions, never by hand, learned that the hard way after the prod incident..." STORE THIS fact: user deploys via GitHub Actions, never manually skill: on deploy failure, check the Actions run before touching prod ``` 步驟 7：用效用，而不是大小，評估記憶 將記憶儲存為事實與 skill 後，一個通用記憶模組在三種不同任務中都勝過專門打造的設計，同時消耗更少 token。這帶來一個衡量指標： 最佳化每花一個 context token，能帶給 Agent 多少決策相關資訊，而不是看你成功儲存了多少內容。密度每次都勝過總量。 步驟 8：讓模型管理自己的 context Microsoft 的 Memento 將記憶放進模型內部。它以區塊為單位進行推理，替自己寫下一份高密度筆記，接著刪除原始推理，因此峰值記憶體降至原本的二分之一到三分之一，吞吐量幾乎翻倍。 Memory Engineer 可以從中得到兩個重點。第一，這是一種透過一般微調學會的 skill，而不是外加在模型上的協調層。第二，被抹除的推理並沒有完全消失；模型內部仍會留下某種影子，而只靠筆記重新建立 context，準確率會降低 15 個百分點。忘記不等於刪除，記住也不只是儲存。 --- # 控制它保留哪些內容（Anthropic） 步驟 9：把記憶放進你能刪除的檔案 Anthropic 的做法幾乎有點無聊，而這正是重點。把記憶做成檔案系統中的檔案，讓 Agent 使用原本就會用的工具讀取與寫入。 這之所以重要，是因為檔案能帶來一切可能性：匯出、檢查，以及以程式方式精確控制 Agent 保留哪些內容。無法開啟與編輯的儲存區，就是一個你無法控制的儲存區。 步驟 10：限定範圍、建立稽核紀錄，並支援回復 錯誤記憶不會只造成一次失敗；它會持續存在於之後每個讀取它的工作階段。因此，控制不是加在記憶上方的一層，而是整體設計本身。 ``` /memory /org read-only conventions.md, past-incidents.md /user-4821 read-write preferences.md, skills/ audit.log which agent, which session, what changed, when -> export, roll back, or redact any memory ``` 限定誰能讀取、誰能寫入；保留學到了什麼、以及內容來自哪裡的稽核軌跡；同時保留介入並刪除內容的權限。做得正確時，成果是可以衡量的：採用這種方式建置的團隊，將第一輪錯誤降低了 97%，驗證速度則提升約三分之一，因為整個學習過程始終保持可觀察。 --- # 讓記憶在硬體上存活（Nvidia） 步驟 11：把記憶視為 KV cache，而不是文字 先把演算法抽離，所有記憶決策最後都會落到 GPU 上。把完整歷史紀錄保留在 context 中不只是慢，它的成本還會呈平方成長；而能在單一工作階段內拯救你的 prefix caching，跨越工作階段後就失效了。 所有壓力最後都集中到一項稀缺資源：高頻寬記憶體中的 KV cache。Memory Engineer 會用 HBM 頻寬、GPU 使用率、每秒 token 數，以及釋放的 KV slot 來理解記憶，因為在每個聰明方案的底層，真正的貨幣就是快取。 ``` FULL CONTEXT cost grows with length squared, KV cache fills HBM, evicted between sessions, so you pay again next time MEMENTO ON vLLM finish a reasoning block, flush its KV entries, return the freed slots to the pool RESULT (B200) 4,290 tok/s vs 2,447 vanilla, same batch 693s vs 1,096s ``` 步驟 12：把建置視為背景工作 建置幾乎純粹是 prefill：長時間讀入、短時間寫出，因此它的行為就像背景索引工作。若將它與即時查詢放在一起執行，大型寫入會在使用者查詢抵達的剛好那一刻，讓排程器停頓。 對它進行限流、批次處理或延後執行，並讓它離開對延遲敏感的路徑。你不是在儲存文字，而是在為真正重要的查詢釋放快取。 --- # 建置系統時別反過來傷害自己 步驟 13：先親手驗證每次處理 在進行任何排程前，先手動執行一次。將 Agent 指向真實的歷史紀錄，要求它擷取事實與 skill，標記兩者之間的矛盾，並計算維持這些內容最新所需的成本。 如果輸出確實改變了某項決策，它才值得被排程。一個只針對三份筆記執行的記憶系統，會捏造不存在的關聯，並讓你逐漸習慣忽略它。因此，先親手驗證每次處理，再進行自動化。 步驟 14：在儲存區開始膨脹前加入遺忘政策 Stanford 測試的系統，預設都不會進行修剪或遺忘，因此儲存空間只會持續成長。在一百萬個 token 的規模下，不同系統的使用量最多相差 9 倍；而隨著儲存區本身變大，Agentic 系統的成長還會持續累積。真正會讓長期運作的 Agent 破產的，不是起始大小，而是成長斜率。 在儲存區變大前，加入去重、整併，以及明確的遺忘規則。而且永遠不要自動合併矛盾：兩段互相衝突的記憶，可能在不同情境下都曾經正確。因此，讓系統把它們呈現出來，由你做決定。 步驟 15：按照這個順序發布 - 先建立寫入路徑，儲存事實與 skill，讓它運作幾週，以累積真正的素材 - 親手加入幾次矛盾偵測；只有真的發現意外的矛盾時，才把它排進排程 - 在資料量增加前，加入遺忘與維護政策 - 最後才調整硬體層，等資料量達到實際規模後再進行：對建置進行批次處理、限制檢索量、觀察 KV cache 不要第一天就把所有事情都排進排程。先讓一次手動執行可靠，再將它包裝起來，最後才自動化。 --- # 這一切實際上代表什麼 每個記憶系統都承諾同一件事：它永遠不會忘記、會注意到模式，並變成一個由你餵進去的內容堆成的資料庫。 很好。那只是工作的簡單一半，也就是記住。 Memory Engineer 處理的是另一半。重點不是「這是我保留的所有內容」，而是「這是我選擇不保留的內容、我提煉出的內容、在它腐敗前修剪掉的內容，以及我清空的內容，好讓下一個批次能夠放得下」。Stanford、Microsoft、Anthropic 與 Nvidia，只是用四種詞彙描述同一個行為：決定哪些內容可以放手。 你的 Agent 從來不是因為會忘記才出問題，而是因為它從來不會刻意忘記。儲存者最佳化系統記得什麼；Memory Engineer 最佳化系統忘記什麼，而這就是整個轉變。 你不是靠給 Agent 更大的記憶來成為 Memory Engineer。當你開始設計它該如何遺忘的那一刻，你就成為了 Memory Engineer。 來源：Stanford（Agent Memory: Characterization and System Implications）、Microsoft Research（PlugMem、Memento）、Anthropic（Built-in Memory for Claude Managed Agents），硬體部分則參考 Stanford 與 Memento 論文中的 H100、vLLM 與 B200 設定。 ## 標籤 記憶系統, Agent, 教學資源, LLM, Stanford, Microsoft, Anthropic