Die meisten KI-Chat-Oberflächen, die du bisher benutzt hast, haben kein echtes Gedächtnis. Sie haben ein Kontextfenster — und das ist etwas völlig anderes. Was du weiter oben im selben Chat gesagt hast, liegt noch vor dem Modell. Was du gestern in einem anderen Chat gesagt hast, ist weg. Am nächsten Tag fängst du wieder bei null an, und der Assistent stellt sich vor, als hätte er dich noch nie gesehen.
Hermes Agent funktioniert anders. Es gibt eine echte Gedächtnisschicht — getrennt vom Gesprächskontext —, die mit der Zeit Dinge über dich lernt, sie über Sessions und Plattformen hinweg mitnimmt und dafür sorgt, dass der Bot sich jedes Mal wie dieselbe Instanz verhält, wenn du mit ihm sprichst. In diesem Artikel geht es darum, wie das konkret funktioniert, welche Designentscheidungen zählen und was das steckbare Memory-Interface in v0.7.0 verändert hat.
Kurzzeitgedächtnis vs. Langzeitgedächtnis
Zuerst die Unterscheidung, auf die es ankommt.
Kurzzeitgedächtnis in Hermes ist das Kontextfenster der laufenden Session. Es ist der Ausschnitt des Gesprächsverlaufs, den der Agent gerade hält, kombiniert mit einer proaktiven Komprimierungsstrategie: Wenn der Kontext sich dem Modelllimit nähert, fährt Hermes einen Zusammenfassungsdurchlauf, der ältere Turns in ein strukturiertes Summary faltet, während die neuesten Wechsel wörtlich erhalten bleiben. Diese Komprimierung wurde über mehrere Releases hinweg verfeinert — strukturierte Summaries mit iterativen Updates in v0.4.0, Token-Budget-Schutz am Ende, ein konfigurierbarer Summary-Endpoint und Fallback-Modell-Unterstützung. Bei langen Gesprächen hält das den Agenten leise schnell und günstig, ohne dass wichtiger Kontext verloren geht.
Langzeitgedächtnis ist der spannende Teil. Es ist ein Speicher für Fakten, Vorlieben, Korrekturen und Nutzermodelle, der außerhalb des Gesprächs lebt. Wenn du dem Bot heute auf Telegram sagst „Ich heiße Alice", wird diese Information ins Langzeitgedächtnis geschrieben. Morgen, wenn du ihm auf Slack eine Frage stellst, wird sie herausgezogen und in den Kontext injiziert, bevor der Agent deine Nachricht sieht. Das Modell bekommt nach wie vor nur das zu sehen, was ins Fenster passt — aber das Fenster ist schon mit den Dingen grundiert, die es über dich wissen sollte.
Kurzzeitgedächtnis ist ein Puffer. Langzeitgedächtnis ist eine Person.
Honcho: Was es ist und warum es zählt
Der Standard-Langzeitgedächtnis-Provider in Hermes ist Honcho, eine Bibliothek, die speziell für KI-natives Memory gebaut wurde. Honchos Aufgabe ist es, hinter dem Agenten zu laufen und drei konkrete Dinge zu tun:
- 1.Beobachten. Jede Nutzernachricht und jede Agentenantwort fließen als Event-Stream in Honcho ein. Honcho baut daraus ein internes Nutzermodell auf — nicht den rohen Chatverlauf, sondern strukturierte Fakten und Vorlieben, die aus dem Gespräch abgeleitet werden.
- 2.Über den Nutzer nachdenken. Honcho betreibt eine kleine „dialektische" Schicht, die versucht, ein stimmiges Bild davon zusammenzusetzen, wer du bist, was du willst und was du korrigiert hast. Das ist keine bloße Keyword-Extraktion — es ist ein laufendes mentales Modell des Nutzers.
- 3.Injizieren. Bei jedem neuen Turn erzeugt Honcho ein kurzes Kontext-Snippet, das zusammenfasst, was es gerade für relevant über dich hält. Hermes stellt das dem System-Prompt voran. Das Snippet verändert sich, je mehr Honcho dazulernt.
Zwei Details sind leicht zu übersehen, aber wichtig.
Erstens: Honcho-Schreibvorgänge sind asynchron. Der Agent blockiert nicht auf einem Memory-Write. Er antwortet, und die Gedächtnisschicht verarbeitet den Austausch im Hintergrund. Das bedeutet, dass lange Gespräche keine Latenz-Steuer für Gedächtnisupdates zahlen, und ein Ausfall des Memory-Backends stoppt den Bot nicht — du verlierst die Updates während des Ausfalls, aber der Assistent redet weiter.
Zweitens: Honchos Recall liegt außerhalb des gecachten System-Präfixes. Anthropics Prompt-Caching-Feature (das bei Modellen wie Claude Sonnet 4.6 intensiv genutzt wird) braucht einen stabilen System-Prompt über Turns hinweg, damit der Cache greift. Honchos injiziertes Snippet ändert sich von Turn zu Turn, also hängt Hermes es absichtlich nach dem gecachten System-Abschnitt an. Der Cache funktioniert weiter für die statischen Teile; die dynamische Gedächtnisschicht funktioniert weiter für die Teile, die sich ändern. Das ist die Art von mechanischem Tradeoff, der nie in den Release Notes auftaucht, aber entscheidet, ob deine Monatsrechnung bei 50 oder bei 500 Dollar liegt.
Mehrbenutzerisolierung im Gateway-Modus
Das Standard-Hermes-Gateway schleust mehrere Nutzer durch denselben Agentenprozess. Das Langzeitgedächtnis muss pro Nutzer getrennt sein — sonst landen Alices Allergien in Bobs Kochvorschlägen. Das v0.3.0-Release hat eine ordentliche Mehrbenutzerisolierung für Honcho innerhalb des Gateways eingebaut, was in der Praxis bedeutet:
- •Jede Gateway-Nutzer-ID wird einem eigenen Honcho-Peer zugeordnet, und Gedächtnisschreibvorgänge sind pro Peer isoliert.
- •Gruppenchat-Sessions erben standardmäßig nutzerbezogene Sessions, d. h. selbst ein geteilter Channel schreibt für jeden Teilnehmer separate Gedächtnisströme.
- •Die Profil-basierte Gedächtnisisolierung (v0.5.0/v0.6.0) sorgt dafür, dass beim Betrieb mehrerer Hermes-Profile auf derselben Maschine jedes Profil sein eigenes Gedächtnis-Universum hat. Profilwechsel lassen keine Persona in eine andere durchsickern.
Nichts davon ist für Nutzer sichtbar. Alles davon zusammen ist der Grund, warum der Bot nicht versehentlich die falsche Person erinnert.
Das steckbare Memory-Interface (v0.7.0)
In den ersten fünf Releases von Hermes war Honcho fest verdrahtet. In v0.7.0 wurde die Gedächtnisschicht in ein ordentliches Provider-Interface refaktorisiert — eine kleine Python-ABC, die jedes Memory-Backend implementieren kann. Die Änderung ist architektonisch bescheiden und praktisch riesig.
Das Interface ermöglicht den Austausch von Memory-Backends, ohne Hermes' Kern anzufassen:
- •Honcho ist der Referenz-Provider (und nach wie vor der Standard). Voller Funktionsumfang, echtes Nutzermodell, korrekte Mehrbenutzerisolierung.
- •Supermemory kam in v0.8.0 als zweiter First-Class-Provider dazu — mit Multi-Container-Support, konfigurierbaren Suchmodi und Identity-Templating.
- •mem0, OpenViking, RetainDB, Hindsight und ByteRover haben Community-Memory-Plugins im Hermes-Plugin-System, mit unterschiedlicher Integrationstiefe.
- •Du kannst auch dein eigenes schreiben. Die ABC ist klein: implementiere
write(),recall(), ein paar Lifecycle-Hooks, und registriere es als Plugin.
Der eingebaute Memory-Provider — der abhängigkeitsfreie Standard, wenn du nichts anderes konfiguriert hast — ist ein SQLite-basierter Faktenspeicher, der die Grundlagen abdeckt: Fakten schreiben, nach Relevanz abrufen, pro Nutzer eingrenzen. Er ist nicht so clever wie Honcho, braucht aber keinen externen Dienst, und für einen persönlichen Assistenten auf einem 5-Dollar-VPS reicht er meistens aus.
Was das im Stillen freisetzt
Steckbares Memory ist die Art von Architekturänderung, die in Release Notes wie Hausmeisterarbeit aussieht. „Memory in ein Provider-Interface refaktorisiert" ist keine Schlagzeile. Was es tatsächlich tut, ist die Frage „Was sollte ein KI-Assistent über dich behalten?" von der Frage „Wie funktioniert Hermes?" zu entkoppeln.
Du kannst Honcho jetzt durch ein Memory-Backend ersetzen, das auf deinen Anwendungsfall zugeschnitten ist — ein Vektorspeicher für Leute, die semantische Suche über eine persönliche Wissensbasis wollen; eine Graphdatenbank für Leute, die explizite Entity-Beziehungen brauchen; ein rein lokaler SQLite-Speicher für Leute, die keine Gedächtnisdaten von ihrer Maschine lassen wollen; ein firmeninterner Memory-Dienst für Teams. Der Agent ändert sich nicht. Nur das, was hinter dem memory-Interface steckt.
Das ist die richtige Abstraktionsebene für ein Projekt, das in ein paar Jahren noch da sein will. Gedächtnis ist etwas Persönliches, und das richtige Memory-Backend für dich ist nicht unbedingt das richtige für jemand anderen. Hermes' Aufgabe ist es, sich mit jeder Gedächtnisschicht, die du einsteckst, gut zu vertragen — und ihr nicht im Weg zu stehen.