Vercel представила agent-browser для AI-агентов — лёгкий доступ к браузеру без MCP

Vercel выпустила agent-browser — инструмент, который даёт AI-агентам доступ к браузеру без громоздких MCP-слоёв. Идея простая: показывать модели не весь DOM страницы, а только короткий список интерактивных элементов, с которыми можно сразу работать.

Почему MCP буксует

Playwright и Puppeteer никуда не исчезают: это сильные инструменты для e2e-тестов, CI/CD и предсказуемого парсинга. Проблемы начинаются в тот момент, когда браузер пытаются отдать под управление LLM через MCP. Чтобы модель понимала, куда кликать, ей нужно видеть страницу.

Обычно для этого в контекст отправляют либо сырой HTML, либо accessibility tree. На современных SPA это быстро превращается в лишние тысячи токенов на каждом шаге и съедает память агента раньше, чем он вообще дойдёт до цели. По данным, на которые ссылается автор разбора, один клик и снимок сложной страницы могут стоить от 15 до 200 тысяч токенов за шаг.

Это не только дорого, но и нестабильно: модель тратит контекст на чтение дерева страницы, начинает путаться в CSS-селекторах и чаще промахивается мимо нужных кнопок. Для детерминированных сценариев такой подход ещё терпим, но для автономного агента, который должен быстро ориентироваться в вебе, он слишком тяжёлый.

Что сделала

Vercel У Vercel задача была прикладная: если агент сам пишет интерфейс, он должен уметь открыть страницу, проверить компонент и пройтись по базовым действиям в браузере. Для этого команда упростила agent-browser и убрала прежнюю связку с Node-демоном. Текущая версия сделана как лёгкий CLI на Rust, который напрямую работает с Chrome DevTools Protocol.

В результате инструмент проще запускать локально, удобнее класть в контейнеры и не нужно тащить с собой дополнительную Node-инфраструктуру. единый бинарник на Rust прямое общение с CDP без лишних прослоек zero-dependency для Docker и локальных окружений короткие референсы вместо полного DOM Ключевая идея — snapshot интерактивных элементов. Вместо гигантского дерева агент получает компактный список вроде button "Sign In" [ref=e1] или textbox "Email" [ref=e2], а дальше работает короткими командами: открыть страницу, кликнуть по @e1, заполнить поле @e2.

Такой формат занимает уже не десятки тысяч, а сотни токенов. Для LLM это заметно снижает нагрузку и одновременно уменьшает шанс, что действие сломается из-за хрупкого селектора.

Новый интерфейс для агентов

Разница хорошо видна на простом сценарии: открыть сайт и нажать на первую статью. В классической MCP-схеме агент сначала получает огромный accessibility tree, потом ищет в нём нужный заголовок и пытается собрать точный CSS-селектор. Любое изменение в вёрстке, модалка с cookies или лишний контейнер делают такой клик хрупким. В agent-browser маршрут короче: open, затем snapshot, затем click по короткому ref. Модель опирается не на догадки о структуре DOM, а на уже подготовленную карту интерактивных элементов.

«Не используйте MCP для браузера — поберегите свои контекстные окна и деньги на API».

Показательно, что похожую идею уже двигает и Microsoft с @playwright/cli. Там агент тоже работает через короткие команды, а состояние браузера хранится вне контекста модели. Это важный сдвиг для всей категории agentic tooling: рынок отходит от идеи стримить внутренности браузера прямо в LLM и переходит к схеме, где локальный инструмент сам держит состояние, а модели отдаёт только минимально нужный слой управления. Разница между решениями теперь скорее в экосистеме: Playwright остаётся тяжелее, Rust-подход Vercel — минималистичнее.

Что это значит Браузерная автоматизация для AI-агентов начинает делиться на два класса.

Классический Playwright и Puppeteer остаются базой для сложного тестирования и скрапинга, но для агентского кодинга и быстрой валидации интерфейсов всё заметнее спрос на лёгкие CLI-обёртки. Главный вывод простой: для LLM выгоднее давать не весь браузер целиком, а компактный слой команд и ссылок на элементы. Это дешевле, стабильнее и практичнее в реальной работе.