博客园  :: 首页  :: 联系 :: 管理

从“会干活”到“会成长”：从OpenClaw 到 Hermes，看懂 Agent 的进化路线

Posted on 2026-07-18 17:51  天戈朱  阅读(23)  评论(0)    收藏  举报

这里的“从 OpenClaw 到 Hermes”不是产品替代关系。 它们代表两种不同的工程侧重点：一个更关注把 Agent 接入真实系统并持续执行；另一个更关注在长期协作中沉淀经验、复用方法。

很多人第一次接触 OpenClaw 和 Hermes 时，都会有一个疑问：它们看起来都能聊天、调工具、做任务，到底差在哪里？

关键不在于模型本身，而在于它们优先补齐了 Agent 工程中的哪一部分能力。

OpenClaw 更关注：让 Agent 接入真实工作环境，连接工具与系统，并将明确的任务持续执行下去。Hermes 更关注：让 Agent 记得住经验、复用方法，并在长期协作中逐渐变得更熟练。

一、先用一个“项目发布助手”理解问题

假设团队准备发布 AIBOX 2.0。产品经理提出目标：

下周准备发布 AIBOX 2.0。请每天检查研发、测试和部署风险，把关键阻塞项同步到钉钉群。

这不是一次普通问答，而是一项持续数天甚至数周的工作。它需要：

  • • 读取代码变更、Bug 列表、测试结果和发布计划；

  • • 判断哪些问题可能影响发布；

  • • 每天定时检查是否出现新的风险；

  • • 遇到关键阻塞项时提醒负责人；

  • • 在发布结束后，把有效检查经验留给下一次使用。

这体现了 Agent 从‘能够回答问题’ 走向 ‘能够持续交付结果’ 的演进过程。

二、人设计系统，OpenClaw 持续运行

一个常见误解是：只要装好 Agent，它就会自动理解项目、设计流程并稳定运行。

现实并不是这样。对于“项目发布助手”，人仍然要先定义工作的骨架：

  • • 目标与验收标准：每天检查哪些风险；日报要包含哪些字段；

  • • 数据来源：代码仓库、Bug 系统、测试平台、发布文档；

  • • 权限边界：哪些数据只读；哪些操作必须人工审批；

  • • 触发规则：每天固定时间检查，还是关键 Bug 出现时立即检查；

  • • 结果出口：日报发到哪里；哪些情况需要提醒负责人；

  • • 异常处理：获取数据失败、规则冲突或高风险时如何暂停、转人工或重试。

可以把这一步理解为：人先设计 Harness 与 Loop 的基本框架。

设计时：人定义“项目发布助手”的工作方式

目标与验收标准
  - 每天检查发布风险
  - 输出风险、负责人、阻塞项
  - 高风险必须人工确认
          ↓
Loop 编排与配置
  - 定时检查规则
  - Bug 事件通知
  - 数据系统连接
  - 权限、审批与通知策略
          ↓
部署到 OpenClaw Gateway

OpenClaw 的价值，是把这些规则、工具和任务入口组织成一个可长期运行的执行环境。

三、OpenClaw：让 Agent 进入工作现场

在这个例子中，OpenClaw 更像 Agent 的连接与执行中枢。

运行时：OpenClaw 按既定 Loop 持续执行

每日定时任务 / Bug 事件通知
                ↓
        OpenClaw Gateway
                ↓
Agent 读取 Context、调用工具、执行检查
                ↓
代码仓库 / Bug 系统 / 测试平台 / 文档 / 日历
                ↓
验证结果、更新任务状态、形成风险结论
                ↓
钉钉群同步 / 提醒负责人 / 等待下一次触发

在这个流程里：

  • • 每日定时任务：按固定节奏执行风险巡检；

  • • Bug 事件通知：关键变化发生时立即触发补充检查；

  • • OpenClaw Gateway：承接触发、调度 Agent、管理工具调用；

  • • 钉钉群：接收日报、风险告警和人工确认请求。

因此，OpenClaw 首先解决的是：

怎样让 Agent 从“会回答”变成“能接入真实系统，并持续执行工作”？

OpenClaw 提供 Gateway、Cron、工具策略、命令审批与可选隔离执行环境等能力。需要注意：工具权限、隔离执行和高权限执行是不同的安全控制，应按实际场景分别配置。

四、Hermes：在持续运行中沉淀经验

Hermes 也需要事先设计。

在“项目发布助手”这个例子中，人依然要先定义任务目标、可访问的数据系统、自动化触发规则、高风险审批边界、初始检查清单和基础 Skill。

换句话说，Harness 与 Loop 的骨架仍然由人设计。

Hermes 的特色不在于“无需设计就会自己把流程搭好”，而在于：它能在持续运行过程中，把长期稳定的经验逐步沉淀下来。

人先设计工作框架
        ↓
OpenClaw 或 Hermes 让框架持续运行
        ↓
Hermes 从执行记录中识别稳定偏好、规则与有效方法
        ↓
小而稳定的事实、偏好与环境约束 
→ 写入 MEMORY.md 或 USER.md 
较长、可重复执行的方法与流程
→ 沉淀为 Skill 
        ↓ 
根据治理策略配置决定沉淀方式
├─ 允许自动写入 → 直接沉淀 
└─ 开启审批门控 → 进入 Pending，等待人工审核
        ↓
下一次任务在更成熟的框架中执行

如下示意：开启记忆与 Skill 的写入配置开启后 Hermes 生成的 Memory 或 Skill 不会直接写入，而是进入 Pending，等待人工审核、修改、批准或拒绝。

memory:
  write_approval: true

skills:
  write_approval: true

例如，经过几次发布后，系统可能逐渐沉淀出：

  • • 发布前必须检查算法版本、设备固件和云端接口兼容性；

  • • 某些类型的 Bug 常在上线前两天集中暴露；

  • • 你更关心“风险、负责人、阻塞项”，而不是冗长过程；

  • • 高风险项不能自动推进，必须人工确认；

  • • 某些检查步骤反复有效，值得沉淀为标准流程。

所以，更准确的说法是：

OpenClaw 更偏“把人设计的流程跑起来”；Hermes 更偏“在既定流程中，把有效经验留下来，并辅助人持续改进流程”。

五、OpenClaw 与 Hermes 分别走到五层能力体系的哪一步？

前文提到过：

Context 包含 Prompt；Harness 组织 Context 并约束执行；Loop 基于 Harness 持续编排任务；Meta-Loop 评估并优化整个系统。

从五层能力体系看，OpenClaw 与 Hermes 都已覆盖 L1 到 L4。

两者真正的差异，不在于谁“有没有”工具调用、定时任务或 sub-agent，而在于产品能力的组织重心不同：OpenClaw 更偏执行治理；Hermes 更强调知识沉淀与复用。

L3：Harness—如何进入真实流程？

OpenClaw 更强调执行治理。Gateway、Tool Policy、Exec approvals、sandboxing 等能力，重点是让 Agent 能够进入真实系统，但始终处于明确的权限、审批和隔离边界内。

Hermes 同样具备工具调用、命令执行、授权和隔离能力，只是更强调让工具调用与项目上下文、Memory、Skill 结合起来。

简言之：
OpenClaw：先管住 Agent 能做什么、在哪儿做。
Hermes：让 Agent 带着已有项目经验去做。

L4：Loop—任务如何持续推进？

定时触发、任务分派、异常后的后续处理，OpenClaw 与 Hermes 都具备，能力差异并不本质。OpenClaw 的 Gateway Cron、Heartbeat、Webhook、Task Flow 是这一层的典型实现；Hermes 也提供内置 Cron 与 sub-agent，可按计划执行任务或分派子任务。

两者的差别更多是工程实现和产品重心，而不是能力是否具备。

L5：Meta-Loop—经验能否沉淀并复用？

Hermes 在这一层更具辨识度。它尝试把稳定事实、用户偏好、项目规则沉淀为 Memory，把验证有效的工作方法、操作步骤和输出规范沉淀为 Skill；后续遇到类似任务时，再优先召回和复用。

这使 Hermes 不只是“记住历史对话”，而是在逐步形成可复用的项目知识和工作方法。但需要注意：这更像是 Meta-Loop 的轻量雏形，而不是完整形态。

完整的 Meta-Loop 不只是“把经验记下来”，还需要能系统地比较不同做法：哪套流程质量更高、成本更低、风险更小；并在出现问题时支持版本回退和人工接管。

Hermes：
把经验留下来，下一次优先复用。

完整 Meta-Loop：
比较多套做法，找到更优方案，并保证可控地上线与回退。

六、Hermes 的记忆管理：它为什么会“越用越懂你”？

Hermes 的“记忆”并不是把所有历史对话都塞回 Prompt，而是把不同类型的信息分开保存、按需调用。

当前任务
   │
   ├─ 常驻规则：平时应该怎样协作
   │  用户偏好、项目约束、长期原则
   │  典型载体：USER.md、MEMORY.md
   │
   ├─ 会话历史：过去发生过什么
   │  历史讨论、排查过程、已确认结论
   │  典型实现：SQLite + FTS5 全文检索
   │
   ├─ Skill：这类事情通常应该怎样做
   │  可复用步骤、检查项、输出规范
   │  典型载体：SKILL.md
   │
   └─ 外部知识库：需要时去哪里查资料
      文档、会议纪要、规范、代码和笔记

这里的分类是便于理解的工程抽象，并不是 Hermes 官方定义的固定分层。

1. 常驻规则：记住长期有效的信息

Hermes 会维护两类核心记忆文件：

  • • USER.md：保存用户偏好、沟通习惯、常用表达方式等；

  • • MEMORY.md：保存项目环境、工作规则、已验证经验和重要约束。

例如：

关键不在于“记得越多越好”，而在于：只把稳定、重要、可行动的信息放进常驻记忆。

2. 会话历史：需要时再找回来

三个月前某次发布失败的详细排查过程，平时不需要一直带进 Prompt；但当类似问题再次出现时，Agent 应该能够找到它。

当前任务：
“为什么测试环境部署失败？”
        ↓
搜索历史会话：
“上一次同类故障如何处理？”
        ↓
找到旧记录：
“当时是镜像标签与配置文件版本不一致”

Hermes 默认将会话保存在本地 SQLite 中，并利用 FTS5 支持全文搜索。

3. Skill：把“知道什么”升级为“知道怎么做”

记忆保存的是事实、偏好和约束；Skill 保存的是方法。例如，项目发布助手可以沉淀一个“发布检查 Skill”：

下一次发布时，Agent 不需要从零摸索，而是可以先加载这个 Skill，再结合本次项目资料执行。Skill 保存的不是某个事实，而是一类任务可复用的做法。

4. 外部知识库：需要时再取，不要长期塞进上下文

项目资料、会议纪要、规范文档和个人笔记，通常不适合全部写入长期记忆。更合理的方式是：

文档 / 知识库 / 会议纪要
          ↓
任务发生时按需检索
          ↓
提取与当前任务相关的少量内容
          ↓
作为本轮 Context 提供给模型

Hermes 可以通过外部 Memory Provider 或可选检索工具扩展长期知识能力。例如 Qmd（Query Markup Documents） 可对本地知识库、笔记、文档和会议记录进行混合检索。

5. 本地优先，不等于不能云端同步

Hermes 的默认思路是本地优先：

  • • 常驻规则保存在本地 Markdown 文件；

  • • 会话历史保存在本地 SQLite；

  • • Skill 以本地文件形式保存；

  • • 外部知识可以按需通过 Provider 或检索工具接入。

这并不意味着 Hermes 无法使用云端或团队级记忆。它提供了 Memory Provider 机制，可接入外部记忆服务；但默认不会把所有记忆自动统一托管到云端。可以这样理解：平台型产品更偏账号级、云端托管的记忆体验；Hermes 更偏本地优先、用户可查看和管理，再按需扩展外部或自托管记忆。

七、延伸观察：WorkBuddy 是另一条“产品化交付”路线

OpenClaw 与 Hermes 更关心“如何构建、运行和沉淀 Agent 能力”；WorkBuddy 更强调把任务、自动化、记忆和工具调用封装成办公用户可直接使用的交付体验。

一个偏运行底座，一个偏长期经验，一个偏产品化交付。

OpenClaw： 把 Agent 接入真实工具，让它开始做事。Hermes： 把完成过的任务沉淀为记忆和 Skill，让它下一次更像“熟手”。WorkBuddy： 把复杂的 Agent 能力封装起来，让用户直接得到成果。

八、结语

Agent 靠不靠谱，关键不在于它会不会聊天，而在于有没有一套机制让它：

  • • 知道该做什么；

  • • 能安全地调用工具；

  • • 可以持续推进任务；

  • • 出问题时有人能看见、能叫停、能回退。

OpenClaw 更强调：让 Agent 安全进入真实系统，真正把事做起来。Hermes 更强调：让 Agent 把经验留下来，下次不用从头再来。更成熟的 Agent，最终要做到的是：

既能持续干活，也能在可控范围内越做越好。

参考资料（官方文档）