Zadania w tle

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

Zadania nie zastępują sesji, zadań cron ani Heartbeat - są dziennikiem aktywności, który zapisuje, jaka odłączona praca została wykonana, kiedy oraz czy zakończyła się powodzeniem.

TL;DR

• Zadania są rekordami, a nie harmonogramami - cron i Heartbeat decydują, kiedy praca jest uruchamiana, zadania śledzą co się stało.
• ACP, subagenci, wszystkie zadania cron i operacje CLI tworzą zadania. Tury Heartbeat tego nie robią.
• Każde zadanie przechodzi przez queued → running → terminal (succeeded, failed, timed_out, cancelled lub lost).
• Zadania Cron pozostają aktywne, dopóki środowisko wykonawcze cron nadal jest właścicielem zadania; jeśli stan środowiska wykonawczego w pamięci zniknie, konserwacja zadań najpierw sprawdza trwałą historię uruchomień cron, zanim oznaczy zadanie jako utracone.
• Ukończenie jest oparte na wypychaniu: odłączona praca może powiadomić bezpośrednio albo wybudzić sesję żądającą/Heartbeat po zakończeniu, więc pętle odpytywania statusu są zwykle niewłaściwym kształtem.
• Izolowane uruchomienia cron i ukończenia subagentów podejmują najlepszą możliwą próbę wyczyszczenia śledzonych kart przeglądarki/procesów dla swojej sesji podrzędnej przed końcowym księgowaniem czyszczenia.
• Izolowane dostarczanie cron tłumi nieaktualne tymczasowe odpowiedzi rodzica, gdy praca potomnych subagentów nadal się kończy, i preferuje końcowe wyjście potomka, jeśli dotrze przed dostarczeniem.
• Powiadomienia o ukończeniu są dostarczane bezpośrednio do kanału albo kolejkowane do następnego Heartbeat.
• openclaw tasks list pokazuje wszystkie zadania; openclaw tasks audit ujawnia problemy.
• Rekordy terminalne są przechowywane przez 7 dni, a następnie automatycznie usuwane.

Szybki start

# List all tasks (newest first)openclaw tasks list # Filter by runtime or statusopenclaw tasks list --runtime acpopenclaw tasks list --status running

# Show details for a specific task (by ID, run ID, or session key)openclaw tasks show <lookup>

# Cancel a running task (kills the child session)openclaw tasks cancel <lookup> # Change notification policy for a taskopenclaw tasks notify <lookup> state_changes

# Run a health auditopenclaw tasks audit # Preview or apply maintenanceopenclaw tasks maintenanceopenclaw tasks maintenance --apply

# Inspect TaskFlow stateopenclaw tasks flow listopenclaw tasks flow show <lookup>openclaw tasks flow cancel <lookup>

Co tworzy zadanie

Cykl życia zadania

stateDiagram-v2
    [*] --> queued
    queued --> running : agent starts
    running --> succeeded : completes ok
    running --> failed : error
    running --> timed_out : timeout exceeded
    running --> cancelled : operator cancels
    queued --> lost : session gone > 5 min
    running --> lost : session gone > 5 min

Przejścia zachodzą automatycznie - gdy powiązane uruchomienie agenta się kończy, status zadania jest aktualizowany tak, aby mu odpowiadał.

Ukończenie uruchomienia agenta jest autorytatywne dla aktywnych rekordów zadań. Pomyślne odłączone uruchomienie finalizuje się jako succeeded, zwykłe błędy uruchomienia finalizują się jako failed, a wyniki przekroczenia czasu lub przerwania finalizują się jako timed_out. Jeśli operator już anulował zadanie albo środowisko wykonawcze już zapisało silniejszy stan terminalny, taki jak failed, timed_out lub lost, późniejszy sygnał powodzenia nie obniża tego statusu terminalnego.

lost uwzględnia środowisko wykonawcze:

• Zadania ACP: zniknęły metadane podrzędnej sesji ACP stanowiące zaplecze.
• Zadania subagentów: podrzędna sesja stanowiąca zaplecze zniknęła z docelowego magazynu agenta.
• Zadania Cron: środowisko wykonawcze cron nie śledzi już zadania jako aktywnego, a trwała historia uruchomień cron nie pokazuje terminalnego wyniku dla tego uruchomienia. Audyt CLI offline nie traktuje własnego pustego stanu środowiska wykonawczego cron w procesie jako autorytatywnego.
• Zadania CLI: zadania z identyfikatorem uruchomienia/identyfikatorem źródła używają aktywnego kontekstu uruchomienia, więc pozostające wiersze sesji podrzędnej lub sesji czatu nie utrzymują ich przy życiu po zniknięciu uruchomienia należącego do Gateway. Starsze zadania CLI bez tożsamości uruchomienia nadal wracają do sesji podrzędnej. Uruchomienia openclaw agent oparte na Gateway także finalizują się na podstawie wyniku uruchomienia, więc ukończone uruchomienia nie pozostają aktywne, dopóki proces sprzątający nie oznaczy ich jako lost.

Dostarczanie i powiadomienia

Gdy zadanie osiągnie stan terminalny, OpenClaw Cię powiadomi. Istnieją dwie ścieżki dostarczania:

Dostarczanie bezpośrednie - jeśli zadanie ma cel kanału (requesterOrigin), wiadomość o ukończeniu trafia prosto do tego kanału (Telegram, Discord, Slack itd.). Ukończenia zadań grupowych i kanałowych są zamiast tego kierowane przez sesję żądającą, aby agent nadrzędny mógł napisać widoczną odpowiedź. Dla ukończeń subagentów OpenClaw zachowuje także powiązane routowanie wątku/tematu, gdy jest dostępne, i może uzupełnić brakujące to / konto z zapisanej trasy sesji żądającej (lastChannel / lastTo / lastAccountId), zanim zrezygnuje z dostarczania bezpośredniego.

Dostarczanie kolejkowane w sesji - jeśli dostarczanie bezpośrednie się nie powiedzie albo nie ustawiono źródła, aktualizacja jest kolejkowana jako zdarzenie systemowe w sesji żądającej i pojawia się przy następnym Heartbeat.

Oznacza to, że typowy przepływ pracy jest oparty na wypychaniu: uruchom odłączoną pracę raz, a następnie pozwól środowisku wykonawczemu wybudzić Cię albo powiadomić po ukończeniu. Odpytuj stan zadania tylko wtedy, gdy potrzebujesz debugowania, interwencji albo jawnego audytu.

Polityki powiadomień

Kontroluj, ile informacji otrzymujesz o każdym zadaniu:

Zmień politykę podczas działania zadania:

openclaw tasks notify <lookup> state_changes

Dokumentacja CLI

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

openclaw tasks show <lookup>

openclaw tasks cancel <lookup>

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

openclaw tasks audit [--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 zobaczyć zadania w tle powiązane z tą sesją. Tablica pokazuje aktywne i niedawno ukończone zadania wraz z runtime, stanem, czasem oraz postępem lub szczegółami błędu.

Gdy bieżąca sesja nie ma widocznych powiązanych zadań, /tasks wraca do lokalnych dla agenta liczników zadań, dzięki czemu nadal otrzymujesz przegląd bez ujawniania szczegółów innych sesji.

Aby zobaczyć pełną księgę operatora, użyj CLI: openclaw tasks list.

Integracja stanu (presja zadań)

openclaw status zawiera szybkie podsumowanie zadań:

Tasks: 3 queued · 2 running · 1 issues

Podsumowanie raportuje:

• active - liczba queued + running
• failures - liczba failed + timed_out + lost
• byRuntime - podział według acp, subagent, cron, cli

Zarówno /status, jak i narzędzie session_status używają migawki zadań uwzględniającej czyszczenie: aktywne zadania mają pierwszeństwo, nieaktualne ukończone wiersze są ukrywane, a ostatnie niepowodzenia pojawiają się tylko wtedy, gdy nie ma już aktywnej pracy. Dzięki temu karta stanu skupia się na tym, co jest ważne teraz.

Przechowywanie i konserwacja

Gdzie znajdują się zadania

Rekordy zadań są utrwalane w SQLite pod adresem:

$OPENCLAW_STATE_DIR/tasks/runs.sqlite

Rejestr jest ładowany do pamięci przy starcie Gateway i synchronizuje zapisy do SQLite, aby zapewnić trwałość między restartami. Gateway utrzymuje dziennik zapisu z wyprzedzeniem SQLite w ograniczonym rozmiarze, używając domyślnego progu autocheckpoint SQLite oraz okresowych punktów kontrolnych PASSIVE. Zamknięcie i jawne punkty kontrolne konserwacji nadal używają TRUNCATE, aby zwykłe zamknięcia mogły odzyskać miejsce WAL bez zmuszania zamiatacza w tle do czekania na aktywnych czytelników.

Automatyczna konserwacja

Zamiatacz uruchamia się co 60 sekund i obsługuje cztery rzeczy:

Jak zadania odnoszą się do innych systemów

Powiązane

• Automatyzacja - wszystkie mechanizmy automatyzacji w skrócie
• CLI: Zadania - dokumentacja poleceń CLI
• Heartbeat - okresowe tury sesji głównej
• Zaplanowane zadania - planowanie pracy w tle
• TaskFlow - orkiestracja przepływu nad zadaniami