Mémoire partagée pour les flottes d'agents : hermes-memory-pgvector
Lorsque vous exécutez plus d'un agent IA — une larve marketing, une larve de trading, une larve de réponse aux incidents — chacun a besoin de mémoire. L'outil de mémoire intégré donne à chaque agent sa propre mémoire. C'est acceptable jusqu'à ce que vous souhaitiez qu'ils la partagent, ou jusqu'à ce que vous souhaitiez vous rappeler ce que l'agent a appris il y a six semaines sans payer un aller-retour LLM juste pour le consulter.
hermes-memory-pgvector est un petit plugin Postgres + pgvector qui réplique les écritures mémoire des agents dans un magasin partagé, embarqué et interrogeable. Version actuelle sur PyPI : v1.0.0.
Nouveau dans v1.0.0 — une surface stable
1.0.0 déclare la surface publique stable sous versionnage sémantique : clés de configuration, noms d'outils, commandes CLI et codes de sortie, et noms de tables. Cette version est publiée après une revue pré-version en plusieurs passes qui a corrigé un bug de perte de données et un ensemble de problèmes mineurs, sans changement de schéma depuis 0.6.0. Depuis v0.5.0, un simple pip install enregistre le fournisseur via un point d'entrée, donc la shim de découverte décrite ci-dessous n'est nécessaire que sur les hôtes plus anciens. Détails : hermes-memory-pgvector 1.0 : une surface mémoire stable.
Nouveau dans v0.4.2 — installation pip native
hermes-agent découvre les fournisseurs de mémoire en scannant les répertoires de plugins (plugins/memory/<name>/ intégré, $HERMES_HOME/plugins/<name>/ utilisateur) — il ne regarde jamais dans site-packages, donc un simple pip install laissait le plugin correctement installé et totalement invisible. v0.4.2 comble cette lacune : pip install installe le code sur la machine, et une commande hermes-pgvector install génère la shim de découverte que le framework lit réellement.
Nouveau dans v0.4.1 — rappel hybride (vecteur + texte intégral)
recall_memory et recall_conversation fusionnent désormais le classement cosinus HNSW avec un classement full-text PostgreSQL via Reciprocal Rank Fusion (k=60). Une ligne remonte si l'un ou l'autre classifieur l'apprécie, ce qui corrige les deux angles morts de la recherche vectorielle pure : les correspondances lexicales exactes que le cosinus lisse (codes d'erreur, noms d'hôtes, flags, identifiants rares), et les lignes purement textuelles avec un embedding NULL — écrites pendant que le point d'entrée d'embedding était en panne — que l'index vectoriel ne peut pas voir du tout. Le rappel hybride sert aussi de récupération best-effort pour ces lignes jusqu'à la prochaine exécution de backfill.
Ce qu'a ajouté v0.4.0
Cette version a conservé la règle « pas de LLM dans le chemin critique » et ajouté quatre capacités au niveau de la couche de stockage :
- Gouvernance d'identité. Les clés de session de messages directs se replient dans un compartiment unique respectueux de la vie privée — pas d'éparpillement de thèmes par contact, pas de PII — le trafic de benchmark est mis en quarantaine, et une liste d'autorisation optionnelle redirige les noms de thèmes mal orthographiés vers une valeur sûre au lieu de créer silencieusement un nouveau thème.
- Attribution et délégation d'agents. Un nouveau registre et des arêtes de provenance enregistrent quel agent a délégué quoi à qui, interrogeables via une vue de base de données. Pure provenance qui/quand — jamais un magasin de faits.
- Remplissage des embeddings. Les lignes écrites en texte seul pendant une panne du point d'entrée d'embedding ne sont plus orphelines : une commande idempotente les ré-embedde pour qu'elles redeviennent recherchables.
- TTL de conversation et contrôles de coût. Un élagage exécuté par l'opérateur supprime les anciens tours de conversation (les souvenirs durables ne sont jamais touchés), et une politique d'embedding ajuste le coût d'embedding à la hausse ou à la baisse.
Tout cela est livré derrière une CLI de maintenance (hermes-pgvector) dont les commandes destructives sont en dry-run par défaut. La ligne 0.4.x est une mise à niveau drop-in depuis v0.3.x — appliquez les migrations additives et les nouveaux hooks s'activent ; sautez-les et tout le reste fonctionne sans changement.
Ce qu'il fait réellement
En une phrase : « une couche de stockage qui offre au modèle de mémoire intégré un backing durable, multi-locataire et interrogeable sémantiquement, sans LLM dans le chemin critique. »
Deux tables, toutes deux avec des index vectoriels HNSW. memory_entries réplique les écritures vers les fichiers MEMORY.md/USER.md de l'agent. conversations stocke les tours de conversation substantiels (≥40 caractères, éléments passe-partout filtrés). Les embeddings sont en 768 dimensions, calculés par un point d'entrée externe — Ollama, compatible OpenAI, au choix. L'agent ne bloque jamais dessus : les écritures reviennent en microsecondes et le worker d'embedding s'occupe du reste sur une file d'arrière-plan.
Thèmes par agent par défaut
Chaque requête transporte un en-tête X-Hermes-Session-Key qui scope les données par agent_identity. Les notes du marketing ne polluent pas le rappel du trading. Lorsque vous souhaitez réellement une recherche inter-thèmes, passez explicitement scope='all'. La valeur par défaut est la plus sûre.
Pourquoi autonome, pas un fork
hermes-agent a fermé sa liste de fournisseurs de mémoire intégrés par politique, donc cela vit comme un scan de répertoire /plugins séparé plutôt que comme un fork amont. Déposez-le à côté de l'agent, définissez quelques clés de configuration, redémarrez. Le rollback est symétrique : désactivez le fournisseur, supprimez éventuellement les tables. Pas d'état de longue durée à migrer, pas de patches noyau à maintenir.
Ce que ce n'est pas
Pas un remplacement de Honcho. Pas un graphe de connaissances. Pas un framework RAG. C'est volontairement une couche fine qui fait une seule chose — transformer l'outil de mémoire intégré en un magasin partagé, durable et interrogeable vectoriellement — et s'efface. Pas de dériveur LLM, pas de boucle dialectique, pas d'opinion sur la façon dont vous devriez découper ou reclasser. Juste des maths vectorielles.
Récupérez-le
pip install hermes-memory-pgvector
hermes-pgvector install
Code source, migration et configuration sur GitHub :