--- read_when: - Ви хочете, щоб просування пам’яті запускалося автоматично - Ви хочете зрозуміти, що робить кожна фаза Dreaming - Ви хочете налаштувати консолідацію, не засмічуючи MEMORY.md sidebarTitle: Dreaming summary: Фонова консолідація пам’яті з легкою, глибокою та REM-фазами, а також Dream Diary title: Dreaming x-i18n: generated_at: "2026-06-30T14:25:27Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 1b636df63cdc5b60758f9600af695b3b6453122a03b0cc6fdc69d3c9259d1e61 source_path: concepts/dreaming.md workflow: 16 --- Dreaming — це система фонової консолідації памʼяті в `memory-core`. Вона допомагає OpenClaw переносити сильні короткострокові сигнали в довготривалу памʼять, зберігаючи процес пояснюваним і придатним до перегляду. Dreaming є **опціональним** і типово вимкнений. ## Що записує Dreaming Dreaming зберігає два типи вихідних даних: - **Машинний стан** у `memory/.dreams/` (сховище пригадування, фазові сигнали, контрольні точки ingestion, блокування). - **Людинозчитуваний вивід** у `DREAMS.md` (або наявному `dreams.md`) і необовʼязкових файлах фазових звітів у `memory/dreaming//YYYY-MM-DD.md`. Довгострокове просування й надалі записує лише в `MEMORY.md`. ## Модель фаз Dreaming використовує три кооперативні фази: | Фаза | Призначення | Довготривалий запис | | ----- | ------------------------------------------------ | ------------------- | | Light | Сортувати й готувати нещодавній короткостроковий матеріал | Ні | | Deep | Оцінювати й просувати довготривалих кандидатів | Так (`MEMORY.md`) | | REM | Осмислювати теми й повторювані ідеї | Ні | Ці фази є внутрішніми деталями реалізації, а не окремими користувацькими "режимами." Фаза Light приймає нещодавні щоденні сигнали памʼяті та сліди пригадування, дедуплікує їх і готує рядки-кандидати. - Читає з короткострокового стану пригадування, нещодавніх щоденних файлів памʼяті та відредагованих стенограм сесій, коли вони доступні. - Записує керований блок `## Light Sleep`, коли сховище містить inline-вивід. - Записує сигнали підсилення для подальшого ранжування Deep. - Ніколи не записує в `MEMORY.md`. Фаза Deep вирішує, що стає довгостроковою памʼяттю. - Ранжує кандидатів за допомогою зваженого оцінювання та порогових фільтрів. - Вимагає проходження `minScore`, `minRecallCount` і `minUniqueQueries`. - Перед записом повторно завантажує фрагменти з live-щоденних файлів, тому застарілі або видалені фрагменти пропускаються. - Додає просунуті записи до `MEMORY.md`. - Записує підсумок `## Deep Sleep` у `DREAMS.md` і, за потреби, записує `memory/dreaming/deep/YYYY-MM-DD.md`. Фаза REM витягує патерни та рефлексивні сигнали. - Створює підсумки тем і рефлексій із нещодавніх короткострокових слідів. - Записує керований блок `## REM Sleep`, коли сховище містить inline-вивід. - Записує сигнали підсилення REM, які використовуються ранжуванням Deep. - Ніколи не записує в `MEMORY.md`. ## Ingestion стенограм сесій Dreaming може приймати відредаговані стенограми сесій у корпус Dreaming. Коли стенограми доступні, вони передаються у фазу Light разом зі щоденними сигналами памʼяті та слідами пригадування. Особистий і чутливий вміст редагується перед ingestion. ## Щоденник снів Dreaming також веде наративний **Щоденник снів** у `DREAMS.md`. Після того як кожна фаза має достатньо матеріалу, `memory-core` запускає фоновий best-effort хід субагента й додає короткий запис у щоденник. Він використовує типову runtime-модель, якщо не налаштовано `dreaming.model`. Якщо налаштована модель недоступна, Щоденник снів повторює спробу один раз із типовою моделлю сесії. Цей щоденник призначений для читання людиною в інтерфейсі Dreams, а не є джерелом просування. Згенеровані Dreaming артефакти щоденника/звітів виключаються з короткострокового просування. Лише обґрунтовані фрагменти памʼяті можуть бути просунуті в `MEMORY.md`. Також є обґрунтований історичний backfill-канал для перегляду та відновлення: - `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` | типова модель | ## Швидкий старт ```json { "plugins": { "entries": { "memory-core": { "config": { "dreaming": { "enabled": true } } } } } } ``` ```json { "plugins": { "entries": { "memory-core": { "config": { "dreaming": { "enabled": true, "timezone": "America/Los_Angeles", "frequency": "0 */6 * * *" } } } } } } ``` ## Slash-команда ``` /dreaming status /dreaming on /dreaming off /dreaming help ``` `/dreaming on` і `/dreaming off` змінюють конфігурацію на рівні Gateway. Викликачі з каналів мають бути власниками, а клієнти Gateway повинні мати `operator.admin`. `/dreaming status` і `/dreaming help` залишаються read-only. ## Робочий процес CLI ```bash openclaw memory promote openclaw memory promote --apply openclaw memory promote --limit 5 openclaw memory status --deep ``` Ручний `memory promote` типово використовує пороги фази Deep, якщо їх не перевизначено прапорцями CLI. Пояснити, чому конкретний кандидат був би або не був би просунутий: ```bash openclaw memory promote-explain "router vlan" openclaw memory promote-explain "router vlan" --json ``` Попередньо переглянути REM-рефлексії, кандидатні істини та вивід просування Deep без запису будь-чого: ```bash openclaw memory rem-harness openclaw memory rem-harness --json ``` ## Ключові типові значення Усі налаштування розміщені в `plugins.entries.memory-core.config.dreaming`. Увімкнути або вимкнути прохід Dreaming. Cron-періодичність для повного проходу Dreaming. Необовʼязкове перевизначення моделі субагента для Щоденника снів. Використовуйте канонічне значення `provider/model`, коли також задаєте allowlist `allowedModels` для субагента. Максимальна приблизна кількість токенів, що зберігається з кожного короткострокового фрагмента пригадування, просунутого в `MEMORY.md`. Походження ранжування залишається видимим. `dreaming.model` вимагає `plugins.entries.memory-core.subagent.allowModelOverride: true`. Щоб обмежити його, також задайте `plugins.entries.memory-core.subagent.allowedModels`. Збої довіри або allowlist залишаються видимими замість тихого fallback; повторна спроба покриває лише помилки недоступності моделі. Більшість політик фаз, порогів і поведінки сховища є внутрішніми деталями реалізації. Див. [довідник конфігурації памʼяті](/uk/reference/memory-config#dreaming) для повного списку ключів. ## Інтерфейс 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. ## Повʼязане - [Памʼять](/uk/concepts/memory) - [CLI памʼяті](/uk/cli/memory) - [Довідник конфігурації памʼяті](/uk/reference/memory-config) - [Пошук у памʼяті](/uk/concepts/memory-search)