Hermes 官方插件目录上线：终于不用再猜哪个插件靠谱了

想给 Hermes 装个社区插件时，你是不是也有过这样的纠结：GitHub 上搜出一堆名字相似的仓库，不知道哪个是官方维护的，哪个是个人写着玩的；README 吹得天花乱坠，可它到底会碰你哪些文件、调用哪些系统能力，装完才敢知道？装第三方代码本来就该谨慎——毕竟插件是直接跑在 Hermes 进程里的 Python 代码，相当于把一把钥匙交到了陌生人手里。

9 月 9 日合并的 PR #69446 就是冲着这个痛点来的：Hermes 官方上线了带人工审核的插件目录（plugin catalog），把“发现插件”和“信任插件”这两件事一起解决了。以后找插件不用再去 GitHub 大海捞针，hermes plugins search 一条命令就能搜官方维护的目录；装插件也不用再赌人品，因为每条目录记录都锁死了精确的 commit，还强制声明了插件的能力清单。

插件目录是什么

先厘清一个概念：这里的“插件”指的是跑在 Hermes 进程内部的原生插件（native plugin），也就是我们之前介绍过的、通过 plugins.entries 配置启用、可以注册自己的工具和钩子的那类扩展——不是 MCP 服务器目录里那种外部进程。MCP 目录解决的是“连外部服务”，插件目录解决的是“给 Hermes 本体加能力”，两者是不同层面的东西。

插件目录的实体是仓库里的一组 YAML 文件（plugin-catalog/ 目录），每个文件对应一个插件条目，包含：

name: hermes-telegram-business   # 目录里的唯一名字，安装时用这个名字
repo: https://github.com/NousResearch/hermes-telegram-business
sha: e905f3bc5eeaa5a9dab9bc5155601b3ebec75757  # 40 位完整 commit SHA
description: 一句话描述
maintainer: NousResearch
tier: official          # official（官方）或 community（社区）
platforms: []           # 留空表示全平台
capabilities:           # 能力声明：这个插件会注册哪些工具/钩子/中间件
  provides_tools: []
  provides_hooks: []
  provides_middleware: []
  requires_env: []

上线时目录里有 7 个种子条目：3 个官方（plugin-llm-example、plugin-llm-async-example、hermes-telegram-business）加 4 个社区（hermes-plugin-chrome-profiles、hermes-snapcompact、jackal-verified、herdr-auto-reconcile）。官方条目全部来自 NousResearch 自己的仓库，社区条目则来自独立开发者——比如 hermes-plugin-chrome-profiles 能让你在本地和远程 Chrome/Edge 配置文件之间切换浏览器工具，hermes-snapcompact 会把对话历史压成位图让视觉模型读取，token 成本大约只有原来的三分之一。

怎么搜索和安装：三条命令入门

发现和安装插件的核心命令是 hermes plugins 下的几个子命令。注意这个功能 9 月 9 日才合并进 main 分支，还没有进入任何正式发布版本（最新的 v0.21.1 发布于 9 月 7 日，不含此功能），想现在就用需要运行包含这次合并的开发版。

搜索整个目录——不带参数列出全部，带关键词则按名字、描述和能力匹配：

hermes plugins search
hermes plugins search telegram      # 搜名字/描述里带 telegram 的
hermes plugins search --json        # 机器可读输出，方便脚本处理

安装——直接写目录里的名字，或者写 Git 地址/owner-repo 简写都行：

hermes plugins install hermes-telegram-business   # 从目录装，自动锁定审核过的 SHA
hermes plugins install anpicasso/hermes-plugin-chrome-profiles  # owner/repo 简写 = 自定义来源
hermes plugins install https://github.com/xxx/my-plugin          # 完整 Git URL

关键区别在来源：命中目录的名字会安装审核过、锁死 SHA 的那个版本，装完还会在插件目录里写一个 .hermes-catalog.json 元数据文件记录来源；而用 Git URL 或 owner/repo 简写安装的会被明确标记为“自定义（未审核）来源”，命令会打出黄色警告。安装时还会询问是否启用——装好 ≠ 启用，启用前会先给你看这个插件的能力摘要，确认它要注册哪些工具再放行。

查看已装的插件：

hermes plugins list
hermes plugins list --plain          # 纯文本输出
hermes plugins show hermes-telegram-business   # 看单个插件的详细信息

信任模型：目录凭什么值得信

目录不是摆设，它的可信度来自一套环环相扣的机制，每一条都写在 plugin-catalog 的 README 里：

  • 人工合并门槛：条目只能通过向 hermes-agent 仓库提 PR 加入，由维护者审核合并。没有自助注册、没有自动收录，不存在“交了钱就能上目录”的通道。
  • 锁死精确 commit：每条记录必须写 40 位完整 SHA，分支名、标签、短 SHA 一律不认。安装时检出的是那个 commit，绝不是最新的 HEAD——所以目录里写的和你装到的，是同一份代码。
  • 固定 ≥2 周“观察期”：条目锁定的版本在收录时必须已经发布至少两周，给社区留出发现问题的窗口，防止官方指针刚指向一个第二天就被发现投毒的版本。
  • 升级 SHA 要重新走 PR：更新某个条目的锁定版本是新 PR，审核者会对比旧 SHA 到新 SHA 之间的提交范围。换句话说，任何指针的移动都有人类盯着。
  • 能力声明必须真实：hermes plugins validate 会在一个临时子进程里真实加载插件，把声明的 provides_tools/provides_hooks 和插件实际 register 的东西逐一比对，对不上就拒绝——防止插件偷偷多注册能力而不声明。收录 CI 对每个改动的条目都会跑这道验证。
  • 下架即拉黑：因安全或政策原因下架的插件会记进 removed.yaml，之后无论从哪个入口（CLI、桌面端、仪表盘）安装，只要名字或仓库命中黑名单就直接拒绝。想强行装？CLI 有 --allow-removed 开关，但会打出醒目的红色警告。

另外这个新目录还顺带解决了一个历史遗留问题：之前 Hermes 用的是临时社区插件索引，指向的官方仓库地址其实从来不存在，也没有收录门槛；这次合并把它整个移除，统一收编到仓库内的目录里。

验证与日常管理

装了插件之后，日常管理还有这些命令可用：

hermes plugins update hermes-telegram-business   # 目录条目：重新锁定到审核过的新 SHA
hermes plugins disable hermes-telegram-business  # 停用但不删除
hermes plugins enable hermes-telegram-business   # 重新启用
hermes plugins remove hermes-telegram-business   # 卸载（别名 rm / uninstall）
hermes plugins capabilities                      # 看每个插件声明 vs 已授予的能力

如果你是插件作者，想让自己写的插件进目录，hermes plugins validate <插件目录> 就是收录 CI 用的同一道校验，本地先跑通再提 PR；hermes plugins doctor 还能用真实运行时契约做更深的体检。目录本身通过文档站点的 JSON（/docs/api/plugin-catalog.json）自动刷新，客户端最多每 6 小时拉一次，离线时自动回退到仓库内置副本，不会因为网络问题装不了。

安全底线再说一遍：插件是跑在 Hermes 进程内的代码，目录的审核降低的是风险，不是归零。装上后仍然建议用 hermes plugins capabilities 定期看看它实际拿到了哪些权限。想知道插件机制本身怎么用、怎么自己写一个，可以回看我们之前写的 pip 模型供应商插件指南；把插件目录和 MCP 服务器目录 配合起来用，官方渠道基本能覆盖你日常八成以上的扩展需求。