مدیریت جلسه

OpenClaw گفتگوها را در نشست‌ها سازمان‌دهی می‌کند. هر پیام بر اساس جایی که از آن آمده است، به یک نشست هدایت می‌شود: پیام‌های مستقیم، چت‌های گروهی، کارهای Cron و غیره.

پیام‌ها چگونه هدایت می‌شوند

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

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

راه‌حل:

{  session: {    dmScope: "per-channel-peer", // isolate by channel + sender  },}

گزینه‌های دیگر:

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

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

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

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

چرخه عمر نشست

نشست‌ها تا زمانی که منقضی شوند دوباره استفاده می‌شوند:

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

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

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

وضعیت کجا نگهداری می‌شود

همه وضعیت نشست متعلق به Gateway است. کلاینت‌های رابط کاربری داده‌های نشست را از Gateway درخواست می‌کنند.

• ذخیره‌گاه: ~/.openclaw/agents/<agentId>/sessions/sessions.json
• رونوشت‌ها: ~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

sessions.json مُهرهای زمانی چرخه عمر را جداگانه نگه می‌دارد:

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

ردیف‌های قدیمی‌تر بدون sessionStartedAt، در صورت وجود، از سرآیند نشست در رونوشت JSONL تعیین می‌شوند. اگر یک ردیف قدیمی‌تر lastInteractionAt هم نداشته باشد، تازگی بیکار به زمان شروع همان نشست برمی‌گردد، نه به نوشتن‌های حسابداری بعدی.

نگهداری نشست

OpenClaw به‌طور خودکار اندازه ذخیره‌سازی نشست را در طول زمان محدود می‌کند. به‌طور پیش‌فرض در حالت enforce اجرا می‌شود و پاک‌سازی را هنگام نگهداری اعمال می‌کند. برای گزارش آنچه بدون تغییر دادن ذخیره‌گاه/فایل‌ها پاک می‌شد، session.maintenance.mode را روی "warn" تنظیم کنید:

{  session: {    maintenance: {      mode: "enforce",      pruneAfter: "30d",      maxEntries: 500,    },  },}

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

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

نگهداری، اشاره‌گرهای بادوام گفتگوی خارجی، از جمله نشست‌های گروهی و نشست‌های چت محدود به رشته را حفظ می‌کند، در حالی که همچنان اجازه می‌دهد ورودی‌های ساختگی Cron، hook، 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 -- آنچه در پرامپت سیستم است.

مطالعه بیشتر

• هرس نشست -- کوتاه‌سازی نتایج ابزار
• Compaction -- خلاصه‌سازی گفتگوهای طولانی
• ابزارهای نشست -- ابزارهای عامل برای کار میان‌نشستی
• بررسی عمیق مدیریت نشست -- شِمای ذخیره‌گاه، رونوشت‌ها، سیاست ارسال، فراداده مبدا و پیکربندی پیشرفته
• چندعاملی — هدایت و جداسازی نشست در میان عامل‌ها
• کارهای پس‌زمینه — کار جداشده چگونه رکوردهای کار را با ارجاع‌های نشست ایجاد می‌کند
• هدایت کانال — پیام‌های ورودی چگونه به نشست‌ها هدایت می‌شوند

مرتبط

• هرس نشست
• ابزارهای نشست
• صف دستور