AI Agents w produkcji: problemem jest czekanie, nie timeout

Przekształcenie długotrwałych procesów sztucznej inteligencji w synchroniczne wywołania HTTP prowadzi do awarii i strat finansowych, ponieważ złożony agent o 10 krokach o niezawodności 99% na krok osiąga zaledwie 90% szans na sukces. Badania Redis wskazują, że 97% organizacji wierzy w nadzór ludzki (HITL), ale tylko 4% wdrożyło go na produkcji. Rozwiązaniem jest zmiana architektury z obsługi żądań na trwałą egzekucję (durable execution) oraz rejestrację stanów oczekiwania.

Mechanizm awarii: dlaczego architektura oparta na HTTP niszczy procesy agentowe

Budowanie autonomicznych systemów sztucznej inteligencji w oparciu o synchroniczne architektury HTTP tworzy strukturalne ryzyko operacyjne. Klasyczne modele żądanie-odpowiedź zakładają, że cała praca zamknie się w kilkukrotnych milisekundach, podczas gdy rzeczywiste przepływy pracy agentów wymagają minut, godzin lub dni na wykonanie zadań.

Gdy krok agenta rozciąga się w czasie, infrastruktura sieciowa wymusza rozłączenie. Równoważniki obciążenia i bramy API zamykają bezczynne połączenia zazwyczaj po 60 sekundach. Zamknięcie gniazda HTTP nie zatrzymuje jednak wykonywania operacji po stronie dostawcy lub zewnętrznego API. Powstaje niebezpieczna luka wykonawcza: klient otrzymuje błąd timeoutu, podczas gdy operacja w systemie docelowym mogła zakończyć się sukcesem.

Timeout nie jest stanem systemu, lecz jedynie obserwacją braku komunikacji. Wyciągnięcie wniosku o awarii i bezmyślne powtórzenie żądania bez weryfikacji skutków ubocznych prowadzi do podwójnych obciążeń kart płatniczych lub duplikacji zgłoszeń. W złożonych ciągach wykonawczych niezawodność drastycznie spada wraz z liczbą kroków: – Przepływ 5-krokowy przy 99% niezawodności pojedynczego wywołania daje łączną sprawność 95%. – Przepływ 10-krokowy przy tych samych parametrach obniża całkowitą niezawodność do 90%. – Przepływy 50-krokowe bez stanów pośrednich zawodzą w większości prób na skutek limitów API, restartów kontenerów lub przepełnienia okna kontekstu.

Dlaczego agenci AI zacinają się w środowisku produkcyjnym?

Awarie produkcyjne w środowiskach agentowych rzadko objawiają się jawnymi błędami systemowymi czy wyjątkami w kodzie. Systemy AI najczęściej ulegają cichej degradacji, tworząc tak zwane zadania zombie, w których proces kontynuuje działanie i wysyła sygnały żywotności, lecz właściwe wnioskowanie i generowanie rezultatów zostaje całkowicie wstrzymane.

Analityka awarii produkcyjnych wyodrębnia cztery dominujące wzorce zacięć w agentach autonomicznym: 1. Pętla kompresji kontekstu (compaction loop): Pamięć podręczna przepływu ulega przepełnieniu, a logika skracania kontekstu wchodzi w nieskończoną cykliczną egzekucję. 2. Nieskończone oczekiwanie (infinite wait): Narzędzie wykonawcze zawiesza się na braku odpowiedzi sieciowej z powodu braku skonfigurowanych limitów czasowych. 3. Czarna dziura podagenta (subagent black hole): Równoległy proces potomny ulega awarii w odizolowanej sesji, a agent nadrzędny czeka w nieskończoność na sygnał zakończenia. 4. Uśpienie limitu zapytań (rate limit sleep): Algorytm wycofania (backoff) usypia wątek po napotkaniu błędu API i nie wybudza go ponownie po upływie wskazanego czasu.

Wdrożenie sztywnych limitów czasowych (wall-clock timeouts), bicia serca (checkpoint heartbeats) oraz weryfikacji plików wynikowych pozwala całkowicie wyeliminować ciche awarie. Praktyka inżynieryjna pokazuje, że wprowadzenie domyślnego limitu 60 sekund dla zewnętrznych wywołań oraz niezależnego procesu nadzorczego (watchdog) pozwoliło wychwycić 12 zaciętych zadań w ciągu 15 minut od wdrożenia, skracając średni czas realizacji z ponad 8 minut do 4,2 minuty i redukując ciche błędy do 0.

Architektura durable execution: rejestracja stanu i unikanie zbędnych kosztów LLM

Trwała egzekucja (durable execution) przesuwa odpowiedzialność za zarządzanie stanem z ulotnej pamięci podręcznej procesu na odporną na awarie warstwę orkiestracji. Wdrożenie punktów kontrolnych (checkpointing) sprawia, że restart kontenera lub skok opóźnienia API nie wymusza ponownego uruchamiania całego przepływu pracy od pierwszego kroku.

Wiodące frameworki orkiestracji agentów stosują dwa główne modele trwałej egzekucji: – Model grafowy (LangGraph): Zapisuje pełny stan w bazie po wykonaniu każdego węzła. W środowisku deweloperskim stosuje się sterownik MemorySaver, natomiast w środowiskach produkcyjnych wymagana jest baza PostgresSaver z identyfikatorem wątku thread_id. 50-krokowy graf generuje 50 trwałych stanów, co pozwala na pełną inspekcję i debugowanie czasowe (time-travel debugging). – Model odtwarzania historii zdarzeń (Temporal, Cloudflare Workflows, Inngest): Loguje wyłącznie rezultaty zewnętrznych operacji (Activities). Kod agenta pozostaje deterministyczny i w przypadku awarii odtwarza historię zdarzeń, pomijając zakończone wywołania narzędzi i odczytując ich wyniki z pamięci trwałej.

Ochrona budżetu tokenowego stanowi kluczową zaletę finansową trwałej egzekucji. Ponieważ wywołania modeli LLM są kosztowne, odczytanie zapisanego wyniku kroku z bazy danych podczas wznowienia procesu zapobiega ponownemu płaceniu za te same tokeny.

W architekturze Cloudflare Durable Objects agent istnieje w sposób ciągły jako tożsamość, ale zużywa zasoby obliczeniowe wyłącznie w momencie obsługi zdarzenia. System hibernuje obiekt przy braku aktywności przez 70–140 sekund, redukując zapotrzebowanie z 10 000 zawsze włączonych kontenerów do około 100 aktywnych instancji przy 1% wskaźniku aktywności.

Walidacja decyzji ATR i zarządzanie konfliktami w długich przebiegach

Tradycyjne mechanizmy kontroli współbieżności i wersjonowania danych traktują każdą zmianę w bazie jako naruszenie spójności wymagające unieważnienia transakcji. Algorytm ATR rozróżnia konflikt wersji od konfliktu decyzji, umożliwiając kontynuację zadania, jeśli nowa wartość zasobu nie podważa warunków formalnych uzasadniających podjęte działanie.

Gdy agent odczytuje dane i formułuje plan, a następnie czeka godzinami na zatwierdzenie przez człowieka, dane źródłowe mogą ulec zmianie. Przykładem jest zwrot kwoty 80 GBP przy limicie uprawnień 100 GBP. W czasie oczekiwania na zatwierdzenie system rejestruje modyfikacje: – Zmiana nazwy wyświetlanej klienta: Tworzy konflikt wersji, ale nie zmienia warunku zwrotu. Ocena bramki ATR: REFRESH (odświeżenie metadanych bez ponownego planowania). – Spadek limitu do 90 GBP: Warunek 80 <= 90 pozostaje spełniony. Ocena bramki ATR: KEEP (kontynuacja egzekucji). - Spadek limitu do 50 GBP lub wykonanie zwrotu przez innego pracownika: Narusza przesłanki decyzji. Ocena bramki ATR: BLOCK lub REPLAN (zablokowanie wywołania lub nakaz ponownej analizy).

W badaniach obejmujących 210 000 kontrolowanych egzekucji algorytm ATR osiągnął 0% fałszywych zezwoleń oraz 0% fałszywych blokad, sprawdzając średnio 0,6 warunku na zmianę w porównaniu do 6,0 warunków w pełnym skanowaniu (FullScan). Mediana opóźnienia walidacji w procesie wyniosła 10,8 µs (wobec 2595,9 µs dla skanowania pełnego przy 4 093 odczytach). Rozmiar zmaterializowanego grafu zależności wyniósł średnio 7,4 KiB na ślad.

Wymogi formalne nakładane przez europejskie rozporządzenie EU AI Act czynią trwały nadzór architektoniczny obowiązkowym. Artykuł 14 wymaga wdrożenia efektywnego nadzoru ludzkiego, Artykuł 12 wymusza automatyczną rejestrację zdarzeń (logging) w systemach wysokiego ryzyka, a Artykuł 26 nakłada na podmioty wdrażające obowiązek przechowywania dzienników zdarzeń. Ramy prawne NIST AI RMF jednoznacznie wskazują wzorce HITL jako podstawową strategię zarządzania ryzykiem.

Wnioski praktyczne i rekomendacje

Skonfiguruj produkcyjny magazyn stanów operacyjnych oparty o PostgresSaver w LangGraph lub wdrożenie Temporal Service zamiast ulotnych sterowników pamięciowych.

Zmierz wskaźnik utraty wywołań poprzez wprowadzenie bezwzględnego limitu czasu egzekucji ściany (wall-clock timeout) o wartości 60 sekund dla wywołań narzędzi zewnętrznych oraz monitorowanie bicia serca (heartbeat) co 10 minut.

Zweryfikuj wszystkie operacje zapisu pod kątem kluczy idempotencji zdefiniowanych jako wyliczalny hash workflow_id:step_name, co zapobiegnie podwójnym skutkom ubocznym w przypadku powtarzania kroków po awarii sieciowej.

Wdróż dwuetapowy model bramkowania akcji (bramka ATR), który rejestruje formalne przesłanki decyzji i przed wykonaniem operacji zewnętrznej sprawdza wyłącznie zmienione warunki logiczne, eliminując zbędne ponowne wywołania modeli LLM.

Źródła

• AI Agent Workflow Checkpointing and Resumability | Zylos Research
• AI Human in the Loop: Production Oversight Patterns - Redis
• DevURLs – A neat developer news aggregator
• Durable Execution: The Key to Harnessing AI Agents in Production - Inngest Blog
• From Version Conflicts to Decision Conflicts: Selective Revalidation for Long-Running AI Agents - arXiv
• How AI Agents Handle Stalled Tasks and Timeouts: Lessons From My Production Failure
• Long-running agents - Cloudflare Developer Docs
• Why Your AI Agent Times Out and How to Fix It in 10 Minutes - YouTube