OpenClaw 是目前 AI Agent 领域最受关注的开源项目之一，GitHub Stars 已超过 367K，曾一度登顶 GitHub 全球趋势榜。它的定位是”本地优先的个人 AI 助手网关”——核心不是大模型本身，而是连接大模型与本地工具、消息平台的调度层。OpenClaw 的优势在于多渠道接入与自托管：支持 WhatsApp、Telegram、Slack、Discord、iMessage 等主流平台，内置会话管理、工具调用，数据不经第三方，运行在用户自己的设备上，适合对数据主权和私有化部署有要求的场景。

Hermes Agent 是 Nous Research（以 Hermes 系列开源模型著称的 AI 实验室）在 2026 年初开源的 AI Agent 框架，目前约 127K Stars，增速非常快。它的定位与 OpenClaw 不同：Hermes 的核心优势是执行能力与自进化——内置 40+ 工具、支持子 Agent 并行执行、自动从成功任务中提炼可复用技能、内置跨会话持久记忆，模型无关，支持 OpenRouter、NVIDIA NIM、Hugging Face 等多种 LLM 接入方式。值得一提的是，Hermes 官方内置了从 OpenClaw 一键迁移配置的工具，两者在生态上有天然的交集。

我是在公司云端同时引入了这两个工具。受部署环境约束，Hermes 侧没有独立的 LLM 接入，需要推理的任务统一由 OpenClaw 侧调度处理，两者必须协同工作才能完整运转。

这篇文章记录的，就是在这个约束下我做的一次融合升级：把Hermes 作为”受控执行面”装进 OpenClaw 的调度体系，让两者形成一个可治理、可追溯、可运营的整体。

摘要

两个系统各司其职：在这次升级搭建的治理体系里，OpenClaw 承担”管控、留证、裁决”的角色；Hermes 是执行能力层，负责”解析、分析、生成”。这次升级把 Hermes 装进 OpenClaw 的统一调度体系里，让两者协作而不是各自为政。

每次交付是一个包，不只是一份稿：最终稿+ 过程证据 + 执行日志 + 放量/止损指标，四件事打包交付，方便抽检、追溯和止损。

遇到不确定就停，不蒙头往前跑：输入材料不完整、校验不通过，流程自动停下来，输出一份“缺什么、怎么补”的问题清单，补齐后再继续。

一、为什么要做这次融合

1. 只用其中一个，运营侧会持续遇到麻烦

在这套约束下，如果只用Hermes 做执行、没有这套融合后的治理体系，运营侧会持续遇到三件烦心事：

稿子出来了，还是不敢直接发。 Hermes 生成产物的过程没有留存记录，无法知道它用了哪些材料、走了什么步骤。只能靠人工再过一遍才敢往外发，时间久了，人工确认就变成了默认流程。

被追问“依据在哪”时，拿不出来。合规侧或业务侧质疑某条内容的出处，过程材料没有留存，只能重新手工回溯，甚至根本找不到。

想升级工具时，不敢动。没有版本记录和回滚手段，升级出了问题不知道是哪个环节引入的，也没法快速回退。

这三个问题的根源是一样的：执行过程不透明，治理成本全部转移到运营侧，靠人扛。

2. 单靠 OpenClaw 也不够

OpenClaw 是调度网关，本身没有内置治理体系——条款解析、影响分析、内容生成这些执行类任务，它做不了；而如果让它在承担调度的同时兼做内容生产，治理就失去了独立性。单靠 OpenClaw，执行能力是缺口；单靠 Hermes，治理能力没有依托。两者必须结合，治理体系才能搭起来。

3. 融合之后能解决什么

把Hermes 装进 OpenClaw 的调度体系，让 OpenClaw 统一管控执行过程，两者结合能带来三个单独使用时都得不到的优势：

执行能力+ 治理闭环同时具备。 Hermes 提供解析、分析、生成的执行能力；这次升级在 OpenClaw 的调度层之上搭建了门禁、留证、裁决的治理体系。执行有人做，治理有结构保证，不互相越界。

推理能力集中在OpenClaw 侧，成本可控。 Hermes 不需要单独接入 LLM，所有推理走 OpenClaw 的管控通道，可以统一审计和限额，同时也节约了成本。

交付可追溯，运营侧可以自己验收。每次执行的输入材料、过程产物、门禁裁决、版本信息，全部打包存档；出了问题打开档案袋就能定位，不需要靠人工回溯。

二、为什么选择把Hermes 装进 OpenClaw 的壳

融合的方向清楚了，但融合方式不止一种，选哪种直接决定了治理成本有多高。

1. 常见做法：两套系统各跑各的

OpenClaw 和 Hermes 分别跑在独立的环境里，通过监控、告警、重试机制互相看护。这种方式部署灵活，但有一个结构性缺陷：两套系统的执行记录、证据和裁决分散在两处，需要额外的机制把它们聚合起来才能追溯。这个聚合成本完全落在运营侧，反而加重了负担。

2. 为什么不直接让 OpenClaw 自己做完

OpenClaw 能不能自己完成整个升级，不需要 Hermes？

做不到，也不该这样设计。这次融合把OpenClaw 定位为”裁判”——负责管控、门禁、留证、最终裁决；把 Hermes 定位为”运动员”——负责解析、分析、生成产物。这个分工是刻意设计的：如果让 OpenClaw 既负责生产内容，又负责对自己的产物做质量裁决，门禁就失去了意义——裁判和运动员是同一个人，检查结果自然不可信。

两个系统的分工不是架构偏好，而是为了保证“裁决可信”这件事在结构上成立。

3. 这次的选择：嵌入式执行面

把Hermes 装进 OpenClaw 的统一调度体系，让 OpenClaw 通过一个固定入口（Runner）调度 Hermes。这样做的好处是：超时控制、权限管理、日志和证据天然在同一个地方收口，不需要额外聚合。

更关键的是，这种结构让一条规则变得可以强制执行：Hermes 的产物必须先通过 OpenClaw 的门禁检查，过了才进入下一步，没过就停。在双进程方案里，这条规则只能靠约定，随时可能被绕过；在嵌入式方案里，这条规则是结构上的硬约束，无法跳过。

这就是为什么选嵌入式：不是因为它更复杂，而是因为它把治理成本从“靠人约定”变成了”靠结构保证”。

三、交付目标：运营可以自己验收的四件事

确定了融合方式之后，下一步是把交付标准写清楚——要做到什么程度，运营侧才能真正用起来。

要实现这四个目标，需要在运行架构上做相应的设计——不能只靠约定，要靠结构来保证。

四、融合后的运行方式

一次请求的完整路径是：运营提交任务→ OpenClaw 接管调度与门禁 → Runner 调度 Hermes 执行 → 产物和证据统一归档到档案袋。这套结构有一条贯穿始终的行为规则需要特别说明：不确定即停止推进。缺信息/ 校验不通过 / 超时，流程立刻停止，转入”补材料 / 人工确认”路径，不蒙头继续跑。这也是它区别于普通自动化流程的关键——遇到不确定，宁可停下来问，也不带着缺口往下生成。

五、落地方式：看目录、看文件就能验收

前面定了四个目标：可回放、门禁可机读、升级可控、可运营。这四件事不是靠流程约定来保证的，而是靠每次运行必须产出的具体文件来兑现。验收方式也很简单：看目录是否完整、看文件里写的是通过还是拦截。

1. 每次运行，留一只完整的”档案袋”

每次运行统一归档，目录结构固定，包含五类内容：

·Context：任务定义与约束（这次要做什么、有哪些限制）

·Inputs：只读输入快照（原文、附件，进来就锁定，不会被修改）

·Outputs：业务产物（结构化结果、分析报告、最终稿）

·Evidence：证据索引与门禁裁决（这次通过了什么、被拦了什么）

·Logs：执行日志（出问题时定位用）

运营侧验收只需要检查这个目录是否完整、Evidence 里的裁决文件写的是”通过”还是”拦截”。

2. 每一步都有”结果回执”，门禁自动判断能不能继续

每个执行步骤完成后，系统都会生成一份结果回执文件。它回答三个问题：

·这一步通过了吗？（通过/ 拦截 / 需人工确认 / 超时 / 出错）

·产出了什么？（文件清单）

·还缺什么？（如果没通过，这里会列出问题清单）

硬规则：任何一步没通过，后续步骤全部停止。目的是防止上游有缺口时，系统继续往下跑、生成一份有问题的最终稿。

3. 证据包：五类归档，缺一不可

每次运行归档时，以下五类内容必须齐全，缺任何一类，本次运行视为不完整：

·输入索引：记录这次用了哪些原始材料，以及每份材料的“指纹”（用来证明材料没被替换）。

·产物索引：记录这次生成了哪些文件，同样附带指纹。

·运行元信息：本次运行ID、各组件版本、耗时、退出状态。

·门禁裁决文件：通过/ 拦截 / 需人工确认，附上原因和策略版本。

·执行日志：最小化的标准输出与错误输出。

所谓“文件指纹”，就是对文件内容做一次数学计算，得到一串唯一的编码。只要文件内容有任何改动，指纹就会变。用这个方法可以证明：存档里的材料和产物，就是当时实际使用/生成的那份，没有被替换过。

4. 执行边界：Runner 固定入口，Hermes 只做执行

OpenClaw 永远只通过固定的 Runner 入口调度 Hermes，不直接绑定命令行，保证入口稳定、可替换、可审计。

适合交给Hermes 做的：条款解析、影响分析、优化建议、按已确认的决策生成最终稿。

必须由OpenClaw 主导的：质量门禁、最终裁决、一切对外的不可逆动作。

六、实际运行示例：一次“制度变更”任务怎么跑

前面讲的是系统层面的标准件。下面用一个具体任务来看这套机制在运营侧实际跑起来是什么感受。以制度管理（PolicyOps）为例，走一遍完整流程。

运营侧需要准备什么（最小集）

·变更背景：为什么改、何时生效、适用范围。

·制度材料：原文+ 附件（提交后系统自动锁定快照）。

·决策点清单：哪些地方需要人工确认（重要程度标P0 / P1）。

流程怎么跑

被门禁拦住时，运营会看到什么

门禁拦截时，系统会输出一份问题清单，每一条都写明缺什么、怎么补，不是模糊的报错信息。例如：

·“必填字段【生效日期】缺失——请补充后重新提交。”

·“前后引用的版本号不一致——请确认以哪个版本为准。”

·“依赖的上游产物文件缺失，无法继续校验——请重新生成后继续。”

运营同学按清单逐条处理，补齐后重新提交，流程从断点继续，不需要重跑全程。

结语

这次升级的核心，不是引入了什么新工具，而是确立了一套运营侧可以直接验收的交付标准。

对运营同学来说，最直接的变化是：以后遇到“这个产物靠不靠谱””上次的依据在哪””出了问题是哪一步引入的”这类问题，不用再靠人工回溯——打开档案袋，证据、裁决、日志都在里面。

治理是否有效，取决于这套机制能否在日常运营中真正用起来。交付包能不能成为团队的默认动作，比工具本身更重要。