Terry Yao's Blog

[ai/18] Hermes Agent vs OpenClaw：兩個開源 AI 助理框架的實戰比較

閱讀時間約 7 分鐘

cover

一個是剛出爐的新框架，一個是我跑了半年的老戰友。到底該不該換？

先講結論

Hermes Agent 在記憶系統和 Skill 生態上明顯領先，OpenClaw 在穩定性和 Windows 支援上更成熟。如果你目前沒有在用任何 Agent 框架，Hermes 是更好的起點；如果已經在跑 OpenClaw，不急著遷移，等 Hermes 穩定一點再說。

背景：為什麼要比較？

2026 年 4 月，Nous Research 發布了 Hermes Agent v0.8.0，主打「會自我改進的 AI 助理」。它內建了從 OpenClaw 遷移的工具（hermes claw migrate），擺明了要搶用戶。

我用 OpenClaw 搭了一套 multi-agent 系統（代號 ClawdBot），跑了半年，包含三個 Agent（main/ops/content）、Discord 整合、Cron 排程、Chrome CDP 自動化。所以這篇不是理論比較，而是一個實際用戶的視角。

架構比較

面向Hermes AgentOpenClaw (ClawdBot)
版本v0.8.0（2026-04 剛發布）穩定版（2026.1.30）
授權MIT自有授權
安裝curl 一行裝（Linux/macOS/WSL2）pnpm 安裝
Windows需 WSL2，無原生支援原生支援
Gateway內建統一 gatewayport 18789 自建 gateway
多 Agent支援但文件較少明確的 agent 分工架構

我的觀察

OpenClaw 的 Windows 原生支援對我很重要——我的開發機是 Windows 11，跑 Docker Desktop + Chrome CDP + VS Code，不想再多一層 WSL2 的複雜度。Hermes 強制要 WSL2 這點在 Windows 環境是明確的劣勢。

記憶系統：最大的差距

這是 Hermes 最強的地方。

Hermes 的四層記憶

  1. Episodic Memory：每次任務完成後自動寫入結構化日誌（工具使用、參數、成敗、耗時）
  2. Retrieval & Pattern Matching：遇到類似任務時自動檢索歷史經驗
  3. Skill Abstraction：同一模式成功 3 次以上，自動抽象成可重用的 Skill 檔案
  4. User Modeling（Honcho）：跨 session 持續理解你的工作風格和偏好

儲存用 FTS5 全文搜索 + LLM 摘要，可以查「上週我們討論了什麼 API 設計決策？」

OpenClaw 的記憶

  • Session-based：單次對話的 context window
  • MEMORY.md：手動維護的長期記憶檔案
  • Session 清空：需要定期 echo '{}' > sessions.json 避免 token bloat

實際差異

我在 OpenClaw 踩過最痛的坑就是 context 爆滿——Agent 累積到 166K tokens 後開始偷懶，每次 heartbeat 只回 HEARTBEAT_OK。解法是每天午夜自動重置 session。

Hermes 的 episodic memory 理論上解決了這個問題：它不是把所有東西塞進 context，而是寫入外部儲存，需要時才檢索。但這是 v0.8.0 的新功能，實際穩定性還需要時間驗證。

Skill 生態

面向HermesOpenClaw
標準agentskills.io 開放標準ClawHub 綁定
安裝hermes skills install openai/skills/k8s手動放入 skills 目錄
社群跨框架可移植僅限 OpenClaw 生態
自動生成3 次成功自動抽象無

OpenClaw 的 Skill 系統其實也很完整（我寫了 gemini-image-gen、disqus-monitor、tech-blog-weekly 等），但它是封閉生態。Hermes 用開放標準，理論上其他框架的 Skill 也能直接裝。

訊息平台與執行環境

平台支援

平台HermesOpenClaw
CLI✅✅
Discord✅✅
Telegram✅❌
Slack✅❌
WhatsApp✅❌
Signal✅❌
Email✅✅
Home Assistant✅❌

Hermes 的 8 平台統一 gateway 是明顯優勢。我的 ClawdBot 只用 Discord，如果要擴到 Telegram 或 Slack 需要自己接。

執行環境

Hermes 支援 6 種 backend（Local/Docker/SSH/Daytona/Singularity/Modal），後兩者支援 serverless，閒置時幾乎零成本。OpenClaw 基本上只有 local 執行。

LLM Provider 支援

面向HermesOpenClaw
Provider 數量16+（含 OpenRouter 200+ models）自定義 gateway routing
切換方式hermes model（互動式選擇）修改 config + 重啟 gateway
Claude 整合OAuth 直接用 Claude.ai 帳號需要手動管理 token

我在 OpenClaw 踩過 ChatGPT token 過期的坑——token 每隔幾天就要手動從 ChatGPT 網頁 console 撈 accessToken 再貼回來。Hermes 的 OAuth 流程看起來更乾淨。

遷移工具

Hermes 內建了從 OpenClaw 遷移的指令：

hermes claw migrate --dry-run      # 預覽變更
hermes claw migrate --preset user-data  # 只遷移使用者資料
hermes claw migrate --overwrite    # 覆蓋衝突項目

這代表 Nous Research 很清楚他們的目標用戶就是現有的 OpenClaw 使用者。

我的判斷

Hermes 的優勢

  • 記憶系統完勝（episodic + skill abstraction + user modeling）
  • 開放 Skill 標準，社群生態更大
  • 多平台支援（8 個 vs 2 個）
  • Serverless 執行選項（Modal/Singularity）

OpenClaw 的優勢

  • Windows 原生支援，不需要 WSL2
  • 穩定跑了半年以上，踩過的坑都修了
  • 我已經建好的 Skill、Cron、Discord 整合全部在上面
  • Gateway 自定義程度高

我的建議

現在不遷移。 原因：

  1. Hermes 是 v0.8.0，太新了。我不想把正在跑的生產系統搬到一個剛出爐的框架上
  2. 需要 WSL2 是個問題——我的 Docker Desktop 已經佔了 13 GB RAM，再開一個 WSL distro 資源更吃緊
  3. 我的 OpenClaw 已經穩定運作，cron 每天跑 5 次，Discord 整合正常

但我會做的事：

  • 在 WSL2 裝一個 Ubuntu，把 Hermes 跑起來當實驗環境
  • 測試 hermes claw migrate --dry-run 看遷移會動到什麼
  • 等 Hermes 到 v1.0 再認真評估

總結

你的狀況建議
還沒用任何 Agent 框架直接用 Hermes，起點更高
已經在用 OpenClaw 且穩定觀望，等 v1.0
想要多平台整合（Telegram/Slack）Hermes 明顯優勢
Windows 環境不想碰 WSL2留在 OpenClaw
重度依賴自動化 Skill兩邊都行，但 Hermes 的自動 skill 生成很吸引人

框架是工具，不是信仰。選能讓你現在穩定運作的那個。

關係圖譜