Wykonywanie w przeglądarce dla agentów AI: Playwright, MCP oraz bezpieczny wykonywacz

Agenci produkcyjni już biegle operują maszynami. Korzystają z API, łączą się z serwerami MCP, uruchamiają kod, wysyłają zapytania do sieci, otwierają pliki i wydają polecenia w środowisku wiersza poleceń. Mimo to zaskakująco duża liczba rzeczywistych oprogramowań umożliwia dostęp do niektórych kluczowych funkcji wyłącznie poprzez interfejs przeglądarki, a właśnie tę lukę ma wypełnić wykonywanie kodu w przeglądarce.

Najnowsze produkty oparte na agentach mają do dyspozycji przeglądarkę lub komputer chmurowy dla agenta. Może się wydawać, że to kolejna demonstracja sztucznej inteligencji klikającej w przyciski. Bardziej przydatne jest spojrzenie z punktu widzenia architektury: przeglądarka nie jest nowym rodzajem agenta, lecz nowym środowiskiem wykonywania.

Różnica jest istotna. Jeśli system już oferuje serwery MCP, umiejętności, działający kod, programowe wywołania narzędzi, środowiska testowe, funkcje wyszukiwania oraz bezpośrednie połączenia z backendem, przeglądarka nie powinna zastępować żadnego z tych elementów. Rozszerza ona system o obszary, których nie może on w sposób niezawodny obsłużyć: aplikacje z pamięcią stanu, oparte głównie na JavaScriptu, wymagające autoryzacji i stworzone dla ludzi.

Wyszukiwarka znajduje informacje. API i MCP komunikują się z systemami. Kod przekształca dane i koordynuje poszczególne kroki. Przeglądarka służy do obsługi interfejsu stworzonego dla ludzi.

Interfejs, który zostaje zapomniany

Architektury agentów zazwyczaj zaczynają się od ustrukturyzowanych możliwości. Gdy usługa dostarcza uporządkowane API REST, SDK lub serwer MCP, to niemal zawsze jest to najlepszy interfejs dla agenta: wyraźna umowa, skategoryzowane dane wejściowe i wyjściowe, błędy, które łatwiej jest zrozumieć, oraz wyraźniejsze granice bezpieczeństwa.

Następnie następuje wykonywanie kodu. Zamiast sprawiać, by model wywoływał dwadzieścia narzędzi po jednym, niech napisze mały program, który je wywołuje, agreguje wyniki lokalnie, filtrowa dane i zwraca jedną zwięzłą odpowiedź. To rozwiązanie nadaje się do dużych katalogów narzędzi, powtarzających się wywołań oraz procesów pracujących z dużymi ilościami danych. Sandbox dodaje kolejną warstwę możliwości dzięki Pythonowi, wierszowi poleceń, plikom, a być może także narzędziom Kubernetesa lub GitHuba w kontrolowanym środowisku. W tym momencie agent może wykonywać wiele zadań, ale nadal zakłada, że wszystko, co przydatne, jest dostępne poprzez interfejsy czytelne dla maszyn.

Nie do końca. Wiele narzędzi istnieje wyłącznie za ekranem: wewnętrzne panele administracyjne, stare portale dostawców, tablice kontrolne raportów, systemy partnerów, portale z ofertami pracy, produkty analityczne, strony ustawień SaaS lub aplikacje, które pobierają rzeczywiste dane tylko po ustawieniu kilku filtrów. Dane mogą być publiczne, podczas gdy użyteczny stan jest generowany przez JavaScript. Dla danej osoby zadanie wydaje się proste, a mimo to żadna API nie jest udokumentowana. Czasami istnieje wewnętrzna API, ale jest prywatna, niestabilna lub celowo nieobsługiwana.

To jest rzeczywisty przypadek użycia: nie chodzi o to, by sztuczna inteligencja mogła swobodnie przeglądać internet, lecz o wykorzystanie przeglądarki jako interfejsu awaryjnego, gdy sama aplikacja stanowi część zadania.

Dlaczego MCP jeszcze tego nie obejmuje

Każdy raz, gdy mowa o uruchamianiu w przeglądarce, pojawia się to pytanie, na które należy udzielić jednoznaczniej odpowiedzi. MCP w żadnym wypadku nie wymaga, aby system docelowy posiadał API; określa jedynie sposób, w jaki agent komunikuje się z daną funkcjonalnością. Załóżmy, że aplikacja docelowa oferuje jedynie interfejs użytkownika przeznaczony dla ludzi. W takim przypadku kod narzędzia MCP może sam sterować przeglądarką. Ograniczeniem nie jest MCP, lecz brak stabilnego, uporządkowanego interfejsu po stronie systemu docelowego.

Cel może nie oferować niczego ustrukturyzowanego. To, co znajduje się za MCP, może być przeglądarką, środowiskiem izolowanym, silnikiem procesów roboczych lub czymś zupełnie innym. Problemy pojawiają się wtedy, gdy aplikacja nie posiada publicznego API, SDK, integracji z bazą danych ani żadnej programowej ścieżki umożliwiającej wykonywanie potrzebnych operacji. MCP może nadal publikować narzędzie o nazwie browser_execute, ale coś za nim musi obsługiwać system – w tym przypadku jest to wykonywanie kodu w przeglądarce. Nie są one konkurentami: MCP może być protokołem, który ujawnia możliwości przeglądarki, a przeglądarka służy do obsługi aplikacji przeznaczonej dla użytkowników, gdy nie ma nic lepszego.

Uwierzytelnianie może być powiązane z przeglądarką. MCP posiada własny model autoryzacji, w tym mechanizmy OAuth, ale obejmuje on jedynie komunikację pomiędzy klientem MCP a serwerem MCP. Nie ingeruje on w zasady logowania systemu, w którym narzędzie musi ostatecznie działać. Wiele wewnętrznych portali, aplikacji dostawców oraz starszych produktów SaaS umożliwia dostęp wyłącznie poprzez interaktywny proces w przeglądarce z wykorzystaniem SSO, MFA, plików cookie sesji lub innych informacji utworzonych podczas logowania przez człowieka, bez żadnych uprawnień serwisowych czy upoważnionych tokenów. Narzędzie MCP nadal może udostępniać te funkcje, przy czym za nim stoi uwierzytelniony profil przeglądarki. Użytkownik loguje się przez przeglądarkę, stan sesji jest przechowywany pod kontrolowanym dostępem, a później działa pod tą tożsamością. Ograniczeniem jest model uwierzytelniania aplikacji docelowej, a nie MCP.

Część zadań to procesy w interfejsie użytkownika, a nie pojedyncze wywołania. Weźmy na przykład „wybierz sektor detaliczny, Europę i ostatnie 90 dni, a następnie oblicz średnią konwersję na kraj”. Może to wymagać serii filtrów, kroku renderowania oraz wydobycia uzyskanego stanu, przy czym żaden punkt końcowy nie zwraca odpowiedzi bezpośrednio. Przeglądarka może obsługiwać interfejs i odczytywać to, co generuje aplikacja.

Strukturalne API, wywoływane bezpośrednio lub przez MCP, pozostają pierwszym wyborem, o ile istnieją. Są tańsze, bardziej deterministyczne i łatwiejsze do zabezpieczenia. Przeglądarka zajmuje się tą częścią, która znajduje się wyłącznie za interfejsem przeznaczonym dla użytkowników.

Szukanie to nie przeglądanie

W wielu architekturach agentów wyszukiwanie w sieci, pobieranie danych przez HTTP, automatyzacja przeglądarki oraz korzystanie z komputera są łączone w jedną niejasną umiejętność „sieciową”, mimo że są to różne narzędzia.

Aby dowiedzieć się, co zmieniło się w najnowszej specyfikacji MCP, prawdopodobnie wystarczy wyszukiwanie w internecie. Mając adres URL zwykłego artykułu publicznego, bezpośrednie pobranie danych może być wystarczające. Jeśli trzeba pracować z Salesforce, należy użyć jego API lub MCP. Aby obliczyć statystyki z danych w formacie JSON, konieczne jest użycie kodu.

Teraz wyobraźmy sobie inny wniosek: otwarcie publicznego panelu kontrolnego, wybranie Ukrainy, ustawienie roku na 2026, wybór opcji Enterprise, przejście przez każdą kategorię i obliczenie średniej dla każdej miary. Silnik wyszukiwania nie może przeprowadzić takiej interakcji, a zwykły żądanie HTTP może zwrócić jedynie pustą strukturę strony. Interesujące dane pojawiają się po tym, jak przeglądarka uruchomi JavaScript, wyśle żądania po stronie klienta, zaktualizuje stan aplikacji i wyświetli wynik.

Lub strona z ofertami pracy: wybierz kategorie Inżynieria AI, Praca zdalna i Niemcy, a następnie policz, ile ofert w opisie wspomina o RAG. To nie jest właściwie zapytanie wyszukiwawcze – to proces w interfejsie użytkownika, po którym następuje wydobywanie informacji i ich przetwarzanie. Właśnie w tym momencie prawdziwy przeglądarka dostarcza agentowi czegoś nowego, mianowicie warstwę wykonywania zadań w sieci z zachowaniem stanu.

Przeglądarka to środowisko wykonywania

Zarządzana przeglądarka, taka jak Amazon Bedrock AgentCore Browser, stanowi infrastrukturę – izolowaną sesję przeglądarki zdalnej, którą można programowo kontrolować. Model językowy nie komunikuje się z nią w sposób magiczny; to ty określasz umowę pomiędzy agentem a środowiskiem.

AgentCore Browser udostępnia sesje za pośrednictwem punktu końcowego automatyzacji WebSocket, a biblioteki takie jak Playwright mogą łączyć się z zdalnym Chromium przez protokół Chrome DevTools. AWS oferuje oddzielne działania przeglądarki na poziomie systemu operacyjnego dla interakcji, których CDP nie może sprawnie obsłużyć. Przeglądarka stanowi zdalny środowisko wykonawcze, a nie warstwę analityczną. Patrząc w ten sposób, integracja staje się prostsza: agent potrzebuje możliwości programowalnej, a środowisko wykonawcze przeglądarki jest miejscem, w którym ta funkcja jest realizowana.

Niech agent pisze kod przeglądarki

Przeglądarka może nawiązać połączenie z agentem na kilka sposobów. Jedną z opcji jest narzędzie wysokiego poziomu, takie jak browser_task(task="find the latest invoice"), w którym znajduje się agent specyficzny dla przeglądarki, który odczytuje zadanie, przegląda stronę, wybiera element do kliknięcia i przekazuje informacje z powrotem. Może to być pomocne przy nieznanych stronach, gdzie konieczne jest odkrycie odpowiedniego procesu pracy, ale jest to słaby punkt wyjścia.

Jeśli główny model jest zdolnym programistą, lepszym rozwiązaniem jest to, aby wygenerował program przeglądarki i przekazał go egzekutorowi przeglądarki. Wystarczy podpis o takiej postaci jak browser_execute(code, profile_id, allowed_domains):

browser_execute(
    code=generated_playwright_code,
    profile_id="vendor-portal-user-42",
    allowed_domains=["portal.example.com"]
)

Gdy otrzymuje połączenie, wykonawca sprawdza żądanie, następnie uruchamia (lub ponownie wykorzystuje) izolowaną sesję i podłącza Playwright do zdalnego przeglądarki. Wykonuje program i zwraca ustrukturyzowane dane. Główny agent przetwarza informacje tylko raz. Drugi model językowy interpretujący ten sam zamiar ma sens tylko wtedy, gdy zadanie naprawdę wymaga eksploracji. W przypadku przewidywalnej konsoli, katalogu lub portalu rozwiązanie to jest lepsze od zagnieżdżonego agenta przeglądarki pod względem ceny oraz łatwości obserwacji.

Dlaczego tryb kodowy jest odpowiedni

To ma największe znaczenie tam, gdzie już wykorzystuje się programowe wywoływanie narzędzi. Ten marnotrawny wzorzec jest łatwy do zauważenia: model wywołuje click, otrzymuje wynik, wywołuje screenshot, ponownie analizuje sytuację, wywołuje type, otrzymuje kolejny wynik. Praca, którą zwykły skrypt załatwiłby w milisekundach, tutaj wymaga dziesiątek iteracji modelu.

Lepszym rozwiązaniem jest agregacja narzędzi do dopasowywania wzorców: niech model napisze jeden program, który wykona wiele operacji przeglądarki w środowisku wykonawczym i zwróci jeden zwięzły wynik.

page = await browser.page()
await page.goto("https://jobs.example.com")
await page.get_by_label("Category").select_option("AI Engineering")
await page.get_by_label("Location").select_option("Germany")
await page.get_by_label("Remote").check()
await page.get_by_role("button", name="Apply").click()
jobs = await page.locator(".job-card").all_inner_texts()

rag_jobs = [job for job in jobs if "RAG" in job.upper()]
return {
    "total_jobs": len(jobs),
    "jobs_mentioning_rag": len(rag_jobs)
}

Model pisze jeden program, wykonawca przeprowadza dziesiątki lub setki deterministycznych operacji na DOM-ie, a agent otrzymuje mały obiekt JSON zamiast długiej serii kliknięć i zrzutów ekranu.

Można posunąć się dalej. Środowisko wykonawcze kodu świadomego możliwości może dostarczyć wygenerowanemu programowi kilka kontrolowanych interfejsów naraz: klientów MCP, zwykłego HTTP, plików, kontroli przeglądarki oraz lokalnych obliczeń. Jeden program może pobrać konta z Salesforce za pomocą MCP, otworzyć portal starszego typu, odczytać wskaźnik dla każdego konta, zsumować je i zwrócić jedną odpowiedź.

customers = await mcp.salesforce.search_accounts(segment="enterprise")

results = []
for customer in customers:
    await browser.goto(f"https://legacy.example.com/customer/{customer.id}")
    metric = await browser.locator("#health-score").inner_text()
    results.append({
        "customer": customer.name,
        "health_score": metric,
    })
return summarize(results)

To nie jest sztuczna inteligencja, która klikuje na różne elementy. To zintegrowana orkiestracja procesów poprzez interfejsy maszynowe i ludzkie.

Przykładowy proces

Weźmy proste żądanie: wejdź na publiczną tablicę kontrolną analityczną, wybierz sektor handlu detalicznego, Europę, ogranicz dane do ostatnich 90 dni i porównaj różnice w stopach konwersji oraz retencji pomiędzy poszczególnymi krajami.

Agent nie powinien od razu otwierać przeglądarki. Router umiejętności najpierw sprawdza, czy istnieje tańsza, bardziej uporządkowana droga do uzyskania informacji. Jeśli wyszukiwarka może udzielić odpowiedzi, skorzystaj z niej. Jeśli strona oferuje stabilną API, skorzystaj z niej. Jeśli dane są dostępne bezpośrednio przez HTTP, nie uruchamiaj Chromium.

Jeśli wartości pojawiają się tylko po interakcji po stronie klienta, router wybiera wykonywanie w przeglądarce. Główny agent generuje program Playwright, a wykonawca uruchamia go w zarządzanej sesji, czeka, aż strona przestanie się zmieniać, odczytuje wyświetlone liczby i zwraca je jako dane strukturyzowane. Następnie tryb kodu przeprowadza porównanie, a agent zapisuje odpowiedź. Użytkownik nie musi wiedzieć, że otwarto przeglądarkę. W wielu produktach powinna to być niewidzialna funkcjonalność backendu, taka jak zapytanie do bazy danych lub środowisko testowe kodu.

Najpierw automatyzacja, potem używanie komputera

Autoryzacja przeglądarek i korzystanie z komputera są czasami traktowane jako jedna rzecz, ale należą do różnych poziomów tej struktury. Playwright i CDP pracują z architekturą przeglądarki: stronami, selektorami, elementami DOM, formularzami, żądaniami sieciowymi, pobieraniem danych oraz stanem aplikacji. Dzięki temu działają szybciej i zużywają mniej zasobów, a także są łatwiejsze do testowania i izolacji.

Używanie komputera opiera się na elementach wizualnych. Model obserwuje ekran i wykonywa czynności myszką lub klawiaturą. Zyskuje na znaczeniu wtedy, gdy DOM nie jest w stanie niezawodnie obsłużyć interfejsu: aplikacje typu canvas, dialogi natywne, menu kontekstowe, nietypowe procesy przeciągania i upuszczania. AWS stosuje tę samą zasadę w AgentCore Browser – ścieżka automatyzacji oparta na WebSocketach jest budowana na bazie CDP, a API InvokeBrowser umożliwia kontrolę na poziomie systemu operacyjnego w sytuacjach, gdy CDP nie radzi sobie z zadaniem. Dlatego najpierw należy korzystać z zautomatyzowanych rozwiązań strukturalnych, a do kontroli wizualnej uciekać się tylko w razie potrzeby. Im niżej agent znajduje się w hierarchii, tym bardziej jest elastyczny, ale jednocześnie każda jego czynność staje się droższa, bardziej złożona pod względem stanu i bardziej ryzykowna.

Po przechodzeniu na użycie komputera wykonawca powinien uruchomić zamknięty cykl weryfikacji, a nie serię ślepych działań. Kliknięcie, które powraca bez błędu, nic nie dowodzi prawidłowości operacji. Strona może nadal się ładować, modala może przyjąć to działanie lub inny element może przejąć kliknięcie. Po każdym kolejnym kroku system powinien sprawdzić nowy stan i potwierdzić, że nastąpiła oczekiwana zmiana, zanim przejdzie dalej. Powinien również wykrywać powtarzające się działania, które nic nie przynoszą. Jeśli ten sam krok się powtarza bez żadnej zmiany, ponowna próba jest błędna; rozwiązaniem jest przeplanowanie działań lub powrót do bardziej uporządkowanej strategii.

Ten cykl opiera się na trzech zasadach bezpieczeństwa: ograniczeniu liczby przechowywanych zrzutów ekranu, wykrywaniu powtarzających się działań, które nic nie zmieniają, oraz stosowaniu poziomów uprawnień krok po kroku.

Autoryzacja sprawia, że praca staje się rzeczywista

Paneliki publiczne nadają się do demonstracji koncepcji, ale prawdziwa wartość biznesowa objawia się w aplikacjach z autoryzacją użytkowników. Playwright już oferuje solidne rozwiązania dotyczące kont przeglądarek oraz możliwości ponownego użycia stanu autoryzacji, a AgentCore Browser dodaje zarządzane profile, które przechowują pliki cookie i dane lokalne pomiędzy sesjami. Użytkownik loguje się raz, profil zostaje zapisany, a kolejna sesja przywraca ten stan. Rozwiązanie to jest przydatne w portalach wewnętrznych, systemach klientów, starszych aplikacjach SaaS oraz oprogramowaniu dostawców, gdzie integracja z API wymagałaby specjalistycznej inżynierii wstecznej lub byłaby niemożliwa.

Zmienia to również sposób modelowania tożsamości. Profil przeglądarki jest w rzeczywistości tożsamością wykonawczą opartą na uprawnieniach, a nie zwykłym obiektem ułatwiającym pracę. Profil, który może uzyskać dostęp do portalu finansowego, nie powinien być automatycznie dostępny dla każdego agenta czy procesu pracy. W środowisku produkcyjnym należy powiązać profile z użytkownikiem, celem oraz zakresem polityki, przyznając agentowi dostęp tylko do konkretnego profilu, a nie ogólny dostęp do wszystkich sesji należących do użytkownika.

Bезpieczeństwo jest ważniejsze niż demonstracja

Wykonywanie zadań w przeglądarce jest potężne, ponieważ działa przez tę samą interfejs, którą używa człowiek, co oznacza również, że może popełniać błędy posiadając uprawnienia człowieka.

Pierwszą granicą jest egzekutor. Kod generowany przez przeglądarkę powinien działać w izolacji, z wyraźnymi ograniczeniami dotyczącymi domen, czasów wykonywania zadań, limitów zasobów oraz kontrolowanym dostępem do profili. Model nie powinien otrzymywać zmiennych środowiskowych hosta, dowolnych danych uwierzytelniających ani ogólnych ścieżek sieciowych tylko dlatego, że może uruchamiać Playwright.

Drugą granicą jest polityka działań. Pobieranie metryk z strony to inna czynność niż publikowanie treści, wysyłanie wiadomości, edytowanie uprawnień konta, usuwanie danych czy zatwierdzanie płatności. Te efekty uboczne należy sklasyfikować poza modeliem i zablokować na warstwie wykonywania.

Trzecim problemem jest iniekcja poleceń. Gdy agent czyta dowolne strony, wszystko, co jest tam wyświetlane, staje się niepewnym danym wejściowym. Tekst w panelu sterowania, e-mailu, banerze lub dokumencie może wyglądać jak polecenie dla agenta. Wykonawca nigdy nie powinien traktować zawartości na ekranie jako autoryzacji użytkownika. Wytyczne OpenAI dotyczące korzystania z komputera mówią to samo: traktuj treści od stron trzecich jako niepewne i proszę o potwierdzenie tuż przed podejmowaniem ryzykownych działań, takich jak publikowanie, wysyłanie, usuwanie, zmiana uprawnień lub przenoszenie pieniędzy. To kwestia polityki wykonywania, a nie tylko inżynierii poleceń. Przeglądarka może obserwować szeroko, ale powinna zmieniać świat wyłącznie poprzez wyraźną politykę.

Następuje możliwość obserwacji. Wykonawca w środowisku produkcyjnym powinien rejestrować zlecenie, profil użyty, dostępne domeny, uruchomiony program, pobrałe pliki, próbowane zewnętrzne efekty uboczne oraz miejsca, gdzie wymagana była ludzka akceptacja. AgentCore Browser można obserwować na żywo, a niestandardowe przeglądarki umożliwiają nagrywanie i odtwarzanie sesji, co stanowi solidną podstawę dla audytu.

Jak współgra z MCP, umiejętnościami i sandboxami

Nic tutaj nie zastępuje niczego innego. MCP i API pozostają preferowanymi rozwiązaniami dla zorganizowanych operacji biznesowych. Pakiet umiejętności obejmuje procedury powtarzalne, kontekst oraz wiedzę operacyjną. Tryb kodu pozostaje efektywną warstwą do powtarzalnych wywołań, agregacji i transformacji. Sandboksy stanowią kontrolowane środowisko do przechowywania plików, pracy z wierszem poleceń, Pythonem, testowania oraz intensywnych obliczeń. Wykonywanie w przeglądarce wypełnia odrębną niszę: umożliwia obsługę interfejsu przeznaczonego dla ludzi, gdy brak odpowiedniego rozwiązania dla maszyn nie jest wystarczająco niezawodny.

Trzymaj się konserwatywnego podejścia do routingu. Czy API może wykonać zadanie? Użyj go. Czy bezpośrednie pobieranie danych wystarczy? Nie otwieraj przeglądarki. Czy konieczna jest obsługa samej strony, aby uzyskać wynik? W takim przypadku wykonywanie w przeglądarce jest właściwym rozwiązaniem. Czy zorganizowana automatyzacja nie może zakończyć interakcji? Użycie komputera jest ostatecznością.

MCP jako umowa

W praktyce gałęzie rzadko pozostają oddzielone. Wykonywanie kodu, działanie przeglądarki, a nawet wyszukiwanie narzędzi zazwyczaj odbywa się za pośrednictwem serwera MCP. MCP to nie tylko gałąź API – to umowa, dzięki której agent uzyskuje dowolną funkcjonalność, niezależnie od tego, czy chodzi o wywołanie REST, skrypt działający w środowisku izolowanym, czy zdalny Chromium.

Pakietowanie sprawdza się dobrze, gdy jeden dedykowany serwer MCP udostępnia kilka narzędzi, takich jak execute_code, browser_execute i find_tool, zamiast jednego narzędzia na każdą podstawową operację. Liczba narzędzi wynosi trzy lub cztery, a nie trzydzieści. Model nie ma potrzeby oddzielnych narzędzi do klikania, robienia zrzutów ekranu czy wybierania opcji, podobnie jak nie potrzebuje oddzielnych narzędzi do restartu, skalowania czy cofania, gdy wystarczy jedna operacja z planem.

Przenośność to kolejny powód. Jeden serwer może działać za pomocą specjalnego agenta lub być podłączony do Claude, ChatGPT lub dowolnego klienta kompatybilnego z MCP, dzięki czemu ta sama funkcjonalność może być testowana przez znajomą interfejs bez konieczności dodatkowej integracji.

Trzymaj egzekutor oddzielnie

Z perspektywy agenta przeglądarka może wyglądać jak część trybu kodu, ponieważ jeden z wygenerowanych skryptów może wykorzystywać browser.goto() oraz browser.locator() obok klientów MCP, plików i interfejsów API obliczeniowych w ramach jednego logicznego środowiska wykonawczego. Podczas wdrażania Browser Executor nadal jest lepszy jako odrębny komponent. Przeglądarki mają swój własny cykl życia oraz powiązane z nim ryzyka: sesje, pliki cookie, lokalne przechowywanie danych, pobrałe pliki, zasady sieciowe, zalogowane profile, stan stron, nagrania oraz efekty uboczne poza Twoim systemem. Sandbox kodu zajmuje się procesorem, pamięcią, plikami, pakietami i procesami. Ich rozdzielenie umożliwia każdemu środowisku wykonawczemu stosowanie modelu bezpieczeństwa odpowiedniego dla niego. Tryb kodu może oferować ograniczony klient przeglądarki, podczas gdy executor zarządza zdalną sesją, dzięki czemu model programowania pozostaje zjednoczony, a infrastruktura podzielona.

Zacznij nudzić

Pomijaj uniwersalnego autonomicznego agenta przeglądarki na początku. Pierwsza użyteczna wersja jest celowo prosta: jedna izolowana zdalna sesja Chromium, mały kontrakt browser_execute, Playwright do automatyzacji, ścisła lista domen dozwolonych oraz ustrukturyzowane wyniki. Przetestuj go na publicznym panelu sterowania intensywnie wykorzystującym JavaScript lub w przykładowej aplikacji, gdzie można pokazać, że przeglądarka przewyższa wyszukiwarki oraz metodę pobierania danych przez HTTP.

Gdy to zadziała, połącz to z wzorcem programowym już używanym w trybie kodowym, aby główny agent generował program przeglądarki i nie wywoływał w kółko narzędzi do klikania o niskim poziomie. Następnie dodaj zautoryzowane profile dla kontrolowanych aplikacji wewnętrznych, a także polityki działań i bramy zatwierdzeń, zanim jakikolwiek proces pracy będzie mógł powodować zewnętrzne efekty uboczne. Dodaj funkcję wizualnego używania komputera wyłącznie dla interfejsów, których Playwright nie może obsłużyć w sposób niezawodny, i rozważ specjalistyczny cykl agenta przeglądarki, który obserwuje, analizuje, próbuje ponownie i eksploruje sytuację tylko wtedy, gdy zadanie jest zbyt niejednoznaczne, by główny agent mógł stworzyć stabilny program. Taka kolejność sprawia, że architektura jest zrozumiała, a najdroższe i najmniej deterministyczne zachowania są umieszczane na marginesie, zamiast stać się standardem.

Większa zmiana

Ciekawe nie jest to, że model językowy może kliknąć przycisk – automatyzacja przeglądarek istnieje od lat. Nowością jest to, że agent może zdecydować, kiedy przeglądarka jest odpowiednią platformą, napisać program, który nią kieruje, połączyć wyniki z wywołaniami MCP oraz wykonywaniem kodu i kontynuować pracę, bez konieczności tworzenia specjalistycznych integracji przez programistów dla każdego aplikacji przeznaczonej dla ludzi.

Interfejsy maszynowe są nadal lepsze: bardziej niezawodne, bezpieczniejsze i łatwiejsze w zarządzaniu. Jednak świat jest pełen systemów, które nie oferują potrzebnych funkcji w prosty sposób, a procesy pracy często kończyły się koniecznością otwarcia strony przez człowieka w celu dokończenia zadania. Wykonywanie kodu w przeglądarce przesuwa tę granicę – sprawia, że interfejs użytkownika staje się kolejną programowalną platformą, którą należy używać ostrożnie, izolować skutecznie i preferować tylko wtedy, gdy strukturalne interfejsy okazują się niewystarczające.

Następne pokolenie platform agentów najlepiej rozumieć nie jako większe zbiory narzędzi czy armie botów przeglądarkowych, lecz jako systemy z kilkoma środowiskami wykonywania oraz routerem, który wie, które z nich powinno obsłużyć każdą część zadania. Celem nie jest zmuszanie agentów do większej liczby kliknięć, ale umożliwienie im dostępu do tych części oprogramowania, które API nadal nie udostępniają.