Ogólne

OpenClaw TaskFlow: długi workflow AI bez gubienia stanu

Najkrócej: TaskFlow w OpenClaw warto traktować jak mały runbook dla długiego zadania AI. Zamiast liczyć, że agent zapamięta cały kontekst rozmowy, opisujesz cel, stan, następny krok, właściciela i warunki zatrzymania. Dzięki temu workflow można wznowić po przerwie, przekazać innemu agentowi albo bezpiecznie uruchomić z crona.

To podejście przydaje się, gdy zadanie trwa dłużej niż jedna odpowiedź: research, publikacja wpisu, triage skrzynki, cykliczny raport, monitoring projektu albo automatyzacja wymagająca decyzji człowieka.

Kiedy zwykły cron przestaje wystarczać

Cron jest świetny do prostego polecenia: uruchom o 9:00, sprawdź stronę, wyślij raport. Problem zaczyna się wtedy, gdy proces ma kilka etapów i nie zawsze kończy się od razu.

  • Agent musi poczekać na odpowiedź użytkownika, plik, build albo zewnętrzny serwis.
  • Trzeba zachować częściowy wynik, ale nie publikować go jeszcze publicznie.
  • Po błędzie potrzebny jest powrót do ostatniego bezpiecznego checkpointu.
  • Kolejny agent powinien zrozumieć, co już zrobiono i czego nie wolno ruszać.

W takich sytuacjach cron powinien uruchamiać workflow, ale nie powinien być jedynym źródłem prawdy o stanie zadania.

Prosty szablon TaskFlow

Najpraktyczniejszy zapis mieści się w kilku polach. Nie musi być rozbudowany, ale powinien być konsekwentny.

  • goal - konkretny wynik, nie ogólna intencja.
  • owner - kto odpowiada za decyzję lub kolejny ruch.
  • state - aktualny status, na przykład working, waiting, blocked albo done.
  • checkpoint - ostatni sprawdzony punkt, do którego można wrócić.
  • next_action - jedno najbliższe działanie, bez listy życzeń.
  • stop_rules - warunki, przy których agent ma przestać działać i raportować.

Dobry test: jeśli wkleisz ten opis do świeżej sesji, agent powinien wiedzieć, co kontynuować, czego nie powtarzać i kiedy poprosić o decyzję.

Jak dzielić workflow na etapy

1. Najpierw granice

Zapisz, co agent może zrobić samodzielnie, a co wymaga człowieka. Dla publikacji bloga może to być: wolno przygotować draft, wolno sprawdzić linki, publikować tylko wtedy, gdy zadanie wyraźnie tego żąda.

2. Potem checkpointy

Checkpoint powinien oznaczać stan, który da się zweryfikować: draft istnieje, testy przeszły, URL zwraca HTTP 200, raport jest zapisany. Unikaj checkpointów typu prawie gotowe, bo nie pomagają przy wznowieniu.

3. Na końcu raport

Raport końcowy powinien mówić, co się stało, gdzie jest wynik i jakie ryzyko zostało. Przy automatyzacji publicznej dopisz też, czy sprawdzono formatowanie, kodowanie i linki.

Minimalny kontrakt stanu

Dla większości zespołów wystarczy taki kontrakt:

  • Nie powtarzaj pracy, jeśli checkpoint mówi, że etap jest już gotowy.
  • Nie eskaluj za wcześnie, jeśli istnieje prosty fallback.
  • Nie ukrywaj blokera, jeśli brakuje dostępu, danych albo finalnego URL.
  • Nie publikuj na zewnątrz, jeśli QA nie potwierdziło wyniku.

Taki kontrakt jest ważniejszy niż skomplikowana notacja. Agent ma rozumieć odpowiedzialność, nie tylko listę kroków.

Ograniczenia

  • TaskFlow nie naprawi źle opisanego celu. Jeśli wynik jest niejasny, stan też będzie niejasny.
  • Nie wszystko warto automatyzować. Jednorazowe, krótkie zadanie często lepiej wykonać w zwykłej sesji.
  • Długie workflowy potrzebują limitów: czasu, kosztu, liczby prób i warunków zatrzymania.
  • Pamięć agenta nie zastępuje jawnego checkpointu. Ważne decyzje zapisuj w stanie zadania.

FAQ

Czy TaskFlow zastępuje crona?

Nie. Cron odpowiada za czas uruchomienia, a TaskFlow za stan procesu. Najlepiej działają razem: cron budzi zadanie, TaskFlow mówi, co dalej.

Czy każdy workflow musi mieć osobny plik?

Nie zawsze. Ważne, żeby stan był trwały i czytelny. Może to być plik, rekord w systemie albo narzędzie koordynujące zadania, o ile agent może wrócić do tych informacji.

Kiedy oznaczyć zadanie jako zablokowane?

Gdy agent nie może wykonać sensownego kolejnego kroku bez decyzji, dostępu albo zmiany stanu zewnętrznego. Sam fakt, że zadanie jest trudne, nie jest jeszcze blockerem.

Powiązane artykuły

Jeśli budujesz pierwszy dłuższy proces w OpenClaw, zacznij od jednego workflowu, jednego checkpointu i jednej jasnej reguły zatrzymania. Dopiero potem dokładaj kolejne automatyzacje.

← Wrocz do bloga