Messages and delivery
صف راهبری
وقتی پیامی در حالی میرسد که اجرای یک نشست از قبل در حال stream شدن است، OpenClaw میتواند آن پیام را به محیط اجرای فعال بفرستد، بهجای اینکه برای همان نشست اجرای دیگری شروع کند. حالتهای عمومی مستقل از محیط اجرا هستند؛ Pi و چارچوب app-server بومی Codex جزئیات تحویل را متفاوت پیادهسازی میکنند.
مرز محیط اجرا
هدایت، فراخوانی ابزاری را که از قبل در حال اجرا است قطع نمیکند. Pi در مرزهای مدل پیامهای هدایت صفشده را بررسی میکند:
- دستیار درخواست فراخوانی ابزار میدهد.
- Pi دسته فراخوانی ابزار پیام فعلی دستیار را اجرا میکند.
- Pi رویداد پایان نوبت را منتشر میکند.
- Pi پیامهای هدایت صفشده را تخلیه میکند.
- 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>، هدایت را ببینید.
حالتها
| حالت | رفتار اجرای فعال | رفتار 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
بهعنوان پنجره سکوت استفاده میکند.