---
read_when:
    - توضیح اینکه steer هنگام استفادهٔ یک عامل از ابزارها چگونه رفتار می‌کند
    - تغییر رفتار صف اجرای فعال یا یکپارچه‌سازی هدایت زمان اجرا
    - مقایسهٔ حالت‌های steer، queue، collect و followup
summary: هدایت اجرای فعال چگونه پیام‌ها را در مرزهای زمان اجرا صف می‌کند
title: صف هدایت
x-i18n:
    generated_at: "2026-04-30T09:36:17Z"
    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 به‌جای صف هدایت داخلی Pi، `turn/steer` را ارائه می‌کند. 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`       | اجرای فعلی را هدایت نمی‌کند.                                                                                              | پیام‌های سازگارِ در صف را پس از پنجرهٔ debounce در یک نوبت بعدی ادغام می‌کند. |
| `interrupt`     | اجرای فعال را لغو می‌کند، سپس جدیدترین پیام را شروع می‌کند.                                                                       | هیچ‌کدام.                                                                               |

## نمونهٔ ارسال پشت‌سرهم

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

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

## دامنه

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

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

## Debounce

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

## مرتبط

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