---
read_when:
    - شرح كيفية تصرّف التوجيه أثناء استخدام الوكيل للأدوات
    - تغيير سلوك قائمة انتظار التشغيل النشط أو تكامل توجيه وقت التشغيل
    - مقارنة أوضاع steer وqueue وcollect وfollowup
summary: كيفية قيام توجيه التشغيل النشط بوضع الرسائل في قوائم الانتظار عند حدود وقت التشغيل
title: قائمة انتظار التوجيه
x-i18n:
    generated_at: "2026-04-30T07:54:52Z"
    model: gpt-5.5
    provider: openai
    source_hash: 560390c8c26bcce95e0137f4336ad6e62bc3e2344cb15fd12ca3cfe4a85a8acc
    source_path: concepts/queue-steering.md
    workflow: 16
---

عندما تصل رسالة بينما يكون تشغيل الجلسة قيد البث بالفعل، يمكن لـ OpenClaw
إرسال تلك الرسالة إلى وقت التشغيل النشط بدلاً من بدء تشغيل آخر
للجلسة نفسها. الأوضاع العامة محايدة بالنسبة إلى وقت التشغيل؛ يطبّق Pi وحزمة
خادم تطبيق Codex الأصلية تفاصيل التسليم بطرق مختلفة.

## حدود وقت التشغيل

لا يقطع التوجيه استدعاء أداة قيد التشغيل بالفعل. يتحقق Pi من
رسائل التوجيه الموضوعة في الطابور عند حدود النموذج:

1. يطلب المساعد استدعاءات أدوات.
2. ينفذ Pi دفعة استدعاءات الأدوات الخاصة برسالة المساعد الحالية.
3. يصدر Pi حدث نهاية الدور.
4. يفرغ Pi رسائل التوجيه الموضوعة في الطابور.
5. يضيف Pi تلك الرسائل كرسائل مستخدم قبل استدعاء LLM التالي.

يحافظ هذا على اقتران نتائج الأدوات برسالة المساعد التي طلبتها،
ثم يتيح لاستدعاء النموذج التالي رؤية أحدث إدخال من المستخدم.

تعرض حزمة خادم تطبيق Codex الأصلية `turn/steer` بدلاً من
طابور التوجيه الداخلي الخاص بـ Pi. يكيّف OpenClaw الأوضاع نفسها هناك:

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

ترفض أدوار مراجعة Codex والـ Compaction اليدوي التوجيه في الدور نفسه. عندما لا
يستطيع وقت التشغيل قبول التوجيه، يعود OpenClaw إلى طابور المتابعة حيث
يسمح ذلك الوضع بذلك.

## الأوضاع

| الوضع           | سلوك التشغيل النشط                                                                                                          | سلوك المتابعة اللاحقة                                                             |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `steer`         | يحقن كل رسائل التوجيه الموضوعة في الطابور معاً عند حد وقت التشغيل التالي. هذا هو الوضع الافتراضي.                             | يعود إلى المتابعة فقط عندما لا يكون التوجيه متاحاً.                           |
| `queue`         | توجيه قديم رسالةً برسالة. يحقن Pi رسالة واحدة موضوعة في الطابور لكل حد نموذج؛ ويرسل Codex طلبات `turn/steer` منفصلة. | يعود إلى المتابعة فقط عندما لا يكون التوجيه متاحاً.                           |
| `steer-backlog` | سلوك التوجيه نفسه أثناء التشغيل النشط مثل `steer`.                                                                                | يحتفظ أيضاً بالرسالة نفسها لدور متابعة لاحق.                              |
| `followup`      | لا يوجه التشغيل الحالي.                                                                                              | يشغّل الرسائل الموضوعة في الطابور لاحقاً.                                                         |
| `collect`       | لا يوجه التشغيل الحالي.                                                                                              | يدمج الرسائل المتوافقة الموضوعة في الطابور في دور لاحق واحد بعد نافذة إزالة الارتداد. |
| `interrupt`     | يوقف التشغيل النشط، ثم يبدأ أحدث رسالة.                                                                       | لا شيء.                                                                               |

## مثال على الدفعة

إذا أرسل أربعة مستخدمين رسائل بينما يكون الوكيل ينفذ استدعاء أداة:

- `steer`: يتلقى وقت التشغيل النشط الرسائل الأربع كلها بترتيب وصولها قبل
  قرار النموذج التالي. يفرغها Pi عند حد النموذج التالي؛ ويتلقاها Codex
  كطلب `turn/steer` واحد مجمّع.
- `queue`: توجيه متسلسل قديم. يحقن Pi رسالة واحدة موضوعة في الطابور في كل مرة؛
  ويتلقى Codex طلبات `turn/steer` منفصلة.
- `collect`: ينتظر OpenClaw حتى ينتهي التشغيل النشط، ثم ينشئ دور متابعة
  برسائل متوافقة موضوعة في الطابور بعد نافذة إزالة الارتداد.

## النطاق

يستهدف التوجيه دائماً تشغيل الجلسة النشط الحالي. لا ينشئ جلسة جديدة،
ولا يغيّر سياسة أدوات التشغيل النشط، ولا يقسم الرسائل حسب المرسل. في
القنوات متعددة المستخدمين، تتضمن المطالبات الواردة بالفعل سياق المرسل والمسار، لذلك
يمكن لاستدعاء النموذج التالي معرفة من أرسل كل رسالة.

استخدم `collect` عندما تريد أن ينشئ OpenClaw دور متابعة لاحقاً يمكنه
دمج الرسائل المتوافقة والحفاظ على سياسة إسقاط طابور المتابعة. استخدم
`queue` فقط عندما تحتاج إلى سلوك التوجيه الأقدم رسالةً برسالة.

## إزالة الارتداد

ينطبق `messages.queue.debounceMs` على تسليم المتابعات، بما في ذلك `collect`
و`followup` و`steer-backlog` واحتياطي `steer` عندما لا يكون توجيه التشغيل النشط
متاحاً. بالنسبة إلى Pi، لا يستخدم `steer` النشط نفسه مؤقت إزالة الارتداد لأن
Pi يجمع الرسائل طبيعياً حتى حد النموذج التالي. بالنسبة إلى حزمة
Codex الأصلية، يستخدم OpenClaw قيمة إزالة الارتداد نفسها كنافذة هدوء قبل
إرسال `turn/steer` المجمّع.

## ذات صلة

- [طابور الأوامر](/ar/concepts/queue)
- [الرسائل](/ar/concepts/messages)
- [حلقة الوكيل](/ar/concepts/agent-loop)
