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