Automatyzacja przeglądarki dla agentów: Playwright, Chrome DevTools, Browser Use, Stagehand i agent-browser

Automatyzacja przeglądarki dla agentów kodujących występuje w dwóch odmianach. Deterministyczne sterowniki (Playwright MCP, Chrome DevTools MCP, agent-browser, dev-browser, Browser Use --cli-mcp) zostawiają każdą akcję agentowi kodującemu i pasują do testowania oraz profilowania własnej aplikacji. Frameworki agentów przeglądarkowych (Stagehand, biblioteka i chmura Browser Use) dokładają osobno płatny model, który planuje akcje na cudzych stronach.

Ta strona jest dla programistów i tech leadów, którzy wybierają, jakie narzędzie przeglądarkowe dostaną ich agenty. Agent melduje, że poprawka koszyka jest gotowa, ale nikt nie otworzył strony. Albo ktoś otworzył: podłączone są trzy serwery przeglądarkowe, w każdej sesji siedzą dziesiątki niemal identycznych schematów narzędzi, a „poprawkę wydajności” zmierzono na serwerze deweloperskim.

Co daje ten przewodnik po automatyzacji przeglądarki

Regułę wyboru: deterministyczny sterownik czy agent przeglądarkowy, i dlaczego ta różnica wychodzi na rachunku.
Macierz zadań: E2E własnej aplikacji, audyt wydajności, scraping cudzych stron i długie, wieloetapowe przepływy.
Sprawdzone polecenia instalacji dla Claude Code, Codex i Cursora, z wyłączoną telemetrią Chrome DevTools MCP.
Pełne dochodzenie w sprawie LCP z performance_start_trace i performance_analyze_insight oraz cztery prompty do skopiowania.
Dowody, które każde zadanie musi zostawić, żeby sprawdzać ślad albo test zamiast czytać diff agenta.

Deterministyczny sterownik czy agent przeglądarkowy: czego potrzebujesz?

Deterministyczny sterownik udostępnia prymitywy przeglądarki (nawigacja, snapshot, kliknięcie, ślad). Twój agent kodujący czyta stronę i sam wybiera każdą akcję, więc ten sam prompt na tej samej stronie daje te same wywołania, a każdy krok widać w transkrypcie. Framework agenta przeglądarkowego bierze krok opisany językiem naturalnym („wyeksportuj zamówienia z zeszłego tygodnia”) i przekazuje go własnemu modelowi, który planuje kliknięcia i przeplanowuje je, gdy strona się zmieni. Za ten model płacisz dodatkowo, a jego decyzje są o jeden poziom dalej od twojego review. Browser Use należy do obu grup: jego serwer --cli-mcp jest sterownikiem, który uruchamia kod napisany przez twojego agenta, a pętla agenta z własnym modelem istnieje tylko w bibliotece Pythona (Agent(task=..., llm=...)) i w Cloud API.

Narzędzie	Rodzaj	Jak agent z niego korzysta	Pakiet (sprawdzono 2026-09-26)	Dodatkowy koszt
Playwright MCP	Sterownik	Serwer MCP, snapshoty drzewa dostępności	npm `@playwright/mcp`	Brak
Chrome DevTools MCP	Sterownik + profiler	Serwer MCP albo plugin z siedmioma skillami	npm `chrome-devtools-mcp` 1.10.1	Brak; statystyki użycia trafiają do Google, dopóki ich nie wyłączysz
agent-browser	Sterownik	CLI w Rust + skill; istnieje też `agent-browser mcp`	npm `agent-browser` 0.38.1	Brak
dev-browser	Sterownik	Skrypty Puppeteera na „ciepłej” przeglądarce, CLI + skill; MCP tylko w 1.0	npm `dev-browser` (`latest` 0.2.9, `next` 1.0.0-rc.3)	Brak
Browser Use	Sterownik (wykonywanie kodu)	Serwer MCP `--cli-mcp`: agent uruchamia kod Pythona na Chrome przez `browser_exec`	PyPI `browser-use` 0.13.10	Brak dla `--cli-mcp`; przeglądarki w chmurze według cennika dostawcy, jeśli z nich korzystasz
Stagehand + Browserbase	Agent przeglądarkowy	SDK dla TypeScriptu, Pythona lub Go; hostowany MCP pod `mcp.browserbase.com`	npm `@browserbasehq/stagehand` 4.1.0	SDK: twój klucz do modelu (+ Browserbase, jeśli używasz przeglądarek w chmurze); hostowany MCP: klucz API Browserbase (według README zarchiwizowanego serwera; nie sprawdzano 2026-09-26)

Są też dwie drogi wbudowane. Claude Code ma integrację Claude in Chrome (claude --chrome), a Codex 0.157.1 wymienia browser_use, in_app_browser i computer_use jako funkcje stabilne, domyślnie włączone. To funkcje aplikacji agenta, a nie samodzielny serwer MCP, który rejestrujesz, przypinasz do wersji i izolujesz per agent w ten sam sposób w Claude Code, Codex i Cursorze. To drugie dają narzędzia z tej strony.

Które narzędzie przeglądarkowe do którego zadania?

Dla własnej aplikacji domyślnym wyborem zostają sterowniki: są tańsze, powtarzalne i zostawiają dowód, który da się uruchomić ponownie. Po Browser Use albo framework agenta przeglądarkowego sięgaj tylko wtedy, gdy strona nie jest twoja albo przepływ jest za długi, żeby go oskryptować ręcznie.

Zadanie	Pierwszy wybór	Alternatywa	Dlaczego	Dowód, który musi zostać
E2E własnej aplikacji: weryfikacja przepływu po zmianie	Playwright MCP albo Playwright CLI ze skillem, gdy brakuje kontekstu	agent-browser	Snapshoty drzewa dostępności, `--isolated` dla każdego agenta, a sprawdzenie może stać się zacommitowanym testem Playwrighta	Test, który przed poprawką nie przechodził, a po niej przechodzi, uruchamiany w CI
Audyt wydajności: regresje LCP, INP, CLS	Chrome DevTools MCP	`vitals` z agent-browser do szybkiego odczytu	Prawdziwe ślady DevTools i nazwane wnioski wydajnościowe; `lighthouse_audit` do dostępności, SEO i dobrych praktyk	Pliki śladów przed i po oraz różnica metryki
Debugowanie: błędy konsoli, nieudane żądania	Chrome DevTools MCP (stack trace z source mapami)	`browser_console_messages` i `browser_network_requests` z Playwright MCP	Ten sam widok DevTools, który otworzyłby człowiek	Nieudane żądanie lub stack trace, a potem to samo sprawdzenie bez błędów
Scraping cudzych stron	`extract` ze Stagehanda ze schematem zod albo hostowany MCP Browserbase	Browser Use	Wynik zwalidowany schematem, który przetrwa redesign, na przeglądarkach w chmurze, poza twoją maszyną	JSON zgodny ze schematem, liczba wierszy i trzy wiersze porównane ze stroną
Długie przepływy: eksporty z panelu, wieloetapowe formularze	Browser Use (`--cli-mcp`)	dev-browser, gdy potrzebna jest ciepła przeglądarka z nazwanymi stronami między wywołaniami	Browser Use steruje twoim prawdziwym, zalogowanym Chrome w trwałej sesji, więc agent nie loguje się ponownie między krokami; dev-browser trzyma stan bez ponownego uruchamiania	Zrzut ekranu z każdego kroku i sprawdzenie stanu końcowego
Kilka agentów naraz	Dowolny sterownik z izolacją per agent: Playwright `--isolated`, agent-browser `--session`, Chrome DevTools `--isolated`	Osobny `--user-data-dir` dla każdego agenta	Trwały profil Playwrighta może otworzyć tylko jedna przeglądarka naraz	Przebieg każdego worktree na własnym porcie

Zainstaluj deterministyczne sterowniki w Claude Code, Codex i Cursorze

Serwery MCP są takie same we wszystkich trzech narzędziach; różni się tylko rejestracja. Poniższe polecenia dodają Playwright MCP z --isolated (bezpieczne dla równoległych agentów) i Chrome DevTools MCP z wyłączonymi statystykami użycia.

# Terminal. Zakres local (ten projekt, tylko ty); --scope project udostępnia serwer przez .mcp.json
claude mcp add playwright -- npx @playwright/mcp@latest --isolated
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --no-usage-statistics

Chrome DevTools MCP jest też dostępny jako plugin z siedmioma skillami (m.in. debug-optimize-lcp, a11y-debugging i memory-leak-debugging). Jeśli się przełączasz, najpierw usuń zwykły serwer:

claude mcp remove chrome-devtools
claude plugin install chrome-devtools-mcp@claude-plugins-official
claude plugin details chrome-devtools-mcp   # prognozowany koszt w tokenach, zanim go zostawisz

Plugin (przypięty do chrome-devtools-mcp 1.9.0 na 2026-09-26, podczas gdy npm latest to 1.10.1, więc zostaje w tyle za samodzielnym serwerem) uruchamia serwer bez --no-usage-statistics i bez --no-performance-crux. Żeby statystyki zostały wyłączone, ustaw CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1 w powłoce albo w bloku env w ~/.claude/settings.json. Zapytania do CrUX wyłącza tylko flaga, więc przy adresach klienta i wewnętrznych zostań przy zwykłym serwerze.

# Terminal. Zapisuje [mcp_servers.<nazwa>] w ~/.codex/config.toml
codex mcp add playwright -- npx @playwright/mcp@latest --isolated
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --no-usage-statistics

Odpowiednik w TOML, jeśli edytujesz ~/.codex/config.toml ręcznie:

[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--no-usage-statistics"]

Dodaj serwery w Cursor Settings > MCP albo w pliku projektu .cursor/mcp.json (kształt pochodzi z README dostawców; nie testowano go tu w Cursorze):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--isolated"]
    },
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
    }
  }
}

Dwa sterowniki typu CLI + skill instaluje się tak samo dla każdego agenta, bo agent uruchamia je ze swojej powłoki:

# agent-browser: CLI, dołączony Chrome for Testing i zaślepka skilla
npm install -g agent-browser && agent-browser install
npx skills add vercel-labs/agent-browser

# dev-browser: 1.0 jest opublikowane tylko pod tagiem next; to ono dodaje serwer MCP
npm install -g dev-browser@next
dev-browser install-skill --claude     # albo --codex, albo --agents

Skill agent-browser to cienka zaślepka, która każe agentowi uruchomić agent-browser skills get core, więc instrukcje zawsze pasują do zainstalowanej wersji CLI. Strona o agent-browser opisuje pełną pętlę weryfikacji, a porównanie Playwright MCP i Playwright CLI omawia każdą flagę Playwrighta.

Wyłącz telemetrię Chrome DevTools MCP

Chrome DevTools MCP wysyła dane do Google na trzy sposoby i każdy ma osobny przełącznik (README, sprawdzono 2026-09-26):

Co opuszcza maszynę	Domyślnie	Jak wyłączyć
Statystyki użycia: skuteczność wywołań narzędzi, opóźnienia, dane o środowisku	Włączone	`--no-usage-statistics` albo zmienna `CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS`; zbieranie jest też wyłączone, gdy ustawiono `CI`
Adresy URL śladów wysyłane do API CrUX po dane terenowe od prawdziwych użytkowników	Włączone dla narzędzi wydajnościowych	`--no-performance-crux`
Sprawdzanie aktualizacji w rejestrze npm	Włączone	Zmienna `CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS`

Rezygnacja z metryk samej przeglądarki Chrome nie wyłącza statystyk serwera i odwrotnie. Przy pracy dla klienta albo na wewnętrznych adresach podawaj obie flagi. Zapytanie do CrUX wysyła adres, który profilujesz, więc nazwa hosta stagingu opuszcza twoją sieć, jeśli nie dodasz --no-performance-crux.

Znajdź przyczynę słabego LCP z Chrome DevTools MCP

Twierdzenie o wydajności bez śladu to zgadywanie. Ten przepływ każe agentowi zmierzyć, poprawić jedną rzecz i zmierzyć ponownie, na buildzie produkcyjnym.

Serwuj build produkcyjny. Serwer deweloperski dokłada niezbundlowane moduły i kod hot-reload, które zniekształcają każdy pomiar. Zbuduj aplikację i serwuj wynik na stałym porcie.
Poproś o ślad, nie o opinię. Wklej prompt poniżej. Agent wywołuje navigate_page, żeby otworzyć adres, potem performance_start_trace z reload: true i autoStop: true, i zapisuje surowy ślad przez parametr filePath.
Przeczytaj wnioski. Wynik śladu zawiera zestawy wniosków (insight sets). Agent wywołuje performance_analyze_insight z identyfikatorem zestawu i nazwą wniosku, np. LCPBreakdown albo DocumentLatency. LCPBreakdown dzieli LCP na fazy, co mówi, czy poprawiać serwer, zasób blokujący renderowanie, czy sam obraz.
Popraw jedną przyczynę i zmierz ponownie. Jedna zmiana na ślad pozwala przypisać różnicę. Agent nagrywa drugi ślad z tymi samymi ustawieniami i podaje obie liczby.
Zachowaj pliki. Oba ślady .json.gz trafiają do dowodów w pull requeście. Każdy otworzy je w panelu Performance w DevTools bez polegania na podsumowaniu agenta.

Use the chrome-devtools MCP tools. Run `npm run build && npm run preview -- --port 4321`
in the background and wait until http://localhost:4321/en/ answers.
1. navigate_page to http://localhost:4321/en/, then performance_start_trace with
   reload true, autoStop true, filePath "traces/lcp-before.json.gz".
2. From the insight sets, call performance_analyze_insight for LCPBreakdown and for
   any insight that names the LCP element or a render-blocking request.
3. Report LCP, the LCP element, and the phase that dominates (TTFB, load delay,
   load duration or render delay), quoting the trace numbers.
4. Propose ONE change that targets that phase, make it, rebuild, and trace again to
   "traces/lcp-after.json.gz" with identical settings.
5. Finish with a table: metric, before, after. If LCP did not improve by at least
   10%, revert the change and say so. Do not run lighthouse_audit for performance;
   it excludes performance.

Dwa szczegóły z dokumentacji narzędzi zmieniają to, o co prosisz. lighthouse_audit obejmuje dostępność, SEO, dobre praktyki i przeglądanie przez agentów, a wydajność wyklucza, więc prośba o „wynik wydajności z Lighthouse” po cichu nie zwraca nic przydatnego. A z zainstalowanym pluginem /chrome-devtools-mcp:debug-optimize-lcp pakuje kroki 2–4 w skill. Używaj go, gdy zaufasz tej pętli, i zachowaj tabelę „przed i po” jako kryterium akceptacji. Po liczby z testów obciążeniowych zamiast śladów pojedynczej strony idź do testów wydajności.

Dołóż Browser Use albo Stagehanda, gdy strona nie jest twoja

Browser Use i Stagehand opłacają się na stronach, których nie możesz zmienić: portal partnera, cennik konkurencji, panel administracyjny bez API. SDK Stagehanda i biblioteka Pythona Browser Use wywołują model, który sam konfigurujesz, i to do niego trafia treść strony. Hostowany MCP Browserbase potrzebuje klucza API Browserbase; według README zarchiwizowanego serwera hostowana usługa uruchamia własny model (Gemini) i sama za niego płaci. Samego endpointu tu nie sprawdzano (2026-09-26). Browser Use --cli-mcp nie uruchamia żadnego modelu; kod sterujący przeglądarką pisze twój agent kodujący.

# Browser Use: uruchamiany przez uvx na Pythonie 3.12; oficjalny plugin opakowuje to samo polecenie
claude mcp add browser-use -- uvx --python 3.12 browser-use@latest --cli-mcp

# Hostowany MCP Browserbase (navigate, act, observe, extract ze Stagehanda).
# Powłoka rozwija zmienną, więc klucz trafia do twojej lokalnej konfiguracji:
# zostaw domyślny zakres local i nigdy nie używaj tu --scope project.
claude mcp add --transport http browserbase https://mcp.browserbase.com/mcp \
  --header "Authorization: Bearer $BROWSERBASE_API_KEY"

codex mcp add browser-use -- uvx --python 3.12 browser-use@latest --cli-mcp

# Codex czyta token ze środowiska w chwili uruchomienia; nic nie jest zapisywane
codex mcp add browserbase --url https://mcp.browserbase.com/mcp \
  --bearer-token-env-var BROWSERBASE_API_KEY

Browser Use trafia do .cursor/mcp.json jak każdy serwer stdio:

{
  "mcpServers": {
    "browser-use": {
      "command": "uvx",
      "args": ["--python", "3.12", "browser-use@latest", "--cli-mcp"]
    }
  }
}

Browserbase dodaj w Cursor Settings > MCP jako https://mcp.browserbase.com/mcp z nagłówkiem Authorization i trzymaj klucz poza każdym mcp.json, który commitujesz.

Browser Use zbiera telemetrię; uruchom browser-use telemetry status i wyłącz ją, zanim skierujesz go na systemy klienta.

To, co każdy z nich udostępnia, decyduje o tym, jak nim zarządzać:

Browser Use --cli-mcp odpowiedział na handshake MCP dokładnie dwoma narzędziami: browser_exec i browser_screenshot (przetestowano na 0.13.10). browser_exec uruchamia pomocniczy kod Pythona na przeglądarce. Traktuj go jak dostęp do powłoki: trzymaj go poza listami automatycznej zgody i z dala od sesji z produkcyjnymi poświadczeniami.
Stagehand to SDK, nie serwer. Sięgaj po niego, gdy automatyzacja ma działać dalej po odejściu agenta: observe() zwraca prawdziwe selektory, więc poświadczenia wypełnia kod i nigdy nie trafiają do modelu, a extract(instruction, schema) zwraca dane zwalidowane schematem zod. Hostowany MCP Browserbase daje agentowi te same navigate, act, observe i extract bez lokalnej przeglądarki.

Use the browserbase tools. Start a session, navigate to https://www.example.com/pricing
and extract every plan as {name: string, monthlyPriceUsd: number | null, seatLimit:
number | null}. Use null when the page does not state a value; never estimate.
Then:
- print the JSON array and the row count,
- list any plan whose price text you could not parse, quoting the raw text,
- end the session.
Do not click sign-up, contact or cookie-consent buttons.

Use the browser-use tools. The connected Chrome is already logged in to
https://staging.example.com/admin with a test admin account; do not log out and do
not open any other site. Go to Orders, filter to the last 7 days, export as CSV, and
tell me how many orders are refunded.
After every step, call browser_screenshot; if it returns an image rather than a
file, save it with browser_exec to steps/NN-<step>.png.
If a step fails twice, stop and report the screenshot and the error instead of
trying a different route.

Jak udowodnić, że przebieg w przeglądarce coś znaczy?

Narzędzie przeglądarkowe przyspiesza agentowi ogłaszanie sukcesu. Sens przebiegu leży w artefakcie, który zostawia, a który recenzent sprawdzi w kilka minut bez czytania diffu linijka po linijce.

E2E własnej aplikacji: agent zamienia sprawdzenie w przeglądarce w test Playwrighta, uruchamia go na niepoprawionym kodzie (czerwony), potem na poprawionym (zielony). CI uruchamia go przy każdym pull requeście. Recenzent pull requesta podpisuje się pod testem i jego czerwonym przebiegiem, nie pod narracją agenta. Zobacz weryfikację E2E prowadzoną przez agenta i siłę wyroczni testowej.
Wydajność: dwa pliki śladów i tabela „przed i po” z progiem ustalonym przed zmianą (prompt powyżej używa 10%). Bez śladu nie ma twierdzenia.
Scraping: wynik zgodny ze schematem, liczba wierszy i trzy wiersze porównane przez człowieka z żywą stroną. Schemat łapie zły kształt; tylko wyrywkowa kontrola łapie wartości wiarygodne, ale błędne.
Długie przepływy: zrzut ekranu z każdego kroku plus sprawdzenie stanu końcowego, którego agent nie podrobi, np. liczba wierszy w wyeksportowanym pliku.

Dołącz to do pull requesta jako pakiet dowodów. W zespole zapisz regułę „zmiana widoczna dla użytkownika idzie z dowodem z przeglądarki”; jak zapisać to jako politykę zespołu, opisuje polityka E2E.

Ile kontekstu kosztują serwery przeglądarkowe?

Każdy podłączony serwer MCP wkłada schematy swoich narzędzi do sesji. Dokumentacja narzędzi Chrome DevTools MCP wymienia 59 narzędzi: wprowadzanie, nawigacja, emulacja, wydajność, sieć, debugowanie, pamięć, rozszerzenia i inne (wrzesień 2026). Tryb --slim zostawia tylko podstawowe zadania przeglądarkowe. README Playwright MCP samo mówi agentom kodującym, że „might benefit from using the CLI+SKILLS instead”, bo schematy narzędzi i drzewa dostępności są duże.

Mierz zamiast zgadywać: w Claude Code uruchom /context przed dodaniem serwera i po nim, a dla pluginu claude plugin details <plugin>, który pokazuje prognozowany koszt. Profiler (Chrome DevTools) podłączaj tylko w sesjach, które profilują, a do codziennej weryfikacji używaj sterownika CLI + skill. Szerzej o budżecie pisze strona o koszcie tokenów MCP.

Jak popularne są te narzędzia przeglądarkowe?

Stan na 2026-09-26, według gwiazdek na GitHubie (GitHub API): Browser Use ★116,3 tys., Chrome DevTools MCP ★52,6 tys., agent-browser ★43,2 tys., Playwright MCP ★37,6 tys., Stagehand ★25,4 tys. i dev-browser ★6,6 tys. W katalogu Claude Marketplace tego samego dnia plugin playwright miał 319 887 instalacji, a chrome-devtools-mcp 102 569. Zestawienie LinklyAI/best-skills oparte na skills.sh (SECONDARY, 2026-09-26) podawało dla agent-browser około 945 tys. instalacji skilla; sprawdź skills.sh ponownie, zanim to zacytujesz. Gwiazdki mierzą uwagę, nie przydatność do twojego zadania; do tego służy macierz powyżej.

@modelcontextprotocol/server-puppeteer jest przestarzały i zarchiwizowany. Użyj Chrome DevTools MCP, który steruje Chrome przez Puppeteera.
@microsoft/playwright-mcp i @playwright/mcp-server nie istnieją; playwright-mcp bez zakresu @... to zupełnie inny, niepowiązany projekt. Właściwy to @playwright/mcp.
@chrome-devtools/mcp i @google/chrome-devtools-mcp nie istnieją. Pakiet to chrome-devtools-mcp, bez prefiksu @....
browser-use na npm to niepowiązana biblioteka TypeScript. Browser Use to pakiet PyPI browser-use, uruchamiany przez uvx.
Pakiet stagehand na npm bez prefiksu @... jest niepowiązany; SDK to @browserbasehq/stagehand. @browserbasehq/mcp-server-browserbase jest przestarzały, a jego repozytorium zarchiwizowane; używaj hostowanego adresu.
npm install -g dev-browser instaluje 0.2.9, które nie ma podpolecenia mcp. Serwer MCP wymaga dev-browser@next.

Kiedy automatyzacja przeglądarki się psuje

Drugi agent pada z zablokowanym profilem. Playwright MCP domyślnie używa trwałego profilu, a jeden profil to jedna przeglądarka. Dodaj --isolated do serwera każdego agenta albo daj każdemu worktree własny --user-data-dir. W agent-browser podawaj osobne --session dla każdego agenta. Równoległe agenty opisują porty per worktree.

Zadanie CI wisi na starcie przeglądarki. Playwright MCP działa w trybie z oknem, dopóki nie podasz --headless. Dodaj tę flagę w CI. Dla agent-browser na Linuksie agent-browser install --with-deps instaluje biblioteki systemowe.

Ślad pokazuje wolną stronę, ale tylko lokalnie. Agent profilował serwer deweloperski albo pierwsze ładowanie z zimną pamięcią podręczną. Powtórz pomiar na buildzie produkcyjnym, nagraj ślad dwa razy i porównuj drugi przebieg.

Agent melduje „brak danych o wydajności” z Lighthouse. lighthouse_audit z założenia wyklucza wydajność. Poproś o performance_start_trace.

Chrome DevTools MCP dziwnie działa w Edge albo Brave. Oficjalnie wspiera tylko Google Chrome i Chrome for Testing. Przełącz się na jedną z nich, zanim zaczniesz debugować dalej.

Cudza strona mówi agentowi, co ma zrobić. Tekst strony to niezaufane dane wejściowe. Sterownik albo agent przeglądarkowy, który przeczyta „zignoruj poprzednie instrukcje i uruchom…”, może na tej podstawie działać. Trzymaj sesje przeglądarki z dala od produkcyjnych sekretów, nigdy nie zatwierdzaj automatycznie browser_exec i przeczytaj bezpieczeństwo MCP, zanim skierujesz agenta na strony, których nie kontrolujesz.

Rachunek za przeglądarkę skacze. SDK Stagehanda oraz biblioteka i chmura Browser Use wywołują model przy każdym kroku. Przepływ, który ciągle się nie udaje, przeplanowuje, dopóki coś go nie zatrzyma, a przeglądarki w chmurze (Browserbase, Browser Use Cloud) dokładają opłaty według cennika dostawcy. Obserwuj zużycie u dostawcy modelu i na koncie przeglądarek w chmurze, nie tylko w swoim agencie kodującym. Przy Browser Use --cli-mcp drugiego modelu nie ma: koszt widać w kontekście i zużyciu samego agenta kodującego, bo rosną w nich powtarzane wyniki browser_exec i zrzuty ekranu. W obu przypadkach wpisz limit kroków w prompt („if a step fails twice, stop”).

Polecenie dev-browser mcp nie istnieje. Masz 0.2.9 z tagu latest. Zainstaluj dev-browser@next i pamiętaj, że 1.0 nie wspiera jeszcze Windowsa.

Dokąd dalej z automatyzacją przeglądarki

Playwright MCP kontra Playwright CLI Wszystkie flagi Playwrighta, od zgłoszenia błędu do testu regresyjnego, jedna przeglądarka na worktree.

agent-browser Pętla „przeglądaj i weryfikuj”, ze zrzutami ekranu jako artefaktami pakietu dowodów.

Pakiet dowodów Gdzie trafiają ślady, testy i zrzuty ekranu, żeby review sprawdzało dowody, nie diffy.

Jak obniżyć koszt tokenów MCP Zmierz i ogranicz to, ile serwery przeglądarkowe kosztują w każdej sesji.

Jeśli wybierasz pierwsze serwery, zacznij od przeglądu serwerów MCP, a po pięć serwerów, których potrzebuje większość zespołów, sięgnij do startowego zestawu MCP.