Kolejka poleceń

​

Dlaczego

• Uruchomienia automatycznych odpowiedzi mogą być kosztowne (wywołania LLM) i mogą ze sobą kolidować, gdy wiele wiadomości przychodzących pojawi się w krótkim odstępie.
• Szeregowanie zapobiega rywalizacji o współdzielone zasoby (pliki sesji, dzienniki, standardowe wejście CLI) i zmniejsza ryzyko przekroczenia limitów częstotliwości usług nadrzędnych.

​

Jak to działa

• Kolejka FIFO uwzględniająca tory opróżnia każdy tor zgodnie z konfigurowalnym limitem współbieżności (domyślnie 1 dla nieskonfigurowanych torów; domyślnie 4 dla main i 8 dla subagent).
• runEmbeddedAgent umieszcza zadania w kolejce według klucza sesji (tor session:<key>), aby zagwarantować tylko jedno aktywne uruchomienie na sesję.
• Każde uruchomienie sesji jest następnie umieszczane w torze globalnym (domyślnie main), dzięki czemu ogólna równoległość jest ograniczana przez agents.defaults.maxConcurrent.
• Gdy włączone jest szczegółowe rejestrowanie, uruchomienia oczekujące w kolejce emitują krótkie powiadomienie, jeśli przed rozpoczęciem czekały dłużej niż około 2 sekundy.
• Wskaźniki pisania nadal są uruchamiane natychmiast po umieszczeniu w kolejce (jeśli kanał je obsługuje), dzięki czemu podczas oczekiwania na swoją kolej środowisko użytkownika pozostaje niezmienione.

​

Wartości domyślne

• mode: "steer"
• debounceMs: 500
• cap: 20
• drop: "summarize"

​

Tryby kolejki

• steer: wstrzykuje wiadomości do aktywnego środowiska wykonawczego. OpenClaw dostarcza wszystkie oczekujące wiadomości sterujące po zakończeniu wykonywania wywołań narzędzi w bieżącej turze asystenta, przed następnym wywołaniem LLM; serwer aplikacji Codex otrzymuje jedno zbiorcze turn/steer. Jeśli uruchomienie nie przesyła aktywnie strumienia lub sterowanie jest niedostępne, OpenClaw czeka z rozpoczęciem polecenia do zakończenia aktywnego uruchomienia.
• followup: nie steruje. Umieszcza każdą wiadomość w kolejce do późniejszej tury agenta po zakończeniu bieżącego uruchomienia.
• collect: nie steruje. Scala wiadomości z kolejki w jedną turę uzupełniającą po upływie okresu ciszy. Jeśli wiadomości są kierowane do różnych kanałów lub wątków, są pobierane pojedynczo, aby zachować routing.
• interrupt: przerywa aktywne uruchomienie tej sesji, a następnie uruchamia najnowszą wiadomość.

{
  messages: {
    queue: {
      mode: "steer",
      debounceMs: 500,
      cap: 20,
      drop: "summarize",
      byChannel: { discord: "collect" },
    },
  },
}

​

Opcje kolejki

• debounceMs: okres ciszy przed pobraniem z kolejki tur uzupełniających lub zbiorczych partii; w trybie Codex steer — okres ciszy przed wysłaniem zbiorczego turn/steer. Same liczby oznaczają milisekundy; opcje /queue akceptują jednostki ms, s, m, h i d.
• cap: maksymalna liczba wiadomości w kolejce na sesję. Wartości mniejsze niż 1 są ignorowane.
• drop: "summarize" (domyślnie): w razie potrzeby usuwa najstarsze wpisy z kolejki, zachowuje ich zwięzłe podsumowania i wstrzykuje je jako syntetyczne polecenie uzupełniające.
• drop: "old": w razie potrzeby usuwa najstarsze wpisy z kolejki bez zachowywania podsumowań.
• drop: "new": odrzuca najnowszą wiadomość, gdy kolejka jest już pełna.

​

Sterowanie i przesyłanie strumieniowe

• partial: podgląd może zostać zakończony wcześniej, a po przyjęciu sterowania rozpoczyna się nowy podgląd.
• block: bloki o rozmiarze wersji roboczej mogą powodować taki sam wygląd sekwencyjny.
• Bez przesyłania strumieniowego sterowanie przechodzi na turę uzupełniającą po aktywnym uruchomieniu, gdy środowisko wykonawcze nie może przyjąć sterowania w tej samej turze.

​

Kolejność pierwszeństwa

1. Wbudowane lub zapisane dla sesji nadpisanie /queue.
2. messages.queue.byChannel.<channel>.
3. messages.queue.mode.
4. Domyślny tryb steer.

​

Nadpisania dla sesji

• Wyślij /queue <steer|followup|collect|interrupt> jako samodzielne polecenie, aby zapisać tryb kolejki dla bieżącej sesji.
• Opcje można łączyć: /queue collect debounce:0.5s cap:25 drop:summarize
• /queue default lub /queue reset usuwa nadpisanie sesji.

​

Anulowanie tur w kolejce

• chat.abort z określonym runId anuluje tę turę, gdy nadal znajduje się ona w kolejce, jeśli żądający ma autoryzację (obowiązują te same reguły własności co w przypadku aktywnych uruchomień).
• chat.abort dla sesji bez runId anuluje najpierw autoryzowane tury w kolejce, a następnie przerywa autoryzowane aktywne uruchomienia. Taka kolejność zapobiega wypromowaniu pracy przez opróżnianie kolejki do częściowo zatrzymanej sesji.
• Czyszczenie całej kolejki sesji bez sprawdzania poszczególnych żądających nie stanowi ścieżki zatrzymywania sesji z wieloma właścicielami.
• Oczekiwanie w kolejce nie jest przedstawiane jako aktywne uruchomienie agenta w sessions.list i nie podlega semantyce limitu czasu aktywnego uruchomienia; dotyczy ona wyłącznie fazy aktywnej.

​

Zakres i gwarancje

• Dotyczy uruchomień agentów automatycznej odpowiedzi we wszystkich kanałach przychodzących korzystających z potoku odpowiedzi Gateway (WhatsApp w przeglądarce, Telegram, Slack, Discord, Signal, iMessage, czat internetowy itd.).
• Domyślny tor (main) obejmuje cały proces dla ruchu przychodzącego i głównych Heartbeatów; ustaw agents.defaults.maxConcurrent, aby zezwolić na równoległe działanie wielu sesji.
• Mogą istnieć dodatkowe tory (np. cron, cron-nested, nested, subagent), dzięki czemu zadania w tle mogą działać równolegle bez blokowania odpowiedzi przychodzących. Izolowane tury agenta Cron zajmują miejsce cron, podczas gdy ich wewnętrzne wykonanie agenta używa cron-nested; oba korzystają z cron.maxConcurrentRuns. Współdzielone przepływy nested, które nie należą do Cron, zachowują własne działanie toru. Te odłączone uruchomienia są śledzone jako zadania w tle.
• Tory dla poszczególnych sesji gwarantują, że w danym momencie tylko jedno uruchomienie agenta korzysta z określonej sesji.
• Brak zewnętrznych zależności i wątków roboczych działających w tle; wyłącznie TypeScript i obietnice.

​

Rozwiązywanie problemów

• Jeśli polecenia wydają się zablokowane, włącz szczegółowe dzienniki i poszukaj wierszy „queued for …ms”, aby potwierdzić, że kolejka jest opróżniana.
• Uruchomienia serwera aplikacji Codex, które przyjmują turę, a następnie przestają emitować postęp, są przerywane przez adapter Codex, aby aktywny tor sesji mógł zostać zwolniony zamiast czekać na limit czasu zewnętrznego uruchomienia.
• Gdy diagnostyka jest włączona, sesje pozostające w stanie processing dłużej niż diagnostics.stuckSessionWarnMs bez zaobserwowanej odpowiedzi, użycia narzędzia, zmiany stanu, bloku ani postępu ACP są klasyfikowane według bieżącej aktywności:
  • Aktywna praca z niedawnym postępem jest rejestrowana jako session.long_running. Należące do właściciela ciche wywołania modelu również pozostają w stanie session.long_running do upływu diagnostics.stuckSessionAbortMs, aby powolni lub niestrumieniujący dostawcy nie byli zbyt wcześnie zgłaszani jako zablokowani.
  • Aktywna praca bez niedawno zarejestrowanego postępu jest klasyfikowana jako session.stalled; należące do właściciela wywołania modelu, zablokowane wywołania narzędzi i zablokowane osadzone uruchomienia przechodzą w stan session.stalled po osiągnięciu progu przerwania. Nieaktualna aktywność modelu lub narzędzia bez właściciela nie jest ukrywana jako długotrwała.
  • session.stuck jest zarezerwowane dla możliwego do naprawienia, nieaktualnego stanu ewidencyjnego sesji, w tym bezczynnych sesji w kolejce z nieaktualną aktywnością modelu lub narzędzia bez właściciela.
  • session.stuck zawsze uruchamia odzyskiwanie, które może zwolnić dotknięty problemem tor sesji. Klasyfikacja session.stalled po przekroczeniu diagnostics.stuckSessionAbortMs (zablokowane wywołanie narzędzia, zablokowane wywołanie modelu lub zablokowane osadzone uruchomienie) również może uruchomić aktywne odzyskiwanie przez przerwanie, więc kolejkę mogą odblokować obie klasyfikacje, nie tylko session.stuck.
  • Powtarzające się ostrzeżenia session.stuck i session.long_running w dzienniku stosują wykładniczo rosnące odstępy, dopóki sesja pozostaje niezmieniona; próby odzyskiwania nadal są wykonywane przy każdym takcie Heartbeatu, niezależnie od tego zwiększania odstępów.

​

Powiązane

• Zarządzanie sesjami
• Kolejka sterowania
• Sterowanie
• Zasady ponawiania