AI 長期記憶怎麼建立？用 Memory Router 管理上下文與知識庫

AI 不會因為資料夾裡多了一份文件，就知道什麼時候該讀它。真正的長期記憶需要一個調用機制：先判斷問題屬於哪個範圍，再取回相關且目前有效的資料，放進這一次回答的上下文。

跟 AI 討論完一個主題後，請它整理成 Markdown，再放進 Obsidian 或資料夾，確實比只留在舊對話裡可靠。但文件一多，新的問題馬上出現：AI 怎麼知道哪一份和目前問題有關？同一主題有三個版本時該相信哪一份？難道每次都要讀完整個知識庫？

我認為這才是 AI 長期記憶真正要解決的問題。保存處理的是資料能不能留下來；記憶處理的是資料能不能在對的時候被正確取回。

這套方法不只適用 Claude，也能搭配 ChatGPT Projects、Gemini Notebook、Obsidian、Notion 或自建 RAG。不過要先修正一個常見說法：不是每個 AI 模型本身都有長期記憶。很多時候，是外部產品或知識系統先找到資料，再把它加入模型這次能看到的 context。

配套練習：下載 AI Memory Router Starter。內容只有 Router、示範筆記與檢索測試，不會自動連接 AI、讀取其他資料或包含私人內容。

文章目錄

模型只會直接使用當下上下文

生成式 AI 產生回答時，直接參考的是這一次請求中的 context。它可能包含目前對話、系統指示、上傳文件、搜尋結果或其他工具取回的內容。Anthropic 把 context window 說明為模型的工作記憶，也提醒更多內容不一定帶來更好結果；內容增長後，找回正確細節與維持準確度可能變得更困難。

這表示 Obsidian 裡的一篇筆記、ChatGPT Project 裡的一份 PDF，或 Claude Project knowledge 裡的一份文件，都不會隔空直接影響答案。系統必須先選中它，再把全文或相關片段送進這次 context。

因此，AI 長期記憶至少包含兩個不同世界：

• context 內：模型這一次真的能使用的內容。
• context 外：可能被搜尋、選取或載入的長期資料。

把資料存到 context 外，只完成了第一步。

訓練、產品記憶與外部知識不是同一件事

「AI 記住了」常把三種機制混在一起。第一種是模型訓練：模型在大量資料中學到一般語言與模式。第二種是產品記憶：應用程式保存偏好、聊天脈絡或 Project 狀態，之後可能再次提供給模型。第三種是外部知識檢索：系統從文件、資料庫或筆記裡搜尋相關內容，再放進這次 context。

機制	改變了什麼	使用者能否直接管理
模型訓練／fine-tuning	模型參數或行為模式	一般聊天使用者通常不能靠一句「記住」直接改變
產品 Memory／Project memory	產品未來可能提供給模型的個人或專案脈絡	依產品功能查看、關閉、刪除或調整
外部知識庫／RAG	問題出現時可搜尋的文件集合	可以管理來源、scope、權限與版本，但仍要驗證檢索
目前 context	這一次回答實際能參考的內容	可透過提示、附件、Project 或工具間接控制

因此，這次和 AI 討論完一篇文章，通常不會讓基礎模型重新訓練。你真正能做的是把有價值的內容保存到產品記憶或外部知識庫，並設計未來的取回方式。

長期記憶比保存多了四個條件

一份可用的 AI 長期記憶，可以拆成五個部分：

1. 持久化：內容離開單次對話後仍存在。
2. 可定位：系統能透過主題、關鍵詞、metadata 或連結找到它。
3. 調用條件：知道什麼問題需要它，什麼問題不應使用它。
4. 按需取回：只把相關內容放進當下 context，不載入整個倉庫。
5. 版本維護：錯誤或過期時能更新、取代或封存。

只有第一項的資料夾是保存系統，不是完整記憶系統。只有搜尋、沒有版本規則的向量資料庫，也可能找出語意很像但已經失效的文件。

文件越多，為什麼反而更容易答錯

長期記憶不是只看「找不找得到」。一次回答可能在四個位置出錯：

失敗位置	表面症狀	真正問題
Scope	搜尋了整個 Vault	沒有先限制專案、主題或資料權限
Recall	漏掉真正相關文件	檔名、關鍵詞、連結或語意索引不足
Ranking	找到五份相似內容，卻選到舊版	缺少 current、superseded 與 canonical 規則
Context composition	相關資料都有載入，回答仍互相矛盾	送進 context 的內容太多、來源角色不清或指示衝突

這也是為什麼「把全部文件做 embedding」不是終點。語意接近只代表文字可能相關，不代表它適用於目前任務、擁有正確權限，或仍是有效版本。Router 的價值，是在語意搜尋前後加入人能理解的範圍與版本判斷。

用 hot、warm、cold 三層限制混亂與成本

避免所有文件一起進入 context，最簡單的做法是把記憶分成三層。

層次	內容	使用方式
Hot：當下上下文	目前問題、必要指示，以及少量相關資料	直接影響這次回答；越精簡越容易核對
Warm：Memory Router	主題、scope、調用條件、排除條件、狀態與正式來源位置	先判斷應該去哪裡找，不保存完整文章
Cold：長期知識庫	完整筆記、來源、文章、交接、證據與歷史版本	只有 Router 判斷相關時才取回指定內容

Router 必須小。它的工作像圖書館目錄，不是把每一本書再抄一次。如果 Router 也膨脹成幾百頁摘要，問題只是從 cold storage 搬到 warm layer。

一份記憶怎麼進入這次回答

無論使用 Claude Project、ChatGPT Project、Gemini Notebook 或自建 RAG，檢索大致可以用同一條鏈理解：

使用者問題
→ 限制可搜尋的 scope
→ 用關鍵詞、語意或連結找候選資料
→ 依適用性、狀態與日期排序
→ 取回少量片段或指定文件
→ 和目前問題一起組成 context
→ 模型產生回答
→ 人回到來源核對

關鍵字搜尋適合專有名詞、檔名與明確代號；語意搜尋能找到不同措辭但概念相近的內容；連結與 metadata 則能表達「這份文件取代哪一份」「只適用哪個專案」。一套系統可以混合使用這些方法，而不是只押一種搜尋方式；實際採用哪些方法，仍要看產品能力。

對新手而言，不必先建立向量資料庫。先用 scope、清楚檔名、`use_when`、`do_not_use_when`、狀態和唯一來源，就能處理大量最常見的錯誤。等到人工搜尋確實成為瓶頸，再增加語意檢索。

Obsidian 不是唯一解法，但單獨使用仍不夠

Obsidian 適合保存可攜的 Markdown、連結與 metadata，也讓人可以看見知識之間的關係。它很適合當 cold knowledge base，但 Obsidian 不會自動讓任何 AI 知道何時應該讀哪篇。你仍需要手動選取筆記、讓 AI 能搜尋 Vault，或加上一層 Connector、MCP、外掛或本機 Agent。

解法	適合情境	主要限制
Claude／ChatGPT Projects	想用最低設定成本，把同一工作的 chats、files 與 instructions 放在一個 scope	產品負責部分檢索，調用理由與錯誤召回不一定透明
Gemini Notebook	學習或研究有一組明確來源，希望回答限制在選定 notebook	每個 notebook 獨立；使用者仍要先選對 notebook 或來源
Obsidian／Notion	需要自己管理內容、連結、欄位、權限與長期可攜性	需要額外的 AI 搜尋或連接層，才會自動取回
自建 RAG	需要 metadata filter、權限、排序、版本與可觀測檢索	技術與維護成本最高，不適合當新手第一步

Claude Projects 在資料量增長時可以用 RAG 搜尋相關 project knowledge；ChatGPT Projects 可以把 chats、files、instructions 與 project memory 放在同一工作範圍；Gemini Notebook 則把每個 notebook 限制為獨立來源集合。三者都在縮小搜尋範圍，但沒有一個能取代內容版本與正式來源管理。

建立一份小型 Memory Router

Memory Router 不需要是一套程式。新手可以先用一份 YAML 或 Markdown 索引，替每個主題記錄「什麼時候使用」與「什麼時候不要使用」。

id: ai-memory-context
topic: AI 長期記憶與上下文
scope: AI 新手教學／Unit 6
use_when:
  - 新對話需要接續之前的學習
  - 問題涉及 AI memory、RAG、知識庫或上下文
do_not_use_when:
  - 只需要摘要目前這段對話
  - 問題是備份或換電腦
canonical_source: notes/ai-memory-context.md
status: current
updated_at: 2026-09-10

其中最重要的不是 tags，而是三個欄位：

• use_when：把主題轉成可判斷的使用場景。
• do_not_use_when：阻止語意相似但任務不同的錯誤召回。
• canonical_source：只指向一份目前有效的完整來源，其他副本只能是索引或快照。

接著把一條簡短的檢索規則放進 AI 每次能取得的 Project instructions、工作規則或 Agent 設定：

回答長期工作問題前，先比對 Memory Router 的 scope、use_when 與 do_not_use_when。
最多取回三筆相關紀錄，只讀 canonical_source。
如果沒有符合項目，直接說找不到，不要載入整個知識庫或猜測。
若來源狀態不是 current，停止把它當現行答案。

在純聊天產品裡，這條規則能提高一致性，但不代表底層檢索一定照做；實際能力仍取決於產品是否能搜尋外部資料。若 AI 無法連接 Obsidian，就由使用者先在 Router 找到來源，再把指定筆記附到對話。

從零建立最小可用的記憶系統

上一篇 AI 上下文、記憶與版本管理 教你留下可交接的目標、決定與下一步；這裡把交接文件放進更完整的系統，替它加上調用與淘汰規則。

先建立四份可讀文件，不需要資料庫：

ai-memory-starter/
  README.md
  memory-router.yaml
  notes/
    ai-memory-context.md
  tests/
    retrieval-tests.md

memory-router.yaml 只負責指路；notes/ 保存目前有效的完整知識；tests/ 保存應該命中、不應命中與版本衝突的問題。README 則說明哪一份是正式來源，以及如何把這組資料交給不同 AI 產品。

第一步：只保存值得重複使用的內容

不要讓 AI 每次對話結束都自動新增一篇摘要。先用三個問題篩選：

• 未來是否可能再次遇到同一類問題？
• 重新推導的成本或答錯的影響是否值得保存？
• 內容能否標出來源、適用範圍與目前狀態？

如果三題都是否，保留聊天歷史即可，不必升級成長期記憶。記憶系統的價值不是保存率，而是未來正確取回的價值。

第二步：建立一份 canonical note

# AI 長期記憶與上下文

status: current
updated_at: 2026-09-10
scope: AI 新手教學／Unit 6
supersedes: none

## 目前理解
AI 長期記憶需要保存、調用、取回、上下文注入與版本維護。

## 成立條件
AI 產品或工作流必須能讀取指定的外部資料。

## 來源
[列出官方文件或實作紀錄]

## 仍未知
[列出產品差異與尚未驗證項目]

Router 只指向這一份 current note。若未來改版，舊 note 可以移入 archive 並標示 superseded，但不能同時讓兩份都保持 current。

第三步：選擇實際調用方式

• 純聊天：由人先查 Router，再附上指定 note。
• AI Project／Notebook：把 Router、current notes 與檢索規則放進同一個受限 scope。
• Obsidian／Notion 連接：讓 AI 搜尋允許的頁面或 Vault，再要求回報實際取回來源。
• 自建 RAG：用 metadata filter 先限制 scope 與 status，再進行關鍵字／語意搜尋與排序。

四種方式共用同一份 canonical note 與 Router，不需要為每個 AI 平台複製一套完整知識。

用新對話測試 AI 是否正確調用

建立文件與 Router 後，開一個新的對話，用三種問題測試。

1. 應該命中：「之前學過的 AI 長期記憶，為什麼需要 Router？」系統應取回這筆目前有效的來源。
2. 不應命中：「怎麼備份電腦裡的 AI 對話？」雖然都有記憶與對話字眼，但 Router 的排除條件應阻止誤用。
3. 版本衝突：把一份舊說法標成 superseded，再問現行方法。系統應使用 current 來源，或明確指出衝突，而不是混合兩份答案。

每次記錄四件事：查了哪些索引、取回哪份來源、送進 context 的範圍，以及回答是否使用正確版本。如果產品不顯示檢索過程，就要求回答引用檔名與更新日期，再回到來源核對。

真正的完成標準不是 AI 說「我記得」，而是它在相關問題中取回正確內容，在無關問題中沒有亂用，遇到舊版本時也沒有混淆。

不要只看答案，要診斷是哪一層失敗

測試結果	可能原因	先修哪裡
相關問題沒有命中	scope 太窄、Router 缺少使用場景、搜尋詞不一致	補 use_when、同義詞或正確 Project；不要立刻複製更多文件
無關問題也命中	條件太寬，只靠相似關鍵詞	補 do_not_use_when 與更小的 scope
命中舊版本	多份文件都標 current，或索引仍指向舊路徑	修 canonical 與 superseded 關係
來源正確但答案錯	片段缺少成立條件、context 內有衝突指示，或模型解讀錯誤	檢查實際取回片段與回答，不要把問題全部怪給搜尋

這四種結果應分開記錄。只用「回答看起來不錯」評估，無法知道系統是真的取回正確記憶，還是模型剛好用一般知識猜對。

哪些內容不應成為長期記憶

長期可取回同時代表長期暴露。登入憑證、API 金鑰、未獲授權的公司資料、客戶個資、私人健康資訊，以及只屬於一次敏感對話的內容，不應因為整理方便就進入跨對話 Memory 或共用知識庫。

每筆記憶至少要回答：誰可以讀、可在哪個 Project 使用、是否能交給雲端模型、何時刪除。若無法確認，就留在受控的正式來源，由人決定是否在單次任務中提供。Router 可以保存「此主題有受限資料」與取得規則，但不要把敏感內容本身複製進索引。

記憶必須能更新、取代與封存

知識庫最容易出問題的時刻不是資料太少，而是同一問題留下太多看起來都像答案的文件。每個 canonical source 至少標示：

• 目前有效（current）
• 待驗證（pending）
• 已取代（superseded）
• 最後更新日期

理解改變時，先更新 canonical source，再調整 Router；歷史版本可以保留，但不得繼續出現在 current 索引。跨工具時也不要複製完整內容：Obsidian 保留正式來源，Claude Memory 或 ChatGPT Project 只保留必要偏好、scope 或指向來源的短索引。

我會把可用的 AI 長期記憶定義成五個條件：找得到、知道何時用、只載入需要的部分、來源核對得了、過期時改得掉。這比累積多少筆記更接近真正成果。

常見問題

有 Obsidian 就等於有 AI 長期記憶嗎？

不等於。Obsidian 可以保存、連結與搜尋資料，但 AI 還需要讀取權限、檢索工具與調用規則。沒有這些連接時，使用者仍要先找到相關筆記，再把它提供給 AI。

直接把整個知識庫放進 AI Project 可以嗎？

可以加入允許使用的資料，但不要假設資料越多答案越好。先按工作範圍拆 Project，保留小型 Router 與唯一正式來源，再測試錯誤召回、舊版本和不相關問題。

Memory Router 一定要使用向量資料庫嗎？

不需要。新手可以先用一份 Markdown 或 YAML 索引，加上明確的 use_when、do_not_use_when 與 canonical_source。只有資料量與使用頻率證明手動方法不夠時，再考慮自建 RAG。

參考資料與適用範圍

產品資料查閱於 2026 年 9 月 10 日：Anthropic：Context windows、Anthropic：RAG for projects、Anthropic：Claude chat search and memory、OpenAI：Projects in ChatGPT、Google：Create a notebook in Gemini Notebook、Notion：Enterprise Search。Memory Router、三層架構與調用欄位為本篇原創操作方法，不代表任何一家公司的內部實作。