Hermes Agent 的 Skills、Plugins、Gateway 深度解析1. 为什么要单独分析这三个系统如果说run_agent.py是“Agent 大脑主循环”tools/是“执行能力层”那么skills/是“可复用经验层”plugins/是“扩展机制层”gateway/是“外部接入层”这三者决定了 Hermes Agent 为什么不是一个封闭单体而是一个可以持续扩展、接入多生态、多平台、多工作流的系统。2. Skills 系统它本质上是什么Skills 不是 Python 插件也不是代码模块。它本质上是一种面向 Agent 的、按需加载的知识文档/工作流文档系统。它解决的问题是有些能力不需要写成工具代码但又不适合每次都把完整说明塞进 system prompt于是 Hermes 采用了技能机制平时只给模型一个技能索引需要时再加载具体 skill 内容skill 可以带 references、templates、scripts、assets这就是文档里所谓的 progressive disclosure。3. Skills 的核心设计3.1 数据结构典型技能目录结构skill-name/ SKILL.md references/ templates/ scripts/ assets/SKILL.md是核心。它一般包含frontmatter使用条件操作步骤常见坑验证方法3.2 技能发现与索引相关关键位置agent/skill_commands.pyagent/skill_utils.pytools/skills_tool.pytools/skills_hub.pyhermes_cli/skills_hub.py工作方式大致是扫描本地技能目录解析SKILL.mdfrontmatter生成 skill 索引将 skill 映射为 slash command在需要时通过skill_view加载完整内容3.3 技能的“按需加载”文档中给出了 3 层加载模式skills_list()只看索引skill_view(name)加载某个技能主内容skill_view(name, path)加载技能附属文件这种设计的价值非常大节省 token降低默认 system prompt 膨胀让技能数量可以扩展得很大4. Skills 的运行方式4.1 Skill 可以像 slash command 一样使用例如/plan/github-pr-workflow/gif-search说明 skill 在用户感知层像“命令”但底层其实是文档型能力加载。4.2 Skill 也可以在自然对话中被调用这说明 skill 不是强依赖显式 slash command 的而是 Agent 可主动发现和装载。4.3 Skill 可以有条件显示文档明确支持platformsfallback_for_toolsetsrequires_toolsetsfallback_for_toolsrequires_tools这意味着 skill 系统已经不是简单文件夹扫描而是具备运行时条件装配能力。5. Skills Hub技能生态层tools/skills_hub.py和hermes_cli/skills_hub.py说明 Hermes 还做了一个更进一步的事情把 skills 做成可安装、可搜索、可审计、可隔离来源的生态系统。它支持的内容包括官方 optional skillsGitHub skill sourcelock filequarantineaudit logtapsindex cache这已经非常接近包管理器思路。5.1 为什么这很重要因为 skill 一旦规模变大用户就不可能只靠仓库自带内容需要外部来源需要 provenance需要审计需要缓存需要信任等级Hermes 已经显式意识到了这一点。6. Plugins 系统它和 Skills 的区别这是很多人第一次看仓库时最容易混淆的点。Skill更偏知识/流程通常是 Markdown 附属文件给 Agent 提示和流程指导不直接修改 Hermes 核心执行逻辑Plugin是真正的程序级扩展能注册 hook能注册 tool能注册 CLI 子命令能注册 slash command甚至能替换 context engine所以Skill 是“给模型看的能力文档”Plugin 是“给系统加能力的代码扩展”。7. Plugins 系统怎么工作关键文件hermes_cli/plugins.py它明确写了三种插件来源用户插件~/.hermes/plugins/name/项目插件./.hermes/plugins/name/pip entrypoint 插件hermes_agent.plugins7.1 一个插件需要什么目录型插件至少要有plugin.yaml__init__.pyregister(ctx)函数7.2 插件能做什么从PluginContext看插件至少可以register_tool(...)register_cli_command(...)register_command(...)dispatch_tool(...)inject_message(...)register_context_engine(...)这意味着插件能力很强几乎能插进系统多个层面。8. Plugin Hooks生命周期插点VALID_HOOKS目前包括pre_tool_callpost_tool_callpre_llm_callpost_llm_callpre_api_requestpost_api_requeston_session_starton_session_endon_session_finalizeon_session_reset这说明插件机制不是“只支持加载工具”而是真正支持生命周期扩展。8.1 这带来的价值可以监控工具调用可以附加上下文可以做审计可以做自定义日志/遥测可以做会话前后处理8.2 这也带来风险Hook 太强调试复杂度会上升插件之间可能发生行为冲突对时序的依赖会增大9. Memory Plugins插件体系中的一个重点方向plugins/memory/说明 Hermes 已经把“记忆后端”做成插件化能力。当前可见的 memory plugin 包括honchosupermemoryholographicmem0openvikingretaindbhindsightbyterover9.1 Honcho从plugins/memory/honcho/README.md看Honcho 是高度 AI-native 的记忆后端双层上下文注入dialectic reasoningsession summaryuser / AI peer modelcadence 控制它已经不是简单 KV memory而是偏用户建模系统。9.2 Supermemory偏语义记忆服务semantic searchprofile recallexplicit memory toolssession-end ingest9.3 Holographic偏本地知识库型设计SQLiteFTS5trust scoringentity resolutionHRR retrieval9.4 说明了什么这说明 Hermes 的 memory 层不是“写死一个实现”而是把记忆视为可插拔基础设施。这是非常平台化的设计思路。10. Gateway 系统为什么它是 Hermes 的第二核心如果不算run_agent.py我认为仓库里第二重要的系统就是gateway/。因为它决定了Hermes 能否脱离本地终端使用Hermes 能否成为常驻机器人Hermes 能否跨平台连续对话Hermes 能否把 cron、memory、tool、session 这些能力带到外部世界11. Gateway 的基本结构关键文件gateway/run.pygateway/config.pygateway/session.pygateway/delivery.pygateway/platforms/base.pygateway/platforms/*.py工作流大致是平台消息入站 - 平台适配器解析 event - gateway session 解析/构建 session_key - 构造 AIAgent 或复用会话上下文 - AIAgent 运行 - 流式状态/工具进度/审批/提问回调 - 平台适配器格式化出站消息12. Gateway 为什么复杂因为它不是一个单纯 webhook 层而是同时要处理多平台差异会话边界多用户/群组/线程中断和排队背景进程通知语音/图片/附件审批流session routingrestart/drainplatform reconnect所以tests/gateway/数量非常多是合理的。13. 平台适配器设计gateway/platforms/base.py是所有平台适配器的基类。它提供的典型基础能力包括消息截断/编码长度处理代理/网络处理平台共通发送接口抽象背景消息与媒体处理辅助然后每个平台单独实现自己的协议细节。当前可见平台包括TelegramDiscordSlackWhatsAppSignalMatrixMattermostEmailDingtalkFeishuWeComWeixinwebhookHome AssistantAPI server这说明 Gateway 其实已经是一个“多协议消息操作系统”了。14. Gateway 的核心价值14.1 脱离本地终端你不需要开着终端守着 Hermes。可以在 Telegram 上问它在 Discord 上继续同一个 Agent让它在远程机器上工作14.2 将 Agent 变成“常驻服务”CLI 更像前台工具。Gateway 更像服务形态。14.3 让 cron、send_message、memory 真正有价值因为只有 Gateway 在下面这些能力才真正形成闭环定时任务完成后发消息后台进程完成后通知多渠道 home channelsession continuity15. API Server 也是 Gateway 体系的一部分gateway/platforms/api_server.py特别值得注意。它让 Hermes 可以对外表现成OpenAI Chat Completions APIOpenAI Responses API作用非常大Open WebUI、LobeChat、LibreChat 等前端可以直接接入第三方工具可以把 Hermes 当成“兼容 OpenAI 的 Agent Server”这相当于把 Hermes 从“应用”变成“服务接口”。16. Skills、Plugins、Gateway 三者的关系可以这样理解Skills回答“Agent 应该知道怎么做这件事吗”Plugins回答“系统本身应该增加什么能力和扩展点”Gateway回答“用户和外部平台怎样连接到这个 Agent”它们分别处在三个不同层Skills知识层Plugins系统扩展层Gateway交互接入层17. 这三个系统的优点Skills 的优点低成本扩展能力适合沉淀经验token 更经济易于社区共享Plugins 的优点可编程扩展强能注册工具和 hooks适合深度定制Gateway 的优点让 Hermes 真正成为多平台 Agent支持长期运行和远程交互把消息、自动化、通知、会话串联起来18. 这三个系统的风险点Skills 的风险skill 质量不均文档可能过时prompt injection 风险skill 数量膨胀后治理困难Plugins 的风险hook 冲突调试复杂权限边界更难控插件加载顺序与兼容性问题Gateway 的风险平台差异巨大行为开关多并发和状态同步复杂测试矩阵膨胀19. 我的结论Hermes Agent 的强大不只是因为它有很多工具而是因为它同时做对了三件更难的事情用 Skills 沉淀“经验和流程”用 Plugins 暴露“系统扩展点”用 Gateway 把 Agent 送到“真实交互环境”这三个系统叠加才让 Hermes 从一个“能调工具的 LLM 应用”变成一个“可长期演化的 Agent 平台”。如果你后续要二开这三个方向分别适合想快速增强业务知识优先看 Skills想深度改系统能力优先看 Plugins想做机器人/平台接入优先看 Gateway