Managed Deep Agents в LangSmith теперь запускают для агента полноценный браузер. Он работает в отдельной песочнице, а управление идёт через набор инструментов, рассчитанных на экономный расход контекста: browser_snapshot читает дерево доступности страницы, browser_run выполняет пачки действий или JavaScript через Playwright-подобный объект page, browser_screenshot снимает отрендеренную страницу, browser_handoff передаёт браузер человеку. Включается всё файлом browser.py в корне проекта и вызовом define_browser. Анонс в блоге LangChain описывает браузер как инструмент для работы там, где API не хватает.
Практический смысл простой. Агенту нужно забронировать рейс или столик в ресторане, отменить подписку, заполнить форму, прокликать сценарий покупки. API под такие задачи либо нет, либо его мало. LangChain отдельно оговаривает правило: если у сайта есть API под конкретную задачу, агент должен идти через API. Браузер остаётся для случаев, где веб-интерфейс — единственный вход.
Второй сценарий из анонса — end-to-end тестирование фронтенда. Кодирующий агент поднимает приложение в своей песочнице, открывает изменённую форму в браузере и кликает по ней. Так работает Open SWE, кодирующий агент авторов. Ту же возможность получают агенты, собранные на open-source Deep Agents.
Тренд под это подстраивается. По данным DataDome, которые приводит LangChain, агентские браузерные запросы выросли в 4,7 раза только за сентябрь. Персональные агенты Instinct и Muse от Meta уже работают через браузер.
Почему curl и обычный HTTP-запрос не решают задачу
curl возвращает HTML до того, как JavaScript отрисует страницу, и кликать не умеет в принципе. На современных сайтах контент и формы часто собираются на клиенте: в исходной разметке лежит пустой каркас, а поля, кнопки и валидация появляются после исполнения скриптов. Агент, который дёргает URL и парсит ответ, видит структуру без интерфейса.
Отсюда выбор источника данных для модели. browser_snapshot читает дерево доступности: заголовки, поля, кнопки и ссылки с ролями и подписями. Такое представление компактнее сырого HTML с сотнями служебных атрибутов и полезнее скриншота, потому что модель получает не картинку, а список элементов, по которым можно кликать. Похожий цикл «наблюдение — решение — действие» разобран в материале про браузерного агента для тикетов техподдержки.
Как включить браузер в своём агенте: define_browser и browser.py
Подключение занимает один файл. В корне проекта создаётся browser.py, из которого экспортируется объект browser:
# browser.py
from managed_deepagents import define_browser
browser = define_browser(
scope="thread",
idle_ttl_seconds=600,
)Это весь минимум из анонса: два параметра, scope и idle_ttl_seconds. Инфраструктуру поднимать не нужно. Managed Deep Agents устроены так, что вы пишете инструкции и инструменты агента, а LangSmith запускает harness и runtime. Браузер живёт в отдельной песочнице, не в вашем процессе и не на вашей машине.
Четыре инструмента браузера и зачем их разделили
Каждый шаг агента съедает токены, а скриншот страницы стоит заметно дороже текстового снимка дерева доступности. Поэтому набор разбит по назначению, а не свален в один универсальный вызов.
| Инструмент | Что делает | Когда вызывать |
|---|---|---|
| browser_snapshot | Читает дерево доступности страницы | Осмотр страницы и поиск элементов, основной рабочий инструмент |
| browser_run | Выполняет пачки действий или JavaScript через объект page | Клики, ввод в поля, прокрутка, заполнение форм |
| browser_screenshot | Снимает отрендеренную страницу | Когда нужна визуальная проверка результата |
| browser_handoff | Передаёт браузер человеку | Вход, двухфакторка, капча, финальное подтверждение |
Логика простая: посмотреть дешевле, чем снять картинку, а снять картинку дешевле, чем тащить в контекст весь HTML. browser_run принимает пачку действий, чтобы модель не тратила отдельный шаг на каждый клик.
scope="thread" против scope="user": что выбрать на практике
scope решает, кто с кем делит браузер. scope="thread" стоит по умолчанию: у каждой ветки свой браузер, каждое обсуждение начинается со свежего окна без cookies и логинов из другой ветки. scope="user" даёт один браузер на авторизованного пользователя. У каждой ветки при этом своё окно, две беседы одновременно не кликают друг по другу, но cookies и прочее состояние браузера общие. Вход на сайт в одной ветке подхватывается в следующей, логиниться заново не нужно.
На практике выбор такой. Разовые бронирования, проверки, прогоны e2e-сценариев — thread: чистое окно на каждую задачу, никаких следов от предыдущей. Повторяющиеся задачи в личном кабинете одного человека — user: агент один раз прошёл вход и дальше работает с той же сессией.
idle_ttl_seconds по умолчанию 600, то есть десять минут без активности, и браузер гасится. Параметр отвечает сразу за две вещи: за ресурсы платформы и за то, что сессия не живёт вечно после того, как задача закончилась.
Когда общий браузер — это риск, а не удобство
Общие cookies означают, что логин, полученный в одной ветке, доступен в другой ветке того же пользователя. Для личного ассистента это удобство. Для команды это вопрос доверия: доступ к сессии получает любая ветка, которую платформа отнесёт к тому же пользователю. В анонсе не описаны механизмы разграничения доступа между ветками внутри scope="user", поэтому перед продакшеном стоит проверить на своей конфигурации, какие именно ветки и агенты попадают в один скоуп. Смежная тема разделения прав и памяти пользователя разобрана в статье про Managed Deep Agents 0.8.
Handoff: как агент входит на сайт, не получая пароль
Авторизация — главный барьер браузерной автоматизации. Handoff снимает его без передачи пароля агенту: агент просит пользователя войти самому в интерактивной карточке LangSmith Studio и вернуть управление. Учётные данные сохраняются между сессиями, поэтому повторный вход не требуется каждый раз. Описание механизма прямо говорит о сохранении credentials между сессиями.
Где handoff обязателен: сайты с логином, капчей, двухфакторной аутентификацией, подтверждением по SMS или email, а также финальные необратимые шаги — оплата, подтверждение брони, удаление аккаунта. Агент делает подготовительную работу, человек выполняет чувствительный шаг. Это не костыль, а осознанная граница ответственности.
Практический сценарий: бронирование и отмена подписки
- Агент открывает сайт и через browser_snapshot находит форму поиска или поле нужной услуги.
- browser_run заполняет даты, город, количество гостей и отправляет форму пачкой действий.
- На шаге, где нужен личный кабинет, агент вызывает browser_handoff и останавливается.
- Пользователь входит в карточке Studio, при необходимости проходит двухфакторку и возвращает управление.
- Агент продолжает: проверяет, что данные сохранились, доходит до экрана подтверждения и завершает действие.
Второй типовой случай — отмена подписки. Кнопки удаления часто спрятаны за тремя экранами настроек, API для отмены не публикуют, а иногда требуют переписку с поддержкой. Браузер проходит эти экраны, handoff закрывает вход. Финальное подтверждение отмены лучше оставить человеку: цена ошибки слишком высока, чтобы отдавать её модели.
End-to-end тесты: браузер в песочнице и localhost-мост
Сценарий из анонса: pull request меняет форму регистрации. Кодирующий агент запускает приложение в своей песочнице, открывает форму в браузере и кликает по ней, чтобы проверить, что изменение работает. Приложение в песочнице агента доступно браузеру через localhost-мост, то есть агент поднимает сервис на локальном адресе, а браузер обращается к нему как к обычному сайту.
Пройденные шаги можно сохранить как обычный Playwright-скрипт. Разовая проверка превращается в воспроизводимый тест: его потом гоняют без модели, без токенов и без вариативности, которую вносит LLM. Подход используется в Open SWE. Полноценный CI это не заменяет, но снимает ручную проверку конкретного изменения перед мержем. Как такой сценарий выглядит на практике, включая доступ к браузеру через Playwright MCP и прогон в CI, разобрано в материале про e2e-тесты с Claude Code.
Насколько это работает: WebVoyager, Stagehand и цифры авторов
Инструменты построены на open-source SDK Stagehand от Browserbase. По данным авторов, на 100 задачах WebVoyager набор прошёл 90% при общих затратах $1.98 и показал лучший результат среди семи протестированных наборов инструментов.
Читать эти цифры стоит с оговорками. Сто задач WebVoyager — узкий бенчмарк на типовых веб-задачах, а не продакшн-нагрузка с антиботом, медленными сайтами и нестандартными интерфейсами. $1.98 — стоимость конкретного прогона, а не цена продукта: в неё не входят ни разработка агента, ни повторные попытки на живых сайтах. Сравнение шло с шестью другими наборами инструментов, и детали методики в анонсе не раскрыты. Авторы обещают отдельный разбор тестирования и настройки браузерных инструментов в следующей публикации, на момент выхода этой статьи его ещё нет. Анонс фиксирует только сам факт тестирования.
Как вообще устроена оценка агентов на длинных сценариях, видно по методологии команды Deep Agents: наборы задач с многократными прогонами, облегчённый бенчмарк для быстрых итераций и unit-тесты на отдельные поведения. Подробности в разборе фреймворка для сквозного тестирования AI-агентов. Один процент успеха на сотне задач не говорит, как агент поведёт себя на сайте с капчей и сменой вёрстки раз в неделю.
Ограничения подхода: где браузерный агент ломается
- API в приоритете. Если у сайта есть API под задачу, браузер не нужен: вызов API дешевле, быстрее и не ломается от смены вёрстки.
- Антибот. DataDome зафиксировал рост агентских браузерных запросов в 4,7 раза за сентябрь. Чем больше агентов, тем активнее сайты фильтруют автоматизацию, и это гонка, а не решённая проблема.
- Время жизни сессии. idle_ttl_seconds=600 означает: десять минут без активности, и браузер погашен. Для сценариев с долгим участием человека значение стоит выставить с запасом и проверить поведение на своей конфигурации.
- Присутствие человека. Handoff требует, чтобы пользователь был на месте и вошёл. Полной автономности в сценариях с авторизацией не будет.
- Стоимость и задержки. Снимок страницы и решение модели на каждом шаге дороже одного HTTP-запроса. Длинные многошаговые сценарии накапливают и время, и токены.
- Общее состояние. В scope="user" cookies делятся между ветками, а значит логин в одной ветке виден в другой. Это вопрос доверия к тому, кто получает доступ к пользовательской сессии.
Чек-лист: браузер или API
- Есть API под задачу — идём в API, без вариантов.
- Контент рендерится JavaScript, нужны клики или ввод в поля — браузер.
- Нужен вход по паролю, 2FA или капча — браузер плюс handoff.
- Нужна проверка фронтенда перед мержем — браузер в песочнице, localhost-мост, сохранение шагов в Playwright-скрипт.
- Разовая чувствительная операция (платёж, бронь, удаление аккаунта) — handoff на финальном шаге.
Кому это нужно и что делать дальше
Подходит командам, которые уже работают на LangSmith и которым нужна автоматизация сайтов без API или e2e-проверки фронтенда внутри агентского цикла. Подходит тем, кто строит агентов на Deep Agents и хочет добавить браузерный режим без собственной инфраструктуры. Подходит для задач, где человек готов присутствовать на шаге входа.
Не подходит, если задача закрывается API. Не подходит, если нужна гарантированная работа против агрессивной антибот-защиты: здесь никто гарантий не даёт. Не подходит, если процесс должен идти полностью без участия человека на авторизации.
Дальше три шага: завести browser.py с define_browser, выбрать scope под сценарий (thread для разовых задач и тестов, user для повторяющейся работы в личном кабинете), заранее расписать точки handoff и выставить idle_ttl_seconds с учётом того, сколько человек может провести в карточке Studio. Разбор тестирования и настройки браузерных инструментов авторы обещали отдельно, и его стоит дождаться, прежде чем ставить агента на реальные бронирования и платежи.