Sessions and memory

جلسه اصلی

OpenClaw پیش از هر چیز یک عامل شخصی است. به‌صورت پیش‌فرض، هر پیام مستقیمی که از هر جایی — Telegram، WhatsApp، iMessage، پیام‌های مستقیم Slack، برنامهٔ وب یا هر جای دیگر — برای آن می‌فرستید، وارد یک گفت‌وگوی پیوسته می‌شود: نشست اصلی. در تلفن خود چیزی بپرسید، از لپ‌تاپتان ادامه دهید؛ عامل در هر دو جا همان زمینه را در اختیار دارد. یک مغز وجود دارد و اینجا جایی است که فکر می‌کند.

در پشت صحنه، نشست اصلی یک نشست عادی با کلید agent:<agentId>:main (برای مثال agent:main:main) است. آنچه آن را ویژه می‌کند این است که دامنهٔ پیش‌فرض پیام مستقیم، همهٔ پیام‌های مستقیم را در آن ادغام می‌کند و بقیهٔ سیستم آن را به‌عنوان ریشهٔ عامل در نظر می‌گیرد: Heartbeatها آن را بیدار می‌کنند، کارهای پس‌زمینه نتایج خود را به آن گزارش می‌دهند و فعالیت‌های دیگر بخش‌ها به آن سرازیر می‌شوند.

خانه

در برنامهٔ وب، نشست اصلی صفحهٔ خانه است — نخستین ورودی در نوار کناری. ردیف هویت در بالا عامل شماست (برای بازکردن منوی عامل روی آن کلیک کنید)؛ خانه جایی است که با آن گفت‌وگو می‌کنید. نشست‌هایی که از گفت‌وگوی اصلی منشعب می‌شوند زیر رشته‌ها، گفت‌وگوهای گروهی زیر گروه‌ها و نشست‌های کدنویسی/CLI زیر کدنویسی نمایش داده می‌شوند.

چه چیزهایی وارد نشست اصلی می‌شوند

نشست اصلی صرفاً یک گزارش گفت‌وگو نیست؛ جایی است که دنیای عامل شما در آن به هم می‌پیوندد:

فعالیت گروهی. نشست‌های گروه و اتاق جدا باقی می‌مانند (پایین‌تر را ببینید)، اما در دامنهٔ پیش‌فرض پیام مستقیم، نشست اصلی به‌طور خودکار آن‌ها را زیر نظر می‌گیرد. فعالیت‌ها به‌شکل اعلان‌های فشرده در صف قرار می‌گیرند — برای هر گفت‌وگو با هم ادغام می‌شوند و هرگز به‌ازای هر پیام یک بیدارباش ایجاد نمی‌شود — و عامل در اجرای بعدی آن‌ها را می‌بیند: هنگام پیام بعدی شما یا در یک Heartbeat زمان‌بندی‌شده. عامل همچنین می‌تواند نشست‌هایی را که زیر نظر دارد بخواند، بنابراین پرسشی مانند «در گروه خانواده چه چیزهایی را از دست دادم؟» کار می‌کند.
کار پس‌زمینه. عامل‌های فرعی و نشست‌های ایجادشده نتایج خود را به نشستی که آن‌ها را آغاز کرده است اعلام می‌کنند؛ بنابراین کاری که عامل از خانه آغاز کرده، نتیجه‌اش را به خانه گزارش می‌دهد.
Heartbeatها. Heartbeatهای زمان‌بندی‌شده نشست اصلی را هدف می‌گیرند و همین اعلان‌های در صف را حتی زمانی که چیزی ننوشته‌اید به آگاهی تبدیل می‌کند.

حافظه در میان بازنشانی‌ها و گفت‌وگوها

گفت‌وگوی پیوسته به پنجرهٔ زمینهٔ مدل محدود است؛ بنابراین تداوم از لایه‌های پیرامون آن تأمین می‌شود:

MEMORY.md، حافظهٔ بلندمدت گزینش‌شدهٔ عامل، در هر نشست تازه بارگذاری می‌شود. یادداشت‌های روزانه (memory/YYYY-MM-DD.md) در صورت نیاز قابل جست‌وجو هستند و موارد اخیر پس از یک /new یا /reset دوباره آماده می‌شوند. پیش از Compaction، عامل واقعیت‌های ماندگار را در یادداشت‌های روزانه ثبت می‌کند تا گفت‌وگوهای طولانی آن‌ها را بی‌سروصدا از دست ندهند.
بازیابی حافظه در میان گفت‌وگوها به عامل امکان می‌دهد محتوای نشست‌های خصوصی دیگر خود را به یاد بیاورد. در پیکربندی‌های شخصی — وقتی session.dmScope سراسری بدون هیچ بازنویسی پیام مستقیم برای اتصال‌ها به main حل می‌شود — این قابلیت به‌طور پیش‌فرض فعال است؛ هرگونه جداسازی پیکربندی‌شدهٔ پیام مستقیم، آن را غیرفعال می‌کند مگر اینکه صریحاً فعالش کنید. پیکربندی حافظه را ببینید.

نشستی پیوسته با تاریخچهٔ ماندگار

نشست اصلی به‌جای اینکه مدل را وادار کند تمام تاریخچه را یک‌باره حمل کند، از میان بازنشانی‌ها و Compactionها به‌صورت پیوسته پیش می‌رود:

به‌طور پیش‌فرض بازنشانی خودکاری وجود ندارد؛ Compaction زمینهٔ فعال را محدود نگه می‌دارد و هم‌زمان نشست پیوسته را حفظ می‌کند. بازنشانی‌های روزانه و ناشی از بی‌کاری اختیاری هستند (مدیریت نشست را ببینید). هنگام /new و /reset، بخش پایانی گفت‌وگوی خاتمه‌یافته در یادداشت‌های حافظهٔ روزانه ذخیره می‌شود و نشست بعدی یادداشت‌های اخیر را دوباره آماده می‌کند. بازنشانی یک شناسهٔ نشست زندهٔ جدید اختصاص می‌دهد، اما رونوشت SQLite قبلی را با همان کلید نشست اصلی قابل جست‌وجو نگه می‌دارد.
وقتی گفت‌وگو به پنجرهٔ زمینه نزدیک می‌شود، Compaction آن را خلاصه می‌کند و در همان‌جا ادامه می‌دهد — تاریخچهٔ رونوشت در مخزن نشست باقی می‌ماند.
فهرست نشست‌ها گفت‌وگوی زندهٔ فعلی را نشان می‌دهد، نه همهٔ شناسه‌های نشست تاریخی پشت آن را.
وقتی پایگاه دادهٔ فیزیکی، WAL و مصنوعات نشست در مخزن هر عامل از بودجهٔ دیسک (به‌طور پیش‌فرض 10 GB) فراتر بروند، OpenClaw قدیمی‌ترین تاریخچهٔ بدون ارجاع را پیش از حذف ردیف‌های آن از پایگاه داده، در یک بایگانی فشردهٔ تأییدشده استخراج می‌کند. نشست‌های زنده، مسیریابی‌شده و در حال اجرا هرگز قربانی محدودیت بودجه نمی‌شوند.

وقتی به‌جای آن جداسازی می‌خواهید

نشست اصلی مشترک، پیش‌فرض مناسبی برای عاملی است که فقط شما با آن گفت‌وگو می‌کنید. اگر چند نفر می‌توانند به عامل شما پیام دهند، پیام‌های مستقیم را جدا کنید:

json5

{  session: {    dmScope: "per-channel-peer",  },}

با دامنه‌ای جداساز، هر فرستنده نشست مختص خود را دریافت می‌کند، نظارت بر گروه‌ها از نشست اصلی غیرفعال می‌شود و بازیابی حافظه در میان گفت‌وگوها به‌طور پیش‌فرض خاموش است. openclaw security audit هنگام تشخیص چند فرستندهٔ پیام مستقیم، جداسازی را توصیه می‌کند. ماتریس کامل دامنه‌ها، پیوند هویت و بازنویسی‌های هر مسیر در مدیریت نشست و مسیریابی کانال پوشش داده شده‌اند.

مرتبط

مدیریت نشست — مسیریابی، دامنه‌ها، بازنشانی‌ها
مسیریابی کانال — نحوهٔ انتخاب عامل‌ها و نشست‌ها
حافظه — لایه‌های حافظهٔ ماندگار
چندعاملی — اجرای چند عامل جداشده

Was this useful?