OpenClaw Memory funktioniert nicht? So trennst du Recall, QMD und Obsidian sauber

Wenn OpenClaw sich angeblich “nichts merkt”, ist der eigentliche Fehler oft banaler: Du erwartest vom falschen Layer die falsche Aufgabe. Builtin Memory speichert Markdown im Workspace, Active Memory holt vor einer Antwort gezielt Recall nach vorn, QMD verbessert die Suche über Dateien und Transkripte, und Obsidian ist nur dann relevant, wenn du dein Wissen außerhalb von OpenClaw kuratieren willst.

Der wichtige Unterschied lautet deshalb nicht “welches Memory passt hier?”, sondern: Welcher Teil deines Gedächtnis-Stacks bricht gerade wirklich? Genau da fängt saubere Fehlersuche an. Wenn du erst die Rollen trennst, lassen sich auch typische Symptome wie fehlender Recall, leere Trefferlisten oder überfüllte MEMORY.md-Dateien deutlich schneller eingrenzen. Für die Grundlagen zum Workspace passt ergänzend unser Tutorial zum Einrichten von SOUL.md, MEMORY.md und Tagesnotizen.

Das eigentliche Modell: vier Layer statt ein “Memory-Feature”

OpenClaw merkt sich Dinge zuerst ganz schlicht über Dateien im Agent-Workspace. Laut Dokumentation gehören dazu MEMORY.md für dauerhafte Fakten, memory/YYYY-MM-DD.md für Tageskontext und optional DREAMS.md für Dreaming-Zusammenfassungen. Es gibt kein verstecktes Langzeitgedächtnis hinter dem Modell: Was nicht auf Platte landet, ist auch nicht zuverlässig wieder da.

Darauf sitzt Active Memory als optionaler Recall-Schritt vor der Antwort. Das Plugin läuft nur für passende interaktive, persistente Chats und nur dann, wenn Agent, Chat-Typ und Session-Regeln überhaupt passen. Es ist also kein globales “immer erinnern”, sondern ein enger Vorlauf, der noch vor der eigentlichen Antwort versucht, relevante Notizen nach oben zu ziehen.

QMD löst ein anderes Problem. Der Sidecar indexiert nicht nur MEMORY.md und den memory/-Baum, sondern auf Wunsch auch zusätzliche Verzeichnisse und Session-Transkripte. Er kombiniert BM25, Vektorsuche und Reranking, fällt aber laut Dokumentation automatisch auf die eingebaute SQLite-Suche zurück, wenn der Sidecar ausfällt.

Obsidian ist schließlich keine vierte Memory-Engine in OpenClaw, sondern eher die kuratierte Außenschicht. Wenn du rohe Notizen verdichtest, über längere Zeit ordnest oder mit einem Vault arbeitest, ist das ein Wissens-Workflow neben OpenClaw, kein Ersatz für den eigentlichen Recall-Pfad. Wer genau diese Brücke sucht, landet eher bei ObsidianClaw im Vault als bei einer Gateway-Konfiguration.

Typische Symptome und was sie wirklich bedeuten

Der häufigste Denkfehler: “Die Datei existiert, also müsste OpenClaw sie doch erinnern.” Das stimmt nur teilweise.

• Wenn der Agent Fakten aus MEMORY.md oder aktuellen Tagesnotizen gar nicht kennt, ist meist der Speicher- oder Bootstrap-Layer kaputt oder überfüllt.
• Wenn Fakten grundsätzlich gespeichert sind, aber im Gespräch nicht rechtzeitig auftauchen, ist eher Active Memory oder der normale Suchpfad das Problem.
• Wenn ältere Sessions, Notizen oder zusätzliche Ordner kaum noch auftauchen, obwohl du sie längst sauber abgelegt hast, hängt es oft am QMD-Retrieval oder an falschen Erwartungen an die Suchabdeckung.
• Wenn dein Wissen schön im Obsidian-Vault liegt, der Agent aber davon nichts weiß, fehlt keine “Intelligenz”, sondern schlicht eine angeschlossene Abrufschicht.

Der praktische Nutzen dieser Trennung: Du suchst nicht mehr blind an allen Stellen gleichzeitig.

Diagnose: Prüfe zuerst den Builtin-Layer

Die naheliegende Frage ist nicht, ob Recall “klug genug” wirkt, sondern ob die Basisdateien überhaupt die richtige Form haben. Die Dokumentation beschreibt MEMORY.md als kuratierte, kompakte Langzeitdatei. Tagesnotizen gehören in memory/YYYY-MM-DD.md. OpenClaw indexiert diese Tagesdateien zwar für memory_search und memory_get, lädt sie aber nicht automatisch als Volltext in jeden normalen Prompt.

Genau hier entsteht oft ein typischer Fehlerpfad:

• MEMORY.md wird als Roharchiv missbraucht statt als kuratierte Kurzfassung.
• Tageslogs bleiben nur in memory/*.md, obwohl ein dauerhafter Fakt längst in MEMORY.md gehört.
• Die Datei wächst über das Bootstrap-Budget hinaus.

Laut Dokumentation bleibt MEMORY.md in so einem Fall zwar vollständig auf der Platte, aber die in den Modellkontext injizierte Kopie kann gekürzt werden. Wenn sich dein Agent an alte Dauerinfos plötzlich nur noch bruchstückhaft erinnert, ist das kein mystisches Modellversagen, sondern oft genau dieser Truncation-Effekt. Prüfen lässt sich das mit /context list, /context detail oder openclaw doctor.

Expected vs. Actual

• Erwartet: Dauerhafte Fakten stehen kurz und kuratiert in MEMORY.md; Tageskontext lebt in memory/*.md.
• Tatsächlich problematisch: MEMORY.md ist ein wucherndes Journal, während die wirklich wichtigen Langzeitpunkte nicht mehr sauber oben ankommen.

Wenn diese Basis schon nicht stimmt, bringt dir weder QMD noch Active Memory einen echten Rettungsanker.

Diagnose: Wann Active Memory gar nicht erst läuft

Active Memory hilft nur, wenn dein Problem wirklich “richtiger Recall zum richtigen Zeitpunkt” ist. Das Plugin läuft laut Dokumentation nur, wenn vier Bedingungen gleichzeitig erfüllt sind: Plugin aktiv, aktueller Agent ist in config.agents freigeschaltet, der Chat-Typ ist erlaubt und die Session ist ein interaktiver persistenter Chat.

Damit lassen sich viele scheinbar rätselhafte Ausfälle sofort erklären:

• In Direktnachrichten klappt Recall, in Gruppen aber nicht: Standardmäßig sind nur allowedChatTypes: ["direct"] aktiv.
• In Heartbeats oder Hintergrundläufen passiert nichts: Dort läuft Active Memory ausdrücklich nicht.
• In einem One-shot oder internen Helper-Run taucht nie Recall auf: Auch dort greift das Plugin nicht.

Für die Sichtprüfung taugen /active-memory status, /verbose on und /trace on. Die Doku beschreibt, dass du damit nach der normalen Antwort eine Statuszeile und eine Debug-Zusammenfassung sehen kannst. Wenn diese Hinweise fehlen, obwohl du Active Memory erwartest, ist das ein starkes Indiz dafür, dass das Plugin die Session gar nicht als eligible einstuft. Wer die Entwicklung des Plugins nachvollziehen will, findet dazu auch unseren Release-Überblick zu Active Memory und dem überarbeiteten Plugin-System.

Diagnose: Wenn QMD die Suche nicht besser macht

QMD wird schnell als Wundermittel missverstanden. Laut Doku ist der Sidecar stark, weil er zusätzliche Ordner, Session-Transkripte und Reranking mitbringt. Aber QMD macht nur den Suchpfad besser, nicht die zugrunde liegende Gedächtnisstruktur.

Wichtige Stolperstellen aus der Dokumentation:

• QMD braucht eine funktionierende Installation auf dem Gateway-PATH.
• Der Standard-Workspace-Index umfasst MEMORY.md plus den memory/-Baum; eine root-Datei memory.md in Kleinbuchstaben wird nicht als Hauptspeicherdatei indexiert.
• Der anfängliche semantische Lauf kann langsam sein, weil QMD beim ersten qmd query GGUF-Modelle nachlädt.
• Wenn der Sidecar komplett scheitert, fällt OpenClaw automatisch auf die eingebaute SQLite-Engine zurück.

Das klingt bequem, hat aber einen Haken: Der Fallback hält die Suche am Leben, kann aber dein subjektives Gefühl erzeugen, QMD sei “an”, obwohl du gerade gar nicht von dessen besserem Recall profitierst. Die saubere Frage lautet also nicht nur “kommt ein Treffer?”, sondern “kommt ein Treffer mit QMD-Qualität oder nur über den Fallback?” Genau dafür nennt die Doku openclaw memory status und einmalige CLI-Probes als Prüfpfad.

Obsidian ist kein Fix für kaputten Recall

Viele Teams bauen gute Memory-Hygiene in Obsidian auf und wundern sich dann, warum der Agent trotzdem nicht sauber antwortet. Der Fehler steckt selten in Obsidian selbst.

Obsidian löst vor allem diese Aufgaben:

• Verdichtung von Tagesnotizen
• längerfristige Wissenspflege
• manuelle oder halbautomatische Strukturierung
• gemeinsamer Blick auf Notizen außerhalb des Chatverlaufs

Was Obsidian nicht automatisch löst:

• Recall direkt vor einer Antwort
• Suchabdeckung im Gateway
• Bootstrap-Truncation von MEMORY.md
• Session-spezifische Eligibility von Active Memory

Wenn dein Vault gut gepflegt ist, OpenClaw aber trotzdem “vergisst”, brauchst du fast immer entweder einen sauberen Import-/Index-Pfad oder du musst die dauerhaften Fakten wieder in den eigentlichen Workspace-Stack zurückführen. Obsidian macht Gedächtnis pflegbarer, aber nicht automatisch abrufbar.

Welche Kombination in der Praxis Sinn ergibt

Für die meisten Setups reicht schon eine nüchterne Aufgabentrennung:

• Builtin Memory allein für kleine, direkte Setups mit wenig Langzeitballast.
• Builtin Memory plus Active Memory für direkte Chats, in denen Vorlieben und laufende Themen rechtzeitig auftauchen sollen.
• Builtin Memory plus QMD für Workspaces mit vielen Dateien, längeren Session-Historien oder zusätzlicher Dokumentation.
• Builtin Memory plus QMD plus Obsidian für Teams oder Einzel-Operatoren, die Rohmaterial nicht nur finden, sondern über Wochen sauber kuratieren wollen.

Wenn du bereits bei dieser Kombination überfordert bist, ist der Fehler nicht fehlende Technik, sondern zu viel System auf einmal. Dann hilft ein Rückschritt mehr als der nächste Sidecar.

Reality Check

Dieser Guide ist kein Plädoyer dafür, jede OpenClaw-Instanz sofort mit Active Memory, QMD und externem Vault auszustatten.

• Builtin Memory bleibt die robuste Basis.
• Active Memory ist nur dort sinnvoll, wo personalisierte Kontinuität im aktiven Chat wirklich zählt.
• QMD bringt erst dann Mehrwert, wenn du mehr suchst als die Standarddateien.
• Obsidian lohnt sich vor allem für kuratierte Langzeitpflege, nicht als Notfallpflaster für kaputtes Retrieval.

Die ehrliche Diagnose lautet deshalb oft: Dein Memory-Problem ist weniger ein Modellproblem als ein falsch geschnittener Stack.

FAQ: Was tun, wenn OpenClaw sich trotzdem nichts merkt?

OpenClaw kennt Fakten aus MEMORY.md nicht mehr zuverlässig.
Prüfe zuerst, ob MEMORY.md kuratiert bleibt oder längst als Journal missbraucht wird. Danach schau mit /context list, /context detail oder openclaw doctor, ob die injizierte Kopie gekürzt wird.

Active Memory ist eingeschaltet, aber ich sehe keinen Unterschied.
Kontrolliere, ob du überhaupt in einem unterstützten Session-Typ unterwegs bist. Standardmäßig laufen direkte Chats, aber keine Gruppen, Heartbeats oder Hintergrundpfade. Sichtbar wird der Recall-Pass erst mit /verbose on oder /trace on.

QMD ist aktiviert, aber Treffer bleiben dünn.
Dann ist entweder der Sidecar nicht sauber verfügbar, du suchst nur über den Fallback oder die relevanten Dateien liegen gar nicht im indexierten Pfad. Besonders tückisch: eine root-Datei memory.md in Kleinbuchstaben zählt laut Doku nicht als primäre Workspace-Memory-Datei.

Reicht Obsidian allein als Langzeitgedächtnis?
Nein. Obsidian ist ein guter Kurationsraum, aber kein automatischer Recall-Mechanismus. Ohne sauberen Abrufpfad bleibt dein Vault für OpenClaw eher Bibliothek als Arbeitsspeicher.