OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Sessions and memory

Dreaming

Dreaming est le système de consolidation de la mémoire en arrière-plan de memory-core. Il transfère les signaux forts à court terme vers la mémoire durable, tout en maintenant le processus explicable et vérifiable.

Ce que Dreaming écrit

  • État de la machine dans memory/.dreams/ (stockage de rappel, signaux de phase, points de contrôle d’ingestion, verrous).
  • Sortie lisible par l’utilisateur dans DREAMS.md (ou un fichier dreams.md existant) et fichiers facultatifs de rapport de phase sous memory/dreaming/<phase>/YYYY-MM-DD.md.

La promotion vers la mémoire à long terme écrit toujours uniquement dans MEMORY.md.

Modèle de phases

Dreaming exécute trois phases coopératives par balayage, dans l’ordre : légère -> REM -> profonde. Il s’agit de phases d’implémentation internes, et non de modes distincts configurés par l’utilisateur.

Phase Objectif Écriture persistante
Légère Trier et préparer les éléments récents à court terme Non
REM Réfléchir aux thèmes et aux idées récurrentes Non
Profonde Évaluer et promouvoir les candidats à conserver durablement Oui (MEMORY.md)
Phase légère
  • Lit l’état récent du rappel à court terme, les fichiers de mémoire quotidiens et, lorsqu’elles sont disponibles, les transcriptions de sessions expurgées.
  • Déduplique les signaux et prépare les lignes candidates.
  • Écrit un bloc ## Light Sleep géré lorsque le stockage inclut une sortie intégrée.
  • Enregistre les signaux de renforcement pour le classement profond ultérieur.
  • N’écrit jamais dans MEMORY.md.
Phase REM
  • Génère des synthèses thématiques et réflexives à partir des traces récentes à court terme.
  • Écrit un bloc ## REM Sleep géré lorsque le stockage inclut une sortie intégrée.
  • Enregistre les signaux de renforcement REM utilisés par le classement profond.
  • N’écrit jamais dans MEMORY.md.
Phase profonde
  • Classe les candidats à l’aide d’une notation pondérée et de seuils (minScore, minRecallCount et minUniqueQueries doivent tous être satisfaits).
  • Recharge les extraits depuis les fichiers quotidiens actifs avant l’écriture, afin d’ignorer les extraits obsolètes ou supprimés.
  • Ajoute les entrées promues à MEMORY.md.
  • Écrit une synthèse ## Deep Sleep dans DREAMS.md et, facultativement, dans memory/dreaming/deep/YYYY-MM-DD.md.

Ingestion des transcriptions de sessions

Dreaming peut ingérer des transcriptions de session expurgées dans le corpus de Dreaming. Lorsqu’elles sont disponibles, les transcriptions alimentent la phase légère aux côtés des signaux de mémoire quotidiens et des traces de rappel. Le contenu personnel et sensible est expurgé avant l’ingestion.

Journal des rêves

Dreaming conserve un journal des rêves narratif dans DREAMS.md. Une fois que chaque phase dispose de suffisamment de matière, memory-core exécute en arrière-plan, dans la mesure du possible, un tour de sous-agent et ajoute une courte entrée au journal, en utilisant le modèle d’exécution par défaut sauf si dreaming.model est configuré. Si le modèle configuré n’est pas disponible, l’exécution du journal réessaie une fois avec le modèle par défaut de la session ; les échecs liés à la confiance ou à la liste d’autorisation ne font pas l’objet d’une nouvelle tentative et restent visibles dans les journaux au lieu de déclencher silencieusement le recours à une entrée de journal générique.

Il existe également un circuit de remplissage rétroactif historique fondé sur des données factuelles pour les tâches de révision et de récupération :

Commandes de remplissage rétroactif
  • memory rem-harness --path ... --grounded prévisualise la sortie fondée sur des données factuelles du journal à partir des notes historiques YYYY-MM-DD.md.
  • memory rem-backfill --path ... écrit des entrées de journal réversibles et fondées sur des données factuelles dans DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term place les candidats durables fondés sur des données factuelles dans le même magasin de preuves à court terme que celui utilisé par la phase profonde normale.
  • memory rem-backfill --rollback et --rollback-short-term suppriment ces artefacts de remplissage rétroactif mis en attente sans toucher aux entrées de journal ordinaires ni au rappel actif à court terme.

L’interface utilisateur Control propose le même flux de remplissage rétroactif et de réinitialisation du journal dans l’onglet Memory de l’agent (page Agents), afin que vous puissiez examiner les résultats dans la scène de rêve avant de décider si les candidats fondés sur des données factuelles méritent une promotion. Un circuit distinct Scene fondé sur des données factuelles indique quelles entrées à court terme mises en attente proviennent d’une relecture historique et quels éléments promus ont été principalement étayés par des données factuelles ; il vous permet également d’effacer uniquement les entrées mises en attente exclusivement fondées sur des données factuelles sans toucher à l’état actif à court terme.

Signaux de classement profond

Le classement profond utilise six signaux de base pondérés, auxquels s’ajoute le renforcement de phase :

Signal Poids Description
Pertinence 0.30 Qualité moyenne de récupération de l’entrée
Fréquence 0.24 Nombre de signaux à court terme accumulés par l’entrée
Diversité des requêtes 0.15 Contextes distincts de requête/jour ayant fait apparaître l’entrée
Récence 0.15 Score de fraîcheur diminuant avec le temps
Consolidation 0.10 Intensité de la récurrence sur plusieurs jours
Richesse conceptuelle 0.06 Densité des balises conceptuelles provenant de l’extrait ou du chemin

Les occurrences des phases légère et REM ajoutent une légère bonification de récence qui diminue avec le temps à partir de memory/.dreams/phase-signals.json.

Les résultats des essais fantômes peuvent se superposer au score de base en tant que signal de révision avant toute écriture durable : un essai utile accorde au candidat une légère bonification plafonnée, un essai neutre maintient son report et un essai préjudiciable le marque comme rejeté pour cette passe de notation. Ce signal est réservé au rapport : il peut modifier l’ordre des candidats ou les métadonnées de révision, mais n’écrit jamais dans MEMORY.md et ne promeut jamais un candidat à lui seul.

Couverture des rapports d’essais fantômes d’assurance qualité

QA Lab inclut un scénario qui génère uniquement un rapport afin d’explorer comment un futur essai fantôme de Dreaming pourrait examiner une mémoire candidate avant sa promotion : un agent compare une réponse de référence à une réponse pouvant utiliser la mémoire candidate, puis rédige un rapport local comportant un verdict, une justification et des indicateurs de risque. Cette couverture est limitée à l’assurance qualité : elle vérifie que l’artefact de rapport reste distinct de MEMORY.md et que l’agent n’affirme jamais que la candidate a été promue. Elle n’ajoute aucun comportement d’essai fantôme en production et ne modifie pas le moteur de promotion de la phase approfondie.

L’exécuteur d’essais fantômes de memory-core conserve le même contrat de génération de rapport uniquement pour les chemins de code nécessitant un artefact stable. Il accepte la candidate, le prompt d’essai, le résultat de référence, le résultat avec la candidate, le verdict, la justification, les indicateurs de risque et les références des preuves, puis rédige un rapport contenant promotion action: report-only. Les verdicts favorables correspondent à une recommandation promote, les verdicts neutres à defer et les verdicts défavorables à reject ; aucun d’eux n’écrit dans MEMORY.md ni n’applique la promotion de la phase approfondie.

Planification

Lorsqu’il est activé, memory-core gère automatiquement une tâche Cron pour un balayage Dreaming complet, dédupliquée entre l’espace de travail principal de l’environnement d’exécution et les espaces de travail d’agents configurés, afin que la multiplication des espaces de travail de sous-agents n’exclue pas le fichier DREAMS.md ni l’état de la mémoire de l’agent principal.

Paramètre Valeur par défaut
dreaming.frequency 0 3 * * *
dreaming.model modèle par défaut

Démarrage rapide

Activer Dreaming

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

Fréquence de balayage personnalisée

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

Commande oblique

text
/dreaming status/dreaming on/dreaming off/dreaming help

/dreaming on et /dreaming off nécessitent le statut de propriétaire pour les appelants d’un canal ou operator.admin pour les clients du Gateway. /dreaming status et /dreaming help sont en lecture seule.

Flux de travail CLI

Aperçu de la promotion / application

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

La commande manuelle memory promote utilise par défaut les seuils de la phase approfondie, sauf s’ils sont remplacés par des options CLI.

Expliquer la promotion

Expliquez pourquoi une candidate précise serait ou ne serait pas promue :

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

Aperçu du banc d’essai REM

Prévisualisez les réflexions REM, les vérités candidates et le résultat de la promotion approfondie sans rien écrire :

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

Principales valeurs par défaut

Tous les paramètres se trouvent sous plugins.entries.memory-core.config.dreaming.

enabledbooleandefault: false

Active ou désactive le balayage Dreaming.

frequencystringdefault: 0 3 * * *

Fréquence Cron du balayage Dreaming complet.

modelstring

Remplacement facultatif du modèle du sous-agent Dream Diary. Utilisez une valeur canonique provider/model lorsque vous définissez également une liste d’autorisation allowedModels pour le sous-agent.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

Nombre maximal estimé de jetons conservés pour chaque extrait de rappel à court terme promu dans MEMORY.md. La provenance du classement reste visible.

Interface utilisateur Dreams

Lorsqu’il est activé, l’onglet Dreams du Gateway affiche :

  • l’état d’activation actuel de Dreaming
  • l’état de chaque phase et la présence du balayage géré
  • les nombres d’éléments à court terme, ancrés, de signaux et promus aujourd’hui
  • l’heure de la prochaine exécution planifiée
  • une voie Scene ancrée distincte pour les entrées préparées de relecture historique
  • un lecteur Dream Diary extensible reposant sur doctor.memory.dreamDiary

Voir aussi

Was this useful?
On this page

On this page