过去这半年，OpenClaw 几乎定义了"个人自托管智能体"这个赛道——清晰的架构、强大的本地执行能力、完善的工作区机制，让普通开发者第一次真正拥有了一个可以长期运行、主动执行任务、深度融入个人工作流的 AI 助手。

但最近，一款来自 Nous Research 的全新智能体 Hermes Agent 快速崛起，大量原本深度使用 OpenClaw 的用户开始转向 Hermes。这不只是一个新工具的出现，而是智能体正在经历从设计哲学、架构逻辑到能力成长路径的一场新变革。

今天不写教程，单纯把我看到的一些关键差异整理出来，加上我自己的理解。两个产品的根本分歧，其实藏着下一代本地智能体到底应该长什么样的回答。

1. 架构哲学的根本分歧

这是理解所有差异的起点。

OpenClaw 的核心是 Gateway 网关——一个长期稳定运行的后台守护进程，承担会话管理、请求路由、工具调用调度、全局状态维护。所有操作、每一条消息收发，都必须经过 Gateway 统一分发。这种中心化的设计带来了极高的稳定性、可审计性与可控性。

而 Hermes 的做法完全不同。它没有把网关作为核心，而是直接将 AI Agent 自身的执行循环 定义为整个系统的同步编排引擎。所有其他模块——网关、定时任务调度器、工具运行时、智能体通信协议 ACP、SQLite 会话持久化、强化学习环境——全部围绕这个核心执行循环来集成。

这两种架构的差别听起来只是"模块位置"的调整，实际带来的是能力边界的根本不同：

  • OpenClaw：稳定、透明、一切行为可追踪
  • Hermes：天生支持自我进化，每次执行都能反馈优化决策逻辑

用一个不太准确但好理解的比喻：OpenClaw 像一台精心设计的机器，每个零件各司其职；Hermes 则更像一个有机体，行动本身就是它学习和进化的方式。

2. 记忆体系：文件 vs 分层数据库

OpenClaw 的记忆以 Markdown 文件为核心载体——MEMORY.md、USER.md、AGENTS.md……结构清晰，可直接编辑，方便版本管理。但它的动态性与自我优化能力相对较弱，记忆的更新和检索比较依赖人工维护。

Hermes 则构建了一套分层持久化系统，一共三层，外加一个可选的扩展层：

第一层：核心持久记忆
包含精心精简的 MEMORY.md 与 USER.md，在每次会话启动时加载到提示词中，会话期间保持稳定。容量严格限制在约 1300 token，必须保持高度精简，保证最关键的信息始终常驻。

第二层：会话历史记忆
容量更大、可无限扩展的可检索历史库。所有对话记录存储在 SQLite 数据库中，通过 FTS5 实现高效全文索引。智能体需要历史上下文时，会主动检索数据库，精准提取相关片段，再通过大模型进行摘要重构。

第三层：扩展记忆层 Honcho
用于跨会话的深层用户理解，建立稳定的长期用户画像，记住用户的长期偏好、使用习惯与行为模式。

第四层（程序性记忆）：自动生成的技能
这是 Hermes 最具特色的设计——它不存储"智能体知道什么"，而是存储"智能体学会了怎么做"，即可以复用的工作流与行动模式。

整个记忆体系围绕 token 效率与按需检索优化：常驻内存小巧精准，动态信息交给可检索历史，稳定又高效。

3. 技能机制：从插件扩展到程序化知识

这是我认为 Hermes 最具颠覆性的差异。

OpenClaw 的技能本质上是可复用的模块化工具或工作流指令，主要由人类开发者编写、优化，按照工作区、个人、共享、插件等不同范围加载。更像是传统意义上的插件扩展包。

Hermes 对技能的理解完全不同。它把已经完成的完整工作流，直接抽象成可复用的程序化流程——不需要人工编写，智能体会根据自己的执行经验自动生成新技能，在后续执行中不断优化完善。这些技能作为动态记忆层，存储在 ~/.hermes/skills/ 目录下，智能体通过内置的 skill_manage 工具，可以自主完成技能的创建、优化、调用与管理。

换句话说：

  • OpenClaw 的技能是"开发者给智能体装上的工具"
  • Hermes 的技能是"智能体自己长出来的能力"

这带来的结果是：Hermes 的工作流全程对用户透明，每一步执行都可以观测，同时在使用中持续获得新能力——用得越久能力越强，从而实现量变到质变的成长。

4. 安全模型：设计之初的不同

OpenClaw 刚推出时，安全性一度成为最大争议点——工具使用权限不受限、自主决策风险、敏感信息泄露、提示注入攻击、运行环境缺乏有效隔离……虽然官方持续优化，但早期版本默认的安全防护较弱，更多依赖用户自身的安全策略与运维能力。

Hermes 从设计之初就把安全作为默认配置，提出了完整的五层纵深防御模型：

  1. 用户授权
  2. 危险命令审批
  3. 容器隔离
  4. MCP 凭证过滤
  5. 上下文文件扫描

此外还有 SSRF（服务器端请求伪造）防护、网站黑名单、环境变量过滤、消息用户配对、危险命令预执行扫描等多重机制。这套安全体系的目标，是让智能体可以长期稳定部署在服务器、消息平台等暴露环境中，把风险降到最低。

5. 部署与兼容性

Hermes 的设计目标是开箱即用，一条命令完成全部安装步骤。它具备极强的可移植性，可以在本地终端、VPS 服务器、Docker 容器、SSH 远程环境、无服务器架构、高性能 GPU 服务器上无缝运行。

模型无关性也是一大亮点——可以自由接入 OpenAI、OpenRouter、Kimi、MiniMax、GLM、Nous Portal 等各类模型服务，模型切换只是一个简单的配置项。

更贴心的是，Hermes 针对 OpenClaw 用户提供了无缝迁移体验——初始化时会自动检测 ~/.openclaw 配置目录，主动提供迁移核心文件的选项，包括导入记忆文件、同步迁移技能与用户偏好，最大程度降低切换成本。

这也侧面说明：Hermes 的产品定位，从一开始就是直接面向 OpenClaw 的核心用户群。

6. 一点个人感想

看完这些对比，我最大的感受不是"哪个更好"，而是它们在回答两个不同的问题。

OpenClaw 回答的是：如何让一个人可以长期、稳定、可控地运行一个 AI 助手？

Hermes 回答的是：如何让一个 AI 助手在持续使用中不断进化，最终成为一个真正意义上"越用越懂你"的存在？

这两种路线没有绝对优劣。OpenClaw 的透明与可控，对于重视审计、安全、以及不希望智能体"自作主张"的用户来说，是巨大优势。Hermes 的自我进化能力，则更接近人们对"真正智能体"的想象——它不只是执行指令的工具，而是一个能够从经验中学习、在实践中成长的伙伴。

有意思的是，Hermes 提出的"程序化知识"这个概念，让我想起了"第二系统效应"——我们通常认为 AI 的能力边界取决于模型本身，但 Hermes 在尝试做一件更激进的事：让能力边界取决于使用频率和经验积累，而不是模型上限。

这大概才是它最值得关注的点。

以上内容基于 Nous Research 官方资料整理，部分分析为个人理解，仅供参考。