OpenClaw与Hermes对比分析

xluge248

175人浏览 · 2026-07-14 18:19:22

xluge248 · 2026-07-14 18:19:22 发布

两个AI放在一起比一比，才能看清楚各自的长短

——OpenClaw 与 Hermes 架构对比分析

第一章：它们看起来一样，但不是一个妈生的

“有比较才能鉴别。”

实践场景

你在开源社区里发现了两个项目：OpenClaw 和 Hermes。两个都说自己是"AI Agent"。两个都支持自定义技能、都有记忆系统、都能通过 Gateway 对接消息平台、都允许你自托管。

你在资料里翻来覆去地看——功能列表上，这两货长得真像。

但你心里明白：如果它们真是一样的东西，开源社区不会同时维护两个。它们一定在某个根本的地方不一样。只是那张功能对比表看不出来。

引出矛盾

两张功能表几乎重叠，但两个项目独立存在——这本身就说明它们不是同一个东西。如果它们只是同一个理念的不同实现，一定会有一个逐步收敛到另一个，或者一个人做两个分支就够了。

它们都活得好好的、各自在迭代——说明它们在用户那里解决的是不同的需求。

表面上看它们像，实际上它们出发的地方不同：

项目	它是从哪长起来的
OpenClaw	从一个消息路由网关长出来的——先有 Gateway，再长 Agent
Hermes	从一个终端命令行 Agent 长出来的——先有 Agent Core，再加 Gateway

这个"出身"的差异，决定了它们整个骨架的方向。

理论/经验：出身决定骨架

一个程序从哪里长起来，决定了它的设计中心落在哪。

Gateway 出身 → 设计中心是"消息怎么收、怎么路由、怎么分发给对的 Agent"。Agent 的能力是挂在这个主干上的枝叶。
Agent 出身 → 设计中心是"Agent 怎么思考、怎么调工具、怎么管理技能"。消息平台的能力是后来挂上去的扩展。

所以虽然它们长大的样子看起来很像，但内部的优先级完全不同。

回到实践

你在功能对比表上看到两家都有"消息网关"和"Agent Loop"——但 OpenClaw 的消息网关是它从娘胎里带的，Agent Loop 是后来装的；Hermes 的 Agent Loop 是它从娘胎里带的，消息网关是后来装的。

这意味着它俩的长处和短板恰好是互补的。这不是巧合，这是设计中心不同导致的必然结果。

第二章：它们到底哪里一样？

“感觉到了的东西，我们不能立刻理解它，只有理解了的东西才更深刻地感觉它。”
——《实践论》

实践场景

你打开两个项目的文档，看到了它们都有的功能清单：聊天、工具调用、技能系统、记忆、消息平台接入、Cron 调度。

如果只看这一层，你分不出谁是谁。

引出矛盾

既然出身不同，为什么长大的过程会趋同？因为它们都在解决同一个大问题——让大模型从一个"白纸"变成一个"能干活的人"。

这个大问题的解法，不管从哪出发，最终都会收敛到几个核心零件上。

理论/经验：共同的骨架

能力	OpenClaw 的实现	Hermes 的实现
大模型驱动	可配置模型提供商	20+ 提供商可切换，支持 OAuth 池
工具执行	内置工具 + MCP 桥	20+ 工具集，每工具集可开关
技能系统	workspace skills/ 目录 + skill_workshop	skills/ 目录 + Curator + Hub
持久记忆	工作区文件（SOUL/MEMORY/USER/AGENTS.md）	MEMORY.md + USER.md + 外部 RAG
消息网关	原生几十个渠道	Gateway 模式 + 20+ 平台适配器
Cron 调度	内置 cron 系统	内置 cron 系统
MCP 协议	原生（客户端 + 服务端）	原生（客户端 + 服务端）
自托管	完全本地运行	完全本地运行

这些共同点不是巧合。它们是"LLM + 工具 + 记忆 + 技能 + 网关"这个通用 Agent 模型的最小零件集。 少了任何一个，这个 Agent 就不完整：

零件	没有它会怎样
大模型	没有智力
工具	只会说话不会干活
技能	没有可扩展的专业能力
记忆	不认识你是谁
网关	只能在自家院里用
Cron	干不了定时任务

现在回头看——OpenClaw 和 Hermes 像，不是因为有谁抄了谁，是因为做一个 Agent 需要的零件是确定的，你无论从哪出发，最终都要把这些零件凑齐。

回到实践

你看到的"功能一样"，说明这两个项目都已经发展到了同一个成熟阶段——都凑齐了一个完整 Agent 的零件集。

它们的差异在于零件怎么排列、优先级怎么排、谁做得好谁做得一般。 这才是下一章的话题。

第三章：它们到底哪里不一样？

“分析的方法就是辩证的方法。所谓分析，就是分析事物的矛盾。”

实践场景

你要在两个项目之间选一个深度使用。功能表上看不出区别——但你知道它们肯定不一样。你开始看架构文档、设计哲学、CLI 的设计、配置的方式——差异开始浮现了。

引出矛盾

一样的零件，不一样的装配方式，造的就不是同一辆车。

OpenClaw 的零件是围绕"Gateway"装配的——它的心脏是一个 WebSocket 消息路由。所有功能（Agent、技能、工具、记忆）都是这个心脏的附件。

Hermes 的零件是围绕"Agent Core"装配的——它的心脏是一个 Agent 循环。所有功能（Gateway、技能、工具、记忆）都是这个心脏的附件。

这个根本差异体现在方方面面。

理论/经验：七处核心差异

差异一：设计中心不同

维度	OpenClaw	Hermes
心脏	Gateway（WebSocket 消息路由）	Agent Core（Agent 循环）
主要入口	Web 页面 / Telegram / 渠道接入点	终端 CLI
向外看还是向内看	向外——管消息、管路由、管渠道	向内——管技能、管记忆、管工具

差异二：消息处理 vs Agent 能力

OpenClaw 在"怎么收消息、怎么路由"上投入最多——它的 Binding 系统、多 Agent 路由、渠道适配器都是深度定制的。

Hermes 在"Agent 自己怎么变强"上投入最多——Curator 技能管理、自动技能生成、多提供者支持、OAuth 池。

各自做得好	OpenClaw	Hermes
消息路由	Binding 系统，细粒度控制	简单路由，没有多 Agent 原生支持
技能管理	手动管理（skill_workshop）	Curator 自动管理生命周期
多 Agent	原生支持，独立工作区	通过 Profiles 实现，隔离度较低
模型切换	固定一个模型提供商	20+ 提供商，OAuth 池化轮转
扩展方式	Markdown 技能 + MCP 工具	技能 + 插件 + MCP + Python 工具
用户门槛	会写 Markdown 即可扩展	要懂 CLI 命令、配置文件

差异三：与用户交互的缝隙不同

OpenClaw 的典型用法：你通过一个渠道（Web/Telegram/Discord）跟它对话，它回复你。交互是"异步、温和、可跨平台"的。

Hermes 的典型用法：你在终端里打开它，面对面实时聊天。交互是"同步、直接、以 CLI 为中心"的。

交互特征	OpenClaw	Hermes
主要场景	在后台运行，多渠道接入	在前台运行，终端交互
启动方式	常驻 Gateway 服务	即时 CLI 会话
跨平台	原生集成，路由强大	Gateway 模式，需要额外配置
会话管理	会话持久化、恢复	会话持久化、恢复

差异四：技能生态的自动化程度

OpenClaw 的技能是一个手动过程：你写 SKILL.md，你用 skill_workshop 创建/更新/应用。你是技能的管理者。

Hermes 的技能可以自动生成、自动管理：Curator 后台跟踪使用情况，闲置的技能自动 stale 和归档。Agent 自己可以生成技能。

技能管理	OpenClaw	Hermes
创建方式	手动写 + skill_workshop	手动 + 自动（Curator）
生命周期	你管理	Curator 自动管理
Hub 生态	无枢纽	有技能 Hub，可搜索安装
技能文件格式	纯 Markdown	纯 Markdown

差异五：对扩展者的友好度不同

OpenClaw 把扩展门槛降到最低：会写 Markdown 就能加技能。 不用写代码、不用装包、不用编译。SOUL.md 里改一行，Agent 就变一个人。

Hermes 的扩展能力更强——支持 Python 插件、自定义工具、MCP 服务——但门槛也更高。你要懂怎么装 Python 包、怎么注册工具、怎么调试配置。

扩展方式	OpenClaw	Hermes
最低门槛	编辑文本文件	编辑 yaml + CLI 命令
中等扩展	MCP 桥工具	自定义工具（Python）
深度扩展	改源码	插件系统 + 改源码

差异六：Gateway 的实现位置

OpenClaw 的 Gateway 是一等公民——它是服务端的核心组件。服务端运行着 Gateway，Gateway 管着所有的连接、路由、会话。你起一个 OpenClaw，启动的是 Gateway 服务。

Hermes 的 Gateway 是附加模式——它默认不启动，需要显式 hermes gateway run 开启。Agent Core 是主角，Gateway 是一顶可以随时戴上的帽子。

Gateway	OpenClaw	Hermes
默认状态	运行	不运行
核心地位	心脏	配件
配置复杂度	开箱即用	需额外 setup

差异七：记忆系统的架构不同

OpenClaw 的记忆来自工作区文件——SOUL.md、MEMORY.md 等都是用户在工作区目录下手写的文件，每次对话被全量注入系统提示。没有外部 RAG——所有的"记忆"都在文本文件里。

Hermes 虽然也有 MEMORY.md 和 USER.md，但它把内置记忆和外部 RAG 提供者（Hindsight、Honcho、Mem0）分成了两层——内置记忆装不下的事，有专门的检索系统去查。

记忆	OpenClaw	Hermes
内置记忆	工作区文件	MEMORY.md + USER.md
外部 RAG	无	Hindsight / Honcho / Mem0 等
容量限制	无硬上限（全量注入受上下文限制）	2200 + 1375 字符硬上限
更新方式	编辑文件	memory() 工具或直接编辑

回到实践

这些差异不是"一个好一个差"——它们是从不同的设计中心长出来的必然结果。

OpenClaw 先是一个消息网关，后是一个 Agent。所以它的多 Agent 路由是全球最强的，渠道接入是全自动的，技能是手动管理的——因为它的设计哲学是"你配好系统，它自动运行"。

Hermes 先是一个终端 Agent，后是一个消息网关。所以它的 Agent Core 是全球最灵活的，Curator 是自动进化的，技能是可以自己生成的——因为它的设计哲学是"你跟它面对面聊天，它越聊越聪明"。

第四章：各自的长处

“事物都是一分为二的。”

实践场景

你要选一个深度使用。你需要知道：什么场景下 OpenClaw 明显是更好的选择？什么场景下 Hermes 甩 OpenClaw 几条街？

引出矛盾

没有万能的工具。在这套架构里表现最好的，在另一套架构里可能是短板。选工具不是选"哪个更好"，而是选哪个更适合你的用法。

理论/经验：各自长处的结构化对比

OpenClaw 的长处

长处	为什么是长处
多渠道接入原生	不用额外配置 Gateway——一个端口管 WebChat、Telegram、Discord 等，开箱即用
多 Agent 路由成熟	原生支持多个独立 Agent，Binding 系统细粒度控制谁去哪；消息一到自动匹配
技能扩展门槛最低	只要求你能写 Markdown，不需要 Python、不需要懂命令行、不需要配置文件
Gateway 天生稳定	作为常驻后台服务启动，设计目标就是长期运行、自动保活、异常恢复
会话管理精细	DM 隔离、群聊隔离、Cron 独立会话——不同场景不串数据
Cron 内置稳定	定时任务是一等公民，跟主系统深度集成

Hermes 的长处

长处	为什么是长处
Agent 自身能力最强	20+ 工具集、OAuth 池、多提供商切换、20+ 模型提供商随时换
自动技能进化	Curator 自动管理技能生命周期：生成、审计、归档——Agent 越用越好用
记忆系统最深	内置记忆 + 外部 RAG 双架构，既能快又能大
CLI 体验最好	作为一个 CLI 程序，终端交互体验经过了数千次迭代
插件系统最强	Python 插件、MCP 服务、自定义工具——扩展深度最高
提供商最自由	20+ 模型提供商，OAuth 自动轮转，不怕被封

回到实践

选 OpenClaw，如果你是：

一个非程序员，只想配好系统就让它自动跑
你需要在多个消息平台上部署 Agent
你需要多个不同人格的 Agent 同时在线（比如工作助手和家庭助手）
你想用最简单的 Markdown 来扩展能力

选 Hermes，如果你是：

一个终端重度用户，大部分时间在 CLI 里工作
你需要 Agent 自己能不断变强、自动积累经验
你对模型的自由度要求最高——想用哪个用哪个
你需要 Agent 做深度的系统操作、代码开发、数据分析

第五章：各自的短板

“处处有矛盾，时时有矛盾。”
《矛盾论》

实践场景

你用 OpenClaw 用了一段时间，发现某些它不太顺手的地方。你又试了试 Hermes，也发现了那边的痛点。你开始想：没有完美的框架，每个选择都有代价。

引出矛盾

每一个长处，反面都是一个短板。设计中心的取舍必然导致另一边照顾不周。

理论/经验：短板的结构化对比

OpenClaw 的短板

短板	为什么是短板
Agent 自身进化能力弱	技能不能自动生成、没有 Curator 机制——你写了什么技能，它就有什么技能，不会自己变强
多模型切换不灵活	固定一个模型提供商，切换需要改配置重启
无外部 RAG 记忆	没有配置外部 RAG 提供者——记忆扩容需要手动编辑文件
CLI 不是核心入口	作为 Gateway 服务，CLI 是管理工具，不是主要交互窗口
技能管理是纯手工	skill_workshop 管理技能需要你主动介入——没有自动生成、没有枢纽安装
插件系统有限	主要扩展方式是 Markdown + MCP 桥，不像 Hermes 那样可以用 Python 写插件

Hermes 的短板

短板	为什么是短板
Gateway 不是一等公民	需要显式启动、额外配置——不是开箱即用的多消息平台
多 Agent 隔离弱	Profiles 做不到 OpenClaw 那样的绑定细粒度——一个 channel 只能绑定一个 profile
技能文件可能会积累过多	Curator 虽然自动管理，但不删除——闲置技能文件会一直占着磁盘
配置复杂度高	要懂 config.yaml、.env、profiles、toolsets 多套配置——入门比 OpenClaw 陡峭
无原生多 Agent 路由	没有 OpenClaw 那样的 Binding 系统——多个 Agent 共存的场景需要自己折腾
记忆容量严格受限	内置记忆 2200 + 1375 字符硬上限——配置外部提供者才能突破

回到实践

OpenClaw 的短板集中在一个方向：Agent 自己的进化能力不足。 它适合"你配好了它就一直这样用"的场景。

Hermes 的短板集中在另一个方向：消息路由和多 Agent 管理不够成熟。 它适合"一个人用一个 Agent"的场景。

选择就是接受短板的过程。

第六章：它们不是竞品，是互补品

“内因是变化的根据，外因是变化的条件。”
——《矛盾论》

实践场景

你纠结了很久选哪一个。但你突然想到一件事：为什么不能两个都要？

引出矛盾

如果你把 OpenClaw 和 Hermes 当竞争关系——“我该选谁”——那你关注的是它们重叠的部分。但如果你把它们当互补关系——“我能不能让它们合作”——你关注的是它们各自的长处能不能互相弥补。

两个项目都是开源的，都支持 MCP 协议，都能在本地安装。技术上没有墙。

理论/经验：双 Agent 协作架构

把长短互补的两套架构放在一起，会产生新的能力：

        用户
          ↓
    OpenClaw（大脑/网关）
     ├── 多渠道接入（Web/Telegram/Discord）
     ├── 多 Agent 路由（工作/生活/实验）
     ├── Binding 系统（精细控制谁去哪）
     ├── 会话管理（隔离+恢复）
     └── MCP 客户端 →   Hermes（工具手）
                          ├── 20+ 工具集（terminal/file/web/vision……）
                          ├── Curator 自动技能进化
                          ├── 内置+外部双重记忆
                          ├── 20+ 模型提供商
                          └── Python 插件系统

各自负责最擅长的部分：

职责	谁干	为什么
消息路由	OpenClaw	它的 Gateway 天生就是干这个的
多 Agent 人格	OpenClaw	Binding 系统是最成熟的
工具执行	Hermes	20+ 工具集 + Python 插件
技能进化	Hermes	Curator 自动管理
终端交互	Hermes	CLI 体验世界一流
技能定义	OpenClaw	Markdown 门槛最低
深度扩展	Hermes	插件系统 + 自定义工具

这种协作关系在技术上是可行的——通过 MCP 协议，OpenClaw 作为 MCP 客户端，把 Hermes 的 12 个核心工具当成自己的工具来用。

回到实践

最终你也许不需要选——两台机器上跑着 OpenClaw 和 Hermes，一台管思考，一台管执行；一台管消息出入，一台管干活出力。

这不是"用谁来取代谁"的问题，是"你的 AI 系统里，需要大脑还是需要手脚，还是两个都要"的问题。OpenClaw 更适合当大脑——管信息流、管路由、管交互界面。Hermes 更适合当工具手——执行操作、管理技能、积累经验。

两个割裂起来看，各有长短。两个拼在一起看，长短互补。

小结

“有比较才能鉴别。”

OpenClaw 和 Hermes，不是同一个产品门类里的不同品牌——它们是同一个 Agent 生态中的不同工种。

对比	OpenClaw	Hermes
出身	消息网关 → 加 Agent	Agent Core → 加消息网关
心脏	WebSocket 路由	Agent 循环
最强项	消息路由 / 多 Agent / Markdown 技能	CLI 体验 / 自动进化 / 工具集
最弱项	Agent 自身进化弱 / 模型单一	多 Agent 隔离弱 / 配置复杂
适合	非程序员的自动化运营	程序员的深度开发
可以当	大脑（网关 + 路由）	工具手（执行 + 技能）