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 es el sistema de consolidación de memoria en segundo plano de memory-core. Ayuda a OpenClaw a mover señales fuertes de corto plazo a memoria duradera mientras mantiene el proceso explicable y revisable.

Qué escribe Dreaming

Dreaming conserva dos tipos de salida:

  • Estado de máquina en memory/.dreams/ (almacén de recuperación, señales de fase, puntos de control de ingesta, bloqueos).
  • Salida legible por humanos en DREAMS.md (o el dreams.md existente) y archivos opcionales de informe de fase en memory/dreaming/<phase>/YYYY-MM-DD.md.

La promoción a largo plazo sigue escribiendo solo en MEMORY.md.

Modelo de fases

Dreaming usa tres fases cooperativas:

Fase Propósito Escritura duradera
Light Ordenar y preparar material reciente de corto plazo No
Deep Puntuar y promover candidatos duraderos Sí (MEMORY.md)
REM Reflexionar sobre temas e ideas recurrentes No

Estas fases son detalles internos de implementación, no "modos" separados configurados por el usuario.

Fase Light

La fase Light ingiere señales recientes de memoria diaria y trazas de recuperación, las desduplica y prepara líneas candidatas.

  • Lee desde el estado de recuperación de corto plazo, archivos recientes de memoria diaria y transcripciones de sesión redactadas cuando están disponibles.
  • Escribe un bloque gestionado ## Light Sleep cuando el almacenamiento incluye salida en línea.
  • Registra señales de refuerzo para la clasificación Deep posterior.
  • Nunca escribe en MEMORY.md.
Fase Deep

La fase Deep decide qué se convierte en memoria a largo plazo.

  • Clasifica candidatos usando puntuación ponderada y compuertas de umbral.
  • Requiere que minScore, minRecallCount y minUniqueQueries se cumplan.
  • Rehidrata fragmentos desde archivos diarios activos antes de escribir, por lo que se omiten fragmentos obsoletos o eliminados.
  • Agrega entradas promovidas a MEMORY.md.
  • Escribe un resumen ## Deep Sleep en DREAMS.md y, opcionalmente, escribe memory/dreaming/deep/YYYY-MM-DD.md.
Fase REM

La fase REM extrae patrones y señales reflexivas.

  • Construye resúmenes de temas y reflexiones a partir de trazas recientes de corto plazo.
  • Escribe un bloque gestionado ## REM Sleep cuando el almacenamiento incluye salida en línea.
  • Registra señales de refuerzo REM usadas por la clasificación Deep.
  • Nunca escribe en MEMORY.md.

Ingesta de transcripciones de sesión

Dreaming puede ingerir transcripciones de sesión redactadas en el corpus de Dreaming. Cuando las transcripciones están disponibles, se alimentan a la fase Light junto con señales de memoria diaria y trazas de recuperación. El contenido personal y sensible se redacta antes de la ingesta.

Diario de sueños

Dreaming también mantiene un Diario de sueños narrativo en DREAMS.md. Después de que cada fase tenga suficiente material, memory-core ejecuta un turno de subagente en segundo plano con el mejor esfuerzo y agrega una entrada breve al diario. Usa el modelo de runtime predeterminado a menos que dreaming.model esté configurado. Si el modelo configurado no está disponible, el Diario de sueños reintenta una vez con el modelo predeterminado de la sesión.

También hay una vía de relleno histórico fundamentado para trabajo de revisión y recuperación:

Comandos de relleno
  • memory rem-harness --path ... --grounded previsualiza la salida de diario fundamentada desde notas históricas YYYY-MM-DD.md.
  • memory rem-backfill --path ... escribe entradas de diario fundamentadas y reversibles en DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term prepara candidatos duraderos fundamentados en el mismo almacén de evidencia de corto plazo que ya usa la fase Deep normal.
  • memory rem-backfill --rollback y --rollback-short-term eliminan esos artefactos de relleno preparados sin tocar entradas ordinarias del diario ni recuperación activa de corto plazo.

La UI de Control expone el mismo flujo de relleno/restablecimiento del diario para que puedas inspeccionar los resultados en la escena Sueños antes de decidir si los candidatos fundamentados merecen promoción. La escena también muestra una vía fundamentada distinta para que puedas ver qué entradas de corto plazo preparadas vinieron de la reproducción histórica, qué elementos promovidos fueron guiados por fundamentación y borrar solo entradas preparadas exclusivamente fundamentadas sin tocar el estado ordinario activo de corto plazo.

Señales de clasificación Deep

La clasificación Deep usa seis señales base ponderadas más refuerzo de fase:

Señal Peso Descripción
Frecuencia 0.24 Cuántas señales de corto plazo acumuló la entrada
Relevancia 0.30 Calidad media de recuperación de la entrada
Diversidad de consulta 0.15 Contextos distintos de consulta/día que la hicieron aparecer
Recencia 0.15 Puntuación de frescura con decaimiento temporal
Consolidación 0.10 Fuerza de recurrencia de varios días
Riqueza conceptual 0.06 Densidad de etiquetas conceptuales del fragmento/ruta

Los aciertos de las fases Light y REM agregan un pequeño impulso con decaimiento por recencia desde memory/.dreams/phase-signals.json.

Los resultados de pruebas sombra se pueden superponer sobre esa puntuación base como una señal de revisión antes de cualquier escritura duradera. Una prueba útil da al candidato un pequeño impulso acotado, una prueba neutral lo mantiene diferido y una prueba perjudicial lo marca como rechazado para esa pasada de puntuación. Esta señal sigue siendo solo de informe: puede cambiar el orden de candidatos o los metadatos de revisión, pero no escribe en MEMORY.md ni promueve el candidato por sí sola.

Cobertura del informe de prueba sombra de QA

QA Lab incluye un escenario solo de informe para explorar cómo una futura prueba sombra de Dreaming podría revisar una memoria candidata antes de la promoción. El escenario pide a un agente que compare una respuesta base con una respuesta que puede usar la memoria candidata y luego escriba un informe local con un veredicto, motivo e indicadores de riesgo.

Esta cobertura está limitada intencionalmente a QA. Verifica que el artefacto de informe permanezca separado de MEMORY.md y que el agente no afirme que el candidato fue promovido. No agrega comportamiento de prueba sombra en producción ni cambia el motor de promoción de la fase Deep.

El ejecutor de prueba sombra de memory-core mantiene ese mismo contrato solo de informe para rutas de código que necesitan un artefacto estable. Acepta el candidato, el prompt de prueba, el resultado base, el resultado del candidato, el veredicto, el motivo, los indicadores de riesgo y las referencias de evidencia, y luego escribe un informe con promotion action: report-only. Los veredictos útiles se asignan a una recomendación promote, los veredictos neutrales se asignan a defer y los veredictos perjudiciales se asignan a reject; ninguna de esas recomendaciones escribe en MEMORY.md ni aplica promoción de fase Deep.

Programación

Cuando está activado, memory-core gestiona automáticamente un trabajo Cron para un barrido completo de Dreaming. Cada barrido ejecuta las fases en orden: Light → REM → Deep.

El barrido incluye el espacio de trabajo principal del runtime y cualquier espacio de trabajo de agente configurado, desduplicado por ruta, para que la expansión de espacios de trabajo de subagentes no excluya el DREAMS.md ni el estado de memoria del agente principal.

Comportamiento de cadencia predeterminado:

Ajuste Predeterminado
dreaming.frequency 0 3 * * *
dreaming.model modelo predeterminado

Inicio rápido

Activar Dreaming

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

Cadencia de barrido personalizada

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

Comando slash

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

/dreaming on y /dreaming off cambian la configuración de todo el Gateway. Los llamadores de canal deben ser propietarios, y los clientes de Gateway deben tener operator.admin. /dreaming status y /dreaming help siguen siendo de solo lectura.

Flujo de trabajo de CLI

Vista previa / aplicación de promoción

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

memory promote manual usa los umbrales de fase Deep de forma predeterminada a menos que se sobrescriban con flags de CLI.

Explicar promoción

Explica por qué un candidato específico se promovería o no:

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

Vista previa del arnés REM

Previsualiza reflexiones REM, verdades candidatas y salida de promoción Deep sin escribir nada:

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

Valores predeterminados clave

Todos los ajustes viven en plugins.entries.memory-core.config.dreaming.

enabledbooleandefault: false

Activa o desactiva el barrido de Dreaming.

frequencystringdefault: 0 3 * * *

Cadencia Cron para el barrido completo de Dreaming.

modelstring

Sobrescritura opcional del modelo de subagente del Diario de sueños. Usa un valor canónico provider/model cuando también configures una lista de permitidos allowedModels para subagentes.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

Recuento máximo estimado de tokens conservado de cada fragmento de recuperación de corto plazo promovido a MEMORY.md. La procedencia de clasificación sigue visible.

UI de Sueños

Cuando está activada, la pestaña Sueños del Gateway muestra:

  • estado actual de activación de Dreaming
  • estado a nivel de fase y presencia del barrido gestionado
  • recuentos de corto plazo, fundamentados, de señales y promovidos hoy
  • momento de la próxima ejecución programada
  • una vía de escena fundamentada distinta para entradas preparadas de reproducción histórica
  • un lector expandible del Diario de sueños respaldado por doctor.memory.dreamDiary

Dreaming nunca se ejecuta: el estado muestra bloqueo

Si openclaw memory status informa Dreaming status: blocked, el Cron gestionado existe, pero el Heartbeat del agente predeterminado no se está disparando. Comprueba que Heartbeat esté activado para el agente predeterminado y que su destino no sea none; luego ejecuta openclaw memory status --deep de nuevo después del siguiente intervalo de Heartbeat.

Relacionado

Was this useful?
On this page

On this page