hermes-memory-pgvector est le plugin open source qui fournit à une flotte d’agents hermes-agent une mémoire partagée et durable sur PostgreSQL et pgvector. La version 0.5.4 est disponible sur PyPI, et elle n’apporte aucune nouvelle fonctionnalité ni aucun changement de code. Voici pourquoi elle a quand même été publiée.
Une version sans code
v0.5.4 ne fait évoluer exactement que deux seuils minimums de dépendances :
psycopg[binary]>=3.3.6,<4
psycopg-pool>=3.3.2,<4
C’est là l’intégralité du changement. En amont, psycopg 3.3.6 et psycopg-pool 3.3.2 ont été publiés le 18 septembre 2026, deux versions de correctif sans changement d’API. Les valeurs par défaut restent inchangées, il n’y a aucune migration, et rien dans le propre code source du plugin n’a bougé.
Le correctif du pool est la raison
psycopg-pool 3.3.2 propage les annulations et autres exceptions de base levées pendant un contrôle de connexion. Cela ressemble à une note de bas de page jusqu’à ce que l’on regarde comment ce plugin est construit.
Il ouvre un ConnectionPool, partagé entre le thread de l’agent et le thread de vidage async-writer. Avant que le pool n’attribue une connexion, il vérifie que la connexion est toujours saine. Si ce contrôle est interrompu — une annulation, un arrêt, n’importe quoi dérivant de BaseException plutôt que de Exception — l’ancien comportement pouvait l’absorber au lieu de le laisser passer. Une écriture de mémoire qui aurait dû échouer bruyamment disparaît alors en silence.
Pour un composant dont la mission entière est de ne pas perdre ce dont un agent se souvient, le silence est le pire mode d’échec qui soit. Ce seul correctif en amont mérite à lui seul une version.
Ce que 3.3.6 apporte d’autre
- Une requête annulée n’attend plus indéfiniment lorsque le serveur a cessé de répondre. Cela nécessite libpq 17 ou plus récent — les roues binaires embarquent libpq 18, donc cela prend effet au lieu de rester dormant.
- La requête en cours est annulée sur
SystemExit. Cela compte dès qu’un worker reçoit un SIGTERM en plein milieu d’une requête : auparavant, l’instruction pouvait continuer à s’exécuter côté serveur alors même que le processus était déjà en train de quitter. - Les instructions préparées sont supprimées sur
DEALLOCATE ALL, ce qui évite les surprises du type « prepared statement does not exist » lorsque quelque chose réémetDISCARDentre deux récupérations. - Une surcharge plus faible lors de l’attente asynchrone, et la prise en charge de Python 3.15.
L’épinglage existe en quatre endroits, et c’est volontaire
La contrainte psycopg apparaît dans pyproject.toml, dans hermes_pgvector/plugin.yaml, dans scripts/install.sh, et dans la commande d’installation affichée dans le README. Les quatre ont évolué ensemble dans cette version, et ce n’est pas de la manie de rangement.
Un examen complet du code le 7 septembre a montré que le README et le script d’installation épinglaient toujours >=3.3.4 alors que pyproject.toml était déjà passé à >=3.3.5. Toute personne suivant le parcours d’installation documenté recevait exactement la version dont la version précédente était censée permettre la sortie. L’écart a survécu à tout un cycle de publication sans que personne ne le remarque.
La règle, désormais, est donc que les quatre avancent comme un seul ensemble, à chaque fois, sinon la version ne part pas.
Mise à niveau
pip install -U hermes-memory-pgvector
Aucune migration, aucun changement de configuration, aucune différence comportementale que vous remarquerez — ce qui est précisément l’objectif d’une version comme celle-ci.
La source et la référence complète de configuration sont sur GitHub :