エージェント群のための共有メモリ: hermes-memory-pgvector
1つ以上の AI エージェント — マーケティング用 minion、トレーディング用 minion、インシデント対応用 minion — を実行すると、それぞれにメモリが必要になります。標準のメモリツールは、各エージェントにそれぞれ専用のメモリを与えます。共有させたい場合や、LLM にただ問い合わせるためだけに往復コストを払わず、6週間前にエージェントが学習した内容を思い出したい場合までは、それで十分です。
hermes-memory-pgvector は、エージェントのメモリ書き込みを、共有され、埋め込み済みで、クエリ可能なストアに反映する、小さな Postgres + pgvector プラグインです。v0.4.2 として PyPI で公開されています。
v0.4.2 の新機能 — pip ネイティブインストール
hermes-agent はプラグイン ディレクトリ（同梱の plugins/memory/<name>/、ユーザー用の $HERMES_HOME/plugins/<name>/）を走査してメモリプロバイダーを見つけます — site-packages は決して見に行かないため、pip install だけではプラグインは正しくインストールされても完全に見えないままでした。v0.4.2 ではそのギャップを解消しました。pip install でコードをマシン上に配置し、1回の hermes-pgvector install コマンドで、フレームワークが実際に読み取るディスカバリー用 shim を生成します。
v0.4.1 の新機能 — ハイブリッドリコール（ベクトル + 全文）
recall_memory と recall_conversation は、HNSW のコサインランキングと PostgreSQL の全文ランキングを Reciprocal Rank Fusion（k=60）で統合するようになりました。どちらか一方のランキングが高く評価すれば行が表示されるため、純粋なベクトル検索の2つの盲点を解消します。つまり、コサインでは平滑化されてしまう完全一致の語彙ヒット（エラーコード、ホスト名、フラグ、まれな識別子）と、埋め込みエンドポイントが停止していた間に書き込まれた NULL 埋め込みのテキストのみの行で、ベクトルインデックスからはまったく見えないものです。ハイブリッドリコールは、次回の backfill 実行まで、そうした行を可能な限り復旧する手段としても機能します。
v0.4.0 で追加されたもの
そのリリースでも「ホットパスに LLM を置かない」というルールは維持しつつ、ストレージ層に4つの機能を追加しました。
- Identity governance. 直接メッセージのセッションキーは、プライバシーに配慮した単一のバケットにまとめられます — 連絡先ごとのテーマの乱立も PII もありません — ベンチマークトラフィックは隔離され、任意の allow-list により、タイプミスされたテーマ名は静かに新規作成されるのではなく安全なデフォルトにルーティングされます。
- Agent attribution & delegation. 新しい registry と provenance エッジが、どのエージェントが何を誰に委任したかを記録し、データベースビュー経由でクエリ可能にします。純粋な who/when の provenance であり、決して事実ストアではありません。
- Embedding backfill. 埋め込みエンドポイントの停止中にテキストのみで書き込まれた行は、もはや取り残されません。1回の冪等コマンドで再埋め込みし、再び検索可能にします。
- Conversation TTL & cost controls. オペレーターが実行する prune が古いチャットターンを整理し（永続メモリには決して触れません）、embed policy で埋め込みコストを増減できます。
これらすべてはメンテナンス用 CLI（hermes-pgvector）の背後で提供され、破壊的コマンドのデフォルトは dry-run です。0.4.x 系は v0.3.x からの差し替えアップグレードです。追加の migration を適用すれば新しい hooks が有効になり、適用しなくても他はすべて変更なしで動作します。
実際に何をするのか
一言で言えば、「組み込みメモリモデルに、耐久性があり、マルチテナント対応で、意味検索可能なバックエンドを、ホットパスに LLM を置かずに提供するストレージ層」 です。
2つのテーブルはいずれも HNSW ベクトルインデックスを持ちます。memory_entries はエージェントの MEMORY.md/USER.md ファイルへの書き込みをミラーします。conversations は実質的なチャットターン（40文字以上、定型文は除外）を保存します。埋め込みは 768 次元で、外部エンドポイントによって計算されます — Ollama、OpenAI 互換、どちらでも選べます。エージェントがそれで待たされることはありません。書き込みはマイクロ秒で返り、埋め込みワーカーが残りをバックグラウンドキューで処理します。
デフォルトではエージェントごとのテーマ
すべてのリクエストは X-Hermes-Session-Key ヘッダーを伴い、agent_identity ごとにデータをスコープします。マーケティングのメモがトレーディングのリコールを汚染することはありません。実際にテーマをまたいだ検索が必要な場合は、scope='all' を明示的に指定してください。デフォルトは安全側です。
なぜ fork ではなく独立版なのか
hermes-agent はポリシーにより組み込みのメモリプロバイダー一覧を閉じたため、これは upstream の fork ではなく、別個の /plugins ディレクトリ走査として存在します。エージェントの隣に置き、いくつかの config key を設定して再起動するだけです。ロールバックも対称的です。プロバイダーを無効化し、必要であればテーブルを削除します。移行すべき長寿命 state も、維持すべき kernel patch もありません。
何ではないか
Honcho の代替ではありません。knowledge graph でもありません。RAG framework でもありません。意図的に薄いレイヤーで、1つのことだけを行います — 組み込みメモリツールを、共有され、耐久性があり、ベクトル検索可能なストアに変換すること — そして邪魔をしません。LLM deriver も、dialectic loop も、どのように chunk したり rerank したりすべきかについての意見もありません。あるのはベクトル計算だけです。
入手する
pip install hermes-memory-pgvector
hermes-pgvector install
ソース、migration、config は GitHub にあります: