---
read_when:
    - می‌خواهید بدانید آیا راه‌اندازی مجدد Gateway باعث از دست رفتن کار در حال انجام عامل می‌شود یا خیر
    - اجرای یک عامل بر اثر راه‌اندازی مجدد، خرابی یا بارگذاری مجدد پیکربندی متوقف شد
    - در حال اشکال‌زدایی بازیابی خودکار نشست پس از راه‌اندازی مجدد Gateway هستید
summary: 'آنچه پس از راه‌اندازی مجدد یا از کار افتادن Gateway باقی می‌ماند: نوبت‌های عاملِ قطع‌شده به‌طور خودکار از سر گرفته می‌شوند، زیرعامل‌ها و وظایف پس‌زمینه بازیابی می‌شوند و تحویل‌های صف‌شده انجام می‌گیرند'
title: بازیابی پس از راه‌اندازی مجدد
x-i18n:
    generated_at: "2026-07-16T16:57:02Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: f2fc0263d792e78e75fb97be44671b44287d469b949e11640f11b6ff651dafb9
    source_path: gateway/restart-recovery.md
    workflow: 16
---

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

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

## چه چیزهایی پس از راه‌اندازی مجدد باقی می‌مانند

| وضعیت                         | محل ذخیره‌سازی                                     | رفتار در راه‌اندازی مجدد                                                 |
| ----------------------------- | ------------------------------------------- | ----------------------------------------------------------------------- |
| تاریخچهٔ مکالمه          | پایگاه دادهٔ SQLite به‌ازای هر عامل                   | بدون تغییر باقی می‌ماند؛ نشست‌ها از رونوشت ذخیره‌شده ادامه می‌یابند                 |
| نوبت قطع‌شدهٔ نشست اصلی | ردیف نشست و رونوشت SQLite به‌ازای هر عامل | چند ثانیه پس از راه‌اندازی به‌طور خودکار از سر گرفته یا تطبیق داده می‌شود         |
| اجراهای زیرعامل                 | SQLite (پایگاه دادهٔ وضعیت مشترک)              | رجیستری هنگام بوت بازیابی می‌شود؛ اجراهای قطع‌شده از سر گرفته می‌شوند                     |
| وظایف پس‌زمینه              | SQLite (پایگاه دادهٔ وضعیت مشترک)              | هنگام بوت تطبیق داده می‌شوند؛ اجراهای بدون مالک بازیابی می‌شوند یا گم‌شده علامت می‌خورند              |
| تحویل‌های خروجیِ در صف    | صف تحویل SQLite                       | پس از راه‌اندازی مجدد تخلیه می‌شود؛ پاسخ‌های تحویل‌نشده دوباره امتحان می‌شوند                  |
| کارهای زمان‌بندی‌شده (Cron)         | مخزن Cron در SQLite                           | زمان‌بندی‌ها باقی می‌مانند؛ زمان‌بند هنگام بوت دوباره فعال می‌شود                        |
| ادامه پس از راه‌اندازی مجدد          | نشانگر راه‌اندازی مجدد SQLite                     | یک پیگیری یک‌باره به نشستی ارسال می‌شود که راه‌اندازی مجدد را درخواست کرده بود |

## راه‌اندازی‌های مجدد کنترل‌شده ابتدا منتظر تخلیه می‌مانند

راه‌اندازی مجدد درخواستی (`openclaw gateway restart`، تغییری در پیکربندی که به
راه‌اندازی مجدد نیاز دارد، یا به‌روزرسانی Gateway) کارهای در حال اجرا را بلافاصله متوقف نمی‌کند.
Gateway پذیرش کار جدید را متوقف می‌کند و سپس تا سقف مهلت تخلیه (به‌طور پیش‌فرض 5 دقیقه)
منتظر می‌ماند تا نوبت‌های فعال عامل و وظایف پس‌زمینه تمام شوند. بنابراین، بیشتر
راه‌اندازی‌های مجدد اصلاً چیزی را قطع نمی‌کنند.

فقط کاری که نتواند در مهلت تخلیه تمام شود (یا هر اجرایی که بر اثر
راه‌اندازی مجدد اجباری یا خرابی قطع شده باشد) متوقف می‌شود — و پیش از آن،
هر نشست متأثر برای بازیابی علامت‌گذاری می‌شود.

## کار قطع‌شده چگونه شناسایی می‌شود

سه سازوکار مکمل، نشست‌هایی را علامت‌گذاری می‌کنند که نوبتشان تمام نشده است:

- **هنگام پذیرش نوبت:** برای یک نوبت متنی عادی در نشست اصلی موجود،
  Gateway پیام کاربر را اضافه می‌کند، نشست را در حال اجرا علامت می‌زند و
  ادعای تحویل بازیابی آن را، پیش از اجرای مدل یا قلاب
  `before_agent_reply`، در یک تراکنش SQLite ثبت می‌کند. Control UI این کار را پیش از بازگرداندن
  تأییدیهٔ `started` انجام می‌دهد؛ ارسال کانال نیز هنگامی این کار را انجام می‌دهد که نوبت آماده‌شده
  اجرای عامل را به اختیار می‌گیرد.
  فرمان‌ها، پیوست‌ها، بازنویسی‌های مختص هر نوبت، تحویل‌های در انتظار، نشانه‌های توقف قبلی،
  نشست‌های تحت مالکیت Plugin و نوبت‌های دارای قلاب اجرا، مسیرهای
  پذیرش تخصصی خود را حفظ می‌کنند.
  اگر قلاب `before_agent_reply` نصب شده باشد، پذیرش مرحلهٔ آن را نیز ثبت می‌کند.
  بازیابی هرگز قلابی را که در میانهٔ فراخوانی قطع شده است دوباره اجرا نمی‌کند. پس از پایان یک قلاب
  مدیریت‌نشده، نقطهٔ وارسی آن نتیجه را ثبت می‌کند، اما تا زمانی که آن قلاب فعال باشد،
  بازیابی همچنان با رویکرد بسته و ایمن شکست می‌خورد: نقطهٔ وارسی نمی‌تواند ثابت کند که
  همان کد و پیکربندی Plugin پس از راه‌اندازی مجدد بارگذاری شده‌اند. نتایج متنی
  مدیریت‌شده و نتایج بی‌صدا برای نهایی‌سازی قطعی، جداگانه در نقطهٔ وارسی ثبت می‌شوند.
  ادعاهای بازیابی پایدار که نسخه‌های قدیمی‌تر نوشته‌اند، نشانگر مالکیت منبع ندارند؛
  بنابراین هنگام ارتقا نیز همان بررسی بسته و ایمن قلاب روی آن‌ها اعمال می‌شود.
- **هنگام خاموش‌شدن:** در طول تخلیهٔ راه‌اندازی مجدد، هر نشست دارای اجرای فعال
  پیش از توقف اجرا، در مخزن نشست با نشانگر بازیابی
  مهر می‌شود.
- **هنگام راه‌اندازی:** Gateway مخازن نشست را برای یافتن نشست‌هایی بررسی می‌کند که هنوز
  ادعا می‌کنند در حال اجرا هستند، اما در فرایند جدید هیچ مالک فعالی ندارند. این کار
  خرابی‌ها و توقف‌های اجباری‌ای را پوشش می‌دهد که در آن‌ها هیچ کد خاموش‌سازی اجرا نشده است. فایل‌های قفل
  منقضی‌شدهٔ رونوشت نیز هم‌زمان پاک‌سازی می‌شوند.

## ازسرگیری خودکار

چند ثانیه پس از راه‌اندازی، Gateway هر نشست علامت‌گذاری‌شده را دوباره
با یک پیام سیستمی مصنوعی ارسال می‌کند که به عامل می‌گوید نوبت قبلی‌اش بر اثر
راه‌اندازی مجدد قطع شده و باید از رونوشت موجود ادامه دهد. اگر
پاسخ نهایی قبلاً تولید شده اما تحویل نشده باشد، متن آن نیز گنجانده می‌شود
تا عامل به‌جای انجام دوبارهٔ کار، آن را تحویل دهد. بازیابی با پس‌روی نمایی تا
3 بار دوباره تلاش می‌کند. هر تلاش مجدد از یک شناسهٔ ارسال پایدار استفاده می‌کند،
بنابراین خرابی مبهم اتصال نمی‌تواند همان بازیابی را دو بار آغاز کند.
نوبت‌های تکمیل‌شده و غیرقابل‌ازسرگیری Control UI نیز سنگ‌قبرهای پایدار و
محدودِ هم‌توانی را نگه می‌دارند تا صندوق خروجیِ دوباره متصل‌شونده بتواند آن‌ها را
بدون اجرای مجدد درخواست کنار بگذارد.

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

پاسخ تحویل‌شده همچنین با شناسهٔ پیام مبدأ خود در رونوشت بازتاب داده می‌شود.
بازتاب‌های نهایی از کلید رسید متمایزی استفاده می‌کنند تا ارسال پیشرفت با
همان کلید هم‌توانی ارائه‌دهنده نتواند نشانگر نهایی را پنهان کند. ارسال‌های پیشرفت
و رسیدهای نوبت‌های قدیمی‌تر نمی‌توانند نوبت کنونی را تکمیل کنند. فقط
ادعاهای پایدار ورودی کانال می‌توانند اختیار کنش پیام را بازیابی کنند. اجرای ازسرگرفته‌شده،
حالت تحویل مبدأ و هم‌بستگی مبدأ اصلی را، از جمله هویت درخواست‌کننده
و هر محدودیت همان کانال/رشته، حفظ می‌کند؛ بنابراین همان رسید حتی اگر
راه‌اندازی مجدد دیگری هنگام بازیابی رخ دهد، همچنان مرجع معتبر باقی می‌ماند. نوبتی که
فقط از ابزار پیام استفاده می‌کند و اختیار کانال آن قابل بازسازی نیست، با رویکرد بسته و ایمن
شکست می‌خورد و اعلان یک‌بارهٔ ارسال مجدد را دریافت می‌کند.

پیش از ازسرگیری، Gateway بررسی می‌کند که ادامه‌دادن از انتهای رونوشت
ایمن باشد. اگر چنین نباشد (برای مثال، نوبت با تأیید در انتظارِ منقضی‌شده
پایان یافته باشد)، نشست کورکورانه دوباره اجرا نمی‌شود؛ در عوض، عامل اعلان کوتاهی
منتشر می‌کند و از کاربر می‌خواهد آخرین درخواست را دوباره ارسال کند. در WebChat، آن اعلان
مستقیماً در تاریخچهٔ نشست نوشته می‌شود تا پس از اتصال مجدد همچنان قابل‌مشاهده باشد.

OpenClaw همچنین می‌تواند کار فقط‌خواندنیِ قطع‌شدهٔ [حالت کد](/fa/reference/code-mode)
را بازسازی کند. حالت کد این اجراها را برای راه‌اندازی مجدد ایمن علامت می‌زند و ابزارهای
کاتالوگ یا فضاهای نام Plugin دارای اثر جانبی را پیش از اجرا رد می‌کند. اگر راه‌اندازی مجدد روی
کنترل `wait` رخ دهد، Gateway جدید نوبت را از رونوشت آن بازسازی می‌کند
و اجرای بازسازی‌شده را وادار می‌کند برای راه‌اندازی مجدد ایمن باقی بماند، حتی اگر
مدل آن پرچم را حذف یا پاک کند. میزبان کل نوبت بازسازی‌شده را به ابزارهای هسته‌ای
فقط‌خواندنیِ ممیزی‌شده و ابزارهای Plugin که صریحاً برای بازپخش ایمن هستند محدود می‌کند،
حتی اگر حالت کد پس از راه‌اندازی مجدد غیرفعال شده باشد. کار دارای اثر جانبی
به‌جای ایجاد خطر نوشتن تکراری، همچنان با اعلان ارسال مجدد محافظت می‌شود.

### زیرعامل‌ها

اجراهای زیرعامل در پایگاه دادهٔ وضعیت مشترک SQLite ماندگار می‌شوند، بنابراین
رجیستری زیرعامل پس از پایان فرایند باقی می‌ماند. هنگام بوت، رجیستری بازیابی می‌شود و
نشست‌های زیرعامل قطع‌شده با زمینهٔ وظیفهٔ اصلی خود از سر گرفته می‌شوند.
دو سازوکار ایمنی اعمال می‌شود:

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

### وظایف پس‌زمینه

[رجیستری وظایف پس‌زمینه](/fa/automation/tasks) با SQLite پشتیبانی می‌شود و
هنگام بوت و در بازه‌های دوره‌ای تطبیق داده می‌شود: نتایج پایدار ثبت‌شده توسط
اجراهای پایان‌یافته بازیابی می‌شوند و اجراهایی که فرایند مالکشان ناپدید شده است،
پس از یک مهلت کوتاه به‌جای معلق‌ماندن همیشگی، گم‌شده علامت می‌خورند.

### راه‌اندازی‌های مجدد درخواستی عامل

هنگامی که خود عامل راه‌اندازی مجدد را فعال می‌کند (اعمال تغییر پیکربندی، به‌روزرسانی
Gateway یا درخواست صریح راه‌اندازی مجدد)، پیش از خروج فرایند یک نشانگر راه‌اندازی مجدد
در SQLite نوشته می‌شود. پس از بوت، Gateway نتیجه را به گفت‌وگوی مبدأ ارسال می‌کند
و یک نوبت ادامهٔ یک‌باره می‌فرستد تا عامل دقیقاً از همان‌جایی که متوقف شده بود،
در همان کانال و رشته ادامه دهد.

## سازوکارهای ایمنی و مشاهده‌پذیری

- **شکنندهٔ حلقهٔ خرابی:** 3 بوت ناپاک در مدت 5 دقیقه، شکننده‌ای را فعال می‌کند که
  راه‌اندازی خودکار سرویس‌های جانبی را در بوت بعدی متوقف می‌کند تا Gateway در حال خرابی
  وضعیت خود را تشدید نکند. پس از پایان پنجرهٔ بوت‌های ناپاک، بازیابی می‌شود.
- **معیارها:** فعالیت بازیابی از طریق
  [Prometheus](/fa/gateway/prometheus) با نام‌های `openclaw_session_recovery_total` و
  `openclaw_session_recovery_age_seconds` صادر می‌شود.
- **گزارش‌ها:** تصمیم‌های بازیابی در زیرسامانه‌های
  `main-session-restart-recovery` و `subagent-interrupted-resume`
  ثبت می‌شوند.

## چه چیزهایی از سر گرفته نمی‌شوند

- نشست‌هایی که از بازیابی نشست اصلی مستثنا هستند، زیرا مالک دیگری از قبل
  آن‌ها را مدیریت می‌کند: نشست‌های زیرعامل (بازیابی زیرعامل)، نشست‌های Cron (زمان‌بند
  طبق برنامه دوباره اجرا می‌کند) و نشست‌های تحت مدیریت ACP (IDE یا
  کلاینت متصل مالک ازسرگیری است).
- نشست‌هایی که ادامهٔ ایمن از انتهای رونوشتشان ممکن نیست؛ این نشست‌ها
  به‌جای اجرای مجدد بی‌صدا، اعلان ارسال مجددِ شرح‌داده‌شده در بالا را دریافت می‌کنند.
- کاری که هرگز پذیرفته نشده است: پیام‌هایی که در پنجرهٔ تخلیه می‌رسند،
  به‌جای قرارگرفتن بی‌صدا در صف فرایندی که در حال پایان است، با خطای صریح
  راه‌اندازی مجدد رد می‌شوند.