Browser-use агенты в 2026: AI работает с браузером

Browser-use агенты в 2026: Playwright MCP, Browserbase MCP, Stagehand и Browser Use. Когда нужен DOM-first браузерный агент, а когда full computer use.

Browser-use агенты в 2026 уже нельзя описывать как набор разрозненных open-source хаков вроде browser-use + Stagehand + старый Playwright MCP из anthropic-quickstarts. Категория стала намного конкретнее: есть официальный @playwright/mcp от Microsoft, managed browser stack от Browserbase и Browser Use как отдельный OSS-plus-cloud слой с профилями, stealth и session lifecycle.

Главная идея не изменилась: агент работает не через внутренний API сайта, а через браузерный интерфейс. Но product framing стало заметно взрослее. Вопрос теперь не "может ли LLM кликать по сайту", а "какой execution layer выбрать: deterministic DOM automation, managed browser infrastructure или полноценный computer use по скриншотам".

Browser-use агент - это AI-агент, который умеет открывать сайт, кликать по элементам, заполнять формы, собирать данные и проходить многошаговые web-flow. Разница с обычным скрейпером в том, что агент понимает задачу на естественном языке и может адаптироваться к интерфейсу, а не только следовать жёстким CSS-селекторам.

Сначала ищите API. Потом MCP или обычную Playwright-автоматизацию. Потом browser-use слой. И только в самом конце - full computer use по скриншотам. Чем ближе вы к GUI и антибот-защите, тем выше цена ошибки, latency и операционные риски.

Короткая версия

Browser-use агенты нужны, когда у системы нет нормального API, но есть веб-интерфейс, через который реально выполнять работу:

войти в кабинет;
пройти multi-step форму;
скачать отчёт;
собрать данные с нескольких страниц;
проверить UI как пользователь.

В 2026 рынок удобно читать так:

Playwright MCP: официальный @playwright/mcp от Microsoft. Лучший вариант, когда агенту нужен надёжный DOM-first доступ к браузеру через MCP.
Stagehand / Browserbase MCP: natural-language browser automation поверх managed browser infrastructure. Подходит, когда важны hosted sessions, session reuse, observability и меньше ручной возни с исполнением.
Browser Use: Python-first стек для OSS и cloud browser automation. Сильная сторона - sessions, profiles, auth, stealth, proxies и production-friendly browser layer.

Browser-use

Агент открывает сайт поставщика, логинится, ищет раздел Invoices, выставляет даты, нажимает Download и проверяет, что CSV скачался.

API / MCP / backend

Один вызов backend-интеграции или MCP tool: `download_invoices(period='last_month')`.

Когда что выбирать

Сценарий	Что брать
Вам нужен стандартный MCP-сервер для Claude Code, Codex, Cursor или Copilot	`@playwright/mcp`
Нужен hosted browser + MCP endpoint + session persistence	Browserbase MCP
Нужны natural-language primitives `act()` / `extract()` / `observe()`	Stagehand
Нужен Python-first stack с профилями, stealth и auth workflows	Browser Use
Нужен не только браузер, а весь desktop / GUI	Computer Use

ПромптBrowser agent reviewer

У нас агент должен войти в B2B-портал, скачать вчерашний CSV и обновить внутреннюю таблицу. Что проверить до запуска?

Ответ модели

Есть ли API или MCP вместо web UI.
Как хранится login state: profile, cookies или ручной handoff.
Есть ли allow-list доменов и лимит по шагам.
Пишутся ли traces, screenshots и session recordings.
Что делать на CAPTCHA, 2FA и repeated failures.

Browser-use почти всегда лучше для веб-задач: он ближе к DOM, accessibility tree и browser session state. Full computer use нужен, когда задача выходит за пределы браузера или требует работы с несколькими GUI-приложениями.

1. Что такое browser-use агент

Browser-use агент - это не просто "LLM в браузере". Это execution loop, где есть:

browser session;
наблюдение за текущим состоянием страницы;
выбор следующего действия;
исполнение действия;
проверка, что цель приблизилась.

Разница между современными инструментами не в самой идее, а в том:

на каком уровне работает агент - DOM, accessibility, screenshot, CDP;
кто управляет browser lifecycle;
как устроены auth, sessions и profiles;
как выглядит observability и replay;
есть ли hosted infrastructure или всё локально на вас.

2. Browser-use, MCP и computer use - это не одно и то же

Слой	Что видит агент	Плюсы	Минусы
API / backend integration	Структурированные данные и команды	Быстро, дёшево, предсказуемо	Нужен API
MCP / Playwright / browser automation	DOM, accessibility, browser actions	Хорошо для web workflows	Ломается на антиботе и нестандартном UI
Full computer use	Скриншоты и GUI	Работает с любым интерфейсом	Медленно, дорого, хрупко

Поэтому browser-use не нужно подавать как замену API. Это слой для web-only but no-good-API сценариев.

3. Как выглядит current tooling

Playwright MCP: базовый DOM-first execution layer

Официальный Playwright MCP теперь живёт в репозитории Microsoft microsoft/playwright-mcp, а не в старом quickstart-репо Anthropic. Для большинства MCP-клиентов это уже стандартный способ дать агенту браузерные инструменты:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Сильные стороны @playwright/mcp:

стандартная MCP-интеграция для Claude Code, Codex, Cursor, VS Code, Copilot и других клиентов;
deterministic browser automation без лишнего product layer;
доступ к navigation, clicks, typing, snapshots и debugging surface;
хороший выбор, когда вы сами хотите контролировать orchestration.

Слабая сторона тоже понятна: это не готовая managed platform. Session lifecycle, auth strategy, anti-bot и production envelope по сути всё ещё на вас.

Stagehand: natural-language browser automation

Stagehand от Browserbase полезно мыслить не как "ещё один Playwright wrapper", а как AI-first browser automation framework. Его current framing строится вокруг четырёх primitives:

act() для одного действия;
extract() для структурированного извлечения;
observe() для состояния страницы;
agent() для multi-step workflow.

Это хороший слой между raw browser control и полноценным автономным агентом. Если вам нужен hybrid-подход "часть шагов кодом, часть шагов моделью", Stagehand обычно удобнее, чем писать весь loop вручную на Playwright.

Ещё один важный плюс: Browserbase явно строит вокруг этого session inspector и hosted execution, то есть речь не только про SDK, но и про operational browser platform.

Browserbase MCP: managed browser через MCP

Browserbase вынес этот же подход в отдельный Browserbase MCP Server. В docs они прямо рекомендуют hosted Streamable HTTP endpoint для большинства пользователей, а local stdio оставляют как вариант для кастомизации.

Это важный сдвиг рынка:

MCP перестал быть только локальным stdio-миром;
browser automation всё чаще подаётся как hosted service с persistent sessions;
browser stack всё сильнее похож на infrastructure layer, а не просто на npm-пакет.

Если вам нужен MCP-клиент плюс облачный браузер, Browserbase MCP обычно ближе к production, чем запускать всё локально через голый Playwright.

Browser Use: OSS plus cloud browser layer

Browser Use теперь тоже важно разделять на два слоя:

Open Source: Python library, локальный или self-hosted run, интеграция с любой LLM;
Cloud: managed tasks, browser infrastructure, sessions, profiles, proxies, stealth и auth helpers.

Для 2026 это уже не только "python-библиотека для LLM, которая кликает по сайтам". По current docs это полноценный browser platform layer:

stateful sessions;
persistent profiles;
live view и recordings;
profile sync для authenticated workflows;
residential proxies и stealth;
1Password / auth / 2FA workflows.

Это делает Browser Use особенно полезным там, где задача упирается не в один клик по сайту, а в устойчивое выполнение authenticated browser flows.

Плюсы

Хорошо закрывает web-only сценарии без нормального API
Даёт агентам доступ к реальному интерфейсу, а не только к backend данным
Позволяет совмещать code-first и natural-language automation
Современные managed stacks уже дают sessions, profiles, replay и observability

Минусы

Антибот, CAPTCHA, 2FA и consent screens остаются главным источником хрупкости
Browser automation всё ещё заметно медленнее и дороже API-first интеграций
Нужны отдельные safety controls для side effects и логинов
Без session strategy и trace logging demo быстро разваливается в production

4. Что реально ломает browser-use в production

Типичные failure modes у browser-use агентов в 2026 почти всегда одни и те же:

agent потерял login state;
anti-bot защита потребовала CAPTCHA;
layout поменялся и старый action plan стал неверным;
сайт загрузился частично и модель увидела неполное состояние;
workflow сделал side effect не на том аккаунте или не в том environment;
run зациклился на repeated retries.

Поэтому production-ready browser-use стек требует не только модели, но и отдельной operational дисциплины.

5. Минимальная operational architecture

Слой	Что должно быть
Session lifecycle	создание, reuse, timeout, clean shutdown
Profiles / auth	persistent cookies, profile sync, domain-scoped credentials
Domain boundaries	allow-list сайтов и environment separation
Observability	traces, session recordings, screenshots, console/network signals
Approval layer	handoff перед оплатой, отправкой, удалением, сменой пароля
Failure policy	retries, stop conditions, escalation to human

Хорошая эвристика простая: если вы не можете ответить, какой profile использует агент, где посмотреть replay и кто подтверждает irreversible action, у вас ещё нет production browser agent.

6. Когда что выбирать на практике

Берите Playwright MCP, если:

вы уже живёте в MCP-клиенте;
вам нужен стандартный browser tool без vendor-specific platform layer;
вы готовы сами управлять сессиями, auth и retry policy.

Берите Stagehand или Browserbase MCP, если:

нужен managed browser stack;
важны hosted sessions, inspector и Browserbase infrastructure;
вы хотите natural-language browser automation поверх нормального execution layer.

Берите Browser Use, если:

у вас Python-first команда;
сценарий сильно упирается в auth, persistent profiles и stealth;
нужен browser platform layer, а не только local automation script.

Уходите в full computer use, если:

workflow выходит за пределы браузера;
нужно работать с desktop apps, file pickers, remote desktops или mixed GUI;
DOM и Playwright уже не дают нужного контроля.

Computer Use: управление компьютером через AI - когда browser-use уже недостаточно
Tool Use в 2026 - как устроены custom tools, built-in tools и MCP-инструменты
MCP в 2026 - host-client-server, capabilities и transport surface
Безопасность LLM в 2026 - approval layer, tool abuse и defense in depth

7. Практический вывод

Browser-use в 2026 - это уже не "магия, которая сама ходит по сайтам", а отдельный инженерный слой между API-first automation и full computer use.

Если нужен самый прямой путь для агентного IDE-клиента - обычно хватит @playwright/mcp. Если нужен managed browser runtime - смотрите в сторону Browserbase MCP и Stagehand. Если нужен Python-first стек с профилями, auth и stealth - Browser Use выглядит сильнее большинства простых wrapper-подходов.

Но базовое правило не изменилось: чем быстрее вы можете заменить browser flow нормальной интеграцией, тем надёжнее будет система.

Проверьте себя

1. Что точнее описывает место browser-use агентов в стеке?

{ "text": "Это универсальная замена API и backend-интеграций", "correct": false, "explanation": "Нет. Browser-use нужен там, где хорошего API нет, но есть web UI." } { "text": "Это промежуточный слой между API-first automation и full computer use", "correct": true, "explanation": "Верно. Browser-use обычно лучше full computer use для веб-задач, но хуже хорошего API." } { "text": "Это просто другое название для MCP", "correct": false, "explanation": "Нет. MCP - это protocol layer, а browser-use - execution/use-case layer." }

2. Что изменилось вокруг Playwright MCP по сравнению со старыми статьями?

{ "text": "Актуальный путь теперь - официальный `@playwright/mcp` от Microsoft, а не старый quickstart Anthropic", "correct": true, "explanation": "Да. Именно так сейчас корректнее ссылаться на Playwright MCP." } { "text": "Playwright MCP исчез и больше не используется", "correct": false, "explanation": "Нет. Наоборот, он стал более официальным и стандартным." } { "text": "Playwright MCP работает только с Anthropic-моделями", "correct": false, "explanation": "Нет. Это MCP server, который можно подключать к разным агентным клиентам." }

3. Какой operational baseline ближе всего к production для browser-use?

{ "text": "Один локальный браузер без профилей, логов и replay", "correct": false, "explanation": "Такой setup слишком хрупкий и плохо отлаживается." } { "text": "Sessions, profiles, observability, allow-list доменов и approval layer", "correct": true, "explanation": "Верно. Без этого browser-use быстро разваливается на auth, side effects и repeated failures." } { "text": "Только сильный system prompt и temperature=0", "correct": false, "explanation": "Одного prompt'а недостаточно для управления браузером в production." }

Источники

Agent-to-Agent Protocol (A2A)

Claude Agent SDK