一種新的 AI 工具類別正在悄然成形：不是存在於你開關的聊天視窗中，而是持續在雲端運行、透過訊息應用與你通訊的 Agent——像一個永遠不下線的同事。Hermes 是這個概念最有趣的實作之一，而它的差異化優勢在於內建的自我改進迴圈：一個觀察你的對話、提取有用的模式、並將它們轉化為自身記憶和技能套件永久升級的系統。
本指南帶你了解 Hermes 的架構、如何設定它，以及那個自我改進迴圈在底層如何運作。
Hermes 是什麼，以及它如何與眾不同
Hermes 是一個雲端常駐的 AI Agent：它 24/7 運行，你透過訊息應用與它互動，而非終端機或瀏覽器分頁。與類似的常駐 Agent 相比，有三個顯著差異：
- 更大的內建技能庫，讓你花更少時間自己串接整合。
- 簡化的設定流程 — 引導式 TUI 處理幾乎所有事情。
- 持續的自我改進 — 它不只是執行任務，還會累積關於如何更好地完成任務的程序性知識。
安裝與初始設定
讓 Hermes 運行只需一行指令。
在 Windows（PowerShell）上：
iex (irm https://hermes-agent.nousresearch.com/install.ps1)
在 Linux、macOS 或 WSL 上：
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
安裝後，重新啟動終端並執行 hermes setup 來啟動引導式配置流程，依序引導你完成模型選擇、終端後端、訊息閘道和工具設定。
選擇和路由模型
第一個真正的決定是哪個 LLM 提供者驅動 Agent 的「大腦」。驗證透過 OAuth 而非原始 API 金鑰——你甚至可以透過現有的 Claude Code 或 Codex CLI 會話登入，而不需要生成單獨的金鑰。
真正設計精良的是 Hermes 如何將你主要對話使用的模型與背景和輔助任務使用的模型分離開來。預設情況下同一個模型處理兩者，但每個輔助任務可以獨立指向不同的提供者：
| 任務 | 功能 |
|---|---|
vision | 圖片分析與描述 |
web_extract | 摘要長網頁 |
compression | 壓縮溢出的對話上下文 |
title_generation | 生成對話標題 |
curator | 自我改進迴圈背後的背景 Agent |
kanban_decomposer | 在 Kanban 模式中將大型任務拆解為子任務 |
goal_judge | 檢查 /goal 是否已實際達成 |
這在 config.yaml 中直接配置：
# 用於聊天和複雜推理的主要模型
model:
provider: "anthropic"
default: "claude-4-8-sonnet"
auxiliary:
vision:
provider: "gemini"
model: "gemini-2.5-flash"
compression:
provider: "custom"
base_url: "http://localhost:11434/v1"
api_key: "none"
model: "qwen2.5:32b"
明確的路由解決了使用 OpenRouter 作為預設時的一個真實問題：相同的名義模型通常由許多提供者以不同的量化方式部署，請求會在它們之間被悄悄地重新導向。在單個會話中，你最終可能在與一組輪替的不同配置實例對話，其中一些在處理工具呼叫和提示模板時比其他的更可靠。在 Hermes 內部手動路由完全避免了這個問題。
值得注意的是，為了在不犧牲編碼品質的情況下節省對話模型的費用，Hermes 支援 /claude_code 和 /codex 指令，將編碼任務直接委派給這些 CLI 工具，而不是用已配置的聊天模型處理。
終端後端
架構的核心部分是終端後端環境，它決定 shell 指令和 Python 腳本在哪裡以及如何執行，以及 Agent 如何接觸你的檔案系統。Hermes 支援五種：
- Local（預設） — 指令直接以你的使用者權限在你的機器上執行，沒有隔離。適合本地開發和受信任的個人使用。安全性依賴內建的核准系統，它會攔截破壞性指令（
rm -rf /、DROP TABLE）並先要求許可。 - Docker — 在隔離的沙箱中運行 Agent，使其無法接觸你的主機系統。
- SSH — 在遠端伺服器上執行指令和處理檔案。
- Modal — 在無伺服器雲端沙箱中運行所有內容，只為你程式碼運行的秒數付費。
- Daytona — 專為 AI 編碼 Agent 建造的容器管理層；比直接運行 Docker 更快，自動處理環境設定和依賴安裝。
對於大多數個人使用場景，Local 真的足夠了——其他的只有在你運行不受信任的程式碼或以團隊規模運作時才重要。
訊息閘道和工具設定
設定完終端後端後，設定會移動到你實際與 Agent 對話的地方——Telegram 是最精緻的選項。選擇它後你會得到一個直接連結，啟動一個預配置的 bot，不需要手動設定 bot token。
設定的其餘部分引導你啟用各個工具和提供者——瀏覽器自動化、圖片生成、文字轉語音和網頁搜尋。對於網頁搜尋，自架的 Firecrawl 或 Exa 因面向 Agent 的爬蟲和擷取能力而特別突出。注意 X 搜尋需要 Grok 訂閱才能啟用。
值得了解的斜線指令
大多數指令從名稱就一目瞭然，但有幾個值得特別說明：
/background <prompt>— 在背景執行任務，不中斷你的主會話。/goal— 設定一個 Agent 持續朝其努力的長期目標（有 pause/resume/clear/status 子指令）；/subgoal管理嵌套在下方的較小目標。/kanban— 協調多個獨立 Agent 之間的非同步長時間工作，透過 to-do、in-progress 和 done 分配任務池。/github_pr_workflow— 處理從分支到合併的完整週期，包括 CI；/github_code_review審查 PR；/codebase_inspection分析儲存庫的語言分佈和行數。/dogfood— 專用的 QA 模式，在 Web 應用中搜尋 bug 並產生有證據支持的報告。/spike— 執行快速的、一次性的實驗來驗證想法；/systematic_debugging以四個階段處理 bug，在嘗試修復前找出根本原因。
還有一群整合專用指令——/notion、/obsidian、/airtable、/google_workspace、/arxiv、/blogwatcher、/polymarket、/ocr_and_documents、/youtube_content——加上 /bundles，透過小型 YAML 設定檔將多個技能組合在一個斜線指令下。
Cron 任務和 Webhooks
兩個自動化基礎元件值得注意：
- Cron 任務 排程腳本在計時器上運行。傳入
--no-agent會執行純 Python 或 bash 腳本並將其輸出轉發到你的訊息應用，不消耗任何 LLM token。 - Webhooks 讓 Agent 回應外部事件而非計時器。你可以設定一個 webhook，讓新的 GitHub PR 自動觸發一個帶有特定提示和技能套件的 Agent——實際上就是零人工介入的值班審查 Agent。
上下文引擎
上下文引擎控制 Hermes 在接近模型 token 限制時如何壓縮和管理對話歷史：
- Compressor（預設） — 對長對話的中間部分應用有損摘要。
- LCM（無損上下文管理） — 不是文字摘要，而是建立對話關鍵點的有向無環圖，讓 Agent 從高層壓縮視圖導航到支持它的具體原始訊息。
記憶引擎
外部記憶提供者與 Hermes 的內建本地記憶檔案（MEMORY.md 和 USER.md）並行運行，新增語義搜尋和知識圖譜。幾個可以直接透過設定 TUI 配置：
| 引擎 | 方式 |
|---|---|
| Honcho | 透過背景 LLM 呼叫建立詳細的使用者檔案，分為基礎層（會話摘要/檔案）和辯證層（當前需求）。 |
| OpenViking | 建立檔案系統式知識層級的上下文資料庫，帶有分層檢索，在每個會話結束時將事實分為六個類別。 |
| Mem0 | 全託管的雲端記憶；伺服器端事實提取、語義搜尋、重新排序和去重（唯一有持續費用的選項）。 |
| Hindsight | 基於知識圖譜的 GraphRAG 式長期記憶；提取實體、建立關係、保留完整回合、分為事實/經驗/意見/觀察。 |
| Holographic | 本地 SQLite 事實儲存、信任評分、用於組合查詢的全息降維表示、自動矛盾偵測。 |
| RetainDB | 用於團隊記憶的雲端 API；混合向量 + BM25 + 重新排序搜尋、七種記憶類型、增量壓縮。 |
| ByteRover | 透過 CLI 的可攜式本地記憶；階層式知識樹，在有損壓縮丟棄前提取事實。 |
| Supermemory | 帶有圖譜 API 的語義長期記憶；擷取完整會話日誌、定期清理已回憶的事實、按 Agent 設定檔隔離記憶。 |
對於日常使用，預設的本地記憶對大多數人來說真的足夠——更重量級的系統以真實的資源成本（特別是本地選項的 RAM）換取大多數工作流還不需要的能力。
自我改進迴圈
這是 Hermes 最與眾不同的功能：一組非同步背景程序，持續分析你的對話、提取有用的模式、將它們寫入長期記憶和程序記憶（技能），然後維護這些知識使其不會退化。系統與你的主聊天並行運行，由三個組件構成。
觸發系統
Hermes 不會即時分析每則訊息。兩個計數器在超過閾值時觸發反思：
- 記憶觸發器 每十個使用者提示觸發一次，檢查是否有值得保存的新事實出現。
- 技能觸發器 在單個回合內每十個工具呼叫迭代觸發一次——理論是如果 Agent 剛花了那麼多步驟在解決一個問題，那段經驗值得分析並可能轉化為可重用的技能。
一旦任一計數器達到限制，內部函數會將當前對話的快照交給背景審查程序。
背景審查 Agent
這個快照送到一個完全獨立的、隔離的 Agent 程序，在背景並行運行，不中斷你的主會話。它在兩個方向上運作：
- 陳述性 — 如果它注意到新的使用者偏好或環境細節（對 Supabase 的偏好、專案指定 Python 3.12），它會更新
MEMORY.md或USER.md。 - 程序性 — 如果它偵測到 Agent 剛解決了一個非平凡的問題，它可以建立新技能、編輯現有技能、套用針對性修補程式或刪除技能。它建立的任何技能都會明確標記為 Agent 生成的，所以其出處永遠可追溯。
為了讓管理者稍後判斷哪些自行生成的技能值得保留，Hermes 維護了一個隱藏的使用日誌，追蹤每個技能的：被載入到提示中的次數、被打開閱讀的次數、被編輯的次數，以及建立、上次使用和上次編輯的時間戳。
管理者
如果不受控制，這個程序可能產生數百個技能，有些是多餘的或過時的。管理者防止知識庫退化。它只在兩個條件同時成立時啟動：距上次運行已過夠長的時間（預設七天），以及主 Agent 已閒置夠久（預設兩小時），不會因重量級的維護流程而干擾活躍的工作。在進行任何變更之前，它會自動備份整個技能目錄，讓任何不滿意的結果都能用一行指令回滾。
管理者的工作分為兩個階段：
- 機械式（無 LLM 呼叫） — 它檢查使用指標，將超過 30 天未使用的 Agent 生成技能標記為棄用，將超過 90 天未使用的移到歸檔目錄。重要技能可以明確釘選以保護它們。
- LLM 審查 — 透過一個獨立的隔離 Agent 實例執行，使用為管理者任務配置的模型。對於每個技能，它決定保持原狀、修復、與另一個涵蓋相同領域的技能合併（重新定位相關的腳本/評估/參考並重寫相對路徑），或歸檔。最後它產生一份詳細報告，包括顯示舊技能名稱如何映射到新名稱的重新命名對映表，讓每個決定都可審計。
對於管理者使用的模型，值得謹慎選擇不要太便宜，因為這些決策的品質對技能庫有實際的下游影響。
好好使用 Hermes
像這樣的雲端 Agent 對於任何可以 24/7 運行的流程來說真的很有價值——編碼工作是顯著的例外——前提是你已仔細地將該流程數位化，並圍繞它建立了扎實的技能，包括評估。一個傾向於產生好結果的工作流：
- 錄下你自己從頭到尾走過流程的過程，最好用口述以便準確捕捉。只有當你真正理解這個流程時才有效。
- 起草第一個技能，將這些筆記餵給帶有技能建立工具的編碼 Agent。它還不夠好以供委託。
- 建入評估 — 代表正確結果的參考解答 — 因為它們讓你衡量技能是否表現良好，而不是猜測。
- 測試和完善 評估和技能內容，根據你的觀察，大部分手工編輯。
- 只有在技能表現一致且確定時才委託。如果流程依賴外部服務，在建立之前先檢查現有的 MCP 伺服器或 CLI 是否已經涵蓋了它。
你可以委託給像這樣的 Agent 的範圍，主要取決於你指定工作的能力，而不是 Agent 的原始能力。三個原則在所有使用場景中都成立：不要將編碼工作委託給無人看守的 24/7 雲端 Agent，保持人類在迴圈中審查 Agent 的產出，並將技能完善視為持續的工作而非一次性完成就可以放手的事情。