Sessions and memory

مدیریت نشست

OpenClaw هر پیام ورودی را بر اساس مبدأ آن — پیام‌های مستقیم، گفت‌وگوهای گروهی، کارهای cron و غیره — به یک نشست هدایت می‌کند. تمام وضعیت نشست در مالکیت Gateway است؛ کلاینت‌های رابط کاربری داده‌های نشست را از Gateway واکشی می‌کنند.

برای حالت پیش‌فرض عامل شخصی — یک گفت‌وگوی پیوسته که میان همه کانال‌های پیام مستقیم شما مشترک است و فعالیت گروهی و کارهای پس‌زمینه به آن وارد می‌شوند — به نشست اصلی مراجعه کنید.

نحوه هدایت پیام‌ها

منبع رفتار
پیام‌های مستقیم به‌طور پیش‌فرض نشست مشترک
گفت‌وگوهای گروهی برای هر گروه مجزا
اتاق‌ها/کانال‌ها برای هر اتاق مجزا
کارهای Cron برای هر اجرا یک نشست تازه
Webhookها برای هر هوک مجزا

جداسازی پیام‌های مستقیم

به‌طور پیش‌فرض، برای حفظ پیوستگی، همه پیام‌های مستقیم یک نشست مشترک دارند؛ این حالت برای راه‌اندازی‌های تک‌کاربره مناسب است.

json5
{  session: {    dmScope: "per-channel-peer", // جداسازی بر اساس کانال + فرستنده  },}

گزینه‌های session.dmScope:

مقدار رفتار
main (پیش‌فرض) همه پیام‌های مستقیم نشست اصلی را به‌اشتراک می‌گذارند
per-peer جداسازی بر اساس فرستنده، در همه کانال‌ها
per-channel-peer جداسازی بر اساس کانال + فرستنده (توصیه‌شده)
per-account-channel-peer جداسازی بر اساس حساب + کانال + فرستنده

اتصال کانال‌های پیوندخورده

فرمان‌های اتصال، مسیر پاسخ نشست فعلی گفت‌وگوی مستقیم را بدون آغاز نشست جدید به کانال پیوندخورده دیگری منتقل می‌کنند. برای نمونه‌ها، پیکربندی و عیب‌یابی به اتصال کانال مراجعه کنید.

راه‌اندازی خود را با openclaw security audit بررسی کنید.

نشست‌های ناشناس

نشست‌های ناشناس فقط از صفحه رشته جدید در رابط کاربری کنترل در دسترس‌اند. پیش از شروع رشته، ناشناس را فعال کنید تا ورودی نشست، رونوشت و وضعیت Compaction آن به‌جای دیسک در حافظه فرایند نگه‌داری شود. با راه‌اندازی مجدد Gateway، رشته ناپدید می‌شود، تخلیه خودکار حافظه OpenClaw را اجرا نمی‌کند و هنگام بازنشانی یا حذف آن، بایگانی رونوشت ایجاد نمی‌شود. اجراهای مبتنی بر Codex نیز رشته مهار خود را در حالت موقت آغاز می‌کنند؛ بنابراین Codex هیچ فایل اجرای مرحله‌ای یا وضعیت نشست محلی نمی‌نویسد. سایر ارائه‌دهندگان مدل از APIهای HTTP استفاده می‌کنند و هیچ رونوشت محلی ارائه‌دهنده‌ای را در OpenClaw نگه نمی‌دارند.

بخش incognito- برای کلیدهای نشست داشبورد، زیرعامل و داخلی پنهان رزرو شده است؛ openclaw doctor --fix نام هر کلید ماندگار قدیمیِ دارای تداخل را تغییر می‌دهد.

حالت ناشناس ابزارهای معمول عامل را محدود نمی‌کند. درخواست صریح برای ذخیره اطلاعات یا هرگونه نوشتن فایل به‌وسیله ابزار همچنان می‌تواند داده‌ها را خارج از مخزن نشست ناشناس ماندگار کند. ارائه‌دهنده مدل پیکربندی‌شده شما همچنان پیام‌های ارسالی را پردازش می‌کند، گزارش‌گیری تشخیصی بدون تغییر باقی می‌ماند و OpenClaw همچنان فراداده ممیزیِ بدون محتوا، مانند ارجاع‌های HMAC، را ثبت می‌کند.

در Gatewayهای چندکاربره، رشته‌های ناشناس فقط برای اتصال‌های دارای دامنه مدیریتی قابل‌مشاهده‌اند و هرگز از طریق ابزارهای نشست عاملِ نشست دیگری یا جست‌وجوی رونوشت نمایش داده نمی‌شوند. این ویژگی آن‌ها را در برابر ذخیره‌سازی و سایر کاربران واسطه‌شده توسط Gateway محافظت می‌کند، نه در برابر مالک Gateway یا گرداننده فرایند که همواره می‌تواند نشست‌های زنده را مشاهده کند.

یادآوری میان گفت‌وگوها

رونوشت‌های جداگانه، تاریخچه محلی هر گفت‌وگو را کنترل می‌کنند. برای یک عامل شخصی یا کاملاً مورداعتماد، memory.search.rememberAcrossConversations: true یک مرحله بازیابی اختیاری را در دیگر گفت‌وگوهای خصوصی همان عامل اضافه می‌کند؛ این گزینه رونوشت‌های آن‌ها را با هم ترکیب نمی‌کند.

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

این تنظیم کلیدهای نشست، دامنه پیام مستقیم، هدایت، تحویل یا tools.sessions.visibility را تغییر نمی‌دهد. حافظه فضای کاری مشترک در MEMORY.md و memory/*.md نیز رفتار فعلی خود را حفظ می‌کند. ارائه‌دهنده حافظه فعلی باید از یادآوری محافظت‌شده رونوشت خصوصی پشتیبانی کند؛ موتورهای زمینه‌ای مانند Lossless Claw مستقل باقی می‌مانند و می‌توانند در کنار آن اجرا شوند. برای جزئیات راه‌اندازی و زمان اجرا به Active Memory مراجعه کنید.

چرخه عمر نشست

نشست‌ها تا زمانی که آن‌ها را به‌صورت دستی بازنشانی کنید یا یک سیاست بازنشانی خودکار را فعال کنید، دوباره استفاده می‌شوند:

  • بدون بازنشانی خودکار (پیش‌فرض mode: "none") - نشست‌ها همان sessionId را حفظ می‌کنند؛ با رشد گفت‌وگو، Compaction زمینه فعال را مدیریت می‌کند.
  • بازنشانی روزانه (mode: "daily") - ایجاد نشست جدید در یک ساعت محلی پیکربندی‌شده (session.reset.atHour، پیش‌فرض 4، 0-23) روی میزبان Gateway را فعال می‌کند. تازگی روزانه بر اساس زمان آغاز sessionId فعلی محاسبه می‌شود، نه نوشتن‌های بعدی فراداده.
  • بازنشانی هنگام بی‌کاری (mode: "idle") - ایجاد نشست جدید پس از session.reset.idleMinutes بی‌فعالیتی را فعال می‌کند. تازگی بی‌کاری بر اساس آخرین تعامل واقعی کاربر/کانال محاسبه می‌شود؛ بنابراین رویدادهای سیستمی Heartbeat، Cron و اجرا نشست را زنده نگه نمی‌دارند.
  • بازنشانی دستی - در گفت‌وگو /new یا /reset را وارد کنید. /new <model> همچنین مدل را تغییر می‌دهد.

وقتی هر دو بازنشانی روزانه و هنگام بی‌کاری پیکربندی شده باشند، هرکدام زودتر منقضی شود اعمال می‌شود. نوبت‌های Heartbeat، Cron، اجرا و سایر رویدادهای سیستمی ممکن است فراداده نشست را بنویسند، اما این نوشتن‌ها تازگی بازنشانی روزانه یا هنگام بی‌کاری را تمدید نمی‌کنند. هنگامی که بازنشانی نشست را جابه‌جا می‌کند، اعلان‌های رویداد سیستمیِ در صف برای نشست قدیمی دور انداخته می‌شوند تا به‌روزرسانی‌های پس‌زمینه قدیمی به ابتدای نخستین پرامپت در نشست جدید افزوده نشوند.

نشست‌هایی که یک نشست CLI فعال و متعلق به ارائه‌دهنده دارند، از همان حالت پیش‌فرض بدون بازنشانی خودکار پیروی می‌کنند. وقتی این نشست‌ها باید با زمان‌سنج منقضی شوند، از /reset استفاده کنید یا session.reset را صریحاً پیکربندی کنید.

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

json5
{  session: {    reset: { mode: "daily", atHour: 4 },    resetByType: {      group: { mode: "idle", idleMinutes: 120 },      thread: { mode: "daily", atHour: 6 },    },    resetByChannel: {      discord: { mode: "idle", idleMinutes: 10080 },    },  },}

resetByType از direct، group و thread پشتیبانی می‌کند. Doctor ورودی‌های قدیمی dm را به direct و session.idleMinutes را به session.reset.idleMinutes مهاجرت می‌دهد؛ طرح‌واره هر دو شکل بازنشسته را رد می‌کند.

محل نگه‌داری وضعیت

  • ردیف‌های نشست زمان اجرا: ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite
  • فایل‌های رونوشت بایگانی‌شده: ~/.openclaw/agents/<agentId>/sessions/
  • منبع قدیمی مهاجرت ردیف: ~/.openclaw/agents/<agentId>/sessions/sessions.json

ردیف‌های نشست در پایگاه‌داده SQLite مختص هر عامل، مُهرهای زمانی چرخه عمر را جداگانه نگه می‌دارند:

  • sessionStartedAt: زمان آغاز sessionId فعلی؛ بازنشانی روزانه از این استفاده می‌کند.
  • lastInteractionAt: آخرین تعامل کاربر/کانال که طول عمر بی‌کاری را تمدید می‌کند.
  • updatedAt: آخرین تغییر ردیف مخزن؛ برای فهرست‌کردن و هرس مفید است، اما مرجع معتبر تازگی بازنشانی روزانه/هنگام بی‌کاری نیست.

هنگام مهاجرت از نصب‌های قدیمی‌تر، راه‌اندازی Gateway و openclaw doctor --fix ردیف‌های قدیمی sessions.json و تاریخچه فعال رونوشت JSONL را به‌طور خودکار به SQLite وارد می‌کنند. ردیف‌های فاقد sessionStartedAt در صورت امکان از سرآیند نشست رونوشت JSONL قدیمی تعیین می‌شوند. اگر یک ردیف قدیمی‌تر lastInteractionAt را نیز نداشته باشد، تازگی بی‌کاری به زمان شروع همان نشست برمی‌گردد، نه نوشتن‌های دفترداری بعدی. هنگامی که بررسی صریح یا شواهد اعتبارسنجی می‌خواهید، از openclaw doctor --session-sqlite inspect --session-sqlite-all-agents و توالی مهاجرت Doctor استفاده کنید.

نگه‌داری نشست

OpenClaw با استفاده از session.maintenance، با مقادیر پیش‌فرض زیر، اندازه ذخیره‌سازی نشست را در طول زمان محدود می‌کند:

json5
{  session: {    maintenance: {      mode: "enforce", // "enforce" پاک‌سازی را اعمال می‌کند؛ "warn" فقط گزارش می‌دهد      pruneAfter: "30d",      maxEntries: 500,    },  },}

برای محدودیت‌های maxEntries در مقیاس تولید، نوشتن‌های زمان اجرای Gateway از یک بافر کوچک حد بالای آب استفاده می‌کنند و در دسته‌ها تا سقف پیکربندی‌شده پاک‌سازی می‌کنند. خواندن‌های مخزن نشست هنگام راه‌اندازی Gateway ورودی‌ها را هرس یا محدود نمی‌کنند؛ بنابراین راه‌اندازی و نشست‌های مجزای Cron هزینه پاک‌سازی کامل مخزن را نمی‌پردازند. openclaw sessions cleanup --enforce سقف را بلافاصله اعمال می‌کند.

نشست‌های کاوش اجرای مدل Gateway به‌طور پیش‌فرض کوتاه‌عمر هستند. ردیف‌هایی که با agent:*:explicit:model-run-<uuid> مطابقت دارند از نگه‌داری ثابت 24h استفاده می‌کنند، اما پاک‌سازی وابسته به فشار است: فقط زمانی ردیف‌های کاوش قدیمی را حذف می‌کند که فشار نگه‌داری/سقف ورودی نشست ایجاد شده باشد و پیش از آستانه گسترده‌تر سن ورودی‌های قدیمی و سقف ورودی اجرا می‌شود. نشست‌های عادی مستقیم، گروهی، رشته‌ای، Cron، هوک، Heartbeat، ACP و زیرعامل این نگه‌داری 24h را به ارث نمی‌برند.

نگه‌داری، اشاره‌گرهای ماندگار گفت‌وگوی خارجی، از جمله نشست‌های گروهی و نشست‌های گفت‌وگوی محدود به رشته را حفظ می‌کند و در عین حال اجازه می‌دهد ورودی‌های مصنوعی Cron، هوک، Heartbeat، ACP و زیرعامل با گذشت زمان حذف شوند.

نشست‌های بایگانی‌شده توسط کاربر کنار گذاشته شده‌اند و از همه مسیرهای نگه‌داری خودکار، از جمله هرس بر اساس سن، سقف ورودی‌ها، پاک‌سازی اجرای مدل و تخلیه بر اساس بودجه دیسک معاف‌اند. آن‌ها تا زمانی که از بایگانی خارج یا صریحاً حذف شوند، بایگانی‌شده باقی می‌مانند.

اگر قبلاً از جداسازی پیام‌های مستقیم استفاده کرده‌اید و بعداً session.dmScope را به main برگردانده‌اید، ردیف‌های قدیمی پیام مستقیم با کلید همتا را با openclaw sessions cleanup --dry-run --fix-dm-scope پیش‌نمایش کنید. اعمال همان پرچم، آن ردیف‌های قدیمی پیام مستقیم را بازنشسته می‌کند و رونوشت‌هایشان را به‌صورت بایگانی‌های حذف‌شده نگه می‌دارد.

هر اجرای نگه‌داری را با openclaw sessions cleanup --dry-run پیش‌نمایش کنید.

بررسی نشست‌ها

فرمان موارد نمایش‌داده‌شده
openclaw status مسیر مخزن نشست و فعالیت اخیر
openclaw sessions --json همه نشست‌ها (فیلتر با --active <minutes>)
/status در گفت‌وگو میزان استفاده از زمینه، مدل و کلیدهای تغییر وضعیت
/context list محتوای پرامپت سیستم

مطالعه بیشتر

مرتبط

Was this useful?
On this page

On this page