Messages and delivery
Черга керування
Коли звичайний запит надходить під час уже потокового виконання сеансу, OpenClaw
за замовчуванням намагається надіслати цей запит в активне середовище виконання,
коли режим черги — steer. Для цієї типової поведінки не потрібні ні запис
конфігурації, ні директива черги. OpenClaw і нативний серверний harness Codex
реалізують деталі доставки по-різному.
Межа середовища виконання
Керування не перериває виклик інструмента, який уже виконується. OpenClaw перевіряє наявність повідомлень керування в черзі на межах моделі:
- Асистент запитує виклики інструментів.
- OpenClaw виконує пакет викликів інструментів поточного повідомлення асистента.
- OpenClaw надсилає подію завершення ходу.
- OpenClaw вивантажує повідомлення керування з черги.
- OpenClaw додає ці повідомлення як повідомлення користувача перед наступним викликом LLM.
Це зберігає результати інструментів у парі з повідомленням асистента, яке їх запитало, а потім дає наступному виклику моделі змогу побачити найновіші вхідні дані користувача.
Нативний серверний harness Codex надає turn/steer замість внутрішньої черги
керування середовища виконання OpenClaw. OpenClaw групує запити з черги протягом
налаштованого тихого вікна, а потім надсилає один запит turn/steer з усіма
зібраними вхідними даними користувача в порядку надходження.
Ходи ревʼю Codex і ручної Compaction відхиляють керування в межах того самого
ходу. Коли середовище виконання не може прийняти керування в режимі steer,
OpenClaw чекає завершення активного виконання, перш ніж запускати запит.
Ця сторінка пояснює керування режимом черги для звичайних вхідних повідомлень,
коли режим — steer. Якщо режим — followup або collect, звичайні повідомлення
не потрапляють у цей шлях керування; вони чекають, доки активне виконання
завершиться. Про явну команду /steer <message> див. Керування.
Режими
| Режим | Поведінка під час активного виконання | Подальша поведінка |
|---|---|---|
steer |
Спрямовує запит в активне середовище виконання, коли може. | Чекає завершення активного виконання, якщо керування недоступне. |
followup |
Не керує. | Пізніше виконує повідомлення з черги після завершення активного виконання. |
collect |
Не керує. | Обʼєднує сумісні повідомлення з черги в один пізніший хід після вікна debounce. |
interrupt |
Перериває активне виконання замість керування ним. | Запускає найновіше повідомлення після переривання. |
Приклад сплеску
Якщо четверо користувачів надсилають повідомлення, поки агент виконує виклик інструмента:
- За типової поведінки активне середовище виконання отримує всі чотири
повідомлення в порядку надходження перед своїм наступним рішенням моделі.
OpenClaw вивантажує їх на наступній межі моделі; Codex отримує їх як один
згрупований
turn/steer. - З
/queue collectOpenClaw не виконує керування. Він чекає, доки активне виконання завершиться, а потім створює наступний хід із сумісними повідомленнями з черги після вікна debounce. - З
/queue interruptOpenClaw перериває активне виконання й запускає найновіше повідомлення замість керування.
Область дії
Керування завжди націлене на поточне активне виконання сеансу. Воно не створює новий сеанс, не змінює політику інструментів активного виконання й не розділяє повідомлення за відправником. У багатокористувацьких каналах вхідні запити вже містять контекст відправника та маршруту, тому наступний виклик моделі може побачити, хто надіслав кожне повідомлення.
Використовуйте followup або collect, коли хочете, щоб повідомлення за
замовчуванням ставали в чергу замість керування активним виконанням.
Використовуйте interrupt, коли найновіший запит має замінити активне виконання.
Debounce
messages.queue.debounceMs застосовується до доставки поставлених у чергу
followup і collect. У режимі steer з нативним harness Codex він також
задає тихе вікно перед надсиланням згрупованого turn/steer. Для OpenClaw саме
активне керування не використовує таймер debounce, бо OpenClaw природно групує
повідомлення до наступної межі моделі.
