2026 年 2 月起，Hermes Agent（Nous Research，MIT）在 GitHub 與 Hacker News 上迅速成為「自進化 Agent」話題中心。它與 Copilot 式補全或一次性 ChatGPT 對話的本質差異是：行程長期駐留、記憶跨工作階段累積、任務完成後自動把路徑寫成 Skill。你從 Telegram 發一則訊息，它在背景跑 shell、檢索網頁、改 Git 儲存庫——更像住在你基礎設施上的同事，而不是瀏覽器分頁。

這種定位立刻帶來硬體問題：Hermes 的 Closed Learning Loop 依賴 Gateway 守護行程、定時 cron 與 SQLite 工作階段索引持續運作。合蓋、斷電維護、偶發 OOM 重啟不會讓 ~/.hermes/skills/ 憑空消失，卻會讓「永遠在線的 Agent」名不副實。社群討論也從「模型夠不夠強」轉向「我該給 Agent 租一台什麼機器」——這正是本文要回應的搜尋意圖。

若你已讀過 30 天實測文，那是時間軸視角；本篇專注架構：各記憶層如何分工，以及為何「常駐」是設計的一部分而非事後維運。與 OpenClaw 常駐 一樣，重點是 launchd 級守護與可預期在線，而不是偶爾手動啟動；差異在 Hermes 明確把 Skill 沉澱與 Episodic 索引寫進產品敘事。

結論先行：Hermes 的價值隨時間複利，硬體選型的核心是讓行程與磁碟狀態持續在線。下面從記憶架構拆到具體機型。

官方與社群文件常把 Hermes 記憶概括為三層，對應從「單次對話」到「越用越懂我」的遞進：

第一層 — 短期工作階段上下文（Stateless 對話的反面）：目前 thread 內的訊息與工具呼叫結果，受 context window 限制。關閉行程或長時間閒置後，這一層不會完整保留在模型上下文裡，需要靠下層記憶補全。

第二層 — Skill Documents（程序性記憶）：複雜任務完成後，Closed Learning Loop 將解決路徑提煉為 ~/.hermes/skills/ 下的 Markdown Skill，下次類似任務以 progressive disclosure 載入，顯著降低 token 與失敗率。這是「越跑越快」的主要來源。

第三層 — 跨工作階段持久使用者模型：USER.md、MEMORY.md、SOUL.md 等 Core Memory 每工作階段注入；Episodic Memory 用 SQLite FTS5 索引歷史工作階段，支援「兩週後接著聊」式召回。三層疊加，才構成 Persistent Agent，而非無狀態 API 包裝。

curl -fsSL https://get.hermes-agent.org | bash
hermes gateway start
ls ~/.hermes/skills/
hermes memory search "deploy checklist"

底層可接 Nous Portal、OpenRouter 或本機 Ollama / llama.cpp / MLX；Skill 與記憶檔不鎖死在某一模型權重。但若 Gateway 每週只醒幾次，Episodic 層的時間連續性斷裂，你仍要手動 re-ground，Persistent 的體感大打折扣。

不少團隊把「記憶架構」誤解成「把 context 開到最大」。對 Hermes 而言，真正可複用的是程序性 Skill：第二次跑部署檢查清單應更省 token、更少工具重試。這要求第三層 SQLite 索引保持熱度，且 cron 能定期維護——再次指向 7×24 伺服器假設。

容量規劃可按層拆：Core 的 Markdown 體量小；Skill 隨成功任務累積；Episodic 的 SQLite 與輪替日誌是長期膨脹主因。僅用 OpenRouter 或 Nous Portal 做 API 編排時，16GB·256 常夠用；若並行本機 Hermes-3 或 MLX，建議 24GB·512，避免召回與推理在 Apple 統一記憶體池裡互搶。

高頻搜尋問句是「重啟會不會清空 Skill」。準確答案是：一般不會刪檔案，會傷執行態與節奏。

這與 OpenClaw Gateway 常駐 面臨的穩定性問題同構：Agent 被當成臨時腳本部署，而不是 7×24 服務。你要的是 launchd 級守護、健康探針與可預期在線視窗，而不是「檔案還在硬碟上」的自我安慰。可參考 健康探針文 套用到 Hermes 巡檢。

維運上建議：換機前先 tarball ~/.hermes/，在測試節點還原驗證，再切換 Telegram/Discord token。連續性既是行程在線，也是備份習慣。

搜尋常問「Skill 會不會不見」；更該問「凌晨三點 Telegram 還回不回、夜間文件同步跑不跑」。檔案在、Gateway 離線，等於富 Skill 的殭屍檔案庫——生產環境應把 Hermes 當常駐服務監控，而非想起才開的 CLI。

Hermes 官方支援 macOS，curl -fsSL https://get.hermes-agent.org | bash 一條指令完成依賴；本機推理可走 Metal 優化的 llama.cpp 或 MLX（見 Nous 文件 Run Local LLMs on Mac）。Mac Mini M4 在該場景下的優勢是結構性的：

統一記憶體（UMA）：16GB / 24GB 統一定址，Agent 執行時（通常 <2GB）疊加 13B 級本機模型仍有餘量；同價位 x86 小主機往往無 Metal 路徑。功耗與噪音：閒置約 10W 級，可 7×24 放機櫃旁。體積：不占工位，適合當「Agent 伺服器」。場景：開發者讓 Hermes 記住架構偏好維護文件；創作者沉澱選題 Skill；研究者把論文處理流程寫成可複用 Skill。

區域與租期見 六區選區指南；記憶體檔位見 儲存與記憶體選配。

Agent 若常改遠端 Git 儲存庫，主機上的 shell 延遲與 DNS 與模型能力同樣重要。獨佔 Mac Mini 放在 Git 遠端與 API 出口附近，可縮短多步工具鏈往返——對夜間發佈 Skill 的創作者尤其明顯。7×24 低噪音運轉也讓 Episodic 時間戳可信，避免「上週二我們定了什麼」出現空白。

自購 Mac Mini M4（以 24GB·512 檔為例）首付高、折舊與 M 系換代壓力自擔；月租把 CapEx 轉為可預算 OpEx，隨時升配、退租前自助擦除，適合「先驗證 Hermes 複利、再決定是否自購」的路徑。下表為決策示意（價格以 定價頁 為準）：

24 個月視角下，隱性成本是停機：Gateway 睡著的每一晚，Skill 複利與 Episodic 召回都在停擺。請把下方自購 vs 月租表與既有 VPS 報價並列做架構評審。KVMNODE 月租把大額首付換成固定月費，租期內可升 24GB 或調區域，退租前在實例內擦除 ~/.hermes/ 即可。

Episodic 若需定期壓縮，請在 Gateway 仍運行或短暫唯讀維護窗內操作，並把步驟寫進 runbook；Skill 與 Core 在小型實例上仍可長期累積，真正吃碟的是超長工作階段歷史。每日 hermes doctor 可參考 健康探針文 的 cron 寫法，避免頻道 token 過期後無人知曉。

可寫入團隊 Wiki：① Hermes Agent 2026 年 2 月 MIT 發布，GitHub 進入開源 Agent 話題前列（社群報導常引用數週內數萬 star 量級，以儲存庫即時為準）。② 預設記憶落在本機 ~/.hermes/，無遙測。③ 官方文件區分 Core / Procedural / Episodic 三層，程序性 Skill 複用對重複維運與內容流水線收益最大。

Quick pick：開發者——純 API 16GB 夠用，本機 Hermes-3 建議 24GB；創作者——穩定性重於峰值算力；研究者——SQLite 健康與磁碟別摳。三者共通點是：先確保 Gateway 全年無長時間離線，再談模型或頻寬優化；獨佔伺服器比共用 VPS 更利於 cron 與磁碟隔離。

攤開替代方案：筆電偶爾開機，三層記憶檔案在漲但 Gateway 時常離線；長期低價 VPS，省月費卻吃 Linux 相容與 RTT；自購 Mac Mini，CapEx 與換代自擔。在 KVMNODE 按月租獨佔 Mac Mini M4，讓 Hermes 的三層架構在 7×24 環境下持續複利：macOS 原生、固定 OpEx、~/.hermes/ 可遷移、退租可擦除——對要長期累積 Skill 的生產環境，通常比「湊合 VPS」更省心。

若同時評估 OpenClaw 等常駐 Gateway，決策順序相同：先保行程連續性，再優化模型成本。三層設計獎勵的是數月穩定上線，而非週末調參。建議先在靠近協作者的區域租 Mac Mini，一次性遷移 ~/.hermes/、綁定頻道，讓 Skill 沉澱後再決定自購。

企業使用者還應在內部文件註明：使用者偏好與對話摘要可能寫入 USER.md 與 Episodic 索引，SSH 存取需納入權限矩陣；退租前擦除 ~/.hermes/ 是標準步驟。架構評審通過後可直接走 訂購入口，其後依六步清單完成安裝與頻道綁定。檔位見 定價頁，網路與遠端操作見 幫助中心；選區可對照 六區指南。