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 — це система фонової консолідації памʼяті в memory-core. Вона допомагає OpenClaw переносити сильні короткострокові сигнали в довготривалу памʼять, зберігаючи процес пояснюваним і придатним до перегляду.

Що записує Dreaming

Dreaming зберігає два типи вихідних даних:

  • Машинний стан у memory/.dreams/ (сховище пригадування, фазові сигнали, контрольні точки ingestion, блокування).
  • Людинозчитуваний вивід у DREAMS.md (або наявному dreams.md) і необовʼязкових файлах фазових звітів у memory/dreaming/<phase>/YYYY-MM-DD.md.

Довгострокове просування й надалі записує лише в MEMORY.md.

Модель фаз

Dreaming використовує три кооперативні фази:

Фаза Призначення Довготривалий запис
Light Сортувати й готувати нещодавній короткостроковий матеріал Ні
Deep Оцінювати й просувати довготривалих кандидатів Так (MEMORY.md)
REM Осмислювати теми й повторювані ідеї Ні

Ці фази є внутрішніми деталями реалізації, а не окремими користувацькими "режимами."

Light phase

Фаза Light приймає нещодавні щоденні сигнали памʼяті та сліди пригадування, дедуплікує їх і готує рядки-кандидати.

  • Читає з короткострокового стану пригадування, нещодавніх щоденних файлів памʼяті та відредагованих стенограм сесій, коли вони доступні.
  • Записує керований блок ## Light Sleep, коли сховище містить inline-вивід.
  • Записує сигнали підсилення для подальшого ранжування Deep.
  • Ніколи не записує в MEMORY.md.
Deep phase

Фаза Deep вирішує, що стає довгостроковою памʼяттю.

  • Ранжує кандидатів за допомогою зваженого оцінювання та порогових фільтрів.
  • Вимагає проходження minScore, minRecallCount і minUniqueQueries.
  • Перед записом повторно завантажує фрагменти з live-щоденних файлів, тому застарілі або видалені фрагменти пропускаються.
  • Додає просунуті записи до MEMORY.md.
  • Записує підсумок ## Deep Sleep у DREAMS.md і, за потреби, записує memory/dreaming/deep/YYYY-MM-DD.md.
REM phase

Фаза REM витягує патерни та рефлексивні сигнали.

  • Створює підсумки тем і рефлексій із нещодавніх короткострокових слідів.
  • Записує керований блок ## REM Sleep, коли сховище містить inline-вивід.
  • Записує сигнали підсилення REM, які використовуються ранжуванням Deep.
  • Ніколи не записує в MEMORY.md.

Ingestion стенограм сесій

Dreaming може приймати відредаговані стенограми сесій у корпус Dreaming. Коли стенограми доступні, вони передаються у фазу Light разом зі щоденними сигналами памʼяті та слідами пригадування. Особистий і чутливий вміст редагується перед ingestion.

Щоденник снів

Dreaming також веде наративний Щоденник снів у DREAMS.md. Після того як кожна фаза має достатньо матеріалу, memory-core запускає фоновий best-effort хід субагента й додає короткий запис у щоденник. Він використовує типову runtime-модель, якщо не налаштовано dreaming.model. Якщо налаштована модель недоступна, Щоденник снів повторює спробу один раз із типовою моделлю сесії.

Також є обґрунтований історичний backfill-канал для перегляду та відновлення:

Backfill commands
  • memory rem-harness --path ... --grounded попередньо показує обґрунтований вивід щоденника з історичних нотаток YYYY-MM-DD.md.
  • memory rem-backfill --path ... записує оборотні обґрунтовані записи щоденника в DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term готує обґрунтованих довготривалих кандидатів у тому самому короткостроковому сховищі доказів, яке вже використовує звичайна фаза Deep.
  • memory rem-backfill --rollback і --rollback-short-term видаляють ці підготовлені backfill-артефакти, не зачіпаючи звичайні записи щоденника або live-короткострокове пригадування.

Control UI надає той самий потік backfill/reset для щоденника, щоб ви могли перевірити результати в сцені Dreams перед рішенням, чи заслуговують обґрунтовані кандидати на просування. Сцена також показує окремий обґрунтований канал, щоб ви могли бачити, які підготовлені короткострокові записи надійшли з історичного повторного відтворення, які просунуті елементи були обґрунтовано ініційованими, і очищати лише обґрунтовані підготовлені записи, не зачіпаючи звичайний live-короткостроковий стан.

Сигнали ранжування Deep

Ранжування Deep використовує шість зважених базових сигналів плюс фазове підсилення:

Сигнал Вага Опис
Частота 0.24 Скільки короткострокових сигналів накопичив запис
Релевантність 0.30 Середня якість пошуку для запису
Різноманітність запитів 0.15 Окремі контексти запитів/днів, які його виявили
Нещодавність 0.15 Оцінка свіжості з часовим згасанням
Консолідація 0.10 Сила повторення впродовж кількох днів
Концептуальна насиченість 0.06 Щільність концепт-тегів із фрагмента/шляху

Збіги фаз Light і REM додають невелике підсилення з часовим згасанням із memory/.dreams/phase-signals.json.

Результати shadow trial можна накладати поверх цього базового балу як сигнал перегляду перед будь-яким довготривалим записом. Корисний trial дає кандидату невелике обмежене підсилення, нейтральний trial залишає його відкладеним, а шкідливий trial позначає його як відхиленого для цього проходу оцінювання. Цей сигнал усе ще є лише звітним: він може змінити порядок кандидатів або метадані перегляду, але сам по собі не записує в MEMORY.md і не просуває кандидата.

Покриття звіту QA shadow trial

QA Lab містить сценарій лише для звітування, який досліджує, як майбутній Dreaming shadow trial міг би переглядати памʼять-кандидата перед просуванням. Сценарій просить агента порівняти базову відповідь із відповіддю, яка може використовувати памʼять-кандидата, а потім записати локальний звіт із вердиктом, причиною та прапорцями ризику.

Це покриття навмисно обмежене QA. Воно перевіряє, що артефакт звіту залишається окремим від MEMORY.md і що агент не стверджує, ніби кандидата було просунуто. Воно не додає production-поведінку shadow trial і не змінює рушій просування фази Deep.

Runner shadow trial у memory-core зберігає той самий контракт лише для звіту для шляхів коду, яким потрібен стабільний артефакт. Він приймає кандидата, trial-промпт, базовий результат, результат кандидата, вердикт, причину, прапорці ризику та посилання на докази, а потім записує звіт із promotion action: report-only. Корисні вердикти зіставляються з рекомендацією promote, нейтральні вердикти — з defer, а шкідливі вердикти — з reject; жодна з цих рекомендацій не записує в MEMORY.md і не застосовує просування фази Deep.

Планування

Коли ввімкнено, memory-core автоматично керує одним cron-завданням для повного проходу Dreaming. Кожен прохід виконує фази в порядку: Light → REM → Deep.

Прохід включає основний runtime workspace і будь-які налаштовані workspaces агентів, дедупліковані за шляхом, тому fan-out workspace субагента не виключає DREAMS.md і стан памʼяті головного агента.

Типова поведінка періодичності:

Налаштування Типове значення
dreaming.frequency 0 3 * * *
dreaming.model типова модель

Швидкий старт

Enable dreaming

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

Custom sweep cadence

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

Slash-команда

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

/dreaming on і /dreaming off змінюють конфігурацію на рівні Gateway. Викликачі з каналів мають бути власниками, а клієнти Gateway повинні мати operator.admin. /dreaming status і /dreaming help залишаються read-only.

Робочий процес CLI

Promotion preview / apply

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

Ручний memory promote типово використовує пороги фази Deep, якщо їх не перевизначено прапорцями CLI.

Explain promotion

Пояснити, чому конкретний кандидат був би або не був би просунутий:

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

REM harness preview

Попередньо переглянути REM-рефлексії, кандидатні істини та вивід просування Deep без запису будь-чого:

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

Ключові типові значення

Усі налаштування розміщені в plugins.entries.memory-core.config.dreaming.

enabledbooleandefault: false

Увімкнути або вимкнути прохід Dreaming.

frequencystringdefault: 0 3 * * *

Cron-періодичність для повного проходу Dreaming.

modelstring

Необовʼязкове перевизначення моделі субагента для Щоденника снів. Використовуйте канонічне значення provider/model, коли також задаєте allowlist allowedModels для субагента.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

Максимальна приблизна кількість токенів, що зберігається з кожного короткострокового фрагмента пригадування, просунутого в MEMORY.md. Походження ранжування залишається видимим.

Інтерфейс Dreams

Коли ввімкнено, вкладка Dreams у Gateway показує:

  • поточний стан увімкнення Dreaming
  • статус на рівні фаз і наявність керованого проходу
  • кількість короткострокових, обґрунтованих, сигнальних і просунутих сьогодні елементів
  • час наступного запланованого запуску
  • окремий обґрунтований канал Scene для підготовлених записів історичного повторного відтворення
  • розгортаний читач Щоденника снів, що спирається на doctor.memory.dreamDiary

Dreaming ніколи не запускається: статус показує blocked

Якщо openclaw memory status повідомляє Dreaming status: blocked, керований Cron існує, але heartbeat типового агента не спрацьовує. Перевірте, що heartbeat увімкнено для типового агента і що його ціль не дорівнює none, а потім знову запустіть openclaw memory status --deep після наступного інтервалу heartbeat.

Повʼязане

Was this useful?
On this page

On this page