跳到主要内容

Hermes Agent v0.15.2 发布 —— pip 安装后，插件去哪了？

· 阅读需 4 分钟

这不是假设场景。从 v0.15.0 开始，如果你通过 pip（wheel 或 sdist）全新安装 Hermes Agent，内置插件会让你找不着。不到第二天有人发 issue 你都不会意识到这不是你的配置问题，而是打包脚本漏了东西。

Hermes Agent v0.15.2 封面

故事的起点：一个看不见的 bug​

Hermes Agent 的内置插件由 plugin.yaml 清单文件定义——每个插件一个 YAML，描述它的工具、触发条件和依赖。这些文件是插件的「身份证」：没有它们，加载器不知道哪些插件可用，更不知道该怎么启动它们。

之前的构建流程里，pyproject.toml 的 include 配置正确包含了这些清单文件。但某次重构后，打包配置和实际的 manifest 目录之间出现了一条裂缝：MANIFEST.in 没有同步更新，导致 wheel 和 sdist 两种打包格式都遗漏了 plugin.yaml。

注意，不是「某些插件坏了」，而是「所有内置插件的入口文件都不在包里」。有人通过源码安装（pip install -e .）正常——因为符号链接直接指向了源码目录里的 manifest；有人通过 hermes update 二进制升级正常——因为不经过 pip 打包路径。但如果你是从 PyPI 新鲜 pip install，你会得到一套没有身份证的插件系统。

fix 本身很简单，但打包的坑不简单​

修复内容就一行改动：在 MANIFEST.in 里把 plugin.yaml 文件所在的目录加进打包清单。PR 链接是 827f7f07，改动量 7 行。

但这个 bug 让我想起一个在 Python 项目里反复上演的模式：源码运行正常 vs 打包后运行正常，完全是两回事。pip install -e . 跑了一万遍的东西，第一次打 wheel 给用户就现原型。很多 Python 项目到 v1.0 了才第一次发现 MANIFEST.in 或 package_data 少了文件——不是没人用，是不在 CI 的测试路径里。

Hermes Agent 的这套插件系统是后来加上的（大概在 v0.13 时代引入），manifest 目录的规划也经历过几次调整。核心维护者 @outsourc-e 捕捉到这个遗漏并提交了修复——团队内部有专门的打包测试流程吗？大概率没有，因为 v0.15.0 到 v0.15.1 隔了不到 24 小时，两版都是密集 hotfix，打包验证不在热修复的检查清单里。这很正常，但不正常的是这种断裂隔了三四个补丁版本才被发现。

这意味着什么​

如果你这周 pip install hermes-agent 发现插件不工作，升级到 v0.15.2 后重新安装一次就能恢复。如果你是通过 curl | bash 安装的或 hermes update 升级的，这个 bug 根本碰不到你——这也是为什么它在 PyPI 上躺了几天才被报告。

事后看，这次问题暴露了一个更大的议题：Hermes 的打包配置正变得越来越复杂。它不只是一个 Python 包，它还捆绑了 Dashboard 前端（Node 构建产物）、MCP 服务器 manifest、插件清单、CI 管道产物、TUI 资源文件——MANIFEST.in 里要包含的东西越来越多。一套 MANIFEST.in + pyproject.toml 的 include 双轨制，迟早还会出类似的问题。

升级​

如果你当前版本是 v0.15.0 或 v0.15.1 并通过 pip 安装：

pip install --upgrade hermes-agent

或简便方式（推荐）：

hermes update

全新安装：

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

完整更新日志：GitHub Release

Gradually, then suddenly. 有些版本往前进，有些版本为将来能往前推进补了条路。

📢 关注我，获取最新开源更新日志和开发者工具动态。如果觉得这篇文章有用，欢迎转发给身边的开发者朋友。

#HermesAgent #打包陷阱 #开源工具 #Python #插件系统