Gemini 3.5 Flash Computer Use API теперь встроен: как это меняет маршрутизацию агентских рабочих нагрузок

Google DeepMind интегрировал computer use как нативный встроенный инструмент в Gemini 3.5 Flash — ту же модель, которая уже обрабатывает function calling, Search grounding и Maps. Это не инкрементальное обновление. Решение сворачивает двухмодельную логику маршрутизации в единый endpoint и меняет структуру затрат операторов на агентскую автоматизацию браузера.

Если ваша команда сейчас маршрутизирует задачи computer use на отдельную standalone-модель, это меняет архитектурное решение.

Что произошло

Прежде Gemini computer use требовал отдельного endpoint — standalone-модели (gemini-2.5-computer-use). В новой версии computer use интегрирован непосредственно в gemini-3.5-flash как встроенный инструмент, наряду с существующими нативными инструментами — Search и Maps grounding.

Ключевые изменения:

• Один endpoint, несколько режимов инструментов. Разработчики вызывают Gemini API с включённым инструментом computer use на той же Flash-модели, которую уже используют для текстогенерации, function calling и grounding. Отдельный model specifier не нужен.
• Корпоративная система защиты. Доступны два опциональных уровня безопасности: явные пользовательские подтверждения для чувствительных или необратимых действий и автоматическая остановка задачи при обнаружении косвенного prompt injection.
• Доступность. Работает через Gemini API (ai.google.dev) и Gemini Enterprise Agent Platform (console.cloud.google.com/agent-platform).

Почему это важно для AI-инженерных команд

Переход от standalone-модели к встроенному инструменту имеет три конкретных последствия для операторов.

1. Упрощение маршрутизации. Любая команда, у которой есть условная ветка маршрутизации — «задача computer use → gemini-2.5-computer-use, иначе → gemini-3.5-flash» — теперь может эту ветку убрать. Flash-модель обрабатывает обе нагрузки. Логика fallback, отслеживание rate limit и сверка биллинга сокращаются с двух model identifier до одного.

2. Изменение базовой стоимости токенов. Standalone-модель computer use имела собственный тарифный уровень. Computer use как встроенный инструмент Flash тарифицируется по ценам Flash. Операторам нужно пересчитать прогнозы стоимости задачи для рабочих нагрузок браузерной и десктопной автоматизации — в большинстве случаев цены Flash должны быть ниже или сопоставимы, но профиль потребления токенов для computer use отличается от обычной генерации текста.

3. Архитектура безопасности переходит от выбора при развёртывании к конфигурации вызова. Две корпоративные опции защиты (ворота подтверждения, обнаружение injection) настраиваются на уровне запроса, а не развёртывания. Операторы, которые ранее изолировали computer use в отдельной модели как периметр безопасности, теперь должны реализовать аналогичные контроли через эти per-call флаги. Google по-прежнему рекомендует сочетать встроенные меры безопасности с изолированной средой исполнения, human-in-the-loop верификацией и строгим контролем доступа.

Анализ с точки зрения router/operator

Для команд, строящих многошаговые агентские pipeline, наиболее важным аспектом маршрутизации является управление prompt injection. Агенты computer use работают в реальных браузерных и десктопных средах, где могут встречать специально подготовленный контент, предназначенный для перехвата управления действиями агента.

Новая система защиты даёт операторам два рычага:

• Ворота подтверждения — требуют явного одобрения человека перед чувствительными или необратимыми действиями. Применяйте в production pipeline, затрагивающих пользовательские аккаунты, файловые системы или внешние API.
• Обнаружение injection с автоостановкой — модель останавливает задачу при обнаружении подозрительного injection вместо продолжения выполнения. Функция включается явно — по умолчанию отключена.

Ни один из этих механизмов не заменяет изоляцию. Рекомендации Google явны: используйте эти функции совместно с безопасной sandbox-средой браузера, human-in-the-loop верификацией и ограниченным контролем доступа. Для AI gateway, маршрутизирующих трафик computer use, это означает, что политика маршрутизации должна учитывать контекст среды исполнения инструмента — тестовая sandbox-среда допускает менее строгие ворота, а production-агент, работающий с клиентскими данными, требует строгой конфигурации.

На что обратить внимание при маршрутизации Gemini:

• Выявите, есть ли в текущих правилах маршрутизации записи, указывающие на gemini-2.5-computer-use или специализированный endpoint computer use — их можно объединить в gemini-3.5-flash с включённым флагом инструмента.
• Если вы отслеживаете расходы по моделям отдельно для computer use и текстовых нагрузок, пересчитайте прогнозы стоимости задачи.
• Проверьте конфигурацию безопасности в вашем agent wrapper — ворота подтверждения и обнаружение injection необходимо включать явно; оба отключены по умолчанию.
• Ознакомьтесь с документацией Gemini API по computer use для изучения синтаксиса вызова инструментов и рекомендаций по безопасности.

На что обратить внимание пользователям TheRouter

Если вы маршрутизируете Gemini-трафик через TheRouter, изменение касается конфигурации выбора модели. Если ранее для нагрузок computer use существовало отдельное правило маршрутизации, указывающее на standalone computer use модель, — это правило теперь можно упростить, направив такой трафик на gemini-3.5-flash с включённым инструментом computer use.

Следите за обновлениями в каталоге /models/ для актуальной информации об endpoint Gemini 3.5 Flash. Конфигурация ворот безопасности обрабатывается на уровне запроса в коде агента, не в слое маршрутизации — но слой маршрутизации определяет, на какой аккаунт и в какой bucket rate limit попадает трафик.