Playwright agenti, MCP a CLI: Jak se v tom vyznat?

Playwright, MCP a CLI: Co to vlastně všechno znamená 

Playwright je automatizační framework, který umožňuje programaticky ovládat webové prohlížeče (Chrome, Firefox, Safari). Slouží nejen pro QA testy, ale i pro web scraping či monitoring webů. 

MCP (Model Context Protocol) je open-source standardizovaný protokol pro komunikaci mezi AI aplikacemi a externími systémy. Umožňuje AI agentům „hovořit” s aplikacemi, CLI nástroji a dalšími službami strukturovaným způsobem. 

CLI (Command Line Interface) jsou nástroje, které pracují za pomoci příkazové řádky – ideální pro integraci do skriptů, automatizace a CI/CD pipelines. 

V kontextu automatizace za pomoci AI a Playwrightu se pak nabízí několik cest. 

Playwright MCP 

Asi nejjednodušší způsob, jak zapojit AI do automatizace s využitím Playwrightu, je použít oficiální MCP server. Ten umožní LLM modelu – přes obsluhujícího agenta – automatizovat úkoly, které uživatel zadá přes textový prompt. Použití je jednoduché – v rámci kódu projektu nainstalujete knihovnu s MCP serverem, “zapojíte” ji do konfigurace svého agenta a ten ji začne automaticky používat. 

Tento způsob s sebou nicméně nese několik problémů. 

Za prvé, automatizace browserů přes MCP přináší velkou spotřebu tokenů, protože MCP posílá do LLM kontextového okna, jehož velikost je omezená, spoustu informací o nástrojích, které MCP má k dispozici, a také veškeré informace o webových stránkách (například celý zdrojový kód či screenshoty), které nejsou k vykonání úkolu nezbytně potřeba. Nezřídka se také stává, že obsah posílaný v kontextu limit okna přesáhne a LLM tak ani nemůže všechny informace zpracovat. 

Za druhé, samotné MCP neříká LLM modelu, jakým způsobem má generovat výstup, který po něm chcete. Pokud modelu například zadáte, aby prošel aplikaci a napsal například test pro přihlášení uživatele, výsledný kód může být opravdu nepěkný. 

Playwright agenti 

Druhý problém by měli vyřešit Playwright agenti. Konkrétně přišel tým stojící za Playwrightem se třemi: 

• plánovač (planner) 
• generátor (generator) 
• léčitel (healer) 

Funguje to tak, že zadáním jednoduchého příkazu Playwright vygeneruje nutné konfigurace pro podporovaný AI nástroj, který si zvolíte. V současné době podporuje VSCode, Claude Code a Opencode. 

Ve své podstatě každý Playwright agent představuje specifický markdown soubor, který specifikuje personu agenta a pravidla, která musí dodržovat při své činnosti. Obsahuje i šablony pro výstupy, pokud je daný agent generuje. 

Toto už je mnohem lépe fungující způsob použití AI společně s Playwrightem. Díky definovaným rolím a pravidlům agentů je výstup kvalitnější a více konzistentní. 

Bohužel v tomto případě se budete stále potýkat s velkou spotřebou tokenů. 

Playwright CLI 

V tuto chvíli nejnovější nástroj od Playwright týmu. Jednoduše řečeno se jedná o knihovnu, která poskytuje CLI rozhraní, přes které se obsluhuje samotný Playwright. Je třeba říct, že je v tuto chvíli stále pod velmi aktivním vývojem a v době psaní tohoto blogu nebyla vydána produkční verze (tj. v1.0.0). 

Jeho hlavním výhodou oproti “nativním” Playwright agentům je výrazně nižší spotřeba tokenů, protože neposílá surová data o navštívených webových stránkách do LLM modelu. Do modelu se typicky posílají jen extrahované výstupy nebo stručné shrnutí. 

Prakticky tento nástroj použijete tak, že po nainstalování knihovny ji jednoduchým příkazem inicializujete. To prakticky znamená automatické vytvoření markdown souborů s tzv. Skills. 

V době psaní tohoto blogu podporovala knihovna automatické generování skills souborů způsobem kompatibilním pouze s Claude Code nástrojem. Nicméně je otázkou chvilky si takto vygenerované soubory přestrukturovat tak, aby vyhovovaly jiným nástrojům. A například Opencode dokáže automaticky najít skills soubory i pokud jsou v konfiguraci pro Claude. 

Používání skills je trendem posledních měsíců. Cílem je minimalizovat spotřebu tokenů a tím co nejvíce zpomalit zaplňování kontextového okna. Menší spotřeba tokenů pak také snižuje náklady. Taková úspora u nejnovějších modelů – v době psaní tohoto blogu šlo například o Claude Opus 4.6., který má trojnásobnou spotřebu tokenů oproti např. Claude Sonnet 4.5, není vůbec zanedbatelná. Využití CLI oproti MCP pak může znamenat úsporu o až 60-80 % tokenů v závislosti na povaze zadaného úkolu. 

V kontextu Playwrightu pak samotný tým Microsoftu v dokumentaci doporučuje používat MCP u vysoce specializovaných agentických procesů, jako je například průzkumná automatizace nebo samo-léčící se testy. 

Pro úkoly, které musí balancovat automatizaci webového prohlížeče s interakcemi s velkým množstvím již existujícího kódu a testy v rozsahu omezeného kontextového okna, doporučuje používat CLI společně se skills. 

Co jsou to vlastně ty skills? 

Skilly jsou jednoduše markdown soubory, které dávají agentům schopnosti “porozumět” specifickým aplikacím, nástrojů a rozhraním. Uživatel na skilly odkáže v promptu, pokud jsou třeba a agent je automaticky nahraje a zařadí do kontextu pro LLM model. 

Z pohledu bezpečnosti musím upozornit na to, že pokud si nepíšete skills soubory sami, ale stahujete si je z různých “tržišť”, vždy důkladně čtete, co obsahují. Infikované skills soubory, které obsahují nepřátelské příkazy pro LLM, jsou velké bezpečnostní riziko. 

Skills jsou dobrý sluha, ale zlý pán 

Jak již bylo zmíněno výše, pokud nechcete psát skills soubory sami, existují “tržiště”, kde si můžete zadarmo stáhnout obsah, který byl vytvořený někým jiným. 

Nicméně problémem takových skills může být, že mohou obsahovat neexistující příkazy a chybné či rovnou škodlivé informace pro agenty a uživatele obecně.  

Příkladem mohou být příkazy pro LLM model, který je v textu markdown souboru “skryt” za pomocí tagu komentáře. V takovém případě, pokud si neprohlížíte obsah souboru v surové formě zdrojového kódu, ale přes náhled (jako mnoho uživatelů), takový škodlivý obsah neuvidíte. LLM ale ano a bude se jím řídit. 

Dalším problémem může být šíření neexistujících příkazů napříč skilly. Pokud někdo vygeneruje skill soubor za pomoci AI a neověří platnost obsahu, pak halucinace v něm se velice snadno rozšíří do dalších skillů. 

Velice pěkné video na toto téma si můžete pustit zde. Video je v angličtině. 

Co použití AI slibuje 

Existuje již řada implementací, ať už na jednoduchých “demo” aplikacích, nebo v produkčních prostředích: 

• Automatické generování testů: Agent analyzuje kód a webové rozhraní, navrhuje scénáře a píše testy. 
• End-to-End monitorování: Agent pravidelně automatizuje kontrolu webové aplikace, detekuje výpadky nebo neobvyklé chování. 
• Inteligentní scrapování: Agenti mohou adaptivně procházet weby a extrahovat data. 

Zní to fantasticky. Realita však naráží na řadu problémů. Některé z nich uvádím níže.

Reálné Problémy: Co v ukázkových demech nenajdete 

1. Nedeterministická podstata AI modelů 

Každý běh AI agenta může generovat jiné výsledky. To není chyba – je to vlastnost. Stejný vstup nemusí produkovat stejný výstup. 

Pokud se zaměřím například na vlastní zkušenost s Playwright agentem “plánovačem”, tak stejné zadání pro vygenerování test plánu pokaždé vrátilo více či méně odlišné testovací scénáře. To nemusí být nutně to co chcete. Pomoci může spouštět generování opakovaně a pak manuálně vybrat k implementaci pouze ty scénáře, které dávají reálný smysl. Nicméně toto pak malinko bourá “sen” o zcela autonomní práci agentů. A opakované spouštění stejného promptu pochopitelně není zadarmo. 

2. Snaha tvořit testy, které prochází 

AI modely jsou trénovány tak, aby byly užitečné a produkovaly výsledky. V kontextu testování to znamená: agenti jsou motivováni psát testy, které projdou. 

To pak může způsobovat falešná pozitiva. Test projde, ale nedetekuje skutečné chyby. Agent nemusí pochopit, proč by měl test selhat – jen že má procházet. 

Opět z vlastní zkušenosti s Playwright agenty, tentokrát s generátorem testů, mohu říci, že agent se opravdu snaží, aby výsledný test splnil zadání vygenerovaného test plánu. Zejména, pokud se jedná o složitější funkci, či delší E2E průchod aplikací, vygenerovaný kód je složitý na porozumění a velice špatně čitelný. 

3. Agent léčí testy za každou cenu 

Agent léčitel je připraven opravit selhávající testy. Cíl se může zdát v pořádku – automaticky opravit selhávající testy a tím zlepšit kvalitu. Problém může být v motivaci – agent se snaží opravit test za každou cenu, tak aby procházel. 

Důsledkem může být, že testy se “opravují” nesprávně. Místo diagnózy problému agent může prostě změnit “assertion” nebo přeskočit problémový krok. Výsledné testy pak mohou poskytovat nesprávný obraz o stavu testované aplikace. 

Z vlastní zkušenosti mohu říct, že opravy jednoduchých problémů v testech fungují přes Playwright agenta léčitele poměrně dobře. U složitých testů, kde problémem nebyl pouze například zastaralý selektor elementu atp., jsem se nicméně setkal většinou s tím, že agent se zacyklil ve snaze jej opravit a v podstatě toho nebyl schopen. 

4. Agent ignoruje nastavená pravidla 

Mám častou zkušenost s tím, že ať se snažíte sebevíce nastavit mantinely a pravidla pro chování agentů, relativně často se potkáte s tím, že některé z nich bude ignorovat. 

Frázi “Máte pravdu. Udělal jsem chybu. Vidím nyní jasně, že jsem měl dělat A a místo toho jsem provedl B”, jsem viděl častěji, než by se mi líbilo. 

Má tedy používání AI v automatizaci testů smysl? 

Určitě má. AI agenti sice zatím nejsou zázračný nástroj, který všechno udělá sám, ale může ulehčit a zrychlit řadu “nudných” a zdlouhavých činností. 

Příkladem může být:  

• Generování dokumentace kódu.  
• Průzkum aplikace a generování návrhu testovacích scénářů. Ovšem pozor na problémy, které jsem popsal výše.  
• Generování složitých datových typů. Toto je velmi užitečné, pokud v testech pracujete s API endpointy.  
• Samozřejmostí v dnešní době je pak dynamické našeptávání při manuálním psaní kódu. 

Pokud jde o problematické vlastnosti, tak z mé zkušenosti je třeba se zaměřit především na následující: 

1. Čtěte. Nepoužívejte slepě to, co AI agent vytvoří – vždy je třeba jejich výstupy číst a kontrolovat. Podle mého názoru se taky nevyhnete znalosti aplikace, pro kterou AI agent tvoří testy, protože pouze kontrola vytvořeného kódu bez znalosti funkčního kontextu aplikace nemusí být dostatečná. 
2. Mějte nastavené automatické validace generovaného kódu – minimem by mělo být lintování a formátování. V současné době jsou standardem ve světě JavaScriptu nástroje ESLint a Prettier. Případně je možné zvolit Biome.js, který provádí jak lintování, tak formátování a je výrazně rychlejší, což oceníte zejména u velkých projektů. 
3. Monitorujte stabilitu a kvalitu – sledování a vyhodnocování reportingu výsledků testů je základ. 
4. Iterativní přístup – postupujte malými kroky. Nesnažte se generovat celou testovací sadu najednou. 
5. Nastavujte agentům mantinely – je třeba agentům jasně stanovit co mají a co nemají dělat. Toto je nikdy nekončící proces. Počítejte s tím, že ať se snažíte sebevíc, agent si prostě občas bude dělat co chce. 
6. Nepodléhejte hypu – vývoj AI nástrojů je překotný. Co je „mainstream“ nyní, může být za půl roku zcela nahrazeno. Počítejte s tím, když se rozhodujete, zda a jakým způsobem používat AI agenty. 
7. Nenechte se oslepit “vytuněnými” demy AI nástrojů – ta zpravidla ukazují ideální stav a způsob užití. Praxe je mnohem komplikovanější a obtížná. 
8. Pozor na bezpečnostní rizika – dávejte si velký pozor na to, co LLM modelů poskytujete. Mějte vždy ošetřeno s poskytovatelem modelu, aby jej na vašich datech netrénoval. Pozor také na slepé přebírání promptů či skills souborů – infikování promptů je obrovský bezpečnostní problém. Vždy podrobně zkoumejte, co obsahují data, která nějakou formou agentům poskytujete.