Hermes Agent 深度解析：自我改进 AI Agent 的架构、安装与迁移指南

本文基于 2026 年 4 月公开的 README、官方文档与 CLI Reference 整理，命令与能力以当时文档展示的 Hermes Agent 0.8.0 为准。

Hermes Agent 的官方定位是 self-improving AI agent，但真正值得关注的不是口号，而是它把技能（Skills）、持久记忆（Persistent Memory）、消息网关（Messaging Gateway）和可迁移的运行环境组合成了一套长期运行的 Agent 基础设施。 版本漂移提醒：Hermes 迭代很快，平台数量、工具数量和部分子命令会随版本调整。本文优先解释架构边界与使用方法，具体数量与 flags 以 hermes --help、hermes skills --help 和官方文档为准。

如果你要的是 IDE 里的即时补全，Hermes 不是最短路径；如果你要的是一个能在终端、聊天平台和远程主机之间持续工作的 Agent，它值得认真评估。

这篇文章尤其适合 3 类读者：准备把 AI Agent 放到远程环境长期运行的开发者，正在评估 Skills、Memory、Gateway 设计取舍的工程负责人，以及计划从 OpenClaw 迁移到 Hermes 的老用户。

学习目标

读完本文，你应该能回答下面 4 个问题：

1. Hermes 和常见 AI 助手的根本差异是什么。
2. Skills、Memory、Sessions、Gateway 分别解决什么问题。
3. 如何用最少步骤完成安装、配置、上线和 OpenClaw 迁移。
4. 哪些能力适合立即使用，哪些地方必须先做安全和运维约束。

先给结论：Hermes 适不适合你

一句话判断：Hermes 的价值不在“能不能接大模型”，而在“能不能随着使用过程积累能力，并脱离你的本地会话独立工作”。

Hermes Agent 真正解决的问题是什么

很多 Agent 项目都能调用模型、执行工具、读写文件，但它们往往缺 3 个关键环节：

1. 缺少长期记忆，上一轮做对的事情下一轮还要重新学。
2. 缺少稳定入口，CLI、聊天平台和远程主机彼此割裂。
3. 缺少可迁移能力，经验停留在 prompt，而不是沉淀为结构化资产。

Hermes 的设计重点恰好针对这 3 个问题。它不是“一个更花哨的聊天壳”，而是一套面向持续运行的 Agent 基础设施。

它和常见 AI 助手的差别

这也是为什么官方反复强调 built-in learning loop。它不是简单地“调用更多工具”，而是把成功经验变成以后还能继续使用的能力。

架构拆解：Hermes 如何把一次成功变成长期能力

1. 闭环学习是它的核心设计

Hermes 的核心流程可以拆成 6 步：

1. 用户给出任务。
2. Agent 调用模型、工具和运行环境完成任务。
3. 对复杂任务的成功路径进行沉淀。
4. 将可复用流程整理为技能（Skills）。
5. 将关键事实写入记忆，或在会话库中保留可检索轨迹。
6. 下次遇到相似任务时直接复用，而不是从零开始。

这个设计的关键意义在于：Hermes 把“会做一次”变成“以后更会做”。很多 Agent 只能临场发挥，而 Hermes 试图把能力积累本身纳入系统设计。

2. 关键组件一览

3. 为什么这套结构适合长期运行

它适合长期运行，不是因为功能列表很长，而是因为几个核心环节解耦得比较干净：

1. 交互入口和执行环境解耦。你可以在 Telegram 下命令，但让它在远程环境里工作。
2. 即时上下文和长期记忆解耦。当前对话不会无限膨胀，关键事实才进入长期层。
3. 临时成功和可复用能力解耦。不是每次都重新 prompt，而是把流程沉淀成 Skill。

重点能力 1：Skills 不是提示词模板，而是程序化记忆

如果只看名字，很多人会把 Skills 理解成“高级 prompt 模板”。这是不够准确的。

在 Hermes 的文档里，Skills 更接近按需加载的知识文档和执行流程封装。它们遵循 progressive disclosure，也就是先只暴露索引，真正需要时再加载全文，从而控制 token 消耗。

你应该怎样理解 Skills

可以把 Skills 看成 3 层东西：

1. 一层是触发条件。什么情况下该用这个 Skill。
2. 一层是操作步骤。遇到问题时应该按什么流程执行。
3. 一层是附属资源。参考资料、模板、脚本、配置说明都可以挂在 Skill 目录下。

这意味着一个 Skill 不只是告诉模型“怎么说”，而是在告诉 Agent“什么时候做、按什么步骤做、做完如何验证”。这比单纯 prompt 更接近工程化工作流。

技术上最值得注意的 4 个点

1. 所有 Skills 的本地主目录都在 ~/.hermes/skills/，这是默认的读写真源。
2. 每个已安装的 Skill 都会自动变成一个斜杠命令，可以在 CLI 或消息平台里直接调用。
3. Agent 可以在完成复杂任务后自己创建或改写 Skill，把成功路径沉淀下来。
4. Hub 安装的第三方 Skills 会经过安全扫描，危险结论不能被 –force 覆盖。

后两点尤其重要。它们决定了 Hermes 的 Skills 不是“共享提示词市场”，而是带有安全门槛和自我积累能力的工作流资产层。

一个 Skill 目录通常长什么样

官方文档给出的 Skill 目录结构，大致是下面这个形态：

~/.hermes/skills/
├── mlops/
│   └── axolotl/
│       ├── SKILL.md
│       ├── references/
│       ├── templates/
│       ├── scripts/
│       └── assets/
├── devops/
│   └── deploy-k8s/
│       └── SKILL.md
└── .hub/

这里可以这样理解：

1. SKILL.md 负责定义触发条件、步骤和验证方式。
2. references/ 放长文档和补充材料，避免把所有内容塞进主 Skill。
3. templates/ 和 scripts/ 负责把知识变成可执行工作流，而不是只停留在说明文字。

这也是 progressive disclosure 真正落地的地方：先给 Agent 一个轻量索引，真正需要时再加载更具体的参考内容或辅助脚本。

常用 Skill 工作流

hermes skills browse --source official
hermes skills search react --source skills-sh
hermes skills inspect official/migration/openclaw-migration
hermes skills install official/migration/openclaw-migration
hermes skills check
hermes skills update

在对话内，对应的入口通常是：

/skills browse
/skills search react --source skills-sh
/<skill-name>

使用建议

1. 优先安装 official 源或文档明确可信的源。
2. 社区 Skill 先 inspect，再 install。
3. 把真正反复执行的工作流沉淀成 Skill，不要把一次性任务也过度结构化。

重点能力 2：Memory、Session Search、External Provider 不是一回事

原稿把这一块写成“Notion 式记忆”，这个说法容易让读者误解。

更准确的说法是：Hermes 有一个小而硬的内置记忆层，一个按需检索的历史会话层，以及一个可插拔的外部记忆增强层。它不是无限知识库，更不是随写随刷新的聊天长上下文。

三层记忆应该这样区分

两个容易被忽略的技术细节

1. 内置记忆是冻结快照。它在会话开始时注入系统提示，中途即使被更新，也不会自动刷新到当前会话前缀里。
2. Built-in Memory 的容量是刻意受限的。官方文档给出的默认上限大约是 MEMORY.md 2200 字符、USER.md 1375 字符，目的是保证信息密度，而不是鼓励无限堆积。

一个很实用的例子是：如果你在当前会话里刚改了 USER.md 中的偏好，持久化已经成功，但当前会话里的模型前缀仍然是旧快照。最稳妥的做法是开启一个新会话，或者在当前轮显式重述刚刚更新的约束。

所以，真正合理的理解方式是：

1. Built-in Memory 存“每次都该知道的关键事实”。
2. Session Search 存“需要时再查的历史上下文”。
3. External Provider 存“更深的跨会话语义层”。

什么时候考虑 Honcho 或其他外部记忆

当你出现下面 3 种需求时，就该认真看外部记忆提供者：

1. 你希望 Agent 建立更稳定的用户画像，而不是只靠 USER.md 的短文本。
2. 你需要更强的跨会话召回，而不是只靠简单的关键词检索。
3. 你要在多个长期项目之间共享更深层的用户和任务上下文。

这时可以用：

hermes memory setup
hermes memory status
hermes honcho status

重点能力 3：Gateway 让 Agent 脱离你的笔记本

很多 Agent 在本地终端里表现不错，一离开笔记本就失去存在感。Hermes 的 Gateway 解决的是这个问题。

官方文档当前列出的平台已经覆盖 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost、Email、SMS、DingTalk、Feishu/Lark、WeCom、Weixin、BlueBubbles，以及 Home Assistant 等场景。更重要的是，这些入口背后不是多个独立 Bot，而是一个统一的 Gateway 进程。

Gateway 到底做了什么

它至少承担 4 件事：

1. 接收各个平台消息并映射到对应会话。
2. 为每个聊天维持 session store。
3. 驱动 cron scheduler，定期执行到点任务。
4. 统一处理消息送达、流式更新、附件与安全约束。

最容易混淆的命令边界

hermes gateway setup
hermes gateway            # 前台运行
hermes gateway install    # 安装用户级服务；macOS 下对应 launchd
hermes gateway start
hermes gateway status

这里最常见的误区是：还没 install，就直接 start。hermes gateway start 启动的是已安装服务，不是“一键配置再启动”的快捷命令。

后台运行的操作速查

如果你要的是个人机器常驻，优先用默认的用户级服务；如果你要的是 VPS 或无人值守主机，再考虑 Linux 下的 system service。

安全默认值值得保留

Gateway 默认会拒绝不在 allowlist 里的用户，或者要求通过 DM pairing 配对。这是正确的默认值，因为一个具备终端访问能力的 Bot 不应该对陌生用户开放。

相关操作包括：

hermes pairing list
hermes pairing approve telegram <code>
hermes pairing revoke telegram <user-id>

macOS 用户要特别注意的一点

在 macOS 上，Gateway 服务通过 launchd 运行，生成的 plist 会固化安装当时的 PATH。如果你后来又装了新的 Node.js、ffmpeg 或其他依赖，最好重新执行一次：

hermes gateway install

否则 Gateway 进程可能继续使用旧 PATH，表现为某些桥接或工具在交互式 shell 里正常、在后台服务里却找不到。

重点能力 4：它不是只能跑在本地终端里

Hermes 的另一个关键点，是执行环境并不绑死在当前机器上。

官方文档当前列出的终端后端包括：

1. local
2. Docker
3. SSH
4. Daytona
5. Singularity
6. Modal

这带来两个直接收益：

1. 你可以把危险任务、长任务或依赖复杂的任务放到隔离环境里。
2. 你可以让 Agent 常驻在 VPS、GPU 主机或近乎零空闲成本的 serverless 基础设施上，而不是要求你的笔记本一直在线。

如果你准备把 Hermes 当作持续运行的个人基础设施，这一点比“支持多少模型”更重要。

重点能力 5：Cron、Subagents、MCP 让它从聊天工具变成自动化底座

当一个 Agent 同时具备调度、并行化和外部系统接入能力时，它的定位就不再只是聊天工具。

对应命令入口主要是：

hermes cron list
hermes mcp list
hermes acp

如果你把 Hermes 只当“能聊天的 CLI”，这三部分会显得多余；如果你把它看作个人或团队自动化底座，这三部分才是决定上限的能力。

10 分钟上手：建议按这个顺序配置

1. 先确认前置条件

最低限度建议先准备好这 4 件事：

1. Linux、macOS、WSL2，或 Android 的 Termux 环境。
2. 一个可用的模型提供商凭据。
3. 如果要接消息平台，对应平台的 Bot token 或认证配置。
4. 如果要跑后台服务，明确你想要的是本机长期运行，还是远端常驻运行。

官方当前不支持原生 Windows，Windows 用户应走 WSL2。

2. 安装与首次启动

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

如果你用的是 Bash，把第二行换成 source ~/.bashrc 即可。

3. 第一轮最小可用流程

建议第一次使用按下面顺序走，而不是一上来就把所有平台、所有插件、所有 Skill 都装满：

1. 先用 hermes setup 完成模型、终端、工具和 Agent 基础配置。
2. 再用 hermes model 确认默认提供商与模型。
3. 然后用 hermes tools 只启用你当前真的需要的工具集。
4. 在 CLI 中跑一轮最简单会话，确认 /model、/usage、/skills 都能工作。
5. 最后才接入 hermes gateway setup，把聊天平台连上。

这条顺序的好处是：你先验证核心执行链，再增加外围集成，排查成本最低。

4. 遇到问题先看这 4 个命令

hermes status --deep
hermes doctor
hermes dump
hermes logs gateway -n 100

这 4 个命令足以覆盖大多数安装、网关和配置问题。尤其是 hermes dump，很适合做支持排障时的“环境快照”。

如果你想少走弯路，可以直接按下面这张表对号入座：

5. 高频命令速查

OpenClaw 迁移：把“先 dry-run，再显式 preset”当成纪律

Hermes 的 OpenClaw 迁移能力很强，但这也是最容易因为想当然而出错的地方。

最稳妥的原则只有两条：

1. 永远先跑 dry-run。
2. 永远显式写出 preset，不要把默认行为交给记忆或旧教程。

推荐迁移顺序

hermes claw migrate --dry-run
hermes claw migrate --preset user-data
hermes claw migrate --preset full

如果你想走交互式、带预览和冲突处理的迁移路径，也可以安装官方 optional skill：

hermes skills install official/migration/openclaw-migration

目前文档显示会直接迁移的内容

官方 CLI Reference 当前列出的直接导入项，已经覆盖 30 多类内容，核心包括：

1. SOUL.md、MEMORY.md、USER.md、AGENTS.md。
2. Skills。
3. 默认模型与自定义 provider。
4. MCP servers。
5. Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost 等平台的 token 与 allowlist。
6. Agent 默认设置、审批规则、TTS、浏览器、工具设置、执行超时、命令白名单。
7. Gateway 配置与 API keys。

目前文档显示需要人工复核的内容

仍有一批内容会被归档，而不是直接无损转写：

1. Cron jobs。
2. Plugins。
3. Hooks / webhooks。
4. 旧的 memory backend 配置。
5. Skills registry config。
6. UI / identity / logging / multi-agent setup。
7. Channel bindings，以及 IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOTSTRAP.md 等文件。

这意味着迁移不是“按下命令就万事大吉”，而是“先自动搬一大半，再对复杂边角做人工复核”。

迁移后立刻检查的 5 件事

1. 默认模型和 provider 是否正确。
2. 平台 token、allowlist 和 pairing 策略是否仍符合你的安全要求。
3. Skills 是否有重名冲突，尤其是你同时保留了本地和导入版本时。
4. AGENTS.md 是否确实迁移到了你期望的 workspace target。
5. 归档项里是否有你真正还在依赖的 cron、plugin 或 hook。

生产使用建议：把它当系统运营，而不是当聊天玩具

三种典型用法

安全与运维底线

真正上线前，至少确认下面 6 条：

1. 不要轻易允许所有 Gateway 用户访问终端能力。
2. 危险命令必须保留审批或更严格的隔离后端。
3. 社区 Skill 先 inspect，再决定是否 install。
4. 长期运行的 Gateway 要有日志检查习惯。
5. 不信任任务优先放进 Docker、SSH 或其他隔离后端。
6. 迁移前后都要保留可回滚的备份视角，不要只相信“看起来成功了”。

故障排查的最小工具箱

hermes status --deep
hermes logs
hermes logs gateway -f
hermes doctor
hermes dump

如果你已经接入消息平台，这一组命令的价值远高于反复重装。因为多数问题不是“程序没装好”，而是认证、PATH、服务状态、配置项和平台授权之间的边界没理清。

常见误区

误区 1：把 Skills 当作静态 prompt 模板

Skills 的工程价值在于触发条件、执行步骤、附属资源和可演进性，而不是“给模型喂一段更长说明”。

误区 2：把 Memory 当成无限知识库

Built-in Memory 是有限容量的高价值事实层，不是所有历史信息的仓库。历史检索应该交给 Sessions 或外部记忆提供者。

误区 3：把 hermes gateway start 当成初始化命令

它启动的是已安装服务，不负责帮你完成平台配置和服务安装。

误区 4：在 macOS 上更新依赖后忘记重装 Gateway 服务

launchd 的 PATH 是静态捕获的。你在 shell 里能找到的新工具，后台服务未必能找到。

误区 5：迁移 OpenClaw 时不写 –preset

迁移是高风险动作。显式写出 user-data 或 full，比依赖记忆中的“默认应该是什么”更稳。

动手练习

如果你想真正理解 Hermes，而不是只记住几个命令，建议做下面 3 个练习：

1. 理解型练习：用自己的话解释 Built-in Memory、Session Search 和 External Memory Provider 的边界差异。
2. 操作型练习：只用 CLI 完成一次从安装、setup 到 model 确认的最小可用链路。
3. 运维型练习：在 macOS 或 Linux 上把 Gateway 配成后台服务，并确认 status、logs、pairing 都能正常工作。

自测清单

• 你是否能区分 hermes、hermes gateway、hermes acp、hermes mcp 这 4 个入口分别面向什么场景。
• 你是否知道为什么 Built-in Memory 在会话中途更新后，不会立刻刷新进当前系统提示。
• 你是否知道为什么社区 Skill 要先 inspect，再 install。
• 你是否知道 OpenClaw 迁移后哪些内容需要人工复核。
• 你是否知道在消息平台开放终端能力前，为什么必须先做 allowlist 或 pairing。

如果这 5 条你都能讲清楚，说明你已经不是“看过 Hermes”，而是开始理解它的系统边界了。

延伸阅读

站内相关文章

• OpenViking：字节跳动开源的 19.6k Stars AI Agent 上下文数据库
• 通用 Agent 竞争的任务交付逻辑分析
• MarkItDown 完整指南：从文档转换到 MCP 服务器

官方资料

• GitHub 仓库
• 官方文档首页
• CLI Reference
• Skills System
• Persistent Memory
• Messaging Gateway
• OpenClaw Migration Guide