Ogólne

OpenClaw handoff: jak przekazywać zadania między agentem, cronem i człowiekiem

Najkrócej: dobry handoff w OpenClaw to krótki, sprawdzalny opis stanu zadania: cel, ostatnia decyzja, aktualny blocker, następny krok, linki do artefaktów i kryterium sukcesu. Dzięki temu agent AI, cron albo człowiek może wejść w pracę bez czytania całej historii od początku.

Po co handoff w automatyzacji AI

Automatyzacje AI rzadko kończą się w jednym idealnym przebiegu. Cron może wykonać część zadania, agent może potrzebować decyzji, a człowiek może wrócić do tematu po kilku dniach. Handoff jest miejscem, które odpowiada na pytanie: co dokładnie wiadomo teraz?

W OpenClaw warto traktować handoff jak mały kontrakt operacyjny. Nie opisuje całego procesu, tylko stan, który pozwala bezpiecznie kontynuować pracę.

Minimalny format handoffu

Dobry wpis handoffu powinien zmieścić się w kilku punktach. Najczęściej wystarczy taki układ:

  • Cel: jaki efekt ma powstać, nie tylko jaka czynność została uruchomiona.
  • Status: co jest już zrobione i co zostało zweryfikowane.
  • Następny krok: jedna konkretna akcja, którą ma wykonać kolejny wykonawca.
  • Blocker: czego brakuje, jeśli praca nie może iść dalej.
  • Artefakty: linki do plików, URL-i, issue, paneli lub logów.
  • Done means: proste kryterium, po którym wiadomo, że zadanie jest zamknięte.

Krótki przykład do wklejenia w notatkę, komentarz albo status zadania:

Cel: opublikować wpis tygodniowy na blogu.
Status: draft utworzony, treść przeszła lokalny sanity check.
Następny krok: opublikować i sprawdzić publiczny URL.
Blocker: brak.
Artefakty: /admin/blog.php?action=edit&id=123
Done means: HTTP 200, tytuł widoczny, linki wewnętrzne 200.

Gdzie zapisywać handoff w OpenClaw

Miejsce zależy od trwałości informacji. Jeśli handoff dotyczy jednego przebiegu crona, wystarczy status zadania lub raport końcowy. Jeśli ma być używany przez kolejne dni, lepiej zapisać go w systemie zadań, issue albo dedykowanej notatce operacyjnej.

Nie wszystko powinno trafiać do pamięci długoterminowej. Dane wrażliwe, hasła, tokeny i pełne logi błędów zostają poza publiczną treścią oraz poza trwałymi notatkami, jeśli nie są konieczne. Do handoffu trafia opis, gdzie znaleźć właściwy artefakt, a nie sekret.

Handoff dla crona

Cron potrzebuje handoffu szczególnie wtedy, gdy działa bez człowieka przy klawiaturze. Warto wymagać od niego raportu w stałym formacie: co próbował zrobić, co się udało, czego nie udało się naprawić i czy retry ma sens.

  • Jeśli wynik jest kompletny, raport powinien zawierać finalny URL, identyfikator zadania albo inny sprawdzalny dowód.
  • Jeśli wynik jest częściowy, raport powinien wskazywać ostatni bezpieczny stan, na przykład draft zamiast publikacji.
  • Jeśli wystąpił błąd, raport powinien odróżniać błąd chwilowy od problemu wymagającego decyzji człowieka.

To dobrze łączy się z podejściem opisanym w artykule o cron QA w OpenClaw: automatyzacja nie powinna udawać sukcesu, jeśli nie ma finalnego, zweryfikowanego efektu.

Handoff między agentami

Gdy jeden agent przekazuje zadanie drugiemu, najważniejsze jest ograniczenie kontekstu do informacji wykonawczych. Zamiast kopiować całą rozmowę, lepiej przekazać wynik analizy, decyzje, ograniczenia i test, który ma potwierdzić sukces.

Przy większych zadaniach dobrym wzorcem jest rozdzielenie ról: jeden agent czyta i diagnozuje, drugi implementuje, a główny agent scala wynik oraz wykonuje QA. Więcej o takim podziale pisaliśmy w tekście o subagentach w OpenClaw.

Najczęstsze błędy

  • Handoff jako streszczenie historii: kolejny wykonawca potrzebuje następnej akcji, nie pełnej kroniki.
  • Brak kryterium końca: bez definicji sukcesu agent może zakończyć pracę po samej próbie.
  • Niejasny blocker: zdanie „nie działa” trzeba zastąpić konkretnym warunkiem, który zatrzymał zadanie.
  • Brak linków do artefaktów: handoff bez adresu pliku, panelu lub logu zmusza do ponownego szukania.

Prosty checklist przed przekazaniem zadania

Przed zakończeniem przebiegu warto odpowiedzieć na pięć pytań:

  1. Czy następna osoba lub agent wie, jaki jest cel?
  2. Czy wiadomo, co zostało już sprawdzone?
  3. Czy jest jedna konkretna następna akcja?
  4. Czy linki do artefaktów działają?
  5. Czy wiadomo, kiedy zadanie można uznać za zakończone?

Jeżeli odpowiedź na którekolwiek pytanie brzmi „nie”, handoff wymaga doprecyzowania przed zamknięciem przebiegu.

FAQ

Czy handoff powinien być długi?

Nie. Najlepszy handoff jest krótki, ale konkretny. Zwykle wystarczy 6-10 zdań i kilka linków.

Czy handoff zastępuje logi?

Nie. Logi pokazują szczegóły techniczne, a handoff mówi, co z nich wynika i co trzeba zrobić dalej.

Czy każdy cron potrzebuje handoffu?

Każdy cron powinien zostawić wynik, ale pełniejszy handoff jest potrzebny głównie tam, gdzie możliwy jest stan częściowy, ręczna decyzja albo późniejsze wznowienie.

Powiązane artykuły

Jeśli budujesz w OpenClaw crony albo workflowy, zacznij od jednego standardowego formatu handoffu. Dopiero potem automatyzuj jego tworzenie i walidację.

← Wrocz do bloga