Gemeinsamer Speicher für Agent-Flotten: hermes-memory-pgvector
Wenn Sie mehr als einen KI-Agenten betreiben – einen Marketing-Minion, einen Trading-Minion, einen Incident-Response-Minion – braucht jeder davon Speicher. Das eingebaute Speicherwerkzeug gibt jedem Agenten seinen eigenen. Das ist in Ordnung, bis Sie möchten, dass sie ihn teilen, oder bis Sie das, was der Agent vor sechs Wochen gelernt hat, abrufen möchten, ohne für eine LLM-Rundreise nur zum Nachschlagen zu bezahlen.
hermes-memory-pgvector ist ein kleines Postgres- + pgvector-Plugin, das Schreibvorgänge in den Agentenspeicher in einen gemeinsamen, eingebetteten, abfragbaren Speicher spiegelt. Aktuelle Version auf PyPI: v1.0.0.
Neu in v1.0.0 – eine stabile Oberfläche
1.0.0 erklärt die öffentliche Oberfläche gemäß semantischer Versionierung als stabil: Konfigurationsschlüssel, Werkzeugnamen, CLI-Befehle und Exit-Codes sowie Tabellennamen. Es erscheint nach einer mehrstufigen Vorveröffentlichungsprüfung, die einen Datenverlust-Bug und eine Reihe kleinerer Probleme behoben hat, ohne Schemaänderungen gegenüber 0.6.0. Seit v0.5.0 registriert ein einfaches pip install den Provider über einen Entry Point, sodass der unten beschriebene Discovery-Shim nur noch auf älteren Hosts nötig ist. Details: hermes-memory-pgvector 1.0: A Stable Memory Surface.
Neu in v0.4.2 – pip-native Installation
hermes-agent entdeckt Speicher-Provider, indem er Plugin-Verzeichnisse scannt (plugins/memory/<name>/ gebündelt, $HERMES_HOME/plugins/<name>/ benutzerseitig) – er schaut niemals in site-packages, sodass ein bloßes pip install das Plugin zwar korrekt installiert, es aber vollständig unsichtbar ließ. v0.4.2 schließt diese Lücke: pip install bringt den Code auf die Maschine, und ein einziger Befehl hermes-pgvector install erzeugt den Discovery-Shim, den das Framework tatsächlich liest.
Neu in v0.4.1 – hybride Suche (Vector + Volltext)
recall_memory und recall_conversation fusionieren nun das HNSW-Cosine-Ranking mit einem PostgreSQL-Volltext-Ranking mittels Reciprocal Rank Fusion (k=60). Eine Zeile taucht auf, wenn einer der Ranker sie mag, was die beiden blinden Erben der reinen Vector-Suche behebt: exakt-lexikalische Treffer, die Cosine glättet (Fehlercodes, Hostnamen, Flags, seltene Bezeichner), sowie text-only Zeilen mit NULL-Embedding – geschrieben, während der Embed-Endpoint ausgefallen war –, die der Vector-Index überhaupt nicht sehen kann. Die hybride Suche dient zugleich als Best-Effort-Wiederherstellung für diese Zeilen bis zum nächsten backfill-Lauf.
Was v0.4.0 hinzugefügt hat
Diese Version behielt die Regel „kein LLM im Hot Path" bei und fügte vier Speicherschicht-Fähigkeiten hinzu:
- Identitäts-Governance. Direktnachrichten-Session-Schlüssel fallen in einen einzigen privatsphärefreundlichen Bucket zusammen – kein Theme-Sprawl pro Kontakt, keine PII – Benchmark-Verkehr wird quarantänisiert, und eine optionale Allow-List leitet falsch geschriebene Theme-Namen auf eine sichere Standardvorgabe um, anstatt stillschweigend einen neuen zu erzeugen.
- Agent-Attribution & Delegation. Eine neue Registry und Provenance-Edges zeichnen auf, welcher Agent was an wen delegiert hat, abfragbar über eine Datenbank-View. Reine Wer/Wann-Provenance – niemals ein Faktenspeicher.
- Embedding-Backfill. Zeilen, die während eines Embedding-Endpoint-Ausfalls text-only geschrieben wurden, bleiben nicht mehr zurück: ein idempotenter Befehl re-embeddet sie, sodass sie wieder durchsuchbar werden.
- Conversation-TTL & Kostensteuerung. Ein vom Operator ausgeführter Prune trimmt alte Chat-Turns (dauerhafte Erinnerungen werden nie angefasst), und eine Embed-Policy dreht die Embedding-Kosten hoch oder runter.
All das wird über eine Wartungs-CLI (hermes-pgvector) ausgeliefert, deren destruktive Befehle standardmäßig auf Dry-Run stehen. Die 0.4.x-Linie ist ein Drop-in-Upgrade von v0.3.x – wenden Sie die additiven Migrationen an, und die neuen Hooks leuchten auf; überspringen Sie sie, läuft alles andere unverändert.
Was es tatsächlich tut
In einem Satz: „eine Speicherschicht, die dem eingebauten Speichermodell eine dauerhafte, mandantenfähige, semantisch durchsuchbare Unterlegung gibt, ohne LLM im Hot Path."
Zwei Tabellen, beide mit HNSW-Vector-Indizes. memory_entries spiegelt Schreibvorgänge in die MEMORY.md/USER.md-Dateien des Agenten. conversations speichert substanzielle Chat-Turns (≥40 Zeichen, Boilerplate herausgefiltert). Embeddings sind 768-dimensional und werden von einem externen Endpoint berechnet – Ollama, OpenAI-kompatibel, Ihre Wahl. Der Agent blockiert nie daran: Schreibvorgänge kehren in Mikrosekunden zurück, und der Embedding-Worker erledigt den Rest in einer Hintergrund-Queue.
Pro-Agent-Themes standardmäßig
Jede Anfrage trägt einen X-Hermes-Session-Key-Header, der Daten nach agent_identity scoped. Die Notizen des Marketings verschmutzen nicht die Suche des Tradings. Wenn Sie tatsächlich eine themenübergreifende Suche wünschen, übergeben Sie explizit scope='all'. Die Standardeinstellung ist die sichere.
Warum eigenständig, nicht ein Fork
hermes-agent hat seine eingebaute Speicher-Provider-Liste per Richtlinie geschlossen, daher lebt dies als separater /plugins-Verzeichnis-Scan statt als Upstream-Fork. Legen Sie es neben den Agenten, setzen Sie ein paar Konfigurationsschlüssel, starten Sie neu. Der Rollback ist symmetrisch: Provider deaktivieren, optional die Tabellen droppen. Kein langlebiger Zustand zum Migrieren, keine Kernel-Patches zu pflegen.
Was es nicht ist
Kein Honcho-Ersatz. Keine Wissensgraph. Kein RAG-Framework. Es ist absichtlich eine dünne Schicht, die eine Sache tut – das eingebaute Speicherwerkzeug in einen gemeinsamen, dauerhaften, vector-durchsuchbaren Speicher verwandeln – und dann aus dem Weg geht. Kein LLM-Deriver, keine dialektische Schleife, keine Meinung dazu, wie Sie chunken oder reranken sollten. Nur Vektor-Mathematik.
Holen Sie es
pip install hermes-memory-pgvector
hermes-pgvector install
Quellcode, Migration und Konfiguration auf GitHub: