Playwright MCP закрывает три вещи разом: агент открывает нужную страницу, читает её содержимое и кликает или заполняет форму — всё через MCP-сервер, который транслирует команды модели в действия настоящего браузера. Сценарий похож на автотест, только вместо фиксированного скрипта решения на каждом шаге принимает модель. Граница здесь простая: необратимые действия — оплату, отправку, удаление — подтверждает человек, а модель останавливается перед этим шагом и ждёт решения.
Сервер между агентом
Playwright MCP — сервер, который переводит команды модели в действия настоящего браузера: открыть страницу, прочитать текст, кликнуть элемент, заполнить поле, — а последовательность шагов и решение на каждом из них выбирает сама модель по ходу задачи.
Обычный автотест на Playwright идёт по фиксированному сценарию, который написал разработчик заранее, — шаг за шагом, без отклонений. Агент через MCP-сервер получает тот же набор действий с браузером, но выбирает следующий шаг сам, глядя на то, что показала страница после предыдущего клика.
Готовый MCP-сервер под собственные данные компании, с первыми инструментами по шагам, собран в статье свой MCP-сервер: как дать Claude доступ к вашим данным; тот же принцип узких инструментов и подтверждения опасных действий разобран подробнее в статье MCP tools: что такое инструменты MCP-сервера этой же серии.
Задачи компании
Задачи, которые агент через Playwright MCP закрывает в компании, построены на одном приёме — модель смотрит на страницу так же, как смотрел бы сотрудник, и действует по тому, что видит на экране прямо сейчас.
- Проверка сайта и форм — агент проходит по ключевым страницам, заполняет форму тестовыми данными и докладывает, где поведение страницы расходится с ожидаемым сценарием
- Сбор данных с личных кабинетов поставщиков — агент заходит в кабинет под своей учётной записью и переносит нужные значения в таблицу компании, как принцип, без готового списка конкретных полей
- Регрессионные проверки — агент повторяет один и тот же путь пользователя после каждого обновления сайта и сравнивает результат с прошлым прогоном
Три задачи объединяет общий принцип — агенту показывают страницу так, как её видит человек, а разбор кода страницы за ней остаётся в стороне, и решение о следующем клике модель принимает по смыслу увиденного.
Задача, которую агент решает через MCP-сервер, редко укладывается в один клик — обычно это цепочка из десятка мелких действий подряд: открыть страницу, найти поле, ввести значение, перейти дальше, и модель держит контекст всей цепочки между шагами.
Чем отличается от готового
Готовый браузер со встроенным агентом, вроде Comet от Perplexity, решает похожую задачу иначе — там агент и браузер идут одним продуктом от вендора, без отдельной сборки. Playwright MCP — обратный случай: компания собирает связку сама из сервера, модели и правил, и получает контроль над каждым узлом связки взамен готовой упаковки.
Разбор такого готового браузера-агента — в статье Comet Perplexity: браузер с ИИ-агентом для компании этой же серии. Для разовой рабочей задачи сотрудника обычно хватает готового продукта, а для регулярной проверки сайта или сбора данных под процесс компании собственная связка через MCP-сервер даёт контроль, которого в готовом продукте нет.
От обычной автоматизации тестов Playwright MCP отличается ровно тем же — фиксированный сценарий против решения модели по ходу задачи; для стабильной, редко меняющейся формы фиксированный сценарий обычно надёжнее и дешевле по вычислениям, а для страницы, которая меняется от прогона к прогону, агент подстраивается там, где скрипт ломается на первом же отличии.
Риски и подтверждение
Агент с доступом к авторизованной сессии браузера действует от имени сотрудника, чей логин там сохранён, — сайт видит обычного пользователя вместо отдельного робота, и это ровно та причина, по которой необратимые действия нуждаются в отдельном шаге подтверждения.
- Оплата и списание средств — подтверждает человек перед отправкой формы, агент готовит шаг и останавливается на кнопке
- Удаление записи или файла — необратимое действие проходит через отдельное согласие вместо автоматического клика модели
- Отдельный профиль браузера — рабочие сессии агента живут вне личного профиля сотрудника, как и в случае с готовым браузером-агентом
- Журнал действий — каждый клик и заполненное поле сохраняются, и по журналу разбирают, что сделал агент и почему
Журнал действий и отдельный профиль вместе закрывают большую часть риска — без них разбор спорного случая превращается в гадание, что именно нажал агент и на какой странице.
Список необратимых действий компания готовит заранее, до первого запуска агента на реальном сайте, — так правило «подтверждает человек» закрепляется в системе целиком, и агент проверяет его на каждом шаге, где оплата, отправка или удаление становятся частью сценария.
Какое необратимое действие в вашей системе сегодня разрешено без подтверждения человека?
Где ждать провалы
Динамические страницы — там, где содержимое подгружается кусками после клика или скролла, — чаще путают агента: модель видит пустой экран в момент, когда часть данных ещё грузится, и принимает решение по неполной картине.
Капча — отдельная стена, поставленная именно для того, чтобы отличить человека от программы, поэтому такие страницы агент оставляет человеку и продолжает работу дальше по сценарию.
| Ситуация | Что видит агент | Что делает команда |
|---|---|---|
| Страница грузится по частям | пустой или неполный экран в момент клика | добавляет паузу перед следующим шагом сценария |
| Капча на странице | элемент проверки, предназначенный только для человека | передаёт шаг человеку и продолжает после него |
| Изменилась вёрстка сайта | знакомые подписи на новых местах экрана | команда перепроверяет сценарий и обновляет инструкцию агенту |
Список ситуаций из таблицы выше стоит пополнять по мере того, как команда встречает новые отказы сценария на практике — у каждого сайта своя специфика вёрстки и загрузки, и универсальный перечень провалов тут работает лишь отправной точкой.
Возьмите одну страницу и один сценарий проверки с подтверждением перед необратимым шагом: на этом наборе разработчик убеждается, что агент останавливается там, где нужно, — и только тогда добавляет вторую страницу в контур.
Команда, которая впервые запускает агента через Playwright MCP, обычно недооценивает разброс поведения сайтов — одна и та же кнопка «отправить» находится на разных страницах в разных местах экрана, и сценарий, рабочий для одного сайта, требует правки для соседнего.
Встраивание такой связки в рабочий процесс компании — агент, MCP-сервер и правила подтверждения — часть работы на этапе автоматизации бизнес-процессов: там же прикидывают, какие проверки сайта и порталов поставщиков стоит забрать у сотрудника первыми.