Если вы в последнее время пытались прикрутить к своему любимому 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 кодинге, и хорошо проводим время.