Google сделала computer use в Gemini API общедоступным. Разработчики теперь могут подключать к модели возможность видеть экран и выполнять действия от имени пользователя. Раньше такая функциональность была ограничена внутренними тестами и отдельными партнёрами, теперь доступ открыт для всех, у кого есть ключ API.
Если коротко: computer use — это не просто анализ скриншотов. Модель получает доступ к интерфейсу, понимает, что на нём происходит, и может кликать, вводить текст, листать страницы — то есть работать с приложением так же, как человек. Это открывает дорогу к автоматизации действий, которые раньше требовали написания отдельных скриптов или использования хрупких обходных путей.
Новость важна для команд, которые занимаются тестированием, роботизацией процессов или созданием AI-ассистентов. В этой статье разберём, как устроен computer use в Gemini API, где он показывает результат, а где пока лучше обойтись без него.
Что такое computer use в Gemini API
Computer use — это режим, в котором мультимодальная модель Gemini получает снимки экрана и может управлять мышью и клавиатурой через API. Вместо того чтобы просто описать картинку, модель принимает решение о следующем действии: куда кликнуть, что ввести, какой элемент выбрать. Для этого она опирается на координаты и доступные ей инструменты.
Отличие от обычного распознавания изображений в том, что здесь есть цикл: модель видит результат своего предыдущего действия, оценивает его и корректирует следующий шаг. Так она может доводить задачу до конца, а не выдавать одноразовый ответ.
Как модель видит экран и совершает действия
Технически это выглядит так: приложение передаёт в Gemini API снимок экрана или поток снимков. Модель возвращает структурированный ответ — например, координаты точки для клика или текст для ввода. Затем ваша программа выполняет это действие, делает новый скриншот и отправляет его снова. Получается цикл из нескольких запросов, пока задача не будет решена.
Важно понимать: Gemini сама не имеет доступа к вашему компьютеру. Она лишь предлагает, что сделать. Исполнение лежит на вашем коде. Такой подход даёт гибкость — вы контролируете каждое действие и можете остановить процесс в любой момент.
Задержка между действиями зависит от скорости API и сложности экрана. Для интерфейсов, где всё статично, цикл работает быстро. Динамические страницы с анимацией требуют большего количества итераций — модель должна дождаться, пока элемент появится или изменится.
Есть нюанс: модель видит только то, что попадает в кадр. Если элемент уходит за пределы окна или скрыт под всплывающим окном, ей нужно сначала прокрутить страницу или открыть нужный раздел. Поэтому сценарии, где интерфейс сильно меняется, требуют продуманной логики на стороне разработчика.
Где это приносит пользу: сценарии для практики
Первый очевидный сценарий — автоматизированное тестирование интерфейсов. Вместо того чтобы писать хрупкие селекторы для каждого элемента, можно дать модели задачу «пройти регистрацию» и дать ей доступ к окну браузера. Это особенно удобно для приложений, которые часто меняют вёрстку.
Второй сценарий — роботизация рутинных операций. Например, перенос данных из одной системы в другую, если нет API. Модель может открыть файл, прочитать нужные поля, ввести их в форму и подтвердить отправку. Настройка занимает меньше времени, чем классический RPA, потому что не нужно программировать каждый шаг.
Третий — создание персональных ассистентов, которые помогают пользователю с веб-интерфейсами: забронировать столик, заполнить заявление, собрать данные с сайта. Здесь computer use становится заменой расширениям браузера и макросам, но с более широкими возможностями.
Отдельно стоит упомянуть автоматизацию рутинных действий в десктопных приложениях, у которых нет веб-версии. Если приложение работает в Windows и принимает ввод с мыши, Gemini сможет управлять им так же, как человек.
Когда computer use пока не стоит доверять
Модель совершает ошибки, и это нормально для технологии на текущем этапе. Нужно закладывать механизмы проверки: например, после каждого важного шага подтверждать, что действие привело к ожидаемому результату. Если страница загрузилась медленно или изменилась, модель может кликнуть не туда.
Не рекомендуется использовать computer use для операций с высокой ценой ошибки: денежные переводы, удаление данных, отправка писем. Ошибка модели может стоить дороже, чем экономия на ручном труде. Лучше ограничить доступ к таким действиям или требовать подтверждение человека.
Проблемы возникают и с интерфейсами, которые используют сложную графику, некорректно отображаются в виртуальной среде или требуют аппаратных ключей. Модель видит только пиксели, поэтому элемент, который не отрисован, для неё не существует.
| Ситуация | Что делать |
|---|---|
| Интерфейс меняется после каждого шага | Добавить паузы и повторные скриншоты, задать модель больше контекста |
| Критичная операция (платёж, удаление) | Вынести за пределы computer use или требовать ручное подтверждение |
| Элемент появляется только после анимации | Увеличить таймауты и предусмотреть ожидание в коде |
| Модель кликает мимо нужной кнопки | Использовать скриншоты с более высоким разрешением |
Ошибки чаще всего возникают на нестандартных элементах вроде календарей, слайдеров, drag-and-drop. Если ваш интерфейс насыщен такими виджетами, стоит сначала прогнать несколько тестовых сценариев и оценить процент успешных прохождений.
Как подключить и проверить: пять шагов
- Получите API-ключ в Google AI Studio и убедитесь, что у вас есть доступ к модели, работающей с computer use.
- Подготовьте окружение: виртуальную машину с браузером или изолированный десктоп, куда вы будете отправлять скриншоты.
- Напишите функцию, которая делает скриншот экрана и отправляет его в API вместе с запросом, описывающим задачу.
- Пропишите обработку ответа модели: извлеките координаты клика или текст, выполните действие через библиотеку автоматизации (например, PyAutoGUI или Playwright).
- Сделайте цикл: после действия делайте новый скриншот и отправляйте в API, пока модель не сообщит о завершении.
Для проверки начните с простого сценария — например, заполнения формы на тестовой странице. Отслеживайте, сколько итераций потребовалось и где произошли сбои. Это поможет понять, какие части вашего интерфейса модель понимает хорошо, а какие требуют дополнительных инструкций.
Первый шаг к запуску
Начните с ограниченного набора действий на тестовом контуре. Зафиксируйте, как ведёт себя модель при изменении разрешения экрана, размера окна и скорости интернета. Эти параметры влияют на качество скриншотов и стабильность цикла. Если прототип отрабатывает простые сценарии без участия человека, расширяйте область на более сложные задачи. Запускайте автоматизацию только после того, как убедитесь, что падение или «застревание» модели не приведёт к необратимым последствиям.
