IT23. Mai 2026

Geteiltes Gedächtnis für Agentenflotten: hermes-memory-pgvector

Von Andrea Borghi
Geteiltes Gedächtnis für Agentenflotten: hermes-memory-pgvector

Geteiltes Gedächtnis für Agentenflotten: hermes-memory-pgvector

Wenn Sie mehr als einen KI-Agenten betreiben — einen Marketing-Minion, einen Trading-Minion, einen Incident-Response-Minion — braucht jeder davon ein Gedächtnis. Das integrierte Memory-Tool gibt jedem Agenten sein eigenes. Das ist in Ordnung, bis Sie möchten, dass sie es gemeinsam nutzen, oder bis Sie abrufen wollen, 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 Memory-Schreibvorgänge von Agenten in einen gemeinsamen, eingebetteten, abfragbaren Speicher spiegelt. Veröffentlicht auf PyPI in v0.4.0.

Neu in v0.4.0

Die neueste Version behält die Regel „kein LLM im kritischen Pfad“ bei und ergänzt vier Funktionen auf Speicherebene:

  • Identitätsverwaltung. Schlüssel für Direktnachrichten-Sitzungen werden zu einem einzigen, datenschutzsicheren Bucket zusammengefasst — kein thematisches Wildwuchs pro Kontakt, keine PII — Benchmark-Traffic wird isoliert, und eine optionale Allowlist leitet falsch geschriebene Themennamen zu einem sicheren Standard weiter, statt stillschweigend einen neuen anzulegen.
  • Agenten-Zuordnung & Delegation. Ein neues Registry und Provenienz-Kanten zeichnen auf, welcher Agent was an wen delegiert hat, über eine Datenbankansicht abfragbar. Reine Wer/Wann-Provenienz — niemals ein Faktenspeicher.
  • Embedding-Nachbefüllung. Zeilen, die während eines Ausfalls des Embedding-Endpunkts nur textbasiert geschrieben wurden, bleiben nicht länger zurück: Ein idempotenter Befehl erzeugt ihre Embeddings neu, damit sie wieder durchsuchbar werden.
  • Conversation-TTL & Kostenkontrollen. Ein vom Operator ausgeführtes Pruning kürzt alte Chatverläufe (dauerhafte Erinnerungen werden niemals angefasst), und eine Embedding-Richtlinie regelt die Embedding-Kosten nach oben oder unten.

All das wird hinter einem Wartungs-CLI (hermes-pgvector) ausgeliefert, dessen destruktive Befehle standardmäßig auf Dry-Run stehen. v0.4.0 ist ein Drop-in-Upgrade von v0.3.x — wenden Sie eine additive Migration an, und die neuen Hooks werden aktiviert; überspringen Sie sie, und alles andere läuft unverändert weiter.

Was es tatsächlich macht

In einem Satz: „eine Speicherschicht, die dem integrierten Memory-Modell dauerhaftes, mandantenfähiges, semantisch durchsuchbares Backend gibt, ohne LLM im kritischen Pfad.“

Zwei Tabellen, beide mit HNSW-Vektorindizes. memory_entries spiegelt Schreibvorgänge in die MEMORY.md/USER.md-Dateien des Agenten. conversations speichert substanzielle Chat-Beiträge (≥40 Zeichen, Boilerplate herausgefiltert). Embeddings haben 768 Dimensionen und werden von einem externen Endpunkt berechnet — Ollama, OpenAI-kompatibel, ganz nach Ihrer Wahl. Der Agent wartet dabei nie darauf: Schreibvorgänge sind in Mikrosekunden erledigt, und der Embedding-Worker übernimmt den Rest über eine Hintergrundwarteschlange.

Standardmäßig themenbezogen pro Agent

Jede Anfrage enthält einen X-Hermes-Session-Key-Header, der Daten nach agent_identity abgrenzt. Die Notizen des Marketing-Agents verunreinigen nicht die Erinnerungen des Trading-Agents. Wenn Sie wirklich themenübergreifende Suche möchten, übergeben Sie scope='all' explizit. Der Standard ist der sichere.

Warum eigenständig und nicht als Fork

hermes-agent hat seine integrierte Liste von Memory-Providern gemäß Richtlinie geschlossen, daher lebt dies als separater Scan des /plugins-Verzeichnisses statt als Upstream-Fork. Legen Sie es neben den Agenten, setzen Sie ein paar Konfigurationsschlüssel, starten Sie neu. Das Zurückrollen ist symmetrisch: Provider deaktivieren, optional die Tabellen löschen. Kein dauerhaftes State-Migrationsthema, keine Kernel-Patches, die gewartet werden müssen.

Was es nicht ist

Kein Honcho-Ersatz. Kein Wissensgraph. Kein RAG-Framework. Es ist absichtlich eine dünne Schicht, die genau eine Sache tut — das integrierte Memory-Tool in einen gemeinsamen, dauerhaften, per Vektorsuche abfragbaren Speicher verwandeln — und sich dann aus dem Weg macht. Kein LLM-Deriver, kein dialektischer Loop, keine Meinung dazu, wie Sie chunking oder reranking machen sollten. Einfach Vektormathematik.

Holen Sie es sich

pip install hermes-memory-pgvector

Quellcode, Migration und Konfiguration auf GitHub:

👉 github.com/andreab67/hermes-memory-pgvector