Vai al contenuto principale
Dreaming è il sistema di consolidamento della memoria in background in memory-core. Aiuta OpenClaw a spostare i segnali forti a breve termine nella memoria durevole mantenendo il processo spiegabile e revisionabile.
Dreaming è opt-in ed è disabilitato per impostazione predefinita.

​
Cosa scrive Dreaming

Dreaming mantiene due tipi di output:
  • Stato macchina in memory/.dreams/ (archivio di richiamo, segnali di fase, checkpoint di ingestion, lock).
  • Output leggibile dalle persone in DREAMS.md (o dreams.md esistente) e file opzionali di report di fase sotto memory/dreaming/<phase>/YYYY-MM-DD.md.
La promozione a lungo termine continua a scrivere solo in MEMORY.md.

​
Modello delle fasi

Dreaming usa tre fasi cooperative:
FaseScopoScrittura durevole
LightOrdinare e preparare materiale recente a breve termineNo
DeepValutare e promuovere candidati durevoliSì (MEMORY.md)
REMRiflettere su temi e idee ricorrentiNo
Queste fasi sono dettagli interni di implementazione, non “modalità” separate configurate dall’utente.
La fase Light acquisisce segnali recenti di memoria giornaliera e tracce di richiamo, li deduplica e prepara righe candidate.
  • Legge dallo stato di richiamo a breve termine, dai file recenti di memoria giornaliera e dalle trascrizioni di sessione redatte quando disponibili.
  • Scrive un blocco gestito ## Light Sleep quando lo storage include output inline.
  • Registra segnali di rinforzo per il ranking deep successivo.
  • Non scrive mai in MEMORY.md.
La fase Deep decide cosa diventa memoria a lungo termine.
  • Classifica i candidati usando scoring ponderato e gate di soglia.
  • Richiede che minScore, minRecallCount e minUniqueQueries siano superati.
  • Reidrata gli snippet dai file giornalieri live prima di scrivere, quindi gli snippet obsoleti/eliminati vengono saltati.
  • Accoda le voci promosse a MEMORY.md.
  • Scrive un riepilogo ## Deep Sleep in DREAMS.md e facoltativamente scrive memory/dreaming/deep/YYYY-MM-DD.md.
La fase REM estrae pattern e segnali riflessivi.
  • Costruisce riepiloghi di temi e riflessioni da tracce recenti a breve termine.
  • Scrive un blocco gestito ## REM Sleep quando lo storage include output inline.
  • Registra segnali di rinforzo REM usati dal ranking deep.
  • Non scrive mai in MEMORY.md.

​
Ingestion delle trascrizioni di sessione

Dreaming può acquisire trascrizioni di sessione redatte nel corpus di Dreaming. Quando le trascrizioni sono disponibili, vengono fornite alla fase Light insieme ai segnali di memoria giornaliera e alle tracce di richiamo. I contenuti personali e sensibili vengono redatti prima dell’ingestion.

​
Diario dei sogni

Dreaming mantiene anche un Diario dei sogni narrativo in DREAMS.md. Dopo che ogni fase ha materiale sufficiente, memory-core esegue in background un turno subagent best-effort e accoda una breve voce di diario. Usa il modello runtime predefinito a meno che dreaming.model non sia configurato. Se il modello configurato non è disponibile, il Diario dei sogni riprova una volta con il modello predefinito della sessione.
Questo diario è destinato alla lettura umana nella UI Sogni, non è una fonte di promozione. Gli artefatti di diario/report generati da Dreaming sono esclusi dalla promozione a breve termine. Solo gli snippet di memoria fondati sono idonei alla promozione in MEMORY.md.
Esiste anche un percorso di backfill storico fondato per attività di revisione e recupero:
  • memory rem-harness --path ... --grounded visualizza in anteprima output di diario fondato da note storiche YYYY-MM-DD.md.
  • memory rem-backfill --path ... scrive voci di diario fondate e reversibili in DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term prepara candidati durevoli fondati nello stesso archivio di evidenze a breve termine che la normale fase Deep usa già.
  • memory rem-backfill --rollback e --rollback-short-term rimuovono quegli artefatti di backfill preparati senza toccare le voci ordinarie del diario o il richiamo live a breve termine.
La Control UI espone lo stesso flusso di backfill/reset del diario, così puoi ispezionare i risultati nella scena Sogni prima di decidere se i candidati fondati meritano la promozione. La Scena mostra anche un percorso fondato distinto, così puoi vedere quali voci a breve termine preparate provenivano dal replay storico, quali elementi promossi erano guidati da contenuti fondati, e cancellare solo le voci preparate esclusivamente fondate senza toccare lo stato ordinario live a breve termine.

​
Segnali di ranking Deep

Il ranking Deep usa sei segnali base ponderati più il rinforzo di fase:
SegnalePesoDescrizione
Frequenza0.24Quanti segnali a breve termine ha accumulato la voce
Rilevanza0.30Qualità media del recupero per la voce
Diversità delle query0.15Contesti distinti di query/giorno che l’hanno fatta emergere
Recenza0.15Punteggio di freschezza con decadimento temporale
Consolidamento0.10Forza della ricorrenza su più giorni
Ricchezza concettuale0.06Densità di tag concettuali da snippet/percorso
Gli hit delle fasi Light e REM aggiungono un piccolo boost con decadimento della recenza da memory/.dreams/phase-signals.json. I risultati delle prove shadow possono essere stratificati sopra quel punteggio base come segnale di revisione prima di qualsiasi scrittura durevole. Una prova utile dà al candidato un piccolo boost limitato, una prova neutra lo mantiene rinviato, e una prova dannosa lo contrassegna come rifiutato per quel passaggio di scoring. Questo segnale resta comunque solo di report: può modificare l’ordinamento dei candidati o i metadati di revisione, ma non scrive in MEMORY.md né promuove il candidato autonomamente.

​
Copertura del report di prova shadow QA

QA Lab include uno scenario solo di report per esplorare come una futura prova shadow di Dreaming potrebbe revisionare una memoria candidata prima della promozione. Lo scenario chiede a un agent di confrontare una risposta baseline con una risposta che può usare la memoria candidata, quindi scrivere un report locale con verdetto, motivazione e flag di rischio. Questa copertura è intenzionalmente limitata alla QA. Verifica che l’artefatto di report rimanga separato da MEMORY.md e che l’agent non affermi che il candidato sia stato promosso. Non aggiunge comportamento di prova shadow in produzione né modifica il motore di promozione della fase Deep. Il runner di prova shadow di memory-core mantiene lo stesso contratto solo di report per i percorsi di codice che richiedono un artefatto stabile. Accetta candidato, prompt della prova, risultato baseline, risultato del candidato, verdetto, motivazione, flag di rischio e riferimenti alle evidenze, quindi scrive un report con promotion action: report-only. I verdetti utili mappano a una raccomandazione promote, i verdetti neutrali mappano a defer, e i verdetti dannosi mappano a reject; nessuna di queste raccomandazioni scrive in MEMORY.md né applica la promozione della fase Deep.

​
Pianificazione

Quando abilitato, memory-core gestisce automaticamente un job cron per una sweep completa di Dreaming. Ogni sweep esegue le fasi in ordine: light → REM → deep. La sweep include il workspace runtime primario e tutti i workspace agent configurati, deduplicati per percorso, così il fan-out dei workspace subagent non esclude DREAMS.md e lo stato della memoria dell’agent principale. Comportamento della cadenza predefinita:
ImpostazionePredefinito
dreaming.frequency0 3 * * *
dreaming.modelmodello predefinito

​
Avvio rapido

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

​
Comando slash

/dreaming status
/dreaming on
/dreaming off
/dreaming help
/dreaming on e /dreaming off modificano la configurazione a livello di Gateway. I chiamanti di canale devono essere proprietari, e i client Gateway devono avere operator.admin. /dreaming status e /dreaming help restano in sola lettura.

​
Flusso di lavoro CLI

openclaw memory promote
openclaw memory promote --apply
openclaw memory promote --limit 5
openclaw memory status --deep
Il comando manuale memory promote usa per impostazione predefinita le soglie della fase Deep, salvo override con flag CLI.

​
Impostazioni predefinite principali

Tutte le impostazioni si trovano sotto plugins.entries.memory-core.config.dreaming.
​
enabled
boolean
predefinito:"false"
Abilita o disabilita la sweep di Dreaming.
​
frequency
string
predefinito:"0 3 * * *"
Cadenza Cron per la sweep completa di Dreaming.
​
model
string
Override opzionale del modello subagent per il Diario dei sogni. Usa un valore canonico provider/model quando imposti anche una allowlist allowedModels per subagent.
​
phases.deep.maxPromotedSnippetTokens
number
predefinito:"160"
Numero massimo stimato di token mantenuto da ogni snippet di richiamo a breve termine promosso in MEMORY.md. La provenienza del ranking resta visibile.
dreaming.model richiede plugins.entries.memory-core.subagent.allowModelOverride: true. Per limitarlo, imposta anche plugins.entries.memory-core.subagent.allowedModels. I fallimenti di attendibilità o allowlist restano visibili invece di ricadere silenziosamente su altro; il retry copre solo gli errori di modello non disponibile.
La maggior parte delle policy di fase, delle soglie e del comportamento di storage sono dettagli interni di implementazione. Consulta il riferimento di configurazione della memoria per l’elenco completo delle chiavi.

​
UI Sogni

Quando abilitata, la scheda Sogni del Gateway mostra:
  • stato corrente di abilitazione di Dreaming
  • stato a livello di fase e presenza della sweep gestita
  • conteggi a breve termine, fondati, di segnale e promossi oggi
  • tempistica della prossima esecuzione pianificata
  • un percorso Scena fondato distinto per voci di replay storico preparate
  • un lettore espandibile del Diario dei sogni supportato da doctor.memory.dreamDiary

​
Dreaming non viene mai eseguito: lo stato mostra blocked

Se openclaw memory status riporta Dreaming status: blocked, il cron gestito esiste ma l’heartbeat dell’agent predefinito non sta scattando. Verifica che heartbeat sia abilitato per l’agent predefinito e che il suo target non sia none, quindi esegui di nuovo openclaw memory status --deep dopo il successivo intervallo heartbeat.

​
Correlati