文 | AI 價值官，作者丨星 野，編 輯丨美 圻

最近一段時間，Hermes Agent 的名字開始頻繁出現在開發者社區里，而且不再只是零散的 " 新項目推薦 "，而是下一個 OpenClaw 的熱門候選者。

在英文技術社區、Reddit、X 以及 The New Stack 等媒體的討論中，它被反復拿來和 OpenClaw 對比；在中文互聯網，從知乎、小紅書到技術社群，也開始出現越來越多真實的使用反饋。

伴隨討論度升溫的，是一組很難忽視的數據變化：Hermes 的 GitHub Star 數在短時間內持續攀升，目前已超過 35k。OpenRouter 上的 token 使用量從 3 月下旬開始明顯加速，單日使用量連續刷新新高，全球日排名一度進入前列。在 Productivity、Personal Agents、Coding Agents 等多個榜單中同時靠前，這對于一個上線不到兩個月的 Agent 框架而言，并不常見。

更重要的是敘事的變化。討論 Hermes 的人，不再只是 " 它能不能用 "" 值不值得試 "，而是開始出現一種判斷：它能否成為下一個 OpenClaw。

這個說法并不意味著體量對等（畢竟，Hermes 的星標數和 OpenClaw 差了一個數量級），而是一種角色上的類比——在 OpenClaw 之后，是否終于出現了一個足夠完整、足夠嚴肅、值得長期投入的 Agent 框架選擇。

OpenClaw 瓶頸漸顯

Agent 生態或告別 " 一家獨大 "

過去三個月，OpenClaw 代表的是一種近乎共識的答案：多渠道接入、全天候運行、龐大的技能生態，讓 Agent 從 " 會話工具 " 變成 " 常駐服務 "。

然而，隨著使用規模擴大、使用周期拉長，一些更底層的問題開始被反復提起：架構復雜度是否會不斷外溢？長期運行的上下文和記憶如何管控？系統成本會不會隨著生態擴張線性上升？這些問題并非突然出現，而是在狂熱期之后自然浮出水面。

在此背景下，小米大模型負責人羅福莉 4 月初發表的文章進一步推波助瀾。當 Anthropic 宣布切斷 OpenClaw 等通過 Claude 訂閱接入的通道，她從工程成本角度拆解了第三方 Agent 框架的效率問題。

她觀察到，OpenClaw 的上下文管理存在明顯浪費：一次用戶查詢往往被拆分為多輪低價值工具調用，每次 API 請求都攜帶超過 10 萬 token 的上下文窗口。按 API 定價折算，單次任務的真實推理成本可能達到訂閱價格的數十倍—— " 這不是一個小差距，是一個巨坑 "。

她同時指出，這種壓力短期內會倒逼框架開發者改進上下文管理，而更根本的出路在于 " 更高 token 效率的 Agent 框架 " 與 " 更強大高效的模型 " 的協同進化，而不是單純壓低 token 價格。

羅福莉的文章之所以在開發者圈子里引發共鳴，是因為它把許多用戶長期使用中感受到的問題，以及行業不斷攀升的 token 成本壓力，擺在了面上。

從 OpenRouter 的使用數據來看，OpenClaw 依然是體量最大的 Agent 框架，但已經開始從 3 月底的峰值回落。結合 Anthropic 收緊第三方調用路徑帶來的沖擊，部分開發者已開始重估單一框架路徑依賴的風險，Agent 生態正進入一輪新的開放競爭階段。

正是在此背景下，Hermes 的熱度開始上升。它受到關注，不是因為提供了更多平臺接入或更龐大的技能市場，而是因為在架構層面給出了另一種回答：當 Agent 被設計為長期運行的系統，是否可以把復雜度更多地收斂進模型和學習循環本身，而不是不斷堆疊外部編排層？

也正是在這一刻，"Hermes 會不會成為下一個 OpenClaw" 這個問題才真正成立——它比的不是規模，而是哪一種架構路徑，更有可能支撐 Agent 走得更遠。

Hermes 的設計哲學有何不同？

如果只對照功能列表，Hermes 和 OpenClaw 的重合度并不低：同樣支持多消息平臺接入，同樣具備持久化記憶、技能系統和多模型切換能力，也都采用 MIT 協議、自托管部署。真正拉開兩者差距的，是它們設計哲學上的顯著差異。

OpenClaw 的核心是一套 Gateway 架構。它的設計重心在于連接和協調：統一管理會話、路由和渠道，把 Telegram、Slack、WhatsApp 等入口匯聚到一個調度中心，再將請求分發給模型和工具。這種架構非常適合快速擴展生態，也解釋了為什么 OpenClaw 能在短時間內積累起龐大的技能市場和第三方集成網絡。

自我進化

Hermes 走的是另一條路線，圍繞 "Agent 如何在長期使用中變得更強 " 來構建。整個系統的核心不是網關，而是 Agent 自身的執行循環，官方稱之為 closed learning loop（閉環學習循環）。這意味著，Hermes 并不試圖通過不斷疊加外部編排層來解決問題，而是實現 agent 的自我進化，真正實現 "grows with you" 的愿景。

這種差異首先體現在技能系統上。Hermes 的技能不是預先編寫的功能模塊，而是在任務完成后，由 Agent 自行生成和維護的操作文檔。當一次任務涉及多次工具調用并形成相對穩定的解決路徑時，Agent 會把整個過程沉淀為一份結構化的 Markdown 技能文件。下次遇到類似問題，它不會重新從零推理，而是直接加載技能，并在執行過程中持續修訂它。

有用戶統計，連續使用一個月后，同類任務的工具調用次數從 20 多次壓縮到八到十次，模型本身沒有變化，變化的是 Agent 已經積累了一套可復用、可改進的 " 操作手冊 "。

相比之下，OpenClaw 也擁有龐大的技能生態，但技能更多是由他人編寫、為通用場景服務，本身并不會隨著某一個用戶的使用而自動進化。一個更像公共教材，一個更像私人工作筆記。

有限記憶

Hermes 在設計哲學上與 Openclaw 的另一重分歧，在于對于 " 記憶 " 這件事的不同理解。

OpenClaw 的策略是 " 什么都存 "，所有對話，所有上下文，全部持久化到數據庫里。需要的時候全量檢索。好處是信息不會丟，壞處是 token 消耗大，而且噪音會隨時間指數級遞增。

圖片來源：Inside Hermes Agent: How a Self-Improving AI Agent Actually Works，Daily AI Insights

Hermes Agent 選了一條反直覺的路：有限記憶。它并沒有采取 " 什么都存 " 的策略，而是有意為長期記憶設置上限。MEMORY.md 和 USER.md 的字符數被嚴格限制。設計者的判斷是：對大模型來說，少量精準的記憶比大量模糊的記憶更有用。

記憶文件在每個 session 開始時注入系統提示詞，占的 token 是固定的，不會隨著使用時間越來越膨脹。而且因為空間有限，agent 被迫學會做信息的篩選和壓縮，只保留真正重要的東西。記憶滿了怎么辦？agent 會自己合并舊條目、刪掉過時信息、把多條相關記錄壓縮成一條。更像一個人在整理筆記，而不是一個數據庫在堆疊數據。

在這一限制之上，Hermes 通過分層結構來解決記憶難題：所有歷史對話被完整存儲在 SQLite 中，通過 FTS5 全文檢索按需召回；技能文件承擔程序性記憶的角色；向量索引用于長期語義搜索；可選的 Honcho 用戶建模模塊，則用于捕捉用戶偏好和認知變化的趨勢，而不是簡單堆疊事實。

這種設計的結果是，上下文不會隨著使用時間失控膨脹，但 Agent 依然能夠 " 記得住事 "。對用戶而言，最直觀的體驗是不再反復解釋背景，不同會話、不同入口之間的理解保持一致。

模型解耦

此外，Hermes 在模型切換這件事上也走得更徹底。OpenClaw 官方雖然也支持多模型，但在實際使用中仍然更推薦搭配自家模型，而 Hermes 從一開始就把 " 模型可替換 " 當作前提條件來設計。

目前 Hermes 開箱即用地支持 18 個以上的 LLM 提供商，切換模型只需要一條命令，所有記憶、技能和歷史數據都保存在本地，幾乎不存在遷移成本。

這意味著用戶可以根據價格、穩定性或具體任務特性自由切換模型。對于不希望被長期綁定在某一個模型或某一家廠商生態里的開發者來說，這種自由度本身就是一種安全感。

綜合來看，Hermes 的這些設計并不是為了在某一次任務中顯得更聰明，而是圍繞一個更長期的問題展開：當 Agent 被持續使用數周甚至數月之后，它是否還能保持穩定、可控，并且越來越貼合用戶自身的工作方式。正是在這個時間維度上，Hermes 與 OpenClaw 拉開了差異。

當然，這條路線的代價同樣清晰。Hermes 在任務狀態管理、長流程穩定性和子 Agent 協作上仍然不成熟，對模型規模的要求更高，學習曲線也明顯陡于 OpenClaw。

更關鍵的是，Hermes 目前的生態成熟度與 OpenClaw 仍存在顯著差距，第三方平臺集成、社區教程、問題排查支持遠不完善，普通用戶的上手門檻遠高于常規開源工具。它并不適合只想 " 裝好就用 " 的用戶。但對于愿意長期運行一個 agent、并期望它隨著時間減少重復勞動的人來說，Hermes 提供的是一種完全不同的價值曲線。

Agent 框架趨同進化

分層架構正在形成

Hermes 的持續升溫，并非對 OpenClaw 的單向替代，而是整個 Agent 框架生態同步進化的一個關鍵信號。

事實上，OpenClaw 早已意識到早期架構所面臨的瓶頸，并主動推進底層能力迭代。在模型解耦與記憶機制這兩個核心方向上，它正呈現出與 Hermes 異曲同工的進化趨勢。

早在被 Anthropic 政策收緊影響之前，OpenClaw 就已經開始為 " 去單一模型依賴 " 做全面準備。在 3 月的更新中，OpenClaw 通過統一兼容層，抹平了不同模型在接口、認證方式和返回結構上的差異，用戶切換模型只需修改一個配置項，無需重新適配工具。這與 Hermes 從設計之初就堅持的 " 模型可替換 " 思路高度一致。

在記憶機制上，針對早期 " 全量存儲 " 帶來的 token 浪費、上下文臃腫問題，OpenClaw 在 4 月 5 日發布的 v2026.4.5 版本中，正式上線了 " 夢境 " 記憶系統。這套系統模擬人類睡眠中的記憶鞏固過程，在用戶不活躍的時段自動完成記憶的篩選、壓縮與提純，僅將高價值信息沉淀為長期記憶。

這套機制與 Hermes 的有限記憶設計，在目標層面高度一致——讓 Agent 越用越懂用戶，同時對長期運行的成本與噪音進行嚴格控制。

不過，底層架構的差異，依然決定了兩者的進化路徑與適用人群的分野。

OpenClaw 的進化，是建立在原有 Gateway 架構之上的優化升級：它依然保留全量數據作為兜底，夢境系統更多是一種上層的離線提純能力；模型解耦的重點，也放在兼容更豐富的生態與場景，而非從根本上重構執行邏輯。

Hermes 則從一開始就以 " 閉環學習循環 " 為核心，將復雜度直接內化進 Agent 的執行過程之中。這種底層設計基因的不同，使兩者天然服務于不同類型的用戶。

當用戶對 Agent 的需求從 " 嘗鮮可用 " 走向 " 長期深度使用 "，需求端已經出現了清晰的分層，與之對應，Agent 框架的三層結構正在逐漸成型。

OpenClaw 是面向普通用戶的多渠道 Agent 平臺，核心價值在于生態深度與低上手門檻，更像 "AI Agent 的 Android"，目標是讓用戶無需理解底層細節，也能直接使用成熟的 Agent 能力。

Hermes 定位于面向專業開發者的 Agent 基礎設施，強調可編程性、記憶深度與長期進化能力，適合希望深度定制、追求長期效率的用戶；Claude Cowork 則代表面向安全敏感場景的封閉生態，模型能力強、沙箱成熟，更符合對數據安全有嚴格要求的企業環境。

這三種定位并不互斥，邊界也在被主動打通。Hermes 已支持從 ClawHub 安裝社區技能，也可以通過 MCP 協議接入 Claude Desktop 與 Cursor。

不少用戶已經形成組合使用的模式：OpenClaw 負責多渠道消息路由與任務執行，Hermes 作為核心推理與記憶引擎。

這種分工協作的現實路徑，顯然比 " 誰取代誰 " 的線性敘事更貼近真實市場。

因此，與其追問 " 誰會成為下一個 OpenClaw"，不如承認一個更清晰的現實：Agent 框架正在從單點爆款時代，進入長期結構分化的階段。

真正決定未來走向的，是在模型快速更迭的時代，誰能讓 Agent 在時間維度上持續積累價值，并把這種積累牢牢掌握在用戶手中。