OpenClaw Memory funktioniert nicht? Recall, QMD und Obsidian sauber prüfen

OpenClaw kennt eine eben gespeicherte Information im nächsten Chat nicht mehr. Die Datei liegt im Workspace, memory_search findet grundsätzlich Treffer, und trotzdem fehlt der richtige Kontext in der Antwort. Wer jetzt gleichzeitig an QMD, Active Memory und Obsidian dreht, verwischt die Ursache.

Erst den Layer finden.

Builtin Memory hält das Wissen in Dateien. Active Memory kann passenden Recall vor eine Antwort schieben. QMD erweitert die Suche über größere Bestände. Obsidian bleibt ein Kurationsraum, bis ein definierter Abrufpfad den Vault mit OpenClaw verbindet.

Vor der Diagnose gehört die installierte Version auf den Tisch, denn Pluginverhalten und verfügbare Statusbefehle können sich zwischen OpenClaw-Releases ändern. Prüfe die folgenden Schritte deshalb gegen den lokalen Hilfetext und die aktive Konfiguration.

Vier Layer, vier Aufgaben

Builtin Memory ist die Basis. Dauerhafte, kuratierte Fakten gehören in MEMORY.md; Tageskontext liegt in memory/YYYY-MM-DD.md. OpenClaw besitzt hinter diesen Dateien kein verlässliches verborgenes Langzeitgedächtnis. Was später gebraucht wird, muss gespeichert und im passenden Moment auffindbar sein.

Active Memory ergänzt diesen Pfad um gezielten Recall vor einer Antwort. Ob der Schritt läuft, hängt vom aktiven Plugin und der konkreten Session ab. Gruppen, Heartbeats oder interne Läufe können anders behandelt werden als ein persistenter Direktchat.

QMD erweitert das Retrieval. Der Sidecar kann zusätzliche Verzeichnisse und Session-Transkripte indexieren. Fällt er aus, kann die eingebaute SQLite-Suche übernehmen; damit bleiben Treffer möglich, obwohl gerade kein QMD-Ranking arbeitet.

Obsidian ordnet Wissen über längere Zeit. Für OpenClaw wird ein Vault erst durch einen festgelegten Import- oder Indexpfad relevant.

Für die Workspace-Grundlagen passt ergänzend unser Tutorial zu SOUL.md, MEMORY.md und Tagesnotizen. Die getrennte Vault-Anbindung erklärt ObsidianClaw im Vault.

Schritt 1: Den Builtin-Pfad prüfen

Lege einen kontrollierten Testfakt an, etwa: „Das interne Testprojekt heißt Kormoran.“ Speichere ihn dort, wo er fachlich hingehört, starte den vorgesehenen Chatpfad und frage später gezielt danach.

Der Test ist erfolgreich, wenn der Fakt in der richtigen Datei steht, über den Memory-Suchpfad auffindbar ist und im passenden Kontext erscheint. Liefert die Suche keinen Treffer oder erreicht nur ein gekürzter Ausschnitt aus MEMORY.md die Session, liegt der Fehler bereits in der Basis.

Prüfe zuerst MEMORY.md. Sie sollte eine kompakte Auswahl dauerhafter Fakten enthalten. Tagesereignisse bleiben in memory/YYYY-MM-DD.md, bis ein Punkt langfristig wichtig wird und in die kuratierte Datei wandert. Auch der Name zählt: Eine root-Datei memory.md in Kleinbuchstaben übernimmt nicht die Rolle der primären Workspace-Memory-Datei.

Mit /context list und /context detail lässt sich untersuchen, welcher Kontext tatsächlich in der Session angekommen ist. openclaw doctor hilft bei allgemeinen Installations- und Konfigurationsproblemen. Zeigt die Kontextansicht eine gekürzte Langzeitdatei, lagere Rohmaterial aus, verdichte die Dauerfakten und wiederhole den Kormoran-Test.

Noch kein QMD.

Eine überfüllte MEMORY.md wird durch einen zusätzlichen Suchlayer nicht sauberer.

Schritt 2: Active Memory in der richtigen Session testen

Der Builtin-Test funktioniert, doch passende Fakten tauchen vor einer Antwort nicht rechtzeitig auf. Jetzt ist Active Memory ein sinnvoller Kandidat.

Kontrolliere, ob das Plugin aktiv ist und der aktuelle Agent teilnehmen darf. Danach prüfst du den Session-Typ. Ein persistenter Direktchat kann Recall erhalten, während Gruppe, Heartbeat oder One-shot ohne Active-Memory-Spur bleiben.

/active-memory status ist ein guter Startpunkt, sofern deine installierte Version diesen Befehl anbietet. /verbose on und /trace on können zusätzliche Hinweise sichtbar machen. Frühere Defaults wie allowedChatTypes: ["direct"] solltest du nie ungeprüft übernehmen; maßgeblich sind die lokale Konfiguration und die Dokumentation deiner Version.

Ein passender Status zeigt den erwarteten Chat und einen ausgeführten Recall-Schritt. Fehlt diese Spur vollständig, teste denselben Fakt in einem unterstützten persistenten Direktchat. Bleibt der Unterschied zwischen Direktchat und Hintergrundlauf reproduzierbar, liegt die Ursache bei Eligibility oder Session-Typ und nicht in den gespeicherten Dateien.

Der Recovery-Weg ist klein: Pluginstatus prüfen, Agent freischalten und den Test erneut ausführen. Den erlaubten Chatumfang erweiterst du erst danach bewusst, weil eine großzügige Freigabe zusätzlichen Kontext und ein reales Datenschutzrisiko erzeugt.

Schritt 3: QMD vom Fallback unterscheiden

QMD lohnt sich bei vielen Dateien oder langen Session-Historien. Der Sidecar muss auf dem Gateway-PATH verfügbar sein, und seine Indexquellen müssen erreichbar sein. Beim initialen semantischen Lauf können Modelle oder Indexdaten nachgeladen werden, wodurch der Aufbau länger dauert.

Nutze openclaw memory status, um Backend und Indexzustand zu prüfen. Danach suchst du nach einem Begriff, der ausschließlich in einer zusätzlichen QMD-Quelle vorkommt. Der Kormoran-Test aus MEMORY.md reicht hier nicht, weil ihn auch die eingebaute Suche finden kann.

Der belastbare Beleg ist ein aktiver QMD-Status zusammen mit dem Treffer aus der zusätzlichen Quelle. Bleibt dieser Inhalt unsichtbar oder weist der Status auf SQLite, kontrolliere Sidecar und PATH; anschließend prüfst du die betroffene Indexquelle und lässt denselben Suchtest erneut laufen.

Kein Treffer? Stopp.

Solange QMD unklar ist, bleibt der SQLite-Fallback der sichere Rückbauzustand. Dokumentiere, dass Reichweite und Ranking vom vorgesehenen Pfad abweichen. Damit wird aus dem diffusen Gefühl „Memory ist schlechter“ ein überprüfbares Backendproblem.

Schritt 4: Obsidian mit einem Abrufvertrag anbinden

Ein Vault hilft bei der langfristigen Kuratierung. Für Recall braucht OpenClaw eine eindeutige Vereinbarung: Welcher Bereich darf indexiert werden, wann werden Änderungen übernommen und welche Dauerfakten bleiben direkt im Workspace?

Teste diese Verbindung mit einer Notiz, die nur im freigegebenen Vault-Bereich liegt. Bleibt sie unsichtbar, untersuche zuerst den Import- oder Indexpfad. Kopiere nicht vorschnell den gesamten Vault nach MEMORY.md; damit verschiebst du das Problem in das Bootstrap-Budget.

Ein Stack, der sich zurückbauen lässt

Für kleine Setups reicht Builtin Memory oft aus. Active Memory ergänzt direkte Chats um gezielten Recall. QMD passt zu größeren Suchräumen. Obsidian kommt hinzu, wenn Kuratierung eine eigene Arbeitsstufe ist.

Sobald die Diagnose unübersichtlich wird, baue auf Builtin Memory zurück. Wiederhole den Kormoran-Test und schalte danach genau eine Erweiterung zu. Der fehlerhafte Layer bleibt so sichtbar.

Ich halte diese Reihenfolge für die wichtigste Betriebsregel des gesamten Stacks: Jeder zusätzliche Memory-Layer braucht einen eigenen Test, einen sichtbaren Status und einen Rückbauweg, bevor er dauerhaft aktiv bleibt. Ohne diese Absicherung wächst die Infrastruktur schneller als die Zuverlässigkeit.

FAQ

OpenClaw kennt Fakten aus MEMORY.md nicht zuverlässig.
Prüfe den Dateinamen und den tatsächlich injizierten Kontext mit /context list beziehungsweise /context detail. Bei Kürzung wird die Langzeitdatei verdichtet; Rohmaterial gehört in Tageslogs oder andere Ablagen.

Active Memory ist eingeschaltet, zeigt aber keinen Effekt.
Kontrolliere Pluginstatus und Agentfreigabe. Wiederhole den Test anschließend in einem unterstützten persistenten Direktchat und prüfe die Befehle deiner installierten Version.

QMD ist aktiviert, zusätzliche Quellen fehlen aber.
openclaw memory status zeigt, ob QMD arbeitet oder SQLite übernimmt. Bleibt eine exklusive QMD-Testnotiz unsichtbar, prüfe Sidecar, PATH und die konkrete Indexquelle.

Reicht Obsidian als Langzeitgedächtnis?
Der Vault übernimmt die Kuratierung. Ein definierter Import- oder Indexpfad bringt dieses Wissen in den Recall.