AI 也能有長期記憶了！Hermes Memory 完全指南
整理版優先睇
Hermes Memory 嘅設計哲學：有界、篩選、跨會話，只記住能提升協作效率嘅關鍵事實
呢篇文章係基於 Hermes 官方文檔整理，重點講解 Agent 長期記憶（Memory）嘅設計理念同實際用法。作者想解決一個常見問題：AI Agent 點樣先可以唔係每次重新自我介紹，而係記住用戶偏好、項目約定同踩過嘅坑？好多 Agent 嘅記憶設計係「乜都記」，但咁樣反而會令上下文變亂，Agent 變蠢。作者提出一個核心觀點：真正好用嘅長期助手，唔係靠無限記憶，而係知道「咩值得記、咩應該忘」。
整體結論係 Hermes Memory 嘅設計好剋制——佢用兩份文件（MEMORY.md 同 USER.md）分別記錄環境事實同用戶偏好，容量有限（約 2,200 同 1,375 字符），逼你用高密度嘅方式保存關鍵事實。記憶會喺每輪會話開始時凍結注入，中途更改唔會影響當前會話，確保穩定性。另外，Memory 同 Skills、session_search、上下文文件各有定位，唔應該互相代替。
容量超過 80% 就要整理，典型數量係 8-15 條同 5-10 條。作者仲提醒，判斷乜嘢值得記嘅標準係「三日後仲會改變 Agent 行動方式嘅信息」。最終，Memory、Skills 同 session_search 三者加埋先係一個完整嘅長期協作結構。如果只係個人輕量使用，內置 Memory 已經夠用；如果需要多 Agent、跨項目，可以考慮外部 Provider。
- Hermes Memory 唔係記低所有對話，而係有界、篩選、跨會話嘅持久記憶，類似 Agent 嘅隨身便籤。
- 記憶分兩份文件：MEMORY.md 記錄環境事實，USER.md 記錄用戶偏好，容量有限，要精煉。
- 記憶會喺會話開始時凍結注入，中途更改唔影響當前會話，保證基礎上下文穩定。
- 判斷乜嘢值得記：三日後仲會改變 Agent 行動方式嘅信息；唔值得記嘅包括瑣碎事實、原始數據、已寫入 SOUL.md 嘅內容。
- 記憶唔係越多越好，使用率超過 80% 要合併；典型數量係 8-15 條，搭配 Skills 同 session_search 先係完整方案。
Memory 係隨身便籤，唔係檔案館
Hermes 嘅 Memory 唔係將所有聊天記錄塞入去。如果咁做，聊天記錄入面嘅臨時路徑、調試日誌、半截思路、過期結論只會令 Agent 更亂。
官方文檔對 Memory 嘅定位係：有界、經過篩選、跨會話保留嘅持久記憶。
呢幾個詞好關鍵：有界表示唔係無限倉庫；篩選表示唔係所有內容都值得記；跨會話表示解決下次仲用得嘅問題。作者將佢理解成 Agent 嘅隨身便籤——唔係檔案館，亦唔係垃圾桶。
只應該放嗰啲下次啓動就值得知道的關鍵事實。
呢個係成個 Memory 功能嘅核心思維：唔係記得多，而係記得準。
內置記憶由兩份文件組成，各有定位
Hermes 嘅內置記憶由兩個文件組成：~/.hermes/memories/MEMORY.md 同 ~/.hermes/memories/USER.md。
MEMORY.md 係 Agent 嘅個人筆記，適合記錄環境事實、項目約定、工作流經驗、踩坑後嘅修正。
例如：項目測試命令係 pnpm test，部署前必須先跑 lint，某接口喺 staging 環境用 2222 端口。呢啲唔係用戶性格，係 Agent 辦事需要知道嘅現場信息。
USER.md 係用戶檔案，適合記錄用戶偏好、溝通方式、期待、禁忌、工作習慣。
例如：用戶默認用中文回答，唔鍾意空泛總結，偏好直接俾結論同下一步。呢類信息每次協作都可能影響輸出方式。
官方仲俾咗明確容量限制：MEMORY.md 約 2,200 字符，USER.md 約 1,375 字符。呢點好重要——逼你唔好將 Memory 當倉庫，真正好用嘅記憶應該短、準、密度高。
凍結快照：新記憶唔會本輪生效
Hermes Memory 有一個好容易忽略嘅設計：凍結快照。記憶會喺每個會話開始時從磁盤加載，並作為凍結塊注入系統提示。
Agent 開始呢輪會話時，會先讀取當時嘅 Memory；如果佢喺本輪新增、替換或刪除記憶，變化會立即持久化到磁盤，但唔會改變當前會話已經注入嘅系統提示。
新嘅記憶要等到下一次會話開始時先會進入提示。呢個設計確保一輪會話入面，Agent 嘅基礎上下文唔會半路漂移，長期記憶亦唔會因為一句臨時話馬上影響當前推理方向。
Memory 工具支援 add、replace、remove，但無單獨嘅 read 操作，因為記憶會喺會話開始時自動注入上下文。呢個細節說明 Memory 係俾 Agent 開局帶狀態用，唔係俾你手動翻筆記用。
呢個凍結機制令到記憶更新同當前推理分離，提高穩定性。
咩值得記、咩應該忘？一個三日法則
應該保存嘅有：用戶偏好、環境事實、用戶糾正嘅信息、項目約定、已經完成且以後可能影響判斷嘅工作、明確要求記住嘅內容。換句話說，要唔係提升下次協作效率，就係避免下次犯同樣錯。
應該忽略嘅包括：瑣碎或顯而易見嘅信息、隨手一搜就查到嘅通用事實、大段代碼日誌表格、一次性調試上下文、已經寫喺 SOUL.md 或 AGENTS.md 嘅內容。
容量管理方面，官方建議記憶使用率超過 80% 時，加新前要先合併現有條目。典型數量：memory 大約 8 到 15 條，user 大約 5 到 10 條。一條差嘅記憶係「用戶有一個項目」，一條好嘅記憶係「項目用 pnpm，開發命令係 pnpm dev，提交前要跑 pnpm lint 同 pnpm test」。
Hermes 仲會安全掃描，寫入記憶前會檢查提示注入、憑證外泄、SSH 後門、不可見 Unicode 字符等風險模式。因為記憶會進入系統提示，所以唔可以隨便信。
真正好用嘅 Agent 需要三層記憶
Hermes 嘅長期能力其實由三層組成：Memory、Skills 同 session_search。Memory 負責常駐關鍵事實；Skills 負責記住可複用嘅方法；session_search 負責搜索歷史會話細節。
三者都重要，但唔好互相替代。Memory 容量細，速度快，必須精煉；session_search 靠 SQLite 全文搜索，適合「我哋上週係咪討論過某個部署方案？」呢類問題；上下文文件（如 AGENTS.md）更似項目說明書。
如果只係個人輕量使用，內置 Memory 已經解決好多問題。如果需要多 Agent、跨項目、長期知識庫，可以考慮外部 Provider（如 Mem0、Honcho 等），但同一時間只可以激活一個，而且外部 Provider 唔會取代內置記憶。
最終結論：長期助手真正需要嘅唔係無限記憶，係知道咩值得記、咩應該忘。呢個先係 Hermes Memory 嘅設計價值。
呢篇文章係根據 Hermes 官方嘅「持久記憶」、「記憶提供者」同「上下文文件」文檔整理，重點講清楚 Memory 到底解決咩問題
前面三篇我哋已經將 Hermes 講到咗一個比較順嘅階段
第一篇講安裝同快速入門
新手都可以5分鐘上手 Hermes Agent：終端裏面嘅 AI 工作台，比你想像嘅簡單
第二篇講 CLI 應該點樣用，唔好將佢當成普通聊天框
Hermes 裝好咗，跟住呢？8 個 CLI 動作畀 Agent 開工
第三篇講 Skills：將重複嘅工作方法沉澱落嚟，畀 Agent 唔使每次重新學流程
唔好再重複教 Agent：Hermes 嘅 Skills，先至係越用越強嘅關鍵
咁第四篇應該講咩？
我覺得一定要講 Memory
因為一個 Agent 真正開始有 AI 嘅助手感覺，唔係佢會講靚話，亦唔係佢可以一次調用好唔多工具
而係你第二次、第三次揾佢嘅時候，佢唔係由零開始
佢知道你嘅偏好
知道呢個項目以前踩過咩坑
知道你反覆強調過邊啲禁忌
呢啲先至係長期助手同一次性聊天機械人嘅分界線
1. Memory 唔係將聊天記錄全部塞入去
Hermes 嘅 Memory 唔係將所有聊天記錄都記住
如果真係咁做，好快就會出問題
聊天記錄裏面有大量一次性內容：臨時路徑、除錯日誌、半截思路、過期結論、廢棄方案
全部塞入上下文，只會令到 Agent 更加亂
官方文檔對 Hermes Memory 嘅定位其實好剋制
有界限、經過篩選、跨會話保留嘅持久記憶
呢幾個詞好關鍵
有界，說明佢唔係無限倉庫
篩選，說明唔係所有內容都值得記
跨會話，說明佢解決嘅係下次仲用得嘅問題
我更情願將佢理解成 Agent 嘅隨身便條——唔係檔案館，亦唔係垃圾桶
佢只應該放嗰啲下次啟動就值得知道嘅關鍵事實
2. Hermes 嘅記憶分成兩份文件
官方文檔裏面，Hermes 嘅內置記憶由兩個文件組成
MEMORY.md 係 Agent 嘅個人筆記
適合記錄：環境事實、項目約定、工作流程經驗、踩坑後嘅修正、已經完成嘅關鍵工作
比如：
呢啲唔係用戶性格，係 Agent 辦事需要知道嘅現場資訊。
USER.md 係用戶檔案
適合記錄：你嘅偏好、溝通方式、期待、禁忌、工作習慣
比如：
呢類資訊每次協作都可能影響輸出方式。
官方仲畀咗明確容量限制MEMORY.md約 2,200 字符USER.md約 1,375 字符。
呢點好重要——佢逼你唔好將 Memory 當倉庫
真正好用嘅記憶，應該短、準、密度高
3. 點解新記憶唔係本輪即刻生效
Hermes Memory 仲有一個好容易俾人忽略嘅設計凍結快照。
官方文檔寫到，記憶會喺每個會話開始嗰陣從磁盤加載，並作為凍結塊注入系統提示
即係話
Agent 開始呢一輪會話嗰陣，會先讀取當時嘅 Memory
如果佢喺本輪會話入面新增、取代或刪除咗記憶，呢啲變化會即刻持久化到磁盤
但唔會改變當前會話已經注入嘅系統提示
新嘅記憶，要到下一次會話開始嗰陣先至進入提示
我哋可以將佢諗成一本會議前派落嚟嘅資料冊：
會議中途有人更新咗資料庫，資料庫當然會保存
但你手上嗰本已經派咗落嚟嘅冊仔，唔會突然自己改頁碼、改段落
下次開會，再拎到新版
呢個設計嘅好處係穩定：
一輪會話裏面，Agent 嘅基礎上下文唔會半路漂移
長期記憶亦唔會因為一句臨時說話，即刻影響當前推理方向
Hermes 嘅 memory 工具支援 add、replace、remove，冇單獨嘅 read 操作，因為記憶會喺會話開始嗰陣自動注入上下文
呢個細節亦都說明Memory 唔係畀你手動翻筆記用嘅，佢係畀 Agent 開局帶狀態用嘅
4. 咩嘢應該記，咩嘢應該忘
Memory 最難嘅係咩嘢值得保存。
好多人一用長期記憶，就會想將所有嘢都記低
呢個其實會將 Agent 養蠢
官方文檔畀嘅方向好明確
應該保存嘅
用戶偏好
環境事實
用戶糾正過嘅資訊
項目約定
已經完成而且以後可能影響判斷嘅工作
明確要求記住嘅內容
換句話講，一係可以提升下一次協作效率，一係可以避免下一次犯同樣嘅錯。
應該忽略嘅
瑣碎或顯而易見嘅資訊
隨手一搜就可以查到嘅通用事實
大段代碼、日誌、表格呢啲原始數據
一次性除錯上下文
已經寫喺
SOUL.md或AGENTS.md裏面嘅內容
呢度有個判斷標準幾好用
如果呢條資訊三日後仲可能改變 Agent 嘅行動方式，就值得考慮保存
如果只係今日傾過 Python，咁冇價值
如果係呢個項目唔好用 sudo 行 Docker，因為用戶已經喺 docker 組裏面，咁就有價值
5. Memory、session_search 同上下文文件，唔係同一樣嘢
Hermes 裏面有幾個嘢睇落都同記住有關，但佢哋負責嘅層次唔一樣。
Memory 負責常駐關鍵事實
佢會喺會話開始嗰陣進入上下文，速度快，但容量細，所以必須精煉
session_search 負責搜索歷史會話
官方文檔寫到，所有 CLI 同消息會話會儲存喺 ~/.hermes/state.db 呢個 SQLite 數據庫裏面，並啟用 FTS5 全文搜索
搜索結果會由 Gemini Flash 做摘要
所以 session_search 更適合呢種問題
上下文文件
比如 .hermes.md、HERMES.md、AGENTS.md、CLAUDE.md、SOUL.md、.cursorrules、.cursor/rules/*.mdc。
呢啲更似項目說明書或行為約定。
例如 AGENTS.md 可以話畀 Agent：呢個項目目錄點樣分、測試命令係咩、邊啲文件唔好亂改、子目錄裏面有咩特殊規則
Memory、session_search、上下文文件擺埋一齊睇，就好清楚喇
Memory 記長期事實
session_search揾歷史細節上下文文件畀項目規則
三者都重要，但唔好互相替代
6. 記憶越多，唔等於越聰明
官方文檔裏面有一個好實在嘅容量管理建議
當記憶使用率超過 80% 嗰陣，添加新條目前最好先合併已有條目
呢句話背後有個樸素道理長期記憶唔係越多越好。
越滿越需要整理
官方畀嘅典型數量亦唔大memory大約 8 到 15 條user大約 5 到 10 條。
即係話 Hermes 唔係叫你寫一本個人傳記畀 Agent，佢更似叫你維護十幾條高價值索引。
例如一條差嘅記憶係
呢個等於冇講過
一條好嘅記憶應該更具體
同樣係佔字符，後者可以直接改變 Agent 下一步點樣做嘢。
安全掃描
Hermes 仲會做安全掃描
官方文檔提到，寫入記憶前會掃描提示注入、憑證外洩、SSH 後門、不可見 Unicode 字符等風險模式
因為 Memory 會進入系統提示。可以進入系統提示嘅嘢，就唔可以隨便信
7. 外部 Provider：記憶仲可以再擴展
如果內置嘅 MEMORY.md 和 USER.md 唔夠用，Hermes 官方仲提供咗外部記憶 Provider。
文檔裏面列咗 8 個Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory。
但呢度要注意兩點
同一時間只可以激活一個外部 Provider
外部 Provider 唔會取代內置記憶
官方講得好清楚
內置記憶始終同外部 Provider 同時啟用，外部 Provider 係疊加層。
啟用後，Hermes 會做幾類事情
注入 Provider 上下文
對話前預取相關記憶
回應後同步對話輪次
喺支援嘅情況下會話結束嗰陣提取記憶
鏡像內置記憶寫入
添加 Provider 專屬工具
常用命令亦好直接
如果只係個人輕量使用內置 Memory 已經可以解決好多唔好再重複提我嘅問題。
如果係多 Agent、跨項目、長期知識庫、語義檢索、知識圖譜呢類更重嘅場景，再考慮外部 Provider 會更合理
8. 真正好用嘅 Agent，需要三層記憶
講到呢度，Hermes 嘅長期能力其實可以拼出一個比較完整嘅結構
第一層係 Memory：畀 Agent 記住關鍵事實
第二層係 Skills：畀 Agent 記住可以重用嘅方法
第三層係 session_search：畀 Agent 喺需要嗰陣揾返歷史細節
呢三層夾埋一齊，先至似一個真正可以長期協作嘅助手
唔係每次見面都重新自我介紹，唔係每次做嘢都重新講流程，亦唔係每次想揾舊結論都翻聊天記錄翻到崩潰
所以我覺得 Hermes Memory 呢部分嘅價值唔在於佢有記憶呢四個字
在於佢對記憶做咗限制：
佢冇假裝咩都可以記
佢畀 Agent 只記應該記嘅嘢
長期助手真正需要嘅，唔係無限記憶，係知道咩值得記，咩應該忘
本文基於 Hermes 官方 持久記憶 記憶提供者 上下文文件 文檔整理，重點講清楚 Memory 到底解決什麼問題
前面三篇我們已經把 Hermes 講到了一個比較順的階段。
第一篇講安裝和快速入門。
小白也能5分鐘上手 Hermes Agent：終端裏的 AI 工作台，比你想象的簡單
第二篇講 CLI 該怎麼用，別把它當普通聊天框。
Hermes 裝好了，然後呢？8 個 CLI 動作讓 Agent 開幹
第三篇講 Skills：把重複的工作方法沉澱下來，讓 Agent 不用每次重新學流程。
別再重複教 Agent：Hermes 的 Skills，才是越用越強的關鍵
那第四篇該講什麼？
我覺得必須講 Memory。
因為一個 Agent 真正開始有 AI 的助手感，不是它會說漂亮話，也不是它能一次調很多工具。
而是你第二次、第三次找它時，它不是從零開始。
它知道你的偏好。
知道這個項目以前踩過什麼坑。
知道你反覆強調過哪些禁忌。
這才是長期助手和一次性聊天機器人的分界線。
1. Memory 不是把聊天記錄全塞進去
Hermes 的 Memory 不是把所有聊天記錄都記住。
如果真這麼做很快就會出問題。
聊天記錄裏有大量一次性內容：臨時路徑、調試日誌、半截思路、過期結論、廢棄方案。
全部塞進上下文，只會讓 Agent 更亂。
官方文檔對 Hermes Memory 的定位其實很剋制：
有界、經過篩選、跨會話保留的持久記憶
這幾個詞很關鍵：
有界，說明它不是無限倉庫
篩選，說明不是所有內容都值得記
跨會話，說明它解決的是下次還能用的問題
我更願意把它理解成 Agent 的隨身便籤——不是檔案館，也不是垃圾桶。
它只應該放那些下次啓動就值得知道的關鍵事實。
2. Hermes 的記憶分成兩份文件
官方文檔裏，Hermes 的內置記憶由兩個文件組成：
MEMORY.md 是 Agent 的個人筆記
適合記錄：環境事實、項目約定、工作流經驗、踩坑後的修正、已經完成的關鍵工作。
比如：
這些不是用戶性格，是 Agent 辦事需要知道的現場信息。
USER.md 是用戶檔案
適合記錄：你的偏好、溝通方式、期待、禁忌、工作習慣。
比如：
這類信息每次協作都可能影響輸出方式。
官方還給了明確容量限制：MEMORY.md約 2,200 字符，USER.md約 1,375 字符。
這點挺重要——它逼着你別把 Memory 當倉庫。
真正好用的記憶，應該短、準、密度高。
3. 為什麼新記憶不是本輪立刻生效
Hermes Memory 還有一個很容易被忽略的設計：凍結快照。
官方文檔寫到，記憶會在每個會話開始時從磁盤加載，並作為凍結塊注入系統提示。
也就是說：
Agent 開始這一輪會話時，會先讀取當時的 Memory
如果它在本輪會話中新增、替換或刪除了記憶，這些變化會立即持久化到磁盤
但不會改變當前會話已經注入的系統提示
新的記憶，要到下一次會話開始時才進入提示。
我們可以把它想成一本會議前發下來的資料冊：
會議中途有人更新了資料庫，資料庫當然會保存
但你手上那本已經發下來的冊子，不會突然自己改頁碼、改段落
下次開會，再拿到新版
這個設計的好處是穩定：
一輪會話裏，Agent 的基礎上下文不會半路漂移
長期記憶也不會因為一句臨時話，馬上影響當前推理方向
Hermes 的 memory 工具支持 add、replace、remove，沒有單獨的 read 操作，因為記憶會在會話開始時自動注入上下文。
這個細節也說明：Memory 不是給你手動翻筆記用的，它是給 Agent 開局帶狀態用的。
4. 什麼該記，什麼該忘
Memory 最難的是什麼值得保存。
很多人一用長期記憶，就會想把所有東西都記下來。
這其實會把 Agent 養笨。
官方文檔給的方向很明確。
應該保存的：
用戶偏好
環境事實
用戶糾正過的信息
項目約定
已經完成且以後可能影響判斷的工作
明確要求記住的內容
換句話說，要麼能提升下一次協作效率，要麼能避免下一次犯同樣的錯。
應該忽略的：
瑣碎或顯而易見的信息
隨手一搜就能查到的通用事實
大段代碼、日誌、表格這種原始數據
一次性調試上下文
已經寫在
SOUL.md或AGENTS.md裏的內容
這裏有個判斷標準挺好用：
如果這條信息三天後還可能改變 Agent 的行動方式，就值得考慮保存。
如果只是今天聊過 Python，那沒有價值
如果是這個項目不要用 sudo 跑 Docker，因為用戶已經在 docker 組裏，那就有價值
5. Memory、session_search 和上下文文件，不是一回事
Hermes 裏有幾個東西看起來都和記住有關，但它們負責的層次不一樣。
Memory 負責常駐關鍵事實
它會在會話開始時進入上下文，速度快，但容量小，所以必須精煉。
session_search 負責搜索歷史會話
官方文檔寫到，所有 CLI 和消息會話會存儲在 ~/.hermes/state.db 這個 SQLite 數據庫裏，並啓用 FTS5 全文搜索。
搜索結果會由 Gemini Flash 做摘要。
所以 session_search 更適合這種問題：
上下文文件
比如 .hermes.md、HERMES.md、AGENTS.md、CLAUDE.md、SOUL.md、.cursorrules、.cursor/rules/*.mdc。
這些更像項目說明書或行為約定。
例如 AGENTS.md 可以告訴 Agent：這個項目目錄怎麼分、測試命令是什麼、哪些文件不要亂改、子目錄裏有什麼特殊規則。
Memory、session_search、上下文文件放在一起看，就很清楚了：
Memory 記長期事實
session_search找歷史細節上下文文件給項目規則
三者都重要，但別互相替代。
6. 記憶越多，不等於越聰明
官方文檔裏有一個很實在的容量管理建議：
當記憶使用率超過 80% 時，添加新條目前最好先合併已有條目。
這句話背後有個樸素道理：長期記憶不是越多越好。
越滿越需要整理。
官方給的典型數量也不大：memory大約 8 到 15 條，user大約 5 到 10 條。
也就是說Hermes 不是讓你寫一本個人傳記給 Agent，它更像讓你維護十幾條高價值索引。
比如一條差的記憶是：
這等於沒說。
一條好的記憶應該更具體：
同樣是佔字符，後者能直接改變 Agent 下一步怎麼幹活。
安全掃描
Hermes 還會做安全掃描。
官方文檔提到，寫入記憶前會掃描提示注入、憑證外泄、SSH 後門、不可見 Unicode 字符等風險模式。
因為 Memory 會進入系統提示。能進入系統提示的東西，就不能隨便信。
7. 外部 Provider：記憶還能再擴展
如果內置的 MEMORY.md 和 USER.md 不夠用，Hermes 官方還提供了外部記憶 Provider。
文檔裏列了 8 個：Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory。
但這裏要注意兩點：
同一時間只能激活一個外部 Provider
外部 Provider 不會替代內置記憶
官方說得很清楚：
內置記憶始終與外部 Provider 同時啓用，外部 Provider 是疊加層。
啓用後，Hermes 會做幾類事情：
注入 Provider 上下文
對話前預取相關記憶
響應後同步對話輪次
在支持的情況下會話結束時提取記憶
鏡像內置記憶寫入
添加 Provider 專屬工具
常用命令也很直接：
如果只是個人輕量使用，內置 Memory 已經能解決很多別再重複提醒我的問題。
如果是多 Agent、跨項目、長期知識庫、語義檢索、知識圖譜這類更重的場景，再考慮外部 Provider 會更合理。
8. 真正好用的 Agent，需要三層記憶
講到這裏，Hermes 的長期能力其實能拼出一個比較完整的結構：
第一層是 Memory：讓 Agent 記住關鍵事實
第二層是 Skills：讓 Agent 記住可複用的方法
第三層是 session_search：讓 Agent 在需要時找回歷史細節
這三層合起來，才像一個真正能長期協作的助手。
不是每次見面都重新自我介紹，不是每次做事都重新講流程，也不是每次想找舊結論都翻聊天記錄翻到崩潰。
所以我覺得Hermes Memory 這部分的價值不在於它有記憶這四個字。
在於它對記憶做了限制：
它沒有假裝什麼都能記
它讓 Agent 只記該記的東西
長期助手真正需要的，不是無限記憶，是知道什麼值得記，什麼應該忘。