用向量資料庫還是用檔案系統管記憶？

看場景。記憶量大、需要語意搜尋（像客服知識庫）用向量資料庫。記憶量在幾十個檔案以內、結構清楚，用檔案系統更簡單也更可控。

AI Agent 記憶系統會拖慢回應速度嗎？

會。載入越多記憶，prompt 越長，模型處理越慢。經驗法則是基礎載入控制在 context window 的 15-20%，回應速度不會有明顯感覺。超過 30% 就會開始變慢。

Dify 和 Claude Code 的記憶管理有什麼差異？

Dify 內建向量資料庫和 RAG，上傳文件就能用，適合知識庫場景。Claude Code 用檔案系統，自由度最高但要自己設計架構。Dify 適合快速上手，Claude Code 適合需要完全掌控記憶結構的人。

AI Agent 記憶系統（2026）｜短期、長期記憶實作完整教學

Q: AI Agent 的記憶存在哪裡？

大部分 agent 框架用文字檔（.md 或 .json）存在本機或雲端。每次對話開始時，把相關的記憶檔案內容餵進 prompt。實戰常用的是 .md 檔案系統放在本機。

Q: 怎麼讓 agent 知道該讀哪些記憶？

用一個索引檔（MEMORY.md）列出所有記憶檔的位置和用途。Agent 每次啟動先讀索引，根據當前任務判斷要不要讀某個主題檔。靠的是索引檔的清楚描述，不是花俏的演算法。

Q: 什麼是 RAG？AI Agent 如何用它？

RAG 是 Retrieval-Augmented Generation（檢索增強生成）。把文件切成小段、轉成向量存進資料庫，agent 回答問題時先搜尋相關段落，再根據搜到的內容生成回覆。Dify 內建這個功能，Claude Code 可以搭配外部向量 DB 做到。

Q: AI Agent 如何記住對話？

模型本身不會記。靠的是每次對話開始前，把之前的對話摘要或相關記憶檔案載入 prompt。實戰做法是把重要資訊蒸餾成短文件，存在固定位置，agent 啟動時自動讀取。

AI Agent 記憶管理是決定 agent 好不好用的關鍵。長期跑 agent 的人多半會踩到「記憶」的坑：agent 完全忘記它是誰、在幫誰做事、之前做過什麼。每次新對話開始，它就像剛入職的新人，需要從頭介紹一切。

下面整理的是踩坑三個月後沉澱出來的記憶架構，重點不在技術名詞，而在設計原則。

TL;DR：記憶管理的核心是「讓每份檔案保持短小」和「讓位置本身就是索引」。不要先衝向量搜尋，先把檔案結構理清楚。

為什麼 AI Agent 會失憶

語言模型沒有真正的記憶。

Claude 也好、ChatGPT 也好，每次對話開始時都是一張白紙。會「記得使用者」，是因為有東西在對話開始前把資訊塞進了 prompt。

這個「塞進去的東西」就是 agent 的記憶系統。

問題出在 context window。這是語言模型一次能處理的文字量上限。Claude Opus 原生開放到 1M token，聽起來很多，但 system prompt、工具定義、對話歷史、記憶檔案全加起來，很容易就衝到數萬 K。

超過之後會怎樣？模型開始忽略早期的內容。精心寫的安全規則、行為準則，可能在長對話中被「擠出去」。Agent 的行為就開始飄。

慘痛經驗：把所有東西塞進同一個檔案

最初搭 OpenClaw 時，記憶系統很簡單：一個 MEMORY.md 檔案，什麼都往裡面丟。偏好寫進去、專案狀態寫進去、工具使用規範寫進去、對話紀錄也寫進去。

兩個月後這個檔案長到 800 行。

記憶系統的坑

問題開始浮現。Agent 回應變笨、變蠢了，因為每次都要處理一大坨文字。更嚴重的是，它開始搞混資訊：把 A 專案的規則套用到 B 專案，把上週的待辦清單當成今天的。

用 token 計算工具量了一下：光是載入這份記憶檔，就吃掉 context window 的相當高比例。加上 system prompt 和工具定義，對話還沒開始，已經用掉超過三成。剩下的空間要放對話歷史和實際工作內容。

agent 表現越來越不穩定，根因在這。

三層記憶架構

把記憶系統推翻重建之後，靈感來自人腦的記憶分類：使用者不會把所有記憶同時放在意識裡，大部分存在「需要時才取用」的狀態。

L0：索引層（每次自動載入）

一個檔案：MEMORY.md，大約 60 行。

它不存任何實際內容，只做一件事：告訴 agent「什麼資訊在哪裡」。

## L0 Boot（自動載入）
- SOUL.md：核心價值
- MIND.md：演化中的人格
- AGENTS.md：操作規則

## L1 Session（每次載入）
- brain.md：當下工作記憶，類似速記版
- TOOLS.md：本機工具和環境

## L2 On Demand（按需載入）
- memory/user/profile.md：基本資料
- memory/user/preferences.md：偏好設定
- projects/*/context.md：專案脈絡

Agent 每次啟動先讀這份索引，根據當前任務，判斷需要讀哪些 L1 和 L2 的檔案。

L1：工作記憶（每個 session 載入）

brain.md 是每天更新的檔案。裡面放的是「現在在做什麼」「哪些事情卡住了」「等誰確認」。

這個檔案大約 80-120 行，每天清理一次。昨天完成的任務移到 journal，只留進行中的。

TOOLS.md 列出 agent 能用的所有工具和 API。Agent 讀完就知道自己「能做什麼」，不會去嘗試不存在的工具。

L2：主題記憶（按需載入）

這是拆分後最大的改善。

以前所有東西擠在一個檔案裡，現在按主題拆開：

memory/user/profile.md：基本資料，30 行
memory/user/preferences.md：溝通和工作偏好，40 行
memory/topics/：穩定的主題知識，每個檔案不超過 100 行
projects/*/context.md：每個專案的脈絡和注意事項

聊到保險的時候，agent 才去讀保險相關的 context；聊到健身的時候，才讀健身的。不相關的檔案完全不載入。

效果

重建之後，context window 的基礎佔用從超過三成降到一成五左右。Agent 的回應品質明顯提升，混淆的情況幾乎消失。

維護也變容易。哪個主題的資訊過時了，直接去那個檔案改，不用在大檔案裡找。

五個設計原則

踩坑之後沉澱出五個原則，每次調整記憶系統都會對照。

原則一：位置就是索引

不要搞複雜的搜尋機制。把檔案放在正確的位置，位置本身就告訴 agent 該什麼時候讀它。

projects/health/context.md 放在 health 專案資料夾裡。Agent 在處理 health 相關任務時自然會去那個資料夾找東西。不需要向量資料庫，不需要 embedding search。

原則二：每份檔案不超過 200 行

超過 200 行就該拆。

200 行大約是 3000-4000 token，對 agent 來說是「讀完之後還能好好處理」的範圍。超過這個量，建議將內容外部化，另存新的檔案。

原則三：一條資訊只存一個地方

SSoT（Single Source of Truth）。同一條資訊存在兩個地方，遲早會不一致，然後 agent 就會搞混。

判斷方法：如果某個專案消失了，這條資訊在其他場景還會用到嗎？不會 → 放專案裡。會 → 放個人檔案。

原則四：區分「穩定」和「流動」

有些資訊很少變（生日、偏好的溝通方式）。有些資訊每天在變（今天的待辦、這週的 sprint 進度）。

穩定的資訊放在 L2 的 profile 和 topics 裡，很少動。流動的資訊放在一個特殊的檔案裡，每天更新。把這兩種東西混在一起，是記憶系統變混亂的主因。

原則五：定期蒸餾（壓縮）

記憶會累積。三個月前的 sprint 紀錄、半年前的對話心得，不清理，檔案就會越來越肥。

每週做一次記憶 review。重要的洞察蒸餾到 MIND.md（agent 的核心認知），過時的紀錄歸檔到 archive/。篩選標準很嚴格：只有影響 agent 行為的「身份級」洞察才會留在核心檔案裡。

記憶架構設計

可以直接套用的檔案結構

要為自己的 AI agent 建記憶系統，建議的起點：

memory/
├── MEMORY.md          # 索引（60 行以內）
├── brain.md           # 今天在做什麼（每天更新）
├── user/
│   ├── profile.md     # 個人基本資料
│   └── preferences.md # 個人偏好
├── topics/
│   ├── topic-a.md     # 穩定的主題知識
│   └── topic-b.md
└── archive/           # 過期的東西

每個檔案開頭寫一行註解，說明這個檔案是什麼、什麼時候該讀它。Agent 看到這行就知道要不要繼續讀下去。

讓 AI 幫你設計記憶系統：三組可複製的 Prompt

設計記憶系統最難的一步通常是開始動手。技術其實都有公開資料可以查，卡住的是「該怎麼把自己的東西分類」。下面三組 prompt 可以直接丟給 Claude 或 ChatGPT，讓它幫忙起一個初版架構，再照著實際使用情境調整。

Prompt 1：讓 AI 分析現有的檔案結構

場景： 手上已經一堆零散的 .md 檔、Google Doc、或 Notion 頁面，想整理成 agent 可以用的記憶系統。 適用工具： Claude（推薦，長 context 處理力最好）、ChatGPT 使用方式： 把現有的目錄結構或檔案清單貼進去，讓 AI 幫忙分類。

想把下面這些檔案整理成 AI agent 的記憶系統，請你幫忙做三件事：

1. 把檔案分成三類：
   - L1（每次對話自動載入，例如個人偏好、當前工作）
   - L2（按主題載入，例如特定專案、特定知識領域）
   - L3（歷史存檔，平常不載入）

2. 找出明顯的問題：
   - 有沒有重複的資訊放在不同檔案
   - 有沒有檔案太長需要拆分（超過 200 行）
   - 有沒有檔案內容太雜應該分成多個檔案

3. 給出一個推薦的新檔案結構，包含：
   - 每個檔案建議的路徑和名稱
   - 每個檔案應該放什麼內容
   - 哪些舊檔案要合併或拆分

檔案清單：
[貼上檔案清單，可以用 ls -la 或 tree 指令的輸出]

使用情境：
[描述主要會用這個 agent 做什麼，例如：日常工作助理、寫作夥伴、程式碼 reviewer]

第一次跑這個 prompt 會拿到一個初版建議。不要全盤照收，挑認同的部分先改，跑一週看看實際用起來順不順，再來第二輪調整。

Prompt 2：讓 AI 幫你規劃記憶分層

場景： 還沒有現成檔案，想從零開始設計記憶分層。 適用工具： Claude、ChatGPT、Gemini

要為 AI agent 設計一套記憶系統，請你根據以下情境，給出一個三層的記憶架構。

情境：
  身份：[例如：自由工作者、學生、產品經理]
  主要任務：[例如：寫作、專案管理、研究資料整理]
  每天會跟 agent 討論的事：[列三到五項]
  偏好的互動方式：[例如：中文、直接、不要繞圈]
  Context window 限制：[例如:Claude Opus/ChatGPT 1M]

請設計：

L0（索引層，每次都讀）
  一份 MEMORY.md 的內容，列出所有檔案的路徑和用途。

L1（工作記憶，每個 session 載入）
  推薦 2 到 3 個檔案，各自負責什麼、預估幾行。

L2（主題記憶，按需載入）
  推薦 4 到 8 個主題檔案，各自放什麼內容、什麼時候會被觸發載入。

請給出每個檔案的：
  1. 檔案路徑和名稱
  2. 預估行數
  3. 應該包含的內容（條列）
  4. 更新頻率（每次、每天、每週、每月）

最後算一下：總共佔 context window 大概多少 token，確認有沒有超過 20%。

算 token 這一步很重要。第一次設計時沒算，做完發現 L0+L1 就吃掉 25% 的 context，後來只好砍掉兩個檔案。請 AI 幫忙算一遍可以省掉這個坑。

Prompt 3：讓 AI 幫你寫 brain.md 範本

場景： 決定開始用 brain.md 記工作記憶，但不知道該放什麼、怎麼排。 適用工具： Claude、ChatGPT

請設計一份 brain.md 範本，這份 AI agent 每次對話會自動讀的「當下工作記憶」檔案。

工作模式：
  同時進行的專案數：[例如：3 個]
  每天會換專案切換幾次：[例如：4 到 6 次]
  常卡住的原因：[例如：等別人回覆、資訊不足、技術難題]
  希望 agent 看完這份 brain.md 之後能做什麼：[例如：掌握今天在忙什麼、提醒等哪些回覆、知道有沒有卡住]

請寫一份範本，包含：

1. 檔頭註解：一句話說明這份檔案是什麼、更新規則
2. 「今天的焦點」區塊：今天最重要的一到兩件事
3. 「進行中」區塊：每個專案用什麼結構記進度
4. 「等回覆」區塊：誰、等什麼、等多久
5. 「卡住的地方」區塊：問題、目前嘗試過的、打算下一步怎麼辦
6. 「今天的小事」區塊：15 分鐘內可以收掉的瑣事
7. 底部：更新時間戳記

請控制在 80 行以內，每個區塊用實際範例填好（標記為範例，之後會改掉）。
風格：口語、簡短，不要正式報告的語氣。

範本拿到之後，第一週會覺得很多欄位用不到，第二週開始會發現有些東西想記但沒有欄位。這是正常的，範本本來就該跟著使用節奏演化。

RAG 和向量資料庫：另一種記憶管理方式

檔案系統不是唯一做法。記憶量很大（幾百份文件、幾千頁的知識庫）時，用 RAG（Retrieval-Augmented Generation）搭配向量資料庫會更合適。

RAG 的運作方式：把文件切成小段、用 embedding 模型轉成向量、存進向量資料庫（像 Pinecone、Weaviate、Chroma）。Agent 需要回答問題時，先用語意搜尋找出相關的段落，再把這些段落餵進 prompt 讓模型生成回覆。

Dify 的 RAG 功能是開箱即用的：上傳 PDF 或 Word，它自動做切段、embedding、建索引。對客服機器人或知識庫問答這類場景很方便。

實戰上選檔案系統的常見場景：記憶量只有幾十個 .md 檔，用向量搜尋反而多此一舉。RAG 的優勢在有上百份文件要管時體現出來，比手動維護檔案結構有效率。

不同工具的記憶管理比較

工具	記憶方式	自由度	適合場景
Claude Code	檔案系統（.md/.json）	最高，完全自訂	個人工作流、需要精細控制
Dify	內建向量 DB + RAG	中，平台提供框架	知識庫問答、客服機器人
Coze	平台內建	低，無法自訂底層	輕量使用、不需複雜記憶
自建	完全自訂	最高	有特殊記憶需求的商業產品

選記憶方案的關鍵問題是：記憶量有多大、需不需要語意搜尋、願不願意花時間維護架構。量小、結構清楚就用檔案系統；量大、需要搜尋就用向量資料庫。

踩坑補充

工作速記版 brain.md 膨脹

brain.md 應該是工作記憶，輕薄短小。曾有一段時間忘了清理，它長到 300-500 行。裡面有兩週前的待辦、一個月前的進度更新、早就結案的 bug 紀錄。

Agent 載入這份 brain.md 之後，把一個月前的 bug 當成今天的任務去修，修了半小時才被發現。

可靠的規則：brain.md 每天清理，超過三天的項目如果還在，要嘛更新狀態，要嘛移到 journal。這邊如果你有搭配 OpenClaw（龍蝦），可以使用 cron job 進行 daily optimization 來輔助。

記憶衝突

曾經在 profile.md 裡寫「偏好用繁體中文」，但在某個專案的 context.md 裡寫「這個專案用英文」。Agent 碰到需要用中文還英文的判斷時，兩份檔案都讀到了，結果寫出一段中英夾雜的東西。

解法是在 context.md 裡明確寫「本專案語言：英文（覆蓋全域偏好）」，讓 agent 知道有衝突時該聽誰的。

FAQ

AI Agent 的記憶存在哪裡？

大部分 agent 框架用文字檔存在本機或雲端。每次對話開始時，把相關的記憶檔案內容餵進 prompt。實戰常用的是 .md 檔案系統放在本機。

記憶檔案多大會出問題？

取決於模型的 context window 大小。以 Claude Opus 為例，原生 context window 是 1M token。經驗法則是超過 1000 行就該拆，總載入量控制在 context window 的 20% 以內。

怎麼讓 agent 知道該讀哪些記憶？

用一個索引檔列出所有記憶檔的位置和用途。Agent 每次啟動先讀索引，根據當前任務判斷要不要讀某個主題檔。靠的是索引檔的清楚描述，不是花俏的演算法。

什麼是 RAG？AI Agent 如何用它？

RAG 是檢索增強生成。把文件切段、轉向量、存進資料庫，agent 回答問題時先搜相關段落，再根據搜到的內容生成回覆。Dify 內建這功能，Claude Code 可以搭配外部向量 DB。

AI Agent 如何記住對話？

模型本身不會記。靠的是每次對話開始前，把之前的摘要或記憶檔案載入 prompt。實戰做法是蒸餾重要資訊成短文件，存在固定位置，agent 啟動時自動讀取。

記憶系統會拖慢回應速度嗎？

會。載入越多記憶，prompt 越長，處理越慢。基礎載入控制在 context window 的 15-20%，回應速度不會有明顯感覺。超過 30% 就會變慢。

用向量資料庫還是檔案系統管記憶？

看場景。記憶量大、需要語意搜尋就用向量資料庫。記憶量在幾十個檔案以內、結構清楚，檔案系統更簡單可控。

小企鵝的經驗

主力 stack 是 OpenClaw 上的 Opus / Sonnet / Codex 三 agent，記憶全部走檔案系統（.md），不接向量資料庫。實戰下來最痛的就是記憶這塊：要處理好記憶又不讓 agent 失憶非常困難，訣竅就是上面寫的那五條原則，越乾淨越能記得住。記憶量不大、需要隨時手動編輯，是選檔案系統而不是 RAG 的兩個主因。

整理：Penna｜小企鵝 Penchan