Zadania w tle

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

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

# TL;DR

• Zadania są rekordami, nie harmonogramami - cron i Heartbeat decydują, kiedy praca jest uruchamiana, a zadania śledzą, co się wydarzyło.
• ACP, subagenci, wszystkie zadania cron i operacje CLI tworzą zadania. Tury Heartbeat nie.
• Każde zadanie przechodzi przez queued → running → terminal (succeeded, failed, timed_out, cancelled lub lost).
• Zadania cron pozostają aktywne, dopóki runtime cron nadal posiada zadanie; jeśli stan runtime w pamięci zniknie, konserwacja zadań najpierw sprawdza trwałą historię uruchomień cron, zanim oznaczy zadanie jako lost.
• Ukończenie jest sterowane zdarzeniami push: odłączona praca może powiadomić bezpośrednio albo wybudzić sesję żądającą/Heartbeat po zakończeniu, więc pętle odpytywania statusu zwykle są niewłaściwym wzorcem.
• Izolowane uruchomienia cron i ukończenia subagentów w miarę możliwości czyszczą śledzone karty przeglądarki/procesy dla swojej sesji podrzędnej przed końcowym księgowaniem sprzątania.
• Izolowane dostarczanie cron tłumi nieaktualne tymczasowe odpowiedzi nadrzędne, gdy praca potomnego subagenta nadal się opróżnia, i preferuje końcowe wyjście potomne, 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 status
openclaw tasks list --runtime acp
openclaw 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 task
openclaw tasks notify <lookup> state_changes

# Run a health audit
openclaw tasks audit

# Preview or apply maintenance
openclaw tasks maintenance
openclaw tasks maintenance --apply

# Inspect TaskFlow state
openclaw tasks flow list
openclaw 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 odpowiednio do wyniku.

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 limitu czasu lub przerwania finalizują się jako timed_out. Jeśli operator już anulował zadanie albo runtime już zapisał silniejszy stan terminalny, taki jak failed, timed_out lub lost, późniejszy sygnał powodzenia nie obniża tego statusu terminalnego.

lost uwzględnia runtime:

• Zadania ACP: metadane podrzędnej sesji ACP zaplecza zniknęły.
• Zadania subagentów: podrzędna sesja zaplecza zniknęła z magazynu agenta docelowego.
• Zadania cron: runtime 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 runtime cron w procesie jako autorytetu.
• Zadania CLI: izolowane zadania sesji podrzędnej używają sesji podrzędnej; zadania CLI oparte na czacie używają zamiast tego aktywnego kontekstu uruchomienia, więc zalegające wiersze sesji kanału/grupy/bezpośredniej nie utrzymują ich przy życiu. Uruchomienia openclaw agent oparte na Gateway również finalizują się na podstawie wyniku uruchomienia, więc ukończone uruchomienia nie pozostają aktywne, dopóki sprzątacz nie oznaczy ich jako lost.

# Dostarczanie i powiadomienia

Gdy zadanie osiąga stan terminalny, OpenClaw powiadamia Cię. 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.). Dla ukończeń subagentów OpenClaw zachowuje również powiązane trasowanie 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 dostarczenie bezpośrednie się nie powiedzie albo nie ustawiono źródła, aktualizacja jest kolejkowana jako zdarzenie systemowe w sesji żądającego i pojawia się przy następnym Heartbeat.

Oznacza to, że zwykły przepływ pracy jest oparty na push: uruchom odłączoną pracę raz, a następnie pozwól runtime wybudzić Cię lub 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ę, gdy zadanie jest uruchomione:

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 ze środowiskiem uruchomieniowym, statusem, czasami oraz postępem lub szczegółami błędu.

Gdy bieżąca sesja nie ma widocznych powiązanych zadań, /tasks przechodzi awaryjnie do lokalnych dla agenta liczników zadań, aby nadal zapewnić przegląd bez ujawniania szczegółów innych sesji.

Aby zobaczyć pełny dziennik operatora, użyj CLI: openclaw tasks list.

# Integracja statusu (presja zadań)

openclaw status zawiera skrócone 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ń świadomej czyszczenia: aktywne zadania mają pierwszeństwo, przestarzałe ukończone wiersze są ukrywane, a niedawne niepowodzenia są pokazywane tylko wtedy, gdy nie pozostaje żadna aktywna praca. Dzięki temu karta statusu skupia się na tym, co ważne w danej chwili.

# Przechowywanie i konserwacja

# Gdzie znajdują się zadania

Rekordy zadań są utrwalane w SQLite pod adresem:

$OPENCLAW_STATE_DIR/tasks/runs.sqlite

Rejestr ładuje się do pamięci przy starcie Gateway i synchronizuje zapisy do SQLite, aby zapewnić trwałość po restartach. Gateway utrzymuje dziennik zapisu z wyprzedzeniem SQLite w ograniczonym rozmiarze, używając domyślnego progu autocheckpoint SQLite oraz okresowych i wykonywanych przy zamykaniu punktów kontrolnych TRUNCATE.

# Automatyczna konserwacja

Proces czyszczący uruchamia się co 60 sekund i obsługuje cztery rzeczy:

# Jak zadania odnoszą się do innych systemów

# Powiązane

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