Выполнение в браузере для ИИ-агентов: Playwright, MCP и безопасный исполнитель.
Выполнение в браузере для ИИ-агентов: браузер в качестве среды выполнения наряду с MCP и режимом кода, в основе — Playwright, защита с помощью профилей, ограничений по доменам и политик.
Источники: Why Browser Execution Is Becoming the Missing Capability in Agent Architecture?
Агенты для автоматизации уже в совершенстве владеют работой с машинами. Они обращаются к API, подключаются к серверам MCP, запускают код, выполняют запросы в Интернете, открывают файлы и отправляют команды в оболочку. Однако удивительно большое количество реальных программных продуктов позволяет выполнять некоторые из своих ключевых операций только через интерфейс браузера, и именно этот пробел и предназначено заполнить выполнение в браузере.
Самые новые продукты таких агентов предоставляют агенту доступ к браузеру или облачному компьютеру. Легко списать это на ещё одну демонстрацию ИИ, нажимающего кнопки. Однако более полезный взгляд — архитектурный: браузер не является новым типом агента, а представляет собой новую среду выполнения.
Разница имеет значение. Если система уже предоставляет серверы MCP, инструменты для работы с навыками, выполнение кода, возможности программного взаимодействия с инструментами, среды тестирования, функции поиска и прямое подключение к бэкенду, браузер не должен заменять ничего из этого. Он расширяет функционал системы в области, которые она не может надежно обслуживать: приложения с состоянием, тяжело зависящие от JavaScript, аутентифицированные приложения, созданные для людей.
Поисковая функция находит нужную информацию. API и MCP взаимодействуют с системами. Код преобразует данные и координирует действия. Браузер использует интерфейс, созданный для людей.
Интерфейс, который забывают
Архитектуры агентов обычно начинаются с структурированных возможностей. Когда сервис предоставляет четкий REST API, SDK или сервер MCP, это почти всегда лучший интерфейс для агента: явный контракт, типизированные входные и выходные данные, более понятные ситуации с ошибками и более четкие границы безопасности.
Далее идет выполнение кода. Вместо того чтобы заставлять модель вызывать двадцать инструментов по одному, пусть она напишет небольшую программу, которая будет вызывать их, собирать результаты локально, фильтровать данные и возвращать один компактный ответ. Это подходит для больших каталогов инструментов, повторных вызовов и рабочих процессов с большим объемом данных. Песочница предоставляет дополнительную среду с Python, оболочкой, файлами, а также, возможно, инструментами Kubernetes или GitHub в контролируемой среде. К этому моменту агент может выполнять множество задач, но он по-прежнему предполагает, что все полезные функции доступны через интерфейсы, читаемые машиной.
Не совсем так. Множество инструментов существуют исключительно за экранами: внутренние панели администрирования, старые порталы поставщиков, панели отчетности, системы партнеров, биржи вакансий, инструменты аналитики, страницы настроек SaaS или приложения, которые загружают реальные данные только после настройки нескольких фильтров. Данные могут быть общедоступными, в то время как полезная информация генерируется с помощью JavaScript. Человек считает эту задачу простой, однако API не документировано. Иногда существует внутреннее API, но оно закрытое, нестабильное или намеренно не поддерживаемое.
Вот что представляет собой реальный сценарий использования: не позволять ИИ свободно исследовать Интернет, а использовать браузер в качестве запасного интерфейса, когда само приложение является частью выполняемой задачи.
Почему MCP пока не покрывает это
Каждый раз, когда речь заходит об выполнении в браузере, возникает и этот вопрос, на который следует дать прямой ответ. MCP никогда не требует наличия API у целевой системы; он лишь определяет, как агент взаимодействует с тем или иным функционалом. Предположим, что целевое приложение предоставляет лишь интерфейс для пользователей. В таком случае код инструмента на основе MCP может сам управлять браузером. Ограничением здесь является не MCP, а отсутствие стабильного, структурированного интерфейса у целевой системы.
Цель может не предоставлять ничего структурированного. То, что находится за MCP, может быть браузером, сандбоксом, движком рабочих процессов или чем-то совершенно другим. Проблемы возникают, когда у приложения нет публичного API, SDK, интеграции с базой данных или поддерживаемого программного способа выполнения необходимой операции. MCP всё равно может публиковать инструмент с именем browser_execute, но что-то за ним должно управлять системой, и это и есть выполнение в браузере. Они не являются конкурентами: MCP может быть протоколом, обеспечивающим возможности браузера, а браузер — средством взаимодействия с приложением для пользователя, когда нет чего-то лучшего.
Аутентификация может быть привязана к браузеру. У MCP есть собственная модель авторизации, включающая механизмы OAuth, но она охватывает только взаимодействие между клиентом MCP и сервером MCP. Она не вмешивается в правила входа в систему, в которой в конечном итоге должен работать инструмент. Многие внутренние порталы, приложения поставщиков и более старые продукты SaaS разрешают доступ только через интерактивный браузерный процесс с использованием SSO, MFA, куки сессии или других данных, создаваемых во время входа человека, при этом отсутствуют учетные данные сервиса или делегированные токены. Инструмент MCP всё равно может предоставлять соответствующие возможности, используя аутентифицированный профиль браузера. Пользователь входит в систему через браузер, состояние сессии находится под контролируемым доступом, и позже выполняет действия от имени этой учетной записи. Ограничением является модель аутентификации целевого приложения, а не модель MCP.
Некоторые задачи представляют собой рабочие процессы интерфейса, а не отдельные запросы. Возьмём, к примеру, задачу «выбрать регион «Розничная торговля, Европа» и период последних 90 дней, затем рассчитать средний показатель конверсии по странам». Для её выполнения может потребоваться серия фильтров, шаг отрисовки и извлечение полученных данных; при этом никакой конечный пункт не возвращает ответ напрямую. Браузер может управлять интерфейсом и считывать результаты, генерируемые приложением.
Структурированные API, вызываемые напрямую или через MCP, остаются первым выбором, когда они доступны. Они дешевле, более предсказуемы и проще в защите. Браузер обрабатывает ту часть, которая находится только за интерфейсом, видимым для пользователя.
Поиск — это не просмотр
Во многих архитектурах агентов поиск в Интернете, получение данных по HTTP, автоматизация браузера и использование компьютера объединяются в один нечёткий набор навыков «веб», хотя это разные инструменты.
Чтобы узнать, что изменилось в последней спецификации MCP, вероятно, достаточно веб-поиска. Имея URL обычной публичной статьи, можно просто получить её содержимое напрямую. Если требуется работать с Salesforce, следует использовать его API или MCP. Для вычисления статистики из JSON необходимо использовать код.
Теперь представьте другой запрос: открыть публичную панель управления, выбрать Украину, установить год на 2026, выбрать вариант Enterprise, просмотреть каждую категорию и вычислить среднее значение для каждого показателя. Поисковик не может выполнять такие действия, а обычный HTTP-запрос может вернуть лишь пустую структуру страницы. Полезные данные появляются после того, как браузер запускает JavaScript, отправляет запросы с клиента, обновляет состояние приложения и отображает результат.
Или портал вакансий: выберите категории «Инженерия ИИ», «Работа на расстоянии» и «Германия», затем подсчитайте, сколько вакансий упоминают RAG в описании. Это на самом деле не запрос к поиску — это рабочий процесс интерфейса, за которым следуют операции извлечения данных и их обработка. Именно здесь настоящий браузер предоставляет агенту что-то новое — рабочую среду для выполнения задач в вебе с сохранением состояния.
Браузер — это среда выполнения
Управляемый браузер, такой как Amazon Bedrock AgentCore Browser, представляет собой инфраструктуру: изолированную удаленную сессию браузера, которую можно программно управлять. Язык больших моделей не взаимодействует с ним магически — вы сами определяете контракт взаимодействия между агентом и средой.
AgentCore Browser обеспечивает доступ к сессиям через точку входа автоматизации WebSocket, а библиотеки вроде Playwright могут подключаться к удаленному Chromium по протоколу Chrome DevTools Protocol. AWS предоставляет отдельные действия браузера на уровне операционной системы для операций, которые CDP не может обработать корректно. Браузер представляет собой удаленную среду выполнения, а не слой интеллектуальной обработки. С такой точки зрения интеграция становится проще: агенту требуется программируемая функциональность, и именно в среде выполнения браузера она реализуется.
Пусть агент пишет код браузера
Браузер может взаимодействовать с агентом несколькими способами. Один из вариантов — использование высокоуровневого инструмента вроде browser_task(task="найти самый свежий счет-фактура"), в котором находится агент, адаптированный под конкретный браузер; он читает задание, исследует сайт, определяет, что нужно нажать, и сообщает об результатах. Это может помочь при работе с незнакомыми сайтами, где необходимо выяснить порядок действий, но это плохая отправная точка.
Если основная модель — способный программист, более чистым первоначальным решением будет заставить её сгенерировать программу браузера и передать её исполнителю браузера. Достаточно подобной простой функции вида browser_execute(code, profile_id, allowed_domains):
browser_execute(
code=generated_playwright_code,
profile_id="vendor-portal-user-42",
allowed_domains=["portal.example.com"]
)
При получении вызова исполнитель проверяет запрос, затем создаёт (или повторно использует) изолированную сессию и подключает Playwright к удалённому браузеру. Он запускает программу и возвращает структурированные данные. Основной агент выполняет свои действия лишь один раз. Второй ЯЗЫК больших моделей, интерпретирующий ту же цель, имеет смысл только тогда, когда задача действительно требует исследования. Для предсказуемого панели управления, каталога или портала это превосходит вложенный браузерный агент как по цене, так и по простоте наблюдения.
Почему подходит режим кода
Это особенно важно там, где уже используется программное вызов инструментов. Неэффективный подход легко распознать: модель вызывает click, получает результат, вызывает screenshot, снова анализирует ситуацию, вызывает type, получает ещё один результат. Работа, которую обычный скрипт мог бы выполнить за несколько миллисекунд, превращается в десятки вызовов модели.
Лучшим подходом является агрегация инструментов для поиска шаблонов: пусть модель напишет одну программу, которая будет выполнять множество операций браузера внутри среды выполнения и возвращать единый компактный результат.
page = await browser.page()
await page.goto("https://jobs.example.com")
await page.get_by_label("Category").select_option("AI Engineering")
await page.get_by_label("Location").select_option("Germany")
await page.get_by_label("Remote").check()
await page.get_by_role("button", name="Apply").click()
jobs = await page.locator(".job-card").all_inner_texts()
rag_jobs = [job for job in jobs if "RAG" in job.upper()]
return {
"total_jobs": len(jobs),
"jobs_mentioning_rag": len(rag_jobs)
}
Модель пишет одну программу, исполнитель выполняет десятки или сотни детерминированных операций с DOM, а агент получает небольшой JSON-объект вместо длинной последовательности кликов и скриншотов.
Это можно усилить. Среда выполнения кода, учитывающая возможности, может предоставить сгенерированной программе несколько контролируемых интерфейсов: клиенты MCP, обычный HTTP, файлы, управление браузером и локальные вычисления. Одна программа может получить данные о счетах из Salesforce через MCP, открыть устаревший портал, прочитать показатели для каждого счета, обработать их и вернуть один ответ.
customers = await mcp.salesforce.search_accounts(segment="enterprise")
results = []
for customer in customers:
await browser.goto(f"https://legacy.example.com/customer/{customer.id}")
metric = await browser.locator("#health-score").inner_text()
results.append({
"customer": customer.name,
"health_score": metric,
})
return summarize(results)
Это не искусственный интеллект, который случайно нажимает на элементы. Это программная координация действий через машинные и человеческие интерфейсы одновременно.
Функциональный процесс
Возьмём простой на первый взгляд запрос: зайти на публичную панель аналитики, выбрать категорию «Ритейл», континент «Европа», ограничиться данными за последние 90 дней и сравнить показатели конверсии и удержания клиентов в разных странах.
Агент не должен сразу открывать браузер. Маршрутизатор функций сначала проверяет, подойдёт ли более дешёвый и структурированный способ получения данных. Если поиск может дать ответ — используем поиск. Если страница предоставляет стабильный API — обращаемся к нему. Если данные доступны через прямой HTTP-запрос — не запускаем Chromium.
Если значения появляются только после взаимодействия с клиентской стороной, маршрутизатор выбирает выполнение в браузере. Основной агент генерирует программу Playwright, исполнитель запускает её в управляемой сессии, ждёт, пока страница перестанет меняться, считывает отрендеренные числа и возвращает их в виде структурированных данных. Затем режим кода выполняет сравнение, и агент записывает результат. Пользователю не нужно знать, что был открыт браузер. Во многих продуктах это должно быть невидимым функционалом серверной части, подобным запросу к базе данных или кодовой песочнице.
Сначала автоматизация, затем использование компьютера
Автоматизация браузера и использование компьютера иногда считаются одним и тем же, но на самом деле они относятся к разным уровням архитектуры. Playwright и CDP работают с структурой браузера: страницами, селекторами, элементами DOM, формами, сетевыми запросами, загрузками данных и состоянием. Благодаря этому они работают быстрее и потребляют меньше ресурсов, к тому же их проще тестировать и изолировать.
Использование компьютера основано на визуальном взаимодействии. Модель наблюдает за экраном и выполняет действия мыши или клавиатуры. Она становится необходимой тогда, когда DOM не может надежно обрабатывать интерфейс: приложения типа canvas, встроенные диалоговые окна, контекстные меню, нестандартные сценарии перетаскивания элементов. AWS применяет аналогичный подход в AgentCore Browser, где автоматизация через WebSocket основана на CDP, а API InvokeBrowser обеспечивает управление на уровне операционной системы для тех задач, которые невозможно выполнить с помощью CDP. Поэтому сначала следует использовать структурированную автоматизацию, а к визуальному управлению обращаться только при необходимости. Чем ниже находится агент в иерархии, тем больше его гибкость, но тем дороже, более зависимым от состояния и рискованным становится каждое его действие.
После перехода на использование компьютера исполнитель должен запустить замкнутый цикл проверки, а не цепочку слепых действий. Клик, прошедший без ошибок, ничего не доказывает относительно выполнения операции: страница всё ещё может загружаться, модальное окно может перехватить действие или другой элемент может принять клик. После любого следующего шага система должна оценить новое состояние и подтвердить наступление ожидаемого изменения перед тем, как переходить дальше. Она также должна выявлять повторяющиеся действия, которые ничего не приносят. Если тот же шаг повторяется без изменений, повторная попытка является ошибкой; решением является перепланирование или возврат к более структурированной стратегии.
Этот цикл опирается на три механизма контроля: ограничение количества сохраняемых скриншотов, выявление повторяющихся действий, не приносящих изменений, и поэтапное применение уровней разрешений.
Аутентификация делает работу реальной
Публичные панели управления подходят для демонстрации концепции, но истинная ценность проявляется в авторизованных приложениях. Playwright уже обеспечивает надежную поддержку контекстов браузера и повторно используемого состояния авторизации, а AgentCore Browser добавляет управляемые профили, которые сохраняют куки и локальное хранилище между сессиями. Пользователь входит один раз, профиль сохраняется, и в последующих сессиях это состояние восстанавливается. Это полезно для внутренних порталов, систем клиентов, устаревших SaaS-решений и приложений поставщиков, где интеграция с API иначе потребовала бы кастомной обратной разработки или была бы невозможна.
Это также влияет на способ моделирования идентичности. Профиль браузера по сути представляет собой идентичность для выполнения с учетными данными, а не простой удобный объект. Профиль, имеющий доступ к финансовому порталу, не должен автоматически быть доступен каждому агенту или рабочему процессу. В производственной среде необходимо связывать профили с арендатором, пользователем, целью использования и диапазоном политик, предоставляя агенту права на конкретный профиль, а не общий доступ ко всем сессиям, принадлежащим пользователю.
Безопасность важнее демонстрации
Выполнение в браузере мощно, поскольку оно осуществляется через тот же интерфейс, что и у человека, что также означает возможность совершения ошибок с использованием привилегий человека.
Первым ограничением является исполнитель. Генерируемый код браузера должен работать изолированно с четкими ограничениями по доменам, таймаутами, лимитами ресурсов и контролируемым доступом к профилям. Модель не должна получать переменные окружения хоста, произвольные учетные данные или общие сетевые пути лишь потому, что она способна запускать Playwright.
Вторым ограничением является политика действий. Извлечение метрик с страницы — это отдельная операция от отправки сообщений, изменения прав доступа к учетной записи, удаления данных или одобрения платежа. Такие побочные эффекты следует отнести к категории действий, не связанных с работой модели, и контролировать их на уровне исполнения.
Третьей проблемой является внедрение команд. Как только агент читает произвольные страницы, весь отображаемый контент становится ненадежным входными данными. Текст в панели управления, электронном письме, баннере или документе может выглядеть как команда для агента. Выполняющий модуль никогда не должен считать контент на экране подтверждением действий пользователя. Руководство OpenAI по использованию компьютера гласит то же самое: рассматривайте контент сторонних источников как ненадежный и запрашивайте подтверждение перед выполнением рискованных действий, таких как публикация, отправка, удаление, изменение прав доступа или перевод средств. Это вопрос политики выполнения, а не только инженерии команд. Браузер может осуществлять общий мониторинг, но должен изменять ситуацию только в соответствии с явно заданной политикой.
Затем следует возможность наблюдения. Инструмент для работы в производственной среде должен фиксировать запрашиваемую задачу, используемый профиль, доступные домены, выполняемую программу, загружаемые файлы, попытки выполнения внешних действий, а также случаи, когда требовалась утверждение человека. AgentCore Browser можно отслеживать в реальном времени, а пользовательские браузеры позволяют записывать и воспроизводить сессию, что обеспечивает прочную основу для аудита.
Как это связано с MCP, навыками и песочницами
Ничто здесь не может заменить что-либо ещё. MCP и API по-прежнему остаются предпочтительными для структурированных бизнес-операций. Набор навыков включает в себя повторяемые процедуры, контекст и операционные знания. Режим кода остаётся эффективным инструментом для повторных вызовов, агрегации и преобразования данных. Сандбоксы служат контролируемой средой для работы с файлами, шеллом, Python, тестированием и высоконагруженными вычислениями. Выполнение в браузере покрывает отдельную нишу: работу с интерфейсом для людей, когда аналог для машин недостаточно надёжен.
Следуйте консервативному подходу к маршрутизации. Может ли API выполнить задачу? Используйте его. Может ли прямой поиск решить проблему? Не открывайте браузер. Необходимо ли управлять самим сайтом для получения результата? Тогда подходит выполнение в браузере. Не может ли структурированная автоматизация завершить взаимодействие? Использование компьютера — последний вариант.
MCP как контракт
На практике ветки редко остаются разделенными. Выполнение кода, работа браузера и даже поиск инструментов обычно происходят через сервер MCP. MCP — это не просто ветка API; это контракт, через который агент получает любые возможности, будь то вызов REST, скрипт в изолированной среде или удаленный Chromium в качестве основы.
Хорошим решением является использование одного специализированного сервера MCP, предоставляющего несколько инструментов, таких как execute_code, browser_execute и find_tool, вместо одного инструмента на каждую операцию. Количество инструментов остается на уровне трех-четырех, а не тридцати. У модели нет необходимости в отдельных инструментах для кликов, снимков экрана и выбора опций, так же как у нее нет потребности в отдельных инструментах для перезапуска, масштабирования и отката, когда достаточно одной операции с планом действий.
Ещё одной причиной является портативность. Один сервер может работать через специальный агент или подключаться к Claude, ChatGPT или любому клиенту, совместимому с MCP, так что те же возможности можно протестировать через знакомый интерфейс без дополнительной интеграции.
Держите исполнитель отдельно
С точки зрения агента, браузер может выглядеть как часть режима кода, поскольку один из генерируемых скриптов может использовать browser.goto() и browser.locator() наряду с клиентами MCP, файлами и API для вычислений в рамках одной логической среды выполнения. При развертывании более предпочтительным остается использование отдельного компонента — исполнителя браузера. Браузеры имеют собственный цикл жизни и связанные с ним риски: сессии, куки, локальное хранилище, загруженные файлы, правила сети, авторизованные профили, состояние страниц, записи и побочные эффекты, возникающие вне вашей системы. В среде кодового песочницы речь идет о процессоре, памяти, файлах, пакетах и процессах. Разделение этих компонентов позволяет каждой среде выполнения применять собственную модель безопасности. Режим кода может обеспечивать ограниченный клиент браузера, в то время как исполнитель контролирует удаленную сессию, тем самым сохраняя единость модели программирования при разделении инфраструктуры.
Начинается скука
Избегайте использования универсального автономного агента браузера в начале. Первая полезная версия преднамеренно проста: одна изолированная удаленная сессия Chromium, небольшой контракт browser_execute, Playwright для автоматизации, строгий список разрешенных доменов и структурированные результаты. Протестируйте ее на публичном панели управления, ориентированной на JavaScript, или на примере приложения, где можно показать, что браузер превосходит по эффективности поисковые системы и методы получения данных через HTTP.
После того как это заработает, подключите его к уже используемой для режима кода программной схеме, чтобы основной агент генерировал браузерную программу и не вызывал инструменты низкого уровня для кликов снова и снова. Затем добавьте аутентифицированные профили для контролируемых внутренних приложений, а также политики действий и механизмы одобрения, прежде чем любой рабочий процесс сможет вызвать внешние эффекты. Используйте визуальное управление компьютером только для интерфейсов, с которыми Playwright не может работать надежно, и рассмотрите возможность специализированного цикла браузер-агент, который будет наблюдать, анализировать, перепробовать и исследовать ситуацию только тогда, когда задача слишком неоднозначна для того, чтобы основной агент смог создать стабильную программу. Такой порядок делает архитектуру понятной и откладывает самое дорогостоящее и наименее детерминированное поведение на периферию, вместо того чтобы сделать его стандартным.
Более кардинальные изменения
Интересно не то, что большая языковая модель может нажимать кнопки — автоматизация браузера существует уже много лет. Новое заключается в том, что агент может сам решать, когда браузер является подходящим инструментом, писать программу для его управления, сочетать результаты с вызовами MCP и выполнением кода, продолжая работу без необходимости разработчиками создавать индивидуальные решения для каждого приложения, предназначенного для людей.
Машинные интерфейсы по-прежнему превосходят их: они более надежны, безопасны и легче поддаются управлению. Однако в мире множество систем, которые не предоставляют необходимых возможностей через простой интерфейс, а рабочие процессы раньше требовали от человека открытия сайта и выполнения работы вручную. Выполнение в браузере смещает эти границы: оно превращает человеческий интерфейс в еще одну программируемую поверхность, которую следует использовать осторожно, строго изолировать и применять лишь тогда, когда структурированные интерфейсы оказываются недостаточными.
Следующее поколение платформ агентов лучше всего понимать не как наборы более мощных инструментов или армии браузерных ботов, а как системы с несколькими средами выполнения и маршрутизатором, который определяет, какая из них должна обрабатывать каждую часть задачи. Цель не в том, чтобы заставить агентов делать больше кликов, а в том, чтобы позволить им обращаться к тем частям программного обеспечения, которые API пока не предоставляют.
Связанные статьи
- Объяснение вызова инструментов: как модели просят программное обеспечение выполнять действия и где возникают сбои — практический обзор вызова функций и использования инструментов: цикл запросов, схемы, инструменты для чтения и действий, агенты, MCP, вставка промптов, отслеживание и распространенные ошибки.