Zadania w tle

Zadania w tle śledzą pracę wykonywaną poza główną sesją konwersacji: uruchomienia ACP, tworzenie subagentów, wykonania zadań cron oraz operacje inicjowane z poziomu CLI.

Zadania nie zastępują sesji, zadań cron ani Heartbeat — są rejestrem aktywności, który zapisuje, jakie odłączone zadania wykonano, kiedy to nastąpiło i czy zakończyły się powodzeniem.

W skrócie

• Zadania są rekordami, a nie harmonogramami — cron i Heartbeat określają, kiedy wykonywana jest praca, a zadania śledzą, co się wydarzyło.
• ACP, subagenci, wszystkie zadania cron i operacje CLI tworzą zadania. Przebiegi Heartbeat ich nie tworzą.
• Każde zadanie przechodzi przez stany queued → running → terminal (succeeded, failed, timed_out, cancelled lub lost).
• Zadania cron pozostają aktywne, dopóki środowisko wykonawcze cron nadal zarządza zadaniem; jeśli stan środowiska wykonawczego w pamięci zniknie, mechanizm konserwacji zadań najpierw sprawdza trwałą historię uruchomień cron, zanim oznaczy zadanie jako utracone.
• Zakończenie jest obsługiwane przez powiadomienia push: odłączone zadanie może powiadomić bezpośrednio albo wybudzić sesję żądającą lub Heartbeat po zakończeniu, dlatego pętle odpytywania o stan są zwykle niewłaściwym rozwiązaniem.
• Izolowane uruchomienia cron i zakończenia subagentów podejmują, w miarę możliwości, próbę zamknięcia śledzonych kart przeglądarki i procesów ich sesji podrzędnej przed końcowym uporządkowaniem rejestru.
• Dostarczanie wyników izolowanego cron pomija nieaktualne pośrednie odpowiedzi rodzica, gdy zadania potomnych subagentów nadal się kończą, i preferuje końcowy wynik potomka, jeśli nadejdzie on przed dostarczeniem.
• Powiadomienia o zakończeniu są dostarczane bezpośrednio do kanału lub umieszczane w kolejce do następnego Heartbeat.
• openclaw tasks list wyświetla wszystkie zadania; openclaw tasks audit ujawnia problemy.
• Rekordy końcowe są przechowywane przez 7 dni (rekordy lost przez 24 godziny), a następnie automatycznie usuwane.

Szybki start

# Wyświetl wszystkie zadania (od najnowszych)openclaw tasks list # Filtruj według środowiska wykonawczego lub stanuopenclaw tasks list --runtime acpopenclaw tasks list --status running

# Wyświetl szczegóły konkretnego zadania (według identyfikatora zadania, identyfikatora uruchomienia lub klucza sesji)openclaw tasks show <lookup>

# Anuluj uruchomione zadanie (kończy sesję podrzędną)openclaw tasks cancel <lookup> # Zmień zasady powiadamiania dla zadaniaopenclaw tasks notify <lookup> state_changes

# Uruchom audyt kondycjiopenclaw tasks audit # Wyświetl podgląd konserwacji lub ją zastosujopenclaw tasks maintenanceopenclaw tasks maintenance --apply

# Sprawdź stan TaskFlowopenclaw tasks flow listopenclaw tasks flow show <lookup>openclaw tasks flow cancel <lookup>

Co tworzy zadanie

Cykl życia zadania

stateDiagram-v2
    [*] --> queued
    queued --> running : agent uruchamia się
    running --> succeeded : kończy się pomyślnie
    running --> failed : błąd
    running --> timed_out : przekroczono limit czasu
    queued --> cancelled : operator anuluje
    running --> cancelled : operator anuluje
    queued --> lost : stan bazowy nie istnieje > 5 min
    running --> lost : stan bazowy nie istnieje > 5 min

Przejścia następują automatycznie — zdarzenia cyklu życia uruchomienia agenta (początek, koniec, błąd) aktualizują stan zadania; nie zarządza się nim ręcznie.

Zakończenie uruchomienia agenta jest rozstrzygające dla aktywnych rekordów zadań. Pomyślne odłączone uruchomienie kończy się stanem succeeded, zwykłe błędy uruchomienia stanem failed, przekroczenia limitu czasu stanem timed_out, a anulowanie lub przerwanie stanem cancelled. Gdy zadanie osiągnie stan końcowy, późniejsze sygnały cyklu życia nie zmieniają go na mniej priorytetowy — zadanie anulowane przez operatora lub mające już stan failed/timed_out/lost zachowuje ten stan, nawet jeśli później nadejdzie sygnał powodzenia.

Stan lost uwzględnia środowisko wykonawcze:

• Zadania ACP: tylko aktywny przebieg ACP w procesie Gateway potwierdza, że uruchomienie nadal trwa; same utrwalone metadane sesji tego nie potwierdzają. Audyt CLI w trybie offline pozostaje zachowawczy i nigdy nie odzyskuje zadań ACP.
• Zadania subagentów: bazowa sesja podrzędna zniknęła z magazynu agenta docelowego lub zawiera znacznik odzyskiwania po ponownym uruchomieniu.
• Zadania cron: środowisko wykonawcze cron nie śledzi już zadania jako aktywnego, a trwała historia uruchomień cron nie zawiera końcowego wyniku tego uruchomienia. Audyt CLI w trybie offline nie uznaje własnego pustego stanu środowiska wykonawczego cron w procesie za źródło rozstrzygające.
• Zadania CLI: zadania z identyfikatorem uruchomienia lub źródła korzystają z aktywnego kontekstu uruchomienia, dlatego pozostałe rekordy sesji podrzędnej lub sesji konwersacji nie utrzymują ich jako aktywnych po zniknięciu uruchomienia zarządzanego przez Gateway. Starsze zadania CLI bez tożsamości uruchomienia nadal używają awaryjnie sesji podrzędnej. Uruchomienia openclaw agent obsługiwane przez Gateway również kończą się na podstawie wyniku uruchomienia, więc ukończone uruchomienia nie pozostają aktywne do czasu oznaczenia ich przez mechanizm czyszczący jako lost.

Dostarczanie i powiadomienia

Gdy zadanie osiąga stan końcowy, OpenClaw wysyła powiadomienie. Dostępne są dwie ścieżki dostarczania:

Dostarczanie bezpośrednie — jeśli zadanie ma cel kanału (requesterOrigin), wiadomość o zakończeniu trafia bezpośrednio do tego kanału (Discord, Slack, Telegram itp.). Zakończenia zadań grupowych i kanałowych są natomiast kierowane przez sesję żądającą, aby agent nadrzędny mógł napisać widoczną odpowiedź. W przypadku zakończeń subagentów OpenClaw zachowuje również powiązane trasowanie wątku lub tematu, gdy jest dostępne, i może uzupełnić brakujące to lub konto na podstawie zapisanej trasy sesji żądającej (lastChannel / lastTo / lastAccountId), zanim zrezygnuje z dostarczania bezpośredniego.

Dostarczanie w kolejce sesji — jeśli dostarczanie bezpośrednie nie powiedzie się lub nie ustawiono źródła, aktualizacja trafia do kolejki jako zdarzenie systemowe w sesji żądającej i pojawia się przy następnym Heartbeat.

Oznacza to, że typowy przepływ pracy opiera się na powiadomieniach push: uruchom odłączone zadanie raz, a następnie pozwól środowisku wykonawczemu wybudzić sesję lub powiadomić Cię po zakończeniu. Odpytuj o stan zadania tylko wtedy, gdy potrzebujesz debugowania, interwencji lub jawnego audytu.

Zasady powiadamiania

Określ, ile informacji chcesz otrzymywać o każdym zadaniu:

Zmień zasady podczas wykonywania zadania:

openclaw tasks notify <lookup> state_changes

Dokumentacja CLI

openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]

openclaw tasks show <lookup> [--json]

openclaw tasks cancel <lookup>

openclaw tasks notify <lookup> <done_only|state_changes|silent>

openclaw tasks audit [--severity <warn|error>] [--code <name>] [--limit <n>] [--json]

openclaw tasks maintenance [--json]openclaw tasks maintenance --apply [--json]

openclaw tasks flow list [--status <status>] [--json]openclaw tasks flow show <lookup> [--json]openclaw tasks flow cancel <lookup>

Tablica zadań czatu (/tasks)

Użyj /tasks w dowolnej sesji czatu, aby wyświetlić zadania w tle powiązane z tą sesją. Tablica pokazuje maksymalnie pięć aktywnych i niedawno ukończonych zadań wraz ze środowiskiem wykonawczym, stanem, informacjami o czasie oraz szczegółami postępu lub błędu.

Gdy bieżąca sesja nie ma widocznych powiązanych zadań, /tasks wyświetla zamiast tego liczbę lokalnych zadań agenta, dzięki czemu nadal otrzymujesz przegląd bez ujawniania szczegółów innych sesji.

Aby wyświetlić pełny rejestr operatora, użyj CLI: openclaw tasks list.

Interfejs sterowania

Internetowy interfejs sterowania zawiera na pasku bocznym stronę Zadania z aktywnymi i niedawnymi zadaniami w tle aktualizowanymi na żywo. Użyj jej, aby sprawdzać postęp, otwierać powiązane sesje, odświeżać rejestr albo anulować zadania znajdujące się w kolejce i uruchomione.

Panele czatu zawierają również zwijany pasek Zadania w tle, ograniczony do agenta danego panelu: uruchomione zadania i podagentów z kontrolką zatrzymania, sekcję ukończonych zadań oraz odnośniki Wyświetl transkrypcję prowadzące do sesji podrzędnej każdego zadania. Otwórz go za pomocą przełącznika aktywności w nagłówku panelu lub pływającego przycisku aktywności w czacie z jednym panelem.

Integracja ze stanem (obciążenie zadaniami)

openclaw status zawiera zwięzły wiersz zadań:

Zadania    2 aktywne · 1 w kolejce · 1 uruchomione · 1 problem · audyt bez zastrzeżeń · 6 śledzonych

Podsumowanie zlicza aktywne prace (queued + running), niepowodzenia (failed + timed_out + lost), ustalenia audytu i łączną liczbę śledzonych rekordów; dane JSON zawierają również podział liczby zadań według środowiska wykonawczego (acp, subagent, cron, cli).

Zarówno /status, jak i narzędzie session_status używają migawki zadań uwzględniającej czyszczenie: preferowane są aktywne zadania, wygasłe wiersze są ukrywane, a zadania końcowe pojawiają się tylko przez krótki okres po zakończeniu (5 minut), przy czym po ustaniu aktywnych prac wyróżniane są niepowodzenia. Dzięki temu karta stanu koncentruje się na tym, co jest ważne w danej chwili.

Przechowywanie i konserwacja

Miejsce przechowywania zadań

Rekordy zadań i stan dostarczania są trwale przechowywane we współdzielonej bazie danych stanu SQLite OpenClaw:

~/.openclaw/state/openclaw.sqlite   (tabele: task_runs, task_delivery_state, flow_runs)

Ustaw OPENCLAW_STATE_DIR, aby przenieść cały katalog główny stanu (domyślnie ~/.openclaw) w inne miejsce; ścieżka współdzielonej bazy danych zostanie przeniesiona razem z nim.

Rejestr jest wczytywany do pamięci przy pierwszym użyciu, a każdy zapis jest utrwalany w SQLite, dzięki czemu rekordy zachowują się po ponownym uruchomieniu Gateway. Wzrost WAL pozostaje ograniczony dzięki domyślnemu progowi automatycznych punktów kontrolnych SQLite oraz okresowym punktom kontrolnym PASSIVE; zamykanie i jawne punkty kontrolne konserwacji używają trybu TRUNCATE, dzięki czemu zwykłe zamknięcia odzyskują miejsce WAL bez zmuszania procesu czyszczącego w tle do oczekiwania na aktywnych czytelników.

Starsze magazyny pomocnicze z poprzednich instalacji (tasks/runs.sqlite, flows/registry.sqlite) są importowane do współdzielonej bazy danych przez openclaw doctor.

Automatyczna konserwacja

Proces czyszczący uruchamia się co 60 sekund (pierwszy przebieg około 5 sekund po uruchomieniu Gateway) i wykonuje cztery czynności:

Powiązania zadań z innymi systemami

Powiązane materiały

• Automatyzacja — przegląd wszystkich mechanizmów automatyzacji
• CLI: Zadania — dokumentacja poleceń CLI
• Heartbeat — okresowe tury sesji głównej
• Zaplanowane zadania — planowanie pracy w tle
• Task Flow — koordynacja przepływów ponad zadaniami