教程

OpenClaw 用户上手 Hermes Agent：从概念迁移到真正跑起来

站在 OpenClaw 用户视角，重新理解 Hermes Agent 的运行方式、模型与 OAuth、Tools / Skills / MCP、Session / Memory、Gateway，以及如何安全迁移现有 OpenClaw 配置。

作者：黄撑更新于 2026-08-22

本文目录 11 节 · 点击展开

如果已经熟悉 OpenClaw，再看 Hermes Agent，最容易犯的错误是：把 OpenClaw 的名词一一套过去，然后认为 Hermes 只是另一套 CLI 外壳。

这在 2026 年已经不准确了。

Hermes 当然可以在终端里直接运行，但现在它同时拥有 Desktop、Dashboard、Project、Profile、Gateway、Session、Memory、Skills、MCP、Cron 等完整能力；更关键的是，官方已经直接提供了 OpenClaw → Hermes 的迁移工具。

HERMES AGENT · OPENCLAW USER FIELD GUIDE不要先背命令。先把你熟悉的 OpenClaw 心智模型，翻译成 Hermes 的运行结构。

理解运行边界 → 跑通模型 → 看懂 Tools / Skills / MCP → 分清 Session / Memory → 最后再接 Gateway。

01Runtime它到底在运行什么

→

02Capability工具能力从哪里来

→

03State会话和记忆如何留下

→

04Gateway再把它接到消息渠道

本文不是官方文档翻译。重点是站在 OpenClaw 用户已经具备的认知基础上，快速建立 Hermes 的运行模型，再把真正需要的安装、能力、状态和 Gateway 串起来。

官方参考入口：Hermes Agent 文档、CLI Reference、GitHub Releases。

先认识 Hermes：它是一套完整的 Agent 运行环境

Hermes 的核心仍然是 Agent Runtime：接收任务、组织上下文、调用模型、选择工具、执行动作、保存状态。但围绕这个 Runtime，已经长出一整套完整表面。

01 · SYSTEM SURFACE同一个 Agent Runtime，可以从很多入口进入

CLI 只是最轻的入口，不再等于 Hermes 的全部。

CLI / TUI终端直接工作

Desktop原生桌面入口

Dashboard浏览器管理配置与会话

Gateway消息平台持续接入

RUNTIMEHermes Agent模型推理 · 工具调用 · 规则 · 状态 · 自动化

Project命名项目 / 多目录工作区

Profile隔离配置、会话与 Skills

Session一次持续对话的运行状态

Memory跨会话保留的信息

所以今天更合适的理解是：

Hermes 是一套完整的 Agent 运行环境。CLI 是它最直接的入口，但不是它的边界。

这和 OpenClaw 的差别，也不再是“一个有 Gateway，一个没有 Gateway”。两者现在都有完整运行时、Skills、工具、会话和消息渠道，只是组织方式和使用重心不同。

用 OpenClaw 的词汇翻译 Hermes

下面这张图不是“协议级对应”，而是为了降低迁移时的理解成本。

02 · CONCEPT MAP可以类比，但不要假设完全等价

先找到熟悉的概念，再看它在 Hermes 里是怎么重新组织的。

OpenClaw↔Hermes理解重点

Agent Runtime→Hermes Agent

都负责模型、工具和上下文的主循环。

Workspace→cwd / Project

OpenClaw 强调每个 Agent 有明确 workspace；Hermes 既能从当前目录启动，也有 Project 管理层。

Tools→Tools / Toolsets

可执行能力。Hermes 通过 toolset 组合、开关和平台策略组织。

Skills→Skills

两边都以 SKILL.md 为核心，用知识和流程指导 Agent 使用能力。

MCP→MCP

都用于接入外部工具服务器；Hermes 也能反过来把自己暴露成 MCP server。

Sessions→Sessions

保存持续对话与运行上下文，但具体路由和存储结构不同。

MEMORY / USER→MEMORY / USER + Provider

Hermes 内置记忆始终存在，还可叠加一个外部 Memory Provider。

Gateway / Channels→Gateway / Platforms

都把同一套 Agent 接入 Telegram、Discord、Slack、钉钉等消息渠道。

Model Provider→Provider / Model / Auth

Hermes 把模型选择、OAuth/API Key 和凭据池拆成不同管理面。

最重要的差异之一，是 OpenClaw 的 workspace 是 Agent 的明确“家”；Hermes 则允许你直接在项目目录里启动 Agent，同时又通过 hermes project 和 hermes profile 管理更复杂的项目和隔离实例。

Hermes 实际在做什么：看一条完整运行链路

如果把所有名词都拿掉，一次 Hermes 任务其实只有四层。

03 · RUNTIME PATH输入不是重点，关键是任务如何穿过四层系统

CLI、Desktop 和 Gateway 最终都会进入同一个 Agent 执行逻辑。

01INPUT用户任务

CLI、TUI、Desktop、Gateway、Cron。

→

02REASONAgent + Model

读取规则、上下文和当前 Session，决定下一步。

→

03ACTTools / Skills / MCP

读文件、执行命令、浏览网页、调用外部服务。

→

04STATE结果 + Session + Memory

返回结果，并把该留下的状态保存下来。

一句话模型负责判断下一步；Tools / MCP 负责真正执行；Skills 负责告诉 Agent 应该怎样做；Session / Memory 负责让下一轮不从零开始。

这也是理解 Hermes 最重要的一条线：Tool 和 Skill 绝不是同一个东西，Session 和 Memory 也绝不是同一个东西。

安装：先选择适合你的运行环境

Hermes 当前支持 macOS、Linux、WSL2 和 Windows Native；macOS / Windows 还提供 Hermes Desktop。选择时不必先从操作系统出发，先决定自己要的是桌面应用还是 CLI 更简单。

04 · INSTALL先选运行环境，再只做最短验证

目标不是一次配齐所有能力，而是先证明模型和 Agent Loop 正常。

macOS / WindowsDesktop Installer

官方当前推荐的桌面安装路径，适合希望直接使用 GUI 的用户。

也可以只安装 CLI

Linux / macOS / WSL2CLI Install

最接近传统 OpenClaw / Coding Agent 的使用方式。

适合服务器、WSL2、SSH 环境

Windows NativePowerShell

不再要求为了 Hermes 单独进入 WSL2。

适合原生 Windows 工作流

Linux / macOS / WSL2 的当前官方 CLI 安装命令：

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Windows Native：

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

安装后先做最小检查：

hermes version
hermes doctor

然后只处理模型，不要马上接 Gateway、Browser、MCP：

hermes model
hermes chat -q "Reply with exactly: OK"

如果这个最小聊天都不通，继续配置更多能力只会增加变量。

官方安装与 Quickstart：Installation、Quickstart。

OpenClaw 用户最值得先看的，其实是官方迁移工具

如果你已经有一套 OpenClaw 配置，这可能是最值得先看的能力。

Hermes 会在首次 hermes setup 时检测 ~/.openclaw，并询问是否查看迁移计划。也可以随时手动执行：

hermes claw migrate --dry-run

这个命令只预览，不写入。

05 · OPENCLAW MIGRATION不要手工复制配置，先让 Hermes 给出迁移计划

官方迁移器已经理解两套系统之间大量字段和目录的映射。

1读取 OpenClaw~/.openclaw

识别 persona、memory、skills、provider、MCP、gateway 等配置。

→

2Dry Run只生成迁移预览

先看会迁什么、冲突在哪里、什么需要人工处理。

→

3Apply确认后才写入

迁移到 ~/.hermes，冲突按策略处理。

可以直接映射SOUL · MEMORY · USER · Skills · Model · MCP · Gateway · Approval 等

当前 CLI Reference 已列出 30+ 类迁移项。

需要归档 / 人工复核Cron · Plugins · Hooks · Multi-Agent · 部分 UI / Identity 等

没有可靠一一对应的内容不会硬塞进 Hermes。

安全默认值：即使使用 full preset，也不会自动迁移 secrets；只有显式加 --migrate-secrets 才会包含密钥。

我更建议的路径是：

# 1. 只看计划
hermes claw migrate --dry-run

# 2. 只迁用户数据，不碰 secrets
hermes claw migrate --preset user-data

如果确实准备把现有 OpenClaw 配置完整迁过去，再查看 hermes claw migrate --help，逐项决定 provider、gateway、skills 冲突和 workspace instruction 怎么处理。

官方文档：Migrate from OpenClaw。

Model / Provider / OAuth：不要把这三个概念揉成一个

OpenClaw 用户通常已经习惯“Provider + Model”。Hermes 还多了一层非常显眼的 Auth 管理。

现在最简单的原则是：

06 · MODEL & AUTH选谁提供推理、选哪个模型、凭什么登录，是三件事

多数配置都应该先从 hermes model 进入，而不是手改 YAML。

PROVIDER谁提供推理

Nous Portal、OpenRouter、Anthropic、OpenAI API、Gemini、Copilot、自建 endpoint……

MODEL具体用哪个模型

同一个 Provider 下面可以切换多个模型，也可以做 fallback / routing。

AUTH凭什么访问

API Key、OAuth、device code、credential pool 等。

ANous Portalhermes setup --portal

一次 OAuth 配好模型入口和 Tool Gateway。适合已经使用 Nous Portal 的用户。

BOAuth Providerhermes model

Codex、Anthropic、Copilot、Qwen、MiniMax 等支持对应 OAuth 流程。

CAPI Key / 自建hermes model / .env

OpenRouter、Gemini、DeepSeek、OpenAI-compatible endpoint 等。

这里有一个非常容易混淆的地方：

hermes model：终端外执行。负责新增 Provider、OAuth 登录、录入 API Key、选择模型。
/model：Hermes 会话里面执行。只负责在已经配置好的模型之间切换。
hermes auth：更偏凭据池和认证状态管理，不是普通用户第一次配置模型的首选入口。

以 OpenAI Codex 为例，当前推荐直接通过 Hermes 的登录入口完成 OAuth：

hermes model

在模型向导里选择 ChatGPT / Codex Subscription，并完成 OAuth。

官方 Provider 文档：AI Providers。

Tools、Skills、MCP：一个负责做，一个负责教，一个负责扩展

这是最需要讲清楚的一组概念。

07 · CAPABILITY LAYERSTool 能执行，Skill 能指导，MCP 能把外部能力接进来

三者最终都会影响 Agent 能不能完成任务，但工作层级完全不同。

TOOL真正产生动作

terminal、file、web、browser、memory、cron、delegation……

像 OpenClaw 的 tools / exec / browser

SKILL告诉 Agent 应该怎么做

按需加载 SKILL.md，提供领域知识、流程、规则和工具使用方法。

不是“执行函数”，而是任务知识

MCP把外部工具接进来

GitHub、数据库、公司服务、文件系统、第三方工具服务器。

外部能力进入 Hermes 的标准桥梁之一

例子“帮我修这个仓库里的 Bug”→

Skill 先告诉 Agent 项目规则和排查方法

→

Tool 读文件、执行测试、修改代码

→

MCP 如果需要，再调用 GitHub 或外部系统

常用查看命令：

hermes tools --summary
hermes skills list
hermes skills search <keyword>
hermes mcp

当前 Hermes 的 Skills 已经不仅是“本地放一份 SKILL.md”。CLI 支持 browse、search、inspect、install、update、audit、publish，也有 Skill 写入审批和 curator 等机制。

Hermes 可以作为 MCP Client 连接 stdio / HTTP server，也可以执行：

hermes mcp serve

把自己的消息会话能力暴露成 MCP server，给其他 Agent 使用。

MCP 工具进入 Hermes 后，会使用类似下面的命名规则：

mcp__server_name__tool_name

例如 server 名和 tool 名中的特殊字符会被清洗后注册。

官方文档：Tools & Toolsets、MCP。

Session 和 Memory：一个负责“这次聊到哪”，一个负责“以后还记得什么”

这两个概念经常被写在一起，实际应该分开。

08 · STATE MODELSession 是运行上下文，Memory 是跨会话知识

“没有清空聊天”不等于长期记忆；“写进 Memory”也不等于永远把全部内容塞进当前上下文。

SESSION这一段对话进行到哪里

保存消息、模型、工具调用和会话状态
Gateway 中按聊天来源路由
可以 browse、resume、rename、export、prune
当前主存储以 ~/.hermes/state.db 为核心

hermes sessions browse

MEMORY跨 Session 仍值得保留什么

内置 MEMORY.md / USER.md 始终可用
可叠加一个外部 Memory Provider
外部 Provider 是增强，不会替代内置 Memory
适合稳定偏好、项目事实、长期知识

hermes memory status

管理 Session：

hermes sessions list
hermes sessions browse
hermes sessions stats

管理外部 Memory Provider：

hermes memory setup
hermes memory status
hermes memory off

当前官方文档列出的外部 Memory Provider 包括 Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover、Supermemory 等；同时只激活一个外部 Provider，内置 Memory 始终继续工作。

官方文档：Memory Providers。

Gateway：它和 OpenClaw 的 Gateway 最像，但仍不要默认完全等价

如果已经把 OpenClaw 当作一个“消息渠道 ↔ Agent Runtime”的统一入口，那么 Hermes Gateway 很容易理解。

09 · MESSAGING GATEWAY一套 Agent，接入多个真实消息渠道

Gateway 负责平台连接、会话路由、Cron 和消息投递，不是模型本身。

TelegramDiscordSlackWhatsAppSignal钉钉飞书企业微信TeamsMatrix更多

Platform Adapter→Per-chat Session→Hermes Agent→Tool / Model→Deliver

最简单的配置入口：

hermes gateway setup

运行方式：

hermes gateway run
hermes gateway status

WSL 用户要特别注意：当前官方 CLI Reference 明确建议 WSL 场景优先使用前台 hermes gateway run，而不是依赖 gateway start 的 systemd 服务模式。

Hermes Gateway 当前支持 Telegram、Discord、Slack、WhatsApp、Signal、Email、Mattermost、Matrix、DingTalk、Feishu/Lark、WeCom、Microsoft Teams、LINE 等渠道。

官方文档：Messaging Gateway。

常用命令：只保留现在真正值得记的

日常使用其实不需要背很多命令。先记住下面这组高频入口，其余功能需要时再查 --help。

安装 / 检查 version · doctor · status · update模型 / 登录 setup · model · auth能力 tools · skills · mcp · memory状态 sessions · profile · project消息 gateway · send · pairing

# 基础状态
hermes version
hermes doctor
hermes status --all --deep
hermes update --check

# 模型与认证
hermes setup
hermes model
hermes auth list

# 工具与扩展
hermes tools --summary
hermes skills list
hermes mcp
hermes memory status

# 会话
hermes sessions browse

# Gateway
hermes gateway setup
hermes gateway status

# OpenClaw 迁移
hermes claw migrate --dry-run

会话内更常用的是：

/model
/status
/new
/sessions
/resume
/tools
/skills
/memory
/reload-mcp
/help

真正不知道时，优先看：

hermes --help
hermes <command> --help

这样比维护一张越来越长、很快过期的命令表可靠得多。

到底什么时候用 Hermes，什么时候继续用 OpenClaw？

我不建议把这个问题理解成“谁替代谁”。更实用的判断是：你当前想优化的是哪一层。

10 · DECISION MAP不是二选一，而是看现有系统哪一套更接近你的工作中心

两边能力已经高度重叠，迁移成本和既有生态往往比功能清单更重要。

更值得试 Hermes你想重新搭一套 Agent 工作环境

希望 CLI / Desktop / Gateway 用同一套 Hermes 状态
重视多 Provider / OAuth / Profile / Project
想使用 Hermes 当前的 Skills、Plugins、Memory Provider 生态
希望直接用官方 hermes claw migrate 迁移 OpenClaw 数据

继续用 OpenClaw现有体系已经稳定运行

现有 workspace、skills、gateway、channels 已经形成稳定习惯
大量项目规则和自动化已经围绕 OpenClaw 构建
当前没有明确痛点，不需要为了“换 Agent”重新迁移运维体系
更重视稳定延续，而不是尝试另一套运行环境

最小成本策略先并行试用，再决定迁移。

用 Hermes 跑一个真实项目，体验模型、Tools、Skills、Session 和 Gateway；确认确实更适合，再对 OpenClaw 做 dry-run migration，而不是先删掉旧系统。

如果已经是 OpenClaw 重度用户，我会先做下面这组最小实验：

# 1. 安装并跑通模型
hermes model
hermes chat -q "检查当前目录，并总结这个项目是做什么的"

# 2. 看工具边界
hermes tools --summary

# 3. 看 OpenClaw 迁移计划，但暂时不写入
hermes claw migrate --dry-run

# 4. 确认真正想迁的内容，再决定是否执行

这样你得到的不是一张“功能对比表”，而是一次真实体验：Hermes 在你的工作流里，到底能不能比现有 OpenClaw 更顺。

TAKEAWAYOpenClaw 用户学 Hermes，最省时间的方法不是重新学习一套 Agent 概念，而是先翻译已有经验，再把不等价的地方单独学清楚。

先跑通 Runtime，再理解 Tools / Skills / MCP；先分清 Session / Memory，再接 Gateway。真正准备迁移时，从 hermes claw migrate --dry-run 开始。