--- read_when: - Пояснення того, як steer поводиться, поки агент використовує інструменти - Зміна поведінки черги активних запусків або інтеграції керування під час виконання - Порівняння режимів steer, queue, collect і followup summary: Як керування активним виконанням ставить повідомлення в чергу на межах середовища виконання title: Черга керування x-i18n: generated_at: "2026-05-03T22:25:48Z" model: gpt-5.5 provider: openai source_hash: c8df35b127ae0c1e1b3b684a1f63ce33874eb3d0b7bf9d0df7cb9dfce093090a source_path: concepts/queue-steering.md workflow: 16 --- Коли повідомлення надходить під час потокового виконання запуску сеансу, OpenClaw може надіслати це повідомлення в активне середовище виконання замість запуску ще одного виконання для того самого сеансу. Публічні режими не залежать від середовища виконання; Pi і нативна обв’язка app-server Codex реалізують деталі доставки по-різному. ## Межа середовища виконання Керування не перериває виклик інструмента, який уже виконується. Pi перевіряє поставлені в чергу повідомлення керування на межах моделі: 1. Асистент запитує виклики інструментів. 2. Pi виконує пакет викликів інструментів поточного повідомлення асистента. 3. Pi надсилає подію завершення ходу. 4. Pi обробляє поставлені в чергу повідомлення керування. 5. Pi додає ці повідомлення як повідомлення користувача перед наступним викликом LLM. Це зберігає результати інструментів пов’язаними з повідомленням асистента, яке їх запитало, а потім дає наступному виклику моделі побачити найновіші введені дані користувача. Нативна обв’язка app-server Codex надає `turn/steer` замість внутрішньої черги керування Pi. OpenClaw адаптує ті самі режими там: - `steer` групує поставлені в чергу повідомлення протягом налаштованого тихого вікна, а потім надсилає один запит `turn/steer` з усіма зібраними введеними даними користувача в порядку надходження. - `queue` зберігає застарілу серіалізовану форму, надсилаючи окремі запити `turn/steer`. - `followup`, `collect`, `steer-backlog` і `interrupt` залишаються поведінкою черги, якою володіє OpenClaw навколо активного ходу Codex. Ходи рецензування Codex і ручної Compaction відхиляють керування в межах того самого ходу. Коли середовище виконання не може прийняти керування, OpenClaw повертається до черги подальших дій там, де цей режим це дозволяє. Ця сторінка пояснює керування в режимі черги для звичайних вхідних повідомлень. Для явної команди `/steer ` див. [Керування](/uk/tools/steer). ## Режими | Режим | Поведінка активного запуску | Поведінка подальших дій пізніше | | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | `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. ## Область дії Керування завжди націлене на поточний активний запуск сеансу. Воно не створює новий сеанс, не змінює політику інструментів активного запуску й не розділяє повідомлення за відправником. У багатокористувацьких каналах вхідні підказки вже містять контекст відправника й маршруту, тож наступний виклик моделі може бачити, хто надіслав кожне повідомлення. Використовуйте `collect`, коли хочете, щоб OpenClaw побудував пізніший хід подальших дій, який може об’єднувати сумісні повідомлення й зберігати політику відкидання черги подальших дій. Використовуйте `queue` лише тоді, коли вам потрібна старіша поведінка покрокового керування. ## Debounce `messages.queue.debounceMs` застосовується до доставки подальших дій, зокрема `collect`, `followup`, `steer-backlog` і резервного варіанта `steer`, коли керування активним запуском недоступне. Для Pi активний `steer` сам не використовує таймер debounce, тому що Pi природно групує повідомлення до наступної межі моделі. Для нативної обв’язки Codex OpenClaw використовує те саме значення debounce як тихе вікно перед надсиланням пакетного `turn/steer`. ## Пов’язане - [Черга команд](/uk/concepts/queue) - [Керування](/uk/tools/steer) - [Повідомлення](/uk/concepts/messages) - [Цикл агента](/uk/concepts/agent-loop)