Agent Browser pozwala modelowi decydować, jak działać na stronie internetowej, zamiast wykonywać sztywno zaprogramowane kroki. Najważniejsze różnice dotyczą podejmowania decyzji, rozumienia strony, wykonywania działań oraz obecnych granic niezawodności.
Automatyzacja przeglądarki za pomocą skryptów jest dobrze znana: lokalizujesz elementy, zapisujesz ścieżki, dodajesz obsługę wyjątków i wszystko działa stabilnie — aż do przebudowy strony. Jeśli zmiana dotknie kluczowego miejsca, cały skrypt może wymagać przepisania, ponieważ kod rozpoznaje konkretną strukturę, a to właśnie struktura zmienia się najłatwiej.
Agent Browser przyjmuje inne podejście. Pozwala modelowi obserwować zawartość strony i decydować, co zrobić dalej. Dzięki temu jest też mniej wrażliwy na zmiany układu.
Różnica 1: kto decyduje o następnym kroku
W tradycyjnym skrypcie ścieżkę zapisuje człowiek. Gdzie kliknąć najpierw, co wpisać później i jak długo czekać, jest ustalone z góry. Podczas działania skrypt jedynie wykonuje te instrukcje.
Agent Browser przekazuje podejmowanie decyzji modelowi. Opisujesz cel, na przykład uporządkowanie w tabeli treści z danego źródła według określonych warunków. To, którą stronę otworzyć, czy najpierw filtrować, czy przechodzić między stronami oraz jak obsłużyć wyskakujące okno, jest ustalane w trakcie wykonania.
Tę różnicę łatwo zlekceważyć. Koszt utrzymania przesuwa się z pisania kodu na precyzyjne opisywanie wymagań. Trudność techniczna maleje, ale rośnie znaczenie jasnego sformułowania celu.
Różnica 2: skąd wiadomo, co znajduje się na stronie
Skrypty rozpoznają elementy za pomocą selektorów. Selektory XPath i CSS wskazują pozycję węzła w strukturze. Gdy pozycja się zmienia, selektor przestaje działać.
Agent Browser zamiast tego przekazuje modelowi informacje o strukturze strony albo zrzut ekranu. Model rozpoznaje, że jeden element jest przyciskiem logowania, drugi polem wyszukiwania, a inny obszar pokazuje cenę produktu. Bardziej opiera się na znaczeniu niż na współrzędnych.
Koszt jest jednak realny. Aby model zrozumiał stronę, trzeba przesłać strukturę DOM lub zrzuty ekranu; im bardziej złożona strona, tym więcej danych trzeba przekazać. Przy długich zadaniach może to być znaczący wydatek. Każdy krok musi też czekać na odpowiedź modelu, dlatego cały proces jest wyraźnie wolniejszy niż sztywno zakodowany skrypt.
Różnica 3: jak wykonywane są działania
Po podjęciu decyzji trzeba jeszcze naprawdę wykonać akcję. Tego typu narzędzia zwykle opakowują możliwości przeglądarki jako wywoływalne działania: otwarcie strony, kliknięcie, wypełnienie formularza, logowanie, przesłanie pliku, przewijanie lub paginacja i pobieranie danych. Model wskazuje, którą akcję wywołać i z jakimi parametrami. Przeglądarka ją wykonuje, a wynik wraca do modelu jako wejście do następnej rundy.
Na tej warstwie odbywa się także dzielenie zadania i korekta błędów. Cel jest rozbijany na kilka kroków wykonywanych po kolei. Jeśli model zauważy, że wybrał złą drogę, może spróbować innego punktu wejścia zamiast od razu zakończyć pracę błędem. Jest to szczególnie ważne na stronach o nieregularnej strukturze, gdzie skuteczność zależy w dużej mierze od sposobu odzyskiwania po pomyłce.
Co potrafi już dziś
Zadania deterministyczne i z jasno określonymi krokami mogą już działać: zbieranie publicznych informacji według warunków i przekształcanie ich w dane strukturalne; powtarzalne wprowadzanie danych i przesyłanie ich w ustalonym formacie we własnych systemach; albo monitorowanie wskazanej strony i wysyłanie powiadomień o zmianach cen, stanów magazynowych lub ogłoszeń. Te scenariusze mają wspólne cechy: ścieżka jest przewidywalna, błędy można ponawiać, a człowiek może zweryfikować wynik.
Gdzie nadal brakuje stabilności
Najłatwiej o problemy tam, gdzie potrzebne jest rozumienie semantyczne. Aby zdecydować, czy kliknąć przycisk, model musi najpierw zrozumieć jego znaczenie biznesowe. Gdy strona jest złożona albo treść jest nietypowa, pojawiają się błędy: wybór złego wejścia lub pobranie niewłaściwego pola. Im dłuższy łańcuch kroków, tym łatwiej kumulują się pomyłki. Niewielkie odchylenie na początku może być później niemożliwe do naprawienia.
Jeszcze trudniejsze są sytuacje silnie odporne na automatyzację. CAPTCHA, blokady systemów ryzyka i wygasłe sesje logowania zależą głównie od środowiska bazowego, a nie od samego modelu. Nawet bardzo dobry model nie zamieni odrzuconego żądania w zaakceptowane. Wykonanie w chmurze i proxy zarządzane przez dostawcę mogą rozwiązać część problemów, ale zwiększają koszty rozliczane według użycia i zależność od infrastruktury stron trzecich.
Na co zwrócić uwagę przy wyborze
Możliwość obserwowania i odtwarzania przebiegu jest często pomijana, ale przy problemach stanowi podstawowe narzędzie diagnostyczne. Warto też sprawdzić sposób korekty błędów: czy narzędzie zatrzymuje się, czy próbuje innej ścieżki? Należy ocenić, czy można kontrolować wybór modelu i koszty, ponieważ długie zadania często kosztują więcej, niż się zakłada. Sprawdź także integrację z własnymi narzędziami i procesami oraz sposób utrzymywania stanu logowania. Konieczność powtórzenia całej pracy po utracie sesji jest bardzo uciążliwa.
Najpierw ustal zasady użycia
To, co jest technicznie możliwe, nie jest równoznaczne z tym, co jest dozwolone. Najpierw trzeba sprawdzić, czy warunki korzystania z platformy docelowej zezwalają na automatyczny dostęp oraz czy częstotliwość żądań nie obciąży jej usług. Używanie takich narzędzi do masowego rejestrowania kont lub automatycznego wykonywania zadań platformy w zamian za korzyści narusza zasady platformy. Serwisy coraz lepiej wykrywają rytm operacji, ścieżki zachowań i spójność środowiska, a działania egzekucyjne często obejmują wiele kont naraz.
Jeśli samo zadanie jest zgodne z zasadami, ale wiele kont musi mieć odseparowane stany logowania, przydaje się izolacja środowiska. PurpleMark oferuje na przykład niezależne środowiska, dzięki czemu sesja i pamięć każdego konta nie są widoczne dla pozostałych.
Praktyczny sposób weryfikacji polega na wybraniu małego, dobrze znanego zadania z jasnymi krokami, uruchomieniu go od początku do końca, porównaniu wyniku z wykonaniem ręcznym, zapisaniu reakcji na błędy i policzeniu rzeczywistego czasu. Jeśli małe zadanie działa poprawnie, można stopniowo rozszerzać zakres. Próba automatyzacji całego procesu od pierwszego dnia zwykle kończy się utknięciem na którymś z pośrednich kroków.
