為什麼我現在不安裝 Hermes Agent
大家好，我是雙越。[wangEditor](https://link.juejin.cn?target=https%3A%2F%2Fwww.wangeditor.com%2F) 作者，前百度、滴滴 資深前端工程師，慕課網金牌講師，PMP，[前端面試派](https://link.juejin.cn?target=https%3A%2F%2Fwww.mianshipai.com%2F) 作者。我正致力於兩個專案的開發與升級，有興趣的可以私訊我，加入專案小組。
最近 Hermes Agent 在社群裡火起來了。作為一個使用 OpenClaw 的使用者，我花了一些時間認真研究了它的文件，和現有工具做了對比，最終決定：暫時不切換，繼續觀察。
這篇文章記錄我的思考過程，希望對同樣在評估 Hermes Agent 的朋友有所參考。
Hermes Agent 核心功能介紹
Hermes Agent 是由 Nous Research（就是訓練了 Hermes、Nomos、Psyche 系列模型的那個 AI 實驗室）開源的自主 Agent 框架，MIT 授權，定位是「自我進化的 AI Agent」。
它的核心能力可以概括為以下幾個方面：
閉合學習迴圈（Closed Learning Loop） 這是 Hermes 最核心的設計理念。Agent 能從使用經歷中自動建立技能文件、主動持久化知識，並隨時間構建對使用者越來越深入的模型。
持久記憶系統 維護兩個關鍵檔案：MEMORY.md（約 2200 字元）記錄環境事實、專案約定、已完成工作；USER.md（約 1375 字元）記錄使用者偏好、溝通風格、技能水平。每個 session 開始時注入 system prompt。同時所有會話存儲在 SQLite（FTS5 全文檢索），支援跨 session 喚回幾週前的對話內容。
執行環境靈活 支援 6 種終端後端：本機、Docker、SSH、Daytona、Singularity、Modal。其中 Daytona 和 Modal 提供無伺服器持久化，環境閒置時休眠，成本幾乎為零。你可以把 Hermes 部署在一台 $5/月的 VPS 上，用 Telegram 遠端指揮它在雲端工作，完全不依賴本地筆電。
多平台訊息閘道 支援 15+ 平台：Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、SMS、DingTalk、Feishu、WeCom、BlueBubbles、Home Assistant 等，一個 gateway 統一管理。
Skills 生態系統 遵循 agentskills.io 開放標準，接入多個 Hub 來源：官方 Optional Skills、skills.sh（Vercel 技能目錄）、GitHub 直接安裝、ClawHub、LobeHub 等。技能採用漸進式揭露載入，先拉摘要列表，需要時再載入全文，節省 token 消耗。
其他能力 47 個內建工具、19 個 toolset、MCP 支援、語音模式、瀏覽器自動化、圖片生成、排程任務（Cron）、子 Agent 平行委派、IDE 整合（VS Code、Zed、JetBrains）、RL 訓練軌跡匯出……功能相當完整。
Hermes Agent 對比 OpenClaw
在我認真核查兩份文件之前，我一度以為 OpenClaw 沒有記憶功能，但實際上並非如此。兩者在核心能力上的對比遠比表面看起來更接近。
記憶系統 OpenClaw 同樣有完整的記憶系統：MEMORY.md 長期記憶、每日筆記檔案（memory/YYYY-MM-DD.md）、混合語意搜尋（向量 + 關鍵字）、自動 memory flush（在上下文壓縮前觸發），以及實驗性的 Dreaming 功能（背景整合短期記憶晉升為長期記憶）。兩者都支援 Honcho 使用者建模，也都有可選的外部記憶 Provider。
訊息平台 兩者都涵蓋主流平台，Hermes 略多（15+），OpenClaw 也有 10+ 個，並且有外掛機制可擴充。
技術棧 OpenClaw 是 Node.js，Hermes 是 Python。
定位側重 OpenClaw 更側重「多 channel 訊息閘道」，把各個 IM 接入 AI 是它的核心場景；Hermes 更側重「自主 Agent 能力」，訊息閘道是它的功能之一，而非核心。
最大的差異 經過仔細對比，兩者真正不同的地方只有一個：技能自動建立。這也是下一節要重點討論的。
Hermes Agent 最重要的特色：技能自動建立
功能介紹
Hermes 的 Skills 系統有兩個層面：一是從社群 Hub 安裝現成技能，二是 Agent 在使用過程中自動建立新技能。
自動觸發的條件包括：完成一個複雜任務（5+ 次工具呼叫）、遭遇錯誤並找到解決路徑、被使用者糾正了某個做法，或發現了一個非顯而易見的工作流程。觸發後，Agent 會透過 skill_manage 工具把這個「走通了的路」結構化為一個 Skill 文件，保存在 ~/.hermes/skills/ 下，供未來複用。
這本質上是把使用者的使用經歷轉化為 Agent 能力的增量。普通 Agent 每次面對複雜任務都是從零開始推理，而 Hermes 累積的 Skill 庫會讓它下次遇到同類問題時直接載入經過驗證的流程，而不是重新摸索。
優點
能力隨時間成長。 使用越久，累積的 Skill 越多，Agent 處理特定領域任務的效率越高。這是一個正向飛輪。
知識可重用、可分享。 Skills 遵循開放標準，可以匯出、分享給社群，也可以從 agentskills.io 等 Hub 安裝他人沉澱的經驗。
降低重複推理成本。 對於頻繁出現的複雜操作，Skill 文件相當於給 Agent 裝了一本操作手冊，減少了無效的試錯輪次。
缺點與潛在問題
數量膨脹。 長期重度使用後，自動建立的 Skill 可能累積到數百甚至更多。更麻煩的是，同類任務可能被反覆建立成相似的 Skill，出現大量冗餘，日後難以維護。
品質稀釋。 自動建立的 Skill 未必都是高品質的——它可能記錄了一個「當時恰好走通但並不通用」的路徑，反而在未來誤導 Agent。
系統提示膨脹。 Skills 透過系統提示注入，即便採用了漸進式揭露（先只注入摘要列表），隨著 Skill 數量增長，系統提示依然會越來越臃腫，影響 context 利用效率和推理品質。
使用者感知不足。 建立過程在使用者不知情的情況下自動發生，缺乏明確的審查機制，使用者難以掌握 Skill 庫的真實狀態。
目前文件中提到的緩解措施主要是漸進式三級載入，並沒有提到 LRU 淘汰或自動清理機制，這意味著 Skill 膨脹問題是真實存在的、尚未被完整解決的。
Agent 核心模組趨於穩定
評估一個新 Agent 工具時，有一個背景值得注意：主流 Agent 框架在核心模組層面已經高度趨同。
如果你橫向對比 Hermes、OpenClaw、Claude Code、Cursor、Aider 等工具，會發現它們幾乎都涵蓋了相同的核心能力矩陣：
- LLM 接入：多 provider 支援，OpenAI 相容介面，本地模型支援
- Skills / 知識文件：SKILL.md、CLAUDE.md、AGENTS.md 等各種形式的上下文文件
- Tools：檔案讀寫、終端執行、Web 搜尋、瀏覽器自動化
- MCP：Model Context Protocol 已成事實標準，幾乎所有主流 Agent 都支援
- Memory：跨 session 持久記憶，語意搜尋
- Context Files：專案上下文注入，SOUL.md 人格定義
- Cron：排程任務
- Security：命令審批、沙箱隔離、allowlist
- Config：彈性的設定檔系統
- Channels：多平台訊息閘道
這個核心模組列表在過去一兩年裡已經基本穩定下來，成為「現代 Agent 框架」的標配。各家工具之間的差異，越來越體現在執行品質、穩定性、生態成熟度，以及少數幾個差異化特性上，而不是模組的有無。
這也意味著，當你看到一個新 Agent 宣稱擁有某項「獨特能力」時，第一個問題應該是：這真的是結構性的差異，還是只是別人還沒做但很快就會做的特性？
我不會立刻安裝使用的原因
綜合以上分析，我決定繼續使用 OpenClaw，暫不切換 Hermes。原因有四：
1. 穩定性和安全性有待驗證
Hermes 是一個相對較新的專案。作為由 Nous Research 團隊打造的工具，工程背景值得信賴，但這不等於生產級穩定。任何新工具都需要經歷大量真實使用者的壓力測試，才能暴露出邊緣情境下的 bug、安全漏洞、或設計缺陷。
Agent 框架尤其如此——它執行在你的機器上、存取你的檔案、執行終端命令，穩定性和安全性的門檻比一般工具更高。我傾向於等它在社群裡跑過足夠多的使用者和時間之後再做評估。
2. 和現有 Agent 沒有本質區別，差異點可以手動彌補
如前所述，Hermes 相對 OpenClaw 最大的差異是「技能自動建立」。但這個功能我可以用人工方式暫時替代：當我完成一個複雜任務後，手動把工作流程整理成一個 Skill 文件，儲存到 OpenClaw 的工作區。
這當然不如自動化便利，但對於目前階段來說足夠用。我不需要為了一個可以人工彌補的功能，就冒著切換成本和穩定性風險遷移到一個新工具。
3. 技能自動建立本身存在尚未解決的問題
如前文所分析，Skill 膨脹、品質稀釋、系統提示臃腫，這些都是自動建立機制帶來的副作用。目前文件中並沒有提到有效的自動清理或淘汰機制。
一個設計上有明顯未解決問題的功能，在它被完善之前，我並不急於使用。
4. 其他 Agent 補齊這一差距的成本很低
這是最關鍵的一點。「技能自動建立」聽起來是個獨特功能，但從技術實現角度看，門檻並不高：偵測複雜任務完成 → 觸發一個結構化寫檔案的 prompt → 儲存到磁碟。任何已經有檔案讀寫工具的 Agent，今天就能實現這個邏輯。
社群 Skills 生態（agentskills.io）也是開放標準，不是 Hermes 私有的，其他 Agent 接入同樣的生態完全沒有障礙。
事實上，Claude Code 已經有 CLAUDE.md 機制，可以把專案約定和常用命令持久化複用，距離完整的 Skill 自動建立只差「自動觸發建立」和「跨專案技能庫」這兩步。OpenClaw 也是同理。
這意味著 Hermes 在這個功能上的先發優勢窗口期不會很長。我沒有理由為了一個競品很快會跟進的特性，現在就承擔切換成本。
總結
Hermes Agent 是一個認真在做的專案，來自有真實技術積累的團隊，功能完整，方向正確。「技能自動建立」這個設計理念本身是值得肯定的——讓 Agent 隨使用累積能力，而不是每次都從零開始，這是 Agent 工具進化的正確方向。
但是，一個工具值得關注和一個工具值得立刻切換，是兩件不同的事。
對我來說，目前的結論是：繼續使用 OpenClaw，定期觀察 Hermes 的社群回饋和版本迭代。等它的穩定性經過充分驗證，技能膨脹等設計問題有了更完善的解法，或者它出現了真正讓我無法在現有工具裡替代的功能，再做切換決定。
Nous Research 的工程迭代速度應該不慢。如果你也在觀望，建議關注他們的 GitHub releases 和 Discord 社群，大概半年內就能看出它是否到了值得切換的成熟度。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
