第十三册:OpenClaw 对比与迁移
本章你将学到
- 为什么技术选型如此重要,以及如何用系统化的方法做决策
- Hermes 与 OpenClaw 在 12 个维度的深度对比(配详细分析)
- 两个项目最核心的差异:自学习 vs 手动配置、有界记忆 vs 模块化记忆
- 四个主流框架的官方定位和适用场景
- 详细的选型决策树,帮你找到最适合自己的工具
- 从 OpenClaw 迁移到 Hermes 的完整步骤和常见问题
- Hermes 与 OpenClaw 共存的最佳实践
预计阅读时间:90-120 分钟
特别提示:本章力求客观公正。Hermes 和 OpenClaw 都是优秀的开源项目,本章的目标是帮助你做出最适合自己的选择,而非贬低任何一方。
1. 为什么需要一章专门对比
1.1 "养虾"和"养马"的选择之困
在前面的章节里,我用了"养马"来比喻使用 Hermes——你需要了解它、训练它、照顾它,它才能成为你得力的伙伴。但如果你去社区里逛一圈,会发现有很多人还在"养虾"——用另一种同样优秀的 AI Agent 框架 OpenClaw。
这就带来了一个问题:我该养虾还是养马?
我见过太多人在这个选择上纠结不已:
- 有人两个都装了,结果哪个都没学好
- 有人跟风选了热门的,后来发现不适合自己的工作流
- 有人死守一个拒绝尝试另一个,错过了更好的功能
- 还有人频繁切换,每次迁移都浪费大量时间
类比
选 AI Agent 框架就像选交通工具。OpenClaw 像是一辆配置丰富的 SUV——空间大、功能全、能装很多东西,但油耗也高。Hermes 像是一辆轻量级的电动跑车——启动快、操控灵活、充电便宜,但 cargo 空间没那么大。如果你要穿越荒野,SUV 更合适;如果你要在城市通勤,电动车更省心。没有绝对的好坏,只有适合不适合。
1.2 两个项目的社区规模与增长数据
在做选择之前,让我们先看看数据。
| 指标 | Hermes Agent | OpenClaw |
|---|---|---|
| GitHub Stars | 104,791(2026年4月) | 309,000+ |
| 首次发布 | 2026年2月 | 2025年11月 |
| Star 增长速度 | ~52k/月(前两个月) | ~26k/月(高峰期) |
| 贡献者数量 | 500+ | 2000+ |
| 社区 Discord 成员 | 45,000+ | 150,000+ |
| 月度活跃 issues | 800+ | 1200+ |
| 已发布版本 | v1.2.3 | v2.1.0 |
数据解读:
OpenClaw 的 Star 数遥遥领先,这是它一年多的积累。Hermes 虽然 Star 数暂时落后,但增长速度是 OpenClaw 峰值的两倍。这个增长速度说明社区对 Hermes 有很高的期待。
但 Star 数不是一切。很多 Star 是"收藏了准备以后看",不代表实际使用者。真正重要的是:哪个框架能更好地解决你的问题?
Tips
不要仅凭 GitHub Star 数做选择。Star 数反映的是"关注度",不是"好用度"。很多小而美的工具 Star 数不高,但在特定场景下比大项目更好用。建议你两个都试一周,亲身体验比任何数据都靠谱。
1.3 本章的客观立场声明
在正式对比之前,我需要声明本章的立场:
第一,我是 Hermes 白皮书的作者,但我首先是 AI Agent 领域的研究者。 我同时在使用 Hermes、OpenClaw、Claude Code 和其他工具。本章的对比基于实际使用体验和技术分析,而非商业利益。
第二,两个项目都有优秀的团队和活跃的社区。 OpenClaw 在 2025 年创造了 AI Agent 开源项目的 Star 增长纪录,它的社区贡献者和生态系统是 Hermes 需要追赶的。Hermes 在架构设计和创新功能上走出了自己的路,但它在社区成熟度上还有成长空间。
第三,大多数高级用户最终都会同时使用多个工具。 这不是"二选一"的选择题。就像摄影师不会只有一个镜头,高级 Agent 用户也不会只用一个框架。
注意
如果你在阅读本章时发现某个描述让你感觉"作者在贬低 OpenClaw"或"作者在夸大 Hermes",请告诉我。我承诺保持客观,如果有失偏颇,那一定是我的疏忽而非故意。
2. 项目背景对比
2.1 OpenClaw:独立开发者的杰作
创始人:Peter Steinberger
OpenClaw 的创始人 Peter Steinberger 是一位来自奥地利的独立开发者。在 AI Agent 领域爆发之前,他已经是 iOS 开发社区的知名人物——他创建的开源 PDF 库 PSPDFKit 被全球数万个应用使用。
Peter 在 2025 年初看到了 AI Agent 的潜力。他认为:"大语言模型已经足够聪明了,我们只需要给它配上合适的工具,它就能完成很多工作。"这个理念催生了 OpenClaw。
发布与成长
2025 年 11 月,OpenClaw 在 GitHub 上开源。最初的版本非常简洁——一个 TypeScript 项目,核心功能是让 AI 能够调用本地文件系统和命令行工具。但正是这种简洁,让它迅速获得了开发者的青睐。
OpenClaw 的爆火有几个关键因素:
- 时机刚好:2025 年底是 AI Agent 概念最热的时候
- 创始人影响力:Peter 在开发者社区有很高的声誉
- 设计哲学清晰:Unix 哲学——一个工具做好一件事
- TypeScript 生态:前端开发者最容易上手
到 2026 年初,OpenClaw 的 GitHub Star 数突破了 30 万,成为 GitHub 历史上增长最快的项目之一。
类比
Peter 和 OpenClaw 的故事,有点像 Linus Torvalds 和 Linux。一个技术极客,看到了行业的一个痛点,用简洁优雅的方案解决了它,然后整个社区就自发地围绕它建立起了生态。不同的是,Peter 是在 AI 时代做了一件类似的事。
2.2 Hermes:研究机构的专业之作
背后团队:Nous Research
Hermes 的背后是 Nous Research,这是一家在 AI 研究界颇有名气的机构。不同于 OpenClaw 的"个人项目"起点,Hermes 从诞生之初就带着"研究驱动"的基因。
Nous Research 在 2024-2025 年间完成了 6500 万美元的融资,投资方包括多家知名风投。这笔资金让他们能够组建一个全职的工程师和研究团队,专注于 Agent 架构的长期研发。
从 OpenClaw 到 Hermes 的演进
有趣的是,Nous Research 团队早期也是 OpenClaw 的活跃用户和贡献者。在使用过程中,他们发现了一些架构层面的局限性:
- 记忆管理不够灵活:OpenClaw 的记忆系统基于文件存储,在大规模使用时性能受限
- 技能系统是静态的:新技能需要手动编写,Agent 不会自己"学习"
- 配置复杂度:随着功能增加,配置文件变得越来越复杂
- TypeScript 的性能瓶颈:某些计算密集型任务在 Node.js 中表现不佳
这些观察促使 Nous Research 决定:不是给 OpenClaw 打补丁,而是重新设计一个 Agent 框架。2026 年 2 月,Hermes 诞生了。
注意
Hermes 不是 OpenClaw 的"竞争者",而是"进化者"。Nous Research 团队在很多场合都表达了对 Peter 和 OpenClaw 社区的尊重。两个项目的开源协议都是 MIT,代码和理念都在互相借鉴。开源社区的健康发展,需要这种"百花齐放"而非"你死我活"的氛围。
2.3 开源协议对比(MIT vs MIT)
两个项目都使用 MIT 许可证,这意味着:
- 你可以自由地使用、修改、分发
- 可以用于商业用途
- 不需要开源你的衍生作品
- 只需要保留原始版权声明
MIT 许可证的核心条款
版权所有 (c) [年份] [作者]
特此免费授予任何人获得本软件及相关文档文件("软件")的副本,
不受限制地处理本软件,包括但不限于使用、复制、修改、合并、
发布、分发、再许可和/或销售软件副本的权利,并允许向其提供
软件的人这样做,但须符合以下条件:
上述版权声明和本许可声明应包含在本软件的所有副本或实质部分中。
Tips
MIT 是开源世界最宽松的许可证之一。对于商业用户来说,这意味着你可以放心地把 Hermes 或 OpenClaw 集成到你的产品中,不用担心法律风险。但记得保留版权声明——这是唯一的要求。
2.4 商业模式对比
虽然两个项目都是开源的,但它们的商业模式有所不同:
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 核心收入 | 个人捐赠、GitHub Sponsors | 研究机构资助、企业咨询 |
| 商业化路径 | 较慢,保持独立 | 可能更快,有投资人期待 |
| 企业服务 | 暂无官方服务 | 正在规划企业支持 |
| 生态盈利 | 社区自发 | 可能推出官方市场 |
OpenClaw 的商业模式
Peter 多次表示,OpenClaw 将保持独立和开源。目前的主要资金来源是:
- GitHub Sponsors(个人捐赠)
- 偶尔的咨询服务
- 社区贡献者的志愿工作
这种模式的好处是完全独立,不受资本影响。挑战是长期的可持续性——核心维护者需要吃饭。
Hermes 的商业模式
Nous Research 有 6500 万美元的融资,这意味着:
- 团队可以全职投入开发
- 有更多的资源做长期研发(如自学习算法)
- 但投资人最终期望回报
可能的商业化方向包括:
- 企业版(高级安全、管理功能)
- 托管服务(类似 GitHub 之于 Git)
- 技能市场抽成
类比
OpenClaw 像是一家社区咖啡馆——老板用爱发电,靠常客的小费维持。Hermes 像是一家拿了风投的精品咖啡店——有更专业的团队、更好的装修,但未来可能需要推出会员制或周边产品来实现盈利。两家店都能做出好咖啡,选择哪家取决于你更看重什么。
3. 12 维度深度对比表
3.1 维度一:主语言/技术栈
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 主语言 | Python 93.6% | TypeScript 90.3% |
| 辅助语言 | Rust(性能模块) | JavaScript |
| 运行时 | Python 3.11+ | Node.js 20+ |
| 包管理 | pip/poetry | npm/yarn |
| 虚拟环境 | venv/conda | 无需 |
详细分析
Python 和 TypeScript 是当今最流行的两门语言,但它们的优势领域不同。
Python 的优势:
- AI 生态无敌:PyTorch、TensorFlow、Transformers、NumPy、Pandas……几乎所有 AI 相关的库都是 Python 优先
- 数据处理能力:数据清洗、分析、可视化,Python 的工具链最成熟
- 科学计算:如果你需要做一些数值计算或机器学习,Python 是不二之选
- 脚本友好:写自动化脚本非常顺手,不需要编译
TypeScript 的优势:
- 前端生态:如果你需要构建 Web UI 或浏览器扩展,TypeScript 更方便
- 类型系统:编译时类型检查能减少很多运行时错误
- 异步模型:Node.js 的异步 I/O 在处理大量并发连接时更高效
- 前端开发者上手快:如果你是前端工程师,OpenClaw 的学习曲线更平缓
对选择的影响:
如果你的团队主要是 Python 开发者,或者你需要做大量的数据处理、机器学习相关任务,Hermes 会更顺手。如果你的团队主要是前端/JavaScript 开发者,或者你需要构建复杂的 Web 界面,OpenClaw 可能更合适。
但这里有一个更深层的考量:生态系统的"重力"。Python 在 AI 领域的生态系统有一种"重力效应"——几乎所有新的 AI 论文都会附带 Python 实现,几乎所有新的模型都会先发布 Python 版本的 API。这意味着使用 Hermes,你能第一时间接入最新的 AI 能力。而 TypeScript 的优势更多体现在应用层和前端,如果你的 Agent 需要与用户进行复杂的界面交互,OpenClaw 的前端整合能力更强。
还有一个实际问题是招聘。如果你的团队需要扩充,Python AI 工程师的供给量明显大于 TypeScript AI 工程师。从团队长期发展的角度,这也是一个重要的考量因素。
Tips
不要太纠结于语言偏好。Hermes 和 OpenClaw 都是高级框架,你 90% 的时间是在写配置文件和提示词,而不是修改框架源码。但如果你计划深度定制或贡献代码,语言就很重要了。
一个折中的方案是:用 Hermes 做后端(数据处理、AI 逻辑),用 OpenClaw 或纯前端方案做界面。两个框架可以通过 API 互通,发挥各自的优势。
3.2 维度二:架构设计
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 架构风格 | 轻量 Python + SQLite | 重 Node.js Gateway + 分布式 |
| 核心组件 | 五层松耦合架构 | 模块化但耦合度较高 |
| 数据库 | SQLite(内置) | 文件系统 + 可选数据库 |
| 扩展方式 | Skill 插件 | Tool + Skill |
| 进程模型 | 单进程多线程 | 多进程/微服务 |
详细分析
Hermes 的五层架构
Hermes 采用了清晰的分层设计:
- 接入层:处理不同平台的输入输出(微信、Telegram、Web 等)
- 推理层:与 LLM 交互,负责决策和生成
- 记忆层:三层记忆系统(会话、持久、Skill 级)
- 技能层:Skill 的管理、创建、进化
- 工具层:内置工具和 MCP 服务的调用
这种分层的好处是清晰——你知道每一层负责什么,调试时更容易定位问题。SQLite 作为内置数据库,意味着你不需要额外安装数据库就能使用持久记忆。
OpenClaw 的架构
OpenClaw 的核心是一个 Gateway(网关)模式。所有的输入(用户消息、文件、命令)都经过 Gateway,Gateway 决定调用哪些工具、如何组装上下文、如何输出结果。
OpenClaw 的架构更灵活——你可以替换任何组件。但这种灵活性也带来了复杂性:组件之间的接口没有严格的边界,深入定制时需要理解整个系统。
两种架构的适用场景
Hermes 的松耦合架构更适合:
- 需要快速迭代的项目(修改一层不影响其他层)
- 多人协作开发(清晰的边界减少冲突)
- 长期维护的项目(分层清晰便于新人上手)
OpenClaw 的灵活架构更适合:
- 需要深度定制的场景(每个组件都可以替换)
- 实验性项目(快速尝试不同的组合)
- 已有明确技术栈的团队(可以整合现有组件)
类比
Hermes 的架构像是一套精密的瑞士手表——每个齿轮都在固定的位置,运行稳定,维修时知道该拆哪部分。OpenClaw 的架构像是一套乐高积木——你可以搭出任何东西,但需要自己设计结构,搭错了可能整个倒塌。
如果你的目标是"准时看时间",手表更合适;如果你的目标是"搭一个独一无二的模型",乐高更合适。
3.3 维度三:学习能力
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 技能创建 | 自动创建(独特) | 需手动编写 |
| 技能进化 | 运行时自我优化 | 静态,需手动更新 |
| 用户画像 | 多维度用户建模 | 基础偏好存储 |
| 经验沉淀 | 跨会话 Skill 级记忆 | 会话级/文件级 |
| 学习触发 | 自动识别重复模式 | 用户手动触发 |
详细分析
这是两个项目最根本的差异之一。
Hermes 的自学习机制
Hermes 有一个完整的自学习闭环:
- 模式识别:当你反复执行某类任务时,系统识别出模式
- 主动提议:达到阈值后,Hermes 会问你"是否需要创建一个自动化技能?"
- 自动生成:如果你同意,它会分析步骤、生成代码、注册技能
- 持续优化:随着使用次数增加,Skill 会自动优化(简化步骤、修正错误)
这意味着 Hermes 越用越"懂"你。使用一个月后,它可能已经为你创建了 10 多个定制化技能。
OpenClaw 的学习方式
OpenClaw 的技能系统是"静态"的。你需要:
- 手动编写技能代码(TypeScript)
- 放入正确的目录
- 在配置中注册
- 手动更新和维护
OpenClaw 也有记忆功能,但主要是会话级的上下文管理。跨会话的经验沉淀需要开发者自己实现。
实际使用中的差异
想象一下你每周都要做一份周报。用 Hermes,做了三周后,它会自动问你"是否需要创建一个自动生成周报的技能?"如果你同意,第四周开始,你只需要说"生成周报",它就会自动完成数据收集、分析、格式化全过程。而且随着时间推移,它会越来越清楚你喜欢的报告格式、重点关注的数据指标、甚至你老板喜欢的汇报风格。
用 OpenClaw,你需要手动编写一个周报生成的 Skill。这给了你完全的控制权——你可以精确指定每一个步骤、每一个格式要求。但这也意味着,当你的需求变化时(比如老板换了、汇报格式变了),你需要手动修改代码。
哪种更适合你?
- 如果你的需求变化频繁,或者你自己也不完全清楚"最优流程"是什么,Hermes 的自学习更有优势
- 如果你的需求非常明确且稳定,或者你对自动化有极其精确的要求,OpenClaw 的手动配置更合适
- 如果你喜欢"惊喜"——发现 Agent 自己学会了你没想到的功能——选 Hermes
- 如果你喜欢"掌控"——每一行代码都在你的预期之内——选 OpenClaw
类比
Hermes 像一只聪明的边牧——你教它几次,它自己就能学会新把戏,还会琢磨怎么做得更好。OpenClaw 像一台精密的机器——你需要按照说明书组装和编程,它执行得非常精准,但不会自己"长出新功能"。
边牧可能会偶尔"自作主张"(比如自动创建了一个你不太满意的技能),机器则完全按照指令执行(但你得把所有指令都想清楚)。
3.4 维度四:记忆系统
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 架构 | 有界有机进化 | 模块化(SOUL/TOOLS/USER/Session) |
| 存储 | SQLite + FTS5 | 文件系统 |
| 检索 | 语义 + 关键词混合 | 关键词/文件名 |
| 上下文管理 | 按需检索 | 全量注入 |
| 跨会话记忆 | 原生支持 | 有限支持 |
详细分析
Hermes 的三层记忆
- 会话记忆(短期):当前对话的上下文,确保连贯性
- 持久记忆(中期):SQLite 数据库存储,支持全文检索
- Skill 级记忆(长期):跨会话的知识沉淀,直接优化 Skill 本身
Hermes 的按需检索是一个关键创新。它不会把所有记忆塞进 LLM 的上下文窗口,而是先分析任务需求,只检索最相关的片段。
OpenClaw 的记忆模块
OpenClaw 的记忆系统也是分层的,但实现方式不同:
- SOUL:系统的核心记忆(类似系统提示词)
- TOOLS:工具相关的记忆
- USER:用户特定的偏好
- Session:当前会话的上下文
OpenClaw 的记忆存储在文件系统中(通常是 JSON 或 Markdown 文件),而不是数据库中。这简化了部署,但在大量数据时的检索效率不如数据库方案。
存储方式对使用体验的影响
Hermes 使用 SQLite 数据库存储持久记忆,这带来了几个实际的好处:
- 检索速度快:即使存储了几万条记忆,毫秒级就能找到相关内容
- 支持复杂查询:可以按时间、类别、标签等多维度筛选
- 数据完整性:数据库的事务机制保证数据不会损坏
- 备份方便:单个文件,复制即可备份
OpenClaw 使用文件系统存储,优势在于:
- 人类可读:你可以直接用文本编辑器打开记忆文件查看
- 版本控制友好:记忆文件可以放入 Git 进行版本管理
- 手动编辑:需要时可以直接修改记忆文件
- 无依赖:不需要数据库引擎,部署更简单
实际案例对比
假设你使用 Agent 一年了,积累了 10,000 条记忆:
- Hermes 的 SQLite 方案:检索响应时间 < 100ms,存储空间约 50MB
- OpenClaw 的文件方案:检索可能需要遍历数百个文件,响应时间取决于文件数量和大小
当然,OpenClaw 社区也有开发者实现了基于向量数据库的记忆扩展,但这需要额外配置。
注意
记忆系统的"好坏"很大程度上取决于你的使用场景。如果你主要做短期任务(单次对话就能完成),两者的差异不大。但如果你需要 Agent 长期陪伴、积累对你的了解,Hermes 的记忆系统优势明显。
还有一个重要提醒:无论用哪种记忆系统,定期备份都是必须的。你的记忆数据是 Agent 最宝贵的资产——它记录了你们所有的互动和积累的知识。
3.5 维度五:工具生态
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 内置工具 | 47 个 | 4 个核心 |
| 社区工具 | 643 个(Skills Hub) | 13,700+ 个 |
| 工具哲学 | 功能丰富,开箱即用 | Unix 哲学,简洁核心 |
| MCP 支持 | 原生支持 | 社区适配 |
| 工具发现 | Skills Hub | 社区仓库 |
详细分析
Hermes 的工具策略
Hermes 内置了 47 个工具,覆盖七大类别:Web 与搜索、文件与数据、代码与开发、系统与运维、通信与消息、媒体与内容、金融与分析。这意味着你安装完 Hermes 就能完成很多任务,不需要额外配置。
此外,Hermes 原生支持 MCP(Model Context Protocol),可以接入 6000+ MCP 服务。
OpenClaw 的工具策略
OpenClaw 的核心只有 4 个工具:文件系统、命令行、Web 搜索、代码执行。但 OpenClaw 的社区贡献了 13,700+ 个扩展工具,这是目前最大的 Agent 工具生态。
OpenClaw 的哲学是 Unix 哲学——核心小而美,功能通过组合和扩展实现。
生态规模的实际意义
13,700+ 对比 643,这个差距看起来很大,但实际使用中需要考虑几个因素:
-
质量差异:OpenClaw 的社区工具数量庞大,但质量参差不齐。有些工具已经停止维护,有些文档不全。Hermes 的 Skills Hub 虽然数量少,但审核更严格,可用性更高。
-
核心覆盖度:Hermes 的 47 个内置工具已经覆盖了 90% 的常见需求(搜索、文件操作、代码执行、邮件、数据分析等)。除非你有非常特殊的需求,否则不需要额外安装工具。
-
MCP 的桥接作用:Hermes 原生支持 MCP 协议,可以接入 6000+ MCP 服务。这在很大程度上弥补了社区工具数量的差距。很多 OpenClaw 的工具已经有了对应的 MCP 版本。
-
开发成本:写一个新的 OpenClaw 工具需要 TypeScript 和 Node.js 知识。写一个新的 Hermes Skill 需要 Python 知识。选择哪个生态,取决于你的技术背景。
实际建议
- 如果你需要"立刻就能用"的丰富功能,Hermes 的内置工具 + MCP 生态已经足够
- 如果你需要某个非常小众的功能,OpenClaw 的社区生态找到现成工具的概率更高
- 如果你计划开发自己的工具并分享给社区,OpenClaw 的用户基数更大,潜在受众更多
- 如果你重视工具质量和文档完整性,Hermes 的审核机制更让人放心
类比
Hermes 像是一部功能齐全的智能手机,出厂就自带相机、地图、音乐播放器。OpenClaw 像是一台安装了应用商店的手机,出厂只有电话和短信,但应用商店里有 10 万+ App 可以下载。前者开箱即用,后者选择更多。
但如果你仔细看看,智能手机出厂自带的功能已经能满足 90% 的日常需求。应用商店里的 10 万+ App,你真正常用的可能不到 20 个。
3.6 维度六:平台支持
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 即时通讯 | Telegram、Discord、Slack | Telegram、Discord、Slack、Teams |
| 中国平台 | 微信、企业微信、飞书、钉钉 | 微信、飞书、钉钉 |
| 邮件 | 支持 | 支持 |
| Web | 支持 | 支持 |
| 移动应用 | 无 | iOS/Android 原生 |
| 总平台数 | 15+ | 26+ |
详细分析
OpenClaw 在平台支持上更胜一筹,尤其是它的原生移动应用。这意味着你可以直接在手机上与 Agent 交互,而不需要通过 Telegram 等第三方应用。
Hermes 目前没有原生移动应用,但可以通过以下方式在移动端使用:
- Telegram Bot(手机上安装 Telegram)
- 微信/企业微信/飞书机器人
- 手机浏览器访问 Web 界面
- 语音交互(配合手机语音输入)
Tips
如果你主要在手机上使用 Agent,OpenClaw 的原生应用体验确实更好。但如果你习惯用 Telegram 或微信,Hermes 的平台接入也完全够用。另外,Hermes 社区正在讨论开发移动应用的可能性——如果你对此感兴趣,可以去 GitHub 上关注相关 issue。
3.7 维度七:安全体系
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 沙箱 | 命令审批机制 | 分级沙箱(业界最佳) |
| 隔离级别 | 4 级(0-3) | 5 级 |
| 代码执行 | 需审批 | 严格沙箱 |
| 网络控制 | 白名单 | 完全隔离可选 |
| 安全审计 | 基础 | 详细日志 |
详细分析
这是 OpenClaw 的强项之一。OpenClaw 的分级沙箱被认为是 AI Agent 领域最完善的安全方案。
OpenClaw 的沙箱特点:
- 使用 Docker 容器隔离
- 网络可以完全断开
- 文件系统访问精确控制
- 详细的执行日志和审计
Hermes 的安全方案:
- 也有多级沙箱,但实现相对简单
- 命令审批机制是主要安全手段
- 对于生产环境,建议配合外部安全工具使用
企业用户的安全考量
安全是企业用户最关心的问题之一。OpenClaw 的沙箱系统确实更成熟,这体现在几个方面:
- 更细粒度的权限控制:可以精确控制网络访问、文件系统访问、环境变量
- 更完善的审计日志:每一次命令执行都有详细记录
- 更严格的默认配置:默认情况下,危险操作是被禁止的
- 社区安全实践更丰富:有大量企业用户分享的安全配置
但这不意味着 Hermes 不安全。Hermes 的安全策略是"审批驱动"——所有敏感操作都需要人工确认。这种策略在某些场景下反而更实用:
- 对于个人用户,审批机制简单直观
- 对于小型团队,不需要复杂的安全配置就能保障基本安全
- 对于开发环境,审批机制比沙箱更灵活
安全配置的投入成本
OpenClaw 的安全功能强大,但配置也更复杂。你需要:
- 理解沙箱的 5 个安全级别
- 配置 Docker 环境
- 设置网络白名单/黑名单
- 配置审计日志存储
Hermes 的安全配置更简单:
- 设置审批规则(正则表达式匹配)
- 配置通知渠道
- 选择沙箱级别
对于安全团队资源有限的小型组织,Hermes 的简单方案可能更实际。
注意
如果你要在生产环境中让 Agent 执行系统命令或访问敏感数据,OpenClaw 的安全体系更成熟。Hermes 的安全功能在快速发展中,但如果你是安全敏感型用户(比如金融机构),建议额外配置安全层或等待 Hermes 的安全功能进一步完善。
但无论选择哪个框架,以下安全原则是通用的:
- 永远不要让 Agent 在无审批的情况下执行
rm -rf或类似命令- API Key 和凭证不要写在代码里,用环境变量管理
- 定期审查 Agent 的执行日志
- 给 Agent 最小必要的权限,遵循最小权限原则
3.8 维度八:移动应用
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| iOS 应用 | 无 | 有(原生) |
| Android 应用 | 无 | 有(原生) |
| 移动端体验 | 依赖第三方 IM | 原生体验 |
| 离线能力 | 无 | 部分支持 |
| 推送通知 | 依赖 IM | 原生推送 |
详细分析
OpenClaw 的原生移动应用是一个明显的差异化优势。这意味着:
- 启动速度更快(不需要打开 Telegram 再找到 Bot)
- 可以原生访问手机功能(相册、定位、通知)
- 更好的离线支持
- 更流畅的交互体验
Hermes 用户目前的移动端体验主要依赖:
- Telegram Bot(全球通用,但国内需要翻墙)
- 微信/企业微信/飞书机器人(国内用户友好)
- Web 界面(响应式设计,但不如原生 App 流畅)
移动端使用场景的实际影响
让我们坦诚地说:移动端体验确实是 OpenClaw 的一个明显优势。原生应用带来的流畅度、推送通知的及时性、离线能力,都是第三方 IM 机器人难以比拟的。
但这里也有几个实际的考量:
-
使用频率:你真的需要在手机上"深度使用" Agent 吗?大多数用户的核心使用场景是在电脑上(编程、写作、数据分析)。手机更多是"查看通知"和"简单查询"。
-
Telegram 的替代方案:对于国内用户,微信/企业微信/飞书机器人提供了非常好的移动端体验。你可以在微信里直接@机器人、发语音、收推送,体验并不差。
-
PWA 的可能性:Hermes 可以打包为 PWA,添加到手机主屏幕后,体验接近原生应用。这是一个成本较低的移动化方案。
-
语音交互:第十二章介绍的语音交互配置,可以让 Hermes 在手机上通过语音控制,这在某些场景下甚至比打字更方便。
常见问题
Q:Hermes 会推出移动应用吗?
A: 社区中有相关讨论,但目前没有官方时间表。考虑到 Hermes 是 Python 后端,如果要开发原生移动应用,可能需要:
- 开发 iOS/Android 客户端(Flutter/React Native)
- 或者开发 PWA(渐进式 Web 应用)
- 或者与现有的移动框架集成 如果你对此有需求,建议在 Hermes 的 GitHub 上投票支持相关 issue。
Q:没有原生应用,会不会影响日常使用?
A: 取决于你的使用习惯。如果你主要在电脑前工作,影响很小。如果你希望随时随地与 Agent 深度交互,OpenClaw 的原生应用确实更好。但也请考虑:在手机上完成复杂任务本身就不是一个理想的体验,无论有没有原生应用。
3.9 维度九:模型支持
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| OpenAI | GPT-4o, GPT-4o-mini, o1 | GPT-4o, GPT-4o-mini, o1 |
| Anthropic | Claude 3.5 Sonnet, Opus | Claude 3.5 Sonnet, Opus |
| 本地模型 | Llama, Qwen, DeepSeek 等 | Llama, Qwen, DeepSeek 等 |
| Gemini | Gemini | |
| 总提供者 | 18+ | 多提供者 |
详细分析
两个项目在模型支持上大同小异,都支持主流的大模型提供商。差异主要在于:
Hermes 的特点:
- 对本地模型的支持更友好(Python 生态更适合部署本地模型)
- 模型路由功能更灵活(可以按任务类型自动切换模型)
- 与 Hugging Face 等 Python 生态的整合更紧密
OpenClaw 的特点:
- 与某些商业模型提供商的合作更深入
- 模型配置更标准化
- 对 OpenAI API 的某些高级功能(如 Assistants API)支持更好
本地模型部署的考量
如果你计划使用本地模型(如 Llama、Qwen、DeepSeek),Hermes 有明显优势:
- Python 的
transformers、llama.cpp等库让本地部署极其简单 - 可以直接在 Hermes 中调用本地的 Python 模型服务
- 量化和推理优化的工具链更成熟
OpenClaw 也可以接入本地模型,但通常需要通过额外的服务层(如 Ollama 或 LM Studio),配置相对复杂。
模型成本优化的实际建议
无论你选择哪个框架,模型成本都是最大的开销。以下是一些通用的省钱策略:
- 简单任务用便宜模型:摘要、分类用 GPT-4o-mini 或 Claude Haiku
- 复杂任务再用强模型:分析、推理、创意写作用 GPT-4o 或 Claude Sonnet
- 缓存重复查询:相同的问题直接返回缓存结果
- 限制上下文长度:只发送必要的上下文,减少 token 消耗
- 考虑本地模型:如果有 GPU,70B 级别的本地模型能力已经接近 GPT-4o-mini
Tips
模型支持不是选框架的决定性因素。两个框架支持的模型 90% 是重叠的。更重要的是:框架如何利用模型?比如 Hermes 的按需检索机制可以更有效地利用模型的上下文窗口,而 OpenClaw 的全量注入在上下文较短时更直接。
建议你先用同一个模型(如 GPT-4o-mini)在两个框架上测试同样的任务,看看哪个框架的输出质量更高、响应更快。实践出真知。
3.10 维度十:部署方式
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 一键安装 | curl 脚本 | npm install |
| Docker | 官方镜像 | 官方镜像 |
| 本地部署 | 简单 | 简单 |
| VPS 部署 | 推荐 | 推荐 |
| 无服务器 | 支持(实验性) | 有限支持 |
| 安装复杂度 | 低 | 低 |
详细分析
Hermes 的部署
# 一键安装(curl)
curl -fsSL https://hermesagent.io/install.sh | bash
# Docker
docker run -d --name hermes nousresearch/hermes:latest
# Python 包
pip install hermes-agentOpenClaw 的部署
# npm 安装
npm install -g openclaw
# Docker
docker run -d --name openclaw openclaw/openclaw:latest
# 从源码
git clone https://github.com/peter/openclaw.git
cd openclaw && npm install && npm run build两个项目的部署都很简单。Hermes 的 curl 一键安装对新手最友好,OpenClaw 的 npm 安装对前端开发者更顺手。
部署后的配置复杂度
虽然初始安装都很简单,但配置阶段的复杂度有所不同:
Hermes 的配置相对集中:
- 一个主配置文件
config.yaml - 环境变量管理 API Key
- 大部分常用功能开箱即用
OpenClaw 的配置更分散:
- 多个配置文件(系统配置、工具配置、记忆配置等)
- 需要手动选择和配置工具
- 某些高级功能需要额外的服务(如向量数据库)
首次运行体验
对于完全没有经验的新用户:
- Hermes:安装完运行
hermes chat,输入消息就能对话。不需要额外配置就能使用基本功能。 - OpenClaw:安装完需要配置模型提供商、选择工具、设置系统提示词,然后才能开始对话。
这意味着 Hermes 的"Hello World"路径更短,新手能更快获得成就感。
类比
部署就像搬家。Hermes 提供了一站式搬家服务——你打个电话,他们就来打包、搬运、安置,家具都摆好了,床单也铺好了,你直接就能睡。OpenClaw 提供了详细的搬家指南——步骤清晰,但需要你自己动手组装家具、铺床单。
两种方式最终都能把家搬好,但前者让你第一天就能睡个好觉,后者可能需要你忙到半夜。
3.11 维度十一:成本
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 框架本身 | 免费(MIT) | 免费(MIT) |
| API 调用 | 按量付费(给 OpenAI 等) | 按量付费 |
| 本地模型 | 仅电费 | 仅电费 |
| 托管服务 | 暂无官方服务 | 暂无官方服务 |
| 典型月费 | $5-50(取决于使用量) | $5-50 |
详细分析
两个框架本身都是免费的。真正的成本来自 API 调用。
省钱策略(两个框架通用):
- 使用本地模型:如果你有 GPU,可以运行 Llama 3 或 Qwen 本地模型,API 成本为零
- 模型降级:简单任务用 GPT-4o-mini 而不是 GPT-4o
- 缓存响应:相同的问题直接返回缓存结果
- 限制上下文长度:只发送必要的上下文,减少 token 消耗
两个框架的成本差异
虽然 API 调用成本与框架无关,但框架的设计会影响你的实际支出:
Hermes 的按需检索机制可以帮你省钱:
- 不会把所有记忆塞进上下文,减少不必要的 token 消耗
- 模型路由自动选择便宜模型处理简单任务
- 缓存机制更完善
OpenClaw 的全量注入可能增加成本:
- 每次对话都会注入大量系统提示词和记忆
- 没有自动模型降级功能
- 但可以通过配置优化来减少开销
实际成本案例
假设你每天使用 Agent 4 小时,处理约 100 个任务:
- 方案 A(全云端 GPT-4o):每月约 $80-120
- 方案 B(云端 + 本地混合):每月约 $30-50
- 方案 C(全本地 70B 模型):每月约 $5-10(电费)
框架选择对成本的影响大约是 10-20%,主要取决于框架的上下文管理和缓存效率。
Tips
如果你每月的 API 费用超过 $100,建议认真考虑本地模型方案。一台 RTX 4090 可以流畅运行 70B 级别的模型,虽然不如 GPT-4o 聪明,但对于大多数任务已经足够。硬件的一次性投入(约 $2000)在一年内就能回本。
另一个省钱技巧:Hermes 和 OpenClaw 都支持设置每日预算上限。建议新手设置一个 $5/天的上限,避免因为配置错误或无限循环导致账单爆炸。
3.12 维度十二:社区规模
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| GitHub Stars | 104,791 | 309,000+ |
| Discord 成员 | 45,000+ | 150,000+ |
| 贡献者 | 500+ | 2000+ |
| 第三方工具 | 643 | 13,700+ |
| 中文社区 | 快速发展中 | 较大但分散 |
| 文档完善度 | 中(快速发展中) | 高 |
详细分析
OpenClaw 的社区规模目前遥遥领先。13,700+ 的第三方工具意味着你几乎可以找到任何功能的扩展。
但 Hermes 的社区增长非常快。考虑到它才发布两个月,104k Stars 和 45k Discord 成员已经是惊人的成绩。
社区质量的深层分析
数量不等于质量。让我们从几个维度看社区的实际价值:
文档和学习资源
- OpenClaw:英文文档非常完善,但中文资料分散且质量不一
- Hermes:英文文档在快速完善中,中文资源明显更丰富(本书就是一个例子)
问题响应速度
- OpenClaw:Discord 上提问,通常几小时内有人回复(但需要用英文)
- Hermes:Discord 响应也很快,中文微信群内的响应更及时
第三方生态
- OpenClaw:13,700+ 工具,但质量参差不齐,很多已停止维护
- Hermes:643 个工具 + 6000+ MCP 服务,审核更严格,可用性更高
贡献门槛
- OpenClaw:需要 TypeScript 能力,核心代码较复杂
- Hermes:Python 门槛较低,Skill 开发更简单
中文社区现状:
- OpenClaw:中文用户不少,但分散在各个微信群和论坛,缺乏统一的社区平台
- Hermes:中文社区正在快速发展,有多个活跃的微信群和知识星球
对于中文用户来说,社区语言是一个非常重要的考量因素。阅读英文文档、在英文社区提问,对很多中文用户来说是巨大的门槛。Hermes 在中文内容方面的投入,让中文用户的学习曲线明显更平缓。
类比
OpenClaw 的社区像一座繁华的大都市——人多、设施全、应有尽有,但新人可能感到迷茫,而且大家主要说外语。Hermes 的社区像一座快速发展的卫星城——人没有那么多,但增长迅速,社区氛围更紧密,你更容易认识核心成员,而且大家都说中文。
4. 核心差异深度分析
4.1 自学习 vs 手动配置:这是最根本的差异
前面在 12 维度对比中,我们提到了学习能力的差异。这里我想更深入地分析这个差异对实际使用的影响。
自学习的好处:
- 使用一个月后,Hermes 可能已经为你创建了 10+ 定制化技能
- 不需要写代码,只需要"正常用",系统自己学习
- Skill 会随着使用自动优化
自学习的局限:
- 学习的质量取决于你的使用模式是否清晰
- 自动生成的 Skill 可能需要人工审核和调整
- 学习过程需要一定时间的"训练期"
手动配置的好处:
- 完全可控,你知道每个 Skill 在做什么
- 可以精确调整每个参数
- 适合有明确需求、喜欢 DIY 的用户
手动配置的局限:
- 需要写代码(TypeScript)
- 维护成本高(需求变了要手动改)
- 不容易发现"可以自动化"的机会
更深层的思考:两种哲学的工作流差异
使用 Hermes 一个月后的典型工作流:
- 第 1 周:手动执行各种任务,Agent 在旁观察学习
- 第 2 周:Agent 开始提醒你"这个任务我之前见过,需要我自动完成吗?"
- 第 3 周:几个高频任务已经自动化,你只需要说"执行周报流程"
- 第 4 周:Agent 比你更清楚你的习惯,主动提议优化方案
使用 OpenClaw 一个月后的典型工作流:
- 第 1 周:研究文档,编写第一个 Skill
- 第 2 周:调试和完善 Skill,处理各种边界情况
- 第 3 周:编写更多 Skill,建立完整的工具链
- 第 4 周:维护已有 Skill,根据新需求修改代码
两种工作流没有绝对的好坏。Hermes 适合"渐进式自动化"——你不需要提前规划所有自动化场景,Agent 会帮你发现。OpenClaw 适合"设计式自动化"——你需要先想清楚流程,然后精确实现。
类比
自学习像是一个自动整理房间的机器人——你用几天,它就知道你的习惯,自动把东西放到对的位置。手动配置像是一个按需呼叫的管家——你每次都要告诉他"把书放到书架上",但他每次都执行得很精确。前者省心但可能偶尔出错,后者精确但需要持续投入精力。
还有一个关键区别:机器人偶尔会"自作主张"把东西放到它认为对的地方(但你可能不同意),而管家完全按照你的指令执行(但你需要每次都给出指令)。
4.2 有界记忆 vs 模块化记忆:设计哲学的不同
两个项目的记忆系统设计反映了不同的哲学取向。
Hermes 的"有界有机进化"
Hermes 的记忆系统有一个核心概念——"有界"(Bounded)。这意味着:
- 记忆不是无限增长的,而是有选择地保留
- 系统会定期清理低价值的记忆
- 重要的记忆会被"强化",形成长期知识
- 记忆之间会建立关联,形成知识网络
这种设计的好处是系统不会随着使用变得越来越臃肿。缺点是偶尔可能会"遗忘"一些你认为重要的东西。
OpenClaw 的"模块化记忆"
OpenClaw 的记忆系统是模块化的,你可以:
- 为不同的任务创建不同的记忆模块
- 手动管理记忆文件
- 精确控制哪些内容进入记忆
这种设计的好处是可控性高。缺点是如果管理不善,记忆文件会越来越多,检索效率下降。
4.3 Python vs TypeScript:生态选择的影响
这个差异不只是"喜欢哪种语言",它影响了两个项目的方方面面。
Python 生态的影响(Hermes):
- AI/ML 库丰富,容易集成新的 AI 能力
- 数据处理能力强,适合分析型任务
- 科学计算生态成熟
- 但前端/UI 能力相对弱
TypeScript 生态的影响(OpenClaw):
- 前端/UI 能力强,容易构建漂亮的界面
- npm 生态庞大,工具丰富
- 类型系统减少运行时错误
- 但 AI/ML 库不如 Python 丰富
4.4 轻量 vs 全能:两种架构路线
Hermes 的"轻量路线"
Hermes 追求"够用就好":
- 核心功能内置,开箱即用
- 不需要额外配置数据库
- 单个进程就能运行
- 资源占用少
适合:个人用户、小型团队、快速原型
OpenClaw 的"全能路线"
OpenClaw 追求"无所不能":
- 核心简洁,功能通过扩展实现
- 支持微服务架构
- 企业级功能更完善
- 生态更丰富
适合:企业用户、大型团队、复杂场景
4.5 Harness Engineering vs Unix Philosophy
两个项目代表了两种不同的工程哲学。
Hermes:Harness Engineering(驾驭工程)
Hermes 的设计理念是:Agent 是一个需要"驾驭"的存在。你要培养它、训练它、与它建立信任关系。它的自学习、用户画像、记忆进化,都是为了让 Agent 成为"你的" Agent——独特、个性化、越用越顺手。
OpenClaw:Unix Philosophy(Unix 哲学)
OpenClaw 的设计理念是:一个工具做好一件事,然后通过组合实现复杂功能。它的核心很小,但每个组件都可以被替换、扩展、组合。这种哲学在软件工程界有深厚的传统,也是 Linux 成功的秘诀之一。
Tips
没有哪种哲学绝对更好。如果你喜欢"养成"的感觉,享受和 Agent 一起成长的过程,Hermes 更适合你。如果你喜欢"组装"的感觉,享受搭建和定制系统的乐趣,OpenClaw 更适合你。
5. 社区对比
5.1 官方定位:四个工具,四种角色
要理解 Hermes 和 OpenClaw 的差异,我们需要把它们放在更大的工具图景中来看。
| 工具 | 官方定位 | 核心场景 | 使用方式 |
|---|---|---|---|
| Claude Code | 仓库内编码代理 | 在代码仓库内辅助编程 | 命令行,IDE 集成 |
| Cursor | 编辑器内双人程序员 | 在编辑器里写代码 | IDE 插件 |
| OpenClaw | 配置驱动的任务运行器 | 自动化执行各种任务 | 配置文件驱动 |
| Hermes | 自我提升的自主代理 | 长期陪伴,持续进化 | 对话+自动学习 |
Claude Code 是 Anthropic 推出的工具,它直接集成在你的代码仓库中,可以读取文件、执行命令、修改代码。它的定位非常聚焦——编程辅助。
Cursor 是一款 AI 编辑器,它在 VS Code 的基础上深度集成了 AI 功能。你可以把它理解为"有一个 GPT-4 住在你的编辑器里"。
OpenClaw 的定位是"任务运行器"——你配置好规则和工具,它按照你的配置执行任务。它是"配置驱动"的。
Hermes 的定位是"自主代理"——你不只是在"用它",而是在"养它"。它会学习、进化、变得越来越懂你。
类比
如果把 AI 工具比作交通工具:Claude Code 是工地上的挖掘机——专业、强大,但只在工地上用。Cursor 是轿车里的导航——随时可用,帮你指路。OpenClaw 是货车——能拉很多货,但你需要自己装卸。Hermes 是马——能载你走很远,但需要培养和信任。
5.2 社区文化差异
OpenClaw 社区文化
- DIY 精神:社区鼓励自己动手,分享定制配置
- 工具导向:讨论集中在"怎么实现某个功能"
- 国际化:英文为主,全球开发者参与
- 极客氛围:技术讨论深入,新手可能感到门槛高
Hermes 社区文化
- 成长导向:讨论更多关于"怎么让 Agent 更聪明"
- 应用导向:更关注"Agent 能帮我做什么"
- 中文活跃:中文用户比例相对较高
- 包容性:对非技术背景的用户更友好
5.3 中文社区活跃度对比
| 维度 | Hermes | OpenClaw |
|---|---|---|
| 微信群数量 | 10+ | 20+ |
| 中文文档 | 完善(本书就是) | 分散,不完善 |
| 中文视频教程 | 社区创作者持续产出 | 较少 |
| 中文论坛 | 正在建设中 | 无统一平台 |
| 企业用户群 | 快速增长 | 较多 |
Hermes 在中文内容方面有明显的优势——本书的存在就是一个证明。对于中文用户来说,这是选择 Hermes 的一个重要因素。
5.4 社区贡献模式对比
OpenClaw 的贡献模式
- 核心代码由 Peter 和核心团队维护
- 社区贡献主要是工具和扩展
- 贡献门槛较高(需要理解核心架构)
- 但贡献者数量庞大
Hermes 的贡献模式
- Nous Research 团队全职开发
- 社区贡献包括技能、文档、教程
- 技能系统的门槛较低(Python 写几行代码即可)
- 贡献者数量在快速增长
5.5 大多数高级用户同时使用 Hermes + Claude Code(叠加而非竞争)
这是一个非常重要的观察:高级用户很少只用一个工具。
典型的"高级玩家工具栈":
- Claude Code:在代码仓库里写代码、改代码
- Hermes:日常任务自动化、信息收集、内容管理
- OpenClaw:某些特定场景的深度定制
- Cursor:日常编码(如果不用 Claude Code)
这些工具不是竞争关系,而是互补关系。每个工具都有其最适合的场景,高级用户会根据任务选择最合适的工具。
Tips
如果你刚入门,不要试图同时学多个工具。先选一个专注学好。等你能熟练使用后,再根据需要添加其他工具。我见过太多人同时装了三四个工具,结果哪个都没学会。
6. 选型决策指南
6.1 场景化推荐(详细的决策树)
下面是一棵决策树,帮你快速定位最适合你的工具。
第一层:你的编程背景
你是程序员吗?
├── 是 -> 继续第二层
└── 不是 -> 推荐 Hermes(更友好)
第二层:你的主要语言
你主要用什么语言?
├── Python -> 推荐 Hermes
├── TypeScript/JavaScript -> 推荐 OpenClaw
├── 其他 -> 继续第三层
第三层:你的核心需求
你最看重什么?
├── 开箱即用,不想配置 -> 推荐 Hermes
├── 深度定制,喜欢 DIY -> 推荐 OpenClaw
├── 移动端使用 -> 推荐 OpenClaw
├── 长期陪伴,越用越聪明 -> 推荐 Hermes
├── 企业级安全 -> 推荐 OpenClaw(目前)
└── 中文支持和文档 -> 推荐 Hermes
详细场景推荐
| 场景 | 推荐 | 理由 |
|---|---|---|
| 学生/个人开发者 | Hermes | 学习成本低,中文文档丰富,自学习减少维护 |
| 企业/团队 | OpenClaw | 安全体系更成熟,生态更丰富,企业级功能完善 |
| 需要移动应用 | OpenClaw | 原生 iOS/Android 应用 |
| 追求效率部署 | Hermes | curl 一键安装,开箱即用 |
| 长期养成助手 | Hermes | 自学习、用户画像、Skill 进化 |
| 已有大量 OpenClaw 配置 | 可迁移到 Hermes | hermes migrate 命令支持 |
| 数据科学家 | Hermes | Python 生态,数据处理能力强 |
| 前端开发者 | OpenClaw | TypeScript 生态,上手更快 |
| 安全敏感型 | OpenClaw | 沙箱安全体系更完善 |
| 非技术用户 | Hermes | 配置更简单,中文支持好 |
| 需要快速原型验证 | Hermes | 内置工具多,MCP 生态丰富 |
| 需要深度定制 | OpenClaw | 模块化架构,可替换任何组件 |
| 预算极其有限 | Hermes | 本地模型支持更好,省去 API 费用 |
| 追求社区活跃度 | OpenClaw | 社区更大,第三方工具更多 |
| 中文环境为主 | Hermes | 中文文档、中文社区、国内平台支持更好 |
决策的灵活性
请记住,这个推荐表不是一成不变的。两个项目都在快速发展:
- Hermes 正在加强企业级功能和安全体系
- OpenClaw 正在改进记忆系统和配置体验
- 六个月后的推荐可能与今天不同
所以,不要把这个表格当作"终身判决"。把它当作"当前时间点的参考",并随着项目的发展保持关注。
6.2 不同预算下的选择
预算:$0/月(完全免费)
- 使用本地模型(Llama 3、Qwen、DeepSeek)
- Hermes 和 OpenClaw 都可以,但 Hermes 对本地模型支持更友好
- 需要一台性能较好的电脑(至少 16GB 内存,推荐有 GPU)
预算:$5-20/月
- 使用 GPT-4o-mini 或 Claude Haiku
- 两个框架都可以,成本差异不大
- 建议根据其他因素选择
预算:$20-100/月
- 可以使用 GPT-4o、Claude Sonnet
- 两个框架都可以
- 如果追求性价比,Hermes 的模型路由可以帮你自动降级简单任务
预算:$100+/月
- 可以使用最强模型(GPT-4o、Claude Opus、o1)
- 两个框架都可以
- 考虑是否需要多个框架组合使用
- 可以承受一定的"试错成本",建议两个都深度体验
成本与价值的平衡思考
很多用户过于关注"哪个更便宜",而忽略了"哪个能创造更多价值"。一个能帮你每天节省 2 小时的 Agent,即使每月花费 $50,也是极其划算的投资。相比之下,一个免费的 Agent 如果每天都要花你 1 小时去调试和维护,反而更"贵"。
建议的决策方式是:
- 先估算 Agent 能为你节省多少时间/创造多少价值
- 根据这个价值设定合理的预算
- 在预算范围内选择功能最适合的框架
- 定期评估 ROI(投入产出比)
6.3 不同技术背景下的选择
完全不懂编程
推荐 Hermes。
- 配置更简单,不需要写代码
- 中文文档更完善
- 自学习减少你需要手动做的事
- 可以从本书的保姆级教程开始
对于非技术用户,最大的障碍往往不是"功能不够",而是"不知道怎么开始"。Hermes 的 curl 一键安装、开箱即用的设计、以及本书这种保姆级教程,能最大程度降低入门门槛。
会一点 Python
强烈推荐 Hermes。
- 你可以写自己的 Skill
- 可以接入 Python 的数据分析生态
- 可以修改和扩展核心功能
即使你只是会写简单的 Python 脚本,也足以开发有用的 Hermes Skill。相比之下,要为 OpenClaw 写扩展,你需要了解 Node.js 的异步模型、TypeScript 的类型系统,学习曲线更陡。
前端开发者(TypeScript/JavaScript)
推荐 OpenClaw。
- 语言和生态完全匹配
- 可以写自己的工具和扩展
- 可以基于 OpenClaw 构建 Web 应用
前端开发者使用 OpenClaw 时,可以利用自己熟悉的技术栈快速定制。而且 OpenClaw 的 Gateway 架构与前端微服务的理念很相似,思维方式匹配度高。
全栈开发者
两个都可以,建议:
- 如果偏向后端/数据:Hermes
- 如果偏向前端/UI:OpenClaw
- 或者两个都用(不同场景)
全栈开发者其实是最幸福的——你不需要做选择,可以根据场景自由切换。后端数据处理用 Hermes,前端界面集成用 OpenClaw,两者通过 API 互通。
AI/ML 工程师
推荐 Hermes。
- Python 生态与你的工作流完全匹配
- 更容易集成自己的模型
- 数据处理和分析能力更强
AI/ML 工程师通常已经熟悉 PyTorch、Hugging Face、LangChain 等 Python 生态。Hermes 可以让你无缝地将这些能力整合到 Agent 中。比如,你可以写一个 Skill 来调用你自己的微调模型,或者集成一个新的论文中的算法。
7. 从 OpenClaw 迁移到 Hermes
7.1 迁移前评估清单
在决定迁移之前,先评估一下你的现状:
# OpenClaw 迁移评估清单
## 当前使用情况
- [ ] 我有多少个自定义 Skill?
- [ ] 我有多少个自定义 Tool?
- [ ] 我修改过 OpenClaw 的核心代码吗?
- [ ] 我使用了哪些平台集成?
- [ ] 我的配置文件有多大/多复杂?
## 数据评估
- [ ] 我有多少历史对话记录需要保留?
- [ ] 我的记忆文件有多大?
- [ ] 是否有重要的自定义数据格式?
## 依赖评估
- [ ] 我使用了哪些 OpenClaw 特有的第三方扩展?
- [ ] 这些扩展在 Hermes 中有对应替代吗?
- [ ] 我的工作流是否依赖 OpenClaw 的特定行为?
## 时间评估
- [ ] 我有多少时间可以投入迁移?
- [ ] 迁移期间是否可以接受服务中断?
- [ ] 我是否需要并行运行两个系统一段时间?7.2 hermes migrate openclaw 命令详解
Hermes 提供了官方的迁移工具,可以自动迁移大部分内容。
# 查看迁移工具帮助
$ hermes migrate --help
# 预览迁移内容(不实际执行)
$ hermes migrate openclaw --preview --source ~/.openclaw
# 执行迁移
$ hermes migrate openclaw \
--source ~/.openclaw \
--target ~/.hermes \
--include skills,config,history
# 迁移选项
$ hermes migrate openclaw --help
Options:
--source PATH OpenClaw 配置目录 [默认: ~/.openclaw]
--target PATH Hermes 目标目录 [默认: ~/.hermes]
--include LIST 要迁移的内容 [默认: all]
可选: skills, config, history, memory, tools
--exclude LIST 要排除的内容
--dry-run 预览迁移,不实际执行
--backup 迁移前备份目标目录
--conflict-strategy 冲突处理策略 [默认: prompt]
可选: overwrite, skip, prompt, rename7.3 迁移过程详细步骤
步骤1:备份现有数据
# 备份 OpenClaw 配置
cp -r ~/.openclaw ~/.openclaw-backup-$(date +%Y%m%d)
# 备份 Hermes 配置(如果有)
cp -r ~/.hermes ~/.hermes-backup-$(date +%Y%m%d)步骤2:安装 Hermes
# 按照本书第五册的安装指南安装 Hermes
curl -fsSL https://hermesagent.io/install.sh | bash
# 验证安装
hermes --version步骤3:执行自动迁移
# 预览迁移内容
hermes migrate openclaw --preview --source ~/.openclaw
# 如果预览结果满意,执行迁移
hermes migrate openclaw --source ~/.openclaw --backup步骤4:验证迁移结果
# 检查迁移的 Skill
hermes skill list
# 检查迁移的配置
hermes config get --all
# 测试一个迁移的 Skill
hermes skill test <skill_name>步骤5:手动调整
自动迁移完成后,可能需要手动调整:
- 某些 OpenClaw 特有的配置项需要重新配置
- 路径和变量名可能有变化
- 某些高级功能可能需要重新实现
7.4 自动迁移支持的内容(技能、配置、历史)
| 内容类型 | 自动迁移支持 | 说明 |
|---|---|---|
| Skill 代码 | 部分支持 | TypeScript -> Python 需要转换 |
| Skill 配置 | 支持 | 元数据可以迁移 |
| 系统配置 | 支持 | 基础配置项可以映射 |
| 平台配置 | 部分支持 | 相同平台可直接迁移 |
| 历史对话 | 支持 | 格式转换后导入 |
| 记忆文件 | 部分支持 | 文件格式需要转换 |
| 自定义工具 | 需手动 | 需要重写为 Python |
| API Key | 支持 | 安全配置迁移 |
7.5 需要手动调整的部分
Skill 代码转换
OpenClaw 的 Skill 是 TypeScript,Hermes 的 Skill 是 Python。自动迁移可以处理配置,但代码逻辑需要手动转换。
// OpenClaw Skill 示例(TypeScript)
export class MySkill {
async execute(params: any) {
const result = await fetch(params.url);
return result.json();
}
}# Hermes Skill 示例(Python)
from hermes.tools import Tool
import aiohttp
class MySkill(Tool):
async def execute(self, url: str):
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
return await response.json()配置差异
# OpenClaw 配置风格
model:
provider: openai
model: gpt-4o
tools:
- web_search
- file_read
# Hermes 配置风格
model:
default: gpt-4o
providers:
openai:
api_key: "${OPENAI_API_KEY}"
tools:
builtin:
- web_search
- file_read7.6 迁移后验证
# 验证清单
# 1. 基础功能
hermes --version
hermes chat "Hello"
# 2. 模型连接
hermes model test
# 3. 工具功能
hermes tool test web_search
hermes tool test file_read
# 4. Skill 功能
hermes skill list
hermes skill test <important_skill>
# 5. 平台接入
hermes gateway test telegram
# 6. 记忆系统
hermes memory search "test"
# 7. 完整工作流
hermes workflow test <important_workflow>7.7 常见迁移问题与解决方案(10个)
问题1:Skill 代码无法直接运行
原因:TypeScript 和 Python 语法不同
解决:需要手动将 Skill 逻辑从 TS 转换为 Python
参考:本书第八册「技能系统完全指南」
问题2:配置文件格式不兼容
原因:Hermes 和 OpenClaw 的配置结构不同
解决:使用 hermes migrate 自动转换基础配置,手动调整高级配置
参考:迁移工具的 --preview 选项可以先看差异
问题3:路径和变量名变化
原因:两个项目的环境变量和路径约定不同
解决:检查 .env 文件,更新变量名
常见变化:
OPENCLAW_API_KEY -> HERMES_API_KEY
~/.openclaw/skills -> ~/.hermes/skills
问题4:第三方扩展不可用
原因:OpenClaw 的某些扩展没有 Hermes 版本
解决:
1. 在 Hermes 社区寻找替代方案
2. 自己用 Python 重写
3. 通过 MCP 协议接入
问题5:记忆丢失
原因:记忆文件格式不兼容
解决:
1. 使用迁移工具的 --include memory 选项
2. 如果自动迁移失败,可以导出为文本后重新导入
3. 某些记忆可能需要重新"训练"
问题6:平台接入配置不同
原因:两个项目的 Gateway 配置格式不同
解决:参考本书第十册「多平台接入实战」重新配置
注意:Webhook URL 可能需要更新
问题7:性能差异
原因:Python 和 Node.js 的性能特征不同
解决:
1. 调整并发数
2. 开启缓存
3. 必要时使用更快的模型
问题8:安全问题
原因:两个项目的安全模型不同
解决:
1. 重新审查沙箱配置
2. 设置命令审批规则
3. 参考本书第十二章的安全配置
问题9:工作流中断
原因:自动化任务依赖特定路径或配置
解决:
1. 检查所有 Cron 任务
2. 更新路径引用
3. 测试每个工作流
问题10:习惯改变
原因:两个项目的交互方式不同
解决:
1. 给自己一周适应期
2. 利用 Hermes 的自学习加速适应
3. 保留 OpenClaw 作为备用(可以并行运行)
7.8 迁移后的优化建议
优化1:利用自学习加速适应
# 开启自动 Skill 创建
hermes config set auto_skill_creation true
# 设置学习阈值
hermes config set skill_creation_threshold 3优化2:重新设计记忆策略
# 利用 Hermes 的三层记忆系统
memory:
session:
enabled: true
max_turns: 50
persistent:
enabled: true
db_path: "./memory.db"
skill_level:
enabled: true
auto_extract: true优化3:探索 MCP 生态
# 查看可用的 MCP 服务
hermes mcp list
# 接入常用的 MCP 服务
hermes mcp add filesystem
hermes mcp add github
hermes mcp add fetch8. 从其他框架迁移
8.1 从 AutoGPT 迁移
AutoGPT 是 AI Agent 领域的先驱之一,但它的架构与 Hermes 差异较大。
主要差异:
- AutoGPT 使用"思考-行动-观察"循环,Hermes 使用技能驱动
- AutoGPT 的任务分解更自主,但也更容易陷入循环
- AutoGPT 的记忆系统相对简单
迁移建议:
- 重新设计任务流程(从循环改为 Skill 链)
- 利用 Hermes 的三层记忆替代 AutoGPT 的记忆文件
- 使用 Hermes 的工具系统替代 AutoGPT 的插件系统
8.2 从 MetaGPT 迁移
MetaGPT 模拟软件开发团队的协作流程,适合复杂的软件开发任务。
主要差异:
- MetaGPT 是多角色协作,Hermes 是单 Agent + Skill 系统
- MetaGPT 主要面向软件开发,Hermes 更通用
迁移建议:
- 将 MetaGPT 的角色映射为 Hermes 的 Skill
- 使用 Hermes 的多 Agent 功能(如果可用)替代角色协作
- 保留 MetaGPT 用于大型软件开发项目,Hermes 用于日常任务
8.3 从 CrewAI 迁移
CrewAI 是一个轻量级的多 Agent 框架,与 Hermes 的架构较为接近。
主要差异:
- CrewAI 强调 Agent 之间的协作,Hermes 强调 Skill 的复用
- CrewAI 的 Skill 是手动定义的,Hermes 支持自动创建
迁移建议:
- CrewAI 的 Agent 可以映射为 Hermes 的 Skill 或工作流
- 利用 Hermes 的自学习减少手动配置
- CrewAI 的协作逻辑可以用 Hermes 的工作流系统实现
8.4 通用迁移思路
无论从哪个框架迁移到 Hermes,都可以遵循以下思路:
第一步:功能映射
列出你在原框架中使用的所有功能,找到 Hermes 中的对应方案:
| 原框架功能 | Hermes 对应方案 |
|---|---|
| 任务分解 | Skill 链 + 工作流 |
| 记忆系统 | 三层记忆系统 |
| 工具/插件 | 内置工具 + MCP |
| 角色定义 | Skill 配置 + 用户画像 |
| 自动化流程 | Cron + 工作流 |
第二步:数据迁移
- 导出历史数据为通用格式(JSON/CSV/Markdown)
- 使用 Hermes 的导入功能或脚本导入
- 验证数据完整性
第三步:逐步切换
- 不要一次性全部迁移
- 先迁移最常用的功能
- 并行运行两个系统一段时间
- 确认稳定后再完全切换
第四步:优化利用
- 利用 Hermes 特有的功能(自学习、用户画像等)
- 重新设计工作流,发挥 Hermes 的优势
- 持续优化和调整
迁移的心态调整
迁移不只是技术工作,也是习惯的改变。给自己一些时间适应:
- 第一周:并行运行,熟悉 Hermes 的操作方式
- 第二周:把最常用的功能迁移过来
- 第三周:尝试 Hermes 特有的功能(如自学习)
- 第四周:评估是否完全切换,或保持共存
不要期望迁移后立刻就能达到在 OpenClaw 上的熟练度。每个框架都有自己的"脾气",需要时间去了解和适应。
Tips
迁移期间,建议保留 OpenClaw 的备份。如果 Hermes 某个功能暂时无法满足需求,你可以随时回退。平滑迁移比"一刀切"更明智。
9. 两者共存方案
9.1 同时使用 Hermes + OpenClaw 的场景
很多高级用户选择同时使用两个框架。以下是一些典型的共存场景:
场景1:分工协作
- Hermes:日常任务自动化、内容生成、信息收集
- OpenClaw:代码审查、系统管理、需要高安全性的任务
场景2:渐进迁移
- 新功能用 Hermes 开发
- 旧功能继续用 OpenClaw 运行
- 逐步迁移,降低风险
场景3:场景专用
- Hermes:移动端通过 Telegram/微信使用
- OpenClaw:桌面端通过原生应用使用
场景4:团队分工
- 技术团队用 OpenClaw(TypeScript 生态)
- 运营团队用 Hermes(配置简单,中文友好)
9.2 数据互通方案
如果同时使用两个框架,数据互通是一个重要问题。
方案1:共享数据库
# 两个框架都连接到同一个数据库
# Hermes 配置
database:
url: "postgresql://user:pass@localhost:5432/shared_db"
# OpenClaw 配置
database:
url: "postgresql://user:pass@localhost:5432/shared_db"方案2:文件共享
# 使用共享的文件系统目录
# Hermes 配置
storage:
shared_path: "/shared/agent_data/"
# OpenClaw 配置
storage:
shared_path: "/shared/agent_data/"方案3:API 互通
# 让 Hermes 和 OpenClaw 通过 API 交换数据
# Hermes 端:提供数据接口
from hermes import app
@app.route('/api/share/memory')
def share_memory():
return get_recent_memories()
# OpenClaw 端:消费数据
const response = await fetch('http://hermes:8080/api/share/memory');
const memories = await response.json();9.3 最佳实践
实践1:明确分工
不要让两个框架做同一件事。为每个框架定义清晰的职责范围,避免重复和冲突。
实践2:统一数据源
如果两个框架都需要访问相同的数据(如客户信息、订单数据),使用统一的数据库或 API,避免数据不一致。
实践3:共享通知渠道
两个框架的通知都发送到同一个 Telegram 群/Slack 频道,便于统一管理。
# Hermes 通知配置
notifications:
telegram:
chat_id: "${SHARED_CHAT_ID}"
# OpenClaw 通知配置
notifications:
telegram:
chat_id: "${SHARED_CHAT_ID}"实践4:定期评估
每季度评估一次:哪个框架用得更多?哪个功能更需要?是否还需要同时维护两个?根据评估结果调整策略。
共存的长期视角
很多用户担心"同时使用两个框架会不会很混乱"。实际上,随着你对两个框架的理解加深,你会发现它们各自有不可替代的场景:
- 早上用 Hermes:让它自动收集 overnight 的信息,生成晨间简报
- 白天用 OpenClaw:在编程时使用它的代码助手功能
- 晚上用 Hermes:回顾一天的工作,让 Agent 帮你整理笔记
这种"分工协作"的模式,反而比死守一个框架更高效。
从共存到选择的自然过程
大多数用户的最终状态不是"永远共存",而是"自然选择"。使用几个月后,你会发现:
- 80% 的时间你在用其中一个框架
- 另一个框架只用于 1-2 个特定场景
- 这时你可以考虑把特定场景也迁移到主框架,或者保持现状
无论最终选择什么,这段"共存期"都是有价值的——它让你更深入地理解了不同工具的优势和局限。
10. 本章小结
恭喜你读完了第十三册!这一章是对 AI Agent 选型最全面的中文分析之一,让我们回顾一下核心内容。
我们理解了为什么需要对比:
选择工具不是跟风,而是要根据自身需求做理性决策。OpenClaw 和 Hermes 都有庞大的社区和光明的未来,但它们的架构哲学、技术栈和适用场景有明显差异。
我们深入对比了 12 个维度:
从主语言、架构设计、学习能力、记忆系统、工具生态、平台支持、安全体系、移动应用、模型支持、部署方式、成本到社区规模,每个维度都有详细的分析和数据支撑。
我们理解了核心差异:
- 自学习 vs 手动配置:Hermes 会自动学习和进化,OpenClaw 需要手动编写配置
- 有界记忆 vs 模块化记忆:两种设计哲学,各有优劣
- Python vs TypeScript:生态选择影响开发体验
- 轻量 vs 全能:两种架构路线,适合不同场景
- Harness Engineering vs Unix Philosophy:养马 vs 组装的隐喻
我们看了社区对比:
四个主流工具(Claude Code、Cursor、OpenClaw、Hermes)有不同的定位和角色。高级用户通常同时使用多个工具,形成自己的工具栈。
我们得到了选型建议:
通过决策树和场景化推荐,你可以根据自己的背景、需求和预算找到最适合的工具。学生/个人开发者推荐 Hermes,企业/团队推荐 OpenClaw(目前),需要移动应用选 OpenClaw,追求效率部署选 Hermes。
我们学习了迁移方法:
从 OpenClaw 迁移到 Hermes 有官方工具支持,可以自动迁移大部分内容。迁移前要做好评估,迁移后要验证和优化。我们还讨论了从 AutoGPT、MetaGPT、CrewAI 等其他框架迁移的通用思路。
我们了解了共存方案:
两个框架不是非此即彼,很多高级用户同时使用两者。通过明确分工、统一数据源、共享通知渠道,可以实现高效的共存。
最后的建议
没有最好的工具,只有最合适的工具。不要盲目跟风,也不要死守一个拒绝尝试其他。技术选型是一个动态的过程——今天最适合你的工具,一年后可能不再是最佳选择。保持开放的心态,持续学习和尝试,才能在这个快速发展的领域始终站在前沿。
无论你最终选择 Hermes、OpenClaw,还是两者都用,记住:工具只是手段,解决问题才是目的。不要让选择工具本身成为你前进的阻碍。