OpenClaw & Hermes 深度使用(二)

距离上一篇文章《OpenClaw & Hermes 深度使用（一）》已经过去10天，这10天中一直在交叉使用OpenClaw与Hermes，为了公平对比这两个工具，在使用期间我设定了以下规则和计划：

设定规则：

1.同时使用minimax m2.7模型

2.同时向他们提问同一个问题，然后不断纠正。

3.为了公平对比，我清空了openclaw的人格文件，“/root/.openclaw/workspace”目录保持默认。同时，hermes这边创建了一个全新profiles目录，“/root/.hermes/profiles”。此时，二者均清空了SOUL.md文件。

一、多个场景横向对比

第一个测试场景：生成裁判案例思维导图

第一个测试场景，分别给OpenClaw和Hermes安排一个生产思维导图的任务

提示词：“请将**/**/上海某某港实业有限公司破产清算转破产重整案.txt”生成思维导图（html方式呈现）”

根据任务完成度，OpenClaw的结果符合预期，但耗时更长、消耗token更多

以下是OpenClaw生成的思维导图

相比之下，Hermes虽然没有按照传统的思维导图的形式呈现，而是以大纲形式呈现。但仍然完整、清晰地展现了这份裁判案例，而且在html美化方面更惊艳。

在这个生成思维导图的任务场景中，OpenClaw在执行这个任务的过程中表现的中规中矩，符合了预期，也没有什么惊艳，相对消耗时间和token都较多一些。

Hermes虽然用另一种形式呈现了任务结果（大纲式的总结），且消耗时间和token都较少，但他明显有自己的想法（没有完全按照任务设定输出）。

怎么理解Hermes的行为呢？举个例子，你给他一个任务“帮我制造一辆自行车”，Hermes最终会给你交付一辆电动自行车，但电机和电池并不匹配，还需要你二次优化。

Hermes的确有自我进化的感知能力，但这情况要一分为二来讲。这种“主动讨好”用户行为，在创作创意方面可以无限发挥，给用户提供惊喜和灵感。但在法律场景下，我更愿意将他称作为一种AI幻觉，在需要严谨的使用场景下，我是不能接受的。

第二个测试场景：抓取并翻译英文技术文档

第一个测试场景是在 CLI模式下进行的，第二个测试场景转向飞书消息gateway。

本次测试任务：抓取“https://dify.ai/blog/deep-research-workflow-in-dify-a-step-by-step-guide”，完整的翻译成中文文档。

这个任务结果基本没有差异，但OpenClaw与飞书的集成显然更契合。

以下是OpenClaw抓取英文并翻译的结果：

以下Hermes抓取英文并翻译的结果：

第三个测试场景：多agent工作流模拟民事诉讼程序

同时给OpenClaw和Hermes一个基于dify的模拟民事诉讼程序的工作流设计，规划如下：

1.这个工作流的多agent角色包括原告、被告、三名法官agent组成合议庭

2.原告、被告agent角色使用相同LLM大模型（qwen3.6plush）

3.三名法官agent角色分别使用大模型为qwen3.6plush、DeepSeekR1、minimax 2.7.

这个任务场景中，openclaw几乎是碾压hermes，openclaw能够充分理解dify的工作流工作模式，不但给出的各个工作流的设计蓝图，而且为每个LLM节点设计了提示词。

反观hermes，既不理解dify工作流编排，也不理解民事诉讼程序。

二、定位之分：通信中枢与任务引擎

根据以上几个场景的横向测试对比后，可以得出的观点是：二者之间不存在简单的“平替”关系，它们更像是一场关于“稳定、可靠”与“感知、进化”的协同配合。

要彻底理清OpenClaw与Hermes这两个工具的定位，得先回到它们的底层逻辑上。

1. 1. OpenClaw：更像是agent的总调度 OpenClaw 的基因是连接，它本质上是一个高性能的消息网关，并在此基础上内置了智能体处理能力。 它的强项在于工程稳定性，能够打通全球超过50种通信协议，无论是正式的邮件，还是各类社交媒体渠道，都能统一接入。 它的设计哲学是确定性。所有的行为逻辑都清晰地定义在 soul.md 和 tools.md 这样的配置文件中。在对容错率要求极高的法律研究、风险管理等场景里，OpenClaw 就像一层最稳妥的“地基”。
2. 2. Hermes：具备“自我进化”能力的执行核心 Hermes 的基因是学习。它是 News Research 团队对智能体能力演进的一次前沿探索。 它的强项是拥有自我学习的闭环。在目前的开源体系中，Hermes 是少见的能够将执行经验沉淀为可复用资产的结构。 它的设计哲学是动态迭代。它不满足于仅仅执行预设的脚本，而是会在任务完成后主动反思：“刚才的做法是最优的吗？如果是，我就把它固化为一项永久技能。”这让它的能力可以随使用次数的增加而持续增强。

三、深入对比：Hermes 真的能取代 OpenClaw 吗？

1. 1. 场景适配：覆盖广度 vs 任务深度 在多端触达场景下，如果需要处理agent任务，OpenClaw 几乎是唯一选择。 而在复杂任务的迭代场景下，例如自动化代码审计或长篇法律文书的交叉比对，Hermes 会越用越强。它所采用的 https://agent-skills.io/ 规范，能让它在持续工作的几周后，比初次配置时要聪明好几个量级。
2. 2. 记忆与检索：向量搜索 vs 全文语义 OpenClaw 沿用经典的 RAG 架构，偏重于从静态的 memory.md 文件中检索事实。 Hermes 则基于 SQLite等数据库引擎，实现了跨会话的全文语义搜索。它不仅能记住你对它说过什么，更能回溯到三周前它是如何思考并解决类似问题的。这种对“认知过程”的检索与复现，正是 OpenClaw 目前所欠缺的。
3. 3. 控制风格：显式规则 vs 自主演化 OpenClaw 的优势在于一切行为都可追溯、可审计。对于需要严格按照 SOP 运行的任务，这种显式控制至关重要。 Hermes 则会根据历史经验动态调整策略。这在追求创新和效率的场景中是优势，但如果缺乏审核机制，也可能带来不可预期的偏差。

四、并行策略：我的“双引擎”实战架构

在实际的私有化部署中，我并没有在两者间做单选题，而是构建了一套“中枢调度 + 深度执行”的并行方案。

1. 1. 用 OpenClaw 做“外壳”与调度中心 作为一名资深的法律与金融从业者，我将 OpenClaw 部署在云端作为系统唯一的对外交互出入口。 它负责过滤无效信息。同时，那些需要严格复刻、不容出错的标准作业流程也全部由它来承担。
2. 2. 用 Hermes 做“内核”与执行专家 当 OpenClaw 接收到那些需要高度灵活性或多步推理的复杂任务时，它会通过 API 将任务委派给后台的 Hermes 实例。 Hermes 在一个受控环境下专注执行，并在此过程中不断沉淀出新的技能文件。这些文件在经过我的人工审核后，会反哺回整个系统，最终积累成我专属的数字能力资产。

总之，这并非一场谁吃掉谁的博弈。在真实的业务场景中，让擅长连接的工具去打通所有节点、做显式控制，让擅长学习的工具去深钻复杂事务、沉淀经验，才是更成熟也更具实效的工程选择。二者并行不悖，反而能构建出一个既稳定又持续进化的生产力系统。