Ogólne

OpenClaw cron QA: automatyzacje AI, które nie udają sukcesu

Najkrócej: cron AI w OpenClaw powinien kończyć się dowodem, nie deklaracją. Dobry raport zawiera publiczny URL, status HTTP 200, widoczny tytuł, fragment treści, sprawdzone linki wewnętrzne i jasną informację, co agent zrobił po drodze.

To jest szczególnie ważne przy zadaniach publikacyjnych, porządkowaniu inboxa, cyklicznych raportach i workflowach, które działają bez człowieka przy klawiaturze. Samo "gotowe" nie wystarcza, bo automatyzacja może utworzyć szkic, zgubić formatowanie albo opublikować stronę z kodowaniem nie do czytania.

Minimalna definicja sukcesu dla crona

Dla praktycznego crona OpenClaw warto opisać sukces tak, żeby dało się go sprawdzić maszynowo i ludzkim wzrokiem. Najprostszy kontrakt wygląda tak:

  • zadanie wykonało dokładnie jedną zmianę, którą można wskazać adresem lub identyfikatorem,
  • agent najpierw utworzył bezpieczny stan pośredni, na przykład draft,
  • po publikacji sprawdził wynik pod publicznym URL-em,
  • raport końcowy mówi, co przeszło QA, a nie tylko że proces się zakończył.

Wzorzec: draft, QA, publish, QA

Najbardziej odporny przebieg jest prosty: cron loguje się, pobiera aktualny token, tworzy szkic, czyta go z powrotem, a dopiero potem publikuje. Po publikacji robi drugą weryfikację już po stronie publicznej.

Checklist przed publikacją

  • czy temat nie dubluje istniejącego wpisu,
  • czy treść ma prawdziwe tagi HTML, a nie tekst z widocznymi nawiasami tagów,
  • czy polskie znaki nie zamieniły się w mojibake,
  • czy linki wewnętrzne prowadzą do działających stron,
  • czy finalny raport nie ujawnia sekretów, ciasteczek ani tokenów.

Krótki szkic kontraktu QA

cron_id: "weekly-blog-publisher"
expected: "1 published post"
checks: ["direct_200", "title_visible", "html_rendered", "internal_links_200"]
report: "4 concise lines, no secrets"

Co agent powinien zapisać w pamięci workflowu

Pamięć nie musi przechowywać sekretów ani całych odpowiedzi z panelu admina. Wystarczą metadane, które pomagają uniknąć duplikatów i debugować kolejne uruchomienie:

  • ostatni opublikowany tytuł, slug i data,
  • źródło tematu lub krótka notatka redakcyjna,
  • wynik QA, na przykład liczba działających linków,
  • znane ograniczenia, które nie blokują sukcesu, ale warto je obserwować.

Ograniczenia i typowe awarie

Najczęstszy problem to fałszywy sukces: agent utworzył wpis, ale nie sprawdził publicznego URL-a. Drugi problem to formatowanie, szczególnie gdy cały HTML został potraktowany jak tekst. Trzeci to indeks, który może odświeżać się inaczej niż bezpośrednia strona wpisu.

Dlatego cron nie powinien kończyć pracy na statusie z panelu administracyjnego. Panel mówi, że zapis się udał; QA mówi, czy czytelnik zobaczy poprawny artykuł.

FAQ

Czy cron może publikować bez człowieka?

Tak, jeśli człowiek wcześniej jasno zatwierdził ten typ działania, a workflow ma ograniczenia: jeden wpis, draft przed publikacją, weryfikacja publicznego URL-a i raport bez sekretów.

Czy wystarczy sprawdzić stronę /blog?

Nie zawsze. Indeks może mieć opóźnienie albo osobny problem renderowania. Direct URL wpisu jest ważniejszym dowodem, a indeks warto sprawdzić jako dodatkowy sygnał.

Co zrobić, gdy HTML jest widoczny jako tekst?

Trzeba wrócić do edycji wpisu i zapisać treść jako realny HTML w polu edytora. Escapować należy tylko literalny kod wewnątrz <code>, nie całą treść artykułu.

Powiązane artykuły

Jeśli budujesz podobny proces, zacznij od małego kontraktu QA i dopiero potem dokładaj kolejne automatyzacje. Dokumentację i punkty startowe znajdziesz w dokumentacji OpenClaw po polsku.

← Wrocz do bloga