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 سامانهٔ یکپارچه‌سازی حافظه در پس‌زمینه در memory-core است. این سامانه به OpenClaw کمک می‌کند سیگنال‌های کوتاه‌مدت قوی را به حافظهٔ پایدار منتقل کند، در حالی که فرایند توضیح‌پذیر و قابل‌بازبینی باقی می‌ماند.

Dreaming چه چیزهایی می‌نویسد

Dreaming دو نوع خروجی نگه می‌دارد:

  • وضعیت ماشینی در memory/.dreams/ (ذخیرهٔ recall، سیگنال‌های فاز، نقاط وارسی ingestion، قفل‌ها).
  • خروجی خوانا برای انسان در DREAMS.md (یا dreams.md موجود) و فایل‌های اختیاری گزارش فاز در memory/dreaming/<phase>/YYYY-MM-DD.md.

ارتقای بلندمدت همچنان فقط در MEMORY.md می‌نویسد.

مدل فاز

Dreaming از سه فاز همکاری‌کننده استفاده می‌کند:

فاز هدف نوشتن پایدار
Light مرتب‌سازی و آماده‌سازی مواد کوتاه‌مدت اخیر خیر
Deep امتیازدهی و ارتقای نامزدهای پایدار بله (MEMORY.md)
REM بازاندیشی دربارهٔ تم‌ها و ایده‌های تکرارشونده خیر

این فازها جزئیات داخلی پیاده‌سازی هستند، نه «حالت‌های» جداگانه‌ای که کاربر پیکربندی کند.

فاز Light

فاز Light سیگنال‌های حافظهٔ روزانهٔ اخیر و ردهای recall را ingest می‌کند، آن‌ها را dedupe می‌کند، و خط‌های نامزد را آماده می‌کند.

  • از وضعیت recall کوتاه‌مدت، فایل‌های حافظهٔ روزانهٔ اخیر، و رونوشت‌های redacted جلسه در صورت وجود می‌خواند.
  • وقتی ذخیره‌سازی شامل خروجی درون‌خطی باشد، یک بلوک مدیریت‌شدهٔ ## Light Sleep می‌نویسد.
  • سیگنال‌های reinforcement را برای رتبه‌بندی Deep بعدی ثبت می‌کند.
  • هرگز در MEMORY.md نمی‌نویسد.
فاز Deep

فاز Deep تصمیم می‌گیرد چه چیزی به حافظهٔ بلندمدت تبدیل شود.

  • نامزدها را با امتیازدهی وزن‌دار و gateهای آستانه رتبه‌بندی می‌کند.
  • برای عبور، به minScore، minRecallCount، و minUniqueQueries نیاز دارد.
  • پیش از نوشتن، snippetها را از فایل‌های روزانهٔ زنده rehydrate می‌کند تا snippetهای کهنه/حذف‌شده نادیده گرفته شوند.
  • ورودی‌های ارتقایافته را به MEMORY.md اضافه می‌کند.
  • یک خلاصهٔ ## Deep Sleep در DREAMS.md می‌نویسد و در صورت پیکربندی، memory/dreaming/deep/YYYY-MM-DD.md را نیز می‌نویسد.
فاز REM

فاز REM الگوها و سیگنال‌های تأملی را استخراج می‌کند.

  • خلاصه‌های theme و reflection را از ردهای کوتاه‌مدت اخیر می‌سازد.
  • وقتی ذخیره‌سازی شامل خروجی درون‌خطی باشد، یک بلوک مدیریت‌شدهٔ ## REM Sleep می‌نویسد.
  • سیگنال‌های reinforcement فاز REM را که رتبه‌بندی Deep استفاده می‌کند ثبت می‌کند.
  • هرگز در MEMORY.md نمی‌نویسد.

ingestion رونوشت جلسه

Dreaming می‌تواند رونوشت‌های redacted جلسه را در پیکرهٔ Dreaming ingest کند. وقتی رونوشت‌ها موجود باشند، همراه با سیگنال‌های حافظهٔ روزانه و ردهای recall وارد فاز Light می‌شوند. محتوای شخصی و حساس پیش از ingestion redacted می‌شود.

دفترچهٔ رؤیا

Dreaming همچنین یک دفترچهٔ رؤیا روایی در DREAMS.md نگه می‌دارد. پس از آنکه هر فاز مواد کافی داشته باشد، memory-core یک نوبت subagent پس‌زمینه به‌صورت best-effort اجرا می‌کند و یک یادداشت کوتاه دفترچه اضافه می‌کند. مگر اینکه dreaming.model پیکربندی شده باشد، از مدل runtime پیش‌فرض استفاده می‌کند. اگر مدل پیکربندی‌شده در دسترس نباشد، دفترچهٔ رؤیا یک‌بار با مدل پیش‌فرض جلسه دوباره تلاش می‌کند.

همچنین یک مسیر backfill تاریخی grounded برای کارهای بازبینی و بازیابی وجود دارد:

دستورهای Backfill
  • memory rem-harness --path ... --grounded خروجی دفترچهٔ grounded را از یادداشت‌های تاریخی YYYY-MM-DD.md پیش‌نمایش می‌کند.
  • memory rem-backfill --path ... ورودی‌های دفترچهٔ grounded و برگشت‌پذیر را در DREAMS.md می‌نویسد.
  • memory rem-backfill --path ... --stage-short-term نامزدهای پایدار grounded را در همان ذخیرهٔ شواهد کوتاه‌مدتی stage می‌کند که فاز Deep عادی از قبل استفاده می‌کند.
  • memory rem-backfill --rollback و --rollback-short-term آن artifactهای backfill آماده‌شده را بدون دست‌زدن به ورودی‌های عادی دفترچه یا recall کوتاه‌مدت زنده حذف می‌کنند.

رابط کاربری کنترل همان جریان backfill/reset دفترچه را ارائه می‌کند تا بتوانید پیش از تصمیم‌گیری دربارهٔ اینکه نامزدهای grounded شایستهٔ ارتقا هستند یا نه، نتایج را در صحنهٔ رؤیاها بررسی کنید. صحنه همچنین یک مسیر grounded مجزا نشان می‌دهد تا بتوانید ببینید کدام ورودی‌های کوتاه‌مدت stage‌شده از بازپخش تاریخی آمده‌اند، کدام موارد ارتقایافته grounded-led بوده‌اند، و فقط ورودی‌های stage‌شدهٔ grounded-only را بدون دست‌زدن به وضعیت کوتاه‌مدت زندهٔ عادی پاک کنید.

سیگنال‌های رتبه‌بندی Deep

رتبه‌بندی Deep از شش سیگنال پایهٔ وزن‌دار به‌علاوهٔ reinforcement فاز استفاده می‌کند:

سیگنال وزن توضیح
فراوانی 0.24 تعداد سیگنال‌های کوتاه‌مدتی که ورودی انباشته کرده است
ارتباط 0.30 میانگین کیفیت بازیابی برای ورودی
تنوع query 0.15 زمینه‌های query/روز متمایزی که آن را آشکار کرده‌اند
تازگی 0.15 امتیاز تازگی با کاهش زمانی
یکپارچه‌سازی 0.10 قدرت تکرار در چند روز
غنای مفهومی 0.06 چگالی tag مفهومی از snippet/path

hitهای فاز Light و REM یک boost کوچک با کاهش تازگی از memory/.dreams/phase-signals.json اضافه می‌کنند.

نتایج shadow-trial می‌توانند به‌عنوان یک سیگنال بازبینی، پیش از هر نوشتن پایدار، روی آن امتیاز پایه لایه‌بندی شوند. یک trial مفید به نامزد boost کوچک و bounded می‌دهد، یک trial خنثی آن را deferred نگه می‌دارد، و یک trial مضر آن را برای آن گذر امتیازدهی rejected علامت‌گذاری می‌کند. این سیگنال همچنان فقط گزارشی است: می‌تواند ترتیب نامزدها یا metadata بازبینی را تغییر دهد، اما در MEMORY.md نمی‌نویسد و به‌تنهایی نامزد را ارتقا نمی‌دهد.

پوشش گزارش shadow trial در QA

QA Lab یک سناریوی فقط-گزارشی برای بررسی این دارد که shadow trial آیندهٔ Dreaming چگونه می‌تواند پیش از ارتقا یک حافظهٔ نامزد را بازبینی کند. این سناریو از یک agent می‌خواهد یک پاسخ baseline را با پاسخی که می‌تواند از حافظهٔ نامزد استفاده کند مقایسه کند، سپس یک گزارش محلی با verdict، دلیل، و flagهای ریسک بنویسد.

این پوشش عمداً به QA محدود شده است. تأیید می‌کند که artifact گزارش جدا از MEMORY.md باقی می‌ماند و agent ادعا نمی‌کند که نامزد ارتقا یافته است. این پوشش رفتار production برای shadow-trial اضافه نمی‌کند و موتور ارتقای فاز Deep را تغییر نمی‌دهد.

runner مربوط به shadow-trial در memory-core همین قرارداد فقط-گزارشی را برای مسیرهای کدی که به artifact پایدار نیاز دارند نگه می‌دارد. این runner نامزد، prompt آزمایش، نتیجهٔ baseline، نتیجهٔ نامزد، verdict، دلیل، flagهای ریسک، و ارجاع‌های شواهد را می‌پذیرد، سپس گزارشی با promotion action: report-only می‌نویسد. verdictهای مفید به توصیهٔ promote نگاشت می‌شوند، verdictهای خنثی به defer، و verdictهای مضر به reject؛ هیچ‌کدام از این توصیه‌ها در MEMORY.md نمی‌نویسد یا ارتقای فاز Deep را اعمال نمی‌کند.

زمان‌بندی

وقتی فعال باشد، memory-core یک job از نوع Cron را برای یک sweep کامل Dreaming به‌صورت خودکار مدیریت می‌کند. هر sweep فازها را به‌ترتیب اجرا می‌کند: Light → REM → Deep.

این sweep شامل workspace اصلی runtime و هر workspace پیکربندی‌شدهٔ agent است که بر اساس path dedupe شده‌اند، بنابراین fan-out مربوط به workspaceهای subagent باعث حذف DREAMS.md و وضعیت حافظهٔ agent اصلی نمی‌شود.

رفتار cadence پیش‌فرض:

تنظیم پیش‌فرض
dreaming.frequency 0 3 * * *
dreaming.model مدل پیش‌فرض

شروع سریع

فعال‌سازی Dreaming

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

cadence سفارشی sweep

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 را تغییر می‌دهند. فراخوان‌های کانال باید owner باشند، و کلاینت‌های Gateway باید operator.admin داشته باشند. /dreaming status و /dreaming help فقط-خواندنی باقی می‌مانند.

گردش‌کار CLI

پیش‌نمایش / اعمال ارتقا

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

memory promote دستی به‌صورت پیش‌فرض از آستانه‌های فاز Deep استفاده می‌کند، مگر اینکه با flagهای CLI override شده باشد.

توضیح ارتقا

توضیح دهید چرا یک نامزد مشخص ارتقا پیدا می‌کند یا نمی‌کند:

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

پیش‌نمایش harness فاز REM

reflectionهای REM، truthهای نامزد، و خروجی ارتقای Deep را بدون نوشتن هیچ‌چیز پیش‌نمایش کنید:

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

پیش‌فرض‌های کلیدی

همهٔ تنظیمات زیر plugins.entries.memory-core.config.dreaming قرار دارند.

enabledbooleandefault: false

sweep مربوط به Dreaming را فعال یا غیرفعال کنید.

frequencystringdefault: 0 3 * * *

cadence از نوع Cron برای sweep کامل Dreaming.

modelstring

override اختیاری مدل subagent برای دفترچهٔ رؤیا. هنگام تنظیم allowlist مربوط به allowedModels در subagent، از مقدار canonical از نوع provider/model استفاده کنید.

phases.deep.maxPromotedSnippetTokensnumberdefault: 160

حداکثر تعداد token تخمینی که از هر snippet کوتاه‌مدت recall ارتقایافته به MEMORY.md نگه داشته می‌شود. provenance رتبه‌بندی همچنان قابل مشاهده می‌ماند.

رابط کاربری رؤیاها

وقتی فعال باشد، تب رؤیاها در Gateway نشان می‌دهد:

  • وضعیت فعلی فعال‌بودن Dreaming
  • وضعیت در سطح فاز و وجود managed-sweep
  • شمارش‌های کوتاه‌مدت، grounded، signal، و promoted-today
  • زمان اجرای برنامه‌ریزی‌شدهٔ بعدی
  • یک مسیر Scene grounded متمایز برای ورودی‌های بازپخش تاریخی stage‌شده
  • یک خوانندهٔ قابل‌گسترش دفترچهٔ رؤیا با پشتوانهٔ doctor.memory.dreamDiary

Dreaming هرگز اجرا نمی‌شود: status مقدار blocked نشان می‌دهد

اگر openclaw memory status مقدار Dreaming status: blocked را گزارش کند، Cron مدیریت‌شده وجود دارد اما Heartbeat پیش‌فرض agent اجرا نمی‌شود. بررسی کنید که Heartbeat برای agent پیش‌فرض فعال باشد و target آن none نباشد، سپس پس از فاصلهٔ Heartbeat بعدی دوباره openclaw memory status --deep را اجرا کنید.

مرتبط

Was this useful?
On this page

On this page