Перейти до основного вмісту
Коли звичайний запит надходить під час уже потокового виконання сеансу, OpenClaw за замовчуванням намагається надіслати цей запит в активне середовище виконання, коли режим черги — steer. Для цієї типової поведінки не потрібні ні запис конфігурації, ні директива черги. OpenClaw і нативний серверний harness Codex реалізують деталі доставки по-різному.

​
Межа середовища виконання

Керування не перериває виклик інструмента, який уже виконується. OpenClaw перевіряє наявність повідомлень керування в черзі на межах моделі:
  1. Асистент запитує виклики інструментів.
  2. OpenClaw виконує пакет викликів інструментів поточного повідомлення асистента.
  3. OpenClaw надсилає подію завершення ходу.
  4. OpenClaw вивантажує повідомлення керування з черги.
  5. 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 collect OpenClaw не виконує керування. Він чекає, доки активне виконання завершиться, а потім створює наступний хід із сумісними повідомленнями з черги після вікна debounce.
  • З /queue interrupt OpenClaw перериває активне виконання й запускає найновіше повідомлення замість керування.

​
Область дії

Керування завжди націлене на поточне активне виконання сеансу. Воно не створює новий сеанс, не змінює політику інструментів активного виконання й не розділяє повідомлення за відправником. У багатокористувацьких каналах вхідні запити вже містять контекст відправника та маршруту, тому наступний виклик моделі може побачити, хто надіслав кожне повідомлення. Використовуйте followup або collect, коли хочете, щоб повідомлення за замовчуванням ставали в чергу замість керування активним виконанням. Використовуйте interrupt, коли найновіший запит має замінити активне виконання.

​
Debounce

messages.queue.debounceMs застосовується до доставки поставлених у чергу followup і collect. У режимі steer з нативним harness Codex він також задає тихе вікно перед надсиланням згрупованого turn/steer. Для OpenClaw саме активне керування не використовує таймер debounce, бо OpenClaw природно групує повідомлення до наступної межі моделі.

​
Повʼязане