Computer-use — это подход, при котором языковая модель управляет компьютером или браузером через скриншоты: видит экран, распознаёт элементы интерфейса и выполняет клики, ввод текста, скролл без специально подготовленного API. Главное следствие — не нужно договариваться с каждым сервисом об интеграции. Агент работает через тот же интерфейс, что и пользователь.

За 2025 год подход прошёл несколько публичных итераций. Anthropic выпустила computer use как часть Claude API, OpenAI встроила аналогичные возможности в Operator, появились специализированные фреймворки вроде Browser Use и Stagehand поверх Playwright и Puppeteer. К середине 2026 года инструменты есть у любой команды — вопрос в том, на каких задачах они действительно работают, а не только впечатляют в демо.

Как устроен computer-use технически

Базовая механика: агент запрашивает скриншот активного окна или браузерной вкладки, передаёт его в мультимодальную модель вместе с инструкцией, получает действие (click на координаты, type текст, scroll, wait), применяет действие через инструмент эмуляции ввода, делает новый скриншот — и цикл повторяется.

Конкретные реализации отличаются в деталях. Claude computer use API возвращает действия в структурированном формате (tool_use), приложение само применяет их через выбранный инструмент. Browser Use и Stagehand работают поверх Playwright: они управляют реальным браузером через его DevTools-протокол, что даёт более надёжное взаимодействие с DOM-элементами, чем чистые координаты на скриншоте. OpenAI Operator работает иначе — через совмещение скриншотов и доступа к DOM, что снижает зависимость от точного распознавания пиксельных координат.

Различие между «клик по координатам на скриншоте» и «клик по DOM-элементу» принципиально для надёжности. Координаты меняются при изменении вёрстки или масштаба. DOM-элементы — нет, если сайт не переписывает структуру. Фреймворки поверх Playwright используют второй подход везде, где это возможно, и первый как fallback.

Задачи, где это уже приносит пользу

Лучшие результаты — на рутинных, структурированных, повторяемых сценариях. Сбор данных с однотипных страниц без публичного API: агент проходит по пагинации, извлекает поля, записывает в таблицу. Заполнение форм: государственные и корпоративные порталы с устаревшим интерфейсом, где API нет и не планируется. Перенос данных между сервисами: выгрузить из одной системы, загрузить в другую, не писать разовый скрипт. Регрессионное тестирование UI: агент проходит по определённым сценариям и фиксирует визуальные аномалии.

В этих случаях ценность создаёт не интеллект модели, а способность механически повторять цепочку действий без усталости и по расписанию. Агент не устаёт на пятисотой одинаковой форме, не пропускает поле из-за невнимательности, всегда следует одному и тому же порядку шагов.

Отдельно работает гибридная схема в сервисных процессах: агент проходит по нескольким корпоративным системам, собирает информацию и готовит черновик ответа для оператора. Финальное решение принимает человек, агент берёт на себя навигацию и копирование. Эта схема даёт предсказуемую отдачу именно потому, что человек остаётся в контуре на критичном шаге — вся нестабильность агентного цикла изолирована на этапе сбора данных, а не применения решений.

Где ломается

Надёжность на длинных траекториях — главное ограничение класса. Каждое действие несёт небольшую вероятность ошибки: неточное распознавание элемента, неожиданное изменение вёрстки, всплывающее окно, которое перекрыло кнопку. На цепочке из 5–10 шагов это проявляется редко. На цепочке из 40–50 шагов накопленная вероятность сбоя становится заметной частью прогонов.

Непредсказуемые интерфейсные события — постоянный источник отказов: капча, cookie-баннер, сессионный таймаут, модальное окно с акцией, push-уведомление браузера — каждое из них может остановить агента, который не ожидал прерывания. Решаемо через явные обработчики и retry-логику, но каждый новый тип прерывания требует отдельного кода. Полного покрытия не существует — интерфейсы слишком разнообразны.

Безопасность — отдельный класс ограничений. Агент, действующий в реальном интерфейсе, может выполнить необратимое действие: отправить форму, удалить запись, подтвердить оплату. Для любой операции с реальными последствиями нужна точка обязательного подтверждения от человека. Без этого автоматизация создаёт риски, которые труднее контролировать, чем в традиционном RPA — там скрипты детерминированы, здесь поведение зависит от модели.

Стоимость и скорость тоже имеют значение. Каждый шаг требует обработки скриншота мультимодальной моделью — это медленнее и дороже вызова специализированного API. На задачах с высоким RPS или жёсткими требованиями к latency computer-use не конкурирует с прямой интеграцией там, где она возможна. Прямой вызов REST API займёт 50–100 мс; агентный шаг с обработкой скриншота — 2–5 секунд.

Как строить надёжные пайплайны

Практика успешных внедрений показывает одну общую черту: они начинаются с узкого, неопасного, хорошо повторяемого сценария с низкой ценой ошибки. Не «автоматизируем всю обработку заявок», а «агент собирает данные из трёх систем и готовит черновик». Масштаб расширяется только после доказанной надёжности на узкой задаче в продакшен-условиях.

Поверх агента строится слой контроля: изолированная браузерная сессия (sandbox без доступа к production-данным при первичной разработке), явное ограничение доступных действий на уровне фреймворка, журналирование каждого шага с записью скриншота, точки обязательного подтверждения перед необратимыми операциями. Хорошие фреймворки — Stagehand в частности — дают эти примитивы из коробки. Это превращает непредсказуемого универсального агента в управляемый инструмент с понятной зоной ответственности.

Отдельная практика — human-in-the-loop checkpoint. Агент выполняет шаги 1–N, затем обязательно останавливается и показывает оператору: вот что я собираюсь сделать дальше. Оператор подтверждает или корректирует. После подтверждения агент продолжает до следующего checkpoint. Это не полная автоматизация, но это позволяет использовать computer-use на операциях, где полная автоматизация недопустима — например, в регулируемых отраслях.

Конкуренция на уровне инфраструктуры контроля

Развитие этого класса инструментов в 2026 году идёт не столько в сторону улучшения базовых моделей, сколько в сторону инфраструктуры контроля — sandbox-окружений, аудита действий, механизмов отката. Anthropic, OpenAI и специализированные фреймворки конкурируют именно здесь.

Anthropic развивает Computer Use API с упором на безопасные примитивы: явные tool definitions для каждого разрешённого действия, детальные логи для аудита, поддержка human-in-the-loop. OpenAI в Operator добавил скрининг задач — модель сначала оценивает, безопасна ли задача для автоматизации, и отказывается от потенциально деструктивных операций. Browser Use (open-source) ставит на гибкость: минимальный фреймворк поверх Playwright, полный контроль разработчика над логикой безопасности.

То, что конкуренция сместилась именно в эту сторону — сигнал зрелости сегмента. Технология переходит из категории «посмотрите, как это работает» в категорию «как это эксплуатировать надёжно в продакшене». Это обычный признак того, что следующие 12–18 месяцев принесут не яркие новые демо, а тихие инженерные улучшения — меньшую частоту отказов, более предсказуемые затраты, лучшие инструменты отладки.