Браузерный тулкит нужен агенту в двух случаях: задача упирается в сайт без публичного API, либо требуется end-to-end проверка веб-приложения, которое собрал кодинг-агент. Если у сервиса есть стабильный API, браузер в стеке добавляет задержку, расход токенов и лишнюю точку отказа.
Как выбирать между конкретными тулкитами, хорошо видно на кейсе команды LangChain. Она сравнила семь браузерных тулкитов для Deep Agents на трёх бенчмарках и остановилась на Stagehand от Browserbase: 90% задач WebVoyager за $1,98 против 78% за $26,71 у Playwright MCP и втрое больше времени на задачу (разбор LangChain).
Разрыв в 13 процентных пунктов по точности объясняет лишь часть истории. Пересчёт на успешную задачу по этим цифрам даёт около $2,2 у Stagehand и около $34 у Playwright MCP: разница почти в 15 раз. Модель при этом не менялась, задачи WebVoyager шли на Claude Sonnet 5.5. Значит, основной вклад в счёт даёт дизайн инструментов, а не выбор модели.
Зачем агенту браузер и когда он не нужен
Browser use закрывает две ниши, и обе связаны с отсутствием нормального программного интерфейса: либо его нет у чужого сайта, либо его нет у вашего собственного приложения, пока оно не запущено.
Две ниши browser use: API не покрывает или нужен end-to-end тест
Первая ниша: действие, которое API не покрывает. Сайт без публичного API, форма, которую нельзя отправить иначе, сценарий, под который агента специально не настраивали. Персональные агенты вроде Instinct и Muse именно так планируют автопутешествия, отменяют неиспользуемые подписки и выставляют машины на продажу: пользователь формулирует задачу, агент кликает по живому сайту.
Вторая ниша: end-to-end тестирование. Кодинг-агент собрал веб-приложение, и проверить его нужно так, как это делает человек: открыть страницу, заполнить форму, нажать кнопку, посмотреть, что получилось. Юнит-тесты такой сценарий не ловят.
Обратная сторона: если API стабильный и покрывает задачу, браузерный агент проигрывает по всем метрикам. Дороже, медленнее, ломается от смены вёрстки. Браузер стоит держать как fallback для случаев, где программного интерфейса нет.
Почему браузерные задачи дорогие по определению
Браузерная задача длинная и состоит из множества последовательных вызовов инструментов. На Playwright MCP одна задача WebVoyager в среднем занимала 26 ходов модели. Каждый ход - это отправка контекста в модель и получение ответа, то есть токены и секунды.
Контент страницы добавляет второй множитель. Одна навигация через hosted MCP-сервер Browserbase возвращает медианно около 17 000 символов. Агент открывает несколько страниц за задачу, и каждый раз в контекст приезжает очередная порция разметки.
Умножьте 26 ходов на десятки тысяч символов, добавьте сетевые задержки и время на рендер, и станет понятно, почему дизайн инструментов влияет на итоговый счёт. Смена модели меняет цену токена. Смена тулкита меняет число round-trip'ов, а вместе с ним количество токенов и время.
Три формы браузерных тулкитов: нативные инструменты, MCP-сервер и CLI
Тулкиты бывают трёх форм: нативные инструменты, MCP-сервер и CLI, который агент запускает в shell. Большинство из них управляют браузером через Chrome DevTools Protocol (CDP), протокол инспекции и управления Chrome. Разница между формами в том, сколько прослоек и round-trip'ов появляется между решением модели и действием в браузере.
Native tools: минимум прослоек, максимум контроля
Нативный инструмент живёт внутри фреймворка агента: вызов попадает прямо в контекст, ответ возвращается сразу. Проще логировать, проще ограничивать набор доступных действий, меньше сетевых переходов. Минус один и серьёзный: привязка к фреймворку. Переехали на другой harness - инструменты переписывать. LangChain сравнивала именно тулкиты для Deep Agents, то есть наборы, которые встраиваются в конкретную агентную архитектуру.
MCP-сервер: стандартизация ценой лишнего хопа
MCP-сервер выносит браузер в отдельный процесс и общается с агентом по протоколу MCP. Плюс: один и тот же сервер подключается к разным агентам, и наоборот. Минус: появляется хоп между агентом и браузером, а провайдер решает, что именно вернуть в ответ. Hosted MCP-сервер Browserbase отдаёт медианно около 17 000 символов за навигацию, и этот объём нужно закладывать в бюджет токенов. Playwright MCP из того же сравнения - типичный пример такого подхода.
CLI в shell: гибко, но дорого по ходам
CLI-вариант заставляет агента формировать команды и разбирать вывод терминала. Гибкость максимальная: доступно всё, что умеет утилита. Плата - дополнительные ходы модели на составление команды, чтение вывода и обработку ошибок. На фоне 26 ходов на одну задачу WebVoyager у Playwright MCP каждый лишний шаг в такой траектории заметен и в токенах, и в секундах.
Как LangChain сравнивала семь тулкитов: бенчмарки и методика
Сравнение шло на трёх бенчмарках задач на живых сайтах: WebVoyager, HardBench и WebTailBench. Первый даёт повседневные сценарии, два других - сложные и хвостовые. Работа велась для Managed Deep Agents, продукта LangSmith: он позволяет создавать и разворачивать агентов без своей инфраструктуры и может запускать браузер за агента. Методику из этого кейса можно перенести в свой проект отдельно от самих результатов.
WebVoyager: 100 задач, Claude Sonnet 5.5 и судья Jev
WebVoyager - 100 повседневных задач на популярных сайтах: Allrecipes, Amazon, Google Flights. Запуск с Claude Sonnet 5.5, оценка судьёй Jev. Судья-модель удобна для массовой проверки, но у неё есть погрешность: она оценивает результат по описанию, а не по фактическому состоянию аккаунта. Как калибровать такого судью и какие ошибки он пропускает, разбирали на кейсе Similarweb с LLM-as-judge: оценка агентов для длинных исследовательских отчётов.
HardBench и WebTailBench: зачем ещё два бенчмарка
Один бенчмарк почти всегда завышает оптимизм. WebVoyager быстро насыщается, в материале LangChain это отмечено прямо, поэтому нужны наборы посложнее и наборы с длинным хвостом редких сценариев. HardBench и WebTailBench играют эту роль: именно на HardBench затем замеряли медианное время агента, которое упало со 182 до 124 секунд после одной правки harness.
Точный состав сценариев HardBench и WebTailBench в опубликованном фрагменте не раскрыт, поэтому относитесь к ним как к дополнительной проверке устойчивости, а не как к готовому публичному лидерборду.
LangSmith experiments: как сравнивать конфигурации бок о бок
Каждый запуск оформлялся как эксперимент LangSmith. Это даёт две вещи: конфигурации сравниваются бок о бок в одной таблице, а из любой метрики можно кликнуть в трассу, которая её дала. Без такой связки цифра «стало медленнее» бесполезна: непонятно, на каком шаге агент застрял. Как строить сквозные прогоны задач и сколько раз повторять каждую, подробно разобрано в материале о бенчмаркинге Deep Agents на фреймворке Harbor.
Результаты: Stagehand против Playwright MCP и остальных
Из семи тулкитов команда выбрала Stagehand от Browserbase. Ключевые цифры на WebVoyager: 90% задач за $1,98 у Stagehand против 78% за $26,71 и втрое большего времени на задачу у Playwright MCP (данные сравнения).
| Тулкит | WebVoyager, успешных задач | Стоимость прогона | Время на задачу |
|---|---|---|---|
| Stagehand (Browserbase) | 90% | $1,98 | втрое меньше, чем у Playwright MCP |
| Playwright MCP | 78% | $26,71 | втрое больше, чем у Stagehand |
Точность, стоимость и время: три метрики вместо одной
Смотреть только на success rate - значит потерять главное. Разница в точности 13 процентных пунктов выглядит скромно на фоне разницы в стоимости: $1,98 против $26,71 на один и тот же прогон из 100 задач. Пересчёт на успешную задачу даёт примерно $2,2 и $34 соответственно. Плюс Playwright MCP тратил втрое больше времени на задачу, а время в браузерных сценариях упирается в лимиты провайдера и в терпение пользователя.
Почему разрыв такой большой: три причины
Дело не в удаче на конкретных задачах. Три механизма в дизайне Stagehand дают накопленный эффект: code mode, snapshot и работа внутри браузера с минимумом round-trip'ов.
Три причины превосходства Stagehand: code mode, snapshot и работа внутри браузера
Code mode: один сниппет вместо серии вызовов
Агент пишет один сниппет, который выполняет несколько действий подряд, вместо серии отдельных tool calls. Клик, ввод текста, ожидание загрузки и чтение результата уходят в один ход модели. При 26 ходах на задачу у конкурента экономия на каждом втором-третьем шаге складывается в заметную разницу по токенам и времени.
Snapshot: компактное дерево доступности с ID интерактивных элементов
Вместо скриншотов и сырого HTML агент получает компактное дерево доступности с ID интерактивных элементов. Ему не нужно угадывать координаты кнопки на картинке и не нужно читать всю разметку страницы. Для сравнения: одна навигация через hosted MCP-сервер Browserbase возвращает медианно около 17 000 символов. Snapshot режет этот объём до списка элементов, с которыми реально можно взаимодействовать, и заодно снимает проблему с пиксельными координатами.
Минимизация round-trip'ов за счёт работы внутри браузера
Чем меньше переходов между агентом и браузером, тем ниже задержка. Каждый round-trip - это сетевой вызов, сериализация ответа и ещё один ход модели. Работа внутри браузера позволяет выполнить последовательность действий и вернуть один результат. Накопление таких переходов и объясняет, почему Playwright MCP тратил втрое больше времени на ту же задачу.
Как улучшать harness: цикл трасса → правка → evals
Выбор тулкита - половина работы. Вторая половина: найти неэффективности в том, как harness использует инструменты, и не сломать точность по пути. Процесс выглядит так: трассировка поведения агента, поиск узкого места, правка harness, проверка каждого изменения через evals до того, как оставить его в коде (описание цикла в разборе LangChain).
Трассы LangSmith: где искать неэффективность
В трассе видно, на что уходят ходы: повторные вызовы одного и того же инструмента, лишние чтения страницы, фиксированные ожидания там, где можно дождаться события. Метрика ведёт в трассу, трасса показывает конкретный шаг, шаг превращается в задачу на правку. Без этой связки разговор о скорости остаётся на уровне ощущений.
Evals как страховка от регрессий
Каждое изменение прогоняется через evals до принятия. Причина простая: ускорение легко покупается падением точности. Убрали ожидание, агент стал быстрее и начал кликать по ещё не отрисованной кнопке. На WebVoyager такой регресс виден по success rate, на HardBench - по числу проваленных сценариев.
Кейс: sleep → ожидание тишины страницы, 182 → 124 секунды
Самый показательный пример из разбора: фиксированные sleep заменены на ожидание тишины страницы. Медианное время агента на HardBench упало со 182 до 124 секунд без потери точности (кейс в блоге LangChain). Фиксированный sleep плох тем, что не связан с состоянием страницы: на быстрой странице он ждёт лишнее, на медленной заканчивается слишком рано. Ожидание тишины привязывает паузу к событию, а не к таймеру.
Приём не универсален: «тишина страницы» определяется эвристикой, и на сайтах с постоянным фоновым трафиком (аналитика, чаты, live-обновления) она может не наступить. Универсальность этого подхода LangChain не заявляла, эффект подтверждён evals в этом конкретном кейсе.
Ограничения Stagehand, hosted-браузеров и самого подхода
Зависимость от hosted-провайдера
Hosted-провайдер вроде Browserbase берёт на себя тяжёлую часть открытого веба: CAPTCHA, блокировку ботов и запуск множества браузеров на масштабе. Взамен вы получаете внешнюю зависимость: доступность, лимиты и цены определяет провайдер. Self-hosted вариант снимает часть этих вопросов, но возвращает вам борьбу с антибот-защитой, обновлениями браузера и изоляцией сессий.
Сайты сопротивляются активнее. Системы защиты вроде DataDome и их аналоги регулярно обновляют эвристики, и траектория, которая работала вчера, сегодня упирается в проверку. Это прямо влияет на стоимость: больше повторных попыток, больше ходов, больше токенов.
Почему нельзя слепо копировать результаты LangChain
Цифры 90% и $1,98 получены на конкретных 100 задачах WebVoyager, с Claude Sonnet 5.5, судьёй Jev и версиями тулкитов на момент сравнения. Другая модель, другой набор сайтов, другой судья - другие числа. Переносится методика: три бенчмарка, эксперименты в LangSmith, evals на каждое изменение. Результаты не переносятся.
Отдельно про выбор Stagehand: он сделан для Managed Deep Agents и их ограничений. Если проект требует CLI или собственного MCP-сервера, вывод может оказаться другим.
Практический чек-лист выбора тулкита под ваш проект
Вопросы, на которые нужно ответить до выбора
- Есть ли API? Если покрывает задачу, браузер не нужен.
- Какая форма вписывается в стек: нативные инструменты, MCP-сервер или CLI. От неё зависит число прослоек и привязка к фреймворку.
- Как тулкит отдаёт страницу агенту: компактный snapshot с ID элементов или скриншоты и сырой HTML. Второй вариант дороже по токенам и хуже для точных кликов.
- Есть ли code mode, то есть может ли агент выполнить несколько действий одним сниппетом.
- Сколько round-trip'ов уходит на типовую задачу. Замерьте на 20-30 своих сценариях, а не на демо.
- Нужен ли hosted-провайдер для CAPTCHA и масштабирования, и готовы ли вы к зависимости от него.
- Как вы будете мерить. Эксперименты и трассы в LangSmith плюс evals на регрессии дают воспроизводимость, без них сравнение превращается в спор о вкусах.
Когда взять Managed Deep Agents и не строить инфраструктуру
Managed Deep Agents в LangSmith позволяет создавать и разворачивать агентов без собственной инфраструктуры и может запускать браузер за агента. Вариант для случаев, когда не хочется держать парк headless-браузеров, следить за обновлениями и строить наблюдаемость с нуля. Плата - привязка к платформе и её модель ценообразования.
Перед стартом полезно пересмотреть и саму обвязку: в Deep Agents v0.7 входные токены сократили на 65%, с ~6k до ~2k, за счёт удаления дефолтного системного промпта и урезания описаний инструментов. Подробности - в разборе Deep Agents v0.7 и экономии входных токенов. Дешёвый harness с плохими инструментами всё равно проиграет, но начинать с двух сторон сразу разумно.
Практический вывод простой. Если браузерный агент уже в стеке, сравните хотя бы два тулкита на своих задачах и посчитайте стоимость успешной задачи, а не только success rate. Дизайн инструментов меняет счёт в разы, смена модели - заметно реже.