Agenci AI w przeglądarce: architektura, wąskie gardła i praktyka wdrożenia

Wprowadzenie: dlaczego agenci webowi stali się głównym tematem 2026 roku

Jeszcze trzy lata temu określenie „agent AI” brzmiało jak slogan marketingowy. Dziś to narzędzie pracy, które otwiera przeglądarkę, czyta stronę, klika przyciski, wypełnia formularze i zwraca wynik. Sprawdza ceny konkurencji na marketplace, porównuje wyniki wyszukiwania w dziesięciu regionach, testuje landing page przed startem kampanii reklamowej i zbiera dane tam, gdzie nie ma i nigdy nie będzie publicznego API.

Dlaczego właśnie teraz? Zbiegły się trzy czynniki. Modele nauczyły się niezawodnie zwracać ustrukturyzowane polecenia zamiast swobodnego tekstu. Pojawiły się środowiska uruchomieniowe przeglądarek zaprojektowane pod sterowanie maszyną, a nie człowiekiem. I wreszcie biznes dojrzał: rutyna w przeglądarce kosztuje pieniądze, a zespoły mają dość pisania kruchych skryptów, które psują się przy każdej zmianie szablonu.

Ale oto co zaskakuje już przy pierwszym poważnym wdrożeniu: agent, który świetnie przechodzi demo, w produkcji wykonuje zadanie skutecznie tylko w połowie przypadków. Gubi się na dynamicznych stronach, traci na dziesięcioetapowy scenariusz kilka minut i dziesiątki tysięcy tokenów, potyka się na zabezpieczeniach przed automatyzacją i czasem robi coś zupełnie innego, niż o to poproszono. Właśnie o tych wąskich gardłach i o tym, jak je zaprojektować z wyprzedzeniem, jest ten artykuł.

Świadomie trzymamy się jednej granicy: mówimy o agentach jako klasie systemów. Nie będziemy streszczać, jak działają protokoły podłączania narzędzi ani wyszukiwanie po wektorowych bazach wiedzy — o tym w blogu są osobne materiały. Tutaj interesuje nas coś innego: jak agent AI postrzega sieć, podejmuje decyzje, działa i dlaczego na każdym z tych etapów powstają straty.

Co zyskasz po lekturze:

• Zrozumienie siedmiowarstwowej architektury agenta webowego i tego, gdzie jest w niej „cienko”.
• Cztery praktyczne metody: projektowanie postrzegania strony, zarządzanie planowaniem, budowa warstwy sieciowej na mobilnych proxy, obserwowalność i ekonomika.
• Checklisty, frameworki oceny i omówienie realnych scenariuszy z liczbami.
• Odpowiedzi na pytania, które zwykle pojawiają się w drugim tygodniu po starcie pilotażu.

Materiał jest przeznaczony dla marketerów, media buyerów, deweloperów i właścicieli firm, czyli ludzi, którzy już pracują z automatyzacją i mobilnymi proxy i chcą zrozumieć, dokąd zmierza ten zestaw narzędzi. Szczegóły techniczne będą, ale każdy z nich omówimy na zrozumiałych analogiach.

Podstawy: czym jest agent webowy i czym różni się od skryptu

Definicja bez magii

Agent AI w kontekście sieci to system programowy, który otrzymuje cel w języku naturalnym, samodzielnie dzieli go na kroki, obserwuje stan przeglądarki, wybiera następne działanie i powtarza cykl, dopóki cel nie zostanie osiągnięty albo nie wyczerpie się limit prób. Kluczowe słowo to cykl. Chatbot odpowiada raz i milczy. Skrypt do scrapingu wykonuje z góry zapisaną sekwencję i przewraca się, gdy rzeczywistość odbiega od planu. Agent natomiast żyje w pętli „obserwacja, rozumowanie, działanie” i właśnie ta pętla daje mu elastyczność i tworzy większość problemów.

Dobra analogia to stażysta w biurze. Skrypt to instrukcja na papierze: „otwórz stronę, kliknij trzeci przycisk od góry, skopiuj liczbę”. Wystarczy, że projektant przesunie przycisk, i instrukcja jest bezużyteczna. Stażysta natomiast rozumie zadanie „poznaj cenę produktu” i znajdzie cenę, nawet jeśli przycisk się przesunął. Ale stażysta jest wolniejszy, droższy, czasem się myli i trzeba go kontrolować. Dokładnie tak samo jest z agentem AI.

Trzy rodziny agentów webowych

• Agenci zorientowani na API. Sieć to dla nich zestaw punktów końcowych. Nie otwierają przeglądarki, tylko wywołują usługi bezpośrednio. Szybko, tanio, ale działa tylko tam, gdzie API istnieje i jego warunki pozwalają na takie użycie.
• Agenci DOM. Sterują prawdziwą przeglądarką przez narzędzia automatyzacji, czytają strukturę strony (drzewo elementów, drzewo dostępności), klikają po selektorach. To koń roboczy większości zadań biznesowych.
• Agenci wizualni (computer use). Patrzą na zrzut ekranu jak człowiek i działają współrzędnymi myszy. Uniwersalni, działają nawet z canvasem i niestandardowymi widgetami, ale najdrożsi i najwolniejsi.

W praktyce dojrzałe systemy są hybrydowe: agent czyta drzewo elementów, a po zrzut ekranu sięga tylko wtedy, gdy reprezentacja tekstowa nie wystarcza.

Poziomy autonomii

Warto myśleć o tym jak o drabinie podobnej do poziomów autopilota w samochodzie:

1. Wspomagany. Człowiek prowadzi, agent podpowiada następny krok.
2. Półautonomiczny. Agent wykonuje łańcuch, ale zatrzymuje się przed nieodwracalnymi działaniami: płatność, wysłanie formularza, usunięcie.
3. Autonomiczny w ramach scenariusza. Agent pracuje bez interwencji w wyznaczonych granicach i na liście dozwolonych domen.
4. Autonomiczny z delegowaniem. Agent sam tworzy podzadania i podagentów. Poziom, na którym dziś żyją głównie systemy badawcze i bardzo dojrzałe zespoły.

Praktyczna rada na start: większość zadań biznesowych w marketingu i analityce komfortowo rozwiązuje się na drugim i trzecim poziomie. Nie trzeba dążyć do czwartego dla samego piękna — każdy wyższy poziom podwaja złożoność kontroli.

Czym sieć jest zła jako środowisko dla agenta

Sieć powstała dla ludzi. Strony są nadmiarowe: jedna karta produktu na marketplace może ważyć setki kilobajtów znaczników, przy danych użytecznych w kilku linijkach. Interfejsy są dynamiczne: treść doładowuje się po przewinięciu, okna modalne zasłaniają przyciski, stan zmienia się bez przeładowania. A do tego sieć jest wroga automatyzacji: strony bronią się przed obciążeniem i nadużyciami, ustanawiają limity i sprawdzają, czy klient wygląda jak zwykły użytkownik. Każdy z tych czynników zamienia się w wąskie gardło i dalej omówimy je warstwa po warstwie.

Głębokie zanurzenie: siedem warstw architektury i ich wąskie gardła

Rozłóżmy typowego przeglądarkowego agenta AI na warstwy. To nie jedyny możliwy schemat, ale wygodny, bo każdej warstwie odpowiada własna klasa problemów i własny zestaw rozwiązań.

Warstwa 1. Postawienie zadania i kontrakt wyniku

Tutaj cel człowieka zamienia się w specyfikację: co uznać za sukces, w jakim formacie zwrócić dane, jakie domeny są dozwolone, jakie działania są zabronione. Wąskie gardło to mgliste sformułowanie. „Zbierz ceny konkurencji” to nie zadanie. „Dla 40 SKU z tabeli pobierz aktualną cenę i dostępność z dwóch wskazanych platform, zwróć JSON z polami i znacznikiem czasu, przy braku produktu zwróć wyraźny status” — to zadanie.

Warstwa 2. Planista i orkiestrator

Planista dzieli cel na podcele, śledzi stan wykonania, decyduje, kiedy powtórzyć krok, kiedy się wycofać, kiedy wezwać człowieka. Tu są dwa bieguny architektoniczne. Agent reaktywny na każdym kroku pyta model „co dalej”, patrząc na bieżący stan. Elastyczny, ale drogi i skłonny do zapętleń. Agent planująco-wykonawczy najpierw buduje plan, potem wykonuje go deterministycznie, sięgając do modelu tylko przy odchyleniach. Tańszy i przewidywalny, ale plan może się zestarzeć na trzecim kroku. Dojrzałe systemy łączą jedno z drugim: plan jako szkielet, reaktywne wstawki przy awariach.

Warstwa 3. Model

Model językowy lub multimodalny to mózg systemu. Wąskie gardła są oczywiste: okno kontekstowe, koszt tokenów, opóźnienie odpowiedzi, halucynacje. Mniej oczywiste jest coś innego: różne kroki wymagają różnych modeli. Wyciągnięcie liczby z czystego tekstu potrafi mały szybki model. Rozgryzienie, dlaczego formularz się nie wysyła, to zadanie dla flagowca. Routing zapytań między modelami według złożoności kroku daje oszczędności rzędu wielokrotności i do tego jeszcze wrócimy.

Warstwa 4. Postrzeganie

Ta warstwa odpowiada na pytanie „co agent widzi”. Warianty: surowy HTML, oczyszczony HTML, drzewo dostępności (accessibility tree), zrzut ekranu, hybryda. Właśnie tutaj spala się większość tokenów. Strona sklepu internetowego w surowej formie to 100–300 tysięcy tokenów, co albo nie mieści się w kontekście, albo kosztuje jak nieduży obiad. Jakościowa kompresja postrzegania to główna dźwignia optymalizacji i poświęcimy jej osobny rozdział poniżej.

Warstwa 5. Działania i narzędzia

Zestaw prymitywów: przejdź pod adres, kliknij, wpisz tekst, przewiń, poczekaj na element, wyciągnij dane, zwróć wynik. Im mniejszy i czystszy zestaw, tym rzadziej model myli się w wyborze. Wąskie gardło to „hojność” deweloperów: dają agentowi czterdzieści narzędzi i on zaczyna się gubić. Drugie wąskie gardło to semantyka oczekiwania. Kliknąć łatwo; zrozumieć, że strona naprawdę się odświeżyła, a nie pokazuje starej treści z kręcącym się wskaźnikiem ładowania — trudniej.

Warstwa 6. Środowisko uruchomieniowe przeglądarki

Gdzie żyje sama przeglądarka: maszyna lokalna, kontener, chmurowa usługa zdalnych przeglądarek. Tu rozstrzygają się kwestie izolacji sesji, zachowania cookies i lokalnego magazynu między krokami, równoległości, zużycia pamięci. Jedna instancja przeglądarki z otwartymi kartami łatwo zjada gigabajt pamięci; sto równoległych agentów wymaga poważnego planowania infrastruktury.

Warstwa 7. Warstwa sieciowa i tożsamość sesji

Z jakiego adresu agent wychodzi do sieci, z jakiego regionu, jak często i z jakimi nagłówkami. Dla marketerów i media buyerów to najbardziej praktycznie ważna warstwa: wyniki regionalne, lokalne ceny, wyświetlanie reklam, regionalne wersje stron — wszystko zależy od punktu wyjścia. Tu też żyją limity zapytań i systemy ochrony przed automatyzacją. Właśnie na tym poziomie mobilne proxy stają się komponentem infrastruktury, a nie opcją, i temu będzie poświęcony osobny praktyczny rozdział.

Komponenty przekrojowe: pamięć i obserwowalność

Ponad warstwami leżą dwie usługi przekrojowe. Pamięć przechowuje kontekst zadania, wyniki pośrednie, historię działań i wyuczone cechy stron („na tej domenie filtry stosują się tylko po naciśnięciu przycisku”). Obserwowalność to logi, ślady każdego kroku, zrzuty ekranu w momentach decyzji, metryki kosztu i czasu. Bez obserwowalności agent to czarna skrzynka, a debugowanie zamienia się w zgadywanie.

Mapa wąskich gardeł

Zbierzmy w jedno, gdzie dokładnie tracą się pieniądze, czas i niezawodność:

• Tokeny i kontekst — nadmierne postrzeganie stron, rozdęta historia kroków.
• Opóźnienie — każdy krok to sieć plus model plus renderowanie; dziesięć kroków łatwo zamienia się w dwie minuty.
• Niedeterminizm — ten sam scenariusz przechodzi różnie w różnych uruchomieniach.
• Kruchość — zmiana szablonu, wyskakujące okna, regionalne różnice interfejsu.
• Ochrona przed automatyzacją i limity — strony ograniczają częstotliwość i sprawdzają klienta.
• Bezpieczeństwo — strona może zawierać instrukcje, które model omyłkowo przyjmie za polecenia (wstrzyknięcie przez treść).
• Koszt — suma wszystkiego powyższego pomnożona przez liczbę zadań.

Każdy z czterech kolejnych praktycznych rozdziałów zamyka jedną lub kilka pozycji z tej listy.

Metoda 1. Projektowanie postrzegania: co dokładnie agent powinien widzieć

Zacznijmy od najdroższej warstwy. Wyobraź sobie, że prosisz kolegę o sprawdzenie ceny na stronie, a zamiast linku wysyłasz mu wydruk surowego kodu strony na 200 kartkach. Mniej więcej tak czuje się model, który dostaje surowy HTML. Zadaniem metody jest zamiana strony w kompaktową, ale wystarczającą reprezentację.

Trzy formaty i ich cena

• Oczyszczony HTML. Usuwamy skrypty, style, niewidoczne elementy, atrybuty techniczne. Kompresja 5–10 razy. Zachowuje strukturę, ale pozostaje wielosłowny.
• Drzewo dostępności. Przeglądarka sama buduje semantyczne drzewo dla czytników ekranu: rola elementu (przycisk, link, pole), nazwa, stan. Kompresja 20–50 razy względem HTML. Właśnie w tym formacie współczesne frameworki najczęściej pokazują stronę agentowi. Każdemu interaktywnemu elementowi nadaje się krótki identyfikator liczbowy, a model mówi „kliknij 17”, a nie „kliknij przycisk z klasą btn-primary wewnątrz trzeciego diva”.
• Zrzut ekranu. Jedna klatka kosztuje mniej więcej jak tysiąc–dwa tysiące tokenów tekstu, ale niesie kontekst wizualny: rozmieszczenie, kolor, co zasłania okno modalne. Niezbędny dla interfejsów na canvasie i kapryśnych widgetów.

Praktyczna zasada: tryb podstawowy — drzewo dostępności z identyfikatorami, zrzut ekranu włącza się na wyzwalacz (działanie nie przyniosło oczekiwanego wyniku dwa razy z rzędu albo element nie został znaleziony).

Krok po kroku: konfiguracja warstwy postrzegania

1. Określ docelowe encje. Dla każdego typu zadania wypisz, jakie pola agent naprawdę potrzebuje: cena, dostępność, tytuł, data. Wszystko inne to szum.
2. Wprowadź filtrowanie widoczności. Przekazuj tylko elementy w obszarze widoczności i tuż poza nim. Strona długa na dwadzieścia ekranów nie powinna trafiać do kontekstu w całości.
3. Normalizuj tekst. Zwężaj spacje, obcinaj powtarzające się bloki (menu, stopki) po pierwszym pokazaniu w sesji.
4. Dodaj delty. Po działaniu przekazuj modelowi nie całą stronę, a zmiany względem poprzedniego stanu. To skraca historię wielokrotnie.
5. Ustaw limit kontekstu historii. Przechowuj pełne obserwacje tylko dla ostatnich dwóch–trzech kroków, starsze zastępuj krótkimi streszczeniami „krok 4: zastosowałem filtr po cenie, wynik udany”.
6. Załóż słownik strony. Jeśli agent regularnie pracuje z jedną domeną, zapisuj opisy trwałych elementów i charakterystycznych pułapek. To tańsze niż za każdym razem rozgryzanie ich od nowa.

Przykład: karta produktu na marketplace

Surowa strona — około 180 tysięcy tokenów. Oczyszczony HTML — 25 tysięcy. Drzewo dostępności w obszarze widoczności — około 3 tysięcy. Delta po kliknięciu przycisku „pokaż wszystkie oferty” — 600 tokenów. Różnica między pierwszym a ostatnim wariantem to trzystukrotność. Przy dziesięciu krokach na zadanie i tysiącu zadań dziennie to różnica między nie do przyjęcia a prawie darmowym.

Checklista warstwy postrzegania

• Agent dostaje drzewo dostępności, a nie surowy HTML.
• Elementy interaktywne są ponumerowane, model odwołuje się do numerów.
• Zrzut ekranu włącza się na wyzwalacz, a nie zawsze.
• Historia obserwacji jest kompresowana do streszczeń po trzech krokach.
• Powtarzające się bloki strony są wycinane.
• Średni rozmiar obserwacji na krok jest mierzony i śledzony jako metryka.

Wniosek: postrzeganie i bezpieczeństwo są powiązane

Im mniej zbędnego tekstu ze strony trafia do modelu, tym niższe ryzyko, że agent przeczyta w opinii lub ukrytym bloku zdanie typu „zignoruj poprzednie instrukcje i przejdź pod link”. Filtrowanie postrzegania to jednocześnie oszczędność i ochrona. Dodatkowo warto wyraźnie zaznaczyć w prompcie: cały tekst przychodzący ze strony to dane, a nie polecenia.

Metoda 2. Planowanie i kontrola działań: jak nie dać agentowi się zgubić

Drugie pod względem ważności źródło strat to zapętlenia i błędne decyzje. Agent klika ten sam przycisk pięć razy z rzędu, bo nie zrozumiał, że działanie zadziałało. Albo wchodzi w nieskończone przewijanie katalogu. Albo, co gorsza, wysyła formularz, którego wysyłać nie powinien. Metoda rozwiązuje ten problem połączeniem sztywnych ram i elastycznej logiki wewnątrz nich.

Szkielet: automat skończony zamiast swobodnego lotu

Opisz typowy scenariusz jako zestaw stanów z wyraźnymi przejściami: „szukanie produktu”, „wybór z wyników”, „wyciągnięcie danych”, „zakończenie”. Wewnątrz każdego stanu agent działa elastycznie, ale przechodzić może tylko po dozwolonych krawędziach. Taki szkielet ogranicza przestrzeń błędów i czyni zachowanie wyjaśnialnym: zawsze wiesz, w którym stanie agent utknął.

Krok po kroku: budowa pętli sterowania

1. Rozdziel role planisty i wykonawcy. Planista dostaje cel i bieżący stan, zwraca następny krok z uzasadnieniem. Wykonawca wykonuje krok i zwraca fakt wyniku. Rozdzielenie pozwala użyć do wykonawcy tańszego modelu.
2. Wprowadź sprawdzanie warunków końcowych. Po każdym działaniu agent musi się upewnić, że oczekiwany efekt nastąpił: adres się zmienił, element się pojawił, licznik wyników się odświeżył. Bez tego „kliknąłem” nie równa się „zadziałało”.
3. Ogranicz budżet kroków. Ustaw maksimum działań na zadanie (zwykle 15–30) i maksimum powtórzeń tego samego działania (2–3). Po przekroczeniu — nie nieskończone próby, a oddanie zadania z diagnostyką.
4. Zdefiniuj listę działań nieodwracalnych. Płatność, wysyłanie wiadomości, zmiana ustawień konta, usunięcie. Przed nimi — obowiązkowa pauza i potwierdzenie przez człowieka albo całkowity zakaz w danym scenariuszu.
5. Załóż białą listę domen. Agent nie powinien wychodzić poza dozwolone strony, nawet jeśli na stronie jest kuszący link.
6. Dodaj mechanizm refleksji przy awarii. Jeśli dwa działania z rzędu nie dały wyniku, agent przechodzi w tryb diagnostyki: robi zrzut ekranu, opisuje, co widzi, i planuje od nowa. To droższe niż zwykły krok, ale tańsze niż dziesięć bezsensownych kliknięć.
7. Przemyśl punkty wznowienia. Długie scenariusze muszą umieć kontynuować się po awarii przeglądarki lub sieci z zapisanego stanu, a nie od zera.

Przykład: porównanie wyników w kilku regionach

Zadanie marketera: sprawdzić, jak wygląda top wyników dla dziesięciu zapytań w pięciu regionach. Naiwny agent otwiera wyszukiwarkę i sprawdza po kolei wszystko — pięćdziesiąt cykli, każdy z błędami. Podejście szkieletowe: stan „ustaw kontekst regionalny” (przez odpowiednie proxy i ustawienia), stan „wykonaj zapytanie”, stan „wyciągnij pozycje”, stan „waliduj” (dziesięć pozycji, każda z adresem i tytułem). Przy nieprawidłowym wyniku — jedno powtórzenie, potem znacznik „wymaga ręcznej weryfikacji”. Planowanie sprowadza się do przejścia po macierzy, model włącza się tylko przy wyciąganiu i walidacji. Koszt spada o rząd wielkości, a przewidywalność rośnie.

Framework oceny gotowości pętli sterowania

• Czy jest wyraźna lista stanów i przejść?
• Czy wynik każdego działania jest sprawdzany?
• Czy ustawiono budżet kroków i powtórzeń?
• Czy wymieniono działania nieodwracalne i jak są zabezpieczone?
• Czy istnieje biała lista domen?
• Co robi agent, gdy nie rozumie, co się dzieje?
• Czy można wznowić zadanie od środka?

Jeśli choć na dwa pytania odpowiedź brzmi „nie”, agent nie jest jeszcze gotowy do pracy bez nadzoru.

Wniosek: najlepszy agent to ten, który rzadko myśli

Paradoksalnie dojrzałość systemu mierzy się tym, jak rzadko sięga do modelu. Wszystko, co da się zrobić deterministycznie — przejścia, oczekiwania, walidację według schematu — powinien robić kod. Model jest potrzebny tam, gdzie rzeczywistość jest nieprzewidywalna: interpretacja niestandardowej strony, wybór między podobnymi elementami, odzyskiwanie po awarii. Taki agent AI jest tańszy, szybszy i, co ważniejsze, bardziej wyjaśnialny.

Metoda 3. Warstwa sieciowa i tożsamość sesji: rola mobilnych proxy

Teraz o warstwie, którą deweloperzy najczęściej niedoceniają, a marketerzy przeceniają. Deweloper myśli: „Podłączyłem proxy — i gotowe”. Marketer myśli: „Proxy rozwiąże wszystkie problemy”. Prawda jest pośrodku: warstwa sieciowa decyduje, co agent zobaczy i jak długo będzie mógł pracować, ale wymaga takiej samej inżynierskiej staranności jak pozostałe.

Po co agentowi w ogóle sterowalna warstwa sieciowa

• Kontekst regionalny. Ceny, asortyment, język interfejsu, wyniki wyszukiwarek, pokazywane reklamy — wszystko to zależy od punktu wyjścia. Agent sprawdzający kreacje media buyera albo lokalne ceny musi wychodzić z właściwego regionu, inaczej dane są bezużyteczne.
• Rozłożenie obciążenia. Setka równoległych agentów z jednego adresu wygląda jak anomalia i tworzy nienormalne obciążenie strony. Rozłożenie po puli adresów to i poprawne zachowanie wobec zasobu, i stabilność twojej pracy.
• Izolacja sesji. Różne zadania i różne konta, z którymi legalnie pracujesz, nie powinny przecinać się kontekstem sieciowym.
• Odporność. Awaria sieci i degradacja jednego kanału nie powinny zatrzymywać całego potoku.

Dlaczego właśnie mobilne proxy

Mobilne proxy kierują ruch przez sieci operatorów komórkowych. Mają właściwość, która czyni je naturalnym wyborem dla agentów: adresy operatorów są używane jednocześnie przez ogromną liczbę realnych abonentów i stale się zmieniają przy ponownym połączeniu. Dla strony taki ruch jest nieodróżnialny od ruchu zwykłych użytkowników mobilnego internetu w danym regionie, a to dokładnie to, czego potrzebujesz, gdy celem agenta jest zobaczyć stronę oczami zwykłego odwiedzającego. Adresy centrów danych, przeciwnie, rzadko kojarzą się z żywymi ludźmi, a systemy ochrony odnoszą się do nich surowiej, stosując ostrzejsze limity częstotliwości zapytań.

Jest i druga zaleta, specyficzna dla mobilnej publiczności: ogromna część zakupów i kliknięć w reklamy odbywa się ze smartfonów. Agent, który sprawdza mobilną wersję landing page’a, mobilne wyniki albo mobilną aplikację marketplace’u przez interfejs webowy, musi i po sieci wyglądać jak klient mobilny. Mobilne proxy plus mobilny profil przeglądarki dają spójny obraz.

Zasada spójności tożsamości

Główny błąd warstwy sieciowej to niespójność. Agent wychodzi z jednego regionu po sieci, ale strefa czasowa przeglądarki odpowiada innemu, język interfejsu trzeciemu, a rozdzielczość ekranu — monitorowi stacjonarnemu przy mobilnym adresie. Takie sprzeczności strony zauważają i reagują zwiększoną uwagą: częściej pokazują weryfikacje, ograniczają funkcjonalność, oddają okrojoną wersję. Zadaniem architekta jest zbudowanie profilu sesji, w którym wszystkie parametry są spójne: region adresu, strefa czasowa, język, typ urządzenia, rozmiar ekranu. I ten profil musi być stabilny przez całe zadanie.

Krok po kroku: konfiguracja warstwy sieciowej

1. Określ macierz regionów. Dla których krajów i miast potrzebujesz danych. Pod każdy punkt — osobny kanał mobilnego proxy.
2. Przypisz kanał do profilu przeglądarki. Jeden kontekst przeglądarki, jeden kanał, jedno zadanie. Nie mieszaj.
3. Ustaw politykę rotacji adresu. Są dwa tryby: utrzymywać adres przez czas zadania (potrzebne przy sesjach z autoryzacją i wieloetapowych scenariuszach) i zmieniać adres między zadaniami (potrzebne przy zbieraniu publicznych danych z rozłożeniem obciążenia). Dobry serwis mobilnych proxy daje sterowanie rotacją przez API i według harmonogramu.
4. Ustaw limity częstotliwości. Agent musi szanować stronę: pauzy między zapytaniami odpowiadające zachowaniu człowieka, ograniczenie równoległych sesji na jedną domenę. To nie tylko etyka, ale i praktyczność — strony, które przeciążasz, zaczynają zwracać błędy właśnie tobie.
5. Przestrzegaj zasad zasobów. Sprawdzaj plik robots i warunki korzystania ze stron, z którymi pracujesz. Publiczne informacje do monitoringu cen i wyników to jedno; działania w kontach to drugie i muszą być wykonywane tylko w ramach twoich praw do tych kont.
6. Zbuduj kontrolę kondycji kanału. Przed zadaniem agent robi zapytanie kontrolne: adres odpowiada, region się zgadza, opóźnienie jest akceptowalne. Niezdrowy kanał jest automatycznie wykluczany z puli.
7. Loguj kontekst sieciowy każdego zadania. Który kanał, który adres, który region, jakie odpowiedzi serwera. Bez tego nie odróżnisz błędu modelu od błędu sieci.

Przykład konfiguracji profilu sesji

{ "task_id": "price-monitor-ru-msk-042", "proxy_channel": "mobile-ru-msk-03", "rotation": "hold_until_task_end", "browser_profile": { "device": "mobile", "locale": "ru-RU", "timezone": "Europe/Moscow", "viewport": "390x844" }, "rate_limit": { "min_delay_ms": 1800, "max_parallel_per_domain": 2 } }

Zwróć uwagę: region kanału, locale, strefa czasowa i typ urządzenia są spójne. To jest właśnie ta niesprzeczna tożsamość.

Wąskie gardło: koszt ruchu

Ruch mobilny jest droższy niż z centrów danych, a przeglądarka ciągnie obrazki, czcionki, skrypty analityczne. Agentowi większość z tego nie jest potrzebna. Blokuj ładowanie mediów i zewnętrznych trackerów na poziomie przeglądarki, jeśli nie wpływa to na funkcjonalność strony. Oszczędność ruchu 60–80 procent to typowy wynik. Wyjątek — agenci wizualni, którym potrzebny jest pełny obraz; dla nich wybieraj, które zadania naprawdę wymagają zrzutów ekranu.

Checklista warstwy sieciowej

• Każde zadanie wychodzi przez jeden kanał mobilnego proxy właściwego regionu.
• Parametry przeglądarki są spójne z regionem i typem urządzenia kanału.
• Polityka rotacji jest wybrana świadomie pod typ zadania.
• Są limity częstotliwości i równoległości na domenę.
• Uwzględniono zasady korzystania z docelowych zasobów.
• Kanał jest sprawdzany przed zadaniem i wykluczany przy degradacji.
• Zbędny ruch mediów jest wyłączony.
• Kontekst sieciowy jest zapisywany w logu każdego zadania.

Metoda 4. Obserwowalność i ekonomika: jak mierzyć i potanieć

Agent bez metryk to jak kampania reklamowa bez analityki: pieniądze uciekają, a nie wiadomo gdzie. Ta metoda mówi o tym, co mierzyć, jak debugować i gdzie szukać oszczędności.

Pięć kluczowych metryk agenta webowego

• Odsetek udanych zadań. Przy czym „sukces” musi być sprawdzany automatycznie według schematu wyniku, a nie według samoopisu agenta. Agenci mają skłonność do optymistycznego ogłaszania sukcesu.
• Liczba kroków na zadanie. Rośnie — znaczy, agent zaczął błądzić; porównuj z trajektorią wzorcową.
• Koszt zadania. Tokeny modelu plus ruch plus czas środowiska uruchomieniowego. Licz w pieniądzach, a nie w tokenach — tak jest zrozumiałej dla biznesu.
• Czas zadania. Mediana i 95. percentyl. Ogon rozkładu zwykle wskazuje na zapętlenia.
• Przyczyny niepowodzeń według kategorii. Sieć, ochrona strony, błąd modelu, zmiana szablonu, timeout. Bez kategoryzacji nie wiesz, którą warstwę leczyć.

Ślad zadania jako jednostka debugowania

Każde zadanie powinno zostawiać ślad: sekwencję kroków, dla każdego — obserwację (w formie skompresowanej), decyzję modelu z uzasadnieniem, działanie, wynik sprawdzenia warunku końcowego, zrzut ekranu w momencie decyzji. Taki ślad pozwala w minutę zrozumieć, gdzie dokładnie coś poszło nie tak. Przechowywanie śladów wszystkich zadań jest drogie; przechowuj w pełni dla nieudanych i wybiórczo dla udanych.

Krok po kroku: budowa ekonomicznego agenta

1. Zmierz koszt bazowy. Uruchom sto typowych zadań i policz średni koszt i rozkład. Bez bazy nie ma optymalizacji.
2. Znajdź najdroższą warstwę. Zwykle to postrzeganie (60–80 procent tokenów). Zastosuj metodę 1.
3. Wprowadź routing modeli. Wyciąganie danych według schematu, sprawdzanie warunków końcowych, proste wybory — tani model. Planowanie, odzyskiwanie po awarii — drogi. Typowy rozkład w dojrzałym systemie: 70–85 procent wywołań idzie do taniego modelu.
4. Keszuj to, co stabilne. Instrukcje systemowe, opis narzędzi, słowniki stron — wszystko to można keszować po stronie dostawcy modelu, oszczędzając na ponownej obróbce.
5. Zastąp model kodem tam, gdzie trajektoria się ustabilizowała. Jeśli agent sto razy przeszedł tę samą stronę tą samą drogą, zapisz tę drogę jako deterministyczny scenariusz ze sprawdzeniami, a model zostaw tylko do obsługi odchyleń. To się nazywa kompilacja trajektorii i jest najpotężniejszym źródłem oszczędności w dojrzałych scenariuszach.
6. Wprowadź budżety. Limit kosztu na zadanie i na dzień z automatycznym zatrzymaniem. Agenci, którzy weszli w pętlę, potrafią spalić tygodniowy budżet w godzinę.

Orientacyjne liczby

Według naszych obserwacji typowych zadań monitoringu i sprawdzania, naiwny agent na flagowym modelu z surowym HTML wydaje na dziesięcioetapowe zadanie kwotę równowartą kilku kawom i robi to w dwie–trzy minuty. Po zastosowaniu czterech metod to samo zadanie kosztuje 20–50 razy mniej i wykonuje się w 20–40 sekund, a odsetek sukcesu rośnie z 50–60 do 85–95 procent. Rozrzut jest duży, bo zależy od stron, ale rząd wielkości jest stabilny. Publiczne benchmarki autonomicznych agentów webowych pokazują podobny obraz: najlepsze systemy rozwiązują około dwóch trzecich zadań, średnie — połowę, a różnicę wyznacza nie tyle model, ile inżynieria wokół niego.

Checklista obserwowalności

• Sukces zadania jest sprawdzany automatycznie według schematu.
• Pięć metryk jest zbieranych i widocznych na panelu.
• Niepowodzenia są skategoryzowane według warstw.
• Ślady nieudanych zadań są przechowywane w całości.
• Są budżety na zadanie i na dzień.
• Jest zestaw regresyjny zadań uruchamiany przy każdej zmianie promptów, modeli lub narzędzi.

Typowe błędy przy budowie agentów webowych

Zbierzmy pułapki, w które wpada niemal każdy zespół. Część z nich już wspominaliśmy, ale powtórzenie jest tu uzasadnione: właśnie te błędy zjadają miesiące.

Błąd 1. Zaczynanie od pełnej autonomii

Zespół od razu buduje agenta czwartego poziomu, który sam tworzy podzadania. Wynik — nieprzewidywalne zachowanie i niemożność debugowania. Zacznij od trybu półautonomicznego z człowiekiem w pętli, zbieraj ślady, stabilizuj, potem zwiększaj autonomię.

Błąd 2. Zaufanie samoopisowi agenta

Agent zwraca „zadanie wykonane pomyślnie”, a dane w wyniku są puste albo nieaktualne. Sprawdzanie sukcesu musi być zewnętrzne i formalne: schemat wyniku, zakresy wartości, obowiązkowe pola.

Błąd 3. Karmienie modelu surową stroną

Najdroższy błąd w dosłownym sensie. Obniża też jakość: w szumie model gorzej znajduje to, co potrzebne.

Błąd 4. Jeden adres na wszystkie zadania

Setka równoległych sesji z jednego adresu centrum danych — gwarantowane ograniczenia ze strony witryn i zniekształcone dane. Warstwę sieciową trzeba projektować, a nie podłączać po resztkowym zasadzie.

Błąd 5. Niespójna tożsamość sesji

Mobilny adres regionu A, przeglądarka stacjonarna ze strefą czasową regionu B i językiem regionu C. Takie sesje dostają okrojone doświadczenie i częste weryfikacje.

Błąd 6. Zbyt wiele narzędzi

Czterdzieści dostępnych działań zamiast ośmiu. Model dłużej myśli, częściej myli się w wyborze, a prompt się rozdyma. Minimalny zestaw prymitywów plus kilka złożonych działań pod konkretny scenariusz — optimum.

Błąd 7. Brak budżetów

Agent, który w nocy wpadł w pętlę, do rana spala miesięczny limit na model i ruch. Twarde budżety to nie opcja.

Błąd 8. Ignorowanie zasad zasobów

Praca ze stronami musi pozostać w ramach ich warunków korzystania i przepisów prawa. Agent to twój przedstawiciel w sieci, a jego zachowanie to twoja odpowiedzialność. Publiczne dane do analityki, działania na własnych kontach, szacunek dla limitów — tak. Wszystko inne — nie.

Błąd 9. Brak rozróżniania typów niepowodzeń

„Nie udało się” to nie diagnoza. Błąd sieci leczy się na jednej warstwie, zmiana szablonu — na drugiej, halucynacja — na trzeciej. Bez kategoryzacji zespół naprawia nie to.

Błąd 10. Brak ochrony przed wstrzyknięciami przez treść

Strona to niezaufane źródło. Tekst na niej może zawierać instrukcje, które model odbierze jako polecenia. Filtrowanie postrzegania, wyraźne rozdzielenie danych i poleceń w prompcie, biała lista domen i zakaz nieodwracalnych działań bez potwierdzenia — obowiązkowe minimum.

Błąd 11. Brak zestawu regresyjnego

Zmieniliście prompt — na jednej stronie lepiej, na pięciu innych gorzej, ale dowiedzieliście się o tym po tygodniu. Zestaw 30–50 zadań wzorcowych z automatycznym sprawdzaniem wyniku, uruchamiany przy każdej zmianie, ratuje przed tym.

Narzędzia i zasoby do budowy agentów webowych

Ekosystem zmienia się szybko, więc zamiast konkretnych wersji damy mapę kategorii i to, na co patrzeć przy wyborze.

Sterowanie przeglądarką

• Playwright — faktyczny standard dla nowych projektów: wsparcie wszystkich głównych przeglądarek, izolacja kontekstów, wbudowane oczekiwanie na elementy, dostęp do drzewa dostępności. Większość frameworków agentowych jest zbudowana właśnie na nim.
• Puppeteer — historyczny poprzednik dla jednej rodziny przeglądarek, wciąż szeroko używany.
• Selenium — weteran, aktualny tam, gdzie istnieje już duża infrastruktura testowa.

Frameworki agentowe dla przeglądarki

• Biblioteki, które zamieniają przeglądarkę w zestaw narzędzi dla modelu i realizują cykl obserwacji i działania: otwarte projekty z rodziny browser-use, Stagehand i podobne. One już robią kompresję strony do drzewa z identyfikatorami, więc metodę 1 w podstawowej formie dostajesz od razu.
• Orkiestratory ogólnego przeznaczenia ze wsparciem grafów stanów: LangGraph i podobne. Przydatne do realizacji szkieletu z metody 2.
• Oficjalne zestawy deweloperskie agentów od dostawców modeli z trybem sterowania komputerem. Dają agenta wizualnego „pod klucz”, ale wymagają szczególnej uwagi na koszt.

Środowiska uruchomieniowe przeglądarek

• Chmurowe usługi zdalnych przeglądarek z zachowywaniem sesji, nagrywaniem i równoległością. Zdejmują ból głowy z infrastrukturą, ale sprawdź, czy pozwalają podłączyć twoje proxy na poziomie kontekstu przeglądarki — to krytyczne dla metody 3.
• Własne wdrożenie w kontenerach — więcej kontroli, więcej pracy. Uzasadnione przy dużych wolumenach.

Warstwa sieciowa

• Mobilne proxy ze sterowaniem przez API. Kluczowe kryteria: wybór regionu aż do miasta i operatora, sterowanie rotacją adresu na żądanie i według harmonogramu, stabilność kanału, wsparcie protokołów, z którymi pracuje twój stos przeglądarkowy, i przejrzysta taryfikacja ruchu. Osobny plus — możliwość przypisania kanału do konkretnego profilu na dłuższy czas.
• Menedżer profili przeglądarki. Dla spójnej tożsamości sesji: strefa czasowa, język, rozmiar ekranu, typ urządzenia. Może być osobnym produktem albo modułem twojego systemu.

Obserwowalność

• Platformy śledzenia wywołań modeli i kroków agentowych z przechowywaniem zrzutów ekranu i liczeniem kosztu.
• Zwykłe systemy logowania i metryk — nie zaniedbuj ich; metryki sieciowe i infrastrukturalne agenta niczym nie różnią się od metryk dowolnej usługi.

Ocena jakości

• Publiczne benchmarki agentów webowych (zestawy zadań na prawdziwych lub odtworzonych stronach) — przydatne, by rozumieć sufit obecnych modeli.
• Własny zestaw regresyjny — niezastąpiony, bo twoje strony i zadania są unikalne.

Co poczytać i czego pilnować

Śledź trzy kierunki. Pierwszy — modele z natywnym sterowaniem komputerem: szybko tanieją i przyspieszają. Drugi — standardy dla ruchu agentowego: w branży dyskutuje się sposoby, którymi agent może otwarcie zadeklarować się stronie przez podpisane zapytania, oraz pliki-opisy, którymi strona wyjaśnia agentom, jak z nią poprawnie pracować. Trzeci — agentowe przeglądarki dla użytkowników końcowych: kształtują oczekiwania i zmieniają to, jak strony odnoszą się do zautomatyzowanych odwiedzających.

Przypadki i wyniki: jak to działa w praktyce

Poniżej cztery uogólnione scenariusze z praktyki zespołów pracujących z automatyzacją i mobilnymi proxy. Liczby są zaokrąglone i podane jako orientacja, a nie gwarancja.

Przypadek 1. Monitoring cen na marketplace’ach dla sprzedawcy

Zadanie. Sprzedawca z asortymentem 600 pozycji chciał codziennie znać ceny i dostępność u ośmiu konkurentów na dwóch platformach. Wcześniej robił to skrypt na selektorach, który psuł się raz na dwa tygodnie i wymagał dwóch dni na naprawę.

Rozwiązanie. Agent DOM na drzewie dostępności, szkielet stanów „szukanie, wybór karty, wyciągnięcie, walidacja”, routing: tani model do wyciągania, drogi — tylko przy awarii. Warstwa sieciowa — pula mobilnych proxy właściwego regionu, utrzymanie adresu przez czas zadania na jednego konkurenta, limit dwóch równoległych zapytań na domenę, pauzy 2–4 sekundy.

Wynik. Odsetek udanych wyciągnięć w pierwszym miesiącu — 93 procent wobec 71 u starego skryptu w „dobrych” tygodniach. Czas naprawy po zmianie szablonu — zero: agent adaptował się sam w 9 przypadkach na 10. Koszt na jedną kartę po kompilacji trajektorii — porównywalny z kosztem zapytania do płatnego API danych, ale z pełną kontrolą nad świeżością.

Przypadek 2. Sprawdzanie kreacji reklamowych i landing page’y według regionów

Zadanie. Zespół media buyera uruchamiał kampanie w sześciu regionach i chciał automatycznie sprawdzać, że landing page’e otwierają się poprawnie z urządzeń mobilnych w każdym regionie, że przekierowania prowadzą tam, gdzie trzeba, a oferty odpowiadają lokalizacji.

Rozwiązanie. Agent hybrydowy: drzewo dostępności plus obowiązkowy zrzut ekranu strony końcowej. Profile sesji ściśle spójne: kanał mobilnego proxy regionu, mobilny rozmiar ekranu, odpowiedni język i strefa czasowa. Wynik zadania — ustrukturyzowany raport z polami „otworzył się, czas ładowania, adres końcowy, język treści, zrzut ekranu”.

Wynik. Ręczne sprawdzanie zajmowało jednemu specjaliście około trzech godzin dziennie. Agent robi pełny przebieg w 12 minut i uruchamia się co dwie godziny. W pierwszym miesiącu wykryto 14 incydentów z błędnym regionem przekierowania, które wcześniej ujawniano dopiero po spadku konwersji po dniu–dwóch. Oszczędność budżetu reklamowego zespół szacuje na dziesiątki procent kwoty, która wcześniej szła na niedziałające kombinacje.

Przypadek 3. Audyt regionalnych wyników wyszukiwania dla agencji SEO

Zadanie. Agencja prowadziła klientów w dwunastu miastach i chciała widzieć realne wyniki i bloki wyszukiwarki dla 300 zapytań w każdym mieście co tydzień.

Rozwiązanie. Agent planująco-wykonawczy: macierz „miasto na zapytanie” przechodzona kodem, model włącza się tylko do wyciągania i klasyfikacji elementów wyników (organiki, mapy, bloki produktowe, wideo). Warstwa sieciowa — mobilne proxy z przypisaniem kanału do miasta, rotacja adresu między zapytaniami, ścisłe pauzy.

Wynik. Koszt jednego sprawdzonego zapytania okazał się kilkukrotnie niższy niż subskrypcja specjalistycznego serwisu przy porównywalnej pełności danych, a co ważniejsze — pojawiła się możliwość wyciągania dowolnych elementów wyników, których serwis nie miał. Odsetek pustych lub nieprawidłowych wyników — poniżej 3 procent, wszystkie automatycznie trafiają do ponownego sprawdzenia.

Przypadek 4. Testy akceptacyjne strony przed wydaniem

Zadanie. Niewielki zespół e-commerce bez dedykowanego testera chciał przepuszczać scenariusze użytkownika (szukanie, koszyk, zamówienie do etapu płatności) przed każdym wydaniem na profilach mobilnych i stacjonarnych.

Rozwiązanie. Agent półautonomiczny z zakazem działań nieodwracalnych (płatność wykluczona na poziomie listy działań zabronionych). Scenariusze opisane w języku naturalnym, co pozwoliło menedżerowi produktu dodawać nowe bez programisty. Profile mobilne przechodzą przez mobilne proxy, by warunki były jak najbliższe realnym użytkownikom.

Wynik. Przebieg regresyjny z 40 scenariuszy — 25 minut zamiast pół dnia pracy ręcznej. W kwartał agent wyłapał 9 regresji przed wyjściem na produkcję. Ciekawy efekt uboczny: ślady agenta stały się dokumentacją ścieżek użytkownika, której wcześniej nie było.

Co łączy udane przypadki

• Zadanie miało formalny kontrakt wyniku.
• Autonomia była ograniczona szkieletem stanów.
• Warstwę sieciową projektowano jako część architektury, a nie podłączano na końcu.
• Koszt i sukces mierzono od pierwszego dnia.
• Model używano oszczędnie, deterministyczny kod — wszędzie, gdzie to możliwe.

FAQ: pytania, które pojawiają się w drugim tygodniu pilotażu

Czym agent AI zasadniczo różni się od zaawansowanego scrapera?

Scraper wykonuje z góry zadaną sekwencję i wyciąga dane według stałych reguł. Agent dostaje cel, sam buduje plan, obserwuje wynik każdego działania i się adaptuje. Scraper jest deterministyczny i tani, ale kruchy. Agent jest elastyczny, ale droższy i wymaga kontroli. W praktyce optimum to hybryda: agent rozpoznaje teren i odzyskuje się po awariach, a stabilne trajektorie są kompilowane do deterministycznego kodu.

Jaki model wybrać dla agenta webowego?

Nie jeden, a minimum dwa. Tani i szybki — do wyciągania danych według schematu, sprawdzeń i prostych decyzji. Flagowy — do planowania i odzyskiwania po awariach. Multimodalny jest potrzebny, jeśli podłączasz zrzuty ekranu. Kryterium wyboru to nie abstrakcyjny ranking, a wynik na twoim zestawie regresyjnym przy zadanym budżecie.

Dlaczego agent przechodzi demo, ale w produkcji sukces spada o połowę?

Demo pokazuje się na znanych stronach w szczęśliwym momencie. W produkcji pojawiają się wyskakujące okna, regionalne wersje interfejsu, wolne ładowanie, limity częstotliwości, zmiany szablonu. Każdy czynnik odbiera kilka procent sukcesu. Leczy się to metodami z artykułu: kompresja postrzegania, szkielet stanów ze sprawdzaniem warunków końcowych, spójna warstwa sieciowa i kategoryzacja niepowodzeń, by naprawiać właściwą warstwę.

Po co agentowi mobilne proxy, jeśli nie robi nic zabronionego?

Właśnie dlatego, że robi to, co dozwolone, ważne jest, by widział stronę tak, jak widzi ją zwykły użytkownik z właściwego regionu i z właściwego typu urządzenia. Adresy centrów danych takiego doświadczenia nie dają: strony odnoszą się do nich surowiej, częściej pokazują weryfikacje i okrojone wersje, a kontekst regionalny się nie zgadza. Mobilne proxy dają ruch nieodróżnialny od ruchu realnych abonentów, naturalną zmianę adresów i dokładną geografię. Plus rozłożenie obciążenia, które jest równie pożyteczne dla ciebie, jak i dla stron, z którymi pracujesz.

Jak często zmieniać adres proxy podczas pracy agenta?

Zależy od typu zadania. Wieloetapowe scenariusze w jednej sesji, zwłaszcza z autoryzacją na twoich kontach, wymagają utrzymania adresu do końca zadania: zmiana adresu w środku sesji wygląda dla strony anomalnie. Zbieranie publicznych danych z dużej liczby stron korzysta z rotacji między zadaniami. Uniwersalna zasada: adres zmienia się na granicach zadań, a nie wewnątrz nich.

Jak chronić się przed tym, że strona „przeprogramuje” agenta?

Cztery środki. Filtrowanie postrzegania: do modelu trafia tylko struktura i istotny tekst. Wyraźne rozdzielenie w prompcie: cała treść strony to dane, nie polecenia. Biała lista domen: agent fizycznie nie może wyjść na obcą stronę. Ochrona działań nieodwracalnych: płatność, wysyłka, usunięcie wymagają potwierdzenia przez człowieka albo są zabronione w scenariuszu. Żaden środek nie jest absolutny, razem redukują ryzyko do akceptowalnego.

Ile kosztuje jedno zadanie agenta webowego?

Zakres jest ogromny: od ułamków centa do kilku dolarów za dziesięcioetapowe zadanie. Decydujące czynniki — format postrzegania (surowy HTML wobec drzewa dostępności daje różnicę kilkudziesięciokrotną), wybór modelu, liczba kroków i ruch. Naiwna implementacja jest droga; po zastosowaniu czterech metod typowa oszczędność to 20–50 razy. Licz koszt w pieniądzach na zadanie od pierwszego dnia i ustawiaj budżety.

Czy można obejść się bez przeglądarki i pracować tylko przez API stron?

Tam, gdzie API istnieje i jego warunki na to pozwalają — tak, i to zawsze taniej i pewniej. Ale ogromna część danych ważnych dla marketingu i e-commerce jest dostępna tylko przez interfejs: wyniki regionalne, wyświetlanie reklam, realna cena z uwzględnieniem personalizacji, wygląd landing page’a. Do tego potrzebna jest przeglądarka. Rozsądna strategia — API gdzie możliwe, agent przeglądarkowy gdzie konieczne.

Jak poznać, że agent jest gotowy do pracy bez nadzoru?

Gdy na zestawie regresyjnym 30–50 zadań odsetek sukcesu jest stabilnie powyżej twojego progu (zwykle 90 procent), niepowodzenia są skategoryzowane i nie zawierają „nieznanej przyczyny”, działania nieodwracalne są zabezpieczone, są budżety i powiadomienia, a ślady pozwalają rozłożyć dowolny incydent w minutach. Do tego momentu — człowiek w pętli, przynajmniej przy wybiórczym sprawdzaniu wyników.

Co zmieni się w agentach webowych w najbliższy rok–dwa?

Trzy trendy. Modele z natywnym sterowaniem komputerem będą tanieć i przyspieszać, przesuwając równowagę w stronę agentów wizualnych. Pojawią się powszechnie przyjęte sposoby, którymi agent otwarcie przedstawia się stronie, a strona wyjaśnia agentom zasady współpracy — to uczyni relacje między zautomatyzowanymi klientami i zasobami bardziej przejrzystymi. I agentowe przeglądarki dla zwykłych użytkowników przyzwyczają strony do tego, że znaczna część odwiedzających działa przez pośrednika. Dla tych, którzy pracują z automatyzacją, oznacza to: inżynieria wokół modelu, w tym warstwa sieciowa, pozostanie główną przewagą konkurencyjną, bo same modele szybko się wyrównują.

Zakończenie: agent to system, a nie model

Jeśli wynieść z artykułu jedną myśl, to oto ona: jakość agenta webowego określa nie to, jaki model ma w środku, a to, jak zaprojektowano warstwy wokół niego. Postrzeganie decyduje, ile płacisz i jak dobrze agent rozumie stronę. Pętla sterowania decyduje, czy się zgubi. Warstwa sieciowa decyduje, co w ogóle zobaczy i czy będzie mógł pracować stabilnie. Obserwowalność decyduje, czy dowiesz się o problemach, zanim staną się drogie.

Omówiliśmy siedmiowarstwową architekturę i mapę wąskich gardeł, cztery praktyczne metody z checklistami, jedenaście typowych błędów, mapę narzędzi i cztery scenariusze, w których to wszystko zadziałało. Co dalej?

1. Wybierz jedno zadanie o jasnej wartości i formalnym kryterium sukcesu. Monitoring cen, sprawdzanie landing page’y według regionów, audyt wyników — cokolwiek, co dziś robisz ręcznie albo kruchym skryptem.
2. Zbuduj agenta półautonomicznego na drzewie dostępności ze szkieletem stanów i budżetem kroków. Nie gonić za autonomią.
3. Zaprojektuj warstwę sieciową od razu. Mobilne proxy właściwego regionu, spójny profil sesji, limity częstotliwości, szacunek dla zasad zasobów.
4. Włącz metryki od pierwszego uruchomienia. Sukces, kroki, koszt, czas, kategorie niepowodzeń.
5. Zbierz sto śladów, zbuduj zestaw regresyjny i dopiero potem optymalizuj: routing modeli, kompresja historii, kompilacja trajektorii.

Sieć powstała dla ludzi i agentom nie jest w niej łatwo. Ale właśnie dlatego dobrze zaprojektowany agent AI daje taką przewagę: robi to, co wcześniej robili tylko ludzie, z szybkością i skalą maszyny. Zadaniem inżyniera jest sprawić, by ta maszyna widziała jasno, myślała oszczędnie, działała starannie i wychodziła do sieci jak porządny odwiedzający. Wtedy wąskie gardła zamieniają się w zrozumiałe zadania inżynierskie, a agent — w niezawodnego pracownika, który nigdy się nie męczy.