steer. Do tego domyślnego zachowania nie jest wymagana żadna pozycja konfiguracji
ani dyrektywa kolejki. OpenClaw i natywny harness app-server Codex implementują szczegóły
dostarczania w różny sposób.
Granica środowiska uruchomieniowego
Sterowanie nie przerywa już działającego wywołania narzędzia. OpenClaw sprawdza zakolejkowane komunikaty sterujące na granicach modelu:- Asystent prosi o wywołania narzędzi.
- OpenClaw wykonuje bieżącą partię wywołań narzędzi z komunikatu asystenta.
- OpenClaw emituje zdarzenie zakończenia tury.
- OpenClaw opróżnia zakolejkowane komunikaty sterujące.
- OpenClaw dołącza te komunikaty jako komunikaty użytkownika przed następnym wywołaniem LLM.
turn/steer zamiast wewnętrznej kolejki
sterowania środowiska uruchomieniowego OpenClaw. OpenClaw grupuje zakolejkowane prompty dla skonfigurowanego
okna ciszy, a następnie wysyła pojedyncze żądanie turn/steer ze wszystkimi zebranymi danymi wejściowymi
użytkownika w kolejności nadejścia.
Tury przeglądu Codex i ręcznej Compaction odrzucają sterowanie w tej samej turze. Gdy
środowisko uruchomieniowe nie może zaakceptować sterowania w trybie steer, OpenClaw czeka na zakończenie
aktywnego uruchomienia przed rozpoczęciem promptu.
Ta strona wyjaśnia sterowanie w trybie kolejki dla zwykłych komunikatów przychodzących, gdy tryb
to steer. Jeśli tryb to followup lub collect, zwykłe komunikaty nie trafiają
na tę ścieżkę sterowania; czekają, aż aktywne uruchomienie się zakończy. Informacje o jawnym
poleceniu /steer <message> znajdziesz w sekcji Sterowanie.
Tryby
| Tryb | Zachowanie podczas aktywnego uruchomienia | Późniejsze zachowanie |
|---|---|---|
steer | Steruje promptem do aktywnego środowiska uruchomieniowego, gdy jest to możliwe. | Czeka na zakończenie aktywnego uruchomienia, jeśli sterowanie jest niedostępne. |
followup | Nie steruje. | Uruchamia zakolejkowane komunikaty później, po zakończeniu aktywnego uruchomienia. |
collect | Nie steruje. | Scala zgodne zakolejkowane komunikaty w jedną późniejszą turę po oknie debounce. |
interrupt | Przerywa aktywne uruchomienie zamiast nim sterować. | Uruchamia najnowszy komunikat po przerwaniu. |
Przykład serii
Jeśli czterech użytkowników wyśle komunikaty, gdy agent wykonuje wywołanie narzędzia:- Przy domyślnym zachowaniu aktywne środowisko uruchomieniowe otrzymuje wszystkie cztery komunikaty w
kolejności nadejścia przed następną decyzją modelu. OpenClaw opróżnia je na następnej granicy modelu;
Codex otrzymuje je jako jedno zgrupowane
turn/steer. - Przy
/queue collectOpenClaw nie steruje. Czeka, aż aktywne uruchomienie się zakończy, a następnie tworzy turę followup ze zgodnymi zakolejkowanymi komunikatami po oknie debounce. - Przy
/queue interruptOpenClaw przerywa aktywne uruchomienie i uruchamia najnowszy komunikat zamiast sterować.
Zakres
Sterowanie zawsze kieruje na bieżące aktywne uruchomienie sesji. Nie tworzy nowej sesji, nie zmienia zasad narzędzi aktywnego uruchomienia ani nie dzieli komunikatów według nadawcy. W kanałach z wieloma użytkownikami prompty przychodzące zawierają już kontekst nadawcy i trasy, więc następne wywołanie modelu widzi, kto wysłał każdy komunikat. Użyjfollowup lub collect, gdy chcesz, aby komunikaty były domyślnie kolejkowane zamiast
sterować aktywnym uruchomieniem. Użyj interrupt, gdy najnowszy prompt powinien
zastąpić aktywne uruchomienie.
Debounce
messages.queue.debounceMs dotyczy zakolejkowanego dostarczania followup i collect.
W trybie steer z natywnym harnessem Codex ustawia też okno ciszy
przed wysłaniem zgrupowanego turn/steer. W przypadku OpenClaw samo aktywne sterowanie nie używa
timera debounce, ponieważ OpenClaw naturalnie grupuje komunikaty do następnej granicy modelu.