OpenClaw与Hermes架构全面对比：自进化、记忆与安全设计深度解析

May 2, 2026

2026 年开年以来，AI 领域迎来两波巨大福利：

第一是 OpenClaw 的爆发，并非因为它直接解决了多少深层问题，而是它首先为 Agent 的普及做出了空前贡献；同时，OpenClaw 基本奠定了由 Agent 驱动 Skills 的基础交付范式。

第二是 Claude Code 源码的泄露，这为许多正在 Agent 赛道上创业的团队提供了大量高质量范本。在 CC 之前，大家对“Harness 驾驭工程”的理解仍是模糊的。

不过，前景虽好，现实依然存在不少问题。根据我的观察与实践：目前 Agent 技术远未成熟，OpenClaw 在执行任务的稳定性与安全性上仍有巨大的提升空间。

因此，后续必然会有越来越多的 Agent 涌现，每次迭代都能前进一小步，比如最近逆势而上的“Hermes”：

Hermes Agent 从 2 月底开源首月即破 2.2 万星，至 4 月 8 日发布 v0.8.0 版本后，单日新增 6400+ 星，不到两个月 GitHub 总星标突破 4.7 万，多日占据全球开源榜首。

OpenClaw VS Hermes

近来常听到“OpenClaw 已死，Hermes 称王”“Hermes 碾压 OpenClaw”之类的言论，说实话，听得有些烦，虽然我自己偶尔也会使用类似标题……

这个 Hermes 到底是个什么东西，又凭什么能与 OpenClaw 一较高下？我们这里还是要回归本质，尽量从工程角度（少量源码切入），为大家展开论述。

首先，OpenClaw 是一个用 TypeScript 编写的 AI 助手平台，工程化程度相当高。我之前写过几篇拆解文章，在本篇开头有链接，可以回顾查看。

Hermes Agent 则由 Nous Research 团队开发，使用 Python 编写，是一套可开源商用的 Agent 平台：

Hermes Agent 的设计理念是什么，与 OpenClaw 最本质的区别又在何处？这是我们今天讨论的重点。

在具体展开之前，市面上已有不少类似的拆解文章，鼓吹 Hermes 若干惊艳特性，因此我需要大家带着以下问题展开阅读：

学习闭环：Hermes 通过三层提示引导 Agent 自主提取技能，这套方案真的可靠吗？
记忆系统：三层记忆 vs 单插件槽位，Hermes 与 OpenClaw 在设计深度上有何差异？
安全 vs 成长：智能审批还是默认安全？两种设计哲学你该站在哪一边？

Hermes整体架构

Hermes 的架构可划分为四层：

核心设计理念是：闭环学习

经验 → 技能 → 改进 → 知识持久化

读过我此前文章的同学，对这个架构图一定会感到熟悉。该设计与 OpenClaw 相似，均采用分层架构，网关、Agent 核心、工具层、执行环境一应俱全：

OpenClaw 五层架构

只不过每个模块的设计出发点有所差异，先看这一张对比表：

维度	Hermes Agent	OpenClaw
核心问题	Agent 如何才能越来越强大？	如何让 Agent 安全可靠地执行任务？
语言	Python	TypeScript
技能/插件	Agent 自行创建 Markdown 技能文件	Plugin SDK，manifest-first，严格边界
记忆系统	三层：内置 + 外部提供商 + 会话搜索	单插件槽位，可替换
上下文压缩	压中间，保护两端，迭代摘要	压缩最旧轮次，保留最近，归档原始数据
安全模型	智能审批（辅助模型判断风险）	10+ 安全模块，默认安全
执行环境	6 种后端（含无服务器）	3 种后端（偏安全沙箱）
国内平台	飞书/钉钉/企业微信/微信原生支持	飞书/QQ 扩展支持
研究能力	内置 RL 训练工具链	纯产品，无训练能力

建立整体印象之后，我们进入细节，首先看最核心的差异点：学习闭环

学习闭环

Hermes 与 OpenClaw 的差异几乎都衍生自“学习闭环”这一核心理念。

OpenClaw 回答的核心命题是：如何让 Agent 安全可靠地执行任务。

因此我们看到它的设计包含多层审批、安全审计、沙箱隔离以及严格的插件边界。

而 Hermes 试图解答的主题则是：Agent 怎样才能变得越来越强大？

目的不同，架构设计的方向自然就会出现细微区别。最初我比较倾向 OpenClaw，因为安全与稳定才是上生产的必要条件。从这个角度看它的安全机制，十多个安全审计模块、危险工具白名单、沙箱隔离等，意义就非常大，完全是工程实践的沉淀。

只是普通用户可能很难感知到安全问题，对此也并不敏感。OpenClaw 虽然做了许多策略，但并没有太多人会将它用于执行严肃的高风险任务，这就造成了一种结果：

我们这些在一线从事 AI Agent 工作的人，可以深刻体会 AI 带来的不确定性，甚至会遭遇删除文件、丢失数据这类窘境。但从学习的角度来说，这部分又显得有些多余，毕竟现在的 OpenClaw 更多还是处在自娱自乐的阶段。

再看 Hermes，既然现阶段的定位仍是范式探索，而非完全面向生产的架构，那么自进化、越用越强就是一个极具吸引力的特性。

例如 Hermes Agent 的 skill loop 这段源码，其整体设计思路就非常有意思，极富借鉴价值。它的核心思路是一个闭环：

核心代码分布在 agent/skill_utils.py、skill_manager_tool.py、prompt_builder.py 这几个函数中。

我原本以为这个“自我进化”是依靠某种自动化流水线，比如 cron job 定时触发 + skill extraction 脚本。

这里先解释一下什么是自进化：

所谓自进化

对于 AI 应用来说，所谓的自进化，其实与数据飞轮的策略非常类似。如果是 AI 客服类项目，传统做法是：

先把用户问题、客服回复、最终是否解决这些数据沉淀下来；
再从这些数据中筛选高质量问答、失败案例、争议案例；
然后由人工或系统对这些内容进行整理、归类、清洗；
最后再回灌到知识库、意图库，推动下一轮回答效果提升；

这是一个非常典型的闭环：

交互数据积累 → 经验提炼 → 知识沉淀 → 下一轮效果提升

所以大家才会频繁提到数据飞轮，因为它描述了系统因数据回流而逐步增强的过程。AI 知识库其实就是最早、也是最常见的一种自进化形态。

这里处理的大多是边界数据、错误数据，回填的是知识库，系统架构本身并没有变化，但由于知识库越来越强，整体系统表现也就越来越好。

从这一点回顾 Agent/Hermes 架构，同样，基础的架构一定不会改变，而 Agent 不会直接涉及原始数据，那么能变化的就只有工作方法，也就是我们常说的工作流。根据之前 OpenClaw 的启示，现阶段 Agent 用以承载 Workflow 的模块就是 Skills。

综上，Agent 的自进化是围绕每一个 skill 展开的。

接下来再说我们之前做自进化的策略：

我们的 Agent 自进化策略

如前所述，从工程上看，所谓 Agent 的自进化，本质上就是把一次次任务执行中产生的经验重新回收，再沉淀成新的 Skill、规则或工作方法。

既然是经验回收，最贴合传统工程习惯的实现方式，往往就不是让 Agent 在主链路里自己边做边判断，而是单独拉出一条后台流水线。

这条流水线大概会长这样：

任务执行完成 → 记录执行轨迹 → 筛选成功/失败案例 → 提取可复用模式 → 生成或更新 Skill 文件 → 下次任务继续使用

再具体解释一下，那就是：

前台 Agent 负责完成任务；
后台系统负责收集日志、调用链、报错信息和成功路径；
再由独立的模块去分析这些轨迹；
最后把总结结果写回技能库、经验库或者某种规则文件；

这是一种很典型的设计，也是很多 AI 应用更常见的做法。

所以我一开始才会觉得，Hermes 背后应该也有一条类似的自动化学习流水线。但看过代码之后，发现似乎并非如此：

Hermes 的自进化策略

Hermes 的技能提取没有一行硬编码的自动触发逻辑，它在三个地方编写了提示词，引导 Agent 自己判断要不要把这个经验存储下来：

举个例子，我在日常开发 Agent 的时候，经常遇到某个问题：模型在使用技能（我们已经编排好的技能）时，尤其是在多次执行过程中，有可能会在同一个地方反复报错。

我的解决方法是将报错行为和成功的经验写入模型能够看到的知识库中，我并没有让它去修改技能的原始内容，主要是怕它乱改！！知识库的经验总结之后，我再去手动修改技能说明……

这个动作是不是“多此一举”，在于你对 AI 的信任程度。其中知识库类似这种：

## 知识库文件  
你的知识库文件路径为：`{knowledge_path}`  
当你需要保存经验、用户偏好、学习到的知识时，请使用 `file_write` 工具写入该文件  
该文件的内容会在每次对话时自动加载到你的系统提示中。

再回归 Hermes，它的三层提示词分工非常清晰：

第一层告诉 Agent 什么时候该创建技能。
第二层列出了五条创建条件和三条更新条件。
第三层在 Agent 使用技能时督促它持续改进，没有硬编码的自动提取逻辑，完全靠提示词引导。

于是真正的问题和先前的差异就出现了：完全依赖 prompt 是否靠谱，会不会跑偏？

这个答案几乎是肯定的：

肯定不会每一次都正确，大概率会有跑偏的时候。

但这套机制的设计者显然认为：大模型的指令跟随能力已经足够强（即便现在不够强，未来肯定能满足），能够准确识别何时新增技能、何时更新技能。

综上，从这里其实也能说清楚 Hermes 的定位：

更适合做稳定性要求不高的任务

因为这东西从架构设计上追求的是更灵活，而非更稳定

举一个实际的例子：你让 Agent 帮你做一期小红书内容运营。

它先搜索当下热门话题，发现某个美妆趋势正在爆发；接着根据这个热点生成配图，再分别写出小红书笔记和公众号长文，排版、标签、封面建议一条龙服务。

前后调用了搜索、图片生成、内容撰写等多个工具，超过 5 次工具调用，满足硬性指标，完成后它把这套流程提取成技能文件：

---  
name:hot-topic-content-creation  
description:"热点追踪与多平台内容创作技能"  
conditions:  
platforms:[macos,linux,windows]  
---  
# 热点内容创作流程  
## 步骤  
1.搜索当前平台热门话题/趋势，筛选与自己领域相关的话题  
2.分析热点关键词，确定内容切入角度  
3.根据话题生成配图（封面图+内文插图）  
4.撰写小红书笔记：标题党+口语化正文+话题标签  
5.基于同一话题改写为公众号长文：深度分析+观点输出  
6.生成发布建议（最佳时间、标签组合、互动话术）  
...

这个文件主要是写给 Agent 看的，但我们可以随时查看技能详情，也可以自定义修改。人和 Agent 都能阅读，下次再遇到类似任务，直接调用这个技能，无需从头推理，整体感觉相当不错。

这里小结一下：

Hermes 具备一种能力：在执行一个复杂任务成功后，可以将它沉淀为 skill

至于 Hermes 何时会沉淀 skill，它遵循一个基本倾向策略：

成功完成了一个复杂任务，尤其是工具调用较多的场景，例如官方文档提及的 5+ tool calls。
中途遇到错误或死路，但最终找到了可行路径。
用户纠正了它的做法，即外部反馈明确告诉它：原来的方法不对，新的方法更好。
它识别出了一个 non-trivial workflow，也就是可能常用、可复用、多步骤的方法链，这正好匹配 skill 的定义。

不过我读到这里也产生了一个疑问：如果不断让 Hermes 做事，技能会不会越来越多？多了之后，system prompt 里塞满一堆技能索引，模型还能准确判断该用哪个吗？

从源码来看，Hermes 采用了渐进式披露，skills_list 只返回名称和描述，不会一股脑全部塞入。

个人用户的技能数量大概率也就几十个，基本覆盖了个人工作和生活的场景，模型仍然可以准确地识别。

真正出问题会在团队使用场景，当技能累积到几百个时，可能需要更智能的技能检索机制，单纯把技能索引塞进 system prompt 里，模型的判断就不一定准确，混用、乱用的情况就会浮现。

记忆系统

在记忆这块，两个项目也存在较大差异：

OpenClaw 把记忆当作一个 特殊插件。也就是说，记忆在其体系里并不是某种不可替换的核心模块，而是被统一纳入插件机制管理。

这种做法的好处非常明显：实现简洁、边界清晰、可替换性强。

可以说，OpenClaw 从未认为自己的记忆系统一定适合所有团队，因此做了一个最简实现，它期待我们用自己的插件去替换，所以 OpenClaw 这块做得就很轻量：

它同一时间只激活一个记忆插件，这也意味着系统对记忆来源、记忆读写、记忆注入方式都有较强的约束，不容易失控。

只不过，可控的另一面就是缺乏灵活性，这也是 OpenClaw 设计之初的考量：它更关注记忆这件事如何接入系统，从而不破坏整体稳定性。

至于Agent 怎么靠记忆越来越像人，这个权限或者说能力，平台交付给了我们。

Hermes Agent 则将记忆分为三个部分：

内置记忆

这一块设计得非常简单，就两个文件：

MEMORY.md：更多是 Agent 自己用的，记录一些环境信息、项目里的约定，还有踩过的坑
USER.md：专门存放用户画像，比如偏好、沟通习惯等

这个设计本来很简单，但有一个细节需要注意：系统提示词中拿到的记忆，并不是实时的，而是会话启动那一刻的一个快照。

也就是说：你在当前对话里往 MEMORY.md 写了新内容，这些东西确实会立刻落盘，但模型当前对话中是看不到的。

只有等到下一次重新开启一个新会话，这些新记忆才会被带入系统提示词。

这个设计应该是为了更好地利用缓存，降低推理成本，而且这两个文件本不该频繁改动，所以有一点延迟也还可以接受。

另外，在写入记忆时会做一轮安全扫描，比如提示注入、不可见 Unicode 字符等，一旦命中规则就直接拒绝写入。

两个文件还有容量限制：

MEMORY.md：2200 字符
USER.md：1375 字符

超过这个上限就不能再写了，实际使用时需要稍微注意，否则很容易写着写着就失败了。这里给一个简单案例，感受一下：

# MEMORY  
## 环境信息  
- 当前主要工作：AI Agent 相关文章写作与分析  
- 常用平台：公众号、小红书  
- 默认输出语言：中文  
  
## 项目约定  
- 写文章时，优先讲清楚架构和设计思路  
- 涉及 Agent 时，重点关注 Skills、记忆、工作流  
- 不要自动改原始技能文件，先记录经验，再人工确认  
  
## 经验记录  
- 做复杂任务时，容易在中间某一步反复报错  
- 同样的错误如果连续出现，应该记录下来，避免下次再犯  
- 成功经验可以先写进知识库，后面再决定要不要改 Skill

# USER  
## 用户偏好  
- 喜欢中文回答  
- 喜欢偏工程化、结构清楚的分析  
- 不喜欢太空、太虚的表述  
  
## 沟通习惯  
- 喜欢先讲结论，再讲原因  
- 喜欢文章里有自然的过渡段  
- 喜欢用真实场景举例  
  
## 内容风格  
- 更关注架构差异，而不只是功能罗列  
- 喜欢比较不同系统背后的设计哲学  
- 希望内容可以直接拿去改成公众号文章

外部记忆

除了本地这套，还有一层是通过 MemoryProvider 做的抽象，就是把记忆能力外包出去，现在一共接了八种不同的实现：

| 提供商 | 特点 |  
|--------|------|  
| Honcho | 更偏用户建模，会一点点把用户画像“养”出来 |  
| Hindsight | 专注会话记忆，适合做跨会话上下文衔接 |  
| Mem0 | 走向量检索这一套，按语义查找历史记录 |  
| Byterover | 偏代码场景，适合存储编程相关上下文 |  
| Holographic | 做多维关联，类似于关系网式的记忆 |  
| OpenViking | 一个开源实现，比较偏基础能力 |  
| RetainDB | 基于数据库做持久化，思路比较传统 |  
| Supermemory | 主打跨平台整合，什么都能往里收 |

Hermes 这一层的设计与 OpenClaw 有一点相似：希望通过可插拔的方式，将不同实现接驳进来。

至于为什么这样设计，这里举个例子：假如你最初做的是内容创作 Agent，最需要的是记住用户的风格和偏好，那你可能更偏向于接入一个擅长用户建模的 provider。

但后来你把这个 Agent 拓展到代码场景，开始帮人修 bug、记项目约定，这时候原来的记忆后端可能就不够用了，你会更想换成一个更适合代码上下文的 provider。

Hermes 官方文档也明确将外部记忆能力区分为用户建模、语义搜索、知识图谱、跨会话记忆等不同方向。

从这里大家想必也会有比较直观的感受：Hermes 这波用户依然更偏向 2C/个人/小团队。

就现阶段它的记忆和 skill 组织方式而言，更像是在做一个陪伴 Agent。官方对此也有提及，当前 Hermes 的特点是“更懂你”。

可以说这相当聪明，这与当前 Agent 不稳定/灵活的特性有关，团队协作确实还不适宜，所以做得越灵活，个人尤其是小白就越喜欢用，因为他们定然会感觉Hermes 似乎比 OpenClaw 更聪明。

会话搜索

Hermes 不会在每一轮中都把历史对话直接塞进上下文。

而是提供了一个工具 session_search，让模型在推理过程中按需去查询历史，流程如下：

先用 FTS5（SQLite 的全文搜索引擎）在历史对话里找到匹配的消息，按相关性排序。  

然后把匹配到的消息按会话分组，取前几个会话；  
每个会话加载完整对话记录，截取匹配点前后约 10 万字符；  

最后把这些内容丢给一个便宜的辅助模型做摘要，返回的是针对搜索关键词的会话摘要，而不是原始对话。

这与 OpenClaw 的思路就不一样。OpenClaw 搜到什么就直接丢给主模型，让模型自己去判断哪些有用。

Hermes 在中间加了一层 LLM，先把信息压缩、过滤一遍，再注入当前上下文。

这样做的好处是上下文更干净，噪音更少；代价则是多了一次模型调用，以及一点延迟，而且大模型处理的效果，逻辑上会更好，所以孰优孰劣，难以下绝对定论。

所有类似这种设计，都可以在算力和质量之间做取舍。更多的循环确认，结果自然会显得更聪明。

接下来，MemoryProvider 这一层实际上非常关键，它直接嵌入 Agent 推理循环里，参与的时机非常多：

class MemoryProvider(ABC):  
    def prefetch(self, query) -> str  
    def queue_prefetch(self, query) -> None  
    def sync_turn(self, user, assistant)  
    def on_turn_start(self, turn_number, message)  
    def on_pre_compress(self, messages) -> str  
    def on_delegation(self, task, result)  
    def on_memory_write(self, action, target, content)  
    def on_session_end(self, messages)

按执行阶段去看会更清晰一些。

在每一轮开始之前，它可以通过 prefetch 把相关记忆提前捞出来塞进上下文；

如果不想阻塞当前推理，可以走 queue_prefetch，异步去准备下一轮要用的东西。

到了对话进行中，像 sync_turn 这种，是在每一轮结束之后，把新的交互同步进去，相当于是持续在喂数据。

还有几个 hook：

on_pre_compress：在上下文压缩之前，先把关键信息摘取出来，避免被压缩算法误伤
on_delegation：子 Agent 执行完任务之后，可以观察学习
on_memory_write：当有记忆写入时，对外发出通知，方便接入外部系统

最后到会话结束，还有一个 on_session_end，用来做总结沉淀，这一步更像是在做长期记忆的整理。

整体看下来，这套设计在 Agent 的整个生命周期里，插入了一层可编排的记忆系统。

什么时候读、什么时候写、什么时候压缩、什么时候总结，全部可控。

这也是为什么它能同时对接那么多外部 MemoryProvider，因为接口本身就是围绕“推理过程”设计的，而非围绕“数据存储”。

最后，我们用一个简单的案例串联：

记忆案例

假设你长期把 Hermes 当成一个内容运营 + 文章写作助理来使用。

第一次对话

你对 Hermes 说：

我写文章喜欢先讲架构，再讲细节
我不希望你自动改原始 skill 文件
我现在主要做公众号和小红书内容

这时，Hermes 可能会把其中一部分内容写入：

***USER.md：***比如喜欢工程化表达、不喜欢太虚
***MEMORY.md：***比如当前主要工作是内容运营与文章分析、不要自动改原始 skill 文件

这两类内容属于**长期稳定、值得反复带入上下文的信息。**官方文档明确指出，USER.md 适合存偏好和沟通方式，MEMORY.md 适合存环境、约定、经验和已完成工作的摘要。

日常对话

接下来几天，你和 Hermes 聊了很多内容，比如：

某篇公众号文章怎么起标题
某次小红书内容怎么选题
某个 skill 在第 3 步总是出错
…

这些对话内容并不会全部塞进 MEMORY.md / USER.md，而是被放入对话数据库。

检索取出

某天你开了一个新会话：

上周我们不是聊过一个 
Agent 自进化和知识库数据飞轮 
的比喻吗？帮我找回来

此时 Hermes 当前 system prompt 里，只有会话启动时注入的 MEMORY.md / USER.md 快照。

于是它就会使用 session_search：

先在 SQLite 的 FTS5 索引里，按关键词寻找相关历史消息。
找到相关会话后，不是把原始长对话一股脑丢进来，而是返回针对这次查询的摘要。
然后主模型基于这个摘要继续回答你；

这里需要特别说明整个检索流程，上述问题可能会被拆解为以下关键词：

Agent 自进化
知识库
数据飞轮
比喻

然后通过 SQLite + FTS5 在历史消息里寻找包含这些词或相近表达的内容。搜出来的结果，可能不是只命中一条消息，而是一坨信息；

继而将这些信息交给辅助模型做判断，与问题一起提炼出相关的内容，例如最后返回类似下面这样的摘要：

你们当时讨论的核心比喻是：  
AI 知识库的自进化，本质上是把错误案例、边界案例、争议案例回流到知识层；  
Agent 的自进化，则是把任务执行中的成功路径、失败模式和可复用 workflow 回流到 Skills 层。  
前者沉淀的是答案，后者沉淀的是做事方法。  
所以两者都像数据飞轮，只是飞轮驱动的对象不同。

上下文压缩

长对话场景下，上下文窗口迟早会被塞满，压缩是不可避免的，关于压缩策略。

两个项目的核心思路其实相同，都是用 LLM 提取摘要，把关键信息留住，区别在于从哪儿开始压缩：

OpenClaw 的做法是从**最老的对话轮次（也就是头部）**开始压缩，最近的对话原样保留。

OpenClaw 压缩前会保留快照，原始消息归档到 archive 路径；OpenClaw 还做了一套缓存稳定性措施，比如确定性排序、空格规范化、cache boundary marker。

Hermes 的 ContextCompressor（在 agent/context_compressor.py 里）则是保护两端、压缩中间：

具体来说，system prompt + 最初几轮对话（head）和最近约 20K tokens 的对话（tail）都不动，中间的轮次用辅助模型生成结构化摘要。

跨多次压缩时采用迭代摘要，不是从头重写，而是在上一版摘要基础上增删改。摘要的前缀类似这样：

## 已解决的问题  
- [配置问题]: 已通过修改 ~/.hermes/config.yaml 解决  
- [依赖缺失]: 已 pip install 缺失包  
  
## 待决问题  
- [性能优化]: 当前方案是用缓存，还在评估其他方案

两种做法的差异在于：OpenClaw 从头压，Hermes 压中间。OpenClaw 额外保留了完整归档和快照，信息可回溯；

Hermes 的迭代摘要机制更注重跨多次压缩的信息连续性。

需要哪种压缩机制，取决于我们的任务场景：高频调用、成本敏感，选 OpenClaw；需要深度推理、信息不能丢，选 Hermes。

这里我没有什么倾向性，但看得出 Hermes 依然比较吸引用户，总而言之，他选择的结果，就是看起来要显得更聪明一些……

技能系统

两个项目在如何让 Agent 积累任务经验这件事上，路径完全不同。

OpenClaw 的 Skills 是预定义的任务流程描述，由开发者或用户手动编写，Skills 的定位是给 Agent 的操作手册，告诉 Agent 遇到某类任务该按什么步骤执行。

创建和更新都依赖人工维护，Agent 本身不会主动创建或改写 Skill。

值得一提的是：OpenClaw 的 Skills 库极其丰富！

Hermes Skills

Hermes 的 Skills 走的是另一个方向：Agent 自己就能写技能。

技能就是 Markdown 文件，放在 ~/.hermes/skills/ 下面，不需要编译、注册、审批。Agent 在推理过程中发现一个复杂问题的解法有价值，就直接写一个 Markdown 文件存下来。

上一节讲到的学习闭环，最终沉淀下来的产物就是这些 Skill 文件。

核心差异

维度	OpenClaw	Hermes
创建方式	人工/开发者编写	Agent 自动提取 + 人工可编辑
更新机制	人工维护	Agent 自主判断是否更新
存储形式	结构化定义	Markdown 文件
设计出发点	标准化、可控	自我进化、持续学习

简单说：OpenClaw 的 Skills 是人教 Agent 怎么做，Hermes 的 Skills 是Agent 自己总结怎么做，一个偏向指令执行，一个偏向经验沉淀。

社区生态方面，Hermes 的 optional-skills/ 目录下有 40+ 个社区技能包，分 13 个类别，从区块链到 MLOps、安全审计到 Blender 3D 建模。

技能分发平台名为 agentskills.io，走开放标准，OpenClaw 的 Skills 目前主要以官方和团队内部维护为主。

OpenClaw 的人工 Skills 在企业环境里更可控，Agent 照着标准流程走这件事本身就具有价值，能够直接封装企业的工作流。

Hermes 的自动提取技能保存，在个人使用和研究场景下更灵活，Agent 用得越多，积累的经验越多。

还是那个点，OpenClaw 这块肯定更稳定，但对于小白用户来说，他们搞不定那个生态，所以 Hermes 大概率对小白用户更为亲和。

执行环境

执行环境这一块，Hermes 给出的选择是比较多的，一共支持六种。

它的思路其实很直接：把执行环境当成一个可更改的后端能力。

比如 Daytona 这一类，是沙盒 + 生命周期管理，可以通过 stop / resume 来节省资源；

Modal 更偏按需启动，通过文件系统快照来保存状态，用的时候拉起来，不用就关掉。

底层实现上，所有执行环境都收敛到一个统一抽象：

class BaseEnvironment(ABC):  
    def execute(self, command, cwd, env) -> dict

如果需要切换执行环境，只需要修改配置即可。

对比来看，OpenClaw 在这块的思路就不太一样了，它是安全优先。把整套执行流程包了一层防护：

有多层审批机制（像 safe-bin、allowlist、执行审批这一套）  
自带一套隔离比较彻底的 Docker 沙箱（甚至包括浏览器环境）  
另外还有审计系统，在策略层面做限制

执行方式上，它支持：

本地  
Docker  
SSH 远程沙箱

整体是一个更偏向生产环境的设计。

所以这一块如果简单总结一下，其实就是两种取向：

Hermes：环境多、切换轻，适合快速试、灵活用
OpenClaw：限制多、边界清，适合需要安全兜底的场景

如果是个人项目或者原型验证，Hermes 会更顺手；但一旦涉及到企业环境，尤其是有安全合规要求的，OpenClaw 这一套会让人更放心一些。

只不过 OpenClaw 当然也远到不了生产环境的要求，这个阶段依旧是 Hermes 更吃香。

子 Agent

两个项目都支持将任务委派给子 Agent，它们在这块的设计原则是一致的：父 Agent 只需要结果，怎么干的不重要，上下文窗口本来就不够用，不该被细节塞满。

OpenClaw 用的是 ACP（Agent Client Protocol），有专门的服务端和客户端实现，偏标准化。sessions_spawn 工具默认在 HTTP 端口上被拒绝，需要显式启用，对委派操作的态度比较谨慎。

Hermes 把委派做成了一个内置工具（Delegate Tool），更直接：

几个设计要点：

子 Agent 是全新会话，不继承父 Agent 的历史对话  
工具黑名单：子 Agent 不能用 `delegate_task`（防递归）、`clarify`（不能与用户交互）、`memory`（不能写共享记忆）、`send_message`（不能产生跨平台副作用）、`execute_code`（应逐步推理而非写脚本执行）  
最大深度 2 层，每子 Agent 最多 50 次迭代  
父 Agent 只看到摘要，不看完整推理过程

严格来说，整个多 Agent 系统目前依旧不成熟，所以两个 Agent 系统都做得偏轻，或者说确实也用不着做得太深，当前把单 Agent 玩明白就已经很不错了。

安全

安全这块，两个项目的差距非常大，是所有模块中差距较显著的一个：

OpenClaw 的原则是“默认安全，高权限需显式声明”。有专门的 SECURITY.md 和漏洞响应流程，安全测试覆盖非常全面。

Hermes 走的则是另一条路：智能审批，同时也有危险命令检测，如 rm -rf、sudo、chmod 这些。

但是它在设计上多了一个机制：用便宜的辅助模型来判断命令风险级别，低风险自动通过，高风险才需要用户确认。

# 简化的智能审批逻辑  
def smart_approve(command) -> bool:  
    risk_level = cheap_model.evaluate(command)  
    if risk_level == "low":  
        return True   # 自动通过  
    else:  
        return ask_user(command)  # 需用户确认

Hermes Agent 在使用辅助模型做风险判断这件事上，本身就引入了一个新的信任问题：辅助模型如果判断不准怎么办？源码里我没有看到针对辅助模型判断的检查，这里就引入了一个安全隐患。

此外还有上下文注入防护，检测提示注入、不可见 Unicode 字符、凭证外泄等攻击模式……

国内生态

Hermes 在中国生态上优势相当大。

消息平台方面，飞书、钉钉、企业微信都有对应的 Gateway 插件（gateway/platforms/ 下的 feishu.py、dingtalk.py、wecom.py），开箱即用。

个人微信的接入值得单独一说，Hermes 通过腾讯官方的 iLink Bot API（weixin.py）实现了微信个人号机器人，不需要逆向协议或第三方框架：

这套 API 支持收发文本、图片、语音、视频、文件，还能发送“正在输入”状态。从 APP_ID = "bot" 和端点路径来看，应该是腾讯面向开发者提供的 Bot 接入能力，走的是官方正规通道。

OpenClaw 通过扩展插件支持飞书和 QQ 机器人（extensions/feishu/、extensions/qqbot/），但缺少钉钉、企业微信和个人微信的原生支持。

模型方面，Hermes 通过 models.dev 集成了 4000+ 模型的元数据，包括智谱、月之暗面、MiniMax。hermes model 一行命令切换模型。

还有离线快照机制，先从打包数据加载，再从磁盘缓存读取，最后才从网络拉取，网络不好也不影响使用。

OpenClaw 走的是 Provider Plugin 路线，每个提供商一个插件，支持 Auth Profile 轮换和 Failover，集成深度不错，广度不如 Hermes。

研究能力

Hermes 除了做产品，同时也是一个研究工具。

项目根目录下有 rl_cli.py、batch_runner.py、trajectory_compressor.py，构成一套完整的 RL 训练工具链。

研究工具链：  
Atropos RL 框架集成  
  ├── 批量轨迹生成（为模型训练造数据）  
  ├── 轨迹压缩（优化训练效率）  
  └── SWE 基准测试环境  
  
配套的 RL 工具集（10 个专用工具）：  
  rl_list_environments    列出可用环境  
  rl_select_environment   选择训练环境  
  rl_start_training       开始训练  
  rl_check_status         查看训练状态  
  rl_get_results          获取训练结果  
  ...

Hermes 的想法是训练下一代工具调用模型，用自己跑任务产生的轨迹数据去训练更强的模型，再用更强的模型跑更好的任务。

OpenClaw 在这一点上立场非常明确，它就是产品，不涉及训练。

如何选择

聊了这么多，说说我的看法。

OpenClaw 的优势在于安全、稳定、渠道丰富。TypeScript 生态对前端和全栈友好，macOS Menu Bar App 和 iOS/Android 原生客户端也是加分项。安全合规要求高的场景，可以选它。

Hermes 的优势在于自我进化。安全审计、测试覆盖确实不如 OpenClaw，但技能自动提取 + 三层记忆的这套机制，对于做 AI 研究的团队、需要频繁切换模型、或者想用 Python 快速做实验的开发者，更有吸引力。

简单总结下选型思路：

安全合规是硬要求，选 OpenClaw  
想让 Agent 自己学习改进，选 Hermes  
消息平台要覆盖最广的，OpenClaw 支持 25+ 渠道（含飞书和 QQ 机器人扩展）  
但如果主力用飞书、钉钉、企业微信，Hermes 三者都有 Gateway 原生支持，开箱即用  
做 RL 训练研究，只有 Hermes 有这套工具链  
想低成本 24 小时跑着，Hermes 的无服务器后端更合适  
TypeScript 技术栈选 OpenClaw，Python 选 Hermes

这里还有一个小细节：Hermes 已经提供了 hermes claw migrate 命令，支持从 OpenClaw 一键迁移配置。

两个项目并不是非此即彼。

最后说一句私下的话：从整体设计来说，Hermes 非常迎合小白用户，而 OpenClaw 想做生产级别的平台，显然现在各方面环境都还不太匹配，现阶段用 OpenClaw/Hermes 的场景依然偏向玩乐。

基于此，Hermes 可能会稍占优势，但做工程研究，还是需要看 OpenClaw。

说实话，我是越研究，越觉得 Hermes 这个框架真的太会讨巧了！