Terminal zamiast przeglądarki: nowa szkoła automatyzacji webowej

Większość narzędzi do automatyzacji stron internetowych działa tak samo – agent dostaje przeglądarkę i wykonuje w niej kolejne kliknięcia. Działa to, ale ma poważną wadę: wszystko dzieje się w jednej, długiej sesji. Gdy coś pójdzie nie tak, trudno wrócić do wcześniejszego kroku albo wykorzystać to samo rozwiązanie gdzie indziej.

Dlaczego tradycyjne podejście się nie sprawdza

Problem polega na tym, że agent jest mocno związany ze stanem przeglądarki. Każda akcja wynika z poprzedniej, a cała historia rośnie w miarę postępu zadania. To prowadzi do kilku konkretnych kłopotów:

• Zbyt dużo stanu – długie sesje zbierają błędy i nieprzewidziane sytuacje
• Trudne debugowanie – nie da się łatwo powtórzyć fragmentu zadania
• Brak ponownego użycia – każde zadanie zaczyna się od zera

Webwright: kod zostaje, przeglądarka odchodzi

Webwright działa inaczej. Zamiast utrzymywać jedną sesję przeglądarki, agent tworzy nowe instancje za każdym razem, gdy ich potrzebuje. Po zakończeniu zadania przeglądarka znika – zostaje tylko kod, logi i zrzuty ekranu zapisane w lokalnym katalogu roboczym.

To fundamentalna zmiana: przeglądarka staje się narzędziem jednorazowego użytku, a wartością jest kod, który ją obsługuje.

Trzy filary tej metody

1. Kod zamiast pojedynczych kliknięć

Zamiast budować długie sekwencje akcji przeglądarkowych, agent tworzy funkcje i pętle. Wybór daty, wypełnianie formularzy czy ekstrakcja danych stają się zwykłymi fragmentami kodu. Dzięki temu automatyzacja jest czytelniejsza i łatwiejsza do utrzymania.

2. Artefakty, które pozostają

Każde zadanie generuje trwałe wyniki: skrypty, logi, zrzuty ekranu. To właśnie one tworzą wartość – można je sprawdzić, udostępnić i wykorzystać przy kolejnych zadaniach.

3. Prosta architektura

Cały system składa się z trzech elementów: Runnera, endpointu modelu i środowiska terminalowego. Około tysiąca linii kodu, bez skomplikowanych mechanizmów orkiestracji.

Jak działa pętla

Proces jest zaskakująco prosty:

1. Runner przekazuje zadanie i aktualny stan workspace'a do modelu
2. Model odpowiada komendą bash – najczęściej skryptem Playwright
3. Środowisko wykonuje komendę i zwraca wyniki
4. Pętla powtarza się, aż agent wygeneruje finalny skrypt i przejdzie własne testy

Nie ma skomplikowanego routingu ani drzew decyzyjnych – tylko terminal, model i rosnący zbiór artefaktów.

Wyniki na żywych stronach

Testy na rzeczywistych zadaniach pokazują solidne wyniki:

• 60,8% dokładności na benchmarku Odyssey – o 35,1% lepiej niż poprzednie rozwiązania
• 86,7% dokładności na Online-Mind2Web przy limicie 100 kroków
• Nawet mniejsze modele, jak Qwen 3.5-9B, osiągają 66,2%, gdy mają dostęp do gotowych narzędzi

Bezpieczeństwo przy dostępie do terminala

Pełny dostęp do terminala to duże możliwości, ale też ryzyko. Webwright wprowadza kilka zabezpieczeń:

• Agent nie może ogłosić sukcesu, dopóki nie wygeneruje finalnego skryptu, nie uruchomi go w czystym środowisku i nie przejdzie własnej weryfikacji
• Długie historie są okresowo kompresowane do podsumowań, żeby nie przekroczyć limitów kontekstu
• Gotowe skrypty można parametryzować i udostępniać jako narzędzia CLI

Co z tego wynika dla programistów

Podejście Webwrighta daje kilka praktycznych wskazówek:

• Oddzielaj inteligencję agenta od środowiska wykonawczego
• Korzystaj z jednorazowych sesji, ale zachowuj wyniki pracy
• Buduj funkcje i pętle zamiast sekwencji prostych akcji
• Wymagaj weryfikacji przed uznaniem zadania za zakończone

Terminal przestaje być tylko interfejsem – staje się miejscem, gdzie kod i artefakty naprawdę żyją.

Szerszy kontekst

Dotychczas automatyzacja webowa polegała głównie na budowaniu coraz bardziej skomplikowanych maszyn stanów. Webwright pokazuje inną drogę: niech agent pisze kod zamiast manipulować stanem. Przeglądarka może być tymczasowa – liczy się trwałość workspace'a.

To wciąż wczesny etap, ale kierunek jest obiecujący. Jeśli budujesz systemy agentowe lub automatyzację webową, warto przyjrzeć się temu podejściu bliżej. Kod jest na GitHubie, wyniki są konkretne, a filozofia prosta: wystarczy terminal.