其他

关注公众号 jb51net

关闭
AI > 其他 >

一文全解Hermes Agent 的 Skills、Plugins、Gateway

jiayong23

Hermes Agent 的 Skills、Plugins、Gateway 深度解析

1. 为什么要单独分析这三个系统

如果说：

那么：

这三者决定了 Hermes Agent 为什么不是一个封闭单体，而是一个可以持续扩展、接入多生态、多平台、多工作流的系统。

2. Skills 系统：它本质上是什么

Skills 不是 Python 插件，也不是代码模块。

它本质上是一种：

面向 Agent 的、按需加载的知识文档/工作流文档系统。

它解决的问题是：

于是 Hermes 采用了技能机制：

这就是文档里所谓的 progressive disclosure。

3. Skills 的核心设计

3.1 数据结构

典型技能目录结构：

<skill-name>/
  SKILL.md
  references/
  templates/
  scripts/
  assets/

SKILL.md 是核心。

它一般包含：

3.2 技能发现与索引

相关关键位置：

工作方式大致是：

  1. 扫描本地技能目录
  2. 解析 SKILL.md frontmatter
  3. 生成 skill 索引
  4. 将 skill 映射为 slash command
  5. 在需要时通过 skill_view 加载完整内容

3.3 技能的“按需加载”

文档中给出了 3 层加载模式：

这种设计的价值非常大：

4. Skills 的运行方式

4.1 Skill 可以像 slash command 一样使用

例如：

说明 skill 在用户感知层像“命令”，但底层其实是文档型能力加载。

4.2 Skill 也可以在自然对话中被调用

这说明 skill 不是强依赖显式 slash command 的，而是 Agent 可主动发现和装载。

4.3 Skill 可以有条件显示

文档明确支持：

这意味着 skill 系统已经不是简单文件夹扫描，而是具备运行时条件装配能力。

5. Skills Hub：技能生态层

tools/skills_hub.py 和 hermes_cli/skills_hub.py 说明 Hermes 还做了一个更进一步的事情：

把 skills 做成可安装、可搜索、可审计、可隔离来源的生态系统。

它支持的内容包括：

这已经非常接近包管理器思路。

5.1 为什么这很重要

因为 skill 一旦规模变大，用户就不可能只靠仓库自带内容：

Hermes 已经显式意识到了这一点。

6. Plugins 系统：它和 Skills 的区别

这是很多人第一次看仓库时最容易混淆的点。

Skill

Plugin

所以：

Skill 是“给模型看的能力文档”，Plugin 是“给系统加能力的代码扩展”。

7. Plugins 系统怎么工作

关键文件：

它明确写了三种插件来源：

  1. 用户插件
    • ~/.hermes/plugins/<name>/
  2. 项目插件
    • ./.hermes/plugins/<name>/
  3. pip entrypoint 插件
    • hermes_agent.plugins

7.1 一个插件需要什么

目录型插件至少要有：

7.2 插件能做什么

从 PluginContext 看，插件至少可以：

这意味着插件能力很强，几乎能插进系统多个层面。

8. Plugin Hooks：生命周期插点

VALID_HOOKS 目前包括：

这说明插件机制不是“只支持加载工具”，而是真正支持生命周期扩展。

8.1 这带来的价值

8.2 这也带来风险

9. Memory Plugins：插件体系中的一个重点方向

plugins/memory/ 说明 Hermes 已经把“记忆后端”做成插件化能力。

当前可见的 memory plugin 包括：

9.1 Honcho

从 plugins/memory/honcho/README.md 看，Honcho 是高度 AI-native 的记忆后端：

它已经不是简单 KV memory，而是偏用户建模系统。

9.2 Supermemory

偏语义记忆服务：

9.3 Holographic

偏本地知识库型设计：

9.4 说明了什么

这说明 Hermes 的 memory 层不是“写死一个实现”，而是把记忆视为可插拔基础设施。

这是非常平台化的设计思路。

10. Gateway 系统：为什么它是 Hermes 的第二核心

如果不算 run_agent.py，我认为仓库里第二重要的系统就是 gateway/。

因为它决定了：

11. Gateway 的基本结构

关键文件：

工作流大致是：

平台消息入站
  -> 平台适配器解析 event
  -> gateway session 解析/构建 session_key
  -> 构造 AIAgent 或复用会话上下文
  -> AIAgent 运行
  -> 流式状态/工具进度/审批/提问回调
  -> 平台适配器格式化出站消息

12. Gateway 为什么复杂

因为它不是一个单纯 webhook 层，而是同时要处理：

所以 tests/gateway/ 数量非常多是合理的。

13. 平台适配器设计

gateway/platforms/base.py 是所有平台适配器的基类。

它提供的典型基础能力包括：

然后每个平台单独实现自己的协议细节。

当前可见平台包括：

这说明 Gateway 其实已经是一个“多协议消息操作系统”了。

14. Gateway 的核心价值

14.1 脱离本地终端

你不需要开着终端守着 Hermes。

可以：

14.2 将 Agent 变成“常驻服务”

CLI 更像前台工具。

Gateway 更像服务形态。

14.3 让 cron、send_message、memory 真正有价值

因为只有 Gateway 在，下面这些能力才真正形成闭环：

15. API Server 也是 Gateway 体系的一部分

gateway/platforms/api_server.py 特别值得注意。

它让 Hermes 可以对外表现成：

作用非常大：

这相当于把 Hermes 从“应用”变成“服务接口”。

16. Skills、Plugins、Gateway 三者的关系

可以这样理解：

Skills

回答：

“Agent 应该知道怎么做这件事吗？”

Plugins

回答：

“系统本身应该增加什么能力和扩展点？”

Gateway

回答：

“用户和外部平台怎样连接到这个 Agent？”

它们分别处在三个不同层：

17. 这三个系统的优点

Skills 的优点

Plugins 的优点

Gateway 的优点

18. 这三个系统的风险点

Skills 的风险

Plugins 的风险

Gateway 的风险

19. 我的结论

Hermes Agent 的强大，不只是因为它有很多工具，而是因为它同时做对了三件更难的事情：

  1. 用 Skills 沉淀“经验和流程”
  2. 用 Plugins 暴露“系统扩展点”
  3. 用 Gateway 把 Agent 送到“真实交互环境”

这三个系统叠加，才让 Hermes 从一个“能调工具的 LLM 应用”，变成一个“可长期演化的 Agent 平台”。

如果你后续要二开，这三个方向分别适合：

到此这篇关于Hermes Agent 的 Skills、Plugins、Gateway全解析的文章就介绍到这了,更多相关Hermes Agent 深度解析内容请搜索脚本之家以前的文章或继续浏览下面的相关文章，希望大家以后多多支持脚本之家！