新型 AI 工具類別正在悄然成形：這些 Agent 不活在開啟關閉的聊天視窗中，而是持續在雲端運作，透過即時通訊軟體與你對話，就像是永遠不下班的同事。
Hermes 是這個概念中較有趣的實現之一，而它與 OpenClaw 這類 Agent 的關鍵差異，在於內建的自動改進迴圈——一個能觀察你的對話、從中提取有用模式，並將這些模式轉化為自身記憶與技能集永久升級的系統。
本文將介紹 Hermes 的架構、配置方式，以及這個自動改進迴圈在底層的實際運作機制。
什麼是 Hermes，它與 OpenClaw 有何不同
Hermes 是一個雲端 AI Agent，結構上與 OpenClaw 相似：它 24/7 全天候運作，你透過即時通訊軟體而非終端機或瀏覽器分頁與它互動。
兩者之間有意義的差異主要有三點。
首先，Hermes 出廠時內建了更龐大的技能庫，讓你花費較少時間在自行連接整合功能。
第二，安裝流程明顯更精簡——一個引導式 TUI 幾乎處理了所有步驟。
第三，也是最重要的，Hermes 以持續自我改進為核心設計：它不僅執行任務，還會隨著時間累積如何更好地執行這些任務的程序性知識。
安裝與初始設定
讓 Hermes 運作只需要一個指令。
在 Windows 上，請在 PowerShell 中執行：
iex (irm
在 Linux、macOS 或 WSL 上，對應的指令是：
curl -fsSL
安裝完成後，重新啟動終端機並執行 hermes setup，就會啟動引導式配置流程，依序引導你完成模型選擇、終端機後端、即時通訊閘道以及工具設定。
選擇與分配模型
設定中第一個實際決策，是選擇哪個 LLM 供應商作為 Agent 的「大腦」。驗證是透過 OAuth 而非原始 API 金鑰進行，這也延伸至你可以透過現有的 Claude Code 或 Codex CLI 工作階段登入，而無需產生單獨的 API 金鑰。
這裡真正設計良好的地方，在於 Hermes 如何將主要對話使用的模型，與背景及輔助任務使用的模型分開。預設情況下，兩個任務使用相同的模型，但每個輔助任務都可以獨立指向不同的供應商。
支援此類覆寫的任務包括：
- vision – 影像分析與描述
- web_extract – 摘要長網頁
- compression – 壓縮過長的對話上下文
- title_generation – 產生工作階段標題
- curator – 負責自我改進迴圈的背景 Agent
- kanban_decomposer – 在看板模式下將大型任務拆解為子任務
- goal_judge – 檢查
/goal是否確實達成的 Agent
這些設定直接在 config.yaml 中進行，例如：
1# 用於聊天與複雜推理的主要模型2model:3 provider: "anthropic"4 default: "claude-4-8-sonnet"5 auxiliary:6 vision:7 provider: "gemini"8 model: "gemini-2.5-flash"9 compression:10 provider: "custom"11 base_url: "http://localhost:11434/v1"12 api_key: "none"13 model: "qwen2.5:32b"
這種明確的路由分配解決了 OpenRouter 作為預設選擇時的實際問題：同一名義模型往往由許多不同供應商部署，且經常使用不同量化級別，而 OpenRouter 會靜默地將每個新請求隨機分配到約二十個供應商中的一個。
實際效果就是，在同一個工作階段中，你並不是在與一個一致的模型對話——你是在與一群配置各異的模型實例輪流對話，其中有些在處理工具呼叫和提示模板時比其他更可靠。在 Hermes 內手動路由完全避免了這個問題。
另外值得一提的是，如果你想在對話模型上節省費用而不犧牲編碼品質，Hermes 支援 /claude_code 和 /codex 指令，可將編碼任務直接委派給那些 CLI 工具，而不是用已設定的聊天模型來處理。
終端機後端
架構中的核心元件是終端機後端環境，它決定了 shell 指令和 Python 腳本在何處以及如何實際執行，以及 Agent 如何接觸你的檔案系統。Hermes 支援五種後端。
Local 是預設選項。指令直接在你的機器上以你的使用者帳號權限執行——沒有隔離。對於本機開發和受信任的個人用途，當你希望 Agent 編輯實際專案檔案時，這是正確的選擇。
這裡的安全性完全依賴於內建的核准系統，該系統會攔截破壞性指令（如 rm -rf /、DROP TABLE），並在執行前要求明確許可。
Docker 將 Agent 放在隔離的沙箱內執行，使其無法接觸主機系統。SSH 讓 Agent 透過遠端連線在遠端伺服器上執行指令並處理檔案。Modal 將所有工作放在無伺服器雲端沙箱中執行——你基本上是按秒租用運算資源，只為程式實際執行的秒數付費。
Daytona 是一個專為 AI 編碼 Agent 設計的容器管理層；它比直接執行 Docker 更快，並自動處理環境設定和依賴安裝。
對於大多數個人使用案例，Local 確實足夠——其他選項主要在你執行不受信任的程式碼或團隊規模操作時才有意義。
即時通訊閘道與工具設定
終端機後端之後，設定進入選擇你實際與 Agent 對話的地方——Telegram 是最完善的選項。選擇它會提供一個直接連結，啟動一個預先配置的機器人；不需要手動設定機器人權杖。
其餘設定流程引導你啟用個別工具及其對應的供應商——瀏覽器自動化、圖片生成、文字轉語音和網頁搜尋。針對網頁搜尋，自行架設的 Firecrawl 或 Exa 是適合 Agent 導向的網頁抓取和檢索的優秀選擇。
X 搜尋需要 Grok 訂閱才能啟用，這點在你去選單中尋找之前值得先知道。
值得了解的斜線指令
Hermes 內建了許多斜線指令，大部分從名稱就能理解，但其中有幾個特別值得提出來說明。
/background <prompt>在背景執行任務，不打斷你的主要工作階段。/goal設定一個長期目標，讓 Agent 持續朝其努力，並提供暫停、恢復、清除或檢查狀態的子指令；/subgoal管理活躍目標下的較小目標。/kanban協調跨多個獨立 Agent 的非同步、長期執行的工作——運作方式就像一個真實的看板，任務池會分配給 worker Agent，並在它們之間移交時經歷待辦、進行中和已完成狀態。
在開發方面，/github_pr_workflow 處理從分支到合併的完整週期，包括 CI；/github_code_review 審查 pull request；/codebase_inspection 分析儲存庫的語言分佈和行數。/dogfood 是一個專用的 QA 模式，用於尋找網頁應用程式中的錯誤並產出有證據支援的報告。/spike 執行一個快速、一次性的實驗，在投入完整開發前驗證想法；/systematic_debugging 分四個階段處理錯誤，在嘗試修復前先理解根本原因。
還有一組整合專用指令——/notion、/obsidian、/airtable、/google_workspace、/arxiv、/blogwatcher、/polymarket、/ocr_and_documents、/youtube_content——每個指令封裝一個特定的外部服務或工作流程；此外還有 /bundles，它透過小型 YAML 設定檔將多個現有技能分組到一個斜線指令下。
Cron 工作與 Webhook
兩個自動化原語特別值得注意。
- Cron 工作讓你可以排程腳本在定時器上執行；如果你在建立時傳入
-no-agent，Hermes 會執行純 Python 或 bash 腳本，並僅將輸出轉發到你的即時通訊軟體，完全不消耗任何 LLM Token。 - Webhook 則是更強大的功能：它們讓 Agent 對外部事件而非計時器做出反應。你可以配置一個 webhook，例如，當 GitHub 上出現新的 pull request 時，自動觸發一個帶有特定提示和技能的 Agent——這基本上等於設立了一個隨叫隨到的審查 Agent，每個 PR 都不需要手動介入。
上下文引擎
上下文引擎負責管理 Hermes 如何在對話接近模型 Token 限制時進行壓縮和管理歷史紀錄，有兩個選項。
- 預設選項稱為 Compressor，對長對話的中間部分進行有損摘要。
- 替代方案 LCM（無損上下文管理）則採用結構上不同的方法：不是生成文字摘要，而是建立對話關鍵點的有向無環圖，讓 Agent 可以從高度壓縮的概覽層級，向下導航到支持該概覽的具體原始訊息。
記憶引擎
外部記憶供應商與 Hermes 內建的本地記憶檔案 MEMORY.md 和 USER.md 並行運作，增加了語義搜尋和知識圖譜等功能。
其中有幾個可以透過設定 TUI 直接配置。
- Honcho 以建立詳細的使用者個人資料為核心，使用背景 LLM 呼叫來綜合兩個層面的觀察：基本層（工作階段摘要和個人資料）和辯證層（分析使用者當前需求）。
- OpenViking 是一個上下文資料庫，建立類似檔案系統的知識階層，支援層級上下文檢索，並在每個工作階段結束時自動將提取的事實分類到六個類別——事件、模式、偏好等。
- Mem0 是一個完全託管的雲端記憶服務；事實提取透過 LLM 在伺服器端進行，並包括語義搜尋、結果重新排序和自動去重，不過由於是雲端託管，它是此處唯一有持續費用的選項。
- Hindsight 是一個更先進的長期記憶系統，建立在知識圖譜上，採用 GraphRAG 風格。它從工作階段中提取實體，建立它們之間的關係，並保留完整的對話回合，包括工具呼叫，記憶分為四個類別：關於世界的事實、Agent 自身的經驗、意見和觀察。
- Holographic 是一個基於 SQLite 的本地事實儲存，無外部依賴，包括儲存事實的可信度評分系統，並使用全像縮減表示法來支援代數組合查詢，且能自動偵測知識庫中的矛盾。
- RetainDB 是一個用於團隊記憶的雲端 API，提供向量、BM25 和重新排序方法的混合搜尋，記憶分為七種不同類型，並使用增量壓縮保持儲存效率。
- ByteRover 是一個可攜式的本地記憶系統，透過 CLI 存取，建立階層知識樹，並在有損壓縮有機會將重要事實從上下文中刪除之前將其提取出來。
- Supermemory 提供具有圖譜 API 的語義長期記憶：它在對話結束後攝取完整的工作階段日誌來建立知識圖譜，定期清理已回憶的事實以避免當前回合的污染，並可以將記憶按 Agent 配置隔離到不同容器中。
對於日常使用，預設的本地記憶對大多數人來說確實足夠——更重的系統需要付出實際的資源成本（尤其是本地託管選項的 RAM），但換來的是大多數工作流程尚不需要的能力。
自動改進迴圈
這是 Hermes 與傳統 Agent 最顯著的區別：一組非同步背景程序持續分析你的對話，從中提取有用的模式，並將這些模式寫入長期記憶和程序性記憶（技能）——然後維護這些累積的知識，使其不會隨時間衰退。整個系統與你的主要聊天並行執行，由三個元件組成：觸發系統、背景審查 Agent 和審查員。
- 觸發系統
Hermes 不會即時分析每一則訊息，因為那樣只會無謂地消耗 Token。相反，它依賴兩個計數器，當它們超過閾值時觸發一次反思傳遞。
記憶觸發器每十次使用者提示觸發一次，檢查對話中是否出現了值得儲存的新事實。
技能觸發器每次單一回合中每十次工具呼叫迭代觸發一次，理由是：如果 Agent 花了那麼多步驟透過試錯來解決問題，那麼這個經歷就值得分析，並可能轉化為可重複使用的技能。
一旦任一計數器達到其限制，一個內部函數就會觸發，將當前對話的快照交給背景審查程序。
- 背景審查 Agent
此快照會交給一個完全獨立、隔離的 Agent 程序，在背景中並行執行，不會中斷你的主要工作階段。它從兩個方向運作。
- 在宣告式方面，如果注意到新的使用者偏好或環境細節——例如偏好 Supabase、專案鎖定 Python 3.12——它會更新
MEMORY.md或USER.md，取決於該事實屬於哪個檔案。 - 在程序性方面，如果偵測到 Agent 剛剛解決了一個非平凡問題或找出了一個複雜流程，它可以建立一個新技能、編輯現有技能、套用針對性修補，或直接刪除技能。它建立的任何技能都會被明確標記為 Agent 產生，因此其來源始終可追溯。
為了讓審查員最終判斷哪些自行產生的技能真正值得保留，Hermes 維護一個隱藏的使用日誌，追蹤每個技能：被載入到提示中的次數、Agent 開啟閱讀的次數、被編輯的次數，以及建立時間、最後使用時間和最後編輯時間的時間戳記。
- 審查員
如果不加控制，這個過程最終可能產生數百個技能，有些重複，有些過時。
審查員的存在是為了防止知識庫退化。它只在兩個條件同時滿足時啟動：距離上次執行足夠久的時間（預設為七天），以及主 Agent 已閒置足夠久的時間（預設為兩小時），這樣一次繁重的維護作業才不會干擾正在進行的工作。
在進行任何更改之前，它會自動備份整個技能目錄，因此任何不滿意的結果都可以透過一個終端機指令回滾。
審查員的工作分兩個階段：
- 第一階段純屬機械性，完全不涉及 LLM 呼叫：它檢查使用指標，將任何超過 30 天未使用的 Agent 產生技能標記為已棄用，並將超過 90 天未使用的任何技能移到封存資料夾。重要的技能可以被明確釘選以保護它們免受此過程影響。
- 第二階段是真正的 LLM 審查，透過一個單獨的隔離 Agent 實例執行，使用為審查員輔助任務配置的模型——預設與主要對話使用相同模型，不過可以指向更便宜的模型。在這裡，要小心不要選太便宜的模型，因為這些決策的品質會對技能庫產生實際的下游影響。
對於每個技能，審查員決定：
- 保持不變（如果仍準確且有用）
- 修復（如果包含錯誤或過時的方法）
- 與另一個涵蓋大致相同領域的技能合併（正確地重新定位相關的腳本、評估或參考檔案，並在過程中重寫相對路徑）
- 或直接封存
在週期結束時，它會產生一份詳細報告，包括一個重新命名映射，顯示舊技能名稱在合併後如何對應到新名稱，因此每個決策背後的理由都是完全可審計的。
善用 Hermes
這類雲端 Agent 對於任何可以 24/7 執行的流程都確實有價值——編碼工作是一個明顯的例外——前提是你已經仔細地將該流程數位化，並圍繞它建立了一個包含評估在內的堅實技能。
通常能產出良好結果的工作流程大致如下：
- 從頭到尾詳細記錄自己逐步執行該流程的過程，最好使用聽寫工具以確保準確記錄——而這個步驟只有在你真正理解該流程或已妥善研究過它時才有效。
- 將該錄音或筆記輸入一個編碼 Agent，使用技能建立工具產出初稿；此時的版本還不夠好到可以直接交接，特別是對於複雜的流程。
- 建立評估——代表正確結果的參考解決方案——因為它們讓你能實際衡量技能是否表現良好，而不是靠猜測。
- 在測試環境中執行該技能，並根據觀察結果改進評估和技能內容，大部分編輯工作應手動完成，而非委派出去。
- 只有在技能表現一致且確定後，才應將其交給持續在線的 Agent。如果流程依賴於某些外部服務，在從零開始建立之前，值得先檢查是否有現成的 MCP 伺服器或 CLI 已涵蓋該功能。
更廣泛的觀點是，你可以交給這類 Agent 的工作範圍，主要受限於你指定工作的能力，而非 Agent 的原始能力。
三個原則似乎在各種使用案例中都適用：不要將編碼工作外包給不受監管的 24/7 雲端 Agent；保留人類在循環中審查 Agent 實際產出的內容；將技能改進視為持續進行的工作，而非一次完成就撒手不管的事情。
如果這篇文章對你有幫助——請把它加入書籤。你會想回過頭來參考它。
想看更多類似的深度解析，請追蹤 @ScottyBeamIO
不廢話，只講真正有用的東西。
