Playwright CLI vs Agent Browser: какой стэк брать для E2E-тестов React через Claude Code
Сравнение Playwright CLI (Microsoft) и Agent Browser (Vercel) для E2E-тестирования React через Claude Code: бенчмарки токенов, фичи, рекомендация.
Playwright CLI vs Agent Browser: какой стэк брать для E2E-тестов React через Claude Code
Я на неделе выбирал инструмент для автоматических E2E-тестов фронта на React через Claude Code. Хотелось не «попробовать и забить», а закрыть вопрос: какой из двух свежих CLI-инструментов — agent-browser от Vercel Labs или @playwright/cli от Microsoft — дать своему агенту прогонять чекаут, логин, регрессию и всё остальное.
Выбор, мягко говоря, не очевидный. Оба инструмента появились в начале 2026 года. Оба решают одну и ту же проблему — «MCP жрёт слишком много токенов». Оба построены на одной и той же идее: snapshot страницы с короткими refs вместо полного DOM в контекст модели. Оба ставятся как скилл в Claude Code одной командой. И оба декларируют экономию токенов относительно Playwright MCP в диапазоне от 4× до 100× в зависимости от сценария.
Я полез копать бенчмарки, читать real-world кейсы, сравнивать фичи и ловить подводные камни. Итог — эта статья. Без маркетинга, с конкретными цифрами из независимых источников (TestCollab, SupaTest, Pulumi, сравнение 5 инструментов Bruce Heyuan) и с финальной рекомендацией, которую я сам для себя сделал.
Если у вас тот же вопрос — какой стэк зашить в своего кодящего агента для тестирования React-фронта — то дальше всё по делу.
Как мы вообще дошли до CLI-паттерна
Чтобы понять, зачем существуют эти два инструмента, нужно на 10 минут откатиться назад и вспомнить, что было до них.
Первой волной интеграции браузеров в кодящих агентов был Playwright MCP от Microsoft. MCP — это Model Context Protocol, протокол Anthropic, через который агент общается с внешним тулингом. Идея красивая: запустил MCP-сервер @playwright/mcp, и твой Claude Code / Cursor / Copilot получает 34 инструмента для работы с браузером — browser_navigate, browser_click, browser_snapshot и так далее. Вместо скриншотов и координат агент видит accessibility tree страницы и кликает по ARIA-ролям. Быстро, детерминированно, красиво в демках.
На практике всё быстро упёрлось в одну проблему: токены.
Вот как выглядит типичный ответ Playwright MCP после простого клика по кнопке на дашборде URL-шортенера, реальный пример из разбора Engin Diri на Pulumi:
- generic [ref=e2]:
- banner [ref=e3]:
- generic [ref=e4]:
- link "S Snip.ly" [ref=e5] [cursor=pointer]:
- /url: /
- generic [ref=e6]: S
- generic [ref=e7]: Snip.ly
- navigation [ref=e8]:
- link "Home" [ref=e9] [cursor=pointer]:
- /url: /
- text: Home
...
[12 891 символов продолжается]Это один ответ на одно действие. 12 891 символ — примерно 3 200 токенов. За 10 шагов простого сценария набегает ~114 000 токенов, по официальным бенчмаркам команды Playwright. Большая задача вроде «пройди полный чекаут с авторизацией» легко пробивает 200-300 тысяч. А у Claude Code контекст ограничен. Что это значит на практике — агент перестаёт помнить, с чего начал, начинает галлюцинировать селекторы, теряет нить, рестартует, жжёт деньги.
Gowtham Boyina описывает это в своём посте на Towards AI так: «Ваш агент буквально тонет в HTML до того, как успевает начать думать над задачей». И это не преувеличение — одно только определение 26 инструментов MCP загружается в контекст до любого действия.
Параллельно у Vercel было своё озарение. Они писали собственный text-to-SQL агент под кодовым именем D0 и описали эксперимент в исследовании «We Removed 80% of Our Agent’s Tools». Начали с 17 специализированных инструментов — отдельно для создания таблиц, отдельно для вставки строк, отдельно для запросов. Звучит логично. По факту: успех 80 % (4 запроса из 5), среднее время выполнения 274,8 секунды, ~102 000 токенов, worst case — 724 секунды и 145 463 токена, и всё равно провал.
Переделали под два инструмента: ExecuteCommand и ExecuteSQL. Успех вырос до 100 %. Среднее время — 77,4 секунды (3,5× быстрее). Токены — ~61 000 (на 37 % меньше). Worst case — 141 секунда и 67 483 токена, успешно.
Вывод простой: больше инструментов ≠ лучше. Иногда меньше тулов и компактнее ответы дают и скорость, и стабильность, и экономию.
К концу 2025 года оба лагеря — Microsoft и Vercel — независимо пришли к одному и тому же выводу: для кодящих агентов нужен не MCP с его protobuf-style обменом жирными payload-ами, а обычный CLI. Агент вызывает команду через Bash, получает в ответ короткое подтверждение и путь к файлу, и читает тяжёлые данные только когда реально надо.
В феврале 2026 Microsoft прямо написала в README Playwright MCP:
«Modern coding agents increasingly favor CLI-based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient.»
Это важный сигнал. Команда, которая сама делает MCP-сервер, публично рекомендует своим пользователям использовать альтернативу. В корпоративном мире такое бывает, когда внутренние бенчмарки слишком очевидны, чтобы их замалчивать.
А в январе 2026 Vercel Labs выкатила agent-browser — нативный Rust-инструмент с той же идеей, но со своим взглядом на реализацию. Гонка началась.
Agent Browser от Vercel: Rust-демон для ленивого агента
agent-browser — это browser automation CLI от Vercel Labs, написанный на Rust. На момент публикации статьи у него 29 300 звёзд на GitHub, что для инструмента возрастом меньше года — безумие. Последний релиз (v0.25.4) вышел буквально на днях, разработка идёт в темпе по релизу каждые 3-4 дня.
Устанавливается одной командой:
npm install -g agent-browser
agent-browser install # скачает Chrome for Testing один разИли через brew install agent-browser на macOS, или через cargo install для хардкорщиков. В Claude Code интегрируется как скилл:
npx skills add vercel-labs/agent-browserВсё. Никаких конфигов, серверов, MCP-настроек. Агент вызывает agent-browser через Bash как обычную команду, типа git или npm.
Как выглядит работа
Ключевая идея — snapshot + refs. Ты говоришь браузеру «открой страницу», потом «дай мне список интерактивных элементов», и получаешь компактный список с короткими идентификаторами:
- button "Sign In" [ref=e1]
- textbox "Email" [ref=e2]
- textbox "Password" [ref=e3]
- link "Forgot Password" [ref=e4]Дальше работаешь через refs: agent-browser click @e1, agent-browser fill @e2 "user@example.com". Никаких CSS-селекторов, никаких XPath. Элемент e1 — это элемент e1, пока страница не перезагрузится.
Вот как выглядит реальная сессия из кейса Engin Diri:
$ agent-browser open https://snip.ly
✓ Snip.ly - Modern URL Shortener
$ agent-browser snapshot -i
- link "S Snip.ly" [ref=e1]
- link "Home" [ref=e2]
- link "Dashboard" [ref=e3]
- link "Analytics" [ref=e4]
- button "Switch to dark mode" [ref=e6]
- textbox "Paste your long URL here..." [ref=e8]
- button "Shorten URL" [ref=e9]
$ agent-browser fill @e8 "https://example.com/test"
✓ Done
$ agent-browser click @e9
✓ DoneОтвет на каждое действие — шесть символов: ✓ Done. У Playwright MCP тот же клик возвращает 12 891 символ с полным обновлённым accessibility tree. Разница — 2 000×. Отсюда и растёт вся экономия токенов.
Архитектура
Изначально Agent Browser был гибридом: Rust CLI для парсинга команд + Node.js daemon для управления браузером через Playwright. В марте 2026 команда переписала demon целиком на Rust, и теперь это полностью нативный инструмент — потребление памяти упало в 18 раз, install size в 99 раз. Холодный старт — миллисекунды.
Дополнительные фишки
Помимо базового набора команд (click, fill, type, scroll, screenshot, PDF, network mocking, HAR recording), Agent Browser даёт пачку вещей, которых у Playwright CLI нет или они реализованы иначе:
AI Chat mode. Можно общаться с инструментом на естественном языке:
agent-browser chat "open google.com and search for cats"
agent-browser chat # интерактивный REPLРаботает через Vercel AI Gateway, по умолчанию использует Claude Sonnet 4.6, можно переключить на openai/gpt-4o флагом.
Sessions. Можно гонять несколько изолированных браузеров параллельно — каждый со своими куками, storage, историей:
agent-browser --session agent1 open site-a.com
agent-browser --session agent2 open site-b.comCloud-интеграции. Это серьёзно. Agent Browser из коробки поддерживает запуск браузера не локально, а в Vercel Sandbox (эфемерная microVM с полной изоляцией), Browserless (cloud-браузеры как сервис) и AgentCore. Для параллельного тестирования на CI/CD — must have:
import { Sandbox } from "@vercel/sandbox";
const sandbox = await Sandbox.create({ runtime: "node24" });
await sandbox.runCommand("agent-browser", ["open", "https://example.com"]);
const result = await sandbox.runCommand("agent-browser", ["screenshot", "--json"]);То есть ты можешь из Node.js-кода поднять 20 изолированных виртуалок, в каждой прогнать свой E2E-сценарий, получить результаты и потушить их. Без настройки инфраструктуры. Для того, кто строит agent-factory для автоматизированного QA — это реально сильный аргумент.
Playwright CLI от Microsoft: тот же паттерн, но от первоисточника
@playwright/cli — инструмент от самой команды Playwright. На GitHub он живёт в репозитории microsoft/playwright-cli, имеет 8 600 звёзд, и был запущен в феврале 2026 года как официальная рекомендация Microsoft для кодящих агентов.
Это важно: @playwright/cli — не обёртка над Playwright MCP и не форк. Это самостоятельный инструмент, построенный на том же базовом движке Playwright, который уже 5 лет крутит E2E-тесты в больших компаниях. Всё, что было наработано в оригинальной библиотеке — смарт-вейты, auto-healing селекторов, кросс-браузерность, видеозапись, трейсы — доступно и здесь.
Установка
npm install -g @playwright/cli@latest
playwright-cli --help
# Для Claude Code — установить skill
playwright-cli install --skillsВсё. В .claude/skills/playwright-cli/SKILL.md появляется описание интерфейса, которое агент читает и учится работать. Никакого claude mcp add, никакого JSON-конфига.
Как выглядит работа
Паттерн тот же: snapshot → refs → actions. Вот пример из документации Playwright — тест add todo на TodoMVC:
$ playwright-cli open https://demo.playwright.dev/todomvc/ --headed
$ playwright-cli type "Buy groceries"
$ playwright-cli press Enter
$ playwright-cli type "Water flowers"
$ playwright-cli press Enter
$ playwright-cli check e21
$ playwright-cli screenshotРазница с Agent Browser — в формате refs (e21 без собачки) и в том, что snapshot сохраняется на диск как YAML-файл, а не стримится в stdout:
.playwright-cli/page-2026-02-12T05-26-24-961Z.ymlАгент читает его только когда нужно разобраться, что на странице. Это тот же трюк, что у Agent Browser, но более явный — снапшот всегда файл, а не строка.
Что внутри
50+ команд. Это значительно больше, чем у Agent Browser. Из существенного:
- Tracing.
tracing-start/tracing-stopсоздают полный интерактивный трейс со всеми DOM-snapshot-ами, network-запросами, скриншотами до/после каждого действия. Потом открываешь в Trace Viewer — золото для отладки флейков. - Video recording.
video-start/video-chapter/video-stop— видео всей сессии с главами. Для ревью, для багрепортов, для демок. - Codegen. Можно запустить
--codegen typescript, и во время интерактивной сессии генерируется полноценный.spec.ts-файл с Playwright-тестом. То есть агент исследует флоу через CLI, а на выходе получаешь рабочий тест дляnpx playwright test. - Cross-browser.
--browser=chrome,--browser=firefox,--browser=webkit,--browser=msedge. Agent Browser умеет только в Chromium. - Route mocking через Playwright API. Не просто intercept/abort, а полноценный
page.route()с фильтрами по URL, методу, статусу. - Monitoring dashboard.
playwright-cli showоткрывает визуальный дашборд, где видно все активные сессии с превью, можно управлять вручную — отличный помощник, когда агент гонит тесты в фоне, и ты хочешь просто глянуть, что там.
Вся эта машинерия пришла из базового Playwright, её не надо было разрабатывать с нуля. Поэтому @playwright/cli — это не «CLI-клон Agent Browser», а «Playwright с CLI-интерфейсом под агентов».
Цитата из README — самый показательный момент
Я уже приводил её выше, но она настолько важная, что повторю целиком:
«Modern coding agents increasingly favor CLI-based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands.»
Команда, которая делает Playwright MCP, прямо в его же документации пишет: для кодящих агентов используйте CLI, не MCP. Рынок за полгода развернулся.
Под капотом оба делают одно и то же
Прежде чем лезть в бенчмарки, важно зафиксировать главное: архитектурно Agent Browser и Playwright CLI — это один и тот же подход. Оба:
- Получают команду от агента через Bash.
- Сохраняют snapshot страницы на диск как компактный текст с refs.
- Возвращают короткое подтверждение плюс путь к файлу.
- Не грузят полный DOM / скриншоты в контекст LLM — пока агент сам не решит их прочитать.
Это архитектурный консенсус, к которому и Microsoft, и Vercel пришли независимо. Разница — только в деталях реализации: Rust vs Node.js, Chromium vs кросс-браузер, формат refs, обвязка фич, интеграции.
С этого и начнём сравнение.
Бенчмарки: что на самом деле быстрее и дешевле
Короткий ответ: оба инструмента разгромно выигрывают у Playwright MCP. Между собой — сложнее, зависит от сценария.
Собрал цифры из четырёх независимых источников.
Сравнение 4 инструментов на 10-шаговом сценарии
Это самый частый бенчмарк в индустрии. Bruce Heyuan прогнал одну и ту же 10-шаговую автоматизацию на всех четырёх тулах через Claude Code:
| Инструмент | Токены на 10 шагов | Индекс |
|---|---|---|
| Playwright MCP | ~114 000 | 16,3× |
| DevTools MCP (Google) | ~50 000 | 7,1× |
| Playwright CLI | ~27 000 | 3,9× |
| Agent Browser | ~7 000 | 1× |
Agent Browser — лидер с разгромным преимуществом. В 4 раза эффективнее Playwright CLI и в 16 раз эффективнее Playwright MCP.
Официальные бенчмарки Microsoft: Playwright CLI vs MCP
Команда Playwright опубликовала бенчмарки своих двух продуктов на типовых задачах:
| Сценарий | Playwright MCP | Playwright CLI | Экономия |
|---|---|---|---|
| Single page snapshot | ~15 000 токенов | ~200 токенов (путь к файлу) | 98,7 % |
| 10-step automation | ~114 000 токенов | ~27 000 токенов | 76,3 % |
| Test flow со скриншотами | ~150 000 токенов | ~5 000 токенов | 96,7 % |
| Долгие сессии (50+ шагов) | риск context overflow | стабильно | качественный скачок |
Независимый обзор от SupaTest подтверждает порядок цифр и формулирует это так: «CLI reduces tokens often by 10–100× compared to MCP because the model does not need to load large tool schemas or rich browser state on every step.»
Официальные бенчмарки Vercel: Agent Browser vs Playwright MCP
Vercel с другой стороны даёт свои цифры:
| Операция | Traditional (MCP) | Agent Browser | Экономия |
|---|---|---|---|
| Открыть среднюю страницу | ~15 000 токенов | ~1 000 токенов | 93 % |
| Заполнить форму | ~8 000 токенов | ~500 токенов | 94 % |
| 10-шаговый workflow | ~100 000 токенов | ~7 000 токенов | 93 % |
Цифры стабильные — везде примерно 93 % экономии.
Real-world кейс от Engin Diri
Это мой любимый источник, потому что он не маркетинговый. Engin Diri из Pulumi прогнал одни и те же 6 тестов своего URL-шортенера и с Playwright MCP, и с Agent Browser, посчитал всё честно:
| Метрика | Playwright MCP | Agent Browser | Экономия |
|---|---|---|---|
| Всего символов ответов | 31 117 | 5 455 | 82,5 % |
| Самый большой ответ | 12 891 | 2 847 | 77,9 % |
| Средний размер ответа | 3 112 | 328 | 89,5 % |
| Homepage snapshot | 8 247 | 280 | 96,6 % |
Итог — агент способен прогнать в 5,7 раз больше тестов в рамках того же context budget. Это уже не «экономия копеечки», это принципиальная разница в том, что физически помещается в одной сессии.
Reddit-эксперимент: Browser DevTools MCP vs Playwright MCP
Ещё один независимый бенчмарк от Serkan Ozal — чтобы показать, что тренд «MCP тяжёлый» подтверждают и сторонние разработчики:
- 78 % меньше токенов: 330 K vs ~1,5 M per run
- 12 turns vs 48–52 у Playwright MCP
- ~57 % быстрее по wall-clock, с меньшей дисперсией результатов
Что с этого
Несколько выводов, которые можно обосновать цифрами:
- Оба CLI-инструмента разгромно лучше MCP на любом сценарии длиннее 3-5 шагов. Если у вас сейчас Playwright MCP — переход на любой из двух даёт минимум 4-кратную экономию токенов.
- Agent Browser в голом сравнении токенов — эффективнее Playwright CLI примерно в 4 раза. Это из-за того, что у него меньше фичей и ответы ещё компактнее.
- На уровне «просто кликнуть / заполнить / скриншот» разница большая. На уровне реальных тестовых сценариев — становится меньше, потому что оба читают снапшоты, анализируют DOM, делают ассёрты, и именно эти шаги оказываются основными пожирателями токенов.
Agent Browser выигрывает гонку токенов. Но выигрывает ли он E2E-тестирование React? Тут начинается самое интересное.
Feature matrix: где реально разница
Цифры по токенам — это только один измеритель. Для E2E-тестирования важнее, покрывает ли инструмент реальные потребности QA. Вот полная матрица по ключевым фичам:
| Критерий | Agent Browser (Vercel) | Playwright CLI (Microsoft) |
|---|---|---|
| Runtime | Rust (native) | Node.js |
| Install size | ~2 МБ после редизайна | ~80 МБ + Playwright-бинари |
| Cold start | ~миллисекунды | ~секунды |
| Поддерживаемые браузеры | Chromium | Chromium, Firefox, WebKit, MS Edge |
| Headed mode | Да | Да |
| Sessions (парал. браузеры) | Да, через --session | Да, через -s=name |
| Snapshot формат | stdout (короткий) | YAML-файл на диске |
| Network mocking | Базовый (route, --abort, --body) | Полный Playwright route API |
| HAR recording | Да (har start/stop) | Через tracing |
| Tracing Viewer | Нет | Да |
| Video recording | Нет (только стрим) | Да (с chapters) |
| PDF export | Да | Да |
Codegen (Playwright .spec.ts) | Нет | Да (--codegen typescript) |
| AI Chat REPL | Да (Vercel AI Gateway) | Нет |
| Cloud execution | Vercel Sandbox, Browserless, AgentCore | Local-first (через CDP можно подключить) |
| Visual monitoring dashboard | Streaming через WebSocket | Да (playwright-cli show) |
| Storage state persist | Да (через авторизацию сессий) | Да (state-save/load) |
| Auto-healing / smart waits | Ограниченно | Полный Playwright (auto-wait, auto-retry) |
| Role / test-id локаторы | Да (find role, find label) | Да (getByRole, getByTestId) |
| Экосистема документации | Новая, тонкая | Зрелая, 5 лет публичного Playwright |
| Версия / стабильность | v0.25.x (частые ломающие изменения) | v0.1.x, но под защитой @playwright/cli senioria |
| Лицензия | Apache-2.0 | Apache-2.0 |
Если читать эту таблицу прагматично, картина ясная: Agent Browser — это быстрая минималистичная тулза «сделать одну вещь хорошо». Playwright CLI — это профессиональный тестовый инструмент со всеми фичами оригинального Playwright, адаптированными под агентов.
Где каждый реально выигрывает
Матрица — это хорошо, но важнее сценарии. Разберу, где каждый инструмент ощутимо лучше.
Agent Browser выигрывает, когда
1. Задача короткая и понятная. Открыл страницу → снэпшот → клик → fill → скриншот. Всё. Agent Browser делает это быстрее всех за счёт нативного Rust-рантайма и минималистичного формата ответов. Для «просто посмотри, как выглядит моя лендинг на мобиле» или «проверь, что форма на /signup работает» — это оптимальный выбор.
2. Нужен минимум токенов. Если у вас долгая сессия с большим кодовой базой, а Claude Code уже грузит в контекст половину проекта — Agent Browser оставляет 93 % бюджета на ваш код. Playwright CLI тоже экономит, но меньше.
3. Вам нужно горизонтально масштабировать прогоны в cloud. Интеграция с Vercel Sandbox — убийца. Можно поднимать 20 изолированных браузеров параллельно, прогонять в каждом свой сценарий, собирать результаты — и всё это из TypeScript. Playwright CLI local-first, cloud-параллелизм придётся городить самому через CDP или Playwright Grid.
4. Хочется AI-первый опыт. Команда agent-browser chat "открой Google и найди котиков" — это буквально магия. Инструмент сам ходит в Claude Sonnet 4.6 через Vercel AI Gateway, сам составляет план, сам исполняет. Для быстрых exploratory-проверок — огонь.
5. Ценен нативный rust-перформанс. 18-кратное снижение потребления памяти — важно, если вы гоняете CI с лимитами по ресурсам. Холодный старт миллисекунды, не секунды.
Playwright CLI выигрывает, когда
1. Нужно профессиональное тестирование с регрессиями. Tracing Viewer, video recording, auto-wait logic, smart locators, codegen — это всё есть только у Playwright CLI. Флейки ловить без trace viewer — кошмар. Я в прошлом проекте убил неделю на флейки в Cypress, пока не переехал на Playwright и не начал просто открывать трейсы.
2. Нужен мульти-браузерный прогон. Тестируете только Chrome — живите счастливо с Agent Browser. Нужны прогоны Firefox / WebKit / Edge — только Playwright CLI.
3. Важно генерировать полноценные Playwright-тесты. --codegen — убийственная фича для команды, которая уже живёт в экосистеме npx playwright test. Агент исследует флоу через CLI, на выходе получается .spec.ts-файл, который потом можно руками дорабатывать, коммитить в репо и запускать в CI. Это hybrid workflow — агент для discovery, Playwright runner для повторяемости. Best of both worlds.
4. Работаешь со сложными ожиданиями. Engin Diri в своём разборе честно пишет о слабости Agent Browser:
«Modals that appear after API calls needed manual wait logic. Playwright’s waiting mechanisms are more mature. Hidden or dynamically loaded elements sometimes didn’t show up without explicit waits.»
Agent Browser умеет ждать networkidle, но не имеет auto-retry на ассёрты, не понимает, что элемент должен стать actionable, и регулярно спотыкается на SPA со Suspense-бургундами. У Playwright всё это вшито в библиотеку и наследуется CLI.
5. Нужна поддержка и документация. Agent Browser — ему год, документация тонкая, edge cases приходится ковырять в сорцах. Playwright — пять лет на продакшене в Microsoft, Airbnb, Bing, Adobe, VS Code — у него зрелая документация, огромное community, книги, курсы, известные паттерны.
6. Нужен monitoring dashboard. playwright-cli show открывает окно со всеми активными сессиями, превью, можно встревать вручную. Agent Browser умеет стримить viewport через WebSocket, но дашборд не даёт такой интерактивности.
Подводные камни
У обоих инструментов есть тёмные стороны.
Agent Browser
Молодость и thin docs. Engin Diri отдельно отмечает: «Agent-browser is early. Documentation is thin, and I read the source more than once to figure out edge cases.» Это реальная цена за «последняя версия v0.25.4 вышла вчера».
Ограниченный waiting logic. Я уже цитировал — модалки после API-запросов, hidden elements, Suspense-боундери. На простых страницах не проблема, на сложном SPA — будешь добавлять wait --load networkidle вручную.
Только Chromium. Для кросс-браузерного тестирования не годится.
Ломающие релизы. 79 релизов за неполный год, API местами меняется. Если вы прибьёте конкретную версию — OK, если пользуетесь @latest в CI — риск.
Playwright CLI
Node.js-зависимость. Если у вас нет Node 18+ в окружении — сначала ставь Node. На Rust-демона не заменишь.
Больший install size. Браузерные бинари Playwright занимают сотни мегабайт, плюс node_modules. Для CI — нормально, для лёгких контейнеров — тяжеловато.
Ранняя версия. @playwright/cli сейчас v0.1.0, хоть и поддерживается командой Playwright. Какие-то API могут двигаться. Пинить версии и следить за changelog — обязательно.
Меньше token-efficient, чем Agent Browser. 4-кратная разница в пользу Vercel — это не иллюзия. Если ваш бюджет токенов критичен (например, крутите всё на Haiku в целях экономии), это станет заметно.
Общие для обоих
Оба всё ещё сырые для unattended production. Флейки бывают у обоих. Для CI/CD-пайплайна я бы всё равно рядом держал традиционные Playwright-тесты как safety net.
Privacy. Всё, что агент видит через любой из CLI — уходит в Anthropic API. Тестировать на прод-данных — нельзя. Только staging с тестовыми аккаунтами.
Decision matrix: что брать для чего
Сводная таблица «задача → инструмент» для E2E-тестирования фронта:
| Задача | Рекомендация | Почему |
|---|---|---|
| Быстрые visual-проверки (как выглядит страница на мобиле, сверстался ли хедер) | Agent Browser | Быстрее, дешевле, проще |
| Self-QA во время разработки («проверь, что форма отправилась») | Agent Browser | Оптимально для «одного клика и скриншота» |
| Exploratory тестирование через чат | Agent Browser | chat REPL — киллер-фича |
| Полный чекаут / регистрация / checkout с мокингом API | Playwright CLI | Route mocking, smart waits, trace viewer |
| Регрессионный прогон 50+ сценариев | Playwright CLI | Auto-waits, codegen, tracing |
| Тестирование SPA со сложной реактивностью | Playwright CLI | Waiting logic зрелее |
| Cross-browser (Firefox / WebKit / Edge) | Playwright CLI | Agent Browser — только Chromium |
| Visual regression с pixel-diff | Playwright CLI | Playwright-экосистема (pixelmatch, playwright-visual-comparison) |
Генерация .spec.ts для CI | Playwright CLI | --codegen typescript |
| Параллельный прогон в cloud (20+ браузеров) | Agent Browser | Нативная интеграция с Vercel Sandbox |
| Хочется сверхэффективно по токенам | Agent Browser | В 4× эффективнее CLI |
| Есть существующий Playwright test suite | Playwright CLI | Прямое продолжение экосистемы |
| Agent-factory с хостингом на Vercel | Agent Browser | Один vendor, один сюр |
| Long-running автономные сценарии (час+ работы) | Playwright CLI | Waiting зрелее, стабильность выше |
Что выбираю я — и почему
Для автоматизированного E2E-тестирования фронта на React через Claude Code, где важно много кейсов, стабильность, повторяемость, скорость на длинных сессиях, и возможность получать готовые .spec.ts на выходе — я выбираю Playwright CLI как основной инструмент.
Причин несколько.
Первое — зрелость waiting-логики. React с Suspense, use хуками, loading-стейтами, модалками на API-ответах — это именно тот класс фронта, где Agent Browser, по честному отзыву Engin Diri, спотыкается, а Playwright разбирает на автомате. Мои флоу включают авторизацию с 2FA-задержками, динамические модалки, lazy-loaded компоненты, infinite scroll. Каждый такой случай у Agent Browser превратится в ручной wait --load networkidle с подбором таймаутов. У Playwright CLI — expect(page.getByRole('button')).toBeVisible() и auto-retry на 5 секунд из коробки.
Второе — codegen. Это для меня прорывная фича. Я запускаю сессию с агентом, он исследует флоу через playwright-cli --codegen typescript, на выходе у меня готовый Playwright-тест, который я коммичу в репо. Дальше он гоняется в CI на каждый PR без агента, быстро, бесплатно, стабильно. Agent Browser такого не умеет. А для меня важнее иметь регрессионный pack, чем каждый раз просить агента «прогони чекаут» — это и дешевле в долгую, и надёжнее.
Третье — кросс-браузерность. У меня в проекте есть Safari-юзеры (я сам на Mac). WebKit-прогон — необходимость. Agent Browser — только Chromium.
Четвёртое — trace viewer. Каждый раз, когда у меня упадёт тест в CI, мне нужно разобрать причину за 3 минуты. Открыть трейс, посмотреть на DOM в момент падения, увидеть network-запросы — бесценно. Без трейсов дебаг флейков превращается в рулетку.
Пятое — я всё равно живу в экосистеме Playwright. Локально у меня npx playwright test, в CI — Playwright runner, в команде все знают getByRole и getByTestId. Переход на @playwright/cli — это продолжение того же, что уже знакомо, только с агентом. Agent Browser — это отдельная планета со своим форматом refs (@e1 vs e1), своими командами, своей документацией.
Когда буду брать Agent Browser
Не «никогда». У него тоже есть ниша.
- Быстрые проверки внутри dev-цикла. Клод закончил фичу, я прошу: «открой localhost:3000, проверь, что новая кнопка работает». Тут Agent Browser отработает за секунды с минимумом токенов — идеально.
- AI Chat REPL для exploratory. Когда я хочу без напряга пробежаться по продакшен-сайту конкурента и сделать ресёрч —
agent-browser chatбыстрее и приятнее. - Параллельный прогон в Vercel Sandbox. Когда я буду строить свою CI-систему с масштабируемыми параллельными прогонами, Sandbox-интеграция — сильный аргумент. Но это уже следующий этап.
Итог: я ставлю оба
В .claude/skills/ у меня прописаны оба скилла. Claude Code сам выбирает инструмент под задачу — для «проверь форму, глянь скриншот» он берёт Agent Browser, для «прогони полный чекаут с регрессионными ассёртами» — Playwright CLI. Оба живут рядом, не конфликтуют, не мешают друг другу.
Это не трусливый компромисс «возьму оба». Это honest acknowledgement того, что у инструментов разные оптимумы. Попытка заставить один инструмент делать всё — это попытка заставить кувалду забивать гвозди. Работает, но медленно и часто не туда.
Как запустить это у себя — пошагово
Если вы решили попробовать — вот минимальный план на 15 минут.
Шаг 1. Установить оба
# Agent Browser (Rust CLI, быстрый)
npm install -g agent-browser
agent-browser install
# Playwright CLI (Node.js, полный)
npm install -g @playwright/cli@latest
playwright-cli installШаг 2. Поставить скиллы в Claude Code
# Agent Browser skill
npx skills add vercel-labs/agent-browser
# Playwright CLI skill
playwright-cli install --skillsШаг 3. Положить в CLAUDE.md проекта короткую инструкцию
## Browser automation
Для быстрых visual-проверок, exploratory QA и простых форм используй
`agent-browser`. Для полноценного E2E-тестирования с регрессиями,
cross-browser, tracing и генерации Playwright-тестов — используй
`playwright-cli`. Для генерации финального `.spec.ts` файла запускай
`playwright-cli --codegen typescript`.Шаг 4. Прогнать первый тест
# Запускаешь Claude Code
claude .
# И просишь:
# «Test the signup flow on http://localhost:3000. Use playwright-cli.
# After testing, generate a Playwright test file signup.spec.ts.»Через минуту у вас есть прогнанный флоу, скриншоты в .playwright-cli/, и готовый тест-файл в корне проекта. Дальше npx playwright test signup.spec.ts для CI.
Шаг 5. Замерить
Прогоните один и тот же флоу в Claude Code два раза — раз через Agent Browser, раз через Playwright CLI. Посчитайте, сколько ушло токенов по каждому (в Claude Code это видно в нижней строке). И честно решите для вашего конкретного контекста, что подходит.
Цифры из статьи — общий ориентир. У каждого проекта свои числа. У меня, например, разница между Playwright CLI и Agent Browser в абсолюте оказалась меньше, чем в публичных бенчмарках, потому что тесты короткие. У кого-то с 500-шаговыми регрессионными прогонами разница будет драматичной.
Что с этим делать
Короткий practical checklist, если у вас прямо сейчас Claude Code и React-фронт:
- Если у вас Playwright MCP — переходите на CLI сегодня. Экономия токенов 4-100×, стабильность выше, флейков меньше. Это buy-now-buy-cheap-twice-later.
- Если у вас ничего нет — ставьте Playwright CLI как основной, Agent Browser рядом для быстрых проверок.
@playwright/cli install --skillsиnpx skills add vercel-labs/agent-browser— обе команды, 3 минуты работы. - Если вы в экосистеме Vercel (хостите фронт на Vercel, у вас Vercel AI Gateway, планируете cloud-параллелизм через Sandbox) — серьёзно рассмотрите Agent Browser как основной. Интеграция с их же Sandbox даёт возможности, которых у Playwright CLI пока нет.
- Если вы автоматизируете только browsing / scraping / visual QA без сложных регрессий — Agent Browser. Дешевле, быстрее, и вы не платите за фичи, которые не используете.
- В любом случае — не тяните с переходом. Рынок за полгода полностью развернулся в сторону CLI. MCP для кодящих агентов — это уже legacy.
Ну и общее: мы на пороге нового поколения QA-инструментов. Agent-factory с параллельным тестированием в облаке, self-verifying agents типа Ralph Wiggum-луп, hybrid workflow «агент для discovery, runner для CI». Всё это становится боевой частью стека прямо сейчас. Кто успеет адаптироваться до конца 2026 — получит огромное преимущество в скорости разработки. Кто не успеет — будет потом 3 месяца догонять. Это не паника, это просто как было с React Hooks в 2019 или с TypeScript в 2017.
Выбирайте осознанно, тестируйте на своих флоу, не ведитесь на чистый маркетинг. Цифры в этой статье — реальные, из трёх независимых источников. Выводы — мои, основанные на своём проекте. Ваш контекст может требовать других решений.
Главное — не оставайтесь на Playwright MCP, если у вас Claude Code. Сам Microsoft пишет в своём же README — не надо. Значит, не надо.
Источники (все inline в тексте):
- microsoft/playwright-cli — официальный репозиторий
- vercel-labs/agent-browser — официальный репозиторий
- Browser Automation in Claude Code: 5 Tools Compared (2026) — сравнение 5 инструментов с бенчмарками
- Playwright CLI: The Token-Efficient Alternative to Playwright MCP — независимый разбор TestCollab
- Playwright MCP vs Playwright CLI — разбор SupaTest
- Self-Verifying AI Agents: Vercel’s Agent-Browser in the Ralph Wiggum Loop — real-world кейс от Pulumi (Engin Diri)
- Browser DevTools MCP vs Playwright MCP: 78% fewer tokens — независимый бенчмарк Serkan Ozal
- We Removed 80% of Our Agent’s Tools — исследование Vercel про D0
- Coding agents — official Playwright docs — официальная документация
- How to Use Playwright MCP Server with Claude Code — Builder.io — детальный разбор Playwright MCP vs CLI
- Vercel Just Solved Browser Automation for AI Agents — разбор Gowtham Boyina про Agent Browser