Виконання в браузері для AI-агентів: Playwright, MCP та безпечний виконавець
Виконання в браузері для AI-агентів: браузер як середовище виконання поруч із 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.
Деякі завдання є частиною робочих процесів інтерфейсу та не є окремими запитами. Розгляньмо ситуацію, коли потрібно „вибрати розділ Retail, Європу та останні 90 днів, а потім обчислити середній показник конверсії за країною“. Для цього може знадобитися низка фільтрів, крок обробки даних та вилучення отриманого результату, причому жоден кінцевий пункт не повертає відповідь безпосередньо. Браузер може керувати інтерфейсом та читати інформацію, яку генерує додаток.
Структуровані API, які можна викликати безпосередньо або через MCP, залишаються першим вибором, коли вони існують. Вони дешевші, більш предсказувані та легші у захисті. Браузер обробляє ту частину, яка знаходиться лише за інтерфейсом, призначеним для користувача.
Пошук — це не перегляд
У багатьох архітектурах агентів пошук в Інтернеті, отримання даних через HTTP, автоматизація браузера та використання комп’ютера об’єднуються в одну розмиту навичку „веб“, хоча це різні інструменти.
Якщо запитати, що змінилося у останній специфікації MCP, ймовірно, достатньо використати пошук в Інтернеті. Якщо є URL звичайної публічної статті, пряме отримання інформації може бути достатнім. Якщо потрібно працювати з Salesforce, слід використовувати його API або MCP. Якщо потрібно обчислювати статистику з JSON-даних, потрібно використовувати код.
Тепер уявіть інший запит: відкрити публічну панель керування, вибрати Україну, встановити рік на 2026, обрати режим Enterprise, пройтися по кожній категорії та обчислити середнє значення для кожного показника. Пошукова система не може виконати таку взаємодію, а звичайний HTTP-запит може повернути лише порожню структуру сторінки. Цікаві дані з’являються після того, як браузер виконує JavaScript, надсилає запити з боку клієнта, оновлює стан додатку та відображає результат.
Або портал вакансій: виберіть категорію AI Engineering, тип роботи Remote та країну Німеччина, а потім підрахуйте, скільки вакансій у описі згадують RAG. Це насправді не запит на пошук — це робочий процес інтерфейсу, який передує вилученню та обробці даних. Саме тут справжній браузер надає агенту щось нове — інтерфейс виконання в мережі зі станом.
Браузер — це середовище виконання
Керований браузер, такий як Amazon Bedrock AgentCore Browser, є інфраструктурою: ізольованою віддаленою сесією браузера, яку можна програмно керувати. LLM не спілкується з ним чудесним чином — ви самі визначаєте контракт між агентом та середовищем.
AgentCore Browser відкриває доступ до сеансів через кінцеву точку автоматизації WebSocket, а бібліотеки на кшталт Playwright можуть під’єднуватися до віддаленого Chromium через протокол Chrome DevTools. 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 до віддаленого браузера. Він виконує програму та повертає структуровані дані. Основний агент виконує свої дії лише один раз. Другий LLM, який переінтерпретує ту саму мету, має сенс лише тоді, коли завдання справді потребує дослідження. Для прогнозованого панелі керування, каталогу чи порталу цей підхід кращий за вкладений браузерний агент як за ціною, так і за простотою спостереження.
Чому підходить режим кодування
Це особливо важливо там, де вже використовується програмне викликання інструментів. Марнотратний підхід легко помітити: модель викликає 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 обробки даних у межах єдиного логічного середовища виконання. Під час розгортання Browser Executor все ще краще використовувати як окремий компонент. Браузери мають власний цикл життя та ризики: сесії, куки, локальне зберігання, завантажені файли, правила мережі, увійшені профілі, стан сторінки, записи та побічні ефекти поза межами вашої системи. Кодова пісочниця працює з CPU, пам’яттю, файлами, пакетами та процесами. Їх розділення дозволяє кожному середовищу виконання застосовувати модель безпеки, яка йому підходить. Режим коду може забезпечити обмежений браузерний клієнт, тоді як екзекутор керує віддаленою сесією, тож модель програмування залишається єдиною, а інфраструктура — розділеною.
Початок нудьги
Пропустіть універсального автономного агента браузера на початку. Перша корисна версія навмисно проста: одна ізольована віддалена сесія Chromium, невеликий контракт browser_execute, Playwright для автоматизації, суворий список дозволених доменів та структуровані результати. Протестуйте її на публічному панелі керування, що використовує багато JavaScript, або у зразковому додатку, де можна показати, що браузер краще справляється з пошуком та отриманням даних через HTTP.
Після того, як це спрацює, під’єднайте це до програмного паттерну, який вже використовується у режимі коду, щоб основний агент генерував браузерну програму та не викликав інструменти низького рівня для кліків знову та знову. Потім додайте автентифіковані профілі для контрольованих внутрішніх додатків, а також політики дій та механізми схвалення, перш ніж будь-який робочий процес зможе створити зовнішні наслідки. Використовуйте візуальне керування комп’ютером лише для інтерфейсів, які Playwright не може надійно обробляти, та розгляньте можливість створення спеціалізованого циклу браузер-агент, який спостерігатиме, аналізуватиме, повторюватиме спроби та досліджуватиме ситуацію лише тоді, коли завдання занадто неоднозначне для того, щоб основний агент міг створити стабільну програму. Такий порядок забезпечує зрозумілість архітектури та відкладає найдорожчу та найменш детерміновану поведінку на периферію, замість того, щоб робити її стандартною.
Більша зміна
Цікавим є не те, що ШІ може натиснути кнопку. Автоматизація браузерів існує вже багато років. Новизна полягає у тому, що агент може вирішити, коли браузер є правильним інструментом, написати програму для керування ним, поєднати результати з викликами MCP та виконанням коду та продовжити роботу, без необхідності для розробника створювати індивідуальну інтеграцію для кожного додатку, призначеного для користувачів.
Машинні інтерфейси все ще кращі: вони надійніші, безпечніші та легші у керуванні. Але світ сповнений систем, які не пропонують необхідних функцій через простий інтерфейс, а робочі процеси раніше завершувалися тим, що людина мусила відкрити сайт та завершити роботу. Виконання в браузері зміщує ці межі. Воно робить людський інтерфейс ще одним програмованим інструментом, який потрібно використовувати обережно, із суворою ізоляцією, та обирати лише тоді, коли структуровані інтерфейси не відповідають вимогам.
Наступне покоління платформ агентів краще розуміти не як набори більш потужних інструментів чи армії ботів у браузері, а як системи з кількома середовищами виконання та маршрутизатором, який визначає, яке з них має обробляти кожну частину завдання. Мета не в тому, щоб змусити агентів клікати частіше. Мета — дозволити їм отримати доступ до тих частин програмного забезпечення, які API ще не розкривають.
Пов’язані матеріали
- Пояснення виклику інструментів: як моделі прослять програмне забезпечення виконати дію та де виникають проблеми — практичний огляд виклику функцій та використання інструментів: цикл запитів, схеми, інструменти для читання та дії, агенти, MCP, вставка запитів, відстеження та поширені проблеми.