95% 的人不知道插件和 skill 的区别，大白话一文讲清楚如何更高效

Hermes 最近这些功能看下来，我觉得有一个问题特别值得单独拎出来讲：Plugin（插件）和 Skill（技能）到底有什么区别。

这个问题看起来像技术细节，实际影响很大。因为很多人一遇到新需求，就习惯性想“我是不是该写个 Skill”。整理资料写 Skill，调接口也写 Skill，接内部系统还想写 Skill，最后 Skill 文件越堆越多，Agent（智能体）每次都读一堆说明，却还是不知道什么时候该调用真实工具。

Hermes 官方文档其实把边界说得很清楚：Skill 更适合用说明、流程、命令和现有工具来表达能力；Plugin 更适合增加自定义工具、Hook（钩子）、集成和更稳定的执行逻辑。换成大白话，Skill 像一份操作手册，Plugin 像给 Hermes 装了一个新按钮和新接口。

这篇不讲复杂开发，只讲怎么判断。先把边界分清，后面装 Skill、写 Skill、做 Plugin，都会少走弯路。

先记住一句话：Skill 教它怎么做，Plugin 给它新的手

Skill 的核心是“教”。比如你希望 Hermes 下次遇到接口报错时，不要瞎猜，而是先看状态码、再复现 curl、再检查鉴权、再看返回体。这个流程完全可以写进 Skill。它不一定要新增底层能力，只是让 Hermes 按更靠谱的顺序做事。

Plugin 的核心是“接”。比如你想让 Hermes 查公司内部订单系统、调用一套自己的 API、监听某个事件、给每次工具调用打日志、把某个命令变成 Hermes 原生子命令。这时只写一段说明就不够了，因为它需要稳定执行代码、处理认证、返回结构化结果。

可以这么理解：Skill 更像“工作方法”，Plugin 更像“工具接口”。工作方法可以写得灵活一点，工具接口必须跑得准一点。

问题

更像 Skill

更像 Plugin

它主要是在教 Hermes 做事吗？

是。比如流程、检查表、判断标准、常见坑。

不是。它需要新增可调用工具或稳定代码。

能不能靠现有终端命令完成？

能。Skill 可以告诉 Hermes 跑什么命令、看什么结果。

不能。需要封装 API、认证、回调、事件处理。

失败后能不能让人看懂并手动修？

通常可以。Skill 失败多半是流程没写清楚。

不一定。Plugin 失败可能是代码、依赖、权限、密钥问题。

适合分享给别人直接改吗？

适合。别人看 SKILL.md 就能理解思路。

要谨慎。涉及代码执行和密钥，安装前更要审查。

什么时候用 Skill：把经验沉淀下来就够了

Hermes 的 Skill 文件通常围绕 SKILL.md 展开。官方文档里给的结构很清楚：什么时候使用、快速参考、执行步骤、常见坑、验证方法。刚接触的朋友可以把它理解成一份给 Agent 看的 SOP（标准操作流程）。

最适合写成 Skill 的，是这几类东西。

第一，重复出现的流程。比如每次检查 API（接口）都要先确认地址、请求方法、鉴权、参数、返回体；每次做发布前检查都要看测试、构建、版本号和回滚方案。

第二，容易忘的判断标准。比如什么情况算接口跑通，什么情况只是“没报错但其实没成功”；什么文件能改，什么文件必须先问人。

第三，依赖现有工具的工作。比如调用命令行、读本地文件、跑已有脚本、整理报告。Hermes 文档里也提到，如果能力可以用 instructions（说明）+ shell commands（终端命令）+ existing tools（已有工具）表达，通常更适合做 Skill。

第四，适合给团队复用的经验。比如公司里某个项目的排查顺序、接口命名习惯、测试约定、代码审查清单。这些内容写成 Plugin 反而重，写成 Skill 刚好。

hermes skills browse --source officialhermes skills search dockerhermes skills inspect official/devops/pinggy-tunnelhermes skills install official/devops/pinggy-tunnel

这里有个小提醒：Skill 不是越多越好。装之前先 inspect（检查）一下，看它到底会让 Agent 做什么、需要什么环境变量、适合哪个系统。能用一句话讲清楚使用场景的 Skill，通常更值得留下。

什么时候用 Plugin：需要新增真实能力，就别硬塞进 Skill

Plugin 就不一样了。Hermes 官方文档说，Plugin 可以添加 custom tools（自定义工具）、hooks（钩子）、slash commands（斜杠命令）、CLI subcommands（命令行子命令）和 integrations（集成），不用改 Hermes 核心代码。

这句话听起来有点开发者味，翻成使用场景就简单多了。

比如你希望 Hermes 多一个“查库存”的工具，输入商品编号，它能稳定返回库存、仓库、更新时间。这个不适合只写进 Skill，因为你不希望 Agent 每次自己拼 curl、自己猜字段、自己处理错误。更好的做法是做一个 Plugin，把查库存封装成一个工具。

再比如你想记录每一次工具调用，或者在每次调用前做权限检查，这就更像 Hook（钩子）。Skill 只能提醒 Agent 小心，Plugin 才能在事件发生时真正拦一下、记一下、改一下。

Hermes 的 Plugin 目录结构也很直观：

~/.hermes/plugins/my-plugin/├── plugin.yaml├── __init__.py├── schemas.py└── tools.py

plugin.yaml 像插件的说明牌，告诉 Hermes 这是什么插件；schemas.py 描述模型能看到的工具参数；tools.py 写真正执行的逻辑；__init__.py 负责把这些能力注册进去。

更关键的是，Hermes 的第三方 Plugin 默认不是闭眼启用。文档里写得很明确：用户安装的通用插件默认是 disabled（未启用），需要加到 plugins.enabled 或手动 enable（启用），这样可以避免第三方代码在你不知情的情况下运行。

hermes plugins listhermes plugins install user/repo --no-enablehermes plugins enable my-pluginhermes plugins disable my-pluginhermes plugins remove my-plugin

所以 Plugin 更强，但也更重。它不是“写一段提示词”，而是往 Hermes 里加一块可执行能力。越强的东西，越要先看来源、权限、依赖和密钥。

一个具体判断：公司流程用 Skill，公司系统用 Plugin

这句话很适合直接拿来用。

如果你只是想让 Hermes 以后按公司流程办事，比如“收到客户需求后先整理字段、再列风险、再生成报价初稿、最后给出待确认项”，这就是 Skill。

如果你想让 Hermes 真的去客户管理系统里查客户状态、查历史报价、查合同文件、写入跟进记录，那就更接近 Plugin。因为这里已经涉及真实系统、API Key（接口密钥）、权限、字段校验和失败处理。

你想做的事

优先选择

原因

让 Hermes 记住一套排查流程

Skill

核心是经验和步骤，不需要新增工具。

让 Hermes 调用内部订单 API

Plugin

涉及认证、字段、错误处理，最好封装成工具。

让 Hermes 每次执行后自动写日志

Plugin

这属于事件钩子，不适合靠提醒完成。

让 Hermes 按固定模板写周报

Skill

流程和格式更重要，现有工具够用。

让 Hermes 新增一个本地命令子功能

Plugin

需要注册命令和执行逻辑。

让 Hermes 学会一个项目的验收标准

Skill

验收标准是知识和规则，适合沉淀成文档。

这样判断会省很多事。别把所有东西都塞进 Skill，也别一遇到问题就做 Plugin。Skill 轻，Plugin 稳。轻的东西适合沉淀经验，稳的东西适合接真实能力。

适合谁，不适合谁，要分清

这篇内容适合三类读者。

第一，已经用 Hermes，但 Skill 越装越多的人。你需要先清理一下：哪些只是一次性提示，哪些值得留下，哪些其实应该变成 Plugin。

第二，想把 Hermes 接进自己工作流的人。如果只是本地整理资料，Skill 足够；如果要接公司系统、内部接口、团队工具，就要开始理解 Plugin。

第三，准备给团队做工具包的人。团队协作最怕“每个人复制一段不同提示词”。能沉淀成 Skill 的沉淀成 Skill，必须稳定执行的封装成 Plugin，后面维护成本会低很多。

不太适合的情况也有。

如果你只是偶尔和 Hermes 聊天，不改文件、不跑命令、不接外部工具，那不用急着研究 Plugin。如果你还没搞清楚本机权限和 API Key（接口密钥），也别急着装第三方 Plugin。它比 Skill 更接近代码执行，越不熟悉越要慢一点。

装之前先做 4 个检查

无论 Skill 还是 Plugin，我都建议先做一遍简单检查。

首先，看它解决的是流程问题，还是能力问题。流程问题优先 Skill，能力问题再考虑 Plugin。

其次，看它会不会执行代码。只读说明和可执行脚本不是一个风险级别。Skill 里如果带脚本，也要看脚本做什么。

第三，看它要不要密钥和账号。只要涉及 API Key（接口密钥）、OAuth（授权登录）、服务账号文件，就不要随手装进真实环境。

第四，看它能不能卸载、禁用、复现。Hermes 的 Plugin 有 list、enable、disable、remove 这些命令，先知道退路，再决定要不要启用。

# 看插件状态hermes plugins list# 安装但先不启用hermes plugins install user/repo --no-enable# 确认后再启用hermes plugins enable my-plugin# 不放心就停掉hermes plugins disable my-plugin

刚接触的朋友可以记住一个保守策略：Skill 可以先读再装，Plugin 可以先装不启用。这样不会因为一时好奇，把一堆第三方能力直接放进工作区。

最后给一段最省心的判断法

以后看到一个需求，不用纠结半天。按这 5 句话判断就行。

第一，如果它只是教 Hermes 按顺序做事，用 Skill。

第二，如果它只是保存某个项目的经验、模板、检查表，用 Skill。

第三，如果它需要新增一个稳定可调用的工具，用 Plugin。

第四，如果它涉及认证、事件、钩子、后台逻辑、真实系统，优先考虑 Plugin。

结论：Skill 负责“怎么做”，Plugin 负责“能做什么”。先把这句话想明白，Hermes 才不会越用越乱。

我的建议很简单：刚开始多用 Skill，少碰 Plugin；等你发现某个流程已经稳定、某个工具必须反复调用，再把它升级成 Plugin。这样既不会一上来过度开发，也不会把真正需要工程化的东西硬塞进一份说明文档里。