<!-- Source: https://hermesbible.com/flows/context-os-for-hermes-agent -->

核心概念

大多數 AI 的「記憶體」就是一張便利貼。你把一些事實貼進系統提示詞（system prompt）—— 模型記住了你喜歡用條列式呈現，還有你的貓叫做手套 —— 然後就覺得搞定了。這在你只有大約 20 件事情需要記住之前都還行得通，超過之後上下文視窗（context window）就開始自我吞噬，agent 變得比一開始更笨。

這個流程的核心轉變很簡單但影響深遠：

記憶體不是一個功能。記憶體是基礎設施。

如果你把它當成一個開關（「我們會記住你的對話」），你得到的是一張便利貼。如果你把它視為一個分層架構 —— 身份、事實、流程、封存、壓縮、排程和擴展介面 —— 你得到的是一個會隨著你成長的系統。差別在於：「我知道你喜歡什麼」和「我知道你怎麼工作」之間的差距。

以下是一個真實 Hermes 架設案例的剖析，它一層一層地成長為一個更接近本地上下文作業系統的東西。

如何審計你自己的記憶體

在複製任何人的架構之前，先審計你實際擁有的東西。關鍵在於拒絕模糊的回答。一個客氣的 agent 會總結；一個徹底的 agent 會給你收據。用明確的約束逼它：

不要猜測，不要假設。只看本地檔案、設定檔、資料庫、指令輸出、程式碼路徑和證據。不要概括。把檔案、位元組數、哪些是活躍的、哪些是閒置的、哪些壞掉的，全部列出來。

第一輪通常太溫和了。再推一次，直到你得到一份結構化的、按介面分類的清單，而不是一個友好的概述。目標是得到每一個記憶介面的誠實地圖 —— 包括那些你從未完成接線的、只是看起來很美好的骨架。

11 層架構

記憶架構不是一個單一的東西。在這個架設方案中，它至少有 11 個不同的層級，每一層有特定的功能，以及在被用於錯誤目的時的特定失敗模式。

第 1 層 — SOUL.md：身份檔案

位於 ~/.hermes/SOUL.md，這是 agent 的操作身份：個性、角色定義、委派規則、品質標準和語氣。大約 15KB 的 markdown，內容像是要直接、要有主見、積極委派、驗證聲明後再信任、在我含糊時要反推、不要像 LinkedIn 網紅那樣寫作。 沒有它，Hermes 仍然能運作，但聽起來像一個泛用的企业助理。這是整個架構中你絕對不會刪除的檔案。

第 2 層 — MEMORY.md 和 USER.md：永遠載入的上下文

這些檔案位於 ~/.hermes/memories/，在每一次對話輪次中都會載入。

• MEMORY.md — 筆記本。環境事實、工具特性、專案慣例和持久的教訓（例如 「Hermes 的 cron 表達式是在 America/Chicago 時區解讀的，不是 UTC —— 務必用 hermes_time.now() 驗證。」）。上限約 3,500 字元；較舊的條目會被壓縮或淘汰。
• USER.md — 使用者檔案。寵物、內容策略、偏好的審查介面和執行偏好。上限約 2,500 字元。

關鍵設計決策：這些檔案刻意保持小巧。它們是暖快取（warm cache），而不是整個大腦。提示詞空間很昂貴 —— 如果這層太大了，你就做錯了。

第 3 層 — 全像記憶體（fact_store）：結構化事實

一個由 SQLite 支援的儲存區，位於 ~/.hermes/memory_store.db，保存離散的聲明而非段落 —— 支援實體解析（entity resolution）、信任評分（trust scoring）和組合式查詢。像是「Tony 偏好 Codex 而不是 Claude」或「專案 hermes-vault 使用 MCP 協定」這樣可以查詢的小原子。

「全像」部分指的是 HRR 風格（全像縮減表示法，holographic reduced representation）的組合式推理 —— 跨實體查詢以找到重疊的事實。誠實的 caveat：這層很容易處於降級狀態。如果缺少像 NumPy 這樣的依賴，組合式查詢路徑會退回到普通關聯模式，而未經訓練的信任評分全部停留在 0.5 的預設值。架構在那裡；但優化通常沒有。

第 4 層 — 對話資料庫和 session_search：封存區

位於 ~/.hermes/state.db，這是一個追蹤每次對話的資料庫 —— 在這個架設方案中，1,047 個對話和 48,422 則訊息，橫跨 cron 工作、Telegram 私訊、CLI 和 TUI 對話。原始收據以 JSONL 檔案的形式存放在 ~/.hermes/transcripts/（約 475 MB）。

資料庫不會把這些內容塞進提示詞。它透過 session_search 搜尋 —— 問一句「三週前 Kiln 促銷流程我們做了什麼？」它就會找出相關對話並總結。儲存 48,000 則訊息不是重點；重點是知道哪些部分是活躍的、可搜尋的、過時的，或刻意排除在提示詞之外的。

第 5 層 — LCM：上下文壓縮

長上下文管理（Long Context Management，~/.hermes/lcm.db）在對話過長時，將較舊的輪次壓縮為階層式摘要節點，在保留語義內容的同時回收上下文視窗空間。它還會將大型負載（大量工具輸出、長檔案讀取）外部化，以保持主上下文的精簡。

這是當前對話的生存工具，而不是長期記憶。把 LCM 誤認為跨週的連續性，就像把工作記憶（working memory）和你的筆記應用程式搞混一樣。

第 6 層 — 技能（Skills）：程序性記憶

技能將「我對你的了解」轉化為「我如何執行你的工作流程」。每個技能都是一個帶有 YAML frontmatter 的 markdown 檔案 —— 一個針對特定任務的獨立操作流程（發布 Google Doc、執行 X 工作流程、智慧家庭控制）。一個成熟的架設可以安裝 250+ 個技能。

重要的區別：「Tony 使用 pytest」是一個事實（第 3 層）。「按這些精確的參數和順序執行 pytest」是一個技能。技能是將一個會聊天的助理轉化為一個操作者的關鍵。

第 7 層 — 專案本地上下文檔案

當 Hermes 進入一個專案目錄時，它會自動載入上下文而不污染全域記憶：

• AGENTS.md — 專案級的 agent 行為規則
• .hermes.md — Hermes 專屬的專案設定
• CLAUDE.md / .cursorrules — 更廣泛的 agent 慣例
• SOUL.md — 工作區層級的身份覆蓋

這就像是走進一個工作室，你的工具就放在你上次放的位置。不需要全域記憶。

第 8 層 — Nexus：第二個大腦

一個本地知識庫（~/nexus/，約 11 MB），包含 wiki、筆記、日誌、計畫和摘要。它不會自動注入 —— 11 MB 會摧毀任何上下文視窗。取而代之的是，工作流程會存取它：一個技能載入 wiki，一個 cron 工作從摘要資料夾拉取，一個研究任務查詢原始筆記。Nexus 是圖書館；MEMORY.md 是筆記本；session_search 是封存區；技能是標準操作流程（SOP）。不同的檢索模式用於不同的目的。

第 9 層 — 自我改進檔案：事後學習

~/self-improving/ 以分層方式儲存從修正、失敗和成功模式中學到的教訓：

• memory.md — 熱層，永遠載入，上限 100 行
• projects/ 和 domains/ — 暖層，按上下文匹配載入
• archive/ — 冷層，已衰減的模式

誠實的 caveat：從 agent 的角度來看，這些通常是只寫不讀的。自動升級/降級和排程清理很容易被擱置 —— 架構支持它，但手動寫入不一定會發生。

第 10 層 — Cron 工作：排程上下文循環

排程任務建立並消耗上下文，而不是儲存它。每日規劃工作產生結構化的摘要；Git 清潔工作每晚自動提交未提交的內容；內容雷達工作將新聞轉化為靈感。每個工作都從記憶體（偏好、專案狀態、Nexus）中讀取，並寫回（新的上下文、產物、對話紀錄）。Cron 工作是循環系統 —— 沒有它，大腦就只是泡在瓶子裡。

第 11 層 — Hooks、外掛和 MCP：擴展介面

架構不是封閉的。Hooks 在事件觸發時執行（對話開始、工具呼叫、輸出產生）。外掛注入新的工具和記憶介面。MCP 伺服器將外部上下文 —— 資料庫、API、知識庫 —— 暴露為可查詢的端點。這些是擴展埠：要讓 Hermes 記住一個 Notion 工作區，你只需將一個 MCP 伺服器指向它，而不是重寫記憶系統。

真正重要的區別

這是多數「AI 記憶體」內容崩潰的地方。記憶體不是一個有開關的功能 —— 它是一個堆疊，把錯誤的層用在錯誤的工作上，比沒有記憶體更糟。

反覆出現的主題：更多記憶體並非自動更好。 過時的事實、錯誤的偏好和過時的流程只會讓 agent 變差。記住一切是個糟糕的設計。真正的超能力是知道該記住什麼、放在哪裡、什麼時候載入，以及什麼時候讓它衰減。

這套架構實際帶給你什麼

架構就位後，日常效益是具體的：

• 你不用一直重複說明。 環境、專案、工作流程和偏好都已經被記住了 —— 不用再解釋 cron 是在芝加哥時區運行的。
• 它搜尋舊對話而不是膨脹提示詞。 過去的臭蟲和決策可以按需檢索。
• 它透過技能載入流程。 「在 articles 資料夾中發布這份 Google Doc」會遵循記錄好的流程，而不是瞎猜。
• 它在專案目錄內使用專案規則。 專案之間的上下文切換是自動的。
• 它執行排程任務。 每日規劃、Git 清潔和靈感雷達在不需要提示的情況下自行運行。
• 它在沒有一大坨提示詞的情況下建立連續性。 每一層處理自己的那一塊；agent 在各層之間導航。

誠實的 caveat

沒有任何架設是完美的，假裝完美只會暴露這是示範而不是日常使用：

• 全像信任評分可能未經訓練 —— 每個事實都停留在 0.5 的預設值，沒有關於可靠性的訊號。
• HRR 組合式推理在依賴（例如 NumPy）缺失時退化為關聯式退路。
• 部分自我改進檔案只有手動寫入；心跳（heartbeat）骨架可能存在但沒有訊號餵入。
• 大型對話封存是收據抽屜，而不是索引圖書館 —— 大部分永遠不會被查詢。
• 「agent 知道什麼」和「agent 能找到什麼」之間的界線仍然模糊。

這是架構與優化的差別。架構是穩固的。優化 —— 訓練信任評分、安裝缺失的依賴、接線心跳機制、清理過時資料 —— 是那些容易被拖延的無聊工作。

為什麼這很重要

業界把「持久記憶體」當成一個已打勾的完成項。它不是。把記憶體當成功能，你得到的是便利貼。把它當成分層基礎設施，你得到的是一個會隨你成長的系統：每一層處理自己的那一塊，agent 在各層之間導航，上下文在系統中流動，而不是聚集在一坨巨大的提示詞裡。

一個是便利貼。另一個是上下文作業系統。