中推圈终于在今天开始集中讨论Hermes Agent了，大概率未来几天国内AI/Agent头部和腰部媒体、自媒体也会开始对Hermes Agent进行集中报道；然后，maybe，又是一波类似于OpenClaw的FOMO潮流，大家会把“养虾不如养马” 挂在嘴边（OpenClaw是🦞；Hermes是“爱马🐴仕”嘛），直到下一个龙虾或下一个爱马仕的出现。
我已经高强度使用Hermes Agent 10天左右，并且在上周将龙虾军团主力切到了Hermes Agent，飞书群里还有2000位热烈讨论Hermes的同学，最常遇到的问题是：
一、对比Hermes Agent和OpenClaw
二、Hermes究竟有什么优势
三、发展趋势
四、文档资源
五、社群资源
下面就来回答这五个问题。
一、Hermes Agent vs OpenClaw full-table comparison
以下内容是我让GPT-5.4在Extra High模式下跑了1个小时，将今天最新版Hermes Agent和OpenClaw的source code放在一起做了apple2apple的客观比较，未携带我的主观评价：
拜万恶的公众号编辑器所赐，表格没办法所在一屏宽度内完整展示，劳烦大家左右滑动表格：
1. 一句话总览
|
|
|
|
|
|
|
|
|
|
|
|
以单个 Python Agent 为核心，向外扩出 messaging、ACP、MCP、cron、skills
|
以本地 Gateway / Control Plane 为中心，把 Pi Agent、channels、plugins、sessions、nodes、ACP 统一编排
|
OpenClaw 更像“本地 AI 操作系统 / control plane”
|
|
|
|
|
|
|
|
Agent loop、procedural memory、轻量整合
|
Gateway、multi-agent routing、插件生态、模型与账户编排
|
|
2. 宏观定位与系统边界
|
|
|
|
|
|
|
AIAgent
是系统中心，run_agent.py 直接承载核心会话循环
|
Gateway + OpenClaw orchestration + embedded Pi runtime
|
OpenClaw 是“control-plane-first”
|
|
|
Python 单仓，核心逻辑集中在 run_agent.py、tools/、gateway/、acp_adapter/
|
TypeScript/Node 大型单仓，含 src/、extensions/、packages/、apps/、ui/
|
|
|
|
单 Agent 为默认；subagent 是工具能力；profiles 是多实例机制
|
多 Agent、多 channel account、bindings、workspace、agentDir 都是一等公民
|
|
|
|
CLI、messaging gateway、ACP adapter、cron、MCP client
|
Gateway、channels、control UI、ACP、MCP HTTP、plugins、nodes、apps
|
|
3. Harness Engineering / 内核工程
|
|
|
|
|
|
|
run_agent.py
里的 AIAgent.run_conversation() 就是内核循环
|
docs/concepts/agent.md
明确写出“embedded agent runtime is built on the Pi agent core”，外层由 OpenClaw 接管 session、tool wiring、delivery
|
OpenClaw 的内核更像“Pi runtime + 外部编排壳”；
Hermes 的内核更像“一体化 Agent loop”
|
|
|
模型调用、工具循环、上下文压缩、缓存、回调、delegation 基本集中在 Agent 主干
|
workspace 解析、sessionKey、auth profile、模型 failover、lane queue、plugin runtime、tool/runtime 注入都在 Pi 外层编排中完成
|
|
|
|
Hermes 有上下文压缩、辅助模型、provider 适配，但整体仍偏单环路控制
|
OpenClaw 在 run.ts 中显式处理 auth profile rotation、failover、live model switch、lane enqueue、runtime plugin 初始化
|
|
|
|
|
|
|
4. IM / Message Gateway
|
|
|
|
|
|
|
gateway/
|
src/gateway/
是完整 control plane：HTTP / WS、discovery、device auth、control UI、models HTTP、MCP HTTP、operator approvals、session persistence、cron server
|
OpenClaw 的 gateway 强很多，且不只是 IM 网关
|
|
|
gateway/config.py
当前内置 telegram / discord / whatsapp / slack / signal / mattermost / matrix / homeassistant / email / sms / dingtalk / webhook / feishu / wecom / api_server
|
频道与扩展面分散在 src/gateway/、docs/channels/、extensions/，整体明显更广，并支持多 account + bindings
|
|
|
|
Hermes 偏“一个平台适配器 + 一个 Hermes 配置”
|
OpenClaw 在 docs/concepts/multi-agent.md 中把 bindings、agentId、accountId、workspace、agentDir 作为一级模型
|
|
|
|
|
|
|
5. Skills 系统
|
|
|
|
|
|
|
~/.hermes/skills/
|
skills 来自 <workspace>/skills、<workspace>/.agents/skills、~/.agents/skills、~/.openclaw/skills、bundled、extraDirs，且有明确优先级
|
OpenClaw 的 skills 来源层次更复杂、更偏 workspace-first
|
|
|
有，skills_list -> skill_view -> path-specific view
|
也有，docs/tools/skills.md 明确描述 prompt 中只注入精简技能索引，并在运行时按需展开
|
|
|
|
SKILL.md + references/templates/scripts/assets |
兼容 AgentSkills，同样支持 skill folder 与 gating / installer metadata
|
|
|
|
|
更偏“多来源 skills + ClawHub + installer + gating + allowlist”
|
OpenClaw 更强在 skills 生态与分发；
|
|
|
|
openclaw skills install
、clawhub、skills-install.ts、installer metadata、dangerous-code scanner 形成完整分发链
|
|
|
|
Hermes 通过 HERMES_HOME / profile 隔离技能目录
|
OpenClaw 通过 workspace、agentDir、agent allowlist、shared roots 组合隔离与共享
|
|
6. Hermes 独有的 Skill 自我进化能力
|
|
|
|
|
|
|
skill_manage
支持 create / edit / patch / delete / write_file / remove_file
|
本次基线下未看到等价的“Agent 显式自写自修 skill”接口；主要看到的是 install / load / gate / sync
|
|
|
|
tools/skill_manager_tool.py
直接写明 “Skills are the agent’s procedural memory”
|
OpenClaw 文档更强调技能的来源、优先级、gating、安装与 workspace 组织
|
Hermes 明确把 skill 放进 agent 认知闭环
|
|
|
官方文档写明：复杂任务成功后、踩坑后、修正后可沉淀为 skill；发现 skill 过时可 patch
|
OpenClaw 文档中更常见的是让用户/工作区维护 skills，而不是 agent 直接演化 skill 本身
|
Hermes 在“从经验到程序性记忆”的闭环上更强
|
|
|
agent-created skills 也会跑 skills_guard 安全扫描
|
OpenClaw 主要在第三方 skill/install 时做扫描与安装保护
|
|
|
|
Hermes 的优势是“skill 具有可写、可补丁、可演化的正式运行时接口”
|
|
|
Hermes Agent最具优势能力(看Hermes Agent工作log就是在频繁调用skill_manage工具)：
7. LLM Provider / Auth
|
|
|
|
|
|
|
以 .env、CLI setup、Python provider 适配为主
|
models-config.ts
+ auth-profiles.ts + agent-command.ts 组成完整模型目录与认证画像体系
|
OpenClaw 的 provider/auth 工程更强
|
|
|
|
有 auth profile store、profile order、cooldown、good/failure 标记、repair、OAuth/API key 双栈
|
|
|
|
Hermes 可以换 provider/model，但没有 OpenClaw 那么重的 auth profile 调度层
|
OpenClaw 显式支持 profile rotation、cooldown、fallback、models.json 原子更新与运行时指纹
|
OpenClaw 更适合复杂 provider 组合与长期运行
|
|
|
|
|
|
8. Memory
|
|
|
|
|
|
|
MEMORY.md + USER.md
的 curated memory，加 session_search 做 FTS 会话检索
|
workspace bootstrap files + memory_search + session transcripts + QMD / memory runtime 插件化后端
|
Hermes 的 memory 更贴近 prompt 内核
|
|
|
memory_tool.py
明确采用 frozen snapshot：会话开始时注入，session 内写盘但不改 system prompt，保护 prefix cache
|
OpenClaw 也有 bootstrap file 注入，但 memory 还外延到检索与 transcript corpus
|
|
|
|
session_search_tool.py
基于 SQLite FTS5，再由辅助模型总结命中结果
|
memory-search.ts
支持 sources、sqlite/vector/hybrid/MMR/temporal decay、remote/local embedding provider、多模态、sync policy
|
OpenClaw 在 retrieval memory 维度更强
|
|
|
Hermes 主要按 profile / session 组织，外部 memory providers 可接入
|
OpenClaw 在 docs/concepts/multi-agent.md 中已支持 per-agent transcript collection 与 cross-agent QMD memory search
|
OpenClaw 更偏“多脑共享或隔离的检索记忆系统”
|
|
|
Hermes 更像“内生化、可控、提示词友好”的记忆栈
|
OpenClaw 更像“检索型、可编排、面向多 agent 的记忆系统”
|
|
9. 多 Agent / 会话编排
|
|
|
|
|
|
|
delegate_task
产生受限 subagent；profiles 产生多个隔离实例；两者是两种不同机制
|
docs/concepts/multi-agent.md
直接把多 agent routing 作为系统一级能力
|
|
|
|
Hermes delegate_tool.py 明确限制深度与工具集，child 不能继续 delegation
|
OpenClaw 有 sessions_spawn、sessions_yield、subagent-* 整套机制，且和 session registry 绑定
|
|
|
|
hermes_state.py
|
JSONL transcripts + ~/.openclaw/agents/<agentId>/sessions + routing/session metadata
|
OpenClaw 更偏 transcript-first；
|
|
|
Hermes 在 ACP / CLI 有 session 概念，但核心还是单 Agent loop
|
OpenClaw 在 ACP、gateway、sessions tool、multi-agent docs 中都把 session / spawn / yield 视为核心操作对象
|
OpenClaw 在会话 orchestration 上更完整
|
10. ACP / MCP / 可扩展性 / 集成能力
|
|
|
|
|
|
|
acp_adapter/server.py
把 Hermes 暴露给编辑器：new/load/resume/fork/list session、tool progress、model switch、approval callback
|
src/acp/
是完整 ACP 子系统，含 control-plane manager、runtime cache、policy、persistent bindings、spawn、translator、server
|
OpenClaw 的 ACP 不只是 adapter，而是一整层控制面
|
|
|
tools/mcp_tool.py
负责连接 stdio / HTTP MCP server，并把工具注册进 Hermes tool registry
|
src/gateway/mcp-http.ts
+ src/mcp/ + loopback runtime，把 MCP 与 gateway/control plane 深度结合
|
Hermes 更像 client-side tool bridge
|
|
|
Hermes 有 tools、skills、MCP servers、外部 skill dirs，但插件化边界相对收敛
|
OpenClaw 有 extensions/、packages/plugin-sdk、plugins/*、plugin package contract、provider/channel/memory 扩展
|
|
|
|
Hermes 依赖工具/skill/MCP 的组合
|
OpenClaw 同时提供 extensions、plugins、gateway APIs、channels、nodes、ACP、MCP
|
|
11. Workspace / Profile / 隔离模型
|
|
|
|
|
|
|
~/.hermes
与 ~/.hermes/profiles/<name>
|
~/.openclaw/agents/<agentId>/agent
|
|
|
|
CLI 使用当前目录，messaging 可配置 MESSAGING_CWD；profile 影响 HERMES_HOME
|
agents.defaults.workspace
是 agent 默认 cwd；multi-agent 时每个 agent 都有自己的 workspace
|
OpenClaw 的 workspace 更强绑定系统配置
|
|
|
profile 级隔离明显；subagent 是临时执行隔离
|
agentId、workspace、auth profiles、channel binding、session store 都可单独隔离
|
|
12. 工具运行时与执行面
|
|
|
|
|
|
|
Python registry 模式，tools/*.py 在导入时 register()
|
工具 catalog + runtime wiring + plugin/extensions 注入
|
|
|
|
Hermes 有 tools/environments/，支持 local/docker/ssh/modal/daytona/singularity 等
|
OpenClaw docs 与代码里对 sandbox、workspace override、nodes、gateway sandboxing 讨论更深入
|
|
|
|
Hermes 有 browser、web、vision、image-generation、tts 等工具
|
OpenClaw 除 browser/web 外，还把 canvas、nodes、设备节点、control UI 等整合进统一平台
|
|
13. 适用场景判断
|
|
|
|
|
想要一个会随着使用逐步沉淀技能的方法型 Agent
|
|
|
|
想把 Agent 当作“长期协作的工作搭子”持续养熟
|
|
|
|
想运营多个 agent、多个 channel account、多个 workspace
|
|
|
|
想构建本地 control plane，把消息平台、插件、ACP、MCP、sessions 都纳进一个大系统
|
|
|
|
想快速 hack 一个核心 Agent、阅读主循环、直接改行为
|
|
|
|
|
|
|
|
想做“技能即 procedural memory，且 agent 能自行 patch”
|
|
|
二、Hermes Agent究竟有什么优势
上面的表格已经从客观角度做出了非常详尽的比较，以下是我的主观评价：
-
1. 从员工沟通和管理角度：Hermes Agent将所有的工作过程（log）都在聊天界面中打印出来了，工作的“透明度”带来了”可信度“，职场老油条们应该都明白这个道理。
-
2. 从员工“Growth Mindset”角度：凡是摔过的坑，Hermes大概率不会再犯，因为Hermes的工作过程就是不断的调整和优化它自己的工作流（其实也是我的工作流），然后用调整过的工作流去跑业务流程，有问题就再调整，如此循环，直到最终的业务结果通过验收，那么最后一版的工作流大概率就是最终需要被沉淀下来的knowhow，你会得到自己都忘了应该进行封装但Hermes已经帮你封装好的若干个新skills，以及一路优化下来的N多旧skills — 妥妥以“Bayesian Inference” 为底层运行机制的Agent。
-
3. 从员工无监管自动运行角度：Hermes Agent的长程无监管运行能力也比较强；我用GPT-5.4跑过2小时以上的Hermes Agent任务，这个时长放在OpenClaw身上我还没有成功过…
-
4. 在上面的表格中我们可以看到OpenClaw的优势在于摊子铺的更大，更“平台化”；但问题是，如果在非常具体的场景中没办法很好沉淀个人或者组织的knowhow的话，摊子又铺那么大，放大的究竟是优势还是劣势呢？
-
5. 总之，“白马”（未经过调教的Hermes）一定是比“白虾”（未经过调教的OpenClaw）更值得信赖和培养的好员工。
三、Hermes Agent发展趋势
Hermes Agent项目发布于2月26日，在Github上有接近3.5万颗星。
在OpenRouter的应用token消耗日榜上，Hermes Agent同时“Top Coding Agent榜”和“Top Productivity”两张榜上。
在Coding Agent区，Hermes Agent在本周超越了老牌Coding Agent “Cline”，排在Coding Agent榜单第三名，并且用量还在快速上升，离去年的当红炸子鸡Kilo Code一步之遥，大概率会在未来一周超越Kilo Code，2-3周超越Claude Code。
在Productivity区，目前Hermes的token消耗量约为OpenClaw的1/4左右，而这个值在上周在1/8左右。
也就是说，1个月后，从token消耗量角度观察，就是OpenClaw和Hermes Agent两强争霸的局面。
这也就是为什么最近有越来越多的人在谈论Hermes Agent… 趋势已经飙起来了，数据不会撒谎。
四、文档资源：
其实你只需要看下面两个文档站，或者把文档站喂给你手边的一个Agent，然后问它，就能得到几乎所有问题的答案了 …
官方文档站： https://hermes-agent.nousresearch.com/docs/
我上周复刻为中文文档站（随官方日更）： https://hermes-doc.aigc.green/
另外，可以关注Hermes Agent的官推：
@Teknium： https://x.com/Teknium （Hermes创始人，NOUS Research Cofounder和模型后训练负责人）
@NousResearch： https://x.com/NousResearch （Hermes Agent官方团队）
NOUS Research团队的迭代能力也堪称光速，昨天就已经把火爆的Karpathy的LLM Wiki能力集成到Hermes里了；
