对照专题：Hermes 与 OpenClaw 的设计差异
“Hermes 会积累技能，OpenClaw 只负责接聊天软件”——这样的概括容易记，却不足以比较当前系统。两者都已经包含模型与工具循环、持久状态、记忆、技能和后台任务，还会继续演化。
经过前面的主线，更有价值的问题是：面对同一份简报任务，两者在哪里组织输入，谁持有状态，经验何时加载，任务如何触发，失败后依据什么继续？
本章核对范围为 Hermes v0.22.5 与 OpenClaw v2026.10.7，核对日期为 2026 年 10 月 26 日。它是固定版本机制对照，没有进行两套系统的同环境性能比赛，不提供速度、成功率或成本排名。
18.1 先固定同一项任务
仍使用自编材料 A、B、C：只包含两件事件，B 对图片的说法与 A 冲突，C 没有准确率提升的依据。相同完成标准是去重、保留限制、说明数量不足，未经授权不发送。
比较时还要记录模型、工具、上下文范围、身份配置、运行后端和授权。若甲使用更强模型、更多资料，乙受限于离线材料，就不能把结果差异全部归因于 Agent 架构。
本章将官方固定版本的机制放进同一问题框架。有关代价的分析是基于这些结构作出的设计推论，不冒充实测结果。
18.2 两套系统怎样把消息变成行动
Hermes 的统一责任图从入口进入核心运行，组织输入、访问模型、执行工具并保存结果。CLI、桌面、网关和后台任务可以复用相关能力；网关也承担规范会话与状态管理，不只是一根消息转发线。
OpenClaw 的官方架构以长期运行的 Gateway 为中心：客户端、消息渠道和具备能力的节点连接到它，由相应路由与运行路径组织会话、模型和工具。节点可以暴露设备能力，客户端则通过协议发请求并接收事件。
这是理解入口不同的两种观察角度，不能简化成“一个有核心、另一个只有网关”。OpenClaw 也有明确的 Agent 运行生命周期；Hermes 同样需要身份、队列与网关协调。
在 OpenClaw 中，一项请求被接受后会有自己的运行标识，运行、工具、流式响应和结束通过相应事件组织；部分路径还区分嵌入式运行与其他运行后端。Hermes 也把模型响应、工具轮与运行终止分开处理。
对使用者，差异体现在连接、运行和状态配置怎样组合；对学习者，值得迁移的是“请求被接受不是任务完成，文字流出现也不是运行结束”这一共同设计要求。
18.3 多个助手的持久边界怎样表达
Hermes 以 Profile 的持久 home 组织配置、记忆、技能、会话与调度等材料，再通过不同入口或 Bot 呈现出来。多个会话与临时委托子任务不自动等于多个 Profile。
OpenClaw 的多 Agent 路由为每个长期身份组织工作区、状态目录、认证及会话存储，通过 bindings，也就是绑定规则，将渠道账号等来源路由到相应 Agent。临时子任务与这种长期身份路由也需要分开理解。
| 同一设计问题 | Hermes 的组织方式 | OpenClaw 的组织方式 |
|---|---|---|
| 独立的长期助手材料 | Profile home 与相关配置、数据 | 每个 Agent 的工作区、状态与会话归属 |
| 消息进入哪一个助手 | 相应连接与 Profile/会话路由 | 渠道账号等条件与绑定规则 |
| 短期分工 | 委托子 Agent 的独立对话与返回 | 有相应子任务/跨会话机制，需区分长期身份路由 |
| 能否访问其他资料 | 看工具、账号与执行环境 | 工作区同样不是强制沙箱，仍需访问限制 |
两种方式都使状态归属显式化，也都不能证明所有外部插件存储和认证资源绝对独享。对简报助手，应分别列出私人草稿、工作资料、渠道账号和外部服务的共享范围，不能只比较配置文件个数。
18.4 记忆保存与进入输入，在哪里分开
Hermes 的默认精选记忆与用户画像以有容量的材料组织，在会话开始准备快照。历史检索另有职责。写入持久材料与修改当前会话的固定前缀是不同时间点，超容量也需要整理或处理。
OpenClaw 同样有精选长期材料与用户信息，也组织按日期的工作记录，并通过记忆检索等机制找回相关内容。部分近期记录会在相应新会话路径加载，不能因此说全部日记都逐轮完整注入。
一个可具体比较的区别是容量压力如何表现。Hermes 的相关精选记忆操作对容量有约束，超限会返回需要处理的结果；OpenClaw 的启动材料超过相应预算时，可以保留磁盘原文件，同时截短注入副本。这两种处理都要求管理信息，代价表现不同。
前者促使写入时整理，可能让“记住这件事”当下失败；后者保留原文，但读者若只查看磁盘，就可能误以为模型已经读全。两者共同需要可观察的加载与截断状态，也需要将细节移入可检索资料，而不是不断放大固定前缀。
OpenClaw 还有后台整理相关机制，例如将工作记录中的有用信息提炼到长期材料。Hermes 也有自身记忆与整理扩展。不能从名字或一句“有记忆”推断具体配置、写入时机和实际效果相同。
18.5 技能积累不能再按“有或没有”比较
两者都能读取以 SKILL.md 等材料表达的方法，并按来源、配置和可用条件组织发现。方法保存为文件或相关持久资料，仍不同于修改模型权重。
Hermes 的方法查看、管理与渐进加载，使 Agent 可以按需要展开方法正文；Curator 等整理能力负责相关生命周期，确定性整理与可选模型整理需要分开核对。
OpenClaw 除了工作区、项目、共享等来源，还有 Skill Workshop，管理 Agent 自己保存的 learned skills，也就是习得方法。它可以记录先前版本、撤销变更并归档不再使用的方法；已有会话的技能快照与后续会话加载也有时间边界。外部安装方法与 Workshop 方法并非同一维护对象。
因此，不能把 Hermes 概括成唯一会积累经验的系统。应比较下面几件事：谁决定保存；适用范围写在哪里；运行时什么时候展开；改错后怎样恢复；长期不用时怎样处理；换会话后是否实际读到新版本。
对简报方法，两个系统都应面对同一反例：方法错误地把转述当原公告，修订之后下一次是否真的采用？文件更新成功只完成了保存环节，还需要检查加载和任务表现。当前没有同环境实验，不能宣布谁学得更快。
18.6 调度怎样选择会话，怎样表达交付
Hermes 的典型定时 Agent 任务在新会话中组织输入，可以绑定技能、工作位置与模型选择；不需要模型的工作也有相应执行方式。任务定义必须能离开创建它的聊天独立成立。
OpenClaw 的自动化区分多种任务载荷与会话执行方式，包括主会话、当前会话、隔离或自定义会话等路径。任务在哪运行，与结果交到哪里，是分别配置和管理的关系。
这带来一个可解释的取舍：独立会话减少无关旧聊天影响，但要求明确任务材料；沿用已有会话更容易延续上下文，却要处理排队、代次和归属。选项多提供表达空间，也要求维护者清楚选择了哪条路径。
交付也不能只看最后的成功字样。Hermes 的排队投递区分待发送、投递中、完成、失败或未知；OpenClaw 的相应自动化交付也区分不同模式与结果，对部分无法确认是否到达的发送保留未知，不盲目重复。
本书实际执行了 Hermes 队列的一组受控路径，没有执行 OpenClaw 的同组模块或真实渠道测试。这说明我们有一侧的局部实测，另一侧有固定文档核对，不能将其包装成完整可靠性对决。
18.7 由需求决定下一步验证
| 如果重点是 | 应在两套系统上核对什么 | 尚不足以作结论的材料 |
|---|---|---|
| 长期复用简报方法 | 技能保存、版本、加载与纠错轨迹 | 宣传页写“持续学习” |
| 多账号、多入口 | 实际路由、身份与会话隔离 | 支持平台名称列表 |
| 后台按时交付 | 离线恢复、配置失效、产物与回执 | 一次手动触发成功 |
| 控制费用 | 相同任务质量下的全部调用与等待 | 单次回复价格或速度 |
| 控制数据边界 | 凭据、挂载、工具、插件和渠道权限 | 仅有独立工作区或安全提示词 |
这些检查有些可以先做确定性模块试验，有些必须在同模型、同材料和相近环境下运行任务。比较范围越明确，结果越有用；产品仍在变化，固定版本结论也不宜无限期沿用。
本章要点
- 两者都已具备多种 Agent 机制，应比较组织方式、状态转换和具体代价。
- Profile 与长期 Agent 路由、精选记忆与工作记录、技能来源与维护路径，都需要按相同职责对齐。
- 保存不等于加载、接受不等于完成、完成不等于送达，是跨产品成立的设计问题。
- 固定版本机制核对可以支持架构分析；效果、成本和可靠性排名需要同条件实验。
理解题
1. OpenClaw 有 Skill Workshop，是否说明 Hermes 的技能章节已经没有学习价值？
没有。章节学习的是方法怎样保存、发现、展开、纠错和维护，这些思想可以跨系统迁移。比较应继续看两者的具体实现与时间边界，而不是用共同功能否定某一方的设计价值。
2. 两套系统都保存同样的偏好文字，为什么同一任务表现仍可能不同？
实际注入范围、快照时机、截断、检索、工具说明、模型和运行路径都可能不同。磁盘文字相同不等于本轮模型输入相同，更不等于行动结果相同。
3. 本书测试了 Hermes 的未知投递分支，能否推断它比 OpenClaw 更可靠？
不能。一侧局部实测不能与另一侧未执行的状态直接比较。应先定义相同故障、版本、执行与交付条件，再分别采集结果，并保留覆盖范围和未测部分。
能够用这些问题读懂另一个系统，就说明你已开始把 hello-hermes 中的知识当作设计工具，而不只是记住产品功能。