hermes-memory-pgvector は、hermes-agent のエージェント群に PostgreSQL と pgvector 上で共有される永続的なメモリを提供するオープンソースのプラグインです。バージョン 0.5.4 が PyPI に公開され、新機能もコード変更も一切含まれていません。それでもリリースされた理由は次のとおりです。
コードの入っていないリリース
v0.5.4 で変更された依存関係の下限は、ちょうど 2 つです。
psycopg[binary]>=3.3.6,<4
psycopg-pool>=3.3.2,<4
変更はこれだけです。上流では psycopg 3.3.6 と psycopg-pool 3.3.2 が 2026年9月18日に公開され、どちらも API 変更のないパッチリリースでした。デフォルトはそのままで、移行作業はなく、プラグイン自身のソースにも動きはありません。
プール修正が理由です
psycopg-pool 3.3.2 は、接続チェック中に発生したキャンセルやその他の base exception を伝播します。これは、このプラグインがどのように作られているかを見るまで、脚注のように聞こえるかもしれません。
このプラグインは、エージェントスレッドと async-writer の drain スレッドで共有される 1つの ConnectionPool を開きます。プールが接続を払い出す前に、その接続がまだ正常かどうかを確認します。そのチェックが中断された場合 — キャンセル、シャットダウン、Exception ではなく BaseException に由来する何か — 以前の挙動では、それを通す代わりに飲み込んでしまうことがありました。本来は明確に失敗すべきメモリ書き込みが、静かに消えてしまうのです。
エージェントが覚えているものを失わないことが役目のコンポーネントにとって、静かな失敗は最悪の失敗モードです。この上流の単一修正だけでも、リリースする価値があります。
3.3.6 のその他の改善点
- サーバーが応答を停止したとき、キャンセルされたクエリが永久に待ち続けなくなりました。これには libpq 17 以降が必要です — バイナリ wheel には libpq 18 が含まれているため、待機したままではなく実際に有効になります。
- 実行中のクエリは
SystemExitでキャンセルされます。ワーカーがクエリの途中で SIGTERM を受けた瞬間に意味を持ちます: 以前は、プロセスがすでに終了に向かっていても、ステートメントがサーバー側で動き続けることがありました。 DEALLOCATE ALLでプリペアドステートメントが破棄されるため、checkout の間に何かがDISCARDを再実行したときに "prepared statement does not exist" が突然出るのを避けられます。- 非同期待機のオーバーヘッドが低減し、Python 3.15 に対応しました。
このピンは 4 か所にあり、それは意図的です
psycopg の要件は pyproject.toml、hermes_pgvector/plugin.yaml、scripts/install.sh、そして README に出力されるインストールコマンドにあります。このリリースでは 4 か所すべてが同時に動いており、それは単なる管理上の細則ではありません。
9月7日のコードベース全体のレビューで、README と install スクリプトがまだ >=3.3.4 に固定されていた一方で、pyproject.toml はすでに >=3.3.5 に移っていることが見つかりました。ドキュメントどおりのインストール手順に従う人は、前回のリリースが回避しようとしていたまさにそのバージョンを渡されていたのです。そのずれは、誰にも気づかれないまま 1 回分のリリースサイクルを生き延びていました。
したがって、今のルールは、4 か所が毎回 1 つとして動くこと、さもなければリリースは出さない、です。
アップグレード
pip install -U hermes-memory-pgvector
移行作業も、設定変更も、気づくような挙動の違いもありません — まさにこの種のリリースの目的はそこにあります。
ソースと完全な設定リファレンスは GitHub にあります: