Messages and delivery
صف هدایت
وقتی یک پیام عادی در حالی میرسد که اجرای یک نشست از پیش در حال پخش جریانی است، OpenClaw
بهطور پیشفرض تلاش میکند آن پیام را زمانی که حالت صف
steer است، به محیط اجرای فعال بفرستد. برای این رفتار پیشفرض،
نه ورودی پیکربندی لازم است و نه دستور صف. OpenClaw و هارنس app-server بومی Codex جزئیات تحویل را
بهصورت متفاوت پیادهسازی میکنند.
مرز محیط اجرا
هدایت، فراخوانی ابزاری را که از پیش در حال اجراست قطع نمیکند. OpenClaw پیامهای هدایتِ صفشده را در مرزهای مدل بررسی میکند:
- دستیار درخواست فراخوانی ابزار میدهد.
- OpenClaw دسته فراخوانی ابزارِ پیام فعلی دستیار را اجرا میکند.
- OpenClaw رویداد پایان نوبت را منتشر میکند.
- OpenClaw پیامهای هدایتِ صفشده را تخلیه میکند.
- OpenClaw آن پیامها را پیش از فراخوانی بعدی LLM بهعنوان پیامهای کاربر اضافه میکند.
این کار نتایج ابزار را با پیام دستیاری که آنها را درخواست کرده جفت نگه میدارد، سپس اجازه میدهد فراخوانی بعدی مدل آخرین ورودی کاربر را ببیند.
هارنس app-server بومی Codex بهجای صف هدایت داخلی محیط اجرای OpenClaw،
turn/steer را ارائه میکند. OpenClaw پیامهای صفشده را برای پنجره سکوتِ
پیکربندیشده دستهبندی میکند، سپس یک درخواست turn/steer واحد را با تمام ورودیهای
گردآوریشده کاربر به ترتیب ورود میفرستد.
نوبتهای بازبینی Codex و Compaction دستی، هدایت در همان نوبت را رد میکنند. وقتی یک
محیط اجرا نتواند هدایت را در حالت steer بپذیرد، OpenClaw پیش از شروع
پیام، منتظر میماند اجرای فعال تمام شود.
این صفحه هدایتِ حالت صف را برای پیامهای ورودی عادی زمانی توضیح میدهد که حالت
steer است. اگر حالت followup یا collect باشد، پیامهای عادی وارد
این مسیر هدایت نمیشوند؛ آنها تا پایان اجرای فعال منتظر میمانند. برای فرمان صریح
/steer <message>، هدایت را ببینید.
حالتها
| حالت | رفتار اجرای فعال | رفتار بعدی |
|---|---|---|
steer |
هر زمان بتواند، پیام را به محیط اجرای فعال هدایت میکند. | اگر هدایت در دسترس نباشد، منتظر میماند اجرای فعال تمام شود. |
followup |
هدایت نمیکند. | پیامهای صفشده را بعدا پس از پایان اجرای فعال اجرا میکند. |
collect |
هدایت نمیکند. | پیامهای صفشده سازگار را پس از پنجره debounce در یک نوبت بعدی ادغام میکند. |
interrupt |
بهجای هدایت اجرای فعال، آن را لغو میکند. | پس از لغو، جدیدترین پیام را شروع میکند. |
نمونه انفجار پیام
اگر چهار کاربر هنگام اجرای یک فراخوانی ابزار توسط عامل پیام بفرستند:
- با رفتار پیشفرض، محیط اجرای فعال هر چهار پیام را به ترتیب ورود
پیش از تصمیم بعدی مدل دریافت میکند. OpenClaw آنها را در مرز بعدی مدل
تخلیه میکند؛ Codex آنها را بهصورت یک
turn/steerدستهبندیشده دریافت میکند. - با
/queue collect، OpenClaw هدایت نمیکند. منتظر میماند اجرای فعال پایان یابد، سپس پس از پنجره debounce یک نوبت پیگیری با پیامهای صفشده سازگار ایجاد میکند. - با
/queue interrupt، OpenClaw اجرای فعال را لغو میکند و بهجای هدایت، جدیدترین پیام را شروع میکند.
دامنه
هدایت همیشه اجرای نشست فعال فعلی را هدف میگیرد. نشست جدیدی ایجاد نمیکند، سیاست ابزار اجرای فعال را تغییر نمیدهد، یا پیامها را بر اساس فرستنده جدا نمیکند. در کانالهای چندکاربره، پیامهای ورودی از قبل شامل زمینه فرستنده و مسیر هستند، بنابراین فراخوانی بعدی مدل میتواند ببیند هر پیام را چه کسی فرستاده است.
وقتی میخواهید پیامها بهطور پیشفرض بهجای هدایت اجرای فعال در صف قرار بگیرند،
از followup یا collect استفاده کنید. وقتی جدیدترین پیام باید جایگزین
اجرای فعال شود، از interrupt استفاده کنید.
Debounce
messages.queue.debounceMs برای تحویل followup و collect صفشده اعمال میشود.
در حالت steer با هارنس بومی Codex، همچنین پنجره سکوت را پیش از
ارسال turn/steer دستهبندیشده تنظیم میکند. برای OpenClaw، خود هدایت فعال از
تایمر debounce استفاده نمیکند، چون OpenClaw بهطور طبیعی پیامها را تا مرز بعدی مدل
دستهبندی میکند.
