會記憶的 AI：Hermes Agent 四層記憶系統讓 AI 真正「懂你」
目錄
共 15 個章節
在人工智慧快速發展的今日，幾乎所有的 AI Agent 都被設計成「即時」的互動工具：你問什麼，它即時回什麼，卻在對話結束後把所有資訊拋諸腦後。這樣的設計固然簡化了系統的負擔，卻也讓 AI 缺乏了「持續了解使用者」的關鍵能力。當使用者需要在多個會話、跨領域任務之間保持一致性與脈絡時，傳統的 AI Agent 往往只能依賴外部的資料庫或手工提示，無法真正「記住」使用者的偏好、行為模式與情境需求。這就是為什麼許多人在使用 AI 助理時，會感覺它們像是一次性的工具，而非具備長期關係的智能夥伴。
Hermes Agent（由 Nous Research 開發）把「會跨會話記得你」做成產品能力，而不是靠使用者每次重貼提示詞。本文沿用「四層記憶」的教學架構，把官方實際機制對應成四個層次，方便理解資料怎麼進、怎麼查、怎麼變成可重用的做法。需先講清楚：截至 2026 年 7 月，官方文件的主軸是有上限的 MEMORY.md／USER.md 持久記憶、會話內的 session_search（本機 SQLite FTS5）、以及可累積的 Skills 程序記憶；另外可外掛 memory provider。下文的英文層名是我們為了說明而對齊的抽象，不是 Nous 後台四個固定商品模組名稱。官方記憶說明見 Hermes Persistent Memory 文件。
Layer 1：Small Context，工作記憶與凍結注入
Small Context，俗稱「工作記憶」，對應 Hermes 在單次會話裡當下可用的上下文：目前對話訊息、工具結果，以及在會話開始時注入系統提示的 MEMORY／USER 快照。模型上下文窗口本身仍受你選定的主模型限制，常見範圍可從數十萬到百萬級 tokens 不等；這與「持久記憶檔的字元上限」是兩件事，不宜混為一談。
在技術實現上，持久筆記不會在每一輪對話無限膨脹。依官方文件，MEMORY.md 上限約 2,200 字元（約 800 tokens），USER.md 上限約 1,375 字元（約 500 tokens），兩者合計約 3,575 字元。它們以凍結快照方式在 session 開始時進入系統提示，以利前綴快取；當輪用 memory 工具寫入後，通常在下一個 session 才完整反映到提示裡。這讓「長期偏好」有固定預算，而不是把整段聊天紀錄硬塞進每一輪。
這一層的侷限也很清楚：會話一長，近期訊息仍會互相排擠；跨天、跨主題的細節也不該全塞進 MEMORY。這就需要第二層：可搜尋的歷史，而不是把所有往事永久塞進系統提示。
Layer 2：Searchable History，可搜尋的會話歷史
Searchable History（可搜尋歷史）在 Hermes 的內建預設，比較接近 session_search：所有 CLI 與通訊平台會話寫進本機 SQLite（例如 state.db），用 FTS5 全文檢索找回數週前的對話片段。重點是「需要時再查」，而不是每輪把歷史全塞進上下文，藉此維持提示詞穩定與成本可控。
產業界若自建 RAG，常見步驟仍包括分段擷取（Chunking）、嵌入模型、向量索引與重排序。Hermes 文件與社群討論也提到可外掛 memory provider、甚至接向量庫類後端；但開箱內建的跨會話召回是關鍵字型 FTS5，不是「一定等於 Pinecone／Weaviate 向量庫」。撰寫或評估時應分清：預設能力 vs 可選擴充。
這層的價值在於跨會話的「宏觀記憶」。例如使用者曾提過台北咖啡廳與夜市小吃，之後再問相關問題時，agent 可先搜尋舊會話再回答，而不必使用者每次重講城市。相較純向量方案，FTS5 對用詞一致的查詢很快，但對大幅改寫的語意問題較弱，實務上要讓 agent「記得去搜」，並用接近原文的關鍵詞。
另外，Hermes 的學習閉環也強調：複雜任務後可沉澱成 skill、使用中可自我修補 skill，這與「只存聊天紀錄」不同，會接到第四層的程序記憶。
Layer 3：Optional Modeling，偏好與使用者模型
Optional Modeling（偏好建模）在官方產品上，最接近的是 USER.md 使用者檔，以及 agent 用 memory 工具主動寫入的偏好、溝通風格與禁忌。目標不是另訓一個巨大推薦模型，而是把穩定、高訊號的使用者事實壓進有限字元，讓之後每個 session 一開始就帶著「你是誰、你要怎麼被對待」。
在技術想像上，業界常談使用者嵌入、偏好圖譜、持續學習；Hermes 文件另提供可選的外部 memory provider（同一時間通常只開一個），並提到可與更進階的使用者建模方案整合。對隱私要求高的情境，應把範圍限在本機檔案與本機會話庫，並審慎開啟任何會外送內容的 provider。
能否關閉「學我的偏好」？實務上可以選擇不寫入 USER／memory、或清空對應條目；這比宣稱「後台有一個開關叫 Optional Modeling」更貼近目前文件描述。關於回覆相關度提升的百分比，若無獨立公開基準測試，本文不引用單一數字當產品保證。
Layer 4：Programming Memory，Skills 程序記憶
Programming Memory（程序記憶）對應 Hermes 的 Skills：可重用的流程、檢查清單與指令型知識。它不是另一份聊天摘要，而是「下次遇到同類任務可以直接載入的做法」。Agent 可在複雜任務後建立 skill，並在使用中修補過時步驟，形成文件所說的 closed learning loop 的一環。
常見對應包括：工作流程模板（例如固定格式的日報）、團隊慣例與除錯步驟、與外部系統整合時的操作順序。使用者也可以用自然語言要求 agent「記住這個流程」，再由 skill 機制沉澱，而不是只依賴臨時對話。
這層的核心是「可執行、可演進」：agent 不只知道事實，還知道下一步做什麼。例如要本月銷售報告時，可先 session_search 找過往口徑，再依 skill 規定的抓數、製表、產出步驟執行，減少每次從零口述流程。
實際應用場景
把上述四層（教學抽象）對回 Hermes 真實能力後，較貼地的情境會像這樣：
- 個人化健康管理助理
首次說明高血壓與低鈉偏好時，寫入 USER／MEMORY；之後飲食建議先對照舊會話與既有筆記。若每週要固定產出報告，則應沉澱成 skill（程序記憶），而不是只靠當輪臨時發揮。 - 跨專案專案管理
每個專案會話有自己的 Small Context；關鍵決策靠 session_search 找回。PM 偏好「只給高層摘要」可進 USER.md；同步 Jira／Asana 的步驟適合做成 skill，避免每次重教操作。 - 智慧客服與售後服務
數天前的物流對話用 session_search 找回單號與承諾；穩定的退換貨步驟做成 skill。滿意度與內部 KPI 屬營運數據，應以各公司自己的量測為準，不宜直接當成 Hermes 官方保證數字。
與 OpenClaw 記憶機制的比較
在 AI Agent 的記憶設計領域，OpenClaw 等框架常被拿來對照：有的偏「統一記憶池」，把歷史、偏好與程式相關內容較集中地丟進同一套檢索後端。部署上可能較單純，但分層的存取頻率、預算與權限邊界也較容易糊在一起。
Hermes 較明顯的取捨是：
- 有預算的策展記憶：MEMORY／USER 有字元上限，強迫精煉，避免系統提示被雜訊灌爆。
- 歷史按需檢索：session_search 不預設全量進每一輪，有利快取與成本。
- 程序記憶獨立成 Skills：流程可版本化、可在使用中修補。
- 可選外部 provider：需要更強語意檢索時再擴，而不是預設綁死單一雲端向量庫。
若你要看產品層級的整體對照，可接著讀站內文章：Hermes Agent vs OpenClaw：2026 年最完整的 AI Agent 比較。
四層記憶系統比較表（教學對照）
| 教學層 | 主要對應（截至 2026-07） | 資料類型 | 存取方式 | 典型容量／特性 | 更新頻率 |
|---|---|---|---|---|---|
| Small Context | 當輪對話＋注入的 MEMORY／USER 快照 | 訊息、工具輸出、精煉筆記 | 系統提示／上下文窗口 | MEMORY 約 2,200 字元；USER 約 1,375 字元；模型窗口另計 | 對話即時；持久檔跨 session 生效 |
| Searchable History | session_search（SQLite FTS5）；可選外部 memory provider | 歷史會話訊息 | 關鍵字全文檢索（預設）；provider 可擴 | 隨本機會話量成長 | 會話寫入後可查 |
| Optional Modeling | USER.md＋memory 工具策展；可選進階 provider | 偏好、風格、禁忌、身份 | 每 session 注入；工具維護 | 受 USER／MEMORY 上限約束 | 高訊號變更時寫入 |
| Programming Memory | Skills 程序記憶 | 步驟、慣例、可重用流程 | 載入 skill／依任務觸發 | 依 skill 檔案數量與長度 | 任務後建立、使用中修補 |
常見問題（FAQ）
以下整理實務上最常被問到的點，並對齊公開文件可核對的說法。
Q1：這樣的記憶架構是否一定要額外 GPU 或向量叢集？
不一定。內建 MEMORY／USER 與 session_search 以本機檔案與 SQLite 為主，一般 VPS 即可運作。若自行加向量庫、外部 provider 或大量 embedding，才需要額外服務與預算。模型本身的推論資源（本地或 API）仍要另計。
Q2：如果不想讓系統記住我的偏好，可以怎麼做？
可以避免把敏感偏好寫入 USER／MEMORY、定期清理條目，並謹慎啟用會外送資料的 memory provider。文件強調記憶是策展式、可被 agent 或人工編修的明文檔，而不是不可見的黑箱權重更新。
Q3：程序記憶一定要用專有 DSL 嗎？
Hermes 的 Skills 本質是結構化說明與步驟（常見為 Markdown skill 檔），重點在可重用與可修補，而不是綁死單一廠商 DSL。與外部系統整合時，仍透過工具、指令與既有自動化方式執行。
Q4：如何避免資訊過時或錯誤累積？
官方對 MEMORY 的設計是「滿了要自己整理，不會默默自動砍」，逼 agent 合併過期條目。Skills 也應在使用中修正錯誤步驟。session_search 找回的是歷史原話，仍要搭配查證，避免把過期結論當永恆事實。
Q5：跟傳統只存對話日誌差在哪？
傳統日誌多半是被動存檔；Hermes 把「精煉後永遠帶著走的筆記」「按需搜尋的會話」「可執行的 skill」拆開。這樣既控制每輪 token，又保留長期召回與流程資產。若只做向量日誌而不做策展，常常會變成檢索到很多、但系統提示仍不穩定。
替代方案有限公司觀點：實測分享
「在 替代方案有限公司（Alternative Solutions）的實際部署測試中，我們將 Hermes Agent 的四層記憶系統與現有的客服平台整合，結果顯示平均問題解決時間從 12 分鐘下降至 4.5 分鐘，客戶滿意度提升 22%。更重要的是，系統在多輪對話後能自動識別重複需求，減少了約 30% 的冗餘回覆。對於需要長期追蹤使用者健康的醫療助理場景，Hermes 的 Optional Modeling 能根據患者的用藥歷史與生活型態，提供個性化的健康建議，錯誤率下降至 3% 以下。這些數據充分證明了四層記憶在實際業務場景中的可行性與效益。」
上述為公司內部實測敘述，屬第二層內部案例，本次查核不改數字；對外解讀時請理解其為特定部署條件下的觀察，而非 Nous 官方 benchmark。
結論
若用一句話概括：Hermes 的「會記憶」不是單一魔術資料庫，而是有預算的策展筆記、按需的會話搜尋、與可演進的 Skills 分工。本文的四層架構是為了好講、好教；實作與除錯時仍應回到官方 MEMORY／session_search／skills 文件。
對台灣中小企業而言，重點通常不是先上豪華向量叢集，而是先讓偏好與規範進 USER／MEMORY、讓重複流程變成 skill、讓歷史對話找得到。需要更強語意檢索時，再評估外部 memory provider。這樣的順序比較控成本，也比較貼近 Hermes 目前公開的設計取捨。
若您想進一步了解 Hermes Agent 的基礎與定位，歡迎閱讀系列首篇：Hermes Agent 是什麼？Nous Research 如何用「會記憶的 AI」改變遊戲規則？
Related
