---
read_when:
    - تغيير تنفيذ الرد التلقائي أو التزامن
    - شرح أوضاع /queue أو سلوك توجيه الرسائل
summary: أوضاع قائمة انتظار الردّ التلقائي، والقيم الافتراضية، والتجاوزات لكل جلسة
title: قائمة انتظار الأوامر
x-i18n:
    generated_at: "2026-06-27T17:32:22Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 6e518b018a85ddbc7afa3925180cc2329eb1d249316d81907ba51cfb3c692375
    source_path: concepts/queue.md
    workflow: 16
---

نُسلسل عمليات الرد التلقائي الواردة (كل القنوات) عبر طابور صغير داخل العملية لمنع تصادم عدة عمليات تشغيل للوكيل، مع استمرار السماح بالتوازي الآمن عبر الجلسات.

## لماذا

- قد تكون عمليات الرد التلقائي مكلفة (استدعاءات LLM) وقد تتصادم عند وصول عدة رسائل واردة في وقت متقارب.
- يمنع التسلسل التنافس على الموارد المشتركة (ملفات الجلسات، السجلات، إدخال CLI القياسي) ويقلل احتمال الوصول إلى حدود المعدل لدى الجهات العليا.

## آلية العمل

- طابور FIFO واعٍ بالمسارات يفرغ كل مسار بحد تزامن قابل للضبط (الافتراضي 1 للمسارات غير المضبوطة؛ الافتراضي لـ main هو 4، ولـ subagent هو 8).
- يضيف `runEmbeddedAgent` إلى الطابور حسب **مفتاح الجلسة** (المسار `session:<key>`) لضمان وجود عملية تشغيل نشطة واحدة فقط لكل جلسة.
- تُضاف كل عملية تشغيل جلسة بعد ذلك إلى **مسار عام** (`main` افتراضياً) بحيث يكون التوازي الإجمالي محدوداً بواسطة `agents.defaults.maxConcurrent`.
- عند تفعيل التسجيل التفصيلي، تصدر عمليات التشغيل الموضوعة في الطابور إشعاراً قصيراً إذا انتظرت أكثر من نحو ثانيتين قبل البدء.
- ما زالت مؤشرات الكتابة تعمل فوراً عند الإضافة إلى الطابور (عندما تدعمها القناة)، لذلك لا تتغير تجربة المستخدم أثناء انتظار دورنا.

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

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

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

التوجيه في الدور نفسه هو الافتراضي. تُحقن المطالبة التي تصل أثناء تشغيل جارٍ
داخل وقت التشغيل النشط عندما يستطيع التشغيل قبول التوجيه، لذلك لا تبدأ عملية تشغيل
جلسة ثانية. إذا لم يستطع التشغيل النشط قبول التوجيه، ينتظر OpenClaw انتهاء
التشغيل النشط قبل بدء المطالبة.

## أوضاع الطابور

يتحكم `/queue` بما تفعله الرسائل الواردة العادية عندما تكون للجلسة عملية تشغيل
نشطة بالفعل:

- `steer`: يحقن الرسائل في وقت التشغيل النشط. يسلّم OpenClaw كل رسائل التوجيه المعلقة **بعد انتهاء دور المساعد الحالي من تنفيذ استدعاءات أدواته**، وقبل استدعاء LLM التالي؛ يتلقى خادم تطبيق Codex دفعة واحدة من `turn/steer`. إذا لم يكن التشغيل يبث بنشاط أو لم يكن التوجيه متاحاً، ينتظر OpenClaw حتى ينتهي التشغيل النشط قبل بدء المطالبة.
- `followup`: لا يوجّه. يضيف كل رسالة إلى الطابور لدور وكيل لاحق بعد انتهاء التشغيل الحالي.
- `collect`: لا يوجّه. يدمج الرسائل الموضوعة في الطابور في دور متابعة **واحد** بعد نافذة الهدوء. إذا استهدفت الرسائل قنوات/سلاسل مختلفة، تُفرغ كل رسالة على حدة للحفاظ على التوجيه.
- `interrupt`: يجهض التشغيل النشط لتلك الجلسة، ثم يشغل أحدث رسالة.

لسلوك التوقيت والتبعيات الخاص بوقت التشغيل، راجع
[طابور التوجيه](/ar/concepts/queue-steering). للأمر الصريح `/steer <message>`،
راجع [توجيه](/ar/tools/steer).

اضبطه عاماً أو لكل قناة عبر `messages.queue`:

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

## خيارات الطابور

تنطبق الخيارات على التسليم الموضوع في الطابور. يضبط `debounceMs` أيضاً نافذة الهدوء
لتوجيه Codex في وضع `steer`:

- `debounceMs`: نافذة الهدوء قبل تفريغ المتابعات الموضوعة في الطابور أو دفعات الجمع؛ في وضع `steer` الخاص بـ Codex، نافذة الهدوء قبل إرسال دفعة `turn/steer`. الأرقام المجردة تُعد بالمللي ثانية؛ وتقبل خيارات `/queue` الوحدات `ms` و`s` و`m` و`h` و`d`.
- `cap`: الحد الأقصى للرسائل الموضوعة في الطابور لكل جلسة. تُتجاهل القيم الأقل من `1`.
- `drop: "summarize"`: الافتراضي. يسقط أقدم الإدخالات الموضوعة في الطابور حسب الحاجة، ويحافظ على ملخصات مضغوطة، ويحقنها كمطالبة متابعة اصطناعية.
- `drop: "old"`: يسقط أقدم الإدخالات الموضوعة في الطابور حسب الحاجة، من دون الحفاظ على ملخصات.
- `drop: "new"`: يرفض أحدث رسالة عندما يكون الطابور ممتلئاً بالفعل.

الإعدادات الافتراضية: `debounceMs: 500`، و`cap: 20`، و`drop: summarize`.

## التوجيه والبث

عندما يكون بث القناة `partial` أو `block`، قد يبدو التوجيه كعدة ردود مرئية
قصيرة بينما يصل التشغيل النشط إلى حدود وقت التشغيل:

- `partial`: قد تُنهى المعاينة مبكراً، ثم تبدأ معاينة جديدة بعد
  قبول التوجيه.
- `block`: يمكن للكتل بحجم المسودة إنشاء المظهر التسلسلي نفسه.
- من دون بث، يعود التوجيه إلى متابعة بعد التشغيل النشط عندما
  لا يستطيع وقت التشغيل قبول التوجيه في الدور نفسه.

لا يجهض `steer` الأدوات الجارية. استخدم `/queue interrupt` عندما ينبغي أن
تجهض أحدث رسالة التشغيل الحالي.

## الأولوية

لاختيار الوضع، يحل OpenClaw:

1. تجاوز `/queue` المضمن أو المخزن لكل جلسة.
2. `messages.queue.byChannel.<channel>`.
3. `messages.queue.mode`.
4. `steer` الافتراضي.

بالنسبة إلى الخيارات، تتغلب خيارات `/queue` المضمنة أو المخزنة على الإعدادات. ثم
تُطبّق مهلة القناة المحددة (`messages.queue.debounceMsByChannel`)، وإعدادات
مهلة Plugin الافتراضية، وخيارات `messages.queue` العامة، والإعدادات الافتراضية
المضمنة. يُعد `cap` و`drop` خيارين عامين/خاصين بالجلسة، وليسا مفاتيح إعداد
خاصة بكل قناة.

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

- أرسل `/queue <steer|followup|collect|interrupt>` كأمر مستقل لتخزين وضع الطابور للجلسة الحالية.
- يمكن دمج الخيارات: `/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 على سلوك المسار الخاص بها. تُتبع عمليات التشغيل المنفصلة هذه كـ [مهام خلفية](/ar/automation/tasks).
- تضمن مسارات كل جلسة أن عملية تشغيل وكيل واحدة فقط تلمس جلسة معينة في كل مرة.
- لا توجد تبعيات خارجية أو خيوط عامل خلفية؛ TypeScript خالص + وعود.

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

- إذا بدت الأوامر عالقة، فعّل السجلات التفصيلية وابحث عن أسطر "queued for ...ms" لتأكيد أن الطابور يُفرغ.
- إذا كنت تحتاج إلى عمق الطابور، فعّل السجلات التفصيلية وراقب أسطر توقيت الطابور.
- عمليات تشغيل خادم تطبيق Codex التي تقبل دوراً ثم تتوقف عن إصدار تقدم تُقاطع بواسطة محول Codex لكي يتحرر مسار الجلسة النشط بدلاً من انتظار انتهاء مهلة التشغيل الخارجية.
- عند تفعيل التشخيصات، تُصنف الجلسات التي تبقى في `processing` بعد `diagnostics.stuckSessionWarnMs` من دون أي رد أو أداة أو حالة أو كتلة أو تقدم ACP مرصود حسب النشاط الحالي. يُسجل العمل النشط كـ `session.long_running`؛ كما تبقى استدعاءات النموذج الصامتة المملوكة `session.long_running` حتى `diagnostics.stuckSessionAbortMs` كي لا يُبلّغ عن الموفرين البطيئين أو غير الباثين كمتوقفين مبكراً جداً. يُسجل العمل النشط الذي لا يملك تقدماً حديثاً كـ `session.stalled`؛ وتتحول استدعاءات النموذج المملوكة إلى `session.stalled` عند عتبة الإجهاض أو بعدها، ولا يُخفى نشاط النموذج/الأداة القديم غير المملوك باعتباره طويل التشغيل. يُحجز `session.stuck` لحفظ سجلات الجلسات القديمة القابلة للاسترداد، بما في ذلك الجلسات الخاملة الموضوعة في الطابور ذات نشاط نموذج/أداة قديم غير مملوك، وهذا المسار وحده يمكنه تحرير مسار الجلسة المتأثر لكي يُفرغ العمل الموضوع في الطابور. تتراجع تشخيصات `session.stuck` المتكررة بينما تبقى الجلسة دون تغيير.

## ذو صلة

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