---
read_when:
    - تغيير تنفيذ الرد التلقائي أو التزامن
summary: تصميم طابور الأوامر الذي يسللسل عمليات التشغيل الواردة للرد التلقائي
title: طابور الأوامر
x-i18n:
    generated_at: "2026-04-25T13:45:36Z"
    model: gpt-5.4
    provider: openai
    source_hash: 0c027be3e9a67f91a49c5d4d69fa8191d3e7651265a152c4723b10062b339f2a
    source_path: concepts/queue.md
    workflow: 15
---

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

## لماذا

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

## كيف يعمل

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

## أوضاع الطابور (لكل قناة)

يمكن للرسائل الواردة أن توجّه التشغيل الحالي، أو تنتظر دور متابعة، أو تفعل الأمرين معًا:

- `steer`: يحقن فورًا في التشغيل الحالي (ويلغي استدعاءات الأدوات المعلقة بعد حد الأداة التالي). وإذا لم يكن هناك بث، فإنه يرجع إلى المتابعة.
- `followup`: يُدرج في الطابور لدور الوكيل التالي بعد انتهاء التشغيل الحالي.
- `collect`: يدمج جميع الرسائل الموجودة في الطابور في **دور متابعة واحد** (الافتراضي). وإذا استهدفت الرسائل قنوات/سلاسل رسائل مختلفة، يتم تصريفها بشكل منفصل للحفاظ على التوجيه.
- `steer-backlog` (ويُعرف أيضًا باسم `steer+backlog`): يوجّه الآن **ويحتفظ أيضًا** بالرسالة لدور متابعة.
- `interrupt` (قديم): يجهض التشغيل النشط لتلك الجلسة، ثم يشغّل أحدث رسالة.
- `queue` (اسم مستعار قديم): مثل `steer`.

يعني `steer-backlog` أنه قد تحصل على استجابة متابعة بعد التشغيل الموجَّه، لذلك
قد تبدو الأسطح المتدفقة وكأنها مكررة. فضّل `collect`/`steer` إذا كنت تريد
استجابة واحدة لكل رسالة واردة.
أرسل `/queue collect` كأمر مستقل (لكل جلسة) أو عيّن `messages.queue.byChannel.discord: "collect"`.

الإعدادات الافتراضية (عند عدم تعيينها في الإعدادات):

- جميع الأسطح → `collect`

هيّئه عالميًا أو لكل قناة عبر `messages.queue`:

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

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

تنطبق الخيارات على `followup` و`collect` و`steer-backlog` (وكذلك على `steer` عندما يرجع إلى المتابعة):

- `debounceMs`: الانتظار حتى يهدأ الإدخال قبل بدء دور متابعة (يمنع “continue, continue”).
- `cap`: الحد الأقصى للرسائل الموجودة في الطابور لكل جلسة.
- `drop`: سياسة الفائض (`old` أو `new` أو `summarize`).

يبقي `summarize` قائمة نقطية قصيرة بالرسائل التي تم إسقاطها ويحقنها كموجّه متابعة اصطناعي.
الإعدادات الافتراضية: `debounceMs: 1000` و`cap: 20` و`drop: summarize`.

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

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

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

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

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

- إذا بدت الأوامر عالقة، ففعّل السجلات المفصلة وابحث عن أسطر “queued for …ms” للتأكد من أن الطابور يتم تصريفه.
- إذا كنت تحتاج إلى عمق الطابور، ففعّل السجلات المفصلة وراقب أسطر توقيت الطابور.

## ذو صلة

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