Gdy automatyzacja Agentów zaczyna zawodzić przy większej skali, źródłem problemu często nie jest model ani skrypt, lecz warstwa środowiska przeglądarki. Artykuł omawia cztery częste wzorce awarii, ich obserwowalne objawy i odpowiadające im praktyki inżynierskie.
Zbudowanie Agenta w LangChain, AutoGen lub CrewAI i podłączenie go do stron internetowych przez Playwright albo Puppeteer nie jest szczególnie trudne. Trudniej sprawić, by działał stabilnie przez długi czas.
Tuż po uruchomieniu problemy zwykle nie są widoczne. Kiedy rośnie liczba zadań, anomalie zaczynają występować częściej: serwisy blokują zadania, sesje kont nagle wygasają albo kilka Agentów przeszkadza sobie nawzajem podczas równoległego działania. Pierwszym odruchem jest często przeglądanie kodu, po czym okazuje się, że z kodem wszystko jest w porządku.
Źródło problemu często znajduje się w warstwie środowiska przeglądarki. W projektach działających na większą skalę awarie zwykle przyjmują kilka powtarzalnych form. Gdy już się je rozpozna, ich obsługa nie jest szczególnie skomplikowana.
Uruchamianie zadań, zanim środowisko będzie gotowe
Jeśli nowo utworzone środowisko przeglądarki od razu wykorzystuje się do wykonania zadania, częstym skutkiem jest nieudane logowanie, niepełne wczytanie elementów strony albo żądanie weryfikacji już przy pierwszym kroku. Powód jest prosty: takie środowisko nie ma historii odwiedzin, plików cookie ani żadnego śladu przeglądania. Dla platformy wygląda jak zupełnie nieznane urządzenie, więc jego poziom zaufania jest naturalnie niski.
Obserwowalny sygnał jest taki, że awarie skupiają się na kilku pierwszych zadaniach po utworzeniu środowiska. To samo zadanie przeniesione do środowiska używanego już od pewnego czasu często kończy się poprawnie.
Właściwym podejściem jest traktowanie gotowości środowiska jako jawnego stanu, zamiast domyślnego założenia, że można go od razu użyć. Po utworzeniu środowiska warto najpierw pozwolić mu przez pewien czas wykonywać lekką aktywność przeglądania, a zadania produkcyjne przydzielać dopiero po ustabilizowaniu stanu. Harmonogram powinien sprawdzać tę gotowość przed wysłaniem zadania, zamiast natychmiast korzystać z nowego środowiska.
Kilka zadań konkuruje o to samo środowisko
Wraz ze wzrostem współbieżności najbardziej widocznym objawem jest narastająca liczba procesów, zużycie pamięci i spowolnienie systemu. Jeszcze trudniejsze są ukryte problemy: dwa zadania kolejno korzystają z tych samych plików cookie i pamięci lokalnej, stan logowania zadania A wypiera stan zadania B, a logi wyglądają tak, jakby od czasu do czasu losowo psuło się jakieś zadanie. Trudno to zlokalizować.
Środowisko przeglądarki należy w takiej sytuacji traktować jako zasób, który można przydzielić i zwolnić. Zadanie przy starcie otrzymuje jedno środowisko, a po zakończeniu je oddaje, zachowując relację jeden do jednego między zadaniem a środowiskiem. Pamięć różnych środowisk nie jest wzajemnie widoczna, więc stan logowania jednego zadania nie przenika do innego. Przy kilkudziesięciu Agentach działających równolegle różnica względem „uruchamiania wielu procesów przeglądarki wewnątrz skryptu” staje się bardzo wyraźna.
Jeżeli scenariusz obejmuje wiele kont, izolacja powinna być jeszcze pełniejsza: każde konto powinno mieć stałe środowisko, a parametry fingerprintu i pamięć nie powinny nakładać się na dane innych kont. PurpleMark zapewnia tutaj warstwę izolacji środowisk i scentralizowanego planowania, dzięki której konto i środowisko pozostają w stabilnej relacji jeden do jednego.
Wygaśnięcie sesji pozostaje niezauważone
Ten rodzaj awarii łatwo przeoczyć, ponieważ nie musi pojawić się błąd. Zadanie nadal działa i logi są generowane, ale w rzeczywistości zwracana jest strona logowania albo puste dane. Problem wychodzi na jaw dopiero po wejściu wyniku do potoku danych, a diagnostyka musi cofać się od dalszych etapów, co jest kosztowne.
Rozwiązaniem jest jawne traktowanie stanu logowania jako warunku wstępnego. Przed rozpoczęciem zadania należy sprawdzić, czy aktualna sesja jest nadal ważna. Jeśli wygasła, trzeba przeprowadzić pełny proces logowania, zamiast pozwalać zadaniu działać na nieaktualnym stanie. Sam stan powinien znajdować się w warstwie środowiska: pliki cookie, pamięć lokalna i historia przeglądania pozostają zapisane w środowisku i mogą zostać w pełni odtworzone przy ponownym uruchomieniu, dzięki czemu zadania kont nie muszą być inicjalizowane od zera za każdym razem.
Praktyczna obserwacja: w kontach używanych długoterminowo częste zmiany stanu logowania mogą same wyglądać dla platformy jak sygnał nietypowego zachowania i powodować dodatkową weryfikację. Warto więc unikać niepotrzebnych ponownych logowań.
Blokada zatrzymuje całą partię
Inny typ awarii pojawia się nagle seriami: wiele zadań jednocześnie przestaje zwracać wyniki. Serwis nie zawsze pokazuje jednoznaczne odrzucenie; częściej zwraca zubożoną treść lub pustą stronę, a Agent kontynuuje pracę na bezwartościowych danych, aż problem ujawni się dopiero na etapie przetwarzania danych.
W takiej sytuacji należy najpierw odróżnić blokadę od zwykłego błędu. Jeśli ta sama grupa środowisk zaczyna zachowywać się nieprawidłowo mniej więcej w tym samym czasie, bardzo prawdopodobne jest, że źródło problemu znajduje się w warstwie środowiska. Dalsze ponawianie tylko zwiększa zakres skutków, dlatego te środowiska należy najpierw zatrzymać i odizolować, a potem zbadać przyczynę.
Typowe wyzwalacze mieszczą się w trzech obszarach: wiele środowisk używa mocno nakładających się konfiguracji fingerprintu, na przykład niemal identycznych ustawień WebGL, Canvas, list czcionek lub wersji silnika; adres IP wyjścia, strefa czasowa i język nie pasują do siebie, na przykład amerykański IP ze strefą azjatycką; albo odstępy między działaniami są zbyt regularne i sam rytm staje się rozpoznawalną cechą. Trzeba ujednolicić konfigurację, kontrolować tempo i zapisywać zarówno stan środowiska, jak i wyniki zadań, aby dostrzegać symptomy zanim awaria obejmie całą partię.
Wydzielenie tej warstwy
Dojrzałe projekty zwykle oddzielają środowisko przeglądarki od Agenta i traktują je jako osobną warstwę: Agent odpowiada za planowanie i decyzje, warstwa środowiska za tożsamość i stan, a warstwa wykonawcza nadal opiera się na Playwright lub Puppeteer. Po takim rozdzieleniu wiadomo, gdzie zarządzać wiarygodnością tożsamości, możliwością odtworzenia stanu i izolacją zadań od siebie.
Patrząc z perspektywy, wszystkie cztery opisane typy awarii mają jedną wspólną cechę: nie znajdują się ani w modelu, ani w logice skryptu. Model i kod oczywiście nadal wymagają ulepszania, ale to, czy automatyzacja będzie działać stabilnie w długim okresie, często zależy właśnie od tej niższej warstwy.
Treść służy wymianie wiedzy z zakresu badań technicznych i praktyki programistycznej. Automatyzację należy stosować legalnie i zgodnie z zasadami, przestrzegając warunków korzystania z platformy docelowej oraz obowiązujących lokalnych przepisów prawa.
