Hermes Agent

資料來源#

• Tips & Best Practices
• Tutorial: Team Telegram Assistant

摘要#

Hermes Agent 是來自 Nous Research 的開源 CLI 程式設計／研究 agent，定位為 Claude Code 的平行生態系，但更強調跨多平台的訊息部署。CLI 提供一個具備工具存取能力的互動式 REPL（終端機、檔案編輯、網頁搜尋、程式碼執行）；Hermes Gateway 則是一個長時間執行的常駐程式，透過 Telegram、Discord、Slack 與 WhatsApp 把同一個 agent 暴露出來，具備每位使用者各自的工作階段、允許清單＋DM 配對授權、排程 cron 工作，以及可設定的容器後端。Hermes 是供應商無關的（可搭配 OpenAI、Anthropic 與其他 LLM API），並採用一套更接近 OpenAI 的 AGENTS.md、而非 Anthropic 的 CLAUDE.md 的情境檔慣例，另外還有一個獨立的 SOUL.md 用於人格設定。

細節#

Architecture (Two Surfaces)#

Gateway 是這兩個介面中架構上更有趣的一半——它在精神上與 Symphony 的 永遠在線常駐模型平行，但採用的是每位使用者而非每個 issue 的租用單位。

Context Files#

Hermes 使用三層分層的設定檔，並有明確的角色分離：

子目錄的 AGENTS.md 檔案是在工具呼叫期間惰性探索（透過 subdirectory_hints.py）並注入到工具結果中——它們不會預先載入。這是刻意的情境預算選擇：只有最上層的專案情境會進入系統提示；巢狀的情境只有在相關時才付出代價。

AGENTS.md（專案）與 SOUL.md（人格）的分離比 Anthropic 的 CLAUDE.md 慣例更為清晰，值得拿來比較——同樣的角色拆分在實務上隱含於 CLAUDE.md 檔案中，但並未另外分檔。（將在即將推出的 Agent Context Files 概念頁中展開。）

Memory System#

Hermes 實作了一套硬性有界的記憶系統：

• MEMORY.md：上限約 2,200 字元。
• USER.md：上限約 1,375 字元。
• 當記憶填滿時，agent 會整併條目（壓縮較舊的筆記）。

文件中特別點出一個陷阱：

「記憶是一份凍結的快照——在工作階段期間所做的變更，要到下一個工作階段開始時才會出現在系統提示中。agent 會立即寫入磁碟，但提示快取不會在工作階段中途失效。」

這是對「為什麼任何具快取機制的 agent 中記憶編輯會感覺『延遲』」最清晰的闡述——而且這是 Claude Code 與其他 agent 共有、卻很少被記錄下來的限制。

Memory 與 Skills 的拆分：

• Memory ＝ 事實（環境、偏好、專案位置）。
• Skills ＝ 程序（多步驟工作流程、可重複使用的食譜）。
• 「Memory 管什麼，skills 管怎麼做。」

Token-Economy Tooling#

直接面向使用者的控制項——在操作上，這些正是 AgentOpt 所形式化的那些槓桿，只是以 CLI 命令的形式暴露出來：

關於快取紀律的提醒很到位：

「大多數 LLM 供應商會快取系統提示的前綴。若你保持系統提示穩定（相同的情境檔、相同的記憶），工作階段中後續的訊息就能命中快取，成本顯著更低。避免在工作階段中途更換模型或系統提示。」

CLI Ergonomics#

Hermes Gateway: Multi-User Daemon Pattern#

Gateway 透過訊息平台暴露 agent：

• 每位使用者各自的工作階段——每位獲授權的使用者都有自己的對話情境。
• Home channel（/sethome）——指定用來接收 cron 輸出與主動訊息的聊天室。
• 兩種授權模型：

1. 靜態允許清單：在 .env 中設定 TELEGRAM_ALLOWED_USERS=123,456。新增使用者需重新啟動。
2. DM 配對：未獲授權的 DM 會收到一組一次性代碼；管理員執行 hermes pairing approve telegram XKGH5N7P。無須重新啟動。

• 配對安全性：代碼 1 小時後過期、採用密碼學隨機性、有速率限制（每位使用者每 10 分鐘 1 次請求，每平台最多 3 筆待處理）、5 次核准失敗 → 平台鎖定 1 小時、所有資料皆以 chmod 0600 儲存。

服務安裝：

hermes gateway install # Default: user-level systemd (Linux) / launchd (macOS)
sudo hermes gateway install --system # Linux: boot-time system service
sudo loginctl enable-linger $USER # Linux: keep running after SSH logout

Cron Jobs#

排程的工作會送達 home channel：

• 從聊天中建立：「每個工作日早上 9 點，檢查 GitHub 儲存庫是否有……」
• 定義儲存在 ~/.hermes/cron/jobs.json；輸出在 ~/.hermes/cron/output/{job_id}/{timestamp}.md。
• 關鍵注意事項：cron 提示是在完全全新、沒有記憶的工作階段中執行。每個提示都必須包含所有需要的情境——檔案路徑、URL、伺服器位址、指示。

這與 Symphony 的 常駐程式驅動的派發模型平行——兩者都是 agent 被拉去按排程非同步工作、而非以互動方式驅動的案例。

Container Safety Model (Worth Flagging)#

Hermes 支援多種終端機後端：

TERMINAL_BACKEND=docker
TERMINAL_DOCKER_IMAGE=hermes-sandbox:latest

支援：Docker、Singularity、Modal、Daytona。

重要的安全性轉變：當在容器後端中執行時，危險命令檢查會被略過——其理由是「容器才是安全邊界」。這意味著：

• 鎖定式容器映像的品質變成承重的關鍵。
• 核准提示 UX 換成了映像紀律 UX。
• 信任從「每個命令都會被審查」轉移到「容器無法逃逸」。

值得一提，因為這與 Claude Code 的逐命令 auto-mode 分類器是顯著不同的安全模型。

Comparison to Claude Code#

最重要的架構差異是 Gateway：Claude Code 以工作階段為先；Hermes 在團隊規模部署時則以常駐程式為先。

Operational Notes#

• VPS 規格：每月 $5 就足以支撐 Gateway 本身——LLM API 呼叫才是成本的驅動因素。
• macOS launchd PATH 陷阱：plist 會在安裝時擷取 shell 的 PATH。在安裝新工具（Node、ffmpeg）後，重新執行 hermes gateway install 以刷新。
• 工作階段自動重置：訊息工作階段在閒置（預設 24 小時）後或每天凌晨 4 點重置。
• 自我更新：從聊天中執行 /update 會拉取最新版本並重新啟動。

相關連結#

• Claude Code Best Practices —— Hermes 是最接近的平行生態系；許多概念可直接對應（/compress ↔ /compact、delegate_task ↔ 子 agent、AGENTS.md ↔ CLAUDE.md）；差異則凸顯了各自所做的設計選擇
• Symphony —— 兩者都是永遠在線的 agent 常駐程式；Symphony 的租用單位是 issue，Hermes 的租用單位是使用者。兩者都偏好以容器後端來確保安全。Cron ＋ home channel 與 Symphony 的輪詢 ＋ tracker 寫入平行
• Client-Side Agent Optimization —— Hermes 的 /model、/compress、delegate_task 與提示快取紀律，正是 AgentOpt 所形式化那些槓桿的使用者端表面
• Agent Harness Engineering —— AGENTS.md 遵循 OpenAI 的「目錄、而非百科全書」原則；有界記憶檔是與 JSON 功能清單類似的、harness 層級的限制
• Scale-Dependent Prompt Sensitivity —— /verbose 模式與有界記憶都隱含地限制了輸出長度；簡潔限制的研究發現會預測出收益
• Claude Code Auto Mode —— Hermes 的逐模式核准模型（once/session/always/deny）與容器停用核准的模型，都是與基於分類器的 auto mode 的比較點
• Agentic Misalignment (AM) —— Hermes 的常駐程式模式（長情境、使用工具、容器即安全邊界、每個動作的人類監督薄弱）正好落在 AM 的威脅面內；容器隔離降低了波及範圍，但並未解決模型端的失準問題
• Ticket-Driven Agent Orchestration —— Hermes 的 cron 工作 ＋ home channel 送達是一個較輕量的類比：自我派發的排程交付物，回報到聊天室而非工單

待解決的問題#

• 容器後端停用危險命令檢查是個站得住腳的設計，但卻是個有意義的安全模型轉變。其經驗上的實績如何？熱門映像（Daytona、nikolaik/python-nodejs）中的鎖定失敗是否曾造成事故？
• 有界記憶檔（MEMORY.md 約 2,200 字元）在長期使用下表現如何？文件提到了自動整併，但並未詳述——整併演算法是什麼，又有多大的損耗？
• Hermes 的 DM 配對流程是個乾淨俐落的安全原語。為什麼這個模式還沒被 Claude Code 或 Cursor 採用於共享／團隊部署？
• AGENTS.md（專案）與 SOUL.md（人格）之間的拆分在 Hermes 中是顯式的，但在 Claude Code 的 CLAUDE.md 中是隱式的。這個拆分是否實質改善了結果，抑或只是一個沒有經驗支持的文件化選擇？
• 在沒有記憶的全新工作階段中執行 cron 工作——團隊要如何在不讓每個 cron 提示膨脹的前提下，組織出「agent 需要的情境」？是否有標準模式？

資料來源#

• Tips & Best Practices — practical CLI usage, context files, memory, performance/cost levers, security patterns
• Tutorial: Team Telegram Assistant — Gateway deployment, BotFather setup, allowlists vs. DM pairing, cron scheduling, production operation