Mémoire partagée pour des flottes d’agents : hermes-memory-pgvector
Lorsque vous exécutez plus d’un agent IA — un minion marketing, un minion de trading, un minion de réponse aux incidents — chacun a besoin d’une mémoire. L’outil de mémoire intégré donne à chaque agent la sienne. C’est bien jusqu’à ce que vous vouliez qu’ils la partagent, ou jusqu’à ce que vous vouliez retrouver ce que l’agent a appris il y a six semaines sans payer un aller-retour LLM juste pour aller le rechercher.
hermes-memory-pgvector est un petit plugin Postgres + pgvector qui réplique les écritures de mémoire des agents dans un magasin partagé, intégré et interrogeable. Publié sur PyPI en v0.4.2.
Nouveautés de v0.4.2 — installation native via pip
hermes-agent découvre les fournisseurs de mémoire en parcourant les répertoires de plugin (plugins/memory/<name>/ intégré, $HERMES_HOME/plugins/<name>/ utilisateur) — il ne regarde jamais dans site-packages, donc pip install seul laissait le plugin correctement installé et complètement invisible. v0.4.2 comble cette lacune : pip install place le code sur la machine, et une commande hermes-pgvector install génère le shim de découverte que le framework lit réellement.
Nouveautés de v0.4.1 — rappel hybride (vectoriel + plein texte)
recall_memory et recall_conversation fusionnent désormais le classement cosinus HNSW avec un classement plein texte PostgreSQL à l’aide de Reciprocal Rank Fusion (k=60). Une ligne remonte si l’un ou l’autre des classeurs 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ôte, drapeaux, identifiants rares), et les lignes texte uniquement avec un NULL embedding — écrites pendant que le point de terminaison d’embed était hors service — que l’index vectoriel ne peut pas voir du tout. Le rappel hybride sert aussi de récupération au mieux 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 a ajouté quatre capacités au niveau du stockage :
- Gouvernance des identités. Les clés de session de message direct se regroupent dans un seul compartiment sûr pour la vie privée — pas de prolifération de thèmes par contact, pas de PII — le trafic de benchmark est mis en quarantaine, et une allow-list optionnelle redirige les noms de thème mal saisis vers un défaut sûr au lieu de créer silencieusement un nouveau thème.
- Attribution et délégation des 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. Une provenance purement qui/quand — jamais un magasin de faits.
- Backfill des embeddings. Les lignes écrites en texte seul pendant une panne du point de terminaison d’embedding ne restent plus bloquées : une commande idempotente les ré-encode pour qu’elles redeviennent recherchables.
- TTL des conversations et contrôle des coûts. Une purge lancée par l’opérateur réduit les anciens tours de chat (les mémoires durables ne sont jamais touchées), et une politique d’embedding ajuste le coût d’embedding à la hausse ou à la baisse.
Le tout est livré derrière une CLI de maintenance (hermes-pgvector) dont les commandes destructrices sont par défaut en mode dry-run. La série 0.4.x est une mise à niveau directe depuis v0.3.x — appliquez les migrations additives et les nouveaux hooks s’activent ; sautez-les et tout le reste s’exécute sans changement.
Ce que cela fait réellement
En une ligne : « une couche de stockage qui donne au modèle de mémoire intégré une base 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 chat substantiels (≥40 caractères, avec filtrage du texte générique). Les embeddings sont en 768 dimensions, calculés par un point de terminaison externe — Ollama, compatible OpenAI, à vous de choisir. L’agent n’attend jamais dessus : les écritures reviennent en microsecondes et le worker d’embedding gère le reste dans une file d’attente en arrière-plan.
Thèmes par agent par défaut
Chaque requête transporte un en-tête X-Hermes-Session-Key qui limite les données par agent_identity. Les notes du marketing ne polluent pas le rappel du trading. Lorsque vous voulez réellement une recherche inter-thèmes, passez explicitement scope='all'. Le défaut est le plus sûr.
Pourquoi un module autonome, et non un fork
hermes-agent a fermé sa liste intégrée de fournisseurs de mémoire pour des raisons de politique, donc cela vit comme un balayage séparé du répertoire /plugins plutôt que comme un fork en amont. Déposez-le à côté de l’agent, définissez quelques clés de configuration, redémarrez. Le retour arrière est symétrique : désactivez le fournisseur, supprimez éventuellement les tables. Pas d’état à long terme à migrer, pas de correctifs du noyau à maintenir.
Ce que ce n’est pas
Pas un remplacement de Honcho. Pas un graphe de connaissances. Pas un framework RAG. C’est intentionnellement une couche mince qui fait une seule chose — transformer l’outil de mémoire intégré en un magasin partagé, durable et interrogeable vectoriellement — puis se met de côté. Pas de dériveur LLM, pas de boucle dialectique, pas d’avis sur la façon dont vous devriez fragmenter ou reranker. Juste des maths vectorielles.
Obtenez-le
pip install hermes-memory-pgvector
hermes-pgvector install
Source, migration et configuration sur GitHub :