Playwright MCP: niech agent AI udowodni, że to działa

Playwright MCP to serwer MCP od Microsoftu, który daje agentowi AI prawdziwą przeglądarkę: otwiera strony, klika, wpisuje tekst i czyta, co jest na ekranie. Używamy go do jednego zadania. Zanim ktokolwiek powie „gotowe”, agent przechodzi zmianę w działającej aplikacji i oddaje PASS lub FAIL dla każdego scenariusza, ze zrzutami ekranu.

Zielony typecheck dowodzi, że kod się kompiluje. Przechodzący test komponentu dowodzi, że komponent renderuje się we własnym środowisku testowym. Żaden z nich nie dowodzi, że prawdziwa strona z prawdziwymi danymi robi to, o co prosiło issue. Tę lukę zamyka kontrola w przeglądarce.

Czym jest Playwright MCP i jak działa?

MCP, czyli Model Context Protocol, to sposób, w jaki agent taki jak Claude Code dostaje dodatkowe narzędzia. Serwer Playwright MCP dodaje narzędzia przeglądarki oparte na Playwright: nawigację, klikanie, wpisywanie, wypełnianie formularzy, odczyt konsoli i żądań sieciowych, zrzuty ekranu.

W Claude Code to jedno polecenie:

claude mcp add playwright npx @playwright/mcp@latest

Kluczowy szczegół: agent nie patrzy na piksele. Według README pracuje „through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models”, czyli przez ustrukturyzowane snapshoty dostępności, bez zrzutów i modeli wizyjnych. Agent dostaje stronę jako drzewo przycisków, linków, nagłówków i pól formularza z ich etykietami. Klika przycisk o nazwie „Zapisz”, a nie punkt o współrzędnych, gdzie kiedyś był przycisk.

Wynikają z tego dwa efekty uboczne. Strona, której przyciski nie mają dostępnej nazwy, jest trudna także dla agenta, więc kontrola jest przy okazji małym przeglądem dostępności. A agent nadal może zrobić zrzut ekranu, gdy człowiek musi zobaczyć wynik.

Domyślnie serwer trzyma trwały profil przeglądarki, więc logowanie przetrwa między sesjami. Do uruchomień, które muszą zaczynać od zera, jest --isolated, a --storage-state wczytuje zapisane ciasteczka do tego czystego kontekstu.

Jak sprawiamy, że agent sprawdza własną zmianę?

Metoda jest w naszym skillu browser-qa. Nie zmienia kodu aplikacji. Zapisuje dowody:

Skill mówi też, co robić, gdy automatyzacja czegoś nie potrafi. Element zagnieżdżony tak głęboko, że kliknięcie nie działa niezawodnie, dostaje notatkę „needs manual click”. Nie jest po cichu oznaczany jako FAIL ani pomijany.

Nie każda kontrola wynika ze spisanego scenariusza. Czasem najlepsza jest otwarta:

Przejście jako persona znajduje to, czego nikt nie zapisał: mylącą etykietę, ślepy zaułek, krok, który ma sens tylko dla tego, kto go zbudował.

Co oddaje agent i kto to sprawdza?

Raport, który agent pisze sam o sobie, jest nadal tylko twierdzeniem. Dlatego kształt dowodów jest stały i sprawdza go skrypt, a nie model.

W naszej pętli agentów zadanie QA każe agentowi używać narzędzi przeglądarki Playwright i zapisać wszystko w evidence/<issue>/: zrzut ekranu dla każdego scenariusza, błędy konsoli i sieci oraz report.md. Resztę robi gate.sh, zwykły skrypt bash z kodami wyjścia:

n=$(grep -cE '\b(PASS|FAIL|PARTIAL)\b' "$tree/$rep"); shots=$(ls "$tree/$(dirname "$rep")"/*.png 2>/dev/null | wc -l | tr -d ' ')
[ "$n" -gt 0 ] && [ "$shots" -gt 0 ] || { echo "FAIL: report needs PASS/FAIL per scenario and screenshots" >> "$out"; exit 1; }

Brak raportu, brak linii z werdyktem albo brak zrzutu oznacza, że zadanie nie jest gotowe, cokolwiek mówi agent.

Zadania z kodem mają podobną zasadę. Gdy pull request zmienia pliki interfejsu, pętla wymaga before-*.png i after-*.png. Jeśli jest dobry powód, by ich nie było, PR musi to powiedzieć w linii zaczynającej się od No screenshots:. Recenzent widzi wtedy zmianę, zamiast ją sobie wyobrażać.

Ta zasada wzięła się z naszego własnego błędu. Przed poprawką każdy PNG liczył się jako dowód, więc wystarczył jeden zrzut czegokolwiek. Teraz muszą być dwa i muszą mieć nazwy mówiące, co pokazują.

Co wychwytuje kontrola w przeglądarce, a czego nie widzą testy jednostkowe?

Test jednostkowy zadaje wąskie pytanie w kontrolowanym pokoju. Przeglądarka pyta, czy ten pokój w ogóle istnieje.

Obie kolumny są ważne. Zasada red-green dla testów jednostkowych jest w artykule Red-green TDD z agentami AI. Kontrola w przeglądarce stoi na niej, a nie zamiast niej.

Uczciwie o granicach: nie liczyliśmy, ile błędów wychwytują kontrole w przeglądarce w porównaniu z testami. Wiemy, jakiego rodzaju są: to rzeczy, które istnieją dopiero wtedy, gdy wszystko jest połączone.

Playwright MCP, skrypty Playwright czy Chrome DevTools MCP?

Nawet zespół Playwright mówi, że MCP nie zawsze jest właściwym narzędziem. Ich README poleca agentom programistycznym Playwright CLI ze skillami, bo jest „more token-efficient”, czyli zużywa mniej tokenów. MCP, jak piszą, „remains relevant for specialized agentic loops”: ma sens w wyspecjalizowanych pętlach agentów, takich jak automatyzacja eksploracyjna czy długotrwałe autonomiczne przepływy.

To zgadza się z tym, co widzimy:

Gdy w tym tygodniu audytowaliśmy tę stronę, w ogóle nie użyliśmy MCP. Agent napisał zwykłe skrypty Playwright na lokalnym buildzie: kontrast tekstu mierzony z obliczonych kolorów, skan dostępności axe, każdą stronę wyrenderowaną w szerokości telefonu i wydajność przy spowolnionym CPU. To kontrole, które chcemy powtarzać po każdej zmianie. Skrypt robi to za każdym razem tak samo. Agent improwizujący kliknięcia nie.

A od tego tygodnia nasz interaktywny skill browser-qa najpierw próbuje Chrome DevTools MCP, jeśli sesja go ma. Metoda nie zmieniła się wcale. Sterownik przeglądarki to część wymienna.

Gdzie to się psuje?

Kilka pułapek, które znamy z naszych zasad albo z własnych błędów:

• Dane testowe. Zielone przejście po pustej bazie danych dowodzi układu i niczego więcej. Skill zabrania uznawać to za gotowe.
• Token sesji. Playwright MCP ma narzędzia, które czytają ciasteczka i local storage. Nasza zasada jest starsza niż jakiekolwiek narzędzie: agent nigdy nie wyciąga, nie loguje ani nie przekazuje tokena sesji.
• Ocena na oko. „Suma wygląda dobrze” na zrzucie to zgadywanie. Agent odczytuje wartość ze strony.
• Dwóch agentów, jeden profil. Z trwałego profilu może naraz korzystać tylko jedna przeglądarka. Uruchomienia równoległe potrzebują --isolated albo własnego katalogu profilu.

Czym są agenci Playwright i czy ich używamy?

Agenci Playwright, oficjalnie Playwright Test Agents, to trzy definicje agentów dostarczane razem z Playwright. Według dokumentacji Playwright (stan na 24.10.2026): planner „explores the app and produces a Markdown test plan”, czyli eksploruje aplikację i pisze plan testów w Markdown; generator „transforms the Markdown plan into the Playwright Test files”, czyli zamienia plan w pliki Playwright Test; a healer „executes the test suite and automatically repairs failing tests”, czyli uruchamia testy i automatycznie naprawia te, które nie przechodzą. Do Claude Code dodaje się je jednym poleceniem:

npx playwright init-agents --loop=claude

Planner zaczyna od seed testu, tests/seed.spec.ts, który przygotowuje środowisko, i zapisuje plan w specs/. Generator zamienia plan w testy w tests/ i na żywo sprawdza selektory i asercje, przechodząc scenariusze.

Uczciwie: w naszych projektach nie używaliśmy jeszcze agentów Playwright. Nasi agenci piszą testy Playwright z kryteriów akceptacji issue we własnej pętli, a eksplorowaniem zajmuje się skill browser-qa. Planner i generator robią w dużej mierze to samo we własnym formacie Playwright, więc warto je wypróbować w zespole, który nie ma własnej pętli.

Na healera uważalibyśmy. Dokumentacja mówi, że jego wynikiem jest „a passing test, or a skipped test if the healer believes that functionality is broken”, czyli przechodzący test albo test pominięty, jeśli uzna, że funkcja jest zepsuta. W naszej pętli pominięty test niczego nie dowodzi, a test czerwony dlatego, że produkt się zepsuł, musi zostać czerwony. Jeśli wypróbują Państwo healera, proszę przeglądać każdy zmieniony przez niego lokator czy asercję jak każdy inny pull request.

Czy Państwa zespół jest gotowy, by agent sprawdzał w przeglądarce?

Proszę przejść przez to, co już Państwo mają:

Jeśli chcą Państwo gotowej bazy, nasz publiczny Claude Code production starter już uruchamia smoke test Playwright w CI i wysyła raport, gdy test nie przejdzie. Jak działa cała pętla wokół niego, opisuje artykuł Harness engineering w praktyce: od issue do PR.

Chcą Państwo agentów, którzy udowadniają swoją pracę w Państwa repozytorium?

Kontrole w przeglądarce, zasady dowodów i CI wokół nich ustawiamy bezpośrednio w repozytorium zespołu w ramach AI-native SDLC dla zespołów deweloperskich. Państwa zespołowi brakuje bardziej rąk niż procesu? Proszę zobaczyć seniora dla Państwa zespołu. Większość naszego kodu pisze AI. Senior sprawdza każdą zmianę i odpowiada za to, co trafia na produkcję. Od 2023 roku dostarczyliśmy ponad 15 projektów produkcyjnych.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Kto w Państwa zespole sprawdza dziś, że zmiana działa w przeglądarce, i jak to udowadnia?

Najczęstsze pytania

Czym jest Playwright MCP?

Serwerem MCP od Microsoftu, który daje agentowi AI narzędzia przeglądarki oparte na Playwright: otworzyć stronę, kliknąć, wpisać tekst, wypełnić formularz, odczytać konsolę i żądania sieciowe, zrobić zrzut ekranu. Agent czyta stronę jako snapshot dostępności, a nie jako piksele.

Jak dodać Playwright MCP do Claude Code?

Proszę uruchomić claude mcp add playwright npx @playwright/mcp@latest. Inni klienci MCP używają tego samego serwera z poleceniem npx i argumentem @playwright/mcp@latest w konfiguracji.

Czy Playwright MCP zastępuje testy end-to-end?

Nie. MCP służy do eksplorowania i jednorazowego sprawdzenia jednej zmiany. Kontrola, której chcą Państwo przy każdym pull requeście, należy do testu lub skryptu Playwright uruchamianego w CI, bez proszenia o to agenta.

Jak agent testuje strony za logowaniem?

Najpierw człowiek loguje się w przeglądarce, której używa agent, a agent pracuje w tej sesji. Nasza zasada: agent nigdy nie czyta, nie loguje ani nie przekazuje tokena sesji. Przy odizolowanych uruchomieniach Playwright MCP może wczytać zapisany storage state.

Czy raport QA od agenta wystarczy, by uznać zmianę za gotową?

Tylko z dowodami: werdykt dla każdego scenariusza i zrzuty ekranu obok. W naszej pętli skrypt gate blokuje przekazanie, gdy brakuje raportu lub zrzutów, a pull request i tak przegląda człowiek.