Sessions and memory
Speicherübersicht
OpenClaw merkt sich Dinge, indem es einfache Markdown-Dateien im Workspace Ihres Agenten schreibt. Das Modell „erinnert“ sich nur an das, was auf der Festplatte gespeichert wird – es gibt keinen verborgenen Zustand.
Funktionsweise
Ihr Agent hat drei speicherbezogene Dateien:
MEMORY.md– Langzeitspeicher. Dauerhafte Fakten, Präferenzen und Entscheidungen. Wird zu Beginn jeder DM-Sitzung geladen.memory/YYYY-MM-DD.md– tägliche Notizen. Laufender Kontext und Beobachtungen. Die Notizen von heute und gestern werden automatisch geladen.DREAMS.md(optional) – Dream Diary und Zusammenfassungen von Dreaming-Durchläufen zur menschlichen Überprüfung, einschließlich fundierter historischer Backfill-Einträge.
Diese Dateien befinden sich im Agent-Workspace (Standard: ~/.openclaw/workspace).
Was wohin gehört
MEMORY.md ist die kompakte, kuratierte Ebene. Verwenden Sie sie für dauerhafte Fakten,
Präferenzen, bestehende Entscheidungen und kurze Zusammenfassungen, die zu Beginn
einer privaten Hauptsitzung verfügbar sein sollten. Sie ist nicht als Rohtranskript,
Tagesprotokoll oder vollständiges Archiv gedacht.
memory/YYYY-MM-DD.md-Dateien sind die Arbeitsebene. Verwenden Sie sie für detaillierte tägliche
Notizen, Beobachtungen, Sitzungszusammenfassungen und Rohkontext, der später noch nützlich
sein kann. Diese Dateien werden für memory_search und memory_get indiziert, aber sie werden
nicht bei jedem Turn in den normalen Bootstrap-Prompt eingefügt.
Mit der Zeit soll der Agent nützliches Material aus täglichen Notizen in
MEMORY.md destillieren und veraltete Langzeiteinträge entfernen. Die generierten Workspace-
Anweisungen und der Heartbeat-Ablauf können das regelmäßig erledigen; Sie müssen
MEMORY.md nicht für jedes gemerkte Detail manuell bearbeiten.
Wenn MEMORY.md das Bootstrap-Dateibudget überschreitet, lässt OpenClaw die Datei auf
der Festplatte intakt, kürzt aber die Kopie, die in den Modellkontext eingefügt wird. Betrachten Sie das als
Signal, detailliertes Material zurück nach memory/*.md zu verschieben, nur die
dauerhafte Zusammenfassung in MEMORY.md zu behalten oder die Bootstrap-Grenzen zu erhöhen, wenn Sie ausdrücklich
mehr Prompt-Budget dafür verwenden möchten. Verwenden Sie /context list, /context detail oder
openclaw doctor, um Roh- und eingefügte Größen sowie den Kürzungsstatus zu sehen.
Abgeleitete Verpflichtungen
Manche zukünftigen Follow-ups sind keine dauerhaften Fakten. Wenn Sie ein Vorstellungsgespräch
morgen erwähnen, kann die nützliche Erinnerung „nach dem Vorstellungsgespräch nachfragen“ sein, nicht „dies
für immer in MEMORY.md speichern“.
Commitments sind optionale, kurzlebige Follow-up-Erinnerungen für diesen Fall. OpenClaw leitet sie in einem verborgenen Hintergrunddurchlauf ab, begrenzt sie auf denselben Agenten und Kanal und liefert fällige Nachfragen über Heartbeat aus. Explizite Erinnerungen verwenden weiterhin scheduled tasks.
Speicherwerkzeuge
Der Agent hat zwei Werkzeuge für die Arbeit mit Speicher:
memory_search– findet relevante Notizen per semantischer Suche, auch wenn die Formulierung vom Original abweicht.memory_get– liest eine bestimmte Speicherdatei oder einen Zeilenbereich.
Beide Werkzeuge werden vom Active Memory-Plugin bereitgestellt (Standard: memory-core).
Begleit-Plugin für Memory Wiki
Wenn Sie möchten, dass dauerhafter Speicher sich eher wie eine gepflegte Wissensdatenbank verhält
als nur wie rohe Notizen, verwenden Sie das gebündelte Plugin memory-wiki.
memory-wiki kompiliert dauerhaftes Wissen in einen Wiki-Tresor mit:
- deterministischer Seitenstruktur
- strukturierten Behauptungen und Belegen
- Verfolgung von Widersprüchen und Aktualität
- generierten Dashboards
- kompilierten Zusammenfassungen für Agent-/Runtime-Verbraucher
- wiki-nativen Werkzeugen wie
wiki_search,wiki_get,wiki_applyundwiki_lint
Es ersetzt das Active Memory-Plugin nicht. Das Active Memory-Plugin bleibt weiterhin
für Abruf, Beförderung und Dreaming zuständig. memory-wiki fügt daneben eine
provenienzreiche Wissensebene hinzu.
Siehe Memory Wiki.
Speichersuche
Wenn ein Embedding-Provider konfiguriert ist, verwendet memory_search hybride
Suche – eine Kombination aus Vektorähnlichkeit (semantische Bedeutung) und Schlüsselwortabgleich
(exakte Begriffe wie IDs und Codesymbole). Das funktioniert sofort, sobald Sie
einen API-Schlüssel für einen unterstützten Provider haben.
Details zur Funktionsweise der Suche, zu Tuning-Optionen und zur Provider-Einrichtung finden Sie unter Memory Search.
Speicher-Backends
SQLite-basiert. Funktioniert sofort mit Schlüsselwortsuche, Vektorähnlichkeit und hybrider Suche. Keine zusätzlichen Abhängigkeiten.
Local-first-Sidecar mit Reranking, Abfrageerweiterung und der Möglichkeit, Verzeichnisse außerhalb des Workspace zu indizieren.
KI-nativer sitzungsübergreifender Speicher mit Benutzermodellierung, semantischer Suche und Multi-Agent-Bewusstsein. Plugin-Installation.
Gebündelter LanceDB-gestützter Speicher mit OpenAI-kompatiblen Embeddings, Auto-Recall, Auto-Capture und lokaler Ollama-Embedding-Unterstützung.
Wissens-Wiki-Ebene
Automatischer Speicher-Flush
Bevor Compaction Ihre Unterhaltung zusammenfasst, führt OpenClaw einen stillen Turn aus, der den Agenten daran erinnert, wichtigen Kontext in Speicherdateien zu speichern. Das ist standardmäßig aktiviert – Sie müssen nichts konfigurieren.
Um diesen Haushaltungs-Turn auf einem lokalen Modell auszuführen, setzen Sie ein exaktes Modell- Override für den Speicher-Flush:
{ "agents": { "defaults": { "compaction": { "memoryFlush": { "model": "ollama/qwen3:8b" } } } }}Das Override gilt nur für den Speicher-Flush-Turn und erbt nicht die Fallback-Kette der aktiven Sitzung.
Dreaming
Dreaming ist ein optionaler Hintergrund-Konsolidierungsdurchlauf für Speicher. Es sammelt
kurzfristige Signale, bewertet Kandidaten und befördert nur qualifizierte Elemente in den
Langzeitspeicher (MEMORY.md).
Es ist darauf ausgelegt, den Langzeitspeicher signalstark zu halten:
- Optional: standardmäßig deaktiviert.
- Geplant: wenn aktiviert, verwaltet
memory-coreautomatisch einen wiederkehrenden Cron-Job für einen vollständigen Dreaming-Durchlauf. - Schwellenwertbasiert: Beförderungen müssen Bewertungs-, Abrufhäufigkeits- und Abfrage- Diversitäts-Gates bestehen.
- Überprüfbar: Phasenzusammenfassungen und Tagebucheinträge werden zur menschlichen Überprüfung
in
DREAMS.mdgeschrieben.
Details zum Phasenverhalten, zu Bewertungssignalen und zum Dream Diary finden Sie unter Dreaming.
Fundierter Backfill und Live-Beförderung
Das Dreaming-System hat jetzt zwei eng verwandte Prüfpfade:
- Live-Dreaming arbeitet aus dem kurzfristigen Dreaming-Speicher unter
memory/.dreams/und wird von der normalen Deep-Phase verwendet, wenn entschieden wird, was inMEMORY.mdaufsteigen kann. - Fundierter Backfill liest historische
memory/YYYY-MM-DD.md-Notizen als eigenständige Tagesdateien und schreibt strukturierte Prüfausgaben inDREAMS.md.
Fundierter Backfill ist nützlich, wenn Sie ältere Notizen erneut durchspielen und prüfen möchten, was
das System für dauerhaft hält, ohne MEMORY.md manuell zu bearbeiten.
Wenn Sie Folgendes verwenden:
openclaw memory rem-backfill --path ./memory --stage-short-termwerden die fundierten dauerhaften Kandidaten nicht direkt befördert. Sie werden in denselben kurzfristigen Dreaming-Speicher gestellt, den die normale Deep-Phase bereits verwendet. Das bedeutet:
DREAMS.mdbleibt die Oberfläche für menschliche Überprüfung.- der kurzfristige Speicher bleibt die maschinenseitige Ranking-Oberfläche.
MEMORY.mdwird weiterhin nur durch Deep-Beförderung geschrieben.
Wenn Sie entscheiden, dass die Wiederholung nicht nützlich war, können Sie die bereitgestellten Artefakte entfernen, ohne gewöhnliche Tagebucheinträge oder den normalen Recall-Zustand anzutasten:
openclaw memory rem-backfill --rollbackopenclaw memory rem-backfill --rollback-short-termCLI
openclaw memory status # Indexstatus und Provider prüfenopenclaw memory search "query" # Über die Befehlszeile suchenopenclaw memory index --force # Index neu erstellenWeitere Informationen
- Builtin memory engine: Standard-SQLite-Backend.
- QMD memory engine: fortgeschrittenes Local-first-Sidecar.
- Honcho memory: KI-nativer sitzungsübergreifender Speicher.
- Memory LanceDB: LanceDB-gestütztes Plugin mit OpenAI-kompatiblen Embeddings.
- Memory Wiki: kompilierter Wissenstresor und wiki-native Werkzeuge.
- Memory search: Suchpipeline, Provider und Tuning.
- Dreaming: Hintergrund-Beförderung von kurzfristigem Recall in den Langzeitspeicher.
- Memory configuration reference: alle Konfigurationsschalter.
- Compaction: wie Compaction mit Speicher interagiert.