Hermes Agent merkt sich nichts mehr: die Fixes

Ihr Agent sollte sich erinnern

Am Montag haben Sie Hermes Agent von Ihrem Projekt erzählt. Am Mittwoch stellt er sich vor, als hätten Sie sich nie gesehen. Das Versprechen des persistenten Speichers ist der ganze Grund, warum Sie sich für einen selbst gehosteten Agenten statt für ChatGPT entschieden haben, und jetzt fühlt er sich an wie dasselbe vergessliche Werkzeug mit mehr Konfigurationsschritten.

Die gute Nachricht: das Speichersystem von Hermes Agent ist einfach genug, um es von außen zu diagnostizieren. MEMORY.md und USER.md sind reine Markdown-Dateien auf der Platte. Wenn der Agent sich nicht erinnert, passiert eine von vier Sachen, und jede hat einen konkreten Fix.

Wie der persistente Speicher von Hermes Agent tatsächlich funktioniert

Bevor Sie diagnostizieren, hilft es, die Form dessen zu kennen, was kaputt ist.

Hermes Agent schreibt zwei Arten von Speicher in das Datenverzeichnis (in der Regel ~/.hermes/memories/):

• MEMORY.md - vom Agenten gepflegte Notizen zu Ihren Projekten, Präferenzen und Workflows. Auf rund 2.200 Zeichen begrenzt, damit das Modell zwingend priorisieren muss.
• USER.md - ein stabiles Profil, wer Sie sind: Rolle, technische Umgebung, Kommunikationsstil.

Zu Beginn jeder Sitzung liest der Agent beide Dateien und schleust sie in den System-Prompt ein. Während der Sitzung aktualisiert er sie automatisch anhand dessen, worüber Sie gesprochen haben. Wenn die Sitzung endet, bleiben die Dateien auf der Platte.

Dieser letzte Satz ist das ganze Versprechen. Wenn die Dateien nach einem Neustart nicht auf der Platte sind, persistiert der Speicher nicht. Wenn sie da sind und der Agent trotzdem vergisst, läuft etwas anderes schief. Das sind zwei verschiedene Bugs.

Einen ausführlicheren Rundgang durch das Speichersystem selbst finden Sie unter wie Hermes Agent Memory und Skills funktionieren. Dieser Beitrag befasst sich nur mit den Fehlermodi.

Ursache 1: Das Daten-Volume ist nicht gemountet

Das ist mit Abstand die häufigste Ursache. Symptom: der Agent funktioniert eine ganze Unterhaltung lang tadellos, erinnert sich an alles, was Sie ihm vor fünf Minuten gesagt haben, dann startet der Container neu und er vergisst, dass Sie existieren.

Was passiert: die Speicherdateien werden in die beschreibbare Schicht des Containers geschrieben statt in ein persistentes Volume. Bei docker stop und docker start überlebt die beschreibbare Schicht. Bei docker rm (oder docker compose down, oder wenn der Host neu startet und den Container neu erzeugt) wird die beschreibbare Schicht zerstört, und MEMORY.md stirbt mit ihr.

Prüfen Sie zuerst: existiert das Speicherverzeichnis überhaupt auf Ihrem Host?

ls -la ~/.hermes/memories/

Wenn dieses Verzeichnis leer ist oder fehlt, obwohl der Agent schon eine Weile läuft, schreibt der Container nicht dorthin.

Der Fix: mounten Sie ~/.hermes als Volume. In docker run:

docker run -v ~/.hermes:/root/.hermes ...

In docker-compose.yml:

services:
  hermes:
    volumes:
      - ~/.hermes:/root/.hermes

Nach der Änderung erzeugen Sie den Container neu (nicht nur restart) und verifizieren Sie, dass sich das memories-Verzeichnis auf dem Host füllt, während Sie den Agenten nutzen. Der Docker-Guide für Hermes Agent enthält das komplette Compose-File.

Ursache 2: Volume gemountet, aber Berechtigungen sind falsch

Sie haben das Volume gemountet, das Verzeichnis existiert auf dem Host, aber die Dateien bleiben leer oder die Logs des Agenten erwähnen „permission denied", wenn er zu schreiben versucht.

Container und Host teilen sich denselben numerischen UID-Raum, und standardmäßig gleicht nichts diese Nummern miteinander ab. Wenn Ihr Agent im Container als UID 1000 läuft und das Host-Verzeichnis root gehört, schlägt der Schreibversuch still fehl. Auf Fedora, RHEL und anderen Distributionen mit SELinux wird der Schreibvorgang verweigert, selbst wenn die Standard-Unix-Rechte ihn erlaubten, und Docker warnt Sie nicht.

Prüfen Sie den Besitzer:

ls -ln ~/.hermes/memories/

Fix, klassisches Docker: machen Sie das Host-Verzeichnis für dieselbe UID beschreibbar, die der Container verwendet:

sudo chown -R $(id -u):$(id -g) ~/.hermes

Fix, SELinux-Hosts: fügen Sie dem Volume-Mount das :Z-Label hinzu, damit Docker es für den Container-Zugriff neu labelt:

volumes:
  - ~/.hermes:/root/.hermes:Z

Fix, Rootless Docker: das „root" des Containers wird über User Namespaces auf Ihre Host-UID gemappt, nicht auf die echte UID 0. Der chown oben deckt diesen Fall schon ab, aber das mentale Modell hakt bei Leuten, die per sudo an die Datei wollen und trotzdem scheitern.

Ursache 3: Das Kontextfenster ist voll, nicht die Speicherdatei

Symptom: MEMORY.md liegt auf der Platte, enthält Ihre Projektnotizen, cat zeigt den Inhalt, und der Agent verhält sich trotzdem so, als würde er sich nicht erinnern. Das ist kein Speicher-Bug. Das ist ein Kontextfenster-Bug im Speicher-Kostüm.

Hermes Agent liest MEMORY.md und USER.md beim Sitzungsstart in den System-Prompt, führt aber gleichzeitig die laufende Unterhaltungshistorie im selben Kontextfenster mit. Übersteigt die kombinierte Größe das Limit des Modells, werden zuerst ältere Tokens gekappt. Schon vor dem harten Limit tritt der „Lost in the middle"-Effekt auf: Modelle rufen Informationen vom Anfang und Ende des Kontexts zuverlässig ab, aus der Mitte deutlich weniger zuverlässig.

Die Speicherdatei kann also vorhanden und korrekt sein, aber in Zug 30 einer langen Unterhaltung hat das Modell eine gekappte oder in der Mitte begrabene Fassung bekommen und verhält sich, als hätte es sie nie gesehen.

Diagnose:

• Vergleichen Sie die Kontextfenster der Modelle. Schauen Sie nach, welches Modell Sie konfiguriert haben. Ein Modell mit kleinem Fenster stößt viel früher an diese Grenze als ein 200k- oder 1M-Token-Modell.
• Prüfen Sie die Größe von MEMORY.md. Nahe am 2.200-Zeichen-Deckel ist in Ordnung. Wenn eine ältere Hermes-Version sie auf 20k anwachsen ließ, kürzen Sie.
• Achten Sie auf die Länge der aktuellen Sitzung. Lange Einzelsitzungen sind hierfür anfälliger als kurze, häufige.

Fixes:

• Wechseln Sie in Ihrer Konfiguration auf ein Modell mit größerem Kontextfenster.
• Kürzen Sie MEMORY.md von Hand, wenn sie über ihren Deckel hinausgewachsen ist.
• Starten Sie die Sitzung regelmäßig neu. Hermes liest den Speicher beim Sitzungsstart frisch ein, eine neue Sitzung lädt MEMORY.md und USER.md also in einen sauberen Kontext.

Derselbe Fehlermodus wird aus einem anderen Blickwinkel im Telegram-Troubleshooting-Guide unter „Nachrichten kommen an, aber der Agent ignoriert den Inhalt" beschrieben. Es ist derselbe Grundbug auf verschiedenen Kanälen.

Ursache 4: Verwirrung zwischen chat-eigener und globaler Erinnerung

Manche Deployments betreiben einen Hermes-Agent-Prozess pro Telegram-Chat, andere teilen den Speicher chatübergreifend. Wenn Sie dem Agenten in einem privaten DM etwas erzählt haben und er es im Gruppenchat nicht weiß, ist das eine Bereichsverwechslung, kein Persistenz-Bug.

Diagnose:

• Lesen Sie Ihre Konfiguration. Wenn es ein Muster für ein Datenverzeichnis pro Chat gibt, ist der Speicher per Design chatbezogen.
• Wenn Sie ein selbst gehostetes Setup mit einem einzigen, chatübergreifend geteilten ~/.hermes haben, ist der Speicher global, und die Ursache liegt woanders.
• Wenn Sie mehrere Hermes-Prozesse gegen dasselbe Home laufen lassen, um verschiedene Chats zu bedienen, haben Sie ein ganz anderes Problem: zwei Schreiber auf derselben MEMORY.md überschreiben sich gegenseitig, und die Datei landet in einem Zustand, den keiner verfasst hat. Machen Sie das nicht.

Fix: entscheiden Sie sich für ein Modell und konfigurieren Sie entsprechend. Die meisten selbst hostenden Betreiber wollen globalen Speicher (ein Sie, ein Agent, alle Chats). Mehrbenutzer- oder mandantenfähige Deployments wollen meist eine Isolation pro Chat. Beide sind legitim, aber nicht austauschbar.

Wiederherstellung nach einem schlechten Neustart

Wenn MEMORY.md nach einem Absturz oder harten Shutdown beschädigt, auf null Byte gekürzt oder mit unlesbarem Inhalt versehen ist, ist der Wiederherstellungsweg unkompliziert, weil es eine schlichte Markdown-Datei ist.

1. Stoppen Sie den Agenten bevor Sie die Datei anfassen. Ein laufender Agent könnte Ihre Rettungsversuche überschreiben.
2. Suchen Sie nach Backups. Wenn Sie den Empfehlungen aus Hermes Agent auf eine neue Maschine migrieren gefolgt sind, haben Sie bereits regelmäßige Snapshots von ~/.hermes. Stellen Sie den letzten funktionierenden Snapshot wieder her.
3. Bearbeiten Sie sie bei Bedarf von Hand. MEMORY.md ist Markdown. Öffnen Sie sie im Texteditor, entfernen Sie den beschädigten Abschnitt, speichern Sie. Es gibt kein Schema, das erfüllt werden müsste.
4. Starten Sie den Agenten und bestätigen Sie in der nächsten Sitzung, dass der wiederhergestellte Speicher wieder auftaucht.

Wenn Sie keine Backups hatten, ist das der Moment, sie einzurichten. Ein tägliches tar czf hermes-backup-$(date +%F).tar.gz ~/.hermes im Cron dauert Sekunden und verschafft Ihnen für den nächsten Vorfall einen echten Wiederherstellungsweg.

Wann Sie mit dem Debugging aufhören und die Infrastruktur abgeben sollten

Jeder Fix in diesem Beitrag ist eine kleine Korrektur an der Verkabelung des Containers. Keiner davon ist für sich schwierig. Was Zeit frisst, ist, sie an dem Tag zu entdecken, an dem der Agent mitten in einer Unterhaltung ein zweiwöchiges Projekt vergisst, und dann festzustellen, dass das Volume nie gemountet war, die Berechtigungen falsch waren und kein Backup existiert, auf das man zurückgreifen könnte.

Wenn Sie nie wieder ein „permission denied" in einem Hermes-Log sehen möchten, betreibt Hermify einen verwalteten Hermes Agent auf Telegram mit denselben MEMORY.md- und USER.md-Dateien, korrekt gemountet, nächtlich gesichert und mit einem Klick wiederherstellbar. Ihr Speicher bleibt Ihrer (die Dateien sind im Ruhezustand verschlüsselt und herunterladbar), und das Volume-Mount-Debugging ist nicht länger Ihr Problem.

Einen breiteren Blick darauf, wie der Deployment-Kompromiss ausfällt, bietet Hermes Agent Hosting gegenüber Selbst-Hosting.

Starten Sie mit Hermify und überspringen Sie die Checkliste zur Speicherpersistenz komplett.

Quellen

• Referenz zum Speicher von Hermes Agent
• Docker-Guide für Hermes Agent
• Berechtigungsprobleme bei Docker-Volumes mit Nicht-Root-Containern
• Das Kontextfenster ist RAM, nicht Speicher (Mem0)
• LLM-Kontextfenster und Trunkierung (Redis)