English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisहिन्दीالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiРусскийفارسیไทย
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page

Sessions and memory

Dreaming

Dreaming ist das Hintergrundsystem zur Speicherkonsolidierung in memory-core. Es hilft OpenClaw dabei, starke Kurzzeitsignale in dauerhaften Speicher zu übertragen und den Prozess zugleich erklärbar und überprüfbar zu halten.

Was Dreaming schreibt

Dreaming behält zwei Arten von Ausgaben bei:

  • Maschinenzustand in memory/.dreams/ (Recall-Speicher, Phasensignale, Ingestions-Checkpoints, Sperren).
  • Für Menschen lesbare Ausgabe in DREAMS.md (oder der vorhandenen dreams.md) und optionalen Phasenberichtdateien unter memory/dreaming/<phase>/YYYY-MM-DD.md.

Langfristige Übernahme schreibt weiterhin nur nach MEMORY.md.

Phasenmodell

Dreaming verwendet drei kooperative Phasen:

Phase Zweck Dauerhafte Schreiboperation
Leicht Aktuelles Kurzzeitmaterial sortieren und bereitstellen Nein
Tief Dauerhafte Kandidaten bewerten und übernehmen Ja (MEMORY.md)
REM Über Themen und wiederkehrende Ideen reflektieren Nein

Diese Phasen sind interne Implementierungsdetails, keine separaten, von Benutzern konfigurierten „Modi“.

Leichtphase

Die Leichtphase nimmt aktuelle tägliche Speichersignale und Recall-Traces auf, dedupliziert sie und stellt Kandidatenzeilen bereit.

  • Liest aus dem Kurzzeit-Recall-Zustand, aktuellen täglichen Speicherdateien und redigierten Sitzungstranskripten, sofern verfügbar.
  • Schreibt einen verwalteten ## Light Sleep-Block, wenn der Speicher Inline-Ausgabe enthält.
  • Zeichnet Verstärkungssignale für ein späteres tiefes Ranking auf.
  • Schreibt niemals nach MEMORY.md.
Tiefphase

Die Tiefphase entscheidet, was zu langfristigem Speicher wird.

  • Bewertet Kandidaten mit gewichteter Bewertung und Schwellenwert-Gates.
  • Erfordert, dass minScore, minRecallCount und minUniqueQueries erfüllt sind.
  • Hydriert Snippets vor dem Schreiben erneut aus Live-Tagesdateien, sodass veraltete oder gelöschte Snippets übersprungen werden.
  • Hängt übernommene Einträge an MEMORY.md an.
  • Schreibt eine ## Deep Sleep-Zusammenfassung in DREAMS.md und schreibt optional memory/dreaming/deep/YYYY-MM-DD.md.
REM-Phase

Die REM-Phase extrahiert Muster und reflektierende Signale.

  • Erstellt Themen- und Reflexionszusammenfassungen aus aktuellen Kurzzeit-Traces.
  • Schreibt einen verwalteten ## REM Sleep-Block, wenn der Speicher Inline-Ausgabe enthält.
  • Zeichnet REM-Verstärkungssignale auf, die vom tiefen Ranking verwendet werden.
  • Schreibt niemals nach MEMORY.md.

Aufnahme von Sitzungstranskripten

Dreaming kann redigierte Sitzungstranskripte in den Dreaming-Korpus aufnehmen. Wenn Transkripte verfügbar sind, werden sie zusammen mit täglichen Speichersignalen und Recall-Traces in die Leichtphase eingespeist. Personenbezogene und sensible Inhalte werden vor der Aufnahme redigiert.

Traumtagebuch

Dreaming führt außerdem ein erzählerisches Traumtagebuch in DREAMS.md. Nachdem jede Phase genügend Material hat, führt memory-core im Hintergrund bestmöglich einen Subagent-Turn aus und hängt einen kurzen Tagebucheintrag an. Es verwendet das standardmäßige Laufzeitmodell, sofern dreaming.model nicht konfiguriert ist. Wenn das konfigurierte Modell nicht verfügbar ist, versucht es das Traumtagebuch einmal erneut mit dem standardmäßigen Sitzungsmodell.

Es gibt außerdem eine fundierte historische Backfill-Spur für Prüfungs- und Wiederherstellungsarbeiten:

Backfill-Befehle
  • memory rem-harness --path ... --grounded zeigt eine Vorschau fundierter Tagebuchausgabe aus historischen YYYY-MM-DD.md-Notizen.
  • memory rem-backfill --path ... schreibt reversible fundierte Tagebucheinträge in DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term stellt fundierte dauerhafte Kandidaten in denselben Kurzzeit-Evidenzspeicher ein, den die normale Tiefphase bereits verwendet.
  • memory rem-backfill --rollback und --rollback-short-term entfernen diese bereitgestellten Backfill-Artefakte, ohne gewöhnliche Tagebucheinträge oder Live-Kurzzeit-Recall zu berühren.

Die Control UI stellt denselben Tagebuch-Backfill-/Reset-Ablauf bereit, damit Sie Ergebnisse in der Dreams-Szene prüfen können, bevor Sie entscheiden, ob die fundierten Kandidaten eine Übernahme verdienen. Die Szene zeigt außerdem eine eigene fundierte Spur, sodass Sie sehen können, welche bereitgestellten Kurzzeiteinträge aus historischer Wiedergabe stammen, welche übernommenen Elemente fundiert geführt waren, und ausschließlich nur fundierte bereitgestellte Einträge löschen können, ohne den gewöhnlichen Live-Kurzzeitzustand zu berühren.

Signale für tiefes Ranking

Tiefes Ranking verwendet sechs gewichtete Basissignale plus Phasenverstärkung:

Signal Gewichtung Beschreibung
Häufigkeit 0.24 Wie viele Kurzzeitsignale der Eintrag angesammelt hat
Relevanz 0.30 Durchschnittliche Abrufqualität für den Eintrag
Abfragediversität 0.15 Verschiedene Abfrage-/Tageskontexte, in denen er aufgetaucht ist
Aktualität 0.15 Zeitlich abklingende Frischebewertung
Konsolidierung 0.10 Stärke der Wiederholung über mehrere Tage
Konzeptuelle Reichhaltigkeit 0.06 Dichte der Konzept-Tags aus Snippet/Pfad

Treffer aus Leicht- und REM-Phasen fügen einen kleinen, nach Aktualität abklingenden Boost aus memory/.dreams/phase-signals.json hinzu.

Shadow-Trial-Ergebnisse können als Prüfsignal vor jeder dauerhaften Schreiboperation auf diese Basisbewertung gelegt werden. Ein hilfreicher Trial gibt dem Kandidaten einen kleinen begrenzten Boost, ein neutraler Trial hält ihn zurückgestellt, und ein schädlicher Trial markiert ihn für diesen Bewertungsdurchlauf als abgelehnt. Dieses Signal bleibt weiterhin nur ein Berichtssignal: Es kann die Kandidatenreihenfolge oder Prüfmetadaten ändern, schreibt aber nicht nach MEMORY.md und übernimmt den Kandidaten nicht von selbst.

QA-Berichtsabdeckung für Shadow Trials

QA Lab enthält ein reines Berichtsszenario, um zu untersuchen, wie ein künftiger Dreaming-Shadow-Trial einen Kandidatenspeicher vor der Übernahme prüfen könnte. Das Szenario fordert einen Agenten auf, eine Basisantwort mit einer Antwort zu vergleichen, die den Kandidatenspeicher verwenden kann, und dann einen lokalen Bericht mit Urteil, Begründung und Risikoflags zu schreiben.

Diese Abdeckung ist bewusst auf QA beschränkt. Sie überprüft, dass das Berichtsartefakt von MEMORY.md getrennt bleibt und dass der Agent nicht behauptet, der Kandidat sei übernommen worden. Sie fügt kein Produktionsverhalten für Shadow Trials hinzu und ändert die Übernahme-Engine der Tiefphase nicht.

Der Shadow-Trial-Runner von memory-core behält denselben reinen Berichtsvertrag für Codepfade bei, die ein stabiles Artefakt benötigen. Er akzeptiert Kandidat, Trial-Prompt, Baseline-Ergebnis, Kandidatenergebnis, Urteil, Begründung, Risikoflags und Evidenzreferenzen und schreibt dann einen Bericht mit promotion action: report-only. Hilfreiche Urteile werden einer promote-Empfehlung zugeordnet, neutrale Urteile defer und schädliche Urteile reject; keine dieser Empfehlungen schreibt nach MEMORY.md oder wendet eine Tiefphasenübernahme an.

Zeitplanung

Wenn aktiviert, verwaltet memory-core automatisch einen Cron-Job für einen vollständigen Dreaming-Durchlauf. Jeder Durchlauf führt Phasen in dieser Reihenfolge aus: Leicht → REM → Tief.

Der Durchlauf umfasst den primären Laufzeit-Workspace und alle konfigurierten Agent-Workspaces, nach Pfad dedupliziert, sodass Subagent-Workspace-Fan-out das DREAMS.md und den Speicherzustand des Hauptagenten nicht ausschließt.

Standardverhalten der Taktung:

Einstellung Standard
dreaming.frequency 0 3 * * *
dreaming.model Standardmodell

Schnellstart

Dreaming aktivieren

json
{  "plugins": {    "entries": {      "memory-core": {        "config": {          "dreaming": {            "enabled": true          }        }      }    }  }}

Benutzerdefinierte Durchlauftaktung

json
{  "plugins": {    "entries": {      "memory-core": {        "config": {          "dreaming": {            "enabled": true,            "timezone": "America/Los_Angeles",            "frequency": "0 */6 * * *"          }        }      }    }  }}

Slash-Befehl

Code
/dreaming status/dreaming on/dreaming off/dreaming help

/dreaming on und /dreaming off ändern die Gateway-weite Konfiguration. Channel- Aufrufer müssen Besitzer sein, und Gateway-Clients müssen operator.admin haben. /dreaming status und /dreaming help bleiben schreibgeschützt.

CLI-Workflow

Übernahmevorschau / anwenden

bash
openclaw memory promoteopenclaw memory promote --applyopenclaw memory promote --limit 5openclaw memory status --deep

Manuelles memory promote verwendet standardmäßig Tiefphasen-Schwellenwerte, sofern sie nicht mit CLI-Flags überschrieben werden.

Übernahme erklären

Erklären Sie, warum ein bestimmter Kandidat übernommen würde oder nicht:

bash
openclaw memory promote-explain "router vlan"openclaw memory promote-explain "router vlan" --json

REM-Harness-Vorschau

Vorschau von REM-Reflexionen, Kandidatenwahrheiten und tiefer Übernahmeausgabe, ohne etwas zu schreiben:

bash
openclaw memory rem-harnessopenclaw memory rem-harness --json

Wichtige Standardwerte

Alle Einstellungen liegen unter plugins.entries.memory-core.config.dreaming.

enabledbooleandefault: false

Aktivieren oder deaktivieren Sie den Dreaming-Durchlauf.

frequencystringdefault: 0 3 * * *

Cron-Taktung für den vollständigen Dreaming-Durchlauf.

modelstring

Optionaler Modell-Override für den Traumtagebuch-Subagent. Verwenden Sie einen kanonischen provider/model-Wert, wenn Sie zugleich eine Subagent-allowedModels-Allowlist setzen.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

Maximale geschätzte Tokenanzahl, die aus jedem Kurzzeit-Recall-Snippet beibehalten wird, das nach MEMORY.md übernommen wird. Die Ranking-Herkunft bleibt sichtbar.

Dreams UI

Wenn aktiviert, zeigt der Gateway-Tab Dreams Folgendes:

  • aktuellen Aktivierungszustand von Dreaming
  • Status auf Phasenebene und Vorhandensein verwalteter Durchläufe
  • Kurzzeit-, fundierte, Signal- und Heute-übernommen-Zähler
  • Zeitpunkt des nächsten geplanten Laufs
  • eine eigene fundierte Szenenspur für bereitgestellte Einträge aus historischer Wiedergabe
  • einen ausklappbaren Traumtagebuch-Reader, gestützt durch doctor.memory.dreamDiary

Dreaming läuft nie: Status zeigt blockiert

Wenn openclaw memory status Dreaming status: blocked meldet, existiert der verwaltete Cron, aber der Heartbeat des Standardagenten wird nicht ausgelöst. Prüfen Sie, dass Heartbeat für den Standardagenten aktiviert ist und sein Ziel nicht none ist. Führen Sie anschließend nach dem nächsten Heartbeat-Intervall erneut openclaw memory status --deep aus.

Verwandt

Was this useful?
On this page

On this page