---
read_when:
    - تغییر اجرای پاسخ خودکار یا هم‌زمانی
    - توضیح حالت‌های /queue یا رفتار هدایت پیام
summary: حالت‌های صف پاسخ خودکار، پیش‌فرض‌ها و بازنویسی‌های مختص هر نشست
title: صف فرمان‌ها
x-i18n:
    generated_at: "2026-05-02T11:43:32Z"
    model: gpt-5.5
    provider: openai
    source_hash: c59ea6802d8bf526f4005db3b1baa87d96a23d561c916f91520e8e641fbaf74f
    source_path: concepts/queue.md
    workflow: 16
---

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

## چرا

- اجراهای پاسخ خودکار می‌توانند پرهزینه باشند (فراخوانی‌های LLM) و وقتی چند پیام ورودی نزدیک به هم می‌رسند ممکن است با هم برخورد کنند.
- سری‌سازی از رقابت بر سر منابع مشترک (فایل‌های نشست، لاگ‌ها، stdin مربوط به CLI) جلوگیری می‌کند و احتمال محدودیت نرخ بالادستی را کاهش می‌دهد.

## نحوه کار

- یک صف FIFO آگاه از لِین، هر لِین را با سقف همزمانی قابل پیکربندی تخلیه می‌کند (پیش‌فرض 1 برای لِین‌های پیکربندی‌نشده؛ main به‌طور پیش‌فرض 4 و subagent به‌طور پیش‌فرض 8 است).
- `runEmbeddedPiAgent` بر اساس **کلید نشست** (لِین `session:<key>`) در صف قرار می‌دهد تا تضمین شود برای هر نشست فقط یک اجرای فعال وجود دارد.
- سپس هر اجرای نشست در یک **لِین سراسری** (به‌طور پیش‌فرض `main`) صف‌بندی می‌شود تا موازی‌سازی کلی توسط `agents.defaults.maxConcurrent` محدود شود.
- وقتی لاگ‌گیری مفصل فعال باشد، اجراهای صف‌بندی‌شده اگر پیش از شروع بیش از حدود 2 ثانیه منتظر مانده باشند، یک اعلان کوتاه منتشر می‌کنند.
- نشانگرهای تایپ همچنان بلافاصله هنگام قرار گرفتن در صف فعال می‌شوند (وقتی کانال پشتیبانی کند)، بنابراین تجربه کاربر هنگام انتظار برای نوبت تغییری نمی‌کند.

## پیش‌فرض‌ها

وقتی تنظیم نشده باشد، همه سطوح کانال ورودی از این موارد استفاده می‌کنند:

- `mode: "steer"`
- `debounceMs: 500`
- `cap: 20`
- `drop: "summarize"`

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

## حالت‌های صف

پیام‌های ورودی می‌توانند اجرای فعلی را هدایت کنند، برای نوبت پیگیری منتظر بمانند، یا هر دو کار را انجام دهند:

- `steer`: پیام‌های هدایت را در زمان اجرای فعال صف‌بندی می‌کند. Pi همه پیام‌های هدایت در انتظار را **پس از پایان اجرای فراخوانی‌های ابزار توسط نوبت فعلی دستیار**، پیش از فراخوانی بعدی LLM، تحویل می‌دهد؛ سرور برنامه Codex یک `turn/steer` دسته‌ای دریافت می‌کند. اگر اجرا به‌طور فعال در حال استریم نباشد یا هدایت در دسترس نباشد، OpenClaw به یک ورودی صف پیگیری بازمی‌گردد.
- `queue` (قدیمی): هدایت قدیمیِ یکی‌درهرنوبت. Pi در هر مرز مدل یک پیام هدایت صف‌بندی‌شده را تحویل می‌دهد؛ سرور برنامه Codex درخواست‌های جداگانه `turn/steer` دریافت می‌کند. مگر اینکه به رفتار سری‌سازی‌شده قبلی نیاز داشته باشید، `steer` را ترجیح دهید.
- `followup`: هر پیام را برای نوبت بعدی عامل پس از پایان اجرای فعلی در صف قرار می‌دهد.
- `collect`: پیام‌های صف‌بندی‌شده را پس از پنجره سکوت در یک نوبت پیگیری **واحد** ادغام می‌کند. اگر پیام‌ها کانال‌ها/رشته‌های متفاوتی را هدف بگیرند، برای حفظ مسیریابی به‌صورت جداگانه تخلیه می‌شوند.
- `steer-backlog` (یا `steer+backlog`): اکنون هدایت می‌کند **و** همان پیام را برای یک نوبت پیگیری حفظ می‌کند.
- `interrupt` (قدیمی): اجرای فعال آن نشست را قطع می‌کند، سپس جدیدترین پیام را اجرا می‌کند.

Steer-backlog یعنی می‌توانید پس از اجرای هدایت‌شده یک پاسخ پیگیری بگیرید، بنابراین
سطوح استریم ممکن است شبیه موارد تکراری به نظر برسند. اگر برای هر پیام ورودی
یک پاسخ می‌خواهید، `collect`/`steer` را ترجیح دهید.

برای زمان‌بندی و رفتار وابستگی مختص زمان اجرا، به
[صف هدایت](/fa/concepts/queue-steering) مراجعه کنید.

به‌صورت سراسری یا برای هر کانال از طریق `messages.queue` پیکربندی کنید:

```json5
{
  messages: {
    queue: {
      mode: "steer",
      debounceMs: 500,
      cap: 20,
      drop: "summarize",
      byChannel: { discord: "collect" },
    },
  },
}
```

## گزینه‌های صف

گزینه‌ها برای `followup`، `collect` و `steer-backlog` اعمال می‌شوند (و برای `steer` یا `queue` قدیمی وقتی هدایت به پیگیری بازمی‌گردد):

- `debounceMs`: پنجره سکوت پیش از تخلیه پیگیری‌های صف‌بندی‌شده. اعداد خام بر حسب میلی‌ثانیه هستند؛ واحدهای `ms`، `s`، `m`، `h` و `d` توسط گزینه‌های `/queue` پذیرفته می‌شوند.
- `cap`: بیشینه پیام‌های صف‌بندی‌شده برای هر نشست. مقادیر کمتر از `1` نادیده گرفته می‌شوند.
- `drop: "summarize"`: پیش‌فرض. ورودی‌های قدیمی‌تر صف را در صورت نیاز حذف می‌کند، خلاصه‌های فشرده را نگه می‌دارد، و آن‌ها را به‌عنوان یک پرامپت پیگیری مصنوعی تزریق می‌کند.
- `drop: "old"`: ورودی‌های قدیمی‌تر صف را در صورت نیاز حذف می‌کند، بدون حفظ خلاصه‌ها.
- `drop: "new"`: وقتی صف از قبل پر است، جدیدترین پیام را رد می‌کند.

پیش‌فرض‌ها: `debounceMs: 500`، `cap: 20`، `drop: summarize`.

## تقدم

برای انتخاب حالت، OpenClaw به این ترتیب حل می‌کند:

1. بازنویسی درون‌خطی یا ذخیره‌شده `/queue` برای هر نشست.
2. `messages.queue.byChannel.<channel>`.
3. `messages.queue.mode`.
4. پیش‌فرض `steer`.

برای گزینه‌ها، گزینه‌های درون‌خطی یا ذخیره‌شده `/queue` بر پیکربندی مقدم هستند. سپس
debounce مختص کانال (`messages.queue.debounceMsByChannel`)، پیش‌فرض‌های debounce مربوط به Plugin،
گزینه‌های سراسری `messages.queue`، و پیش‌فرض‌های داخلی اعمال می‌شوند. `cap` و `drop` گزینه‌های سراسری/نشستی هستند، نه کلیدهای پیکربندی برای هر کانال.

## بازنویسی‌های هر نشست

- برای ذخیره حالت برای نشست فعلی، `/queue <mode>` را به‌عنوان یک فرمان مستقل ارسال کنید.
- گزینه‌ها را می‌توان ترکیب کرد: `/queue collect debounce:0.5s cap:25 drop:summarize`
- `/queue default` یا `/queue reset` بازنویسی نشست را پاک می‌کند.

## دامنه و تضمین‌ها

- برای اجراهای عامل پاسخ خودکار در همه کانال‌های ورودی که از خط لوله پاسخ Gateway استفاده می‌کنند اعمال می‌شود (وب WhatsApp، Telegram، Slack، Discord، Signal، iMessage، وب‌چت و غیره).
- لِین پیش‌فرض (`main`) برای ورودی + Heartbeat‌های اصلی در سطح فرآیند است؛ برای مجاز کردن چند نشست به‌صورت موازی، `agents.defaults.maxConcurrent` را تنظیم کنید.
- ممکن است لِین‌های اضافی وجود داشته باشند (مثلاً `cron`، `cron-nested`، `nested`، `subagent`) تا کارهای پس‌زمینه بتوانند بدون مسدود کردن پاسخ‌های ورودی به‌صورت موازی اجرا شوند. نوبت‌های عامل Cron ایزوله یک اسلات `cron` را نگه می‌دارند در حالی که اجرای درونی عامل از `cron-nested` استفاده می‌کند؛ هر دو از `cron.maxConcurrentRuns` استفاده می‌کنند. جریان‌های `nested` غیر-Cron مشترک رفتار لِین خودشان را حفظ می‌کنند. این اجراهای جداشده به‌عنوان [کارهای پس‌زمینه](/fa/automation/tasks) ردیابی می‌شوند.
- لِین‌های هر نشست تضمین می‌کنند که در هر زمان فقط یک اجرای عامل به یک نشست مشخص دست می‌زند.
- بدون وابستگی خارجی یا رشته‌های worker پس‌زمینه؛ فقط TypeScript + promiseها.

## عیب‌یابی

- اگر فرمان‌ها گیرکرده به نظر می‌رسند، لاگ‌های مفصل را فعال کنید و برای تأیید تخلیه شدن صف، به‌دنبال خطوط «queued for …ms» بگردید.
- اگر به عمق صف نیاز دارید، لاگ‌های مفصل را فعال کنید و خطوط زمان‌بندی صف را زیر نظر بگیرید.
- اجراهای سرور برنامه Codex که یک نوبت را می‌پذیرند و سپس انتشار پیشرفت را متوقف می‌کنند، توسط آداپتور Codex قطع می‌شوند تا لِین نشست فعال بتواند آزاد شود، به‌جای اینکه منتظر پایان مهلت اجرای بیرونی بماند.
- وقتی تشخیص‌ها فعال باشند، نشست‌هایی که پس از `diagnostics.stuckSessionWarnMs` بدون هیچ پاسخ، ابزار، وضعیت، بلوک، یا پیشرفت ACP مشاهده‌شده‌ای در `processing` باقی می‌مانند، بر اساس فعالیت فعلی دسته‌بندی می‌شوند. کار فعال با `session.long_running` لاگ می‌شود؛ کار فعال بدون پیشرفت اخیر با `session.stalled` لاگ می‌شود؛ `session.stuck` برای حسابداری نشست کهنه بدون کار فعال رزرو شده است، و فقط همان مسیر می‌تواند لِین نشست آسیب‌دیده را آزاد کند تا کارهای صف‌بندی‌شده تخلیه شوند. تشخیص‌های تکراری `session.stuck` تا زمانی که نشست بدون تغییر بماند، با عقب‌نشینی انجام می‌شوند.

## مرتبط

- [مدیریت نشست](/fa/concepts/session)
- [صف هدایت](/fa/concepts/queue-steering)
- [سیاست تلاش مجدد](/fa/concepts/retry)
