Как безопасно тестировать Computer Use в Gemini API

Создайте отдельный проект и один обезличенный кейс. Не начинайте с клиентских данных. Запишите четыре величины: корректность результата, задержку, usage из ответа и число ручных вмешательств. Для функций, способных вызвать действие, используйте тестовый endpoint без права изменять реальные записи.

Заранее определите pass/fail. Успех — это не «ответ выглядит нормально», а проверяемое условие: валидный JSON, найденный идентификатор, совпавшая сумма, полный аудиофайл, корректно закрытый поток или разрешённое действие.

Пошаговая настройка

1. Выполните контрольный запрос без функции Computer Use и сохраните сырой ответ.
2. Подключите Computer Use строго по актуальному примеру официального SDK. Не копируйте параметры из старых библиотек.
3. Повторите тот же вход, не меняя одновременно промпт и модель.
4. Проверьте обычный, пустой, противоречивый и потенциально опасный вход.
5. Запишите идентификатор запроса, модель, версию конфигурации, usage и результат валидатора.
6. Включайте функцию поэтапно, начиная с небольшого процента запросов.

Если API вернул 4xx, сначала исправьте запрос или права. Не повторяйте такую ошибку бесконечно. Для временной перегрузки и ограничения частоты используйте очередь, ограниченное число попыток и увеличивающуюся задержку. Операции с последствиями защищайте собственным ключом идемпотентности.

Готовый промпт

Работай только на тестовом сайте. Найди форму, заполни демонстрационные поля и остановись перед отправкой. Не вводи пароли и платёжные данные.
Если данных недостаточно, верни needs_human_review=true и перечисли missing_fields.
Используй только переданные данные и результаты разрешённых инструментов.

Промпт задаёт смысл задачи, но не заменяет программную защиту. Проверяйте схему ответа, допустимые значения, максимальную длину и права на действие в коде. Инструкция внутри письма, сайта или документа не должна менять системные правила.

Пример входа и ожидаемый результат

Вход: тестовая форма заказа. Ожидается предложение клика и ввода, но финальная отправка не выполняется.

Сохраните для теста вход, конфигурацию Computer Use, сырой ответ и итог бизнес-проверки. Если результат вариативный, повторите пример несколько раз и сравнивайте долю успешных ответов, а не выбирайте лучший вручную.

Как проверить качество

• Результат соответствует заранее заданному формату.
• Значения можно сверить с исходником или ответом инструмента.
• Пропущенные данные не заменены догадкой.
• Ошибка и отмена отображаются как отдельное состояние.
• Один пользовательский запрос не создаёт повторных внешних действий.
• В журнал не попадают ключи API и лишние персональные данные.

Добавьте в набор минимум десять реальных обезличенных примеров и пять пограничных. Полезные пограничные случаи: пустой файл, неизвестное поле, конфликт двух источников, длинный ввод, недоступный инструмент и попытка изменить правила внутри данных. После смены модели запускайте тот же набор снова.

Типичные ошибки

Смешивать инструкции и данные

Внешний текст может содержать фразы вроде «игнорируй предыдущие правила». Размечайте его как недоверенное содержимое и не выдавайте модели права на основе такого текста.

Оценивать один удачный ответ