Geteiltes Gedächtnis für Agenten-Flotten: hermes-memory-pgvector
Wenn du mehr als einen KI-Agenten einsetzt — einen Marketing-Minion, einen Trading-Minion, einen Incident-Response-Minion — braucht jeder von ihnen ein Gedächtnis. Das integrierte Memory-Tool gibt jedem Agenten sein eigenes. Das ist in Ordnung, bis du möchtest, dass sie es teilen, oder bis du dich daran erinnern willst, was der Agent vor sechs Wochen gelernt hat, ohne für einen LLM-Roundtrip zu bezahlen, nur um es nachzuschlagen.
hermes-memory-pgvector ist ein kleines Postgres- + pgvector-Plugin, das Schreibvorgänge aus dem Agentengedächtnis in einen gemeinsamen, eingebetteten, abfragbaren Speicher spiegelt. Veröffentlicht auf PyPI in v0.4.2.
Neu in v0.4.2 — pip-native Installation
hermes-agent entdeckt Memory-Provider, indem es Plugin-Verzeichnisse durchsucht (plugins/memory/<name>/ gebündelt, $HERMES_HOME/plugins/<name>/ benutzerseitig) — es schaut nie in site-packages, daher ließ pip install allein das Plugin korrekt installiert und vollständig unsichtbar zurück. v0.4.2 schließt diese Lücke: pip install legt den Code auf der Maschine ab, und ein einziger hermes-pgvector install-Befehl erzeugt den Discovery-Shim, den das Framework tatsächlich liest.
Neu in v0.4.1 — hybrides Recall (Vektor + Volltext)
recall_memory und recall_conversation verbinden jetzt die HNSW-Cosine-Rangfolge mit einer PostgreSQL-Volltext-Rangfolge unter Verwendung von Reciprocal Rank Fusion (k=60). Eine Zeile erscheint, wenn einer der beiden Ranker sie mag, was die zwei blinden Flecken der reinen Vektorsuche behebt: exakte lexikalische Treffer, die Cosine verwischt (Fehlercodes, Hostnamen, Flags, seltene Bezeichner), und rein textbasierte Zeilen mit einem NULL-Embedding — geschrieben, während der Embed-Endpunkt ausgefallen war — die der Vektorindex überhaupt nicht sehen kann. Hybrides Recall dient auch als bestmögliche 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 kritischen Pfad“ bei und fügte vier Fähigkeiten auf der Speicher-Ebene hinzu:
- Identitäts-Governance. Direktnachrichten-Session-Keys fallen in einen einzigen datenschutzsicheren Bucket zusammen — keine thematische Zersplitterung pro Kontakt, keine PII — Benchmark-Traffic wird quarantänisiert, und eine optionale Allowlist leitet vertippte Themennamen an einen sicheren Standard weiter, statt stillschweigend einen neuen zu erzeugen.
- Agenten-Attribution & Delegation. Ein neues Register und Provenienz-Kanten zeichnen auf, welcher Agent was an wen delegiert hat, abfragbar über eine Datenbank-View. Reine Wer/Wann-Provenienz — niemals ein Facts-Store.
- Embedding-Backfill. Zeilen, die während eines Ausfalls des Embedding-Endpunkts nur als Text geschrieben wurden, sind nicht mehr abgeschnitten: Ein idempotenter Befehl bettet sie erneut ein, damit sie wieder durchsuchbar werden.
- Conversation-TTL & Kostenkontrollen. Ein vom Operator ausgeführtes Prune kürzt alte Chat-Verläufe (dauerhafte Memories werden nie angetastet), und eine Embed-Policy reguliert die Embedding-Kosten nach oben oder unten.
All das wird hinter einer 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 — wende die additiven Migrationen an, und die neuen Hooks werden aktiviert; lass sie weg, und alles andere läuft unverändert weiter.
Was es tatsächlich tut
In einem Satz: „eine Speicherschicht, die dem integrierten Memory-Modell eine dauerhafte, mandantenfähige, semantisch durchsuchbare Grundlage gibt, ohne LLM im kritischen Pfad.“
Zwei Tabellen, beide mit HNSW-Vektorindizes. memory_entries spiegelt Schreibvorgänge in die Dateien MEMORY.md/USER.md des Agenten. conversations speichert inhaltlich relevante Chat-Verläufe (≥40 Zeichen, Boilerplate herausgefiltert). Embeddings haben 768 Dimensionen und werden von einem externen Endpunkt berechnet — Ollama, OpenAI-kompatibel, deine Wahl. Der Agent blockiert dabei nie: Schreibvorgänge kehren in Mikrosekunden zurück, und der Embedding-Worker erledigt den Rest über eine Hintergrund-Queue.
Standardmäßig pro Agent eigenes Theme
Jede Anfrage trägt einen X-Hermes-Session-Key-Header, der Daten nach agent_identity abgrenzt. Die Notizen von Marketing verunreinigen nicht das Recall von Trading. Wenn du tatsächlich eine themenübergreifende Suche willst, übergib scope='all' explizit. Der Standard ist der sichere.
Warum eigenständig und kein Fork
hermes-agent hat seine eingebaute Liste von Memory-Providern laut Richtlinie geschlossen, daher lebt dies als separater Scan des /plugins-Verzeichnisses statt als Upstream-Fork. Lege es neben den Agenten, setze ein paar Konfigurationsschlüssel, starte neu. Rollback ist symmetrisch: Provider deaktivieren, optional die Tabellen löschen. Kein langfristiger Zustand zu migrieren, keine Kernel-Patches zu pflegen.
Was es nicht ist
Kein Honcho-Ersatz. Kein Knowledge Graph. Kein RAG-Framework. Es ist absichtlich eine dünne Schicht, die genau eines tut — das integrierte Memory-Tool in einen gemeinsamen, dauerhaften, vektorsuchbaren Speicher verwandeln — und sich aus dem Weg hält. Kein LLM-Deriver, kein dialektischer Loop, keine Meinung dazu, wie du chunking oder reranking machen solltest. Nur Vektor-Mathematik.
Hol es dir
pip install hermes-memory-pgvector
hermes-pgvector install
Quellcode, Migration und Konfiguration auf GitHub: