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 to system konsolidacji pamięci w tle w memory-core. Pomaga OpenClaw przenosić silne sygnały krótkoterminowe do trwałej pamięci, zachowując przy tym wyjaśnialność i możliwość przeglądu procesu.

Co zapisuje Dreaming

Dreaming utrzymuje dwa rodzaje danych wyjściowych:

  • Stan maszyny w memory/.dreams/ (magazyn odwołań, sygnały faz, punkty kontrolne ingestii, blokady).
  • Dane czytelne dla człowieka w DREAMS.md (lub istniejącym dreams.md) oraz opcjonalne pliki raportów faz w memory/dreaming/<phase>/YYYY-MM-DD.md.

Promowanie do pamięci długoterminowej nadal zapisuje wyłącznie do MEMORY.md.

Model faz

Dreaming używa trzech współpracujących faz:

Faza Cel Trwały zapis
Lekka Sortowanie i etapowanie najnowszego materiału krótkoterminowego Nie
Głęboka Ocena i promowanie trwałych kandydatów Tak (MEMORY.md)
REM Refleksja nad motywami i powracającymi pomysłami Nie

Te fazy są wewnętrznymi szczegółami implementacji, a nie osobnymi „trybami” konfigurowanymi przez użytkownika.

Light phase

Faza lekka pobiera najnowsze dzienne sygnały pamięci i ślady odwołań, deduplikuje je i etapu­je wiersze kandydatów.

  • Odczytuje krótkoterminowy stan odwołań, najnowsze dzienne pliki pamięci i zredagowane transkrypty sesji, gdy są dostępne.
  • Zapisuje zarządzany blok ## Light Sleep, gdy magazyn obejmuje dane wyjściowe inline.
  • Rejestruje sygnały wzmocnienia do późniejszego rankingu głębokiego.
  • Nigdy nie zapisuje do MEMORY.md.
Deep phase

Faza głęboka decyduje, co staje się pamięcią długoterminową.

  • Klasyfikuje kandydatów przy użyciu ważonej punktacji i progów.
  • Wymaga spełnienia minScore, minRecallCount i minUniqueQueries.
  • Odtwarza fragmenty z aktywnych dziennych plików przed zapisem, więc nieaktualne/usunięte fragmenty są pomijane.
  • Dopisuje promowane wpisy do MEMORY.md.
  • Zapisuje podsumowanie ## Deep Sleep w DREAMS.md i opcjonalnie zapisuje memory/dreaming/deep/YYYY-MM-DD.md.
REM phase

Faza REM wyodrębnia wzorce i sygnały refleksyjne.

  • Buduje podsumowania motywów i refleksji z najnowszych krótkoterminowych śladów.
  • Zapisuje zarządzany blok ## REM Sleep, gdy magazyn obejmuje dane wyjściowe inline.
  • Rejestruje sygnały wzmocnienia REM używane przez ranking głęboki.
  • Nigdy nie zapisuje do MEMORY.md.

Ingestia transkryptów sesji

Dreaming może pobierać zredagowane transkrypty sesji do korpusu Dreaming. Gdy transkrypty są dostępne, trafiają do fazy lekkiej obok dziennych sygnałów pamięci i śladów odwołań. Treści osobiste i wrażliwe są redagowane przed ingestą.

Dziennik snów

Dreaming utrzymuje także narracyjny Dziennik snów w DREAMS.md. Gdy każda faza ma wystarczająco dużo materiału, memory-core uruchamia w tle najlepszą możliwą turę subagenta i dopisuje krótki wpis dziennika. Używa domyślnego modelu runtime, chyba że skonfigurowano dreaming.model. Jeśli skonfigurowany model jest niedostępny, Dziennik snów ponawia próbę raz z domyślnym modelem sesji.

Istnieje też ugruntowana ścieżka historycznego uzupełniania do pracy przeglądowej i odzyskiwania:

Backfill commands
  • memory rem-harness --path ... --grounded podgląda ugruntowane dane wyjściowe dziennika z historycznych notatek YYYY-MM-DD.md.
  • memory rem-backfill --path ... zapisuje odwracalne ugruntowane wpisy dziennika do DREAMS.md.
  • memory rem-backfill --path ... --stage-short-term etapu­je ugruntowanych trwałych kandydatów w tym samym krótkoterminowym magazynie dowodów, którego używa już normalna faza głęboka.
  • memory rem-backfill --rollback i --rollback-short-term usuwają te etapowane artefakty uzupełniania bez naruszania zwykłych wpisów dziennika ani aktywnych krótkoterminowych odwołań.

Control UI udostępnia ten sam przepływ uzupełniania/resetowania dziennika, aby można było sprawdzić wyniki w scenie Dreams przed decyzją, czy ugruntowani kandydaci zasługują na promocję. Scena pokazuje też osobną ugruntowaną ścieżkę, dzięki czemu widać, które etapowane wpisy krótkoterminowe pochodzą z historycznego odtworzenia, które promowane elementy były prowadzone przez ugruntowanie, oraz można wyczyścić tylko ugruntowane etapowane wpisy bez naruszania zwykłego aktywnego krótkoterminowego stanu.

Sygnały rankingu głębokiego

Ranking głęboki używa sześciu ważonych sygnałów bazowych oraz wzmocnienia faz:

Sygnał Waga Opis
Częstotliwość 0.24 Ile sygnałów krótkoterminowych zgromadził wpis
Trafność 0.30 Średnia jakość pobierania dla wpisu
Różnorodność zapytań 0.15 Odrębne konteksty zapytań/dni, które go ujawniły
Świeżość 0.15 Wynik świeżości z zanikiem czasowym
Konsolidacja 0.10 Siła wielodniowego nawrotu
Bogactwo konceptualne 0.06 Gęstość tagów pojęć z fragmentu/ścieżki

Trafienia faz lekkiej i REM dodają niewielkie wzmocnienie z zanikiem świeżości z memory/.dreams/phase-signals.json.

Wyniki prób shadow można nakładać na tę punktację bazową jako sygnał przeglądowy przed jakimkolwiek trwałym zapisem. Pomocna próba daje kandydatowi małe, ograniczone wzmocnienie, neutralna próba pozostawia go odroczonym, a szkodliwa próba oznacza go jako odrzuconego w danym przebiegu punktacji. Ten sygnał nadal jest tylko raportowy: może zmieniać kolejność kandydatów lub metadane przeglądu, ale sam nie zapisuje do MEMORY.md ani nie promuje kandydata.

Pokrycie raportu prób shadow w QA

QA Lab obejmuje scenariusz tylko raportowy do badania, jak przyszła próba shadow Dreaming mogłaby przeglądać kandydata pamięci przed promocją. Scenariusz prosi agenta o porównanie odpowiedzi bazowej z odpowiedzią, która może użyć pamięci kandydata, a następnie zapisanie lokalnego raportu z werdyktem, powodem i flagami ryzyka.

To pokrycie jest celowo ograniczone do QA. Weryfikuje, że artefakt raportu pozostaje oddzielony od MEMORY.md oraz że agent nie twierdzi, iż kandydat został promowany. Nie dodaje produkcyjnego zachowania prób shadow ani nie zmienia silnika promocji fazy głębokiej.

Runner prób shadow w memory-core utrzymuje ten sam kontrakt tylko raportowy dla ścieżek kodu, które potrzebują stabilnego artefaktu. Przyjmuje kandydata, prompt próby, wynik bazowy, wynik kandydata, werdykt, powód, flagi ryzyka i referencje dowodów, a następnie zapisuje raport z promotion action: report-only. Pomocne werdykty mapują się na rekomendację promote, neutralne werdykty na defer, a szkodliwe werdykty na reject; żadna z tych rekomendacji nie zapisuje do MEMORY.md ani nie stosuje promocji fazy głębokiej.

Harmonogram

Po włączeniu memory-core automatycznie zarządza jednym zadaniem cron dla pełnego przebiegu Dreaming. Każdy przebieg uruchamia fazy w kolejności: lekka → REM → głęboka.

Przebieg obejmuje główny obszar roboczy runtime i wszystkie skonfigurowane obszary robocze agentów, zdeduplikowane według ścieżki, więc rozgałęzienie obszarów roboczych subagentów nie wyklucza DREAMS.md ani stanu pamięci głównego agenta.

Domyślne zachowanie kadencji:

Ustawienie Domyślnie
dreaming.frequency 0 3 * * *
dreaming.model model domyślny

Szybki start

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 * * *"          }        }      }    }  }}

Polecenie slash

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

/dreaming on i /dreaming off zmieniają konfigurację w całym Gateway. Wywołujący z kanałów muszą być właścicielami, a klienci Gateway muszą mieć operator.admin. /dreaming status i /dreaming help pozostają tylko do odczytu.

Przepływ pracy CLI

Promotion preview / apply

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

Ręczne memory promote domyślnie używa progów fazy głębokiej, chyba że zostaną nadpisane flagami CLI.

Explain promotion

Wyjaśnij, dlaczego konkretny kandydat zostałby lub nie zostałby promowany:

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

REM harness preview

Podgląd refleksji REM, prawd kandydatów i wyniku promocji głębokiej bez zapisywania czegokolwiek:

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

Kluczowe wartości domyślne

Wszystkie ustawienia znajdują się pod plugins.entries.memory-core.config.dreaming.

enabledbooleandefault: false

Włącz lub wyłącz przebieg Dreaming.

frequencystringdefault: 0 3 * * *

Kadencja Cron dla pełnego przebiegu Dreaming.

modelstring

Opcjonalne nadpisanie modelu subagenta Dziennika snów. Użyj kanonicznej wartości provider/model, gdy ustawiasz też listę dozwolonych modeli subagenta allowedModels.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

Maksymalna szacowana liczba tokenów zachowywana z każdego krótkoterminowego fragmentu odwołania promowanego do MEMORY.md. Pochodzenie rankingu pozostaje widoczne.

Interfejs Dreams

Po włączeniu karta Dreams w Gateway pokazuje:

  • bieżący stan włączenia Dreaming
  • status na poziomie faz i obecność zarządzanego przebiegu
  • liczbę krótkoterminowych, ugruntowanych, sygnałowych i promowanych dzisiaj elementów
  • czas następnego zaplanowanego uruchomienia
  • osobną ugruntowaną ścieżkę Sceny dla etapowanych wpisów historycznego odtworzenia
  • rozwijany czytnik Dziennika snów oparty na doctor.memory.dreamDiary

Dreaming nigdy się nie uruchamia: status pokazuje blokadę

Jeśli openclaw memory status zgłasza Dreaming status: blocked, zarządzany cron istnieje, ale Heartbeat domyślnego agenta nie działa. Sprawdź, czy Heartbeat jest włączony dla domyślnego agenta i czy jego cel nie jest none, a następnie uruchom ponownie openclaw memory status --deep po następnym interwale Heartbeat.

Powiązane

Was this useful?
On this page

On this page