来源：https://zhuanlan.zhihu.com/p/2026323277375643746
中推圈终于在今天开始集中讨论Hermes Agent了，大概率未来几天国内AI/Agent头部和腰部媒体、自媒体也会开始对Hermes Agent进行集中报道；
然后，maybe，又是一波类似于OpenClaw的FOMO潮流，大家会把“养虾不如养马” 挂在嘴边（OpenClaw是🦞；Hermes是“爱马🐴仕”嘛），直到下一个龙虾或下一个爱马仕的出现。
我已经高强度使用Hermes Agent 10天左右，并且在上周将龙虾军团主力切到了Hermes Agent，飞书群里还有2000位热烈讨论Hermes的同学，最常遇到的问题是：
一、对比Hermes Agent和OpenClaw
二、Hermes究竟有什么优势
三、发展趋势
四、文档资源
下面就来回答这4个问题。
一、Hermes Agent vs OpenClaw full-table comparison
1. 一句话总览
| 结论维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 主要Language | Python | Typescript | |
| 产品姿态 | 以单个 Python Agent 为核心，向外扩出 messaging、ACP、MCP、cron、skills | 以本地 Gateway / Control Plane 为中心，把 Pi Agent、channels、plugins、sessions、nodes、ACP 统一编排 | Hermes 更像“自进化工作型 Agent”；OpenClaw 更像“本地 AI 操作系统 / control plane” |
| 架构复杂度 | 中等，主干清晰，容易通读 | 高，层次多，子系统多，扩展面宽 | OpenClaw 更重、更广；Hermes 更集中 |
| 系统重点 | Agent loop、procedural memory、轻量整合 | Gateway、multi-agent routing、插件生态、模型与账户编排 | 两者目标不同，不是简单的谁替代谁 |
2. 宏观定位与系统边界
| 维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 主体对象 | AIAgent 是系统中心，run_agent.py 直接承载核心会话循环 | Gateway + OpenClaw orchestration + embedded Pi runtime 共同组成主体 | Hermes 是“Agent-first”； OpenClaw 是“control-plane-first” |
| 代码组织方式 | Python 单仓，核心逻辑集中在 run_agent.py、tools/、gateway/、acp_adapter/ | TypeScript/Node 大型单仓，含 src/、extensions/、packages/、apps/、ui/ | OpenClaw 的系统边界明显更大 |
| 运行边界 | 单 Agent 为默认；subagent 是工具能力；profiles 是多实例机制 | 多 Agent、多 channel account、bindings、workspace、agentDir 都是一等公民 | OpenClaw 原生把“多脑并存”建模进系统了 |
| 对外形态 | CLI、messaging gateway、ACP adapter、cron、MCP client | Gateway、channels、control UI、ACP、MCP HTTP、plugins、nodes、apps | OpenClaw 的外部产品面更宽 |
3. Harness Engineering / 内核工程
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 内核是谁 | 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 外层编排中完成 | OpenClaw 的 harness 更重、更工程化 |
| 失败恢复 | Hermes 有上下文压缩、辅助模型、provider 适配，但整体仍偏单环路控制 | OpenClaw 在 run.ts 中显式处理 auth profile rotation、failover、live model switch、lane enqueue、runtime plugin 初始化 | OpenClaw 的“运行时调度工程”更强 |
| 维护成本 | 低到中，主链路可直接读懂 | 高，优点是能力面大，代价是理解成本高 | 小团队更容易先吃透 Hermes |
4. IM / Message Gateway
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 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 已覆盖常见平台；OpenClaw 在广度和调度能力上更强 |
| 多账号与路由 | Hermes 偏“一个平台适配器 + 一个 Hermes 配置” | OpenClaw 在 docs/concepts/multi-agent.md 中把 bindings、agentId、accountId、workspace、agentDir 作为一级模型 | OpenClaw 更适合复杂团队和多账号运营 |
| 交付风格 | 更像聊天入口 | 更像本地控制总线 | 这是两者最直观的系统边界差异之一 |
5. Skills 系统
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| Skills 根目录 | ~/.hermes/skills/ 是单一真相源，外部目录可读不可写 | skills 来自 <workspace>/skills、<workspace>/.agents/skills、~/.agents/skills、~/.openclaw/skills、bundled、extraDirs，且有明确优先级 | OpenClaw 的 skills 来源层次更复杂、更偏 workspace-first |
| Progressive disclosure | 有，skills_list -> skill_view -> path-specific view | 也有，docs/tools/skills.md 明确描述 prompt 中只注入精简技能索引，并在运行时按需展开 | 这不是差异点，两边都有 |
| Skill 目录能力 | SKILL.md + references/templates/scripts/assets | 兼容 AgentSkills，同样支持 skill folder 与 gating / installer metadata | 这也不是差异点，两边都支持完整 skill 包 |
| 生态重心 | 更偏“Agent 本地可写技能库” | 更偏“多来源 skills + ClawHub + installer + gating + allowlist” | OpenClaw 更强在 skills 生态与分发；Hermes 更强在 skills 自写自修 |
| 安装与分发 | 有 Skills Hub，但生态与安装管线较轻 | openclaw skills install、clawhub、skills-install.ts、installer metadata、dangerous-code scanner 形成完整分发链 | OpenClaw 在“技能平台”维度更强 |
| 每 Agent 隔离 | Hermes 通过 HERMES_HOME / profile 隔离技能目录 | OpenClaw 通过 workspace、agentDir、agent allowlist、shared roots 组合隔离与共享 | OpenClaw 的隔离/共享策略更细粒度 |
6. Hermes 独有的 Skill 自我进化能力
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 是否有显式写接口 | skill_manage 支持 create / edit / patch / delete / write_file / remove_file | 本次基线下未看到等价的“Agent 显式自写自修 skill”接口；主要看到的是 install / load / gate / sync | 这是 Hermes 的强差异点 |
| 概念定位 | 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
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| Provider 配置风格 | 以 .env、CLI setup、Python provider 适配为主 | models-config.ts + auth-profiles.ts + agent-command.ts 组成完整模型目录与认证画像体系 | OpenClaw 的 provider/auth 工程更强 |
| Auth 抽象 | 有 provider 凭证解析，够用但相对直接 | 有 auth profile store、profile order、cooldown、good/failure 标记、repair、OAuth/API key 双栈 | OpenClaw 在认证编排上明显更成熟 |
| 失败恢复 | Hermes 可以换 provider/model，但没有 OpenClaw 那么重的 auth profile 调度层 | OpenClaw 显式支持 profile rotation、cooldown、fallback、models.json 原子更新与运行时指纹 | OpenClaw 更适合复杂 provider 组合与长期运行 |
| 维护体验 | Hermes 更简单，单人机器和快速配置更友好 | OpenClaw 更强，但也更复杂 | 小规模使用偏 Hermes；复杂生产路由偏 OpenClaw |
8. Memory
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 记忆主形态 | MEMORY.md + USER.md 的 curated memory，加 session_search 做 FTS 会话检索 | workspace bootstrap files + memory_search + session transcripts + QMD / memory runtime 插件化后端 | OpenClaw 的 memory 面更大，Hermes 的 memory 更贴近 prompt 内核 |
| Prompt 注入策略 | memory_tool.py 明确采用 frozen snapshot：会话开始时注入，session 内写盘但不改 system prompt，保护 prefix cache | OpenClaw 也有 bootstrap file 注入，但 memory 还外延到检索与 transcript corpus | Hermes 在“提示词稳定性”上更明确 |
| 检索能力 | 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 维度更强 |
| 跨 Agent / 多 collection | 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 / 会话编排
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 多 Agent 是什么 | delegate_task 产生受限 subagent；profiles 产生多个隔离实例；两者是两种不同机制 | docs/concepts/multi-agent.md 直接把多 agent routing 作为系统一级能力 | OpenClaw 的多 Agent 模型更原生 |
| Subagent 深度 | Hermes delegate_tool.py 明确限制深度与工具集，child 不能继续 delegation | OpenClaw 有 sessions_spawn、sessions_yield、subagent-* 整套机制，且和 session registry 绑定 | OpenClaw 的子 Agent 编排更系统化 |
| 会话存储 | hermes_state.py SQLite + FTS5 | JSONL transcripts + ~/.openclaw/agents/<agentId>/sessions + routing/session metadata | OpenClaw 更偏 transcript-first；Hermes 更偏 DB-first |
| Fork / resume | Hermes 在 ACP / CLI 有 session 概念，但核心还是单 Agent loop | OpenClaw 在 ACP、gateway、sessions tool、multi-agent docs 中都把 session / spawn / yield 视为核心操作对象 | OpenClaw 在会话 orchestration 上更完整 |
10. ACP / MCP / 可扩展性 / 集成能力
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| ACP | 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，而是一整层控制面 |
| MCP | tools/mcp_tool.py 负责连接 stdio / HTTP MCP server，并把工具注册进 Hermes tool registry | src/gateway/mcp-http.ts + src/mcp/ + loopback runtime，把 MCP 与 gateway/control plane 深度结合 | OpenClaw 的 MCP 集成更像平台能力；Hermes 更像 client-side tool bridge |
| 插件化 | Hermes 有 tools、skills、MCP servers、外部 skill dirs，但插件化边界相对收敛 | OpenClaw 有 extensions/、packages/plugin-sdk、plugins/*、plugin package contract、provider/channel/memory 扩展 | OpenClaw 的扩展能力明显更强 |
| 外部系统整合方式 | Hermes 依赖工具/skill/MCP 的组合 | OpenClaw 同时提供 extensions、plugins、gateway APIs、channels、nodes、ACP、MCP | OpenClaw 更像集成底座 |
11. Workspace / Profile / 隔离模型
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 隔离根目录 | ~/.hermes 与 ~/.hermes/profiles/<name> | ~/.openclaw/agents/<agentId>/agent + workspace + sessions | OpenClaw 隔离对象更多，Hermes 隔离路径更直观 |
| 默认工作区 | 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 都可单独隔离 | OpenClaw 更适合多人/多脑同机共存 |
12. 工具运行时与执行面
| 子维度 | Hermes Agent | OpenClaw | Comments |
|---|---|---|---|
| 工具注册 | Python registry 模式，tools/*.py 在导入时 register() | 工具 catalog + runtime wiring + plugin/extensions 注入 | Hermes 简洁；OpenClaw 灵活但复杂 |
| 执行沙箱 | Hermes 有 tools/environments/，支持 local/docker/ssh/modal/daytona/singularity 等 | OpenClaw docs 与代码里对 sandbox、workspace override、nodes、gateway sandboxing 讨论更深入 | OpenClaw 的运行面更宽 |
| 浏览器 / Web / Canvas / 节点 | Hermes 有 browser、web、vision、image-generation、tts 等工具 | OpenClaw 除 browser/web 外，还把 canvas、nodes、设备节点、control UI 等整合进统一平台 | OpenClaw 更偏“能力平台” |
13. 适用场景判断
| 场景 | 更适合 Hermes Agent | 更适合 OpenClaw |
|---|---|---|
| 想要一个会随着使用逐步沉淀技能的方法型 Agent | 是 | 否 |
| 想把 Agent 当作“长期协作的工作搭子”持续养熟 | 是 | 可做，但不是最鲜明优势 |
| 想运营多个 agent、多个 channel account、多个 workspace | 一般 | 是 |
| 想构建本地 control plane，把消息平台、插件、ACP、MCP、sessions 都纳进一个大系统 | 一般 | 是 |
| 想快速 hack 一个核心 Agent、阅读主循环、直接改行为 | 是 | 较难 |
| 想要强 skills 生态、安装和分发能力 | 一般 | 是 |
| 想做“技能即 procedural memory，且 agent 能自行 patch” | 是 | 否 |
二、Hermes Agent究竟有什么优势
上面的表格已经从客观角度做出了非常详尽的比较，以下是我的主观评价：
- 1. 从员工沟通和管理角度：Hermes Agent将所有的工作过程（log）都在聊天界面中打印出来了，工作的“透明度”带来了”可信度“，职场老油条们应该都明白这个道理。
- 从员工“Growth Mindset”角度：凡是摔过的坑，Hermes大概率不会再犯，因为Hermes的工作过程就是不断的调整和优化它自己的工作流（其实也是我的工作流），然后用调整过的工作流去跑业务流程，有问题就再调整，如此循环，直到最终的业务结果通过验收，那么最后一版的工作流大概率就是最终需要被沉淀下来的knowhow，你会得到自己都忘了应该进行封装但Hermes已经帮你封装好的若干个新skills，以及一路优化下来的N多旧skills — 妥妥以“Bayesian Inference” 为底层运行机制的Agent。
- 从员工无监管自动运行角度：Hermes Agent的长程无监管运行能力也比较强；我用GPT-5.4跑过2小时以上的Hermes Agent任务，这个时长放在OpenClaw身上我还没有成功过…
- 在上面的表格中我们可以看到OpenClaw的优势在于摊子铺的更大，更“平台化”；但问题是，如果在非常具体的场景中没办法很好沉淀个人或者组织的knowhow的话，摊子又铺那么大，放大的究竟是优势还是劣势呢？
- 总之，“白马”（未经过调教的Hermes）一定是比“白虾”（未经过调教的OpenClaw）更值得信赖和培养的好员工。
三、Hermes Agent发展趋势
Hermes Agent项目发布于2月26日，在Github上有接近5.3万颗星。
在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里了；
