hermes-memory-pgvector ist das Open-Source-Plugin, das einem Verbund von hermes-agent-Agenten gemeinsamen, dauerhaften Speicher auf PostgreSQL und pgvector bereitstellt. Version 0.5.4 ist auf PyPI verfügbar, und sie enthält keinerlei neue Funktionen und überhaupt keine Code-Änderungen. Hier ist der Grund, warum sie trotzdem veröffentlicht wurde.
Eine Veröffentlichung ohne Code darin
v0.5.4 verschiebt genau zwei Abhängigkeitsuntergrenzen:
psycopg[binary]>=3.3.6,<4
psycopg-pool>=3.3.2,<4
Das ist die gesamte Änderung. Upstream hat psycopg 3.3.6 und psycopg-pool 3.3.2 am 18. September 2026 veröffentlicht, beides Patch-Releases ohne API-Änderungen. Die Standardwerte bleiben unverändert, es gibt keine Migration, und im eigenen Quellcode des Plugins wurde nichts geändert.
Der Pool-Fix ist der Grund
psycopg-pool 3.3.2 leitet Abbrüche und andere Basisausnahmen weiter, die während einer Verbindungsprüfung ausgelöst werden. Das klingt nach einer Fußnote, bis man sich ansieht, wie dieses Plugin aufgebaut ist.
Es öffnet einen ConnectionPool, der zwischen dem Agent-Thread und dem Async-Writer-Drain-Thread gemeinsam genutzt wird. Bevor der Pool eine Verbindung ausgibt, prüft er, ob die Verbindung noch gesund ist. Wenn diese Prüfung unterbrochen wird — ein Abbruch, ein Shutdown, alles, was von BaseException und nicht von Exception abgeleitet ist — konnte das ältere Verhalten dies verschlucken, statt es weiterzugeben. Ein Speicher-Schreibvorgang, der laut hätte fehlschlagen sollen, verschwindet stattdessen still.
Für eine Komponente, deren gesamte Aufgabe darin besteht, nicht zu verlieren, was sich ein Agent merkt, ist still die schlimmste Fehlerart, die es gibt. Dieser eine Upstream-Fix ist allein schon ein Release wert.
Was 3.3.6 sonst noch bringt
- Eine abgebrochene Abfrage wartet nicht mehr für immer, wenn der Server nicht mehr antwortet. Dafür ist libpq 17 oder neuer erforderlich — die Binary Wheels liefern libpq 18 mit, also greift die Änderung tatsächlich, statt brachzuliegen.
- Die laufende Abfrage wird bei
SystemExitabgebrochen. Das ist in dem Moment wichtig, in dem ein Worker mitten in einer Abfrage ein SIGTERM erhält: Zuvor konnte die Anweisung serverseitig weiterlaufen, nachdem der Prozess bereits auf dem Weg nach draußen war. - Vorbereitete Anweisungen werden bei
DEALLOCATE ALLverworfen, wodurch Überraschungen wie "prepared statement does not exist" vermieden werden, wenn etwas zwischen Checkouts erneutDISCARDausführt. - Geringerer Async-Warte-Overhead und Unterstützung für Python 3.15.
Die Pin-Grenze lebt in vier Stellen, und das ist Absicht
Die psycopg-Anforderung erscheint in pyproject.toml, in hermes_pgvector/plugin.yaml, in scripts/install.sh und in dem Installationsbefehl, der in der README ausgegeben wird. Alle vier wurden in diesem Release gemeinsam geändert, und das ist kein pedantischer Verwaltungsaufwand.
Eine vollständige Codebasis-Prüfung am 7. September ergab, dass README und Installationsskript weiterhin >=3.3.4 festsetzten, während pyproject.toml bereits auf >=3.3.5 umgestellt worden war. Wer dem dokumentierten Installationspfad folgte, bekam genau die Version geliefert, von der sich der vorherige Release eigentlich lösen sollte. Diese Abweichung überdauerte einen ganzen Release-Zyklus, ohne dass es jemand bemerkte.
Also lautet die Regel jetzt, dass sich die vier jedes Mal gemeinsam bewegen — oder der Release wird nicht ausgeliefert.
Aktualisieren
pip install -U hermes-memory-pgvector
Keine Migration, keine Konfigurationsänderung, kein Verhaltensunterschied, den Sie bemerken werden — und genau das ist der Sinn eines Releases wie dieses.
Die Quelle und die vollständige Konfigurationsreferenz finden Sie auf GitHub: