---
read_when:
    - توضیح رفتار هدایت هنگام استفادهٔ یک عامل از ابزارها
    - تغییر رفتار صف اجرای فعال یا یکپارچه‌سازی هدایت زمان اجرا
    - مقایسه حالت‌های هدایت، صف، جمع‌آوری و پیگیری
summary: نحوهٔ صف‌بندی پیام‌ها توسط هدایت اجرای فعال در مرزهای زمان اجرا
title: صف راهبری
x-i18n:
    generated_at: "2026-05-04T02:24:13Z"
    model: gpt-5.5
    provider: openai
    source_hash: c8df35b127ae0c1e1b3b684a1f63ce33874eb3d0b7bf9d0df7cb9dfce093090a
    source_path: concepts/queue-steering.md
    workflow: 16
---

وقتی پیامی در حالی می‌رسد که اجرای یک نشست از قبل در حال stream شدن است، OpenClaw می‌تواند
آن پیام را به محیط اجرای فعال بفرستد، به‌جای اینکه برای همان نشست اجرای دیگری
شروع کند. حالت‌های عمومی مستقل از محیط اجرا هستند؛ Pi و چارچوب app-server بومی Codex
جزئیات تحویل را متفاوت پیاده‌سازی می‌کنند.

## مرز محیط اجرا

هدایت، فراخوانی ابزاری را که از قبل در حال اجرا است قطع نمی‌کند. Pi در مرزهای مدل
پیام‌های هدایت صف‌شده را بررسی می‌کند:

1. دستیار درخواست فراخوانی ابزار می‌دهد.
2. Pi دسته فراخوانی ابزار پیام فعلی دستیار را اجرا می‌کند.
3. Pi رویداد پایان نوبت را منتشر می‌کند.
4. Pi پیام‌های هدایت صف‌شده را تخلیه می‌کند.
5. Pi پیش از فراخوانی بعدی LLM، آن پیام‌ها را به‌عنوان پیام‌های کاربر اضافه می‌کند.

این کار نتایج ابزار را با پیام دستیاری که آن‌ها را درخواست کرده است جفت نگه می‌دارد،
سپس اجازه می‌دهد فراخوانی بعدی مدل آخرین ورودی کاربر را ببیند.

چارچوب app-server بومی Codex به‌جای صف هدایت داخلی Pi، `turn/steer` را در اختیار می‌گذارد.
OpenClaw همان حالت‌ها را در آنجا تطبیق می‌دهد:

- `steer` پیام‌های صف‌شده را برای پنجره سکوت پیکربندی‌شده دسته‌بندی می‌کند، سپس یک
  درخواست واحد `turn/steer` را با همه ورودی‌های کاربر گردآوری‌شده به ترتیب ورود می‌فرستد.
- `queue` با ارسال درخواست‌های جداگانه `turn/steer` شکل سریالی‌سازی‌شده قدیمی را حفظ می‌کند.
- `followup`، `collect`، `steer-backlog`، و `interrupt` رفتار صف تحت مالکیت OpenClaw
  در پیرامون نوبت فعال Codex باقی می‌مانند.

نوبت‌های بازبینی Codex و Compaction دستی، هدایت در همان نوبت را رد می‌کنند. وقتی یک
محیط اجرا نمی‌تواند هدایت را بپذیرد، OpenClaw در مواردی که آن حالت اجازه می‌دهد،
به صف followup برمی‌گردد.

این صفحه هدایت در حالت صف را برای پیام‌های ورودی عادی توضیح می‌دهد. برای فرمان
صریح `/steer <message>`، [هدایت](/fa/tools/steer) را ببینید.

## حالت‌ها

| حالت            | رفتار اجرای فعال                                                                                                          | رفتار followup بعدی                                                             |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `steer`         | همه پیام‌های هدایت صف‌شده را با هم در مرز بعدی محیط اجرا تزریق می‌کند. این حالت پیش‌فرض است.                             | فقط وقتی هدایت در دسترس نباشد به followup برمی‌گردد.                           |
| `queue`         | هدایت قدیمی تک‌به‌تک. Pi در هر مرز مدل یک پیام صف‌شده را تزریق می‌کند؛ Codex درخواست‌های جداگانه `turn/steer` می‌فرستد. | فقط وقتی هدایت در دسترس نباشد به followup برمی‌گردد.                           |
| `steer-backlog` | همان رفتار هدایت در اجرای فعال مانند `steer`.                                                                                | همان پیام را برای یک نوبت followup بعدی نیز نگه می‌دارد.                              |
| `followup`      | اجرای فعلی را هدایت نمی‌کند.                                                                                              | پیام‌های صف‌شده را بعدا اجرا می‌کند.                                                         |
| `collect`       | اجرای فعلی را هدایت نمی‌کند.                                                                                              | پیام‌های صف‌شده سازگار را پس از پنجره debounce در یک نوبت بعدی ادغام می‌کند. |
| `interrupt`     | اجرای فعال را لغو می‌کند، سپس جدیدترین پیام را شروع می‌کند.                                                                       | هیچ‌کدام.                                                                               |

## نمونه burst

اگر چهار کاربر در حالی پیام بفرستند که عامل در حال اجرای یک فراخوانی ابزار است:

- `steer`: محیط اجرای فعال هر چهار پیام را به ترتیب ورود پیش از تصمیم بعدی مدل
  دریافت می‌کند. Pi آن‌ها را در مرز بعدی مدل تخلیه می‌کند؛ Codex آن‌ها را به‌صورت یک `turn/steer` دسته‌بندی‌شده
  دریافت می‌کند.
- `queue`: هدایت سریالی‌سازی‌شده قدیمی. Pi هر بار یک پیام صف‌شده را تزریق می‌کند؛
  Codex درخواست‌های جداگانه `turn/steer` دریافت می‌کند.
- `collect`: OpenClaw تا پایان اجرای فعال صبر می‌کند، سپس پس از پنجره debounce
  یک نوبت followup با پیام‌های صف‌شده سازگار ایجاد می‌کند.

## دامنه

هدایت همیشه اجرای نشست فعال فعلی را هدف می‌گیرد. نشست جدیدی ایجاد نمی‌کند،
سیاست ابزار اجرای فعال را تغییر نمی‌دهد، یا پیام‌ها را بر اساس فرستنده جدا نمی‌کند. در
کانال‌های چندکاربره، promptهای ورودی از قبل زمینه فرستنده و مسیر را شامل می‌شوند، بنابراین
فراخوانی بعدی مدل می‌تواند ببیند هر پیام را چه کسی فرستاده است.

وقتی می‌خواهید OpenClaw یک نوبت followup بعدی بسازد که بتواند
پیام‌های سازگار را ادغام کند و سیاست حذف صف followup را حفظ کند، از `collect` استفاده کنید. فقط وقتی
به رفتار هدایت تک‌به‌تک قدیمی‌تر نیاز دارید از `queue` استفاده کنید.

## Debounce

`messages.queue.debounceMs` برای تحویل followup اعمال می‌شود، از جمله `collect`،
`followup`، `steer-backlog`، و fallback مربوط به `steer` وقتی هدایت اجرای فعال
در دسترس نیست. برای Pi، خود `steer` فعال از تایمر debounce استفاده نمی‌کند، چون
Pi به‌طور طبیعی پیام‌ها را تا مرز بعدی مدل دسته‌بندی می‌کند. برای چارچوب بومی
Codex، OpenClaw پیش از ارسال `turn/steer` دسته‌بندی‌شده از همان مقدار debounce
به‌عنوان پنجره سکوت استفاده می‌کند.

## مرتبط

- [صف فرمان](/fa/concepts/queue)
- [هدایت](/fa/tools/steer)
- [پیام‌ها](/fa/concepts/messages)
- [حلقه عامل](/fa/concepts/agent-loop)