我认真对比了 Hermes Agent 和 OpenClaw，结论是：前者更像会成长的超级助理，后者更像智能助理操作系统
最近花了一轮时间，把 Hermes Agent 和 OpenClaw 做了一次偏源码级的对比。
这篇文章不聊首页文案，也不复述 README 里的宣传语，而是重点看几件更本质的事：
- Hermes 的 memory 到底怎么落盘，怎么进入 prompt？
- 它说自己会 learning，是真的能学，还是只是概念包装？
- 它的 delegate / subagent 到底是真隔离，还是“看起来像隔离”？
- gateway、cron、background task 是怎么组织的？
- 如果和 OpenClaw 放在一起看，两者到底代表了哪两种不同路线？
先给结论。
先说结论
如果只用一句话概括：
Hermes 更像会自我成长的成品超级助理，OpenClaw 更像边界清楚、适合长期运营的智能助理 操作系统 。
再展开一点，就是下面三条：
1）Hermes 在“Agent 自我增强”这件事上，走得更激进
Hermes 不是只想做一个“能调用工具的 LLM 包装层”。
从它的设计看，它更想做的是一个：
- 有长期记忆
- 能回忆历史会话
- 能把经验沉淀为 skill
- 能把任务委派给子代理
- 能通过 nudges / cron 继续运转
的长期存在体。
也就是说，Hermes 的核心命题不是“这次任务做得好不好”，而是“这个 agent 会不会越来越强”。
2）OpenClaw 在“平台边界与治理”这件事上，更成熟
OpenClaw 给我的感觉很不一样。
它不是把所有能力尽量揉进一个超级 runtime，而是尽量把这些东西做成平台级对象：
- gateway
- session
- route
- tool policy
- sub-agent
- ACP runtime
- channels
- automation
这种设计的好处是，它可能没有 Hermes 那种“一个 agent 正在长大”的强烈人格感，但它的系统边界更清楚，长期运营更稳。
3）两者不是简单替代关系，而是两种路线
如果你问我，这俩谁更先进，我反而觉得这个问题问得不够准确。
更准确的问法是：
- 你想要一个默认就很完整、很聪明、很会成长的 agent runtime？
- 还是你想要一个适合多渠道、多会话、多 agent、强调隔离和治理的平台底座？
如果是前者，Hermes 很有吸引力。 如果是后者，OpenClaw 更稳。
所以我的判断是：
Hermes 值得深学，OpenClaw 值得深用。
为什么我会得出这个判断？
下面按几个核心点展开。
一、Hermes 的 memory，不是“记一下”，而是正式进入 system prompt
Hermes 在 memory 这块，做得比很多 agent 系统都更彻底。
我在它的 tools/memory_tool.py 和 run_agent.py 里确认到几件事：
- 它把
MEMORY.md和USER.md作为长期记忆来源 - 这些内容会在 session 启动时 作为 frozen snapshot 注入 system prompt
- 它明确提到这样做是为了 preserve the prefix cache
- 运行链路里还有
build_memory_context_block这样的注入逻辑
这意味着什么？
意味着 Hermes 的 memory 不是“临时查一下文件”，而是被当成 prompt 结构的一部分。
这会带来三个明显好处：
- agent 的长期人格和连续性更强
- prompt 前缀更稳定，有利于 cache
- 整体体验更像“一个持续存在的助手”
但它也有代价：
- 因为是 session 启动时冻结的 snapshot，所以 session 内新写入的 memory，不一定马上影响当前 prompt
- 它优先的是“稳定连续”，不是“每轮都动态刷新”
我的看法是：
Hermes 在 memory 上明显优先选择了产品体验，而不是最强的动态一致性。
这也是它为什么会显得更像“一个长期存在的 agent”。
二、Hermes 的 session recall 是内建能力，不是外挂补丁
另一个让我印象很深的点，是 Hermes 的 session search。
很多系统会说自己支持记忆，最后其实只是：
- 写点 markdown
- 向量存点摘要
- 需要的时候临时检索一下
但 Hermes 在这件事上更“工程化”。
我在 hermes_state.py 里看到：
- 它直接使用 SQLite 做 persistent session storage
- 用 FTS5 做全文搜索
- 还用
parent_session_id管理压缩/切分后的 session 链
在 tools/session_search_tool.py 里又能看到：
- 先用 SQLite + FTS5 搜索历史 transcript
- 再把结果交给模型做 focused summarization
- 文档里甚至直接提到了 Gemini Flash summarization 的路径
这说明 Hermes 的 recall 不是“顺手加一个记忆功能”，而是整套系统的一部分。
我会把它理解成两层结构：
- Memory files：长期稳定认知
- Session search：历史行为与上下文回忆
这套设计的价值很大。
因为真正有用的 agent，很多时候不是“知道你喜欢什么”，而是“能回忆起你之前到底做过什么、讨论过什么、卡在哪里、已经验证到哪一步”。
在这一点上，Hermes 的方向是对的，而且完成度不低。
三、Hermes 的 delegate 不是假的，但它更像内部 child runtime
再说子代理。
Hermes 的 tools/delegate_tool.py 很值得看，因为它不是那种“看起来能委派，实际只是同上下文切个分支”的伪子代理。
从代码上看，它明确做了这些事：
- child agent 是 fresh conversation
- isolated context
- restricted toolsets
- own terminal sessions
- 父代理只拿到 delegation call 和 summary result
而且它还显式设置了：
skip_context_files=Trueskip_memory=Trueparent_session_id=...
同时还封掉了一批默认不该给子代理的能力，比如：
- clarify
- memory
- send_message
- recursive delegation
- execute_code
所以如果只问一句：
Hermes 的 subagent / delegate 是不是真的？
我的回答是：是真的。
但问题在于，它的隔离方式更像什么？
我觉得更像：
一个超级 runtime 内部创建的受控 child agent
而不是像 OpenClaw 那样，把 sub-agent 明确提升为平台级工作对象。
这两种方式都能跑，但抽象层级不一样。
- Hermes：更偏“系统内部能力”
- OpenClaw：更偏“平台级运行单元”
这也是为什么我会说，Hermes 更像成品超级助理，OpenClaw 更像操作系统。
四、Hermes 的“会学习”不是宣传词，是真的把 skill evolution 做成了系统能力
如果说 Hermes 最让我觉得“这项目有野心”的点，我会选 skill manager。
在 README 里，它明确写这些内容：
- closed learning loop
- periodic nudges
- autonomous skill creation after complex tasks
- skills self-improve during use
这几个词放在一起，不是在说“我们未来可能支持学习”，而是在说：
学习，就是系统设计目标本身。
更关键的是，源码也能对得上。
在 tools/skill_manager_tool.py 里，我看到它允许 agent 直接：
- create skill
- update skill
- delete skill
- 写 supporting files
- 技能目录就在
~/.hermes/skills/
这说明 Hermes 想做的，不只是“完成一次任务”，而是：
把完成任务的方法，沉淀成下次可复用的能力。
这件事一旦做成，意义是非常大的。
因为一个 agent 系统真正强，不在于它第一次答得多聪明，而在于它能不能把正确做法逐渐固化下来。
当然，副作用也非常明显：
- 你把更深的写权限给了 agent
- skill 质量控制会变难
- skill 污染和错误积累的风险会上升
- 一旦没有强治理，很容易越学越乱
所以 Hermes 在这块的评价，我会给得很高，但同时保留警惕：
这是它最先进的地方，也是最需要治理能力跟上的地方。
五、Hermes 的 gateway / cron / background task，明显是强一体化路线
如果再往系统组织层看，Hermes 的倾向就更明显了。
我在 gateway/run.py 和 cron/scheduler.py 里确认到：
- gateway 直接导入 cron scheduler
- gateway 会起 background thread 驱动 cron tick
- cron 本身就是 runtime 旁边的一部分，不是独立控制平面
这种设计其实非常符合 Hermes 的整体哲学：
- 能收进来就尽量收进来
- 能形成闭环就尽量形成闭环
- 能默认跑起来就不要拆太多组件
这会带来很强的产品感。
用户的感受会是：
- 安装之后很多东西天然就能配合起来
- 记忆、delegate、cron、gateway 更像一体
- 默认体验非常完整
但对应的代价也很清楚：
- 系统边界会更糊
- 故障域更容易互相传染
- 想替换某一层的时候成本更高
所以 Hermes 的问题从来不是“它做得不够多”，而是：
它做得太多，而且尽量揉在一起。
这既是它的魅力，也是它的代价。
六、对照 OpenClaw 后，我更能看清两者的分野
如果只单看 Hermes，很容易得出一种结论：
“这才是下一代 agent。”
但一旦和 OpenClaw 并排看，视角会清楚很多。
OpenClaw 给我的核心感受是：
- 它先把 gateway 定成 single source of truth
- 再把 sessions、routing、channels、tools、subagents、ACP、security 明确拆开
- 它更像一个承载 agent 的平台，而不是 agent 本体本身
比如在 OpenClaw 里：
- sub-agents 是 own session 的平台级对象
- background task 是可追踪对象
- tool policy 是显式治理对象
- session isolation 是明确控制面
- channels 和 runtime 的关系也被文档化得更清楚
这意味着 OpenClaw 的强项，不一定是“一个 agent 本身更聪明”，而是：
整个系统更适合长期运营。
如果你要面对的是：
- 多渠道接入
- 多 agent 协同
- 会话治理
- 权限边界
- prompt injection 风险
- 工具策略控制
- 远期平台演进
那 OpenClaw 这种路线，其实更稳。
七、真正的差别，不是功能多少，而是路线不同
做到这里，我的判断基本就稳定了。
Hermes 和 OpenClaw 的核心差别，不是“谁多一个 feature，谁少一个 feature”。
而是：
Hermes 代表的是一条“超级 Agent 本体”路线
这条路线强调的是：
- 记忆
- 回忆
- 成长
- 自学习
- 经验沉淀
- 内部委派
- 默认闭环
也就是尽量让 agent 本身越来越像一个持续成长的数字个体。
OpenClaw 代表的是一条“Agent 平台 / 操作系统”路线
这条路线强调的是：
- 多渠道
- session
- routing
- 隔离
- tool policy
- runtime orchestration
- ACP / subagents / automation 的平台级组织
也就是尽量让系统本身成为承载很多 agent 工作流的底座。
所以如果你问我：
要不要用 Hermes 替代 OpenClaw？
我的答案是：
不应该这么问。
更合理的问题是：
能不能在 OpenClaw 这种边界清楚的平台上，吸收 Hermes 那种更激进的 learning loop 设计？
我觉得，这才是真正有价值的方向。
八、最后给一个更直接的选型建议
如果你是下面这类需求：
更适合看 Hermes
- 想研究未来 agent 的成长路径
- 想做长期演化型个人助理
- 看重 memory / skill / recall / delegate 的闭环体验
- 愿意接受更强的一体化设计
更适合用 OpenClaw
- 想做长期运营的系统
- 想跑多渠道、多会话、多 agent 协同
- 更看重治理、隔离、安全、平台边界
- 希望架构可控、可替换、可演进
如果让我用一句更偏工程视角的话收尾，我会这么说：
Hermes 解决的是“agent 如何越来越像一个会成长的个体”，OpenClaw 解决的是“如何构建一个长期可运营的 agent 平台”。
这两件事都重要，但优先级取决于你到底是在做“超级助理”，还是在做“超级助理的操作系统”。
