Temporal: trwałe procesy agentów AI

Otwarta platforma trwałego wykonywania długich procesów. Koordynuje zlecenie agenta przez wiele minut lub dni, także po awarii workerów. Ten tekst ocenia konkretną rolę komponentu w systemie AI-native. „Najlepszy” oznacza tu dobry wybór przy określonych wymaganiach, nie zwycięzcę w każdej firmie.

Szeroką architekturę opisuje filar Open Source AI. Źródłem opisu projektu jest dokumentacja lub repozytorium twórców. Stan funkcji i licencji należy potwierdzić dla wybranej wersji.

Czym jest i do czego służy?

Otwarta platforma trwałego wykonywania długich procesów. Koordynuje zlecenie agenta przez wiele minut lub dni, także po awarii workerów. W praktyce trzeba oddzielić rolę tej technologii od całej platformy: komponent rozwiązuje określony problem, a tożsamość, polityka danych i obserwowalność nadal wymagają własnego projektu.

Dlaczego Temporal ma szczególne znaczenie dla agentów?

Typowy agent wykonuje serię kroków: pobiera kontekst, prosi model o plan, woła narzędzie, czeka na zatwierdzenie, zapisuje wynik i informuje użytkownika. Jeśli proces kończy się po błędzie sieci, sama kolejka zadań nie mówi, które kroki już zaszły. Temporal zapisuje historię przebiegu i odtwarza logikę workflow. Dzięki temu można kontynuować proces po restarcie workera bez ręcznego sklejania stanów z logów.

Granica jest ważna: kod workflow musi być deterministyczny względem historii, a wywołanie modelu, wysłanie wiadomości i zapis do ERP powinny być aktywnościami. Ponowienie aktywności może wykonać efekt uboczny drugi raz, dlatego identyfikator operacji i idempotencja są obowiązkowe. „Exactly once” nie powstaje magicznie przez użycie platformy.

W AI SDLC przygotuj test procesu, który zatrzymuje worker po wykonaniu akcji, ale przed potwierdzeniem jej wyniku. Uruchom go ponownie i sprawdź, czy nie tworzy drugiego zamówienia. Osobno przetestuj timeout modelu, odmowę narzędzia, cofnięcie uprawnienia i oczekiwanie na człowieka. Dopiero taki test pokazuje, czy agent jest operacyjnie bezpieczny.

Problem	Najprostszy punkt startu	Kiedy Temporal ma przewagę
Jednorazowe zadanie w tle	Celery lub kolejka z workerem	Gdy zadanie przechodzi przez wiele kroków, timerów i decyzji.
Cykliczny pipeline danych	Airflow	Gdy przebieg jest związany z konkretną sprawą użytkownika, a nie harmonogramem zbioru.
Zdarzenia dla wielu konsumentów	Kafka	Gdy trzeba zachować stan jednej instancji procesu i odtworzyć jej kolejny krok.

Nie uruchamiaj jednego workflow dla każdego tokenu odpowiedzi modelu. Granicę procesu wyznacza trwała decyzja biznesowa: na przykład „obsłuż reklamację”, z krokami pobrania danych, oceny, akceptacji i zapisu. Wynik modelu powinien być artefaktem aktywności, a nie niejawnie odtwarzanym efektem ubocznym. Dla każdej akcji zapisz klucz idempotencji i osobę lub usługę, w której imieniu agent działa.

Dlaczego warto rozważyć ją w suwerennym AI OS?

Historia zdarzeń, ponawianie aktywności i trwały stan pozwalają bezpiecznie wracać do procesu po restarcie. Suwerenność oceniamy przez możliwość uruchomienia, kontrolę danych i uprawnień, przenośność formatu oraz plan zmiany dostawcy. Jeśli rozwiązanie jest usługą zarządzaną, należy jawnie wskazać granicę kontroli; otwarty klient czy API nie czynią całej usługi open source.

Jak wykorzystać ją przy kodowaniu z AI?

W AI SDLC agent kodujący może przygotować konfigurację, adapter i test integracyjny, lecz człowiek powinien sprawdzić uprawnienia, koszty oraz skutki błędu. Punktem odbioru jest działający scenariusz: koordynuje zlecenie agenta przez wiele minut lub dni, także po awarii workerów. Agent nie powinien sam zatwierdzać swojej zmiany ani otrzymywać szerszych uprawnień niż wymaga zadanie. Przed wdrożeniem warto zachować ślad: wymaganie, wersję zależności, wynik testu i osobę akceptującą.

Alternatywy i ograniczenia

Możliwe alternatywy: Celery z własnym stanem, Airflow dla batch, kolejka RabbitMQ z orkiestratorem. Aktywności z efektami ubocznymi muszą być idempotentne; replay workflow wymaga dyscypliny kodu. Wybór powinien wynikać z pomiaru na własnych danych, zgodności z obecnym zespołem i możliwości wycofania rozwiązania. Sama liczba gwiazdek repozytorium lub obietnica marketingowa nie zastępuje próby.

Co sprawdzić przed decyzją?

Zbuduj małą próbę realizującą ten przypadek: koordynuje zlecenie agenta przez wiele minut lub dni, także po awarii workerów. Zmierz opóźnienie, koszt, jakość wyniku i zachowanie po błędzie. Sprawdź też, czy inny członek zespołu potrafi odtworzyć wynik na podstawie zapisanej konfiguracji. Powiązane składniki architektury to Apache Iceberg oraz RBAC. Zapisz kryterium, po którym rozwiązanie będzie można wymienić.