OpenClaw 与 Hermes Agent 的架构差异：Gateway 控制面和学习型 Runtime

OpenClaw 和 Hermes Agent 经常被放在一起比较，因为它们看起来都像“通用 Agent 系统”：都能接聊天入口，都有工具调用，都支持记忆和技能，也都关心本地运行、权限控制和长期使用。

但它们解决的核心问题并不一样。

OpenClaw 更像一个本地优先的 Agent Gateway（网关/控制面）。它的重点是把 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Matrix、飞书、LINE、微信、WebChat 等入口接进来，再用 Gateway 管会话、路由、设备节点、工具和安全策略。

Hermes Agent 更像一个学习型 Agent Runtime（智能体运行时）。它的重点是让 Agent 在执行任务时记录经验，把复杂任务的成功路径沉淀成 Skills（技能），并在后续任务里通过搜索、记忆和用户建模减少重复试错。

一句话概括：

OpenClaw 的价值在“接入复杂世界”，Hermes 的价值在“沉淀复杂经验”。

通用 Agent 系统到底包含哪些层

一个真正能长期使用的 Agent 系统，不能只看 LLM（Large Language Model，大语言模型）本身。模型只是推理和生成的核心引擎，外面还需要一整套工程结构，才能让它稳定地接收请求、调用工具、记住信息、执行任务，并在权限边界内运行。

可以把通用 Agent 系统拆成几层：

flowchart TB
    A[消息入口<br/>聊天平台 / CLI / WebChat / API] --> B[Gateway 控制面<br/>鉴权 / 路由 / 会话 / 权限]
    B --> C[Agent Loop<br/>规划 / 调用工具 / 观察结果 / 继续执行]
    C --> D[工具系统<br/>文件 / Shell / 浏览器 / API / MCP]
    C --> E[Skills 技能层<br/>任务方法 / SOP / 可复用流程]
    C --> F[Memory 记忆层<br/>上下文 / 用户偏好 / 历史会话 / 经验]
    D --> G[执行环境<br/>本地 / 容器 / SSH / Serverless]

OpenClaw 和 Hermes 都覆盖了这些层，但“做厚”的位置不同。

如果把两者看成同一种“聊天机器人”，很多差异会被抹平；如果放到 Agent 系统分层里看，它们的架构性格就很清楚了。

OpenClaw：把真实世界接进 Agent

OpenClaw 的核心不是某一次模型调用，而是 Gateway 控制面。

它关心的问题很现实：

• 用户能不能从 Telegram、Discord、Slack、微信等熟悉入口唤起 Agent？
• 私聊和群聊应该怎么区分？
• 哪些人可以访问这个 Gateway？
• 不同设备节点应该拥有哪些权限？
• 一个长期运行的个人助理如何在本地机器或小服务器上稳定工作？
• WebChat、Dashboard、移动端节点、桌面端节点如何接到同一个控制面？

OpenClaw 支持的入口非常多，包括 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、BlueBubbles、IRC、Microsoft Teams、Matrix、飞书、LINE、Mattermost、Nextcloud Talk、Nostr、Synology Chat、Tlon、Twitch、Zalo、WeChat、WebChat 等。仓库里还包含 macOS menu bar app、iOS/Android node、Voice Wake、Talk Mode、Live Canvas 等组件。

这说明 OpenClaw 想做的不是一个“能聊天的脚本”，而是一个本地优先的个人 AI 助手控制面。

一条消息进入 OpenClaw，大致会经历这样的路径：

sequenceDiagram
    participant U as 用户
    participant C as 聊天渠道
    participant G as OpenClaw Gateway
    participant S as 会话管理
    participant M as Memory / Skills
    participant A as Agent
    participant T as 工具与设备节点

    U->>C: 发送消息
    C->>G: Webhook / Adapter 转发
    G->>G: 鉴权、allowlist、配对检查
    G->>S: 找到或创建会话
    S->>M: 加载工作区记忆与技能
    M-->>A: 提供上下文
    A->>T: 调用工具或设备节点
    T-->>A: 返回执行结果
    A-->>G: 生成回复
    G-->>C: 路由回原渠道
    C-->>U: 展示结果

这里的难点不在“调用一次 LLM”，而在消息入口、权限边界、会话状态和设备节点协同。

OpenClaw 的几个关键模块可以这样理解：

OpenClaw 的思路可以概括为：

先把入口、会话、设备和权限管起来，再让 Agent 在这个秩序里工作。

这类系统特别适合多入口个人助理、家庭设备联动、小团队内部助理、群聊机器人和本地常驻 AI 助手。

Hermes Agent：让 Agent 把经验写下来

Hermes Agent 也支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口，但这些不是它最核心的地方。

Hermes 更关心一个问题：

Agent 完成复杂任务以后，过程经验会不会消失？下次遇到相似任务时，能不能少走弯路？

它把 Agent 的执行轨迹当成长期资产处理。任务执行过程中，Agent 可以搜索过去的会话，创建或更新 Skills，并把用户偏好、工作方式、常见任务模式沉淀到记忆系统里。

Hermes 的学习循环大致如下：

flowchart LR
    A[收到任务] --> B[Agent Loop 执行]
    B --> C[调用工具<br/>Shell / 文件 / API / MCP]
    C --> D[观察执行结果]
    D --> E{任务是否完成}
    E -- 否 --> B
    E -- 是 --> F[总结关键路径]
    F --> G{是否有复用价值}
    G -- 是 --> H[创建或修补 Skill]
    G -- 否 --> I[保存会话记录]
    H --> J[写入 Skills / Memory]
    I --> K[FTS5 会话索引]
    J --> L[后续任务召回复用]
    K --> L

公开代码结构里有几类模块比较关键：

FTS5 是 SQLite 的全文搜索扩展，适合把历史会话做成可检索索引。Hermes 还使用 WAL（Write-Ahead Logging，预写日志）模式来改善并发读写体验，并支持按 source tag 过滤会话来源，比如 CLI、Telegram、Discord 等。

Hermes 的核心思路可以概括为：

不让 Agent 每次都像第一次做任务，而是把成功路径沉淀下来，后续任务通过搜索和技能复用减少重复探索。

这让 Hermes 更适合长期研究、代码修改、数据分析、周期性报告、排障流程、PR 审查、自动化运维等重复性强、路径复杂的工作。

Skills：同一个名字，两种含义

OpenClaw 和 Hermes 都讲 Skills，但语义并不一样。

OpenClaw 的 Skill 更像一个可治理的 SOP（Standard Operating Procedure，标准作业流程）库。一个 Skill 通常是一个目录，里面包含 SKILL.md，也可以包含脚本、模板、参考资料和相关资产。系统会根据来源、工作区、加载优先级、依赖条件和 gating 规则决定哪些 Skill 可用。

OpenClaw 内置了大量技能目录，例如 1Password、Discord、Slack、GitHub、coding-agent、Apple Notes、voice-call 等，也支持 AgentSkills-compatible skill folders。它强调的是“技能从哪里来、谁能用、如何加载、如何覆盖、如何审计”。

Hermes 的 Skill 更像过程记忆。它不只是预先写好的能力清单，而是 Agent 在完成复杂任务、修复棘手错误、发现可复用 workflow 后，主动创建或更新的工作方法。skill_manager_tool.py 里对 Skills 的定位就是 procedural memory：记录“怎样完成某类任务”。

两者差异可以放在一张表里：

用一个类比会更直观：

• OpenClaw 的 Skills 像团队知识库里的标准操作手册；
• Hermes 的 Skills 像一个执行者不断更新的工作笔记。

前者更适合稳定治理，后者更适合持续学习。两者不是谁取代谁，而是面向不同管理目标。

Memory：上下文、记忆和经验要分开看

Agent 系统里经常把 Context、Knowledge、Memory、Experience 混在一起说，但它们不是同一件事。

OpenClaw 的 Memory 更偏“文件即记忆”。常见文件包括：

这种方式的优点是直接、透明、容易迁移，也方便人工审查。它更像给 Agent 一个可编辑的笔记本。

Hermes 的 Memory 更像“可搜索、可召回、可转化成技能”的记忆系统。它通常包含三层：

差异在于：

• OpenClaw 更重视记忆和工作区、身份、入口权限之间的关系；
• Hermes 更重视记忆和执行轨迹、全文搜索、技能沉淀之间的关系。

如果主要需求是“让助理在不同入口里记住我是谁、当前工作区是什么”，OpenClaw 的文件化记忆更容易理解和治理。

如果主要需求是“让 Agent 记住过去怎么解决复杂问题，并在新任务中召回”，Hermes 的会话搜索和过程记忆更贴近目标。

安全模型：一个管入口，一个管运行时

安全是两者差异很大的地方。

OpenClaw 的安全模型建立在 personal assistant 场景上。它更偏向“一个受信任的操作者管理自己的 Gateway 实例”，再通过 allowlist、DM pairing、sandbox、doctor、安全审计等机制收紧边界。

常用审计命令如下：

openclaw security audit --deep

OpenClaw 需要重点防的风险包括：

• Gateway 暴露到公网后的鉴权风险；
• 多聊天渠道带来的身份冒用和误触发；
• 第三方 Skill 的 Prompt 注入和数据外泄；
• 工作区记忆被不可信输入污染；
• 设备节点和插件边界过宽；
• 临时目录、子 Agent 委派、远程访问带来的额外攻击面。

OpenClaw 历史上公开出现过 WebSocket Token 泄露、第三方 Skill 数据外泄、Prompt 注入、恶意 Skill 等安全事件。修复速度是一回事，架构上必须承认：入口越多、生态越开放，攻击面也越大。

Hermes 的安全思路更偏纵深防御。它提供多种 terminal backend，包括 local、Docker、SSH（Secure Shell，安全外壳协议）、Daytona、Singularity、Modal 等，方便把 Agent 的执行环境放进容器、远程机器或隔离后端里。

Hermes 的安全措施主要包括：

两者安全差异可以这样概括：

一句话区分：

OpenClaw 更关心“人和入口如何被治理”，Hermes 更关心“Agent 执行时如何被限制”。

能力对比表

下面的表可以作为快速选型索引。

安装路径暴露了产品性格

OpenClaw 的推荐安装方式通常从全局命令和守护进程开始：

npm install -g openclaw@latest
openclaw onboard --install-daemon

安装向导会引导配置 Gateway、workspace、channels、skills、模型和守护进程。后续可以检查 Gateway 状态：

openclaw gateway status

这条路径说明 OpenClaw 关注长期运行和入口可用性。它不是只启动一次 CLI 会话，而是希望在本地机器或服务器上常驻，成为一个可从多渠道访问的个人助理控制面。

Hermes 的快速安装方式更像先把一个会执行、会记忆、会沉淀经验的 Agent 跑起来：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
hermes

常见配置命令包括：

hermes model          # 选择模型
hermes tools          # 配置工具
hermes config set     # 修改配置
hermes gateway        # 启动 messaging gateway
hermes setup          # 全量设置向导
hermes doctor         # 诊断环境

Hermes 还强调 MCP（Model Context Protocol，模型上下文协议）、cron 定时任务、六种 terminal backend、RL（Reinforcement Learning，强化学习）trajectory 等能力。它也可以部署在 VPS（Virtual Private Server，虚拟专用服务器）上，或者通过 Daytona、Modal 这类后端降低常驻成本。

从安装体验也能看出差异：

• 想要一个长期在线、能接多个聊天入口的助理，OpenClaw 的路径更自然；
• 想要一个能执行长任务、跨会话复用经验的 Agent，Hermes 的路径更直接。

从 OpenClaw 迁移到 Hermes：能迁配置，不能迁架构

Hermes 提供了 OpenClaw 迁移命令。安装后，如果检测到 ~/.openclaw 目录，设置向导会提示迁移，也可以手动执行：

hermes claw migrate                  # 交互式迁移，默认 full preset
hermes claw migrate --dry-run        # 预览迁移内容，不真正写入
hermes claw migrate --preset user-data
hermes claw migrate --overwrite      # 覆盖已有冲突

常见可迁移内容包括：

迁移流程可以理解为：

flowchart LR
    A[OpenClaw 配置目录<br/>~/.openclaw] --> B{选择迁移模式}
    B --> C[user-data<br/>不迁 secrets]
    B --> D[full<br/>迁移允许导入的 secrets]
    C --> E[Hermes 配置目录]
    D --> E
    E --> F[检查模型 provider]
    E --> G[检查 messaging gateway]
    E --> H[重启或新建 session<br/>加载 imported skills]
    F --> I[试跑少量工作流]
    G --> I
    H --> I

迁移时要注意几个边界：

• --dry-run 适合先看清楚会迁哪些内容；
• user-data preset 不包含 secrets，更适合谨慎迁移；
• full preset 会导入 allowlisted secrets，但不会无差别搬走所有凭据；
• Discord、Telegram 等机器人配置迁移后仍建议逐项确认；
• WhatsApp 这类二维码配对型渠道可能需要重新配对；
• imported skills 通常需要新 session 或重启后才会生效；
• Hermes 迁移配置后，模型 provider 和 API Key 可能还要单独设置；
• OpenClaw Gateway 和 Hermes Gateway 的工作方式不同，迁移不是“换壳”。

更稳妥的做法是把迁移当成低成本试用入口：先迁 user-data，再挑一两个重复性强的工作流验证 Hermes 的 session search 和 skill 沉淀是否真的减少了重复劳动。

选型：看复杂度落在哪一层

选择 OpenClaw 还是 Hermes，不应该只看功能清单。两者都有聊天入口、工具调用、Skills、Memory 和模型配置，但复杂度所在的层不一样。

可以用下面这张决策表判断：

还可以用三个问题快速判断：

1. 复杂度主要在入口，还是任务本身？
2. 更担心 Agent 不可控，还是更担心 Agent 不成长？
3. 需要多用户、多渠道治理，还是个人长期任务经验积累？

如果复杂度在入口，OpenClaw 更合适；如果复杂度在任务路径和经验复用，Hermes 更合适。

更完整的 Agent 系统可能同时需要两种能力

OpenClaw 和 Hermes 并不是简单的替代关系。

OpenClaw 解决的是 Agent 如何进入真实环境：从哪些入口来、谁能访问、会话怎么分、设备节点怎么接、权限怎么管。

Hermes 解决的是 Agent 如何积累经验：过去做过什么、哪些路径可复用、哪些技能需要更新、用户偏好如何长期保留。

一个只会学习但入口和权限混乱的 Agent，很难长期接入真实生活和团队流程；一个入口齐全但每次复杂任务都从零开始的 Agent，用久了也会暴露重复劳动成本。

所以更准确的判断是：

OpenClaw 回答“Agent 如何进入世界”，Hermes 回答“Agent 如何积累经验”。

通用 Agent 的竞争已经不只是“能不能调用工具”。更关键的问题变成了：能不能管理入口、治理风险、保存经验，并让 Agent 在长期使用中变得更省心。