Twoi agenci sterują prawdziwą przeglądarką.
Nie udawaną.
AgentsRoom osadza prawdziwą przeglądarkę Chromium w każdym projekcie i dostarcza serwer AgentsRoom Browser MCP, który pozwala Twoim agentom AI nią sterować. Twój agent QA otwiera Twoją stronę na localhost, klika przyciski, wypełnia formularze, robi screenshoty, czyta konsolę i weryfikuje, że feature faktycznie działa, zanim powie done. Browser automation end-to-end dla Claude Code, Codex, OpenCode, Gemini CLI i Aider, z zerową konfiguracją Playwright.
Spruj to z Agent Teams: agent Dev dowozi feature'a, agent QA ładuje stronę localhost w wbudowanej przeglądarce, odpala scenariusz weryfikacji, robi screenshot rezultatu i zatwierdza. Natywna automatyzacja przeglądarki też jest w roadmap, z planowanymi w przyszłości serwerami MCP dla aplikacji React Native i Electron, by agenci mogli też testować aplikacje mobilne i desktopowe.
Demo AgentsRoom Browser MCP: testowanie end-to-end aplikacji webowej sterowane przez agenta QA Claude Code przez wbudowaną przeglądarkę Chromium.
Browser Automation w AgentsRoom to dwie rzeczy w jednej. Po pierwsze, prawdziwa przeglądarka Chromium osadzona w każdym roomie projektu, z paskiem URL, back/forward, reload, history, screenshotem do schowka, open-in-default-browser, persystentnymi cookies i localStorage per projekt. Po drugie, serwer AgentsRoom Browser MCP (agentsroom-browser), który wystawia tę przeglądarkę Twoim agentom AI przez Model Context Protocol. Agent dostaje czysty, skryptowalny interfejs: navigate, click, type, screenshot, evaluate JavaScript, wait for element, get page state, get console logs, go back, go forward, reload.
Dlaczego to ma znaczenie? Bo cała obietnica agentów AI do kodowania rozpada się, gdy agent mówi 'feature shipped', a nigdy nie otwiera strony, by sprawdzić. Większość agentów dziś polega na uruchamianiu unit testów, a potem ma nadzieję. Z prawdziwym browser MCP agent ładuje serwer localhost, ćwiczy user flow, widzi to, co widziałby ludzki użytkownik, i dopiero wtedy zatwierdza. Rola QA Engineer agent w końcu ma narzędzia, których potrzebuje, by robić prawdziwe QA, nie tylko statyczną analizę.
Setup techniczny jest dla Ciebie niewidoczny. Gdy zaznaczasz 'Browser access' na agencie, AgentsRoom wmerge'uje wpis agentsroom-browser do .mcp.json Twojego projektu i agent startuje z dostępnymi narzędziami przeglądarki. Most WebSocket działający na porcie loopback (127.0.0.1, przydzielany przez OS, regenerowany przy każdym bootcie, autentykowany 32-bajtowym tokenem hex) łączy subprocess MCP z WebContentsView Chromium w aplikacji Electron. Każdy click, każdy type, każdy screenshot to wywołanie JSON-RPC. Agent widzi prawdziwą przeglądarkę, nie stub.
Panel Browser AgentsRoom: pasek URL, history, screenshot i pełna powierzchnia kontroli MCP dla agentów AI do nawigacji, klikania, pisania i weryfikacji.
Prawdziwa przeglądarka, nie stub Playwright
Większość dem agentów AI mówiących o browser automation używa headless instancji Playwright spawnowanej przy każdym wywołaniu narzędzia. To działa do benchmarków, ale jest bolesne w prawdziwym życiu: nie widzisz, co robi agent, każda nawigacja respawnuje Chromium, cookies się gubią, localStorage jest puste, Twój dev server myśli, że każda wizyta to świeżutka sesja. AgentsRoom bierze inny kąt. Przeglądarka jest już otwarta w Twoim roomie projektu (sam jej używasz, jak normalnej przeglądarki), a agent steruje tą przeglądarką. Sesje, cookies, localStorage, stan logowania, wszystko zachowane.
Każdy click i type od agenta wyzwala prawdziwy natywny dispatch przez WebContentsView Electrona, z właściwymi key events, mouse events i mutacjami DOM. Screenshoty to prawdziwe PNG-i przechwycone z faktycznie wyrenderowanej strony (nie hack DOM-to-image). Logi konsoli są buforowane i queryable, włącznie z warningami i błędami. Agent widzi to samo, co widziałbyś Ty, gdybyś miał otwarte DevTools: prawdziwą wydajność, prawdziwe zachowanie sieci, prawdziwy CORS, prawdziwy auth.
Izolacja cross-room jest egzekwowana. AgentsRoom tworzy jeden Chromium WebContentsView per projekt, z własną session partition (persist:agentsroom-browser-<projectId>). Cookies projektu A nigdy nie wyciekają do projektu B. Gdy zmieniasz projekt, poprzednia przeglądarka jest ukrywana, a nowa wchodzi online z własnym stanem. Agent zawsze ląduje na właściwym projekcie, z właściwymi credentialami.
Warstwa MCP jest celowo mała i bez zależności. Subprocess browser-mcp-server.cjs mówi protokołem MCP 2024-11-05 przez stdio (initialize, tools/list, tools/call) i tłumaczy go na wywołania JSON-RPC po loopback WebSocket bridge. W porównaniu do ciężkiego serwera SDK-based zostaje szybki (pierwsze wywołanie narzędzia jest sub-100ms) i łatwy do debugowania. Po każdej akcji zmieniającej stronę (click, type, navigate, reload, back, forward) odpowiedź zawiera screenshot PNG base64 ograniczony do 1.6 MB, więc agent zawsze widzi rezultat tego, co właśnie zrobił. To okazało się największą pojedynczą wygraną pod względem niezawodności: agenci, którzy widzą ekran, robią właściwą rzecz znacznie częściej niż agenci, którzy mają nadzieję.
Toolkit Browser MCP, który dostają Twoi agenci
Każdy agent AI z dostępem do przeglądarki startuje z tymi narzędziami dostępnymi. Są wystawione przez standardowy MCP, więc każdy kompatybilny CLI je widzi: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Otwórz URL w wbudowanej przeglądarce. Smart URL handling: localhost:3000 staje się http://localhost:3000 zamiast wyzwalać dialog 'cannot open application'. Zwraca finalny URL i screenshot strony po załadowaniu.
browser_click
Kliknij element po selektorze lub po widocznym tekście. Prawdziwy natywny click event, nie dispatch JavaScript. Zwraca post-click screenshot, więc agent widzi rezultat swojej akcji.
browser_type
Wpisz tekst w input lub textarea. Wspiera skróty klawiszowe i submit. Prawdziwe key eventy, handlery onChange strony odpalają. Zwraca screenshot po pisaniu.
browser_screenshot
Przechwyć aktualny viewport jako PNG. Przydatne do kontroli regresji wizualnej, design QA, porównań before-and-after lub do dzielenia się stanem buga z resztą zespołu.
browser_evaluate
Uruchom wyrażenie JavaScript w main world strony. Dostań z powrotem zserializowany rezultat. Używane przez agentów do czytania stanu strony, queryowania DOM, inspekcji store'a Redux lub wyzwalania akcji, która nie ma widocznego przycisku.
browser_wait_for
Czekaj, aż element się pojawi, aż URL się zmieni, aż request sieciowy się skończy lub aż dowolny JavaScript zwróci true. Unika klasycznego race'a 'agent klika za szybko'.
browser_get_state
Czytaj aktualny URL, tytuł, viewport, pozycję scrolla i ustrukturyzowany snapshot dostępnych elementów strony. Główny input agenta, gdy musi zaplanować kolejną akcję.
browser_get_logs
Wyciągnij bufor konsoli (log, warn, error). Agent może zobaczyć te same warningi React, błędy hydration, network failures i runtime exceptions, które widziałbyś Ty w DevTools. Bug reporty stają się 'oto błąd z konsoli'.
browser_go_back / forward / reload
Standardowa nawigacja przeglądarki, skryptowalna. Używana przez agentów do cofania, gdy flow idzie źle, lub do re-testowania strony po hot reloadzie z Vite, Next.js lub Expo Metro.
Co agenci faktycznie robią z przeglądarką
Prawdziwe workflow, które możesz zbudować już dziś, z rolą QA Engineer i Agent Teams.
End-to-end smoke test przy każdym handoffie
Połącz zespół Dev do QA. Agent QA nawiguje do Twojego dev servera localhost, klika przez krytyczne ścieżki (signup, checkout, dashboard), robi screenshot rezultatu i zatwierdza tylko, jeśli nic nie rzuca. Łap regresje, zanim człowiek otworzy stronę.
QA regresji wizualnej
Screenshoty before-and-after na zmianach UI. Agent ładuje stronę na poprzednim commitcie, screenshot, zmienia branch, screenshot, prosi Claude'a o porównanie. Tania QA wizualnego diffu bez Percy lub Chromatic w pętli.
Polowanie na błędy konsoli
Agent nawiguje po appce, wywołuje browser_get_logs, znajduje warningi hydration React, warningi useEffect, sieciowe 404, błędy CORS, deprecation notices. Raportuje je jako listę ryzyk w payloadzie handoff zespołu, kolejny agent Dev je naprawia.
Testowanie walidacji formularzy
Agent wypełnia formularz prawidłowymi danymi, pustymi polami, edge case'ami (stringi XSS, bardzo długie inputy, non-ASCII). Weryfikuje komunikaty walidacji, requesty sieciowe, redirecty. Prawdziwa QA formularzy, nie unit testy.
Audyt accessibility
Agent przechodzi po stronie, queryuje accessibility tree przez browser_get_state i browser_evaluate, sprawdza alt teksty, atrybuty ARIA, zarządzanie focusem, nawigację klawiaturową. Raportuje problemy ze screenshotami.
Design QA przeciwko Figma
Połącz z feature'em Figma to AI agents. Agent ładuje frame Figma, screenshot, ładuje stronę localhost, screenshot, porównuje spacing, fonty, kolory, alignment. Wystawia listę niezgodności.
Weryfikacja tunela live preview
Spruj z tunelem localhost AgentsRoom. Agent nawiguje do publicznego URL HTTPS preview (nie localhost), weryfikuje, że strona jest osiągalna z zewnątrz, robi screenshot i potwierdza, że stakeholder może faktycznie otworzyć link.
Reprodukcja buga klienta z publicznego ticketa backlogu
Wpada publiczny ticket backlogu z URL i krokami do reprodukcji. Agent QA otwiera URL, podąża za krokami, łapie błąd konsoli, dołącza screenshot, robi handoff do Dev z czystym repro. Koniec z pętlami 'cannot reproduce'.
Jak agent dostaje przeglądarkę
Otwórz zakładkę Browser w roomie
W roomie projektu prawy panel wystawia trzy zakładki: Files, Changes, Browser. Kliknij Browser. Panel się rozszerza, sidebar zwija, a pojawia się prawdziwa Chromium view. Wpisz URL lub wybierz z historii projektu.
Zaznacz 'Browser access' na agencie
Otwórz modal Edit Agent, rozwiń Capabilities, zaznacz Browser access. AgentsRoom wmerge'uje wpis agentsroom-browser do .mcp.json projektu i agent zobaczy narzędzia przeglądarki przy następnym starcie.
<project>/.mcp.jsonAgent startuje z browser MCP
Przy spawnie agenta Claude (lub Codex, Gemini itp.) inicjalizuje serwer MCP agentsroom-browser, listuje swoje narzędzia (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload) i od teraz może sterować przeglądarką.
Agent używa przeglądarki
Agent nawiguje, klika, pisze, robi screenshoty, czyta konsolę. Każda akcja idzie przez most loopback WebSocket (127.0.0.1, port przydzielany przez OS, 32-bajtowy token hex, regenerowany przy każdym bootcie aplikacji desktopowej). Po każdej akcji zmieniającej stronę screenshot jest zwracany inline, więc agent wizualnie weryfikuje swój ruch.
Auto-target localhost lub Twój tunel
Jeśli tunel localhost działa, pierwsza nawigacja ląduje na URL tunela. W przeciwnym razie pierwszy wykryty dev server. W przeciwnym razie https://localhost:3000. Połączone z Dev Terminals, agent dosłownie startuje dev server, potem otwiera go w przeglądarce, potem testuje.
Weryfikacja, screenshot, handoff
Gdy podpięte do Agent Teams, węzeł QA odpala swoje scenariusze, łapie screenshoty, ustawia flags.qaPassed w payloadzie handoff. Kolejny agent dziedziczy werdykt. Pass idzie do PM, fail wraca do Dev z podpowiedziami testowymi.
Pod maską
Dla ciekawskich. Stack browser automation jest celowo mały.
Każdy projekt ma jeden Chromium WebContentsView (nowoczesne API Electrona, nie zdeprekowane BrowserView), nakładany na główne okno na boundsach streamowanych z React renderera. Per-projektowa session partition trzyma cookies, localStorage i autentykację izolowane między projektami. Domyślne offscreen bounds pozwalają agentom wywoływać narzędzia browser nawet zanim człowiek otworzy zakładkę Browser, z 5-sekundowym timeoutem na screenshotach, by uniknąć zawieszeń.
Lekki serwer WebSocket (browser-bridge.ts) działa na porcie loopback wybranym przez OS, bound tylko do 127.0.0.1. Autentykacja używa 32-bajtowego tokena hex regenerowanego przy każdym bootcie desktopa. Plik mostu ~/.agentsroom/browser-bridge.json trzyma aktualny port, token i PID, atomowo przepisywany przy każdym bootcie, więc subprocess MCP zawsze podchwytuje świeże credentiale z automatycznym retry.
Sam serwer MCP to browser-mcp-server.cjs, zero-dependency skrypt Node implementujący protokół MCP 2024-11-05 przez stdio (initialize, tools/list, tools/call). Mówi JSON-RPC do mostu WebSocket przez ręcznie napisanego klienta WebSocket (bez ws, bez @modelcontextprotocol/sdk). Mały, szybki, łatwy do audytu. Dostarczany jako plik extraResources w aplikacji desktopowej, więc każda instalacja ma go gotowego do użycia.
Natywne wsparcie przeglądarki (first-class feature przeglądarki poza MCP) jest w roadmap AgentsRoom. Poza tym długoterminowy plan obejmuje dodatkowe MCP, by agenci mogli też sterować non-web targetami: MCP React Native dla aplikacji mobilnych i MCP Electron dla aplikacji desktopowych. Ta sama idea, ten sam UX: agent nie tylko pisze kod, faktycznie ćwiczy działającą aplikację.
FAQ
Czym to się różni od Playwright MCP lub narzędzi browser opartych na Puppeteerze?
MCP-y oparte na Playwright i Puppeteer spawnują świeżą headless przeglądarkę przy każdej sesji. To w porządku do bezstanowych zadań, ale traci cookies, localStorage i auth między wywołaniami, a człowiek nie widzi, co robi agent. AgentsRoom Browser to ta sama przeglądarka, której człowiek używa wewnątrz aplikacji, z persystentną sesją per projekt, widoczna dla użytkownika w czasie rzeczywistym. Agent steruje oknem, które możesz widzieć i przejąć w dowolnym momencie. To bardziej uczciwa, bardziej debuggable browser automation.
Czy działa z wszystkimi dostawcami AI, czy tylko z Claude Code?
Działa z każdym dostawcą wspieranym przez AgentsRoom: Claude Code, Codex CLI, OpenCode, Gemini CLI i Aider. Narzędzia przeglądarki są wystawiane przez standardowy Model Context Protocol, który wszystkie te CLI czytają z .mcp.json. Agent nigdy nie wie, że jest w AgentsRoom, widzi tylko zestaw narzędzi MCP i używa ich tak, jak używałby każdego innego narzędzia.
Czy agent może sterować zdalną stroną, czy tylko localhostem?
Obydwoma. Wpisz dowolny URL i jedź. Localhost (i formy host:port) są smart-detectowane, prefiksowane http:// i otwierane bezpośrednio. Strony publiczne działają jak w każdej normalnej przeglądarce, z cookies i stanem logowania zachowanym per projekt. Połączone z tunelem localhost AgentsRoom, agent może też sterować Twoim lokalnym dev serverem przez publiczny URL HTTPS, co jest przydatne do QA cross-network i mobilnego.
Czy browser MCP jest bezpieczny? Co stoi na drodze nadużycia?
Most binduje się tylko do 127.0.0.1, nigdy do 0.0.0.0. Port jest przydzielany przez OS (żaden stały port do collision-prone scanowania). 32-bajtowy token hex jest wymagany przy każdym połączeniu, regenerowany przy każdym bootcie desktopa. Subprocess MCP otrzymuje credentiale tylko przez env vary, nigdy w żadnym commitowanym pliku. Browser access jest opt-in per agent w modalu Edit Agent. Jeśli go usuniesz, wpis .mcp.json jest usuwany i agent nie może już używać narzędzi.
Czy agent widzi konsolę przeglądarki (błędy, warningi, sieć)?
Tak, przez browser_get_logs. Bufor trzyma wiadomości console.log, console.warn i console.error z main world strony. Wiele prawdziwych bugów (błędy hydration React, warningi useEffect, awarie CORS) wypływa tylko w konsoli, nigdy w unit testach, więc okazuje się to jednym z najbardziej sygnałowych narzędzi dla agenta QA.
Co dzieje się ze screenshotami zwracanymi do agenta? Czy kosztują dużo tokenów?
Po każdej akcji zmieniającej stronę screenshot PNG base64 jest dopisywany do odpowiedzi narzędzia, ograniczony do 1.6 MB. Powyżej tego wysyłany jest text marker. Screenshoty są krytyczne dla niezawodności (agent, który widzi ekran, popełnia znacznie mniej błędów), więc trade-off jest tego wart. Jeśli chcesz wyłączyć screenshoty z powodu budżetu, zwykłe wywołania browser_evaluate zwracają tylko tekst.
Czy agent może wypełnić formularz logowania? Persystować swoją sesję?
Tak. Cookies i localStorage są persystowane per projekt pod session partition persist:agentsroom-browser-<projectId>. Agent może zalogować się raz przez browser_type i browser_click i pozostać zalogowany przez resztę runa. Gdy zmieniasz projekt, sesja się zmienia, więc credentiale nigdy nie wyciekają między projektami.
Czy agent się złamie, jeśli dev server nie działa?
Nawiguje do URL i widzi stronę błędu Chromium. Może odczytać ten błąd przez browser_get_state i browser_get_logs i odpowiednio zareagować: poprosić Cię o uruchomienie servera lub wywołać komendę Dev Terminals, by go uruchomić. Z Agent Teams i Dev Terminals możesz podpiąć workflow, który startuje server, czeka, potem otwiera przeglądarkę, wszystko bez interwencji człowieka.
Czy aplikacje mobilne i desktopowe też są wspierane?
Web jest dowożony dziś, przez wbudowany Chromium i AgentsRoom Browser MCP. Roadmap obejmuje natywny AgentsRoom Browser jako first-class feature przeglądarki. Poza tym planowane są dodatkowe serwery MCP: MCP React Native, by agenci mogli sterować bundle'ami Expo iOS i Android, i MCP Electron, by agenci mogli sterować aplikacjami desktopowymi, które nie są web. Ta sama logika agenta, zastosowana do non-web targetów.
Czy człowiek może zatrzymać agenta i przejąć przeglądarkę?
Tak. Przeglądarka to ten sam Chromium view, którego używa człowiek. W dowolnym momencie kliknij w panelu Browser i jesteś w kontroli. Gdy przestaniesz wchodzić w interakcję, agent może wznowić swoje wywołania narzędzi. Nie ma koncepcji 'agent-locked browser', to wspólna powierzchnia, dokładnie jak sesja pair-programmingu.
Daj swoim agentom prawdziwe oczy w przeglądarce
Zaznacz Browser access na dowolnym agencie w AgentsRoom. Browser MCP startuje automatycznie. Twój agent QA w końcu testuje to, co dowozi.
Aplikacja towarzyszaca: monitoruj agentów w podrozy
Działa z Claude, Codex, OpenCode, Gemini CLI i Aider
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.