Если вы в последнее время пытались прикрутить к своему любимому LLM‑агенту возможность самостоятельно гулять по интернету, дебажить веб‑приложения, и даже верстать, вы наверняка столкнулись с суровой реальностью. Оказывается, засунуть современный веб в контекстное окно нейросети — очень «дорогая» задача.
Обычно в таких случаях не глядя берут проверенные инструменты вроде Puppeteer или Playwright, которые обернуты в те самые три буквы MCP. Но ребята из Vercel недавно выкатили свою альтернативу — agent‑browser (cli‑утилиту, написанную на связке Rust и, некогда Node, но об этом позже). Зачем понадобился еще один велосипед для автоматизации, если у нас уже есть стандарты индустрии? Давайте разбираться.
1. Что не так с существующими решениями (Puppeteer, Playwright MCP и тд)
Никто не спорит, Playwright и Puppeteer — это шедевры инженерии. Они идеально подходят для того, для чего создавались: детерминированного end‑to‑end тестирования, CI/CD пайплайнов и предсказуемого парсинга.
Но когда мы пытаемся передать управление браузером AI‑агенту через популярный сейчас Model Context Protocol (MCP), начинается боль, и заканчиваются токены. Агенту нужно «видеть» контент страницы, чтобы понимать, куда кликать. Есть два основных способа дать ему эту возможность:
Скормить сырой HTML. И моментально выжечь весь контекст на одном только DOM‑дереве тяжелого SPA‑приложения.
Отдать Accessibility Tree. Это стандартный подход для MCP‑серверов, но полные деревья весят все равно неадекватно много.
Проблема совершенно не выдумана. Загляните в issue‑трекеры популярных инструментов: например, в официальном репозитории ChromeDevTools/chrome-devtools-mcp разработчики прямо показывают в логах, как один только клик и снятие снимка сложной страницы (вроде Jupyter Notebook) выбивает в трубу от 15 000 до 200 000 токенов за шаг. Агент делает пару кликов, забывает, зачем вообще пришел на сайт и как его зовут, и с треском падает с ошибкой context length exceeded.
К тому же, LLM часто галлюцинируют в сложных CSS‑селекторах. В итоге традиционные инструменты заставляют агента жрать лишние токены и постоянно промахиваться мимо кнопок.
2. Как Vercel избавились от лишнего и в своем же решении в том числе
Команда Vercel последнее время плотно занялась AI‑инструментами (тот же v0, инфра для агентов и тд) и столкнулась с очевидным затыком: им нужен был способ валидации фронтенда. Когда автономный кодинговый агент пишет компонент, он должен сам открыть браузер, покликать и убедиться, что всё работает.
Изначально они слепили гибрид: Rust‑клиент плюс тяжелый фоновый процесс на Node.js. В сети до сих пор можно наткнуться на статьи, где люди жалуются на скорость agent‑browser в той версии, сравнивая его с другими решениями. Но, к сожалению, или к моему счастью, ко мне в руки он попал уже тогда, когда из него полностью выпилили Node‑демон.
Архитектура стала максимально простой:
Единый бинарник (100% Rust): моментально парсит команды из терминала.
Прямое общение с CDP: Rust дергает Chrome DevTools Protocol напрямую, без прослоек.
Zero‑dependency: вам больше не нужно тащить в Docker‑контейнер всю экосистему Node.js.
Главная киллер‑фича — компактизация стейта. Вместо того, чтобы вываливать на агента весь DOM, agent‑browser делает снимок интерактивных элементов (snapshot -i) и присваивает им короткие референсы.
Для LLM вывод выглядит так:
button "Sign In" [ref=e1] textbox "Email" [ref=e2]
Это занимает пару сотен токенов. Агент понимает, что ему нужно нажать, и просто отправляет bash‑команду: agent-browser fill @e2 "admin".
3. Сравнение подходов и внезапный ответ от Microsoft
Разница в подходах лучше всего видна на практике. Допустим, мы просим агента: «Зайди на habr.com и кликни на первую статью».
Подход классического MCP‑сервера:
Агент вызывает инструмент навигации. В ответ ему прилетает простыня Accessibility Tree на 20 000 токенов. LLM продирается через эти мегабайты текста, чтобы найти заголовок, а затем пытается сгенерировать точный селектор для клика: browser_click({ "selector": "tm-articles-list__after-article h3 > a.title-link" }). Шаг влево, шаг вправо в верстке — и клик улетает в пустоту, или в диалог о согласии на куки.
Подход agent‑browser:
Агент плюет в bash одну строчку: agent-browser open https://habr.com. Затем делает agent-browser snapshot, получает плоский короткий список, где нужная ссылка помечена как [ref=e42], и отправляет agent-browser click @e42. Риск промахнуться стремится к нулю.
А как же playwright‑cli?
Самое смешное, что в Microsoft тоже осознали тупиковость классического MCP для агентов. Буквально недавно они выкатили свой ответ — @playwright/cli, специальный интерфейс именно для AI‑агентов. Не путать с обычным playwright раннером.
Они пошли по тому же пути и перевели агентов на bash. Теперь агент через Playwright тоже может написать playwright-cli click e15. Инструмент сам разбирается с селекторами под капотом, а вместо того, чтобы стримить гигантские деревья в контекст LLM, сохраняет стейт на диск. Это кардинально снижает расход токенов.
Сравнивая agent‑browser и playwright‑cli, мы видим битву двух одинаковых философий. Отличие в деталях: playwright‑cli тянет за собой всю мощь (и тяжесть) экосистемы Node/Playwright, предлагая привычный инструментарий для тех, кто уже плотно сидит на стеке с Playwright. agent‑browser же подкупает своей хайповой нативной Rust‑природой и абсолютным минимализмом — один маленький бинарник, который идеально ложится в легковесные контейнеры.
4. Заключение
Индустрия браузерной автоматизации прямо сейчас дробится на ниши. Сегодня есть разные способы дать возможность агенту пользоваться браузером, и каждый из них по‑своему хорош.
Если вам нужен сложный скрапинг данных с обходом антифрод‑систем или жесткие E2E‑тесты в пайплайнах, вы всё равно будете писать код на классическом Playwright. А если вы хотите, чтобы кодинговый агент сам проверял, что кнопка в вашем React‑Tailwind‑VibeСode‑WebApp работала так, как нужно, используйте легковесные обертки вроде agent-browser или нового playwright-cli.
Все эти подходы отлично работают, если применять их по назначению. Но самая важная мысль, которую я хочу, чтобы вы унесли с собой из этой статьи — не используйте MCP для браузера. Поберегите свои контекстные окна и деньги на API.
Ну, а на дорожку, пощупать agent‑browser можно буквально в пару строк:
npm install -g agent-browser npx skills add vercel-labs/agent-browser agent-browser install agent-browser open https://habr.com
А как ваши агенты пользуются браузерами? Есть ли решения еще более оптимизированные? И самое главное, как много токенов вы в свое время сожгли открытием одной веб‑страницы?
А если вам понравилось что тут написано или вы заинтересованы агентским кодингом, то приглашаю в свой телеграм канал: OpenKirill: AI Coding и другие приколы. Мы там разбираем тулинг, следим за новыми трендами в AI кодинге, и хорошо проводим время.
