---
read_when:
    - تغيير تنفيذ الرد التلقائي أو التزامن
    - شرح أوضاع /queue أو سلوك توجيه الرسائل
summary: أوضاع قائمة انتظار الرد التلقائي، والقيم الافتراضية، والتجاوزات لكل جلسة
title: قائمة انتظار الأوامر
x-i18n:
    generated_at: "2026-05-02T07:25:26Z"
    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`.
- عند تفعيل التسجيل المفصل، تصدر العمليات المصطفة إشعارا قصيرا إذا انتظرت أكثر من ~2s قبل أن تبدأ.
- تظل مؤشرات الكتابة تعمل فور الإدراج في الطابور (عندما تدعمها القناة) بحيث لا تتغير تجربة المستخدم أثناء انتظار الدور.

## الإعدادات الافتراضية

عند عدم ضبطها، تستخدم كل أسطح القنوات الواردة:

- `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` إذا كنت تريد
استجابة واحدة لكل رسالة واردة.

للاطلاع على توقيت وقت التشغيل المحدد وسلوك الاعتماديات، راجع
[طابور التوجيه](/ar/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`: نافذة الهدوء قبل تفريغ المتابعات المصطفة. الأرقام المجردة بالمللي ثانية؛ تقبل خيارات `/queue` الوحدات `ms` و`s` و`m` و`h` و`d`.
- `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` المضمنة أو المخزنة على الإعدادات. ثم
يطبق تأخير القناة المحدد (`messages.queue.debounceMsByChannel`)، وافتراضيات
تأخير Plugin، وخيارات `messages.queue` العامة، والافتراضيات المدمجة.
`cap` و`drop` خياران عامان/خاصان بالجلسة، وليسا مفاتيح إعداد لكل قناة.

## تجاوزات كل جلسة

- أرسل `/queue <mode>` كأمر مستقل لتخزين الوضع للجلسة الحالية.
- يمكن دمج الخيارات: `/queue collect debounce:0.5s cap:25 drop:summarize`
- يمسح `/queue default` أو `/queue reset` تجاوز الجلسة.

## النطاق والضمانات

- ينطبق على عمليات وكيل الرد التلقائي عبر كل القنوات الواردة التي تستخدم مسار ردود Gateway (WhatsApp web وTelegram وSlack وDiscord وSignal وiMessage ودردشة الويب، إلخ).
- المسار الافتراضي (`main`) على مستوى العملية للوارد + Heartbeat الرئيسية؛ اضبط `agents.defaults.maxConcurrent` للسماح بعدة جلسات بالتوازي.
- قد توجد مسارات إضافية (مثل `cron` و`cron-nested` و`nested` و`subagent`) حتى تتمكن مهام الخلفية من العمل بالتوازي من دون حظر الردود الواردة. تحتفظ دورات وكيل Cron المعزولة بفتحة `cron` بينما يستخدم تنفيذ الوكيل الداخلي `cron-nested`؛ ويستخدم كلاهما `cron.maxConcurrentRuns`. تحافظ تدفقات `nested` المشتركة غير Cron على سلوك مسارها الخاص. تتبع هذه العمليات المنفصلة بوصفها [مهام خلفية](/ar/automation/tasks).
- تضمن مسارات كل جلسة أن عملية وكيل واحدة فقط تلمس جلسة معينة في كل مرة.
- لا توجد اعتماديات خارجية أو خيوط عامل في الخلفية؛ TypeScript + وعود فقط.

## استكشاف الأخطاء وإصلاحها

- إذا بدت الأوامر عالقة، فعّل السجلات المفصلة وابحث عن أسطر “queued for …ms” لتأكيد أن الطابور يفرغ.
- إذا كنت تحتاج إلى عمق الطابور، فعّل السجلات المفصلة وراقب أسطر توقيت الطابور.
- يقاطع محول Codex عمليات خادم تطبيق Codex التي تقبل دورة ثم تتوقف عن إصدار التقدم، بحيث يمكن لمسار الجلسة النشطة أن يتحرر بدلا من انتظار مهلة العملية الخارجية.
- عند تفعيل التشخيصات، تصنف الجلسات التي تبقى في `processing` بعد `diagnostics.stuckSessionWarnMs` من دون أي رد أو أداة أو حالة أو كتلة أو تقدم ACP مرصود حسب النشاط الحالي. يسجل العمل النشط باسم `session.long_running`؛ ويسجل العمل النشط من دون تقدم حديث باسم `session.stalled`؛ ويخصص `session.stuck` لمسك دفاتر الجلسات القديمة من دون عمل نشط، وهذا المسار وحده يستطيع تحرير مسار الجلسة المتأثرة حتى تفرغ الأعمال المصطفة. تتراجع تشخيصات `session.stuck` المتكررة ما دامت الجلسة من دون تغيير.

## ذو صلة

- [إدارة الجلسات](/ar/concepts/session)
- [طابور التوجيه](/ar/concepts/queue-steering)
- [سياسة إعادة المحاولة](/ar/concepts/retry)
