OpenClaw 與 Hermes 比較：記憶、技能、多 Agent 與訂閱生圖/影片

你一定也遇到過這種窘境：剛在 Docker 裡架好一個新的 AI Agent，想叫它幫你爬個資料或寫段測試，結果不是忘記上一輪對話聊了什麼，就是把你的 Token 刷爆；不然就是好不容易教它的技能，換個 Session 就忘得一乾二淨。為了解決這些痛點，OpenClaw 與 Hermes 這兩套 Agent 框架橫空出世，但它們解題的思路完全走在不同的軌道上。

OpenClaw 比較像一套「多 Agent 作業平台（Fleet Operating System）」。它把 Agent、Workspace、Gateway、Skills、Memory、Browser、Media Generation、Approval、Channel Integration 都包進一個大系統裡。你可以把它想成一個 Agent Fleet 的中央控制層：每個 Agent 有自己的身份、目錄、技能可見範圍、模型路由策略、記憶與媒體生成能力。

Hermes 則比較像一套「會自我累積的個人或團隊 Agent Workbench」。它強調 Persistent Memory、Session Search、技能自動沉澱、Profile、Cron Job、Subagent Delegation，以及透過 Provider / Tool Gateway 把搜尋、瀏覽、圖片、語音、影片接到同一個操作介面。它的賣點不是把所有 Agent 管成一個大型企業平台，而是讓單一 Agent 越用越懂你，並能把做過的工作變成可再次調用的技能。

在架構設計上，我的初步判斷是：

• 想要做多入口、複數 Agent 派發、多 Channel 整合（如 Telegram/Discord）、多權限與 Gateway 集中管理，選 OpenClaw 比較對題。
• 想要做個人研發助理、內容助理、需要長期記憶、技能提煉、定期任務（Cron）與快速可用的多 Agent 臨時分工，選 Hermes 比較順手。
• OpenClaw 的能力面雖然很寬，但因為前期迭代過於頻繁，開發者很容易陷入天天跟著修 bug 的維護地獄。
• Hermes 的產品線更加聚焦，技能與記憶屬於一等公民（First-class citizen），但如果要做企業級的 Agent Governance，就必須靠自己建立 CI/CD 規範與部署紀律。
• 關於訂閱式生圖與影片：OpenClaw 可以直接走 ChatGPT/Codex OAuth 與 xAI OAuth 通道；Hermes 則能走 Nous Subscription、OpenAI Codex 圖像後端與 xAI OAuth，兩者差別只在於設定入口與 Tool 啟用開關。

核心概念定義：我們在討論什麼？

在深入比較前，我們先把以下幾個經常被混淆的技術名詞定義清楚：

• 記憶機制：Agent 如何保存長期偏好、專案 Rule、過往決策、工作摘要，以及在下一次任務中如何召回（Recall）這些資訊。
• 技能提煉（Skill Extraction）：把一次成功的操作流程、Prompt、工具調用方式，沉澱成下次能直接重用的 SKILL.md 或類似能力模組。
• 多 Agent（Multi-Agent）：並非多開幾個對話視窗，而是能將複雜任務切細並派發給不同的 Agent，每個 Agent 擁有獨立的 Context、工具權限、工作目錄與模型 Configuration。
• Context 控制：決定哪些內容該進入 LLM 上下文，哪些該丟進向量庫搜尋，哪些應該截斷、壓縮或延後讀取，用來節省 Token 費用。
• Gateway (網關)：通常指多 Channel、多工具、多 Provider 的調用入口層，例如 Telegram、Slack、網頁瀏覽器、生圖或影片 API 的整合。

OpenClaw 早期「既要又要」帶來的維護地獄

OpenClaw 的架構方向並沒有錯，問題在於它在早期將戰線拉得太長。

從實際踩坑的經驗來看，它在初期就不斷把 Browser Session、Gateway、Docker 部署、Windows 支援、Memory Backend、Skills 權限控制、Mission Control 儀表板、Media Generation 等功能硬塞進同一套平台。功能快速膨脹的副作用非常明顯：你這週可能在修 Browser 的 Session 遺失問題，下週要處理 Gateway 的 timezone，再下週又要去修 xAI 影片生成的 API 變更。

這種高頻率的重構對開發者會造成兩種極端的感受。一邊是興奮於每次更新都有新功能可以接（例如 Live Chrome Session、Grok 訂閱整合），另一邊則是疲於奔命——你發現你不是在寫 Agent 應用，而是天天在維護一個不穩定的 Agent 平台，設定檔、Workspace 權限、Sandbox 環境隨時都會因為一次 Minor Update 而壞掉。

相較之下，Hermes 的變動就比較克制，重心幾乎都放在 Agent Runtime 本身：如何優化記憶、Session Search、Skills 提取、Cron 定期任務與 Subagent 的 Context 隔離。它更像是要把一個 Agent 的體驗打磨到極致，而不是急著把所有企業級平台功能一次鋪滿。

記憶機制對決：系統級治理 vs. 輕量化 Session 檢索

OpenClaw 的記憶設計是「Workspace 內的可治理知識層（Governance Knowledge Layer）」。

它在文件裡把記憶切成了這幾層：

• MEMORY.md：存放長期記憶、偏好、決策與重要工作摘要。
• memory/YYYY-MM-DD.md：每日工作日誌（Daily log），放當天觀察、任務進度與執行線索。
• DREAMS.md：可選的「夢境」整理機制，用來在背景非同步檢視哪些 Daily notes 值得晉升成長期記憶。
• memory_search 與 memory_get：透過語意搜尋（Vector Search）加關鍵字，精準讀取特定範圍的記憶檔案。
• 記憶後端（Memory Backends）：內建 SQLite、QMD、Honcho、LanceDB 等多種存儲路線。

這套設計的優點是極具治理性，你可以精準控制什麼資訊進 Prompt、甚至用 Wiki 結構管理知識。但缺點就是配置成本太高，對只想簡單紀錄對話的人來說，光是搞懂這套 Memory Pipeline 就要花上不少時間。

Hermes 則採用了「Bounded Memory 加上 Session Search」的務實路線。

它核心只管兩個 Markdown 檔案：

• MEMORY.md：Agent 的工作記憶，放環境變數、專案 Rules、踩坑紀錄。
• USER.md：使用者偏好，放語氣、開發習慣與溝通規則。

Hermes 會把這兩份檔案以 Frozen Snapshot 的形式直接注入到 Session 開頭，並用字數上限硬性控制 Prompt 成本。至於過往的歷史對話細節，Hermes 則是直接存進本地 SQLite，並透過 FTS5 做 Session Search 全文檢索。

這種做法非常符合開發者的日常體感：長期規則要小、要好改；歷史對話則需要時再去下關鍵字撈，不要把整坨 Chat History 都塞給 LLM 增加成本。

實務應用場景分析

根據兩者的架構特性，在選型上可以做如下劃分：

適合 OpenClaw 的場景：

• 需要多個不同角色的 Agent 長期在線協作（例如 Writer Agent、Researcher Agent、Ops Agent）。
• 需要把 Agent 整合進 Telegram、Slack、Discord 等複數通訊軟體中作為客服或自動化網關。
• 團隊需要對 Sandbox、API 呼叫進行審批（Approval）、並有多租戶 Workspace 隔離需求。
• 團隊有專職的 Ops 人員能維護這套複雜的 Agent 中控平台與 Mission Control 儀表板。

適合 Hermes 的場景：

• 作為個人的 Local 研發助理，需要它深度理解你的本地 Repo、Shell 工具鏈與個人寫 code 習慣。
• 需要跑定時任務（如每天早上 9 點自動爬取最新 AI 論文並整理成 Markdown 筆記）。
• 希望 Agent 能在跑完一次長任務後，自動把成功經驗提煉成 Skill 檔以供下次使用。
• 需要頻繁開 Subagent 去做平行除錯、跑對比測試，且不希望污染當前主對話的 Context。

技能提煉（Skills Hub）：如何把成功經驗沉澱下來？

OpenClaw 與 Hermes 都支援 Skill，但兩邊的心智模型完全不同。

OpenClaw 的 Skill 是「權限管控的模組」。它有 Global Skill Roots、Workspace Skills、Agent Allowlist 等設定。這對平台管理很方便，你可以透過設定檔明確限制 Writer Agent 不能去 call 執行 Shell 命令的 Skill。但它的缺點是缺乏自動提煉的閉環，要把一次成功的 Debug 軌跡包裝成可複用的 Skill，仍然需要開發者自己動手寫程式碼或寫提示詞文件。

Hermes 則把 Skill 視為 Agent 的「程序記憶（Procedural Memory）」。它強調 Agent 能在執行任務的過程中「自我改進」，將成功的工作流自動沉澱為 Skills Hub 裡的 Markdown 技能檔，甚至能直接與其他 Hermes 實例共享。在這種自動化 Skill Loop 的優化上，Hermes 的體驗明顯流暢許多。

複數 Agent 協作：長期分工 Fleet 還是臨時組隊 Delegation？

OpenClaw 走的是「Agent Fleet（艦隊）」思維。

它把每個 Agent 視為一個獨立的運行單元，擁有自己的身份、Workspace 目錄、模型路由與 Runtime Policy。你可以用 agents.defaults 建立全域基礎設定，再在 agents.list[] 裡做 individual override。這很適合拿來做長期運作的流水線分工。

Hermes 則走「Delegation（委派）」思維。

主 Agent 在收到複雜任務時，會透過 delegate_task 臨時生成 Child Agents。每個 Subagent 擁有獨立的 Conversation 與 Terminal Session，而且只能拿到 Parent 傳進去的 Goal 與特定 Context。Subagent 中間產生的所有 Tool calls 與碎碎念都不會塞回 Parent 的 Context 中，最後只把 Summary 回傳。

這在跑複雜 Debug 或進行多方案對照時非常實用，能有效防止 Context 被中間產生的垃圾訊息塞滿。

設定檔大不同：平台治理 vs. 工作台隨切

OpenClaw 的配置重心在於「Agent 身份與 Workspace 治理」。你需要去宣告每個 Agent 的 ID、對應的獨立 Folder、繼承的基線、可見技能清單以及 API Gateway 路由。這更偏向平台工程（Platform Engineering）的範疇。

Hermes 的配置重心則在於「Profile 切換與 Toolset 綁定」。你通常會透過 CLI Profile 切換不同的工作身份，設定要不要啟用 Cron，以及指定生圖或影片工具該走 Nous 網關、FAL.ai 還是 xAI 訂閱。這比較像是一個個人工作台（Workbench）。

Context 治理與壓縮優化實務

在 Context 控制上，OpenClaw 提供了極其細緻的 Knobs（旋鈕），你可以限制 Workspace 載入的字數上限、單次 Tool Result 的長度、甚至設定生圖的解析度上限。然而，設定過於複雜也代表著你必須非常清楚每個參數的運作邏輯，否則很容易因為限制過緊而導致 Agent 漏看關鍵資訊。

Hermes 則相對直覺，它靠著 MEMORY.md 控死長期 Facts，靠對話壓縮機制（Context Compression）來維持歷史對話的健康度。

在實務上，使用 Hermes 時常會因為 Provider 無法自動辨識而把 Context 壓得太小。以下是我們在 Local 或 API 混用環境下，推薦的優化 YAML 設定：

model:
  default: "your-model"
  provider: custom
  base_url: "http://localhost:11434/v1"
  context_length: 131072
  max_tokens: 8192

compression:
  enabled: true
  threshold: 0.40
  target_ratio: 0.20
  protect_last_n: 20
  protect_first_n: 0

這段 YAML 設定主要是限制本地模型或 API 的 Context 上限，並啟動對話壓縮機制。當對話長度超過設定比例時，系統會自動做摘要以節省 token，但會強制保留最近 20 輪的對話細節不被壓縮。

如果你習慣用 CLI 指令來動態調整參數，可以直接執行：

hermes config set model.context_length 131072
hermes config set model.max_tokens 8192
hermes config set compression.enabled true
hermes config set compression.threshold 0.40
hermes config set compression.target_ratio 0.20
hermes config set compression.protect_last_n 20
hermes config set compression.protect_first_n 0

這些 CLI 指令等同於直接修改 Hermes 的全域設定檔。當你臨時需要調整模型的 Context Window 或調整壓縮閾值時，直接在終端機打這些指令就能即時生效。

如果你不想手動改設定檔，也可以直接對 Hermes 下這段 Prompts 讓它自我設定：

請檢查我的 ~/.hermes/config.yaml。
把 model.context_length 設成目前模型實際可用的 context window，不要拿 max_tokens 代替 context_length。
如果 provider 無法自動偵測，coding/research 用 131072 起跳。
compression 保持 enabled，threshold 先設 0.40，target_ratio 0.20，protect_last_n 20。
如果這是長時間 gateway session，把 protect_first_n 設為 0。
改完後請說明你改了哪些欄位，以及哪些欄位需要我依模型實際限制再調整。

這是一段可以直接餵給 Hermes 的自然語言 Prompt，用來命令 Agent 自動幫自己改設定。你不需要手動去翻系統設定檔，直接用講的它就會幫你修改並解釋改了什麼。

值得一提的是，Hermes 的 Context 參數支援在 Gateway 運行中熱更新（Hot Reload），下一則發送的 Request 就會直接套用新設定，無需重啟服務。

訂閱制生圖（Image Gen）：OAuth 通道與 API 的抉擇

我們在探討「吃訂閱生圖」時，並非指打開瀏覽器去按 ChatGPT，而是指 Agent 能否透過 OAuth 登入，直接白嫖你個人 ChatGPT Plus 或 Codex 訂閱背後的生圖算力。

OpenClaw 對此支援得非常直接：它的 image_generate 工具支援 openai/gpt-image-2。除了填寫 API Key 扣款外，你也可以直接執行 OAuth 認證。一旦檢測到 Codex 訂閱帳號已登入，OpenClaw 就會自動將生圖 Request 導向你的 Codex Response 後端，實現零額外成本生圖。

OpenClaw 綁定 OAuth 訂閱的指令如下：

openclaw models auth login --provider openai-codex
openclaw config set agents.defaults.imageGenerationModel.primary "openai/gpt-image-2"

這兩行指令是先透過 OAuth 登入你的 OpenAI 帳號，並將 OpenClaw 的預設生圖模型指定為 GPT-Image-2。設定完成後，Agent 在執行生圖任務時就會優先走你的訂閱通道而非 API 扣款。

在與 OpenClaw 對話時，你可以直接下達此類指令：

請用 image_generate 走 openai/gpt-image-2，生成一張 16:9 的極簡科技部落格封面。
不要加文字，保留中間留白。

這是下給 OpenClaw 的生圖 Prompt，指定呼叫剛綁定好的 gpt-image-2 模型來生出部落格封面。Agent 會自動把這個自然語言請求轉換成工具調用，並將圖片存回工作區。

Hermes 則提供了三種生圖路徑：

1. Nous Subscription：透過 Nous 官方的付費 Portal 訂閱，直接走內建的 Tool Gateway 生成，免填 FAL API Key。
2. FAL.ai 直連：依用量付費，支援 Flux、Ideogram 與 gpt-image 系列。
3. OpenAI Codex OAuth：透過啟用內建的 image_gen/openai-codex 插件，打通 ChatGPT 訂閱通道。

Hermes 的啟用與設定步驟如下：

# Nous Subscription / FAL 路線
hermes tools
# Image Generation -> 選 Nous Subscription 或 FAL.ai -> 選 fal-ai/gpt-image-2

# OpenAI Codex OAuth image backend 路線，依版本可用性啟用
hermes plugins enable image_gen/openai-codex
hermes tools
# Image Generation -> 選 OpenAI Codex / gpt-image-2 類 backend

這段指令展示了在 Hermes 裡切換生圖後端的兩種方式，包含啟用內建的外掛插件以及開啟互動式選單。這讓開發者可以根據手邊的 API Key 或訂閱帳號靈活選擇要用 FAL 還是 Codex 的服務。

在 Hermes 中，你可以用語意指派任務：

請用目前 Image Generation backend 生成一張 1810x400 的部落格封面。
如果 backend 支援 gpt-image-2，優先用 gpt-image-2；如果不支援，回報目前可用模型與原因。

這是丟給 Hermes 的生圖對話範例，要求它使用當前設定的後端引擎。Agent 會先檢查後端相容性，若不支援指定的 gpt-image-2 則會退回防禦性邏輯並回報狀態。

Grok 影片生成（Video Gen）：SuperGrok 訂閱的白嫖與限制

影片生成在實務上多用於產生 Banner 或動態示意。這兩套框架都支援透過 xAI OAuth，將你的 SuperGrok 或 X Premium+ 訂閱帳號轉換為 Agent 的影片生成工具，省去昂貴的 API 呼叫費用。

OpenClaw 端的配置非常簡單，它將 xAI 整合進了全域的 Provider Policy 中：

openclaw models auth login --provider xai --method oauth
openclaw config set agents.defaults.videoGenerationModel.primary "xai/grok-imagine-video"

這段指令讓 OpenClaw 透過 OAuth 流程綁定 xAI 帳號，並把預設影片生成後端指定為 Grok。如此一來，後續所有需要產生短影片的任務，都會預設交給 Grok 的影片生成引擎處理。

如果你的 Agent 部署在 headless 的 VPS 上，無法彈出瀏覽器視窗進行 OAuth，可以使用 Device Code 模式進行配對：

openclaw models auth login --provider xai --device-code

這是在沒有圖形化介面的遠端伺服器（例如透過 SSH 連線的 VPS）上跑登入時的指令，它會生成一組 PIN 碼讓你能在手機或另一台電腦的瀏覽器上完成 xAI 的認證。

完成後，便可在對話中直接叫它產生影片：

請用 video_generate 走 xai/grok-imagine-video，
生成 5 秒 16:9 影片：黑色馬在極簡科技格線上向前奔跑，鏡頭穩定、不要字幕。

這是下給 Agent 的影片生成 Prompt，明確指定了模型與畫面細節。Agent 接收到後會送出 Request 給 xAI 的 endpoint，並在下載完生成的 MP4 檔案後回傳給使用者。

Hermes 也是透過內建的 xAI Grok OAuth 實現此功能，但你必須手動到 hermes tools 介面中將關閉的 Video Toolset 開啟：

hermes auth add xai-oauth
hermes config set model.provider xai-oauth
hermes tools
# Video Generation -> 開啟 toolset -> 選 xAI Grok Imagine

這段指令是在 Hermes 裡新增 xAI 的 OAuth 認證，並引導使用者進入互動式工具選單去開啟影片生成功能。這屬於 Workbench 風格的配置方式，方便個人使用者手動切換不同供應商。

開啟後即可發送請求：

請用 video_generate 產生 5 秒 16:9 影片。
如果目前 video_gen backend 是 xAI Grok Imagine，就用 grok-imagine-video；
如果 video_gen 沒開，請先指出需要到 hermes tools 啟用 Video Generation。

這是給 Hermes 的防禦性對話提示，要求它先檢測影片工具的啟用狀態。這樣能避免因後端沒開或未設定而導致的執行期噴錯，讓 Agent 能主動給出修正指示。

need to be aware that 不論你用哪套框架，OAuth 登入成功只代表打通了認證管道，如果你的 xAI 訂閱帳號本身沒有對應的生影片權限（Entitlement），API 依然會回傳 403 Forbidden，此時就必須乖乖回去使用 API Key。

總結選型：看你想承擔哪一種架構成本

這兩套工具並沒有絕對的優劣，只有定位上的差異：

• OpenClaw 是一套偏向平台化治理的 Agent Operating Layer，適合團隊用來協同管理複數 Agent 與對外通道，代價是配置複雜度極高。
• Hermes 則是一套偏向個人工作流的 Agent Runtime，記憶檢索與技能改進非常順手，代價是缺乏開箱即用的多租戶管理與審批機制。

想清楚你的專案需要的是「一整個艦隊的長期分工」，還是「一個能陪你越用越聰明的隨身夥伴」，答案就很明顯了。

OpenClaw vs. Hermes 規格與定位對照表

參考文獻與專案文件

• OpenClaw Memory overview：https://docs.openclaw.ai/concepts/memory
• OpenClaw agents configuration：https://docs.openclaw.ai/gateway/config-agents
• OpenClaw skills config：https://docs.openclaw.ai/tools/skills-config
• OpenClaw image generation：https://docs.openclaw.ai/tools/image-generation
• OpenClaw video generation：https://docs.openclaw.ai/tools/video-generation
• OpenClaw OpenAI provider：https://docs.openclaw.ai/providers/openai
• OpenClaw xAI provider：https://docs.openclaw.ai/providers/xai
• Hermes Agent documentation：https://hermes-agent.nousresearch.com/docs/
• Hermes persistent memory：https://hermes-agent.nousresearch.com/docs/user-guide/features/memory
• Hermes skills system：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
• Hermes delegation patterns：https://hermes-agent.nousresearch.com/docs/guides/delegation-patterns/
• Hermes context compression：https://hermes-agent.nousresearch.com/docs/developer-guide/context-compression-and-caching/
• Hermes providers / context length：https://hermes-agent.nousresearch.com/docs/integrations/providers
• Hermes image generation：https://hermes-agent.nousresearch.com/docs/user-guide/features/image-generation
• Hermes built-in plugins：https://hermes-agent.nousresearch.com/docs/user-guide/features/built-in-plugins
• Hermes xAI Grok OAuth：https://hermes-agent.nousresearch.com/docs/guides/xai-grok-oauth