← 返回文章列表

2026年5月3日

OpenClaw、Hermes 和 Harness：它们到底是什么关系

梳理 OpenClaw、Hermes Agent 与 Harness 在 Agent 体系中的分层、定位与关系。

OpenClaw、Hermes 和 Harness：它们到底是什么关系

很多人第一次看到 OpenClaw、Hermes Agent、Harness 这几个名字，会有一种很自然的混乱：

它们是不是同一种东西？
是不是谁比谁更高级？
是不是 OpenClaw 和 Hermes 都是在做 Harness？
那 Harness 到底是一个产品，还是一种架构思想？

如果上来直接给定义，反而会越讲越绕。更好的方式是先回到 Agent 真正遇到的问题。

当大模型从”会聊天”变成”能替你做事”以后，最难的已经不是回答问题，而是把它放进什么样的运行环境里。

这是理解三者关系的入口：

OpenClaw 解决的是：Agent 怎么接入你的日常入口并被唤起
-> Hermes Agent 解决的是：Agent 怎么记住经验并逐渐沉淀能力
-> Harness.io 解决的是：Agent 怎么进入企业流水线并被治理
-> Agent Harness 是它们背后共同的工程思想

先说明一个小细节：Hermes Agent 和 Harness 只差几个字母，但说的不是同一个东西。前者是一个具体系统，后者在这里主要指 Agent 外层运行系统这类架构思想。

为了让这篇文章不飘，我们固定一个例子：

我希望有一个 AI 助理，每天早上帮我：
1. 看一眼重要消息和技术新闻
2. 结合我的兴趣过滤掉噪音
3. 把值得看的内容整理成摘要
4. 如果发现项目 CI 失败，自动分析原因
5. 需要改代码或发 PR 时，先按团队规则走审批

这件事看起来像一句”让 AI 帮我自动化”。但拆开以后，你会发现它至少包含三层不同问题：

• 它怎么从 Telegram、飞书、Slack 或网页入口被叫起来？
• 它怎么记住我的偏好、历史任务和常用处理方式？
• 它怎么在企业工程流程里安全执行、审计、审批和回滚？

OpenClaw、Hermes Agent、Harness.io 的差别，就藏在这三层问题里。

一、故事要从”Agent 已经能动起来”开始

前文已经讲过：[[03.从对话到干活-Agent#四、Agent 为什么会出现：因为真实任务不是一次问答，而是一串循环|Agent]] 不是模型突然长出了手脚，而是模型外面接了一套工具、状态和执行循环。

一个最小 Agent 大概长这样：

用户提出目标
-> 模型判断下一步
-> 调用工具
-> 工具结果回到上下文
-> 模型继续判断
-> 直到完成、失败或需要用户决策

这一步解决的是”模型怎么从说话变成做事”。

但一旦 Agent 真的能做事，新的问题马上出现：

它在哪里做事？谁能叫醒它？记不记得以前做过什么？能不能碰文件、浏览器、终端、密钥和生产环境？出了事谁负责？

这时就不能只说”模型 + 工具”了。

真实 Agent 系统需要的是一整套外壳：

• 入口：消息从哪里来
• 上下文：模型每轮看到什么
• 工具：它能调用什么能力
• 状态：它做到哪一步
• 记忆：什么经验应该留下来
• 调度：它什么时候被唤醒
• 权限：哪些动作能直接做，哪些必须确认
• 审计：做过什么能不能追踪
• 验收：怎么判断真的完成

这套外壳，就是前文专门讲过的 [[04.如何让Agent更好干活-Harness#三、Harness 到底是什么|Agent Harness]]。这里可以直接沿用那个公式：

Agent = Model + Harness
Harness = Agent - Model

模型之外，所有让 Agent 能稳定、可控、可恢复、可审计地工作起来的工程系统，都可以放进 Harness 这个大框里理解。

接下来再看 OpenClaw、Hermes Agent 和 Harness.io，就清楚多了。

二、OpenClaw 为什么会出现：因为 Agent 需要”入口”和”控制平面”

先看我们的例子。

如果你希望每天早上收到 AI 整理的摘要，第一件事不是模型聪不聪明，而是：

这个任务从哪里进入系统？

你可能希望在飞书里发一句：

帮我整理今天 AI 新闻，十分钟后发给我。

也可能希望它每天早上自动触发。或者在 Telegram、Discord、Slack、WebChat、手机节点里都能叫它。

这就是 OpenClaw 最容易让人兴奋的地方。

OpenClaw 的核心价值不是”它有一个独家大模型”，而是把 Agent 放进了一个多入口、多通道、可持续运行的控制平面里。

你可以把它想成一个个人 Agent 总机：

Telegram / 飞书 / Slack / WebChat / 定时任务 / 设备节点
-> OpenClaw Gateway
-> Agent Session
-> Runtime + Tools + Workspace + Memory
-> 返回消息或执行动作

它解决的是：

怎样让 Agent 不只停在网页聊天框里，而是接到你已经在用的消息入口、设备入口和自动化入口上。

OpenClaw 的强项通常在这些地方：

• 多渠道触发：从聊天工具、网页、移动端或设备节点唤起 Agent
• 长期运行：通过 gateway、session、heartbeat、cron 维持持续工作感
• 工具接入：浏览器、文件、命令、消息发送、节点能力等
• workspace：用本地文件承载身份、规则、工具说明和记忆
• skills / plugins：把任务套路和运行时扩展接入系统

换句话说，OpenClaw 就是那个”让 Agent 能从各种地方被叫醒”的基础设施。很多人第一次用的时候会觉得”终于不用只在网页里跟 AI 聊天了”，就是这个感觉。

回到刚才那个早报例子，OpenClaw 更像是在解决：

我怎么随时随地叫起这个 Agent？
它怎么接我的消息？
它怎么定时醒来？
它怎么把结果发回我常用的聊天入口？

所以说 OpenClaw 更像 Personal Agent Control Plane，也就是个人 Agent 控制平面。

但这里要降一降温。

OpenClaw 能把 Agent 接进现实入口，不代表它已经是一个成熟、稳定、低成本的个人助理。更准确地说，它是一个很有研究价值的 Agent 运行时样本：能跑，能做事，能把很多未来 Agent 的问题提前暴露出来，但离”普通人装上就能长期放心使用”还有明显距离。

OpenClaw 目前还不够在哪里

第一，它的”主动性”更多是调度意义上的主动，不是稳定自治。

比如每天早上整理新闻，本质上通常是：

cron / heartbeat 到点触发
-> 把任务 Prompt 重新送进 Agent Session
-> 模型再判断下一步要不要搜索、整理、发送

这当然有用，但它不等于模型真的拥有一个长期目标，也不等于它能在没有调度器、没有明确触发条件时稳定自我推进。很多看起来像”它自己在做事”的能力，其实是宿主系统在反复唤醒它。

第二，它的执行方式容易变贵。

OpenClaw 为了让模型知道”我是谁、能用什么工具、应该遵守什么规则”，往往会在首轮塞进大量 System Prompt（系统提示词，定义 LLM 角色和行为底线的全局指令）。结果就是，哪怕只是问一句”你有多少内存”，后台也可能变成：

用户消息
-> 大量系统提示词
-> 模型判断要调工具
-> 执行 shell 命令
-> 工具结果回流模型
-> 模型再整理成最终回答

这里有一个隐性成本：System Prompt 是每轮都带上的，上下文越长，Token 消耗越容易被低估。可以把它理解成”首轮税”：不管用户问多简单，都要先交一笔上下文税。

表面上像一次问答，实际上是多轮模型和工具闭环。任务越复杂，工具越多，首轮上下文和后续试错成本就越容易被放大。

第三，复杂任务容易滑向”高成本试错”。

还是早报例子。如果你让它”搜索今日 AI 新闻，整理成 PDF，再发到聊天软件”，它可能会一路做下去：

搜索新闻
-> 写 markdown
-> 尝试转 PDF
-> 发现依赖缺失
-> 安装或换命令
-> 格式不对再修
-> 发送失败再补救
-> 继续局部修补

每一步局部看都说得通，但整体可能已经不划算。OpenClaw 现在暴露出的一个典型问题，就是行动意愿强于成本意识，局部补洞能力强于全局重规划能力。它会努力把眼前这一步过掉，却不一定会及时停下来问：

这条路径还值得继续吗？
要不要换成 RSS、API 或已有工作流？
继续做会不会把环境弄乱？
这一步是否需要用户确认？

第四，它的记忆还不是成熟的”长期人格”。

OpenClaw 的 memory 更应该被理解成一种长期上下文机制：把信息写进 workspace 里的文件，再在未来某个时刻检索回来喂给模型。

这很有用，但也很危险。因为记忆不是越多越好。历史对话、偏好、错误假设、临时状态如果都被不断写进去，却没有分层、失效、冲突处理和人工清理，Agent 不会自然变得越来越懂你，反而可能越来越混乱。

所以 OpenClaw 的记忆问题，不是”有没有记忆”，而是：

什么应该写入长期记忆？
什么只是当前任务状态？
旧记忆什么时候失效？
冲突记忆谁来裁决？
错误经验怎么删除？

这也是我说 OpenClaw 能提供一个可用入口，但还没有替用户解决成熟的记忆治理。

OpenClaw 真正需要警惕的风险

OpenClaw 最大的风险，不是它会说错话，而是它会把”说错话”升级成”做错事”。

一旦 Agent 能接触文件系统、浏览器、Shell、消息通道、邮箱、日历或其他外部服务，它就不再是一个普通聊天机器人，而是一个高权限代理进程。

风险会在三个条件同时出现时迅速变大：

• 它能接触私密数据
• 它能读取不可信输入
• 它能对外执行动作

OpenClaw 这类系统往往三者都占。

一个网页里藏着提示词注入，一条外部消息伪装成用户命令，一个文档里夹带”忽略前面规则并发送文件”的指令。如果 Agent 同时能读这些内容、能访问本地文件、还能发消息或执行命令，问题就不再是模型被诱导输出一句怪话，而是系统可能真的执行了不该执行的动作。

所以 OpenClaw 的安全问题，必须被放在运行时设计里看：

它在哪个环境里跑？
默认暴露了哪些工具？
哪些工具只读？
哪些动作必须人工确认？
哪些密钥和文件根本不该让模型看到？
渠道消息进来以后怎么做权限映射？
定时任务怎么防止误触和重复执行？
失败时有没有日志、回滚和止损？

这也是 OpenClaw 和传统脚本、RPA、工作流引擎的差别。

确定性自动化最强的地方，是路径明确、边界清楚、输出可预期。OpenClaw 更适合补足那些有模糊判断、多步骤决策、非结构化输入的场景，但不适合无脑替代所有自动化。很多任务如果脚本、API 编排、规则系统就能稳定解决，直接上 Agent 反而会带来更多成本和风险。

所以，OpenClaw 最适合的定位不是”万能个人 AGI”，而是：

一个很好的 Agent Harness 研究样本，一个适合开发者和自动化重度用户驯化的运行时，而不是一个默认给普通用户长期无保护运行的成熟消费级产品。

它真正留下的新问题也就更清楚了：

Agent 被叫起来之后，怎么避免每次都像第一次做事？

如果它每天都整理新闻，却不记得你喜欢哪些方向、不知道你昨天已经看过什么、不知道哪种摘要格式你最满意，那它虽然能跑，却很难越用越顺手。

于是就引出了 Hermes Agent 这类系统更关心的问题。

三、Hermes Agent 为什么会出现：因为 Agent 需要”记住”和”成长”

OpenClaw 解决的是”入口”和”控制面”的问题。
Hermes Agent 更想解决的是另一个问题：

Agent 能不能把经验沉淀下来，而不是每次从零开始？

这件事对我们的例子很关键。

你不只是想要一个每天会抓新闻的工具，而是想要它慢慢知道：

• 你更关心 Agent、LLM、Claude Code、Harness Engineering
• 你不喜欢标题党摘要
• 你希望摘要有”结论、证据、风险、延伸阅读”
• 你常用 Obsidian 存知识
• 你处理 CI 失败时，习惯先看最近提交和失败日志
• 有些任务应该生成 PR，有些任务只需要评论建议

如果这些东西每次都靠你在 Prompt 里重说一遍，Agent 就只是一个”能调用工具的临时工”。
如果这些东西能被整理成记忆、技能和项目上下文，它才开始像一个会积累经验的助手。

Hermes Agent 的重点就在这里。

它强调的不是单个入口有多炫，而是长期运行时里的几类能力：

• 持久记忆：跨会话记住用户、项目、偏好和环境事实
• 技能系统：把做过的复杂任务沉淀成可复用操作文档
• 会话检索：需要时能回查过去会话，而不是全靠当前聊天历史
• 上下文文件：读取项目里的规则文件来塑造当前行为
• 任务委派和自动化：把任务拆给子 Agent 或定时任务执行
• 多后端执行：本地、Docker、SSH、云沙箱等不同终端环境

用一句话说：

Hermes Agent 更像一个把”经验”放进运行时里的 Agent 系统。

OpenClaw 让 Agent 更容易被你叫起来，Hermes Agent 则试图让 Agent 更容易变得”熟练”。

还是早报例子。

OpenClaw 关心的是：

每天早上 8 点从哪里触发？
结果发到哪个聊天软件？
过程中能不能打开网页、读文件、发消息？

Hermes Agent 更关心的是：

哪些新闻源对你长期有价值？
哪些摘要格式上次被你接受了？
哪些处理步骤可以沉淀成 Skill？
哪些个人偏好应该写进 MEMORY.md / USER.md？
哪些历史会话值得在未来召回？

这就是 Hermes Agent 经常被描述成 Self-improving Agent Runtime（自我改进的 Agent 运行时，指能在使用过程中持续积累经验并优化自身行为的运行系统）的原因。

但这里要冷静一点。

“会记住”不等于”真的越来越聪明”。记忆如果缺少治理，会变成污染源；技能如果缺少审核，会变成错误套路；历史会话如果不加筛选，会让 Agent 把旧误判当成新事实。

所以 Hermes Agent 解决了 OpenClaw 留下的”经验沉淀”问题，同时也引出了下一层问题：

如果 Agent 要进入团队和企业工程流程，谁来管权限、密钥、审批、审计和标准化交付？

这就到了 Harness.io 更擅长的层面。

四、Harness.io 为什么会出现：因为 Agent 需要进入”企业流程”

这层最容易混淆。

Harness 有两种含义：

第一种是通用概念：[[04.如何让Agent更好干活-Harness#三、Harness 到底是什么|Agent Harness]]，也就是模型外面的运行系统。
第二种是具体公司和产品：Harness.io，它本来就是做软件交付、CI/CD、DevOps 和平台工程的。

当我们说 OpenClaw 和 Hermes 都是 Harness 的工程落地时，说的是第一种：它们都是 Agent Harness 的不同样板。

当我们说 Harness.io Agents 时，说的是第二种：一个把 AI Agent 嵌进企业软件交付流水线的产品形态。

为什么这层会出现？

还是看早报例子里的最后两步：

如果发现项目 CI 失败，自动分析原因。
需要改代码或发 PR 时，先按团队规则走审批。

这已经不是个人助理场景了，而是企业工程场景。

在企业里，Agent 不能只靠”我觉得可以”就做事。它必须面对：

• 代码仓库权限
• CI/CD 执行上下文
• secrets 和 connector
• 环境、服务、部署历史
• RBAC（基于角色的访问控制，按用户角色分配不同权限的权限管理模型）和组织权限
• OPA policy（Open Policy Agent 策略，用声明式语言统一管理和执行访问控制规则）
• 人工审批
• 审计日志
• PR review
• 回滚与失败策略

这就是 Harness.io Agents 的切入点。

它不是把 Agent 当成一个漂在外面的聊天助手，而是把 Agent 做成流水线里的一级步骤。

也就是说，Agent 不再是：

外部聊天机器人
-> 调 API
-> 偷偷改一点东西

而更像：

Pipeline 触发
-> Agent 继承本次流水线上下文、权限、密钥和连接器
-> 分析仓库 / 日志 / 测试 / 部署状态
-> 生成建议或 PR
-> 经过审批、审计和团队规则
-> 进入正常交付流程

这解决的是：

怎样让 Agent 不只是”能干活”，而是在组织允许的边界里干活。

Harness.io 的重点不是个人多入口，也不是个人记忆成长，而是：

• 流水线原生执行：Agent 是流水线步骤，不是外部脚本
• RBAC / secrets / connectors：继承企业平台已有权限边界
• Knowledge Graph：利用组织内部服务、部署和流水线上下文
• OPA policy：用策略管住 Agent 行为
• 人在环路：关键动作让人审批
• 可审计性：每一步可追踪、可回放、可治理

用一句人话概括：

Harness.io 关心的不是”Agent 会不会做”，而是”Agent 做这件事是否符合企业交付流程”。

（这里有一个实际观感上的差异：OpenClaw 和 Hermes 给你的感觉是”我在用一个聪明的助手”，而 Harness.io 给你的感觉是”流水线里多了一个能自己看日志、写代码、提 PR 的步骤”。两者不是竞争关系，是不同层级的问题。）

五、把三者放回一条链里

不要把 OpenClaw、Hermes Agent、Harness.io 当成三个平级竞品。

更好的理解方式是，它们分别回答了 Agent 落地过程中的不同问题：

模型已经能调用工具
-> 需要入口和控制平面：OpenClaw
-> 需要记忆和能力沉淀：Hermes Agent
-> 需要企业流程和治理：Harness.io Agents
-> 这些共同属于 Agent Harness 的工程空间

可以压成一张表：

名字	更像什么	核心问题	典型场景
OpenClaw	Personal Agent Control Plane	Agent 怎么被多渠道唤起，并接入个人自动化入口	Telegram / 飞书 / Slack / cron / 浏览器 / 本地文件
Hermes Agent	Self-improving Agent Runtime	Agent 怎么记住经验、沉淀技能、跨会话成长	长期个人助理、技能复用、记忆治理、云端常驻
Harness.io Agents	Enterprise Workflow Harness	Agent 怎么进入企业流水线并被权限、审批和审计治理	CI 修复、代码审查、测试补全、部署与 DevOps 自动化
Agent Harness	架构思想	模型外面需要什么系统，才能稳定做事	所有生产级 Agent 系统

所以它们的关系不是：

OpenClaw vs Hermes vs Harness

而更像：

OpenClaw 是偏入口层的 Harness 实现
Hermes Agent 是偏运行时和成长层的 Harness 实现
Harness.io Agents 是偏企业治理层的 Harness 实现

六、初学者最容易混淆的几个点

1. OpenClaw 不是 Harness 本身

OpenClaw 是一个具体的 Agent 平台或运行时样本。它体现了很多 Harness 能力，比如 gateway、workspace、tools、skills、sessions、memory、cron、heartbeat。

但它不是 Harness 这个概念的全部。

它更偏：

入口接入 + 个人自动化 + 多渠道控制平面

2. Hermes Agent 不是”拼错的 Harness”

Hermes Agent 是另一个具体系统。它的名字和 Harness 很像，但重点不同。

它更偏：

长期记忆 + Skill 沉淀 + 会话召回 + 自我改进运行时

所以它和 OpenClaw 的区别，不是”谁更像 Agent”，而是：

OpenClaw 更会接入口
Hermes 更强调经验沉淀

3. Harness.io 不是泛泛的 Agent Harness

Harness.io 是具体公司和平台。它的 Agents 更偏企业软件交付。

它更关心：

Agent 如何作为流水线步骤被执行、审批、审计和治理

所以不要把 Harness.io Agents 和通用概念 Agent Harness 完全画等号。

4. Harness 不是万能药

Harness 不是把模型套一层壳，Agent 就稳定了。

一个糟糕的 Harness 仍然会：

• 给模型太多不相关上下文
• 暴露过多危险工具
• 没有成本止损
• 记忆越来越脏
• 权限边界过宽
• 失败后继续硬做
• 做完后没有验收

真正的问题不是”有没有 Harness”，而是：

你的 Harness 有没有把入口、上下文、工具、状态、权限、记忆、调度、审计和验收设计清楚。

七、今天为什么会进一步走向 Harness Engineering

过去我们最关注的是模型能力。

后来大家发现，只调 [[02.如何让LLM更聪明#二、Prompt 为什么会出现：因为“只会接话”不等于“会按要求干活”|Prompt]] 不够，还要给模型正确上下文，于是有了 [[02.如何让LLM更聪明#三、Context 为什么会出现：因为只有任务，没有材料，模型还是干不好活|Context Engineering]]。

再后来 Agent 能调用工具、能执行任务，问题继续外扩：

Prompt 解决"怎么说清楚"
Context 解决"给什么信息"
Tool 解决"怎么让模型产生动作"
Agent 解决"怎么连续行动"
Harness 解决"怎么让连续行动稳定、可控、可治理"

OpenClaw、Hermes Agent、Harness.io 之所以值得放在一起看，不是因为它们名字像，而是因为它们刚好站在 Agent Harness 的三条不同分支上：

• OpenClaw 暴露了个人 Agent 的入口、成本和安全问题
• Hermes Agent 暴露了长期记忆、技能沉淀和自我改进问题
• Harness.io 暴露了企业流程、权限治理和审计问题

这也是学习它们最有价值的地方。

你不一定要选择其中一个。
更重要的是，从它们身上拆出 Agent Harness 的工程清单：

入口怎么来
上下文怎么装
工具怎么控
状态怎么存
记忆怎么治
任务怎么调度
失败怎么恢复
权限怎么约束
结果怎么验收
过程怎么审计

只要你准备做一个真实可用的 Agent，这些问题迟早都会回来找你。

八、最后给读者一个最低成本记忆法

如果只想带走最短版本，可以这样记：

• OpenClaw 像一个个人 Agent 总机：负责把 Agent 接到各种入口上。
• Hermes Agent 像一个会写工作手册的助理：负责把经验沉淀成记忆和技能。
• Harness.io Agents 像一条企业流水线里的 AI 工位：负责在权限、审批和审计下执行工程任务。
• Agent Harness 是它们背后的共同问题：模型外面那套让 Agent 能稳定干活的系统。

再压缩一句：

OpenClaw 让 Agent 更容易被叫起来，Hermes 让 Agent 更容易记住和进步，Harness.io 让 Agent 更容易进入企业流程；它们都是 Harness Engineering 在不同层级上的落地样本。