Pular para o conteúdo principal
Dreaming é o sistema de consolidação de memória em segundo plano em memory-core. Ele ajuda o OpenClaw a mover sinais fortes de curto prazo para memória durável, mantendo o processo explicável e revisável.
Dreaming é opt-in e vem desabilitado por padrão.

​
O que o Dreaming escreve

Dreaming mantém dois tipos de saída:
  • Estado de máquina em memory/.dreams/ (armazenamento de recall, sinais de fase, checkpoints de ingestão, bloqueios).
  • Saída legível por humanos em DREAMS.md (ou dreams.md existente) e arquivos opcionais de relatório de fase em memory/dreaming/<phase>/YYYY-MM-DD.md.
A promoção de longo prazo ainda escreve somente em MEMORY.md.

​
Modelo de fases

Dreaming usa três fases cooperativas:
FaseFinalidadeEscrita durável
LightClassificar e preparar material recente de curto prazoNão
DeepPontuar e promover candidatos duráveisSim (MEMORY.md)
REMRefletir sobre temas e ideias recorrentesNão
Essas fases são detalhes internos de implementação, não “modos” separados configurados pelo usuário.
A fase Light ingere sinais recentes de memória diária e rastros de recall, deduplica-os e prepara linhas candidatas.
  • Lê a partir do estado de recall de curto prazo, arquivos recentes de memória diária e transcrições de sessão redigidas quando disponíveis.
  • Escreve um bloco ## Light Sleep gerenciado quando o armazenamento inclui saída inline.
  • Registra sinais de reforço para ranqueamento Deep posterior.
  • Nunca escreve em MEMORY.md.
A fase Deep decide o que se torna memória de longo prazo.
  • Ranqueia candidatos usando pontuação ponderada e gates de limite.
  • Exige que minScore, minRecallCount e minUniqueQueries sejam aprovados.
  • Reidrata snippets a partir de arquivos diários ativos antes de escrever, para que snippets obsoletos/excluídos sejam ignorados.
  • Acrescenta entradas promovidas a MEMORY.md.
  • Escreve um resumo ## Deep Sleep em DREAMS.md e, opcionalmente, escreve memory/dreaming/deep/YYYY-MM-DD.md.
A fase REM extrai padrões e sinais reflexivos.
  • Cria resumos de temas e reflexões a partir de rastros recentes de curto prazo.
  • Escreve um bloco ## REM Sleep gerenciado quando o armazenamento inclui saída inline.
  • Registra sinais de reforço REM usados pelo ranqueamento Deep.
  • Nunca escreve em MEMORY.md.

​
Ingestão de transcrições de sessão

Dreaming pode ingerir transcrições de sessão redigidas no corpus de Dreaming. Quando transcrições estão disponíveis, elas são alimentadas na fase Light junto com sinais de memória diária e rastros de recall. Conteúdo pessoal e sensível é redigido antes da ingestão.

​
Diário de Sonhos

Dreaming também mantém um Diário de Sonhos narrativo em DREAMS.md. Depois que cada fase tem material suficiente, memory-core executa uma tentativa em segundo plano de subagente e acrescenta uma entrada curta de diário. Ele usa o modelo padrão do runtime, a menos que dreaming.model esteja configurado. Se o modelo configurado estiver indisponível, o Diário de Sonhos tenta novamente uma vez com o modelo padrão da sessão.
Este diário é para leitura humana na UI de Sonhos, não uma fonte de promoção. Artefatos de diário/relatório gerados por Dreaming são excluídos da promoção de curto prazo. Somente snippets de memória fundamentados são elegíveis para promoção para MEMORY.md.
Também há uma pista de preenchimento histórico fundamentado para trabalho de revisão e recuperação:
  • memory rem-harness --path ... --grounded pré-visualiza a saída fundamentada de diário a partir de notas históricas YYYY-MM-DD.md.
  • memory rem-backfill --path ... escreve entradas reversíveis de diário fundamentado em DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term prepara candidatos duráveis fundamentados no mesmo armazenamento de evidências de curto prazo que a fase Deep normal já usa.
  • memory rem-backfill --rollback e --rollback-short-term removem esses artefatos de preenchimento preparados sem tocar em entradas comuns de diário ou recall ativo de curto prazo.
A UI de Controle expõe o mesmo fluxo de preenchimento/redefinição de diário para que você possa inspecionar os resultados na cena Sonhos antes de decidir se os candidatos fundamentados merecem promoção. A Cena também mostra uma pista fundamentada distinta para que você possa ver quais entradas de curto prazo preparadas vieram de replay histórico, quais itens promovidos foram liderados por fundamentação, e limpar somente entradas preparadas exclusivamente fundamentadas sem tocar no estado comum ativo de curto prazo.

​
Sinais de ranqueamento Deep

O ranqueamento Deep usa seis sinais base ponderados mais reforço de fase:
SinalPesoDescrição
Frequência0.24Quantos sinais de curto prazo a entrada acumulou
Relevância0.30Qualidade média de recuperação da entrada
Diversidade de consulta0.15Contextos distintos de consulta/dia que a revelaram
Recenticidade0.15Pontuação de frescor com decaimento temporal
Consolidação0.10Força de recorrência em múltiplos dias
Riqueza conceitual0.06Densidade de tags de conceito do snippet/caminho
Acertos das fases Light e REM adicionam um pequeno impulso com decaimento de recenticidade a partir de memory/.dreams/phase-signals.json. Resultados de testes sombra podem ser sobrepostos a essa pontuação base como um sinal de revisão antes de qualquer escrita durável. Um teste útil dá ao candidato um pequeno impulso limitado, um teste neutro o mantém adiado, e um teste prejudicial o marca como rejeitado para aquela passagem de pontuação. Esse sinal ainda é somente de relatório: ele pode alterar a ordenação de candidatos ou metadados de revisão, mas não escreve em MEMORY.md nem promove o candidato por conta própria.

​
Cobertura de relatório de teste sombra de QA

O QA Lab inclui um cenário somente de relatório para explorar como um futuro teste sombra de Dreaming poderia revisar uma memória candidata antes da promoção. O cenário pede que um agente compare uma resposta de baseline com uma resposta que pode usar a memória candidata e, então, escreva um relatório local com um veredito, motivo e flags de risco. Essa cobertura é intencionalmente limitada ao QA. Ela verifica que o artefato de relatório permanece separado de MEMORY.md e que o agente não afirma que o candidato foi promovido. Ela não adiciona comportamento de teste sombra em produção nem altera o mecanismo de promoção da fase Deep. O executor de teste sombra de memory-core mantém esse mesmo contrato somente de relatório para caminhos de código que precisam de um artefato estável. Ele aceita o candidato, prompt do teste, resultado de baseline, resultado do candidato, veredito, motivo, flags de risco e referências de evidência; então escreve um relatório com promotion action: report-only. Vereditos úteis mapeiam para uma recomendação promote, vereditos neutros mapeiam para defer, e vereditos prejudiciais mapeiam para reject; nenhuma dessas recomendações escreve em MEMORY.md nem aplica promoção da fase Deep.

​
Agendamento

Quando habilitado, memory-core gerencia automaticamente um job de Cron para uma varredura completa de Dreaming. Cada varredura executa as fases em ordem: Light → REM → Deep. A varredura inclui o workspace principal do runtime e quaisquer workspaces de agente configurados, deduplicados por caminho, para que o fan-out de workspace de subagente não exclua o DREAMS.md e o estado de memória do agente principal. Comportamento de cadência padrão:
ConfiguraçãoPadrão
dreaming.frequency0 3 * * *
dreaming.modelmodelo padrão

​
Início rápido

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

​
Comando slash

/dreaming status
/dreaming on
/dreaming off
/dreaming help
/dreaming on e /dreaming off alteram a configuração em todo o Gateway. Chamadores de canal devem ser proprietários, e clientes do Gateway devem ter operator.admin. /dreaming status e /dreaming help permanecem somente leitura.

​
Fluxo de trabalho da CLI

openclaw memory promote
openclaw memory promote --apply
openclaw memory promote --limit 5
openclaw memory status --deep
memory promote manual usa os limites da fase Deep por padrão, a menos que sejam substituídos por flags da CLI.

​
Padrões principais

Todas as configurações ficam em plugins.entries.memory-core.config.dreaming.
​
enabled
boolean
padrão:"false"
Habilita ou desabilita a varredura de Dreaming.
​
frequency
string
padrão:"0 3 * * *"
Cadência de Cron para a varredura completa de Dreaming.
​
model
string
Substituição opcional do modelo do subagente do Diário de Sonhos. Use um valor canônico provider/model ao também definir uma lista de permissões allowedModels de subagente.
​
phases.deep.maxPromotedSnippetTokens
number
padrão:"160"
Contagem máxima estimada de tokens mantida de cada snippet de recall de curto prazo promovido para MEMORY.md. A proveniência do ranqueamento permanece visível.
dreaming.model exige plugins.entries.memory-core.subagent.allowModelOverride: true. Para restringi-lo, defina também plugins.entries.memory-core.subagent.allowedModels. Falhas de confiança ou de lista de permissões permanecem visíveis em vez de cair silenciosamente para fallback; a nova tentativa cobre apenas erros de modelo indisponível.
A maior parte da política de fases, limites e comportamento de armazenamento são detalhes internos de implementação. Consulte a referência de configuração de memória para a lista completa de chaves.

​
UI de Sonhos

Quando habilitada, a aba Sonhos do Gateway mostra:
  • estado atual de habilitação do Dreaming
  • status em nível de fase e presença de varredura gerenciada
  • contagens de curto prazo, fundamentadas, de sinais e promovidas hoje
  • horário da próxima execução agendada
  • uma pista de Cena fundamentada distinta para entradas preparadas de replay histórico
  • um leitor expansível do Diário de Sonhos baseado em doctor.memory.dreamDiary

​
Dreaming nunca executa: status mostra bloqueado

Se openclaw memory status relatar Dreaming status: blocked, o Cron gerenciado existe, mas o Heartbeat do agente padrão não está disparando. Verifique se o Heartbeat está habilitado para o agente padrão e se o destino dele não é none; então execute openclaw memory status --deep novamente após o próximo intervalo de Heartbeat.

​
Relacionado