AI Agent 記憶怎麼選？Context、Checkpoint、RAG 與 Knowledge Graph
用四層模型拆解 AI Agent 記憶：當下 Context、執行 Checkpoint、語意檢索 RAG 與關係型 Knowledge Graph，並依任務、查詢和維護成本選出最小可行組合。
目錄+
「讓 Agent 記住」不是一個功能，而是四個不同問題：它現在看得到什麼、執行中斷後能否繼續、能否從大量資料找回相關內容，以及能否理解內容之間的關係。把這四件事都叫 memory，團隊很容易一開始就選錯工具。
最常見的誤區是把向量資料庫當成完整記憶層。它很擅長找相似文字，卻不負責保存 workflow 的精確進度，也不會自動知道兩個名字是不是同一家公司。另一個誤區是把整段對話一直塞回 prompt，直到 context window 被歷史訊息占滿，成本上升，關鍵指令反而被淹沒。
比較穩定的做法，是把 Agent Memory 拆成四層：Context、Checkpoint、RAG、Knowledge Graph。每一層都有不同的寫入時機、查詢方式與失敗模式，不需要每個系統一次買齊。
四層記憶模型
第一層：Context，這一刻需要知道什麼
Context 是模型在這一次呼叫中實際收到的資訊，包括 system instruction、使用者問題、工具定義、近期訊息與檢索結果。它不是資料庫，而是模型的工作桌面。
好的 context engineering 不是把所有可能相關的內容塞進去，而是選出完成當前步驟所需的最小資訊。Planner 需要目標、限制與可用工具；Reviewer 需要輸出、驗收標準與證據；兩者不一定要看到完整的聊天紀錄。
Context 的優點是直接、延遲低；缺點是有限、昂貴，而且呼叫結束後不會自動成為可靠的長期記憶。如果你的任務在一次請求內完成，這一層可能已經足夠。
第二層：Checkpoint，這次執行走到哪裡
Checkpoint 保存的是 workflow state：目前步驟、已完成任務、工具結果、重試次數、待處理清單，以及能讓執行恢復的必要狀態。它回答「上次停在哪裡」，不是「世界上有哪些關係」。
長時間運作的 Agent 會遇到 timeout、API 失敗、人工審核或程序重新部署。沒有 checkpoint，只能從頭重跑；有 checkpoint，runtime 可以從明確狀態繼續。Anthropic 在多代理研究系統的工程分享裡，也把 durable execution、錯誤恢復與 regular checkpoints 視為 production reliability 的一部分。
Checkpoint 通常適合 key-value store、事件紀錄或關聯式資料表，不需要先做 embedding。資料應跟 run ID、狀態機版本和過期策略綁定，避免下一次完全不同的任務誤讀上次的暫存結果。
第三層：RAG，哪些內容跟現在的問題相近
RAG 把文件切成 chunks，建立關鍵字或向量索引，再依問題找出可能相關的段落放進 context。它擅長「這份政策文件有沒有提到退款」、「哪些筆記跟 OAuth 錯誤最相近」這類以內容相似度為主的問題。
RAG 的核心價值是壓縮搜尋範圍，不是建立真相。chunk 可能失去前後文；相似的段落可能彼此矛盾；同一人物在不同來源使用不同名字時，也未必會被視為同一實體。因此 RAG 應保留 source URL、document version、chunk offset，讓回答能回到原文。
實務上也不必把 RAG 等同純向量搜尋。全文檢索、metadata filter、reranker 與 hybrid search 都可以加入。像 OpenSpace 的 Graph RAG 實作 所呈現的，graph 與 retrieval 可以混合，但仍要先知道每一層負責什麼。
第四層：Knowledge Graph，事物之間如何相關
Knowledge Graph 把資料表達成實體與具名關係，例如「A 公司 acquired B 公司」、「產品 X depends_on 套件 Y」。它適合跨來源 entity resolution、multi-hop query、關係方向、provenance 與時間有效性。
它的代價也最高。團隊必須定義 entity type、relation schema、去重策略、證據模型與更新機制。如果沒有這些規則，圖譜只是把模型產生的猜測永久化。前一篇 Graph Engineering 的兩張圖模型 已經說明，Knowledge Graph 不等於 Agent 的 orchestration graph。
不是四選一，而是逐層增加
| 需求 | 優先選擇 | 寫入內容 | 典型讀取 | 主要風險 |
|---|---|---|---|---|
| 完成單次推理 | Context | 當前指令、必要資料 | 直接放進 prompt | 過長、關鍵資訊被稀釋 |
| 任務中斷後恢復 | Checkpoint | run state、工具結果 | 依 run ID 載入 | 舊狀態污染、無法遷移 |
| 從大量文件找相關段落 | RAG | chunks、embedding、metadata | similarity／hybrid search | 召回錯誤、段落失去脈絡 |
| 跨文件追蹤實體與關係 | Knowledge Graph | entity、relation、evidence、time | traversal／subgraph | 誤合併、錯誤關係被放大 |
一個客服 Agent 可能只需要 Context＋RAG：當下對話是 context，產品手冊走 retrieval。若工單要等待付款 webhook，才加入 checkpoint。只有當問題需要跨訂單、帳號、裝置與事件追查關係，才考慮 Knowledge Graph。
一個研究 Agent 則可能四層都需要：當前研究目標在 context；多個 subagent 的執行進度在 checkpoint；原始文件先由 RAG 找候選；被反覆查詢的人物、組織、事件與證據再進 graph。層次增加是因為查詢需求增加，不是因為「multi-agent」這個標籤。
三個常見的錯誤組合
把聊天紀錄當資料庫
有些系統把完整歷史訊息每次都傳回模型，稱為「長期記憶」。這只能讓模型看見過去，不能提供一致的資料模型、權限、版本或刪除機制。當上下文開始壓縮，哪些資訊留下又會變成不可見的產品邏輯。
應把原始對話保存於資料層，再根據當前任務摘要或檢索。真正需要長期沿用的偏好，應抽成可編輯的明確欄位；需要審計的事實，則保留來源。
用 checkpoint 回答跨任務問題
Checkpoint 的資料通常跟某個 run 綁定。若直接把它當長期知識庫，系統會混入未驗證的中間產物、失敗工具輸出與已過期計畫。恢復執行所需的狀態，不等於下次回答問題時值得相信的知識。
比較好的邊界是：checkpoint 可以保存「候選事實等待 reviewer」，只有通過驗證後才寫入 RAG 索引或 Knowledge Graph。這讓 runtime state 與 reusable memory 有清楚的晉級門檻。
把 Knowledge Graph 當 RAG 替代品
圖譜不適合保存所有原文細節。若只留下實體和三元組，語氣、條件、否定與上下文都可能消失。回答 Agent 仍然需要回到 evidence 或原始文件。
反過來，RAG 也不擅長穩定回答「A 的投資人創辦了哪些公司」這種多跳關係。成熟系統常採混合路徑：RAG 找文件、graph 找關係、evidence 提供可引用原文，最後才組成 context。LangGraph、Oracle 與 Agent Memory 的案例也顯示，memory 通常是多種持久化與檢索機制的組合。
四層都自架時，embedding 模型與圖查詢會同時吃顯示記憶體；量化後仍要 32GB 級距才跑得順，麗臺 RTX PRO 4000 Blackwell 是這個級別的入門選擇。
用問題型態決定資料結構
選型時，不要先問「大家都用哪個向量資料庫」，而要收集真實問題並分類。
如果使用者常問「跟這段內容最相近的是什麼」，需要 retrieval quality：chunking、embedding、filter、reranking 與 citation。這是 RAG 問題。
如果常問「上次工作完成到哪裡」，需要 state machine、idempotency、retry 與 version migration。這是 checkpoint 問題。
如果常問「某事件如何透過兩層關係影響某公司」，需要 entity identity、typed relation、time range 與 traversal。這是 Knowledge Graph 問題。
如果只是要求模型遵循規則、使用工具並產出格式，先改善 context、tool description 與 eval。Anthropic 的 Building Effective Agents 一再強調：只有在較簡單的方案無法達成可量測結果時，才增加 agentic complexity。記憶架構也應採同一原則。
每一層都要有自己的評估
Context 的評估，可以測 instruction following、關鍵資料是否被選入，以及 token 成本。Checkpoint 測中斷恢復、重試後是否重複副作用、舊版本是否能遷移。RAG 測 recall、precision、citation correctness 與找不到答案時的行為。Knowledge Graph 則測 entity resolution、relation accuracy、provenance completeness、temporal validity 和 multi-hop answer correctness。
不要只測最終回答。當答案錯誤時，團隊要能知道是 context 遺漏、checkpoint 污染、RAG 沒召回、圖譜寫錯，還是回答模型忽略證據。四層分開後，觀測與修復才有落點。
最小可行的採用順序
一個務實的順序是：
- 先固定 prompt、tools 與輸出 schema，建立最小 gold set。
- 任務超過一次呼叫或需要人工審核時，加 checkpoint。
- 文件量超過 context 能可靠承載的範圍時，加 RAG 與 citation。
- 收集到明確的跨來源、多跳與時間查詢後，再建 Knowledge Graph。
- 每增加一層，都用原有 gold set 比較品質、延遲與成本；沒有改善就移除。
這個順序的重點不是保守，而是可診斷。當系統只有必要的層次，每一次錯誤比較容易找到責任邊界。
下一篇會專門處理 Knowledge Graph 最危險的部分：Entity Resolution、Provenance 與時間真相。想直接動手實作，可進入訂閱教學：用 Claude＋Supabase 建立可追溯的多代理共享記憶。
來源與延伸閱讀
- Anthropic：Building Effective Agents
- Anthropic：How we built our multi-agent research system
- Anthropic Knowledge Graph Cookbook
常見問題
Agent Memory 一定要使用向量資料庫嗎？
不一定。短任務可只用 context，長流程可先加 checkpoint；只有需要從大量非結構化內容找相似片段時，向量檢索才特別有價值。若資料已有明確主鍵與固定查詢，一般關聯式資料表可能更簡單。
Checkpoint 和長期記憶有什麼不同？
Checkpoint 保存一次執行能否恢復所需的狀態，長期記憶則跨任務保存可重用資訊。前者偏 runtime recovery，後者偏 retrieval 與 knowledge reuse；未驗證的中間狀態不應自動升級成長期事實。
什麼情況才需要 Knowledge Graph？
當答案需要跨文件對齊同一實體、沿關係做多跳查詢、處理時間真相，或逐條追溯證據時才值得導入。若問題只是找相似段落並引用來源，先用 RAG 通常能以更低成本完成。
利益揭露：本文含聯盟連結，透過連結購買我可能取得少量分潤，不影響你的價格與本文內容。