--- read_when: - Вы хотите, чтобы продвижение памяти запускалось автоматически - Вы хотите понять, что делает каждая фаза Dreaming - Вы хотите настроить консолидацию, не засоряя MEMORY.md sidebarTitle: Dreaming summary: Фоновая консолидация памяти с легкой, глубокой и REM-фазами, а также Dream Diary title: Dreaming x-i18n: generated_at: "2026-06-28T22:49:20Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 257e8095114e05f18e0ba7a6870765a6b88c80e1eedaccfa891faa231f68f01b source_path: concepts/dreaming.md workflow: 16 --- Dreaming — это фоновая система консолидации памяти в `memory-core`. Она помогает OpenClaw переносить сильные краткосрочные сигналы в долговременную память, сохраняя процесс объяснимым и пригодным для проверки. Dreaming **включается явно** и по умолчанию отключен. ## Что записывает Dreaming Dreaming хранит два вида выходных данных: - **Машинное состояние** в `memory/.dreams/` (хранилище recall, фазовые сигналы, контрольные точки ingest, блокировки). - **Человекочитаемые выходные данные** в `DREAMS.md` (или существующем `dreams.md`) и необязательных файлах отчетов фаз в `memory/dreaming//YYYY-MM-DD.md`. Долгосрочное продвижение по-прежнему записывает данные только в `MEMORY.md`. ## Фазовая модель Dreaming использует три совместно работающие фазы: | Фаза | Назначение | Долговременная запись | | ----- | ---------------------------------------------------- | --------------------- | | Light | Сортировка и подготовка недавнего краткосрочного материала | Нет | | Deep | Оценка и продвижение долговременных кандидатов | Да (`MEMORY.md`) | | REM | Осмысление тем и повторяющихся идей | Нет | Эти фазы являются внутренними деталями реализации, а не отдельными пользовательскими «режимами». Фаза Light загружает недавние ежедневные сигналы памяти и трассы recall, удаляет дубликаты и подготавливает строки-кандидаты. - Читает из краткосрочного состояния recall, недавних ежедневных файлов памяти и отредактированных стенограмм сессий, когда они доступны. - Записывает управляемый блок `## Light Sleep`, когда хранилище включает встроенный вывод. - Регистрирует сигналы усиления для последующего глубокого ранжирования. - Никогда не записывает в `MEMORY.md`. Фаза Deep решает, что станет долгосрочной памятью. - Ранжирует кандидатов с помощью взвешенной оценки и пороговых фильтров. - Требует прохождения `minScore`, `minRecallCount` и `minUniqueQueries`. - Перед записью повторно гидратирует фрагменты из актуальных ежедневных файлов, поэтому устаревшие или удаленные фрагменты пропускаются. - Добавляет продвинутые записи в `MEMORY.md`. - Записывает сводку `## Deep Sleep` в `DREAMS.md` и при необходимости записывает `memory/dreaming/deep/YYYY-MM-DD.md`. Фаза REM извлекает паттерны и рефлексивные сигналы. - Формирует сводки тем и рефлексий из недавних краткосрочных трасс. - Записывает управляемый блок `## REM Sleep`, когда хранилище включает встроенный вывод. - Регистрирует сигналы усиления REM, используемые глубоким ранжированием. - Никогда не записывает в `MEMORY.md`. ## Ingest стенограмм сессий Dreaming может загружать отредактированные стенограммы сессий в корпус Dreaming. Когда стенограммы доступны, они передаются в фазу Light вместе с ежедневными сигналами памяти и трассами recall. Личный и чувствительный контент редактируется перед ingest. ## Дневник сновидений Dreaming также ведет повествовательный **Дневник сновидений** в `DREAMS.md`. После того как каждая фаза накапливает достаточно материала, `memory-core` запускает best-effort фоновый ход субагента и добавляет короткую запись в дневник. Используется модель среды выполнения по умолчанию, если не настроен `dreaming.model`. Если настроенная модель недоступна, Дневник сновидений один раз повторяет попытку с моделью сессии по умолчанию. Этот дневник предназначен для чтения человеком в UI 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, не затрагивая обычные записи дневника или актуальный краткосрочный recall. Control UI предоставляет тот же поток backfill/reset для дневника, чтобы можно было проверить результаты в сцене Dreams перед решением, заслуживают ли основанные на фактах кандидаты продвижения. Scene также показывает отдельную основанную на фактах линию, чтобы было видно, какие подготовленные краткосрочные записи появились из исторического replay, какие продвинутые элементы были основаны на фактах, и можно было очищать только подготовленные записи, существующие лишь в grounded-линии, не затрагивая обычное актуальное краткосрочное состояние. ## Сигналы ранжирования 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 включает сценарий только для отчетности, предназначенный для изучения того, как будущий shadow trial Dreaming мог бы проверять кандидат памяти перед продвижением. Сценарий просит агента сравнить базовый ответ с ответом, который может использовать кандидат памяти, а затем записать локальный отчет с вердиктом, причиной и флагами риска. Это покрытие намеренно ограничено QA. Оно проверяет, что артефакт отчета остается отдельно от `MEMORY.md` и что агент не утверждает, будто кандидат был продвинут. Оно не добавляет production-поведение shadow trial и не меняет движок продвижения фазы Deep. Runner shadow-trial в `memory-core` сохраняет тот же контракт только для отчетности для путей кода, которым нужен стабильный артефакт. Он принимает кандидата, prompt trial, базовый результат, результат кандидата, вердикт, причину, флаги риска и ссылки на свидетельства, затем записывает отчет с `promotion action: report-only`. Полезные вердикты сопоставляются с рекомендацией `promote`, нейтральные вердикты — с `defer`, а вредные — с `reject`; ни одна из этих рекомендаций не записывает в `MEMORY.md` и не применяет продвижение фазы Deep. ## Планирование Когда включено, `memory-core` автоматически управляет одной задачей cron для полного прохода Dreaming. Каждый проход выполняет фазы по порядку: light → REM → deep. Проход включает основное рабочее пространство среды выполнения и любые настроенные рабочие пространства агентов, с удалением дубликатов по пути, поэтому fan-out рабочих пространств субагентов не исключает `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 ``` ## Рабочий процесс 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` для субагента. Максимальное оценочное количество токенов, сохраняемое из каждого краткосрочного фрагмента recall, продвинутого в `MEMORY.md`. Происхождение ранжирования остается видимым. `dreaming.model` требует `plugins.entries.memory-core.subagent.allowModelOverride: true`. Чтобы ограничить его, также задайте `plugins.entries.memory-core.subagent.allowedModels`. Сбои доверия или allowlist остаются видимыми вместо тихого fallback; повторная попытка покрывает только ошибки недоступности модели. Большинство политик фаз, порогов и поведения хранилища являются внутренними деталями реализации. Полный список ключей см. в [справочнике конфигурации памяти](/ru/reference/memory-config#dreaming). ## UI Dreams Когда включено, вкладка **Dreams** в Gateway показывает: - текущее состояние включения Dreaming - статус на уровне фаз и наличие управляемого прохода - счетчики краткосрочных, grounded, signal и продвинутых сегодня элементов - время следующего запланированного запуска - отдельную основанную на фактах линию Scene для подготовленных записей исторического replay - раскрываемый читатель Дневника сновидений на базе `doctor.memory.dreamDiary` ## Dreaming никогда не запускается: статус показывает blocked Если `openclaw memory status` сообщает `Dreaming status: blocked`, управляемая задача cron существует, но heartbeat агента по умолчанию не срабатывает. Проверьте, что heartbeat включен для агента по умолчанию и что его target не равен `none`, затем снова выполните `openclaw memory status --deep` после следующего интервала heartbeat. ## Связанные материалы - [Память](/ru/concepts/memory) - [CLI памяти](/ru/cli/memory) - [Справочник конфигурации памяти](/ru/reference/memory-config) - [Поиск по памяти](/ru/concepts/memory-search)