OpenClaw vs Hermes Agent：一个深度用户的对比调研

调研时间：2026-04-20 | 基于作者 54 天 OpenClaw 实装经验 + 4 月 11 日首轮 Hermes 调研更新

最近一直刷到 Hermes ，看到很多人从 OpenClaw 转投了 Hermes，心里痒痒的，在考虑是不是也迁移玩玩，于是有了下面这个深度调研报告 

•  报告全程由 OpenClaw 完成，Skill 是自己写的https://github.com/Gracker/gracker-deep-research-skill^[1] ，调研过程中会先阅读本地大量的我之前保存的资料（Obsidian），然后启用多个 Agent （Minimax、GLM）去网上搜一手资料，最终由 GPT5.4 撰写。 
  

• 润色使用的 Skill 是我自己调教的：https://github.com/Gracker/gracker-writing^[2] 。没办法，AI 黑话和翻译腔太多了，如果你觉得结果还行可以点个 star 
  

• OpenClaw 的数据是我自己真实的数据，非杜撰，OpenClaw 每天都有记录
  

• 决定暂时先不迁移，一是让 OpenClaw 和 Hermes 的子弹再飞一会。二是 OpenClaw 目前在跑比较重要的几个项目，还有那些日报、调研等 Task ，结果我现在非常满意，所以没有那么强烈的迁移的动力 
  

• Obsidian 太好用了，再次夸一下这个 App，Claudian 插件 + Velocity 主题 + Cubox 同步，知识库直接就闭环了。同步使用 iCloud ，家里的 Apple 设备都可以直接访问，贼方便。 
  

• OpenClaw 和 Things 的联动效果还不错，每日提醒会有 Things 里面的 Todo 提醒，调研缺口也会记录到 Things 里面提醒我，一些比较重要的事情也会记录到 Things 里面。我完成了他也知道，算是闭环了。

摘要

Hermes Agent 是 Nous Research 在 2026 年 2 月发布的开源 AI Agent 框架，核心差异在于内建的 closed learning loop。Agent 会从执行轨迹里提炼模式，自动生成并迭代 Skill，而不是完全依赖人工维护。自进化子系统基于 DSPy + GEPA（ICLR 2026 Oral），单次优化成本约 $2-10，Phase 1（SKILL.md 优化）已经可用。

OpenClaw 的定位是 control plane first。它提供一个可靠的控制平面，负责多通道路由、cron 调度、工具编排和长期记忆管理。Hermes 的定位是 learning loop first，重点是让 Agent 在使用中越跑越准。

作者从 2026 年 2 月 26 日开始使用 OpenClaw，至今 54 天，实装了 126 个 cron 任务、66 个 Skill、471 条 memory 记录、10000+ 篇 Obsidian 文档。本文结合这套实装体系的具体数据和踩坑经验，对两个框架做一次工程视角的详细对比。

结论：现阶段不建议全量迁移。更合理的路径是并行运行——OpenClaw 继续负责编排与调度，Hermes 承担能从自改进中持续获益的任务。

---

一、为什么做这次对比

2026 年 2 月底装 OpenClaw 的时候，我的预期很简单：后台帮我干活，不用管。监控 GitHub 趋势、日报、Twitter 内容总结、各平台 Android 信息收集。50 多天后，这套体系已经成了我离不开的东西：

指标	数据
cron 任务	126 个（含 AIW 流水线 9 个 Task）
Skill	66 个（baoyu 系列、technical-writing、deep-research 等）
memory 记录	471 个文件，3543 chunks，vector+fts 双索引
Obsidian 文档	10029 篇 Markdown
连接通道	Telegram、微信、Discord
模型配置	primary: openai-codex/gpt-5.4，fallback: glm-5-turbo / MiniMax-M2.7
每日 token 消耗	约 200-400K（含 cron）

但 54 天的使用也暴露了一系列真实问题：Skill 迁移成本被低估、memoryFlush 格式不规范导致检索命中率低、cron 并发超 API 限制、LLM 判断误判任务完成、复杂任务没有进度跟踪机制。

Hermes Agent 的自学习系统恰好声称要解决其中一部分问题——尤其是"Skill 越用越好"和"自动从执行中提炼模式"。这次调研要回答的问题就是：Hermes 的自学习到底能做到什么程度，值不值得投入迁移成本。

---

二、架构哲学的分叉

功能表放在一起对比不难，但要先搞清两个框架的根假设，否则对比只剩数字堆砌。

OpenClaw：控制平面优先

OpenClaw 的根假设是：用户缺的不是"会自己生长的 Agent"，而是一个可靠的控制平面。能接多通道、跑 cron、分发任务、调用工具、管理上下文，还要长期稳定在线。

架构上，OpenClaw 是一个 TypeScript 单进程 Gateway + Node.js daemon，作为所有消息、工具、session 的中枢：

50+ 消息通道 ──→ OpenClaw 控制平面
                    ├── Gateway（消息路由）
                    ├── session 管理
                    ├── cron 调度器
                    ├── tool 执行环境
                    ├── skill 加载器
                    └── memory 子系统

OpenClaw 由此赢在系统化运营能力。多群路由映射、AGENTS.md 上下文隔离、HEARTBEAT 定期巡检、Webhook 外部触发，这些机制组合起来就是一个稳定的 24/7 在线运营系统。

Hermes：适应性优先

Hermes 的假设正好相反。它认为很多用户并不想持续设计 Agent 的行为，只想让 Agent 在真实任务里越跑越准。

架构上，Hermes 是 Python 多后端系统，核心是 AIAgent Loop + 三层记忆 + 学习循环：

消息通道 ──→ Gateway
              ├── AIAgent Loop（核心引擎）
              ├── 三层记忆（笔记 + FTS5 会话 + Skill）
              ├── 用户建模（Honcho dialectic）
              └── 自进化子系统（DSPy + GEPA）

Hermes 由此赢在程序性知识的自动演化。Skill 会随任务执行持续演化，不是写完就定型的说明书。

这是产品哲学层面的分叉。 OpenClaw 在回答"怎么把 Agent 变成一个可运营系统"；Hermes 在回答"怎么让执行本身变成训练数据"。

---

三、Hermes 自学习系统：这是它最值得看的部分

Hermes 的 closed learning loop 是整个框架的核心差异化，包含两个层次。

3.1 运行时学习循环

对一次复杂任务，Hermes 不只关心"有没有完成"，还会回头分析"这次为什么能完成"，然后把可复用模式写成可重复使用的规则。

流程是：

1回溯执行轨迹：识别任务中关键的步骤和判断点

2提取成功模式：把关键步骤抽象为通用工作流

3生成 Skill 文件：以 Markdown 形式写入 Skill 系统

4后续使用中继续优化：根据实际执行效果改写 Skill

Skill 由此从人类手写文档变为 Agent 在执行中积累的程序性记忆。如果让它反复做 Android 性能调研或结构化写作，它理论上会越来越像一个在这个领域受过训练的执行者。

官方数据称，自改进后重复任务完成速度可提升约 40%[1]。

3.2 自进化子系统：DSPy + GEPA

hermes-agent-self-evolution 是独立项目，目标是系统化优化 Agent 的 Skill、工具描述和系统提示词。当前核心组合：

•DSPy：Stanford NLP 出品的声明式 LLM 编程框架，把 LLM 调用从手写 prompt 提升为可声明、可组合、可优化的程序结构

•GEPA（Genetic-Pareto Prompt Evolution）：ICLR 2026 Oral 论文，通过执行轨迹分析失败原因，生成多个候选变体，在多个目标之间寻找 Pareto 最优

GEPA 的价值不在"调 prompt"，而在回答一个更关键的问题：这次失败，到底是 prompt 的哪一部分在拖后腿？

GEPA 的精确工作机制

传统 prompt 优化（包括 RLHF）通常只看最终正确率，把优化当成黑箱。GEPA 的做法是打开黑箱，看中间过程：

读取当前 Skill/Prompt
      ↓
生成评估数据集（基于历史执行轨迹）
      ↓
Pareto 选择（从候选池中选"非支配"父代）
      ↓
执行并捕获完整执行轨迹
（推理日志、工具调用、工具输出、错误消息、profiling 数据）
      ↓
自然语言反思（LLM 读取轨迹，诊断失败根因）
      ↓
生成 N 个候选变体（基于诊断的定向突变）
      ↓
约束门控：
  - pytest 测试 100% 通过
  - Skill ≤ 15KB，工具描述 ≤ 500 字符
  - 语义保持（不能偏离原始用途）
  - 禁止会话中修改
      ↓
Pareto 最优选择（多目标：准确率 + 成本 + 延迟）
      ↓
最佳变体提 PR → 人工审核后合并

几个关键细节：

•Golden Splitting：初始时把复合 AI 系统拆成独立可优化的 prompt 组件

•频率加权采样：从 Pareto 前沿选父代时，平衡探索与利用，防止陷入局部最优

•祖先经验继承：每个突变可以继承搜索树中祖先的累积教训，不是每次从零开始

•System-aware Merge：最终可以把不同 Pareto 最优候选的优势合并

和 RLHF 的区别：RLHF 给的是 sparse scalar reward（"对"或"错"），GEPA 给的是 rich natural language feedback（"为什么错、哪里错、怎么改"）。GEPA 因此在更少的迭代次数下就能收敛。

单次优化成本约 $2-10，纯 API 调用，无需 GPU[2]。

路线图与当前局限

Phase	目标	引擎	状态
1	Skill 文件（SKILL.md）	DSPy + GEPA	✅ 已实现
2	工具描述	DSPy + GEPA	🔲 计划中
3	System Prompt 段落	DSPy + GEPA	🔲 计划中
4	工具实现代码	Darwinian Evolver	🔲 计划中
5	持续改进管道	自动化 pipeline	🔲 计划中

注意，Phase 1 已经可以直接运行：

# 使用合成评估数据
python -m evolution.skills.evolve_skill \
  --skill github-code-review \
  --iterations 10 \
  --eval-source synthetic

# 使用真实会话历史（Claude Code / Copilot / Hermes）
python -m evolution.skills.evolve_skill \
  --skill github-code-review \
  --iterations 10 \
  --eval-source sessiondb

但 Phase 4（代码层进化）和 Phase 5（持续管道）还只是计划。说 Hermes "已经可以自动优化一切"是夸大了——Skill 自进化已可运行，完整的全栈自进化还需要时间。

3.3 用户建模：Honcho dialectic

Hermes 接入了 Honcho 风格的用户建模能力，把用户偏好从静态键值对升级为随交互逐步加深的画像体系。Agent 可以据此积累用户偏好、决策模式、边界条件，再反向影响后续对话与执行策略。

和 OpenClaw 的 USER.md 手工维护相比，这种方式更自动化。但它的深度受限于 MEMORY.md 约 2,200 字符预算，在知识密集场景下会明显受限。

---

四、技术对比：逐维度展开

4.1 记忆系统

维度	OpenClaw	Hermes Agent
长期记忆	MEMORY.md + memory/*.md + 向量索引（3543 chunks）	MEMORY.md + SQLite FTS5 + 用户建模
检索方式	语义检索（vector）+ 关键词检索（fts）	关键词检索（FTS5）+ 规则匹配
记忆容量	几乎无硬限制（文件系统）	MEMORY.md 约 2,200 字符预算
自动整理	cron 定时任务（autoDream 等）	periodic nudge 机制
知识管理方法	三层记忆维护体系（日记层 + 核心层 + 向量层）	内建 periodic evaluation

OpenClaw 在记忆深度上有明确优势。471 条 memory 记录 + 3543 chunks + 向量索引，是一套经过 54 天实际验证的知识管理体系。Hermes 的 FTS5 擅长关键词命中，速度快，但在跨表达方式的语义匹配上不如向量索引。

Hermes 的 periodic nudge（周期性评估哪些信息值得固化）是一个聪明的设计，OpenClaw 目前没有对等机制——记忆整理完全依赖 cron 任务 + 人工规范。

4.2 Skill 系统

维度	OpenClaw	Hermes Agent
Skill 来源	人工编写 + ClawHub 市场（100+）	自动创建 + 自动进化 + agentskills.io
Skill 格式	SKILL.md（Markdown）	SKILL.md（Markdown，格式基本兼容）
Skill 优化	人工迭代	DSPy + GEPA 自动优化
Skill 市场	ClawHub（clawhub.com）	agentskills.io（成长中）
实际可用 Skill 数	66 个（我的实装）	社区规模较小

Hermes 的 Skill 自动进化是核心差异化。在 OpenClaw 里，我写一个 deep-research Skill 大概花了 2-3 天，后续微调又花了若干次。如果 Hermes 的 GEPA 能自动做这件事，长期来看会显著降低维护成本。

但短期来看，OpenClaw 的 66 个 Skill 是已经验证可用的资产。Hermes 的 Skill 生态还在成长阶段，迁移后大概率需要逐个验证。

4.3 Agent 调度与编排

维度	OpenClaw	Hermes Agent
定时任务	openclaw cron，126 个任务稳定运行	内置 cron scheduler
多 Agent	sessions_spawn（sub-agent / ACP）	subagent delegation
多群路由	AGENTS.md + 群映射表（8 个 Telegram 群）	Profiles 多实例系统
Heartbeat	30 分钟心跳巡检	Smart Inactivity Timeout
Webhook	原生支持	无直接等价物

OpenClaw 在编排深度上明显领先。8 个 Telegram 群各有明确功能定位（Writer、知识库、Android、Daily、Action、Twitter、EBook、Image），通过群映射表路由。这套体系是长期运行时最值钱的基础设施之一，Hermes 的 Profiles 能做实例隔离，但无法自然复用成"单系统、多群、多角色"的控制面。

4.4 安全

维度	OpenClaw	Hermes Agent
执行隔离	Docker sandbox（可选）	容器隔离 + 命名空间隔离
Skill 安全	ClawHub 审核 + 本地信任	内部生成，无外部市场供应链风险
MCP	原生支持	原生 + OAuth 2.1 PKCE
ACP	mcporter + acp-router	原生 ACP server
恶意软件扫描	无内置	自动扫描

Hermes 在默认安全特性上更激进：Skill 内部生成（避免供应链攻击）、强制容器隔离、自动恶意软件扫描。OpenClaw 的安全更偏工程化配置，用户需要自己决定信任边界。

4.5 部署

维度	OpenClaw	Hermes Agent
运行时	Node.js	Python
本地部署	macOS / Linux / Windows(WSL2)	Local / Docker / SSH
云部署	Docker / VPS / ClawBox	Docker / SSH / Daytona / Singularity / Modal
迁移工具	无（OpenClaw 是"源"）	hermes claw migrate

Hermes 在终端后端选择上更清晰，尤其是 Daytona（云开发环境）和 Modal（Serverless），对需要弹性运行环境的团队场景更友好。

---

五、迁移成本：逐项评估

Hermes 提供了 hermes claw migrate 迁移工具，可以自动导入一部分 OpenClaw 配置。但"能导入"不等于"能无缝替换"。

5.1 按 Gracker 实装逐项评估

维度	难度	预估工时	备注
SOUL.md / IDENTITY.md	低	0.5h	格式基本兼容
USER.md	低	0.5h	直接导入
基础 Memory	中	2-4h	2200 字符预算需裁剪重组
Telegram 连接	低	1-2h	token + user ID + 路由验证
简单 Skill（10-20 个）	低-中	4-8h	标准格式可迁，需验证效果
复杂 Skill（baoyu 系列，15+ 个）	高	16-24h	逐个适配、调试、回归测试
deep-research Skill	高	8-12h	含 sub-agent 编排、多阶段流程
AIW Pipeline（Task 2B/6/9/12）	极高	24-40h	含 queue 管理、质量门控、自动晋升
Cron 任务（126 个）	中	8-12h	逐个重建，语法与行为模型不同
多群路由 + AGENTS.md	高	8-16h	Hermes 无等价一键迁移路径
HEARTBEAT 机制	中	4-6h	可模拟，行为语义不同
Webhook / TaskFlows	高	需自行实现	当前无直接等价物
MCP 工具配置	中	4-6h	协议相同，配置格式不同
X/Twitter 内容系统	中	4-8h	Skill + 投递流程都要复核
Obsidian 整合	低	2h	底层仍是文件系统操作

总工时估算：3-4 周全职等效工作量。 这还是在"不重构业务流程，只迁运行链"的前提下。

5.2 不可替代的核心资产

以下能力不是简单"配置搬过去"就能解决的：

1memory-wiki 知识系统：结构化日志前缀（## [HH:MM] ingest | ...）、cron 连续失败 3 次自动熔断、技能复利规则（手工验证 → Skill 化 → cron 化）、Wiki Lint 健康检查。这是一整套 AI 协作知识管理方法论，Hermes 没有现成对等实现。

2AIW 流水线：Task 6（文风 Review）→ Task 9（技术审计）→ Task 2B（回炉修复）→ 自动晋升 finalized，含 queue 管理、质量门控、多模型 fallback。这套体系在 Hermes 里需要从零搭建。

3多群路由体系：8 个 Telegram 群各有明确功能定位，通过群映射表和投递规则路由。这是长期运营积累出来的控制面资产。

5.3 迁移收益与成本对比

收益端：
 - 自改进循环，任务做得越多 Skill 理论上越准
 - Skill 自动生成，减少手工编写和维护
 - 用户建模自动化更强
 - 部署后端选择更灵活

成本端：
 - 3-4 周迁移工时
 - 126 个 cron 任务需要重建
 - 66 个 Skill 需要逐个验证
 - MEMORY.md 容量受限（2200 字符），长期知识深度下降
 - 社区生态差距（47k vs 354k stars），遇到问题时更难找到成熟解法
 - Hermes 仍处于快速迭代阶段（v0.8.0，2026 年 4 月 8 日发布），接口和行为可能持续变化

短期 ROI 为负。 Hermes 的长期价值存在，但对已经深度定制 OpenClaw 的用户来说，这些收益在短期内不足以覆盖迁移成本。

---

六、建议：并行运行，分阶段验证

6.1 推荐架构

┌─────────────────┐
                │   OpenClaw      │
                │  （编排调度层）  │
                │                 │
Telegram ──────→│  多群路由       │
微信 ──────────→│  126 cron 任务  │
Discord ───────→│  HEARTBEAT      │
                │  Webhook        │
                │  AIW Pipeline   │
                └────────┬────────┘
                         │
                ┌────────▼────────┐
                │  Hermes Agent   │
                │   （学习执行层） │
                │                 │
                │  自改进循环      │
                │  Skill 进化     │
                │  用户建模       │
                └─────────────────┘

6.2 实施路径

Phase 1（1-2 天）：部署 Hermes 实例
 - 在 Mac Studio 上部署，先把基础消息通道和模型配置配好
 - 用 hermes claw migrate 导入基础 persona 和 memory

Phase 2（1 周）：选 2-3 个任务做试点
 - 推荐：深度调研（deep-research）、周期性摘要（RSS Digest）、结构化写作
 - 这三类任务有明确的成功标准，适合观察 Skill 进化效果

Phase 3（2-4 周）：观察质量复利
 - 重点看 Skill 质量是否随使用显著提升
 - 看 GEPA 优化后的 Skill 是否比手工版本更准或更快
 - 记录每次优化的成本和收益

Phase 4（按需）：扩大或收缩
 - 如果试点效果成立，扩大 Hermes 的职责边界
 - 如果效果不达预期，Hermes 降级为实验工具，OpenClaw 保持主力

6.3 可以反向吸收的成果

即使最终不迁移，并行运行也有价值：如果 Hermes 产出了高质量 Skill 或 workflow，总可以移植回 OpenClaw 体系。GEPA 优化过的 SKILL.md 格式基本兼容，手动移植成本不高。

---

七、关键判断

1Hermes 的自学习系统是真实可用的，但范围有限。 Phase 1（SKILL.md 优化）已经可运行，Phase 2-5 还在 roadmap 中。不要把它想象成"Agent 可以自己写代码优化自己"，至少目前不行。

2GEPA 的核心价值是"诊断根因"而非"调参"。 它通过自然语言反思分析执行轨迹，理解为什么失败，再提出定向改进。这比传统 RLHF 的 sparse reward 更高效，也更可解释。

3MEMORY.md 2200 字符预算是当前最现实的结构性约束。 对轻量助手场景没问题，对需要深度知识积累的用户会直接压缩可表达的信息密度。

4社区体量差距（354k vs 47k）会在真实使用中放大。 模板、案例、踩坑经验、第三方集成数量差一个级别，真正开始迁移时，这些差距会变成工程成本。

554 天 OpenClaw 实装积累的运营方法论无法一键迁移。 memory-wiki 体系、AIW 流水线、多群路由——这些是"用出来的资产"，不是"配出来的功能"。

---

参考资料

1hermes-agent-self-evolution^[3] — Nous Research，自进化子系统源码 [一手：源码]

2Hermes Agent 官方仓库^[4] — Nous Research [一手：源码]

3OpenClaw 官方仓库^[5] — OpenClaw [一手：源码]

4OpenClaw 文档^[6] — 架构、配置、安全 [一手：官方文档]

5DSPy^[7] — Stanford NLP，声明式 LLM 编程框架 [一手：源码]

6GEPA (ICLR 2026 Oral)^[8] — Genetic-Pareto Prompt Evolution [一手：论文]

72026-04-11 Hermes Agent 深度调研 — 作者首轮调研 [本地：memory]

8OpenClaw 实装经验记录 — 54 天使用记录 [本地：memory]

---

本报告基于 2026 年 4 月 20 日可获取的信息撰写。Hermes Agent 仍处于快速迭代阶段（当前 v0.8.0），部分判断需要随版本演进持续复核。

参考链接

[1] https://github.com/Gracker/gracker-deep-research-skill: https://t.co/DaOCOaK1eD

[2] https://github.com/Gracker/gracker-writing: https://t.co/fXUUHfX5Dd

[3] hermes-agent-self-evolution: https://github.com/NousResearch/hermes-agent-self-evolution

[4] Hermes Agent 官方仓库: https://github.com/NousResearch/hermes-agent

[5] OpenClaw 官方仓库: https://github.com/openclaw/openclaw

[6] OpenClaw 文档: https://docs.openclaw.ai

[7] DSPy: https://github.com/stanfordnlp/dspy

[8] GEPA (ICLR 2026 Oral): https://openreview.net/forum?id=gepa-iclr2026