Automatyzacje

Automatyzacje wykonują instrukcję według harmonogramu i dostarczają wynik jako zwykłą sesję czatu. Codzienny przegląd wiadomości, cotygodniowe podsumowanie, raport miesięczny — każde wykonanie działa bez interfejsu na serwerze, trafia na listę czatów i można je otworzyć oraz kontynuować jak każdą inną rozmowę.

Budowa

Automatyzacja ma nazwę, instrukcje w dowolnym tekście, co najmniej jeden wyzwalacz, opcjonalny model (puste oznacza Auto: domyślny model czatu w chwili wykonania), cel wykonania i preferencję powiadomień (w aplikacji lub wyłączone). Cel określa rezultat: Chat session (domyślnie) kolejkuje instrukcje jako rozmowę, a Work task uruchamia izolowaną piaskownicę Work z instrukcjami jako pierwszą wiadomością, opcjonalnie według nazwanej polityki Work wybranej w formularzu. Przy włączonych powiadomieniach nieudane wykonanie trafia też do skrzynki powiadomień, więc dowiesz się o awarii nawet po zamknięciu strony Automations. Niezależnie od tego, włączenie Wyników automatyzacji w Settings → Notifications → Email notifications wysyła Ci e-mailem wynik każdego wykonania, gdy tylko administrator skonfiguruje serwer poczty wychodzącej (zobacz Powiadomienia). Nazwy i instrukcje są zaszyfrowane w spoczynku. Każda automatyzacja należy do użytkownika, który ją utworzył.

Wyzwalacze używają wspólnego modelu kalendarza — once, hourly, daily, weekly, monthly, yearly — a automatyzacja może mieć ich maksymalnie pięć. Następne wykonanie to zawsze najwcześniejsze nadchodzące wystąpienie ze wszystkich wyzwalaczy, obliczone w lokalnej strefie czasowej serwera.

Wyzwalacze zdarzeniowe

Siódmy rodzaj, event, nie ma żadnego zegara: uruchamia się, gdy nadejdzie jedno z Twoich powiadomień.

{ "kind": "event", "event": "channel-mention", "match": "release" }

event to dowolny typ powiadomienia poza automation-failed — procedura nie może restartować się od własnego komunikatu o błędzie. Opcjonalne match to test podłańcucha bez rozróżniania wielkości liter na tytule powiadomienia; bez niego uruchamia ją każde powiadomienie tego typu.

Wyzwalacz zdarzeniowy nigdy nie wnosi czasu następnego wykonania. Automatyzacja, której wszystkie wyzwalacze są zdarzeniami, nie pokazuje więc żadnego następnego wykonania: lista i okno edycji pokazują zamiast tego Uruchamia się, gdy…. Łączenie wyzwalacza zdarzeniowego z harmonogramem działa bez problemu — zaplanowane wyzwalacze nadal napędzają zegar.

Dwa zabezpieczenia ograniczają zasięg. Procedura uruchamia się z wyzwalaczy zdarzeniowych najwyżej raz na minutę, bez względu na to, jak ruchliwy jest strumień, a powiadomienie o własnym niepowodzeniu wykonania nigdy nie uruchamia ponownie procedury, która je wygenerowała.

Wykonanie otrzymuje to, co je uruchomiło, dołączone do instrukcji:

---
Trigger payload (JSON):
{"event":"channel-mention","title":"...","body":"...","href":"..."}

Wykonanie

Co minutę działa krok harmonogramu za dzierżawą koordynacyjną, dzięki czemu dokładnie jedna replika przesuwa harmonogramy. Gdy nadchodzi termin automatyzacji, krok zapisuje wykonanie, kolejkuje trwałe zadanie automation.run.v1 i przesuwa next_run_at operacją compare-and-set, aby każde wystąpienie uruchomiło się najwyżej raz. Zadanie tworzy sesję czatu nazwaną jak automatyzacja, a następnie przekazuje instrukcję przez tę samą trwałą ścieżkę generowania, której używa każda rozmowa — wraz z routingiem dostawcy, wartościami domyślnymi persony i trwałością.

Jeśli serwer był wyłączony w chwili wystąpienia, następny krok uruchamia je raz i pomija wcześniejsze, przegapione terminy. Wstrzymanie automatyzacji czyści harmonogram; wznowienie lub edycja oblicza go ponownie od bieżącej chwili. Usunięcie automatyzacji usuwa historię wykonań przez kaskadę klucza obcego.

Wykonania są rozstrzygane z trwałego rejestru zadań: sukces po ukończeniu generowania czatu, błąd po trafieniu zadania do dead-letter, a stalled, gdy zakolejkowane wykonanie nie rozpocznie się w ciągu 30 minut.

Wykonania kierowane do Work zachowują się tak samo, ale korzystają z cyklu życia Work zamiast zadania czatu: wykonanie rejestruje utworzone zadanie (karta Runs prowadzi bezpośrednio do niego), kończy się powodzeniem po ukończeniu przez agenta — albo zatrzymaniu w celu uzyskania danych — i błędem, gdy zadanie zawiedzie lub zostanie anulowane. Wiadomość e-mail z wynikiem dla wykonania kierowanego do Work niesie podsumowanie zapisane przez samo wykonanie Work — ten sam tekst, który pokazuje historia przebiegów zadania — a gdy wykonanie pochodzi sprzed zapisywanych podsumowań, korzysta z jednowierszowego statusu zadania. Dostęp do Work jest sprawdzany w chwili uruchomienia harmonogramu, więc jego odebranie użytkownikowi wycisza również automatyzacje Work; wykonanie kończy się jako work-access-denied, a nie jest po cichu pomijane. Wybrana polityka jest sprawdzana przy zapisie automatyzacji, a jej domyślna sieć i limity zasobów obowiązują każde uruchomione zadanie. W Work działają tylko bezpośredni dostawcy modeli, a model musi obsługiwać narzędzia — tak jak w polu Work.

Procedury agentów

Automatyzacja kierowana do Work może zamiast tego połączyć się z istniejącym zadaniem Work przez workTaskId — jest to struktura sekcji Routines w panelu szczegółów agenta. Powiązana procedura nie tworzy nowego zadania przy każdym wystąpieniu: każde uruchamia wykonanie we własnym obszarze i rozmowie zadania, korzystając z jego modelu, dostawcy i polityki środowiska. Pola modelu i polityki automatyzacji nie obowiązują, a przekazana polityka jest usuwana przy zapisie. Powiązanie jest sprawdzane przy zapisie (zadanie musi istnieć i należeć do wywołującego). W chwili wykonania usunięte zadanie kończy się jako work-task-missing, a zadanie już działające — lub mające aktywny podgląd — uczciwie kończy wystąpienie jako work-task-busy zamiast ustawiać je w kolejce.

Wyzwalacze webhook

Poza harmonogramem automatyzację może uruchomić system zewnętrzny — potok CI, usługa cron, automatyka domowa. W oknie edycji automatyzacji Wyzwalacz webhook → Włącz generuje sekret dla tej automatyzacji; przechowywany jest tylko jego SHA-256, więc jawna postać pokazuje się dokładnie raz. Rotacja sekretu natychmiast unieważnia poprzedni, a wyłączenie webhooka ponownie zamyka punkt końcowy.

System zewnętrzny uruchamia automatyzację tak:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..."

(X-Libre-Webhook-Secret: lwh_... działa jako alternatywny nagłówek). Odpowiedź to 202 z identyfikatorem zakolejkowanego wykonania — ta sama ścieżka ręcznego uruchomienia co Uruchom teraz, więc wykonania kończą się, powiadamiają i trafiają do historii identycznie. Porównanie sekretu jest stałoczasowe, brakująca automatyzacja i błędny sekret odpowiadają identycznie (brak wyroczni identyfikatorów automatyzacji), a wstrzymana automatyzacja odpowiada 409: w odróżnieniu od Uruchom teraz właściciela wywołujący z zewnątrz nie przebije się przez pauzę.

Obiekt JSON w treści żądania wjeżdża do wykonania jako jego ładunek wyzwalacza, dzięki czemu procedura widzi, na co reaguje:

curl -X POST https://your-host/api/automations/<automationId>/webhook \
  -H "Authorization: Bearer lwh_..." \
  -H "Content-Type: application/json" \
  -d '{"commit":"abc123","branch":"main"}'

Ładunek jest dołączany do instrukcji wykonywanych przez wykonanie, pod nagłówkiem Trigger payload (JSON): — zarówno dla wykonań czatu, nowych zadań Work, jak i procedur powiązanych z zadaniem. Przenoszone są tylko obiekty JSON (tablice i wartości proste są ignorowane), a ładunek, którego zserializowana postać przekracza 4000 znaków, jest odrzucany zamiast przycinany, z ostrzeżeniem w dzienniku serwera. Uruchomienie bez treści zachowuje się dokładnie jak wcześniej.

API

Wszystkie punkty końcowe poza uruchomieniem webhookiem wymagają uwierzytelnienia i działają tylko na automatyzacjach wywołującego; uruchomienie webhookiem uwierzytelnia się sekretem danej automatyzacji.

Metoda	Ścieżka	Cel
GET	/api/automations	Lista automatyzacji
POST	/api/automations	Utworzenie automatyzacji
GET	/api/automations/occurrences?from=&to=	Nadchodzące obliczone wystąpienia
GET	/api/automations/runs	Historia wykonań (z filtrami)
GET	/api/automations/runs/summary	Liczba nieobejrzanych + okresy 30-dniowe
POST	/api/automations/runs/seen	Oznaczenie ukończonych wykonań jako obejrzane
GET	/api/automations/:automationId	Odczyt jednej automatyzacji
PUT	/api/automations/:automationId	Aktualizacja automatyzacji
DELETE	/api/automations/:automationId	Usunięcie automatyzacji
POST	/api/automations/:automationId/pause	Wstrzymanie harmonogramu
POST	/api/automations/:automationId/resume	Wznowienie harmonogramu
POST	/api/automations/:automationId/run	Uruchomienie teraz (202 z identyfikatorem wykonania)
POST	/api/automations/:automationId/webhook	Uruchomienie sekretem (202)
POST	/api/automations/:automationId/webhook-secret	Utworzenie lub rotacja sekretu
DELETE	/api/automations/:automationId/webhook-secret	Wyłączenie webhooka

Użytkownik może przechowywać maksymalnie 50 automatyzacji; nazwy są ograniczone do 200 znaków, a instrukcje do 20 000.