Новый Browser Automation Agent в Azure AI Foundry: многосессионный Playwright в пару команд

Что нового

Microsoft добавила в Azure AI Foundry готовый Browser Automation Agent на Python, который управляет браузером через Playwright CLI и Foundry Toolbox MCP. Это не абстрактный «ассистент», а конкретный bring-your-own агент, который:

• запускает удалённые Chromium-браузеры в Azure Playwright Workspace;
• создаёт сессии «лениво» — пока модель не вызвала инструмент, браузер не поднимается;
• держит несколько браузеров параллельно и управляет ими через единый API;
• даёт модели доступ к готовым сценариям («скиллам») для автозаполнения форм и веб-скрейпинга;
• позволяет пользователю в любой момент принудительно закрыть нужную сессию.

Чётких бенчмарков по скорости, стоимости или лимиту контекста в описании нет. Но есть конкретные технические возможности:

• работа с Python 3.12+;
• использование gpt-4.1 как чат-модели в Azure AI Foundry;
• таймаут для каждой команды playwright-cli задаётся через переменную окружения BROWSER_TIMEOUT_SECONDS (по умолчанию 180 секунд);
• управление удалённым браузером по CDP URL, который выдаёт Foundry Toolbox.

Ключевой акцент — не на новом типе модели, а на том, что теперь Foundry даёт готовый агент для браузерной автоматизации, который можно запускать локально, в контейнере и как hosted-агент в Azure.

Как это работает

Архитектура строится вокруг Responses Protocol и простого Python-сервера без Azure Agent Framework.

Цепочка выглядит так:

1. Пользователь отправляет текстовый запрос.
2. main.py принимает запрос по Responses Protocol и передаёт его в модель вместе с описаниями инструментов.
3. Модель в режиме tool calling выбирает нужный инструмент, например:
   • run_browser(command="goto", args=["https://..."]);
   • create_session(name="aws");
   • kill_session("email") и т.д.
4. На первом вызове run_browser сессия создаётся лениво:
   • toolbox.py через MCP вызывает Foundry Toolbox create_session;
   • Foundry Toolbox поднимает удалённый Chromium и возвращает cdp_url и live_view_url;
   • browser.py запускает playwright-cli attach --cdp=<url> и подключается к браузеру.
5. Все следующие вызовы run_browser по умолчанию используют уже созданную «default»‑сессию.
6. Для параллельной работы модель вызывает create_session(name) и получает дополнительные браузеры.
7. kill_session немедленно завершает нужную сессию или все сразу ("all").

Схема потока:

• User → Responses Protocol → main.py (handler)
• main.py → модель (loop с инструментами)
• Модель → инструменты run_browser / create_session / kill_session
• Инструменты → toolbox.py (MCP-клиент Foundry Toolbox) и browser.py (обёртка над playwright-cli)
• Foundry Toolbox → удалённый Chromium + CDP URL

Структура проекта

Проект организован так:

browser-automation/
├── main.py              # обработчик Responses, управление сессиями, цикл вызова инструментов
├── toolbox.py           # MCP-клиент для Foundry Toolbox (жизненный цикл браузерных сессий)
├── browser.py           # обёртка над playwright-cli (класс BrowserSession)
├── skills.py            # загрузчик markdown-скиллов
├── constants.py         # системный промпт, определения инструментов, конфиг
├── skills/
│   ├── form-filler.md   # сценарий заполнения форм с поддержкой date picker
│   └── web-scraper.md   # сценарий извлечения данных с пагинацией
├── agent.yaml           # конфигурация hosted-агента
├── agent.manifest.yaml  # манифест для инструментов azd
├── Dockerfile           # сборка контейнера
├── requirements.txt     # зависимости Python
└── README.md

Инструменты, доступные модели

Модель получает чёткий набор инструментов:

• run_browser — выполнение любой команды playwright-cli в рамках сессии. Если сессии ещё нет, создаётся автоматически.
• create_session — создание именованной сессии браузера для параллельной работы.
• kill_session — закрытие конкретной сессии или всех ("all").
• run_parallel — запуск нескольких команд сразу в разных сессиях.
• list_sessions — список активных сессий и их live_view_url.
• load_skill — загрузка markdown-скилла для пошагового сценария (формы, скрейпинг).

Skills лежат в папке skills/ и описывают типовые сценарии:

• form-filler — пошаговое заполнение форм, включая сложные элементы вроде date picker и многостраничные формы.
• web-scraper — извлечение данных с помощью JavaScript eval и обработка пагинации.

Модель сама решает, когда подключать skill, через инструмент load_skill.

Что это значит для вас

Кому это реально пригодится

• Разработчикам внутренних ассистентов, которые должны «ходить по сайтам» не только для чтения, но и для действий: логин, формы, клики.
• Командам, которые уже используют Azure AI Foundry и хотят добавить браузерную автоматизацию без написания своей обвязки вокруг Playwright.
• Тем, кто строит сложные сценарии: параллельный мониторинг нескольких страниц, human‑in‑the‑loop потоки (OTP, подтверждения по почте), заполнение длинных форм.

Типовые задачи, где агент помогает

1. Исследование в нескольких вкладках

   Пример из документации: ассистент одновременно открывает страницы с ценами на AWS и Azure, делает снимки и возвращает сравнение.

   • создаёт две сессии: "aws" и "azure";
   • в обеих выполняет goto на нужные страницы;
   • параллельно делает snapshot и формирует ответ.

2. Заполнение форм с участием человека

   Сценарий регистрации с OTP:

   • агент открывает страницу регистрации;
   • заполняет email;
   • нажимает кнопку отправки OTP;
   • останавливается и просит пользователя ввести код;
   • после ввода кода заполняет поле OTP, нажимает «Verify» и делает снимок страницы.

3. Мониторинг и работа в двух браузерах сразу

   Один браузер заполняет заявку на работу, второй следит за почтой:

   • сессия "application" — форма на careers.contoso.com;
   • сессия "email" — mail.contoso.com;
   • агент периодически обновляет почту, пока в другой сессии завершает форму.

4. Управление сессиями по запросу пользователя

   Пользователь может попросить закрыть только email-сессию, а сессию с заявкой оставить активной. Агент вызывает kill_session("email") и подтверждает действие.

Где использовать осторожно

• Массовый агрессивный скрейпинг публичных сайтов. Агент умеет это делать, но ответственность за соблюдение robots.txt, ToS и локального законодательства лежит на вас.
• Работа с сайтами, где сильно меняется DOM и селекторы. Придётся регулярно обновлять сценарии и селекторы в скиллах.
• Сайты с жёсткими антибот-механизмами. Автоматизированный Playwright может упираться в капчи и ограничения.

Доступность из России

Агент завязан на Azure AI Foundry, Azure Playwright Workspace и Azure CLI. Для полноценной работы нужен доступ к Azure и возможность аутентифицироваться через az login. Если инфраструктура Azure недоступна из вашей сети, может понадобиться VPN и корпоративная учётная запись Azure.

Место на рынке

Browser Automation Agent решает задачу, которая традиционно ложилась на связку «Playwright + самописный backend + своя логика сессий». Здесь Microsoft предлагает готовую связку:

• моделям Azure (например, gpt-4.1) не нужно напрямую работать с Playwright SDK — всё идёт через playwright-cli и инструменты;
• разработчик получает уже настроенный MCP-клиент для Foundry Toolbox и готовый hosted-агент.

Прямых численных сравнений с другими решениями в описании нет: нет данных по скорости относительно Puppeteer, Selenium или headless-браузеров у других вендоров. Но по функционалу заметно, что акцент сделан на:

• многосессионность из коробки (create_session, run_parallel, list_sessions);
• интеграцию с Azure AI Foundry и Foundry Toolbox, а не на «чистый» Playwright;
• скриптуемые сценарии в markdown (skills), которые модель подгружает сама.

Если вы уже сидите в Azure‑экосистеме и используете gpt-4.1 в Foundry, этот агент логично дополняет существующую инфраструктуру. Если у вас всё строится вокруг других облаков и своих Playwright-контейнеров, он полезен скорее как референс-архитектура.

Установка

Предварительные требования

Нужно подготовить:

• проект в Azure AI Foundry с развёрнутой чат-моделью, например gpt-4.1;
• Foundry Toolbox с настроенным инструментом browser_automation_preview, который опирается на Azure Playwright Workspace;
• установленный и аутентифицированный Azure CLI (az login);
• Python 3.12+ для локальной разработки.

Переменные окружения

Обязательные:

• FOUNDRY_PROJECT_ENDPOINT — endpoint проекта Foundry (в hosted-контейнерах подставляется автоматически);
• AZURE_AI_MODEL_DEPLOYMENT_NAME — имя деплоймента модели, например gpt-4.1.

Необязательные:

• BROWSER_TIMEOUT_SECONDS — таймаут для каждой команды playwright-cli. По умолчанию 180 секунд.

Как запустить локально

# Установить переменные окружения
export FOUNDRY_PROJECT_ENDPOINT="https://<account>.services.ai.azure.com/api/projects/<project>"
export AZURE_AI_MODEL_DEPLOYMENT_NAME="gpt-4.1"

# Установить зависимости Python
pip install -r requirements.txt

# Установить playwright-cli глобально
npm install -g @playwright/cli@latest

# Запустить агента
python src/main.py

Вызов агента через HTTP

После запуска можно отправить запрос curl:

curl -sS -X POST http://localhost:8088/responses \
  -H "Content-Type: application/json" \
  -d '{"input": "Go to https://example.com and tell me the page title"}' | jq .

Тестирование в Agent Inspector

В VS Code откройте Agent Inspector (Command Palette → Foundry Toolkit: Open Agent Inspector) и отправляйте сообщения интерактивно. Это удобно для отладки цепочек инструментов и проверки, как модель управляет браузером.

Деплой в Azure AI Foundry

Для развёртывания hosted-агента используется Azure Developer CLI (azd).

# Инициализация из манифеста
azd ai agent init -m agent.manifest.yaml

# Деплой агента
azd deploy

После деплоя нужно выдать управляемой идентичности агента роль Playwright Workspace Contributor в вашем Playwright Workspace. Без этого агент не сможет создавать браузерные сессии через Foundry Toolbox.

Примеры многосессионной работы

1. Параллельное исследование цен

Задача: сравнить цены на AWS и Azure.

• Пользователь: "Compare pricing on aws.amazon.com and azure.microsoft.com side by side".
• Агент:
  • create_session("aws");
  • create_session("azure");
  • run_parallel([ {session: "aws", command: "goto", args: ["https://aws.amazon.com/pricing/"]}, {session: "azure", command: "goto", args: ["https://azure.microsoft.com/pricing/"]} ]);
  • run_parallel([ {session: "aws", command: "snapshot"}, {session: "azure", command: "snapshot"} ]);
  • формирует ответ с сравнением.

2. Регистрация с OTP (human-in-the-loop)

• Пользователь: "Sign up on example.com/register with my email test@contoso.com".

• Агент:

  • run_browser(command: "goto", args: ["https://example.com/register"]);
  • run_browser(command: "fill", args: ["#email", "test@contoso.com"]);
  • run_browser(command: "click", args: ["#send-otp"]);
  • отвечает: "OTP sent to test@contoso.com. Please provide the code when you receive it.".

• Пользователь: "The OTP is 847291".

• Агент:

  • run_browser(command: "fill", args: ["#otp-input", "847291"]);
  • run_browser(command: "click", args: ["#verify-btn"]);
  • run_browser(command: "snapshot");
  • отвечает: "Verified! Proceeding with registration...".

3. Мониторинг почты во время заполнения формы

• Пользователь: "Fill the job application on careers.contoso.com, and keep checking my email on mail.contoso.com for a confirmation".

• Агент:

  • create_session("application");
  • create_session("email");
  • run_browser(session: "application", command: "goto", args: ["https://careers.contoso.com/apply"]);
  • заполняет форму;
  • run_browser(session: "email", command: "goto", args: ["https://mail.contoso.com"]);
  • run_browser(session: "email", command: "snapshot");
  • отвечает: "Form submitted. Checking email — no confirmation yet. I'll check again.".

• Пользователь: "Check email again".

• Агент:

  • run_browser(session: "email", command: "reload");
  • run_browser(session: "email", command: "snapshot");
  • отвечает: "Confirmation email received!".

4. Закрытие ненужных сессий

• Пользователь: "Close the email browser, keep the application one".
• Агент:
  • kill_session("email");
  • отвечает: "Closed email session. Application session still active.".

Как кастомизировать под свои сценарии

Вы можете:

• добавлять свои markdown-скиллы в папку skills/, описывая пошаговые сценарии для конкретных сайтов или типов задач;
• править constants.py, чтобы настроить системный промпт и поведение инструментов под ваши требования;
• модифицировать browser.py, если нужно использовать дополнительные флаги playwright-cli или подключать другие браузеры;
• донастроить agent.yaml и agent.manifest.yaml для своего пайплайна деплоя.

Итог: Browser Automation Agent в Azure AI Foundry — это уже собранный каркас для ассистентов, которые должны не только читать веб, но и активно им управлять через Playwright, с поддержкой многосессионности и готовыми сценариями для форм и скрейпинга.

---

Читайте также

• Как подружить Terraform и Microsoft Foundry: DevOps-пайплайн для Hosted Agents без боли
• Как проверить голосового ассистента до релиза: Microsoft выложила VoiceLive Evaluation Harness
• Genie из Azure Databricks теперь работает в Copilot Studio и Microsoft Foundry: разговорная аналитика прямо в Teams