AI Agent 的記憶怎麼找資料？用筆記整理講清楚

助理每天跟你聊天、看文件、改程式、記住偏好。幾週後你問它：「上次那個登入問題後來怎麼處理？」它要回答得好，靠的不會是神奇記性，重點在於能不能從一大堆舊筆記裡，快速找回正確的那幾段。

這篇原文談的就是這件事：AI Agent 的記憶系統，難題有兩層：要先把東西存起來，之後還要找得回來。更重要的是，搜尋方法不能到最後才選，它在你寫入記憶的那一刻，就大致被決定了。

先問一個很生活的問題：你是怎麼整理筆記的？

想像你有四種整理方式：

• 把最重要的 100 件事貼在牆上，每次工作都看得到。
• 把每個主題整理成一張清楚的索引卡。
• 把所有聊天紀錄和工作紀錄原封不動存下來。
• 先存摘要，需要時再展開細節。

這四種筆記方式，會自然導向四種找資料方式。

牆上的便條不用搜尋，因為它一直在眼前。索引卡適合用關鍵字找。完整紀錄太雜，可能需要同時用「關鍵字」和「語意相似」來找。摘要加細節的系統，則會先看大方向，再決定要不要往下挖。

AI Agent 的記憶系統也是同樣的道理。

小而重要的記憶，可以直接放在眼前

有些系統不搜尋記憶，聽起來很奇怪，但其實很合理。

如果記憶很少，而且幾乎每次都會用到，搜尋反而是多餘的。例如你的姓名、語氣偏好、正在做的專案、常用工具規則。這些資訊就像貼在螢幕旁邊的便條，Agent 每次回應前都看得到。

原文提到 deerflow 會把記憶限制在 100 個 facts 以內，直接放進 prompt。letta 的 Core Memory 也類似，核心記憶常駐在系統提示中。

這種做法的好處是穩定，不用擔心搜尋漏掉。代價是空間有限，不能把所有東西都塞進去。它適合「少量、長期、經常需要」的記憶。

已整理好的筆記，用關鍵字就很好找

BM25 可以先理解成「聰明一點的關鍵字搜尋」。它會看某些字出現的位置與頻率，幫搜尋結果排序。它不懂語意，但很擅長找精準字詞。

如果 Agent 寫入記憶前已經整理過內容，BM25 就很夠用。例如把「使用者喜歡 dark mode」整理成一張主題卡，以後搜尋 dark mode、使用者偏好、介面設定，都比較容易命中。

原文用 engram 當例子：Agent 不會把所有原話都丟進資料庫，它會在寫入時把內容整理成主題記錄。這樣搜尋時就不用做太複雜的語意判斷。

對產品設計來說，這像是團隊先把訪談逐字稿整理成洞察卡。卡片整理得好，搜尋系統就不用那麼吃力。

原始紀錄很多時，最好混合幾種找法

麻煩出現在「資料又多又雜」的時候。

聊天內容常有同義句：我喜歡暗色模式、我偏好 dark theme、幫我把介面調暗，意思可能相近。程式工作又有很多不能模糊的字：auth.go、write_file、JWT、某個函式名稱。這些字只要差一點，指向的可能就是另一件事。

所以有些系統會用混合搜尋：

• 用向量搜尋找語意相近的內容。
• 用 BM25 找精準字詞。
• 用人名、專案名、檔名等關聯再加分。

原文提到 mem0、agentmemory、mempalace 都屬於這類，但各自的比例不同。原因不在於誰比較潮，而是它們存的記憶不一樣。聊天很多的系統需要處理語意相近；寫程式很多的系統需要保留精準字詞；工具紀錄很多的系統還要處理噪音。

這裡最像產品中的搜尋頁：使用者有時輸入概念，有時輸入型號，有時輸入人名。只靠一種搜尋，很容易漏掉重要結果。

有些記憶要先看摘要，再展開細節

另一種做法像是看書的目錄。

你不會一開始就把整本書翻完，而是先看章節標題，找到可能相關的部分，再打開那幾頁。OpenViking 這類層級式搜尋也是這個思路：先找摘要層，方向對了，再展開到細節或原始內容。

這種做法比較省空間，也比較像人類查資料。缺點是系統比較複雜，可能還需要多一次 AI 判斷，先把你的問題轉成搜尋計畫。

當記憶很多、內容很長、又不確定該取多細時，層級搜尋會很有用。

最難的是：要在寫入時整理，還是在搜尋時理解？

同樣意思、不同說法，要在哪個階段處理？

一種做法是在寫入時整理。Agent 先把「我喜歡暗色介面」整理成標準事實，例如「使用者偏好 dark mode」。好處是之後很好找；風險是整理時可能漏掉細節。

另一種做法是保留原文，等搜尋時再靠語意模型理解。好處是原始資訊完整；風險是搜尋模型不夠好時，可能找不到，或找錯。

這其實是產品設計裡常見的取捨：要讓使用者填結構化表單，還是讓他自由輸入，之後再由系統理解？前者乾淨，後者保留脈絡。

記憶片段太小會沒脈絡，太大又浪費

搜尋結果到底要拿回多大一段，也是大問題。

只拿一句話很精準，但可能不知道當時為什麼這樣決定。拿一整段對話比較完整，但會佔用很多 token，也可能把不相關內容帶進來。

這像是設計研究中的便利貼：一張便利貼太短，容易斷章取義；整份訪談逐字稿太長，又很難快速使用。好的記憶系統要在「精準」和「脈絡」之間取得平衡。

原文列出不同系統的選擇：有的存 20 字左右的 fact，有的存 100 到 300 字的主題記錄，有的存 800 字 chunk，也有的用多層摘要按需展開。這些都沒有標準答案，重點在不同情境下的取捨。

給非工程讀者的判斷法

如果你之後看到 AI 記憶功能，可以用三個問題快速判斷它的設計：

1. 它存的是什麼？是原文、摘要、事實，還是工具紀錄？
2. 它怎麼找？是直接放進上下文、關鍵字搜尋、語意搜尋，還是混合搜尋？
3. 它一次拿回多大段？是一句事實、一張卡片、一段原文，還是一層一層展開？

只要回答這三題，就能看出一個 Agent 記憶系統的性格。

這篇文章真正想說的事

AI Agent 的記憶不能只當成資料庫功能。它比較像一套工作流程：怎麼記、怎麼整理、怎麼搜尋、怎麼把結果放回當下對話。

寫入和搜尋是綁在一起的。你如果存的是整理過的事實，就適合簡單、快速、可解釋的搜尋。你如果存的是完整原文，就需要更強的語意搜尋和混合排序。你如果希望記憶能長期變大，就要處理摘要、層級、取回片段大小這些問題。

對一般使用者來說，最簡單的理解是：AI 要變得可靠，不能只把所有記憶都塞進腦袋。它要像一位好助理，知道什麼該寫成便條，什麼該整理成卡片，什麼要保留原始紀錄，以及需要時該怎麼找回來。

參考來源

• Warmwater.dev：Memory 02：記憶怎麼被找到——四種搜尋模式與 Write-Search 耦合

https://warmwater.dev/blog/agent-memory-02-search-retrieval