hermes-memory-pgvector 是一个开源插件，为一组 hermes-agent 代理在 PostgreSQL 和 pgvector 上提供共享、持久化记忆。0.5.4 版本已发布到 PyPI，而且它完全没有任何新功能，也没有任何代码变更。下面解释为什么它仍然发布了。
一个没有任何代码的发布
v0.5.4 恰好只移动了两个依赖下限：
psycopg[binary]>=3.3.6,<4
psycopg-pool>=3.3.2,<4
这就是全部变更。上游在 2026 年 9 月 18 日发布了 psycopg 3.3.6 和 psycopg-pool 3.3.2，二者都是没有 API 变更的补丁版本。默认设置保持不变，没有迁移，插件自身源码也没有任何移动。
pool 修复就是原因
psycopg-pool 3.3.2 会在连接检查期间传播被取消以及其他基础异常。听起来像是个注脚，直到你看见这个插件是如何构建的。
它打开 一个 ConnectionPool，由代理线程和 async-writer drain 线程共享。在 pool 分配连接之前，它会检查连接是否仍然健康。如果该检查被中断——无论是取消、关闭，还是任何派生自 BaseException 而不是 Exception 的情况——旧行为可能会把它吞掉，而不是让它继续传播。原本应该明确失败的一次内存写入，反而会悄然消失。
对于一个职责就是绝不能丢失代理记忆的组件来说，静默是最糟糕的失败模式。仅凭这一条上游修复，就足以单独发一个版本。
3.3.6 还带来了什么
- 当服务器停止响应时，被取消的查询不再会永远等待。这一项需要 libpq 17 或更新版本——二进制 wheel 自带 libpq 18，所以它会生效，而不是闲置。
SystemExit时会取消正在运行的查询。这在 worker 在查询中途收到 SIGTERM 的那一刻就很重要：此前即使进程已经在退出途中，语句仍可能继续在服务器端运行。- 在
DEALLOCATE ALL之后，已准备语句会被丢弃，这样当某些操作在 checkout 之间重新发出DISCARD时，就能避免“prepared statement does not exist”的意外。 - 更低的 async-wait 开销，以及对 Python 3.15 的支持。
这个 pin 分布在四处，而且这是有意为之
psycopg 依赖出现在 pyproject.toml、hermes_pgvector/plugin.yaml、scripts/install.sh，以及 README 中打印的安装命令里。这四处在本次发布中一起移动，这并不是琐碎的维护细节。
9 月 7 日的一次全代码库审查发现，README 和安装脚本仍然固定在 >=3.3.4，而 pyproject.toml 已经移动到了 >=3.3.5。任何按文档安装路径操作的人，拿到的正是上一版本来就是为了移开的那个版本。这个漂移整整持续了一个发布周期，却没人注意到。
所以现在的规则是：这四处每次都必须一起移动，否则这个版本就不发布。
升级
pip install -U hermes-memory-pgvector
没有迁移，没有配置变更，也不会有你能察觉到的行为差异——这正是像这样的发布的意义所在。
源码和完整的配置参考在 GitHub 上：