Agent-Memory

Properties2
tags狀態/草稿
aliasesAgent Memory, Agent 記憶, LLM Agent 記憶, External Memory

閱讀時間約 10 分鐘

Agent-Memory

一句話定義

AI Agent 的「外部記憶」——把 context 的一部分從 prompt 移到硬碟、由 LLM 在需要時用工具存取——是 Context-Engineering 的演算法形式 C = (P, M) 中 M 的具體實作；既能突破 LLM context window 上限，也是 Lifelong-AI-Agent 跨 session 持續累積的物理基底。

核心要點

C = (P, M)：把 Context 拆兩部分

李宏毅 在 2026-05-02-AI-Agent-Context-Engineering系統化 將 Context-Engineering 演算法形式化：

  • P（Prompt）= 真的會被丟進 LLM 的部分（LLM 看得到）
  • M（Memory）= 存在硬碟、不會直接進 prompt 的部分（LLM 看不到，但能用工具存取）
  • 詞彙澄清：vault 上下文中 Prompt ≠ Context；prompt 是 context 的真子集（= P 部分）。
        ┌──────── Context ────────┐
        │                          │
        │   ┌────┐      ┌────┐    │
        │   │ P  │      │ M  │    │
        │   │ ▲  │      │ ▲  │    │
        │   │ │  │      │ │  │    │
        │   └─┼──┘      └─┼──┘    │
        │     │           │       │
        └─────┼───────────┼───────┘
              │           │
       LLM ──→             ←── hard disk

兩個基本動作

動作更新對象何時發生
save_memory(content)M（硬碟）LLM 主動決定把當前 context 中某段挪到記憶
load_memory(query)P（prompt）LLM 需要回想時把記憶撈回 prompt
  • 這兩個動作對應虛擬碼中對 C = (P, M) 的不同更新分支。

Filtering：讀記憶不等於 dump 整個檔案

為什麼讀 memory 不直接用一般 read 工具——OpenCode 的具體設計：

  • memory_search(query)：先用搜尋找出相關 memory 段落（類似 RAG retrieval）。
  • memory_get(file, start_line, num_lines)：再帶起始行 + 行數精確讀取——避免一次把整個 memory file 讀進 prompt 把 context 灌爆。
  • 這兩個工具一起 = Memory 的過濾介面——讀檔本身就有過濾語意，這是 Context-Engineering 「治本（過濾）」精神在 Memory 子議題的具體落地。

Storage 結構研究方向

李宏毅 列舉的記憶相關文獻汗牛充棟；常見研究軸：

  • Graph 結構：把記憶建成 graph，搜尋時可看到不同記憶之間的關聯。
  • 時間戳：給記憶加時間，存取時優先較新或較舊的記憶。
  • Importance 分層：高頻 / 重要 vs 低頻 / 次要記憶不同處置。
  • Save / Load 時機：何時主動 save、何時自主 load 都是研究議題。

一個從 log 檔案到全功能 Memory 的演化路徑

李宏毅 講解 Context-Engineering 「壓縮 F 變體」時提到的 log 外掛法 → 自然演化到 Memory：

  1. 基本壓縮：工具輸出 → 換成「這裡曾經有個工具的輸出」（observation masking）。
  2. Log 檔案外掛：工具輸出 → 寫進 log1.txt，context 只留「詳見 log1.txt」。
  3. Memory 系統：所有要長期保存的內容 → 統一收進 memory 結構（graph / 時間戳 / 搜尋介面），由 LLM 主動 save / load。

內存 vs 外存的直白定義（2026-05-02-Agent神文沒告訴你的事 整理）

「這不是兩種神秘的能力，本質上就是說我需要做一個決定，這個東西存在哪兒、存多久。」

詞定義何時用
內存這輪對話結束就消失信息只對這一輪有用——寫到外面繼續帶會變噪音 / 污染下一輪
外存多輪對話都拿得到的東西必須跨輪保存的信息

典型外存案例：Claude-Code / Cursor 裡的 To-do list——任務步驟多 / 中間需用戶確認 / 引入外部狀態系統告訴 AI「走到第幾步、用戶給了什麼輸入、現在不該執行什麼」。

紀律：「不要一上來看到記憶體 / 內存 / 外存我都要用——順序永遠都是你走到這個階段、發現不用不行了你才用」。對位 Agent複雜度演化 階段 5：memory 不是 day 1 該上的優化項。

指針傳遞取代複製貼上（memory 從優化項變必需品的時刻）

2026-05-02-Agent神文沒告訴你的事 階段 5 的撞牆問題具體化：

典型場景：用戶給段代碼希望改 → 規劃者看到代碼但不寫代碼，需把任務交給寫代碼的執行者 → 怎麼把代碼百分之百原封不動傳過去？

「規劃者把輸入再 output 一遍」的兩個糟糕後果：

  1. 為複製貼上付費：純 copy paste 卻消耗大量 output token——而 output token 比 input token 貴
  2. 無法保證一字不差：模型不擅長機械複製——哪怕你明說「一行都不要改」，它很可能順手改一個明顯的 bug（例如把錯誤標點改正確）；問題是用戶本來就是要修 bug，bug 在還沒傳到執行者之前就被解決了——這在很多場景下是災難性的

Memory 的真正動機：「有些信息我只想存著，而不是讓模型反覆讀寫」。

Memory 機制 = 傳遞指針而非內容（Sub-Agent / 規劃者 / 執行者場景的具體做法）：

規劃者收到代碼 ──→ 寫進文件系統 ──→ 得到文件名
                                       │
                                       ▼
                          告訴執行者「需要改的代碼存在這個文件名」
                                       │
                                       ▼
            執行者用文件名讀內容 ──→ 改代碼（不依賴規劃者輸出）

效果：

  • 規劃者不輸出完整代碼 → output token 成本下降
  • 執行者不依賴規劃者輸出 → 錯誤率明顯降低（避開機械複製不可靠問題）

何時是必需品：「當你開始做上下文隔離的時候，當你需要開始傳遞不能改動的長內容的時候，記憶系統就不再是優化項，而是一個必需品」。對位 Agent複雜度演化 階段 5。

Rick and Morty 類比（李宏毅 用）

  • 《Rick and Morty》第三季：Morty 發現他爺爺 Rick 把他大半輩子的記憶藏在地下室管子裡——Morty 爆氣打架，最終兩人記憶都消失。
  • 對 LLM 的啟示：把 context 中內容放到硬碟、需要時讀回——這就是 LLM 的「記憶」。LLM 對「記憶被移走」的反應與 Morty 類似：抗拒（見 Sub-Agent / AgentFold 中「LLM 不喜歡壓縮自己的記憶」的多次反覆驗證）。

與其他概念的關係

  • 父概念：Context-Engineering——本頁是 C = (P, M) 演算法形式中 M 的具體實作軸。
  • 對 prompt 的鏡像：Prompt-Engineering 處理「進到 P 的內容怎麼寫」；本頁處理「M 怎麼存 / 怎麼讀回 P」。
  • 時間軸延伸：Lifelong-AI-Agent——agent memory 是 lifelong agent 的物理基底；跨 session 持續累積能力 = memory 持續成長。OpenCode memory.md / CLAUDE.md 等檔案都是 memory 在 CLI agent 的具體 host。
  • 對位 Sub-Agent：兩者都是 LLM 對 context 的主動處置——sub-agent 是「自主壓縮對話歷程」、memory 是「自主搬移內容到外部儲存」。
  • 對位 第二大腦 / LLM-Wiki：人類 PKM 把資訊放外部儲存 + LLM 自己對自己做 PKM。
  • 代表 host：Claude-Code（memory_search / memory_get 工具設計）；OpenCode 等其他 harness 也有類似設計。

相關來源

備註

建頁理由：vault 既有 Context-Engineering / Lifelong-AI-Agent / Claude-Code 都涉及 memory 議題但散落，且 Context-Engineering 在本期被推進到「演算法層」後，C = (P, M) 中的 M 軸足以獨立成頁。本頁讓未來 graph memory / vector memory / temporal memory / agent identity 等議題 ingest 時有共同錨點。

未來累積方向：(a) graph / vector / temporal memory 各種具體 storage 結構；(b) 跨 session memory 的 agent identity 議題；(c) memory pruning（不只增加、也要刪除）；(d) memory 安全 / 隱私（lifelong agent 累積的個人資料）；(e) 多 agent 共享 memory 的協議。

反向連結