Источник: Google Developers Blog — https://developers.googleblog.com/all-the-news-from-the-google-io-2026-developer-keynote/
Ключевой доклад Google I/O 2026 для разработчиков был не столько про очередного помощника для кода, сколько про перенос агентов в разработческую инфраструктуру на правах полноценного слоя.
Главный тезис Google понятен: компания хочет, чтобы разработчики создавали и запускали агентов, которые проходят сложные рабочие процессы, а не просто отвечают на запросы или дописывают код. Анонсы охватывают модели Gemini 3.5, Antigravity 2.0, Managed Agents в Gemini API, инструменты для Android, интеграции с Chrome DevTools и раннюю работу над веб-стандартами через WebMCP.
Поверхность большая. Читать ее полезнее уже: Google пытается сделать агентную разработку не похожей на окно чата, а похожей на управляемую среду выполнения — с sandbox, контролем учетных данных, доступом к IDE и инструментам, путями деплоя и навыками под конкретные задачи.
Главный сдвиг: агентам дают инфраструктуру, а не только prompt#
Google построила доклад вокруг перехода от AI, который «помогает», к агентам, способным самостоятельно брать на себя более крупные части рабочего процесса. Практическая основа — Antigravity 2.0 и новый Antigravity CLI.
По словам Google, Antigravity теперь поддерживает специализированных субагентов для сложных сценариев. Также появились кроссплатформенный terminal sandboxing, маскирование учетных данных и усиленные политики Git. Эти детали важнее обещаний продуктивности. Как только агент может запускать команды, менять файлы, работать с репозиториями и перемещаться по проекту, модель безопасности становится частью продукта.
Antigravity CLI дает разработчикам еще одну поверхность для таких процессов. Google также анонсировала Antigravity SDK для команд, которым нужен программный контроль над agent harness и размещение агентов на собственной инфраструктуре.
Это разделение важно. Управляемые сервисы снижают порог входа. Самостоятельный хостинг нужен командам, которые не могут отправлять чувствительную логику сборки, учетные данные или состояние репозитория в полностью управляемый черный ящик. В источнике пока недостаточно деталей, чтобы оценить границы и исключения, но направление видно: Google хочет, чтобы один и тот же agent harness существовал в hosted-версии, CLI, API и self-managed-варианте.
Managed Agents приходят в Gemini API#
Google также анонсировала Managed Agents в Gemini API. Идея простая: один API-вызов поднимает агента с удаленным sandbox, используя Antigravity agent harness, без необходимости строить инфраструктуру самостоятельно.
Если это работает так, как описано, это один из самых заметных анонсов. Многие команды могут прототипировать агентные процессы через скрипты и tool calls. Гораздо меньше команд хотят поддерживать удаленные sandbox, политики выполнения, работу с состоянием и правила изоляции. Managed Agents пытается превратить эту операционную нагрузку в функцию API.
Компромисс привычный. Управляемое выполнение ускоряет внедрение, но концентрирует доверие. Разработчикам придется понимать, что и где запускается, к чему агент получает доступ, как изолированы sandbox, как хранятся логи и как защищены учетные данные. В посте Google упоминаются маскирование учетных данных и sandboxing в контексте Antigravity, но там нет достаточных деталей реализации, чтобы считать эти меры уже полноценно оцененными.
Пока безопасная трактовка такая: это снижает трение в оркестрации агентов, но не отменяет необходимости строить модель доверия.
AI Studio становится средой для сборки приложений#
Google AI Studio тоже глубже втягивается в разработку приложений. Google сообщила, что AI Studio теперь поддерживает нативный Kotlin для Android-приложений, интеграции с Google Workspace, деплой в Cloud Run в один клик и поддержку сервисов Firebase.
Цель — дать разработчикам возможность собирать и запускать full-stack-приложения прямо внутри AI Studio, а затем экспортировать полное состояние проекта в Google Antigravity, если они хотят продолжить разработку там.
Этот путь экспорта стоит отметить отдельно. AI-инструменты для сборки приложений часто ломаются на этапе передачи проекта: демо работает, но сопровождать проект вне среды генерации трудно. Google дает понять, что маршрут AI Studio → Antigravity должен сохранять состояние, а не оставлять разработчика в игрушечной рабочей области. Источник не доказывает, насколько чисто это работает в реальных проектах, но правильно указывает на слабое место таких инструментов.
Android получает инструменты, доступные агентам#
Android был одной из самых практичных тем доклада. Google анонсировала стабильный Android CLI, через который AI-агенты смогут использовать более тяжелые возможности Android Studio. Среди примеров — скачивание Android SDK и запуск приложений на Android-устройствах.
Это важно, потому что Android-разработка — не только генерация кода. В нее входят управление SDK, запуск на устройствах, системы сборки, миграции, UI-фреймворки и платформенные особенности. Дать агентам доступ к этим процессам через стабильный CLI полезнее, чем просить модель вспоминать shell-команды из памяти.
Google также открыла исходный код Android skills для LLM. Они должны вести модели по сложным workflow и API, включая миграции на Jetpack Compose и Jetpack Navigation 3. Смысл не в том, что LLM внезапно «знает Android». Смысл в том, что Google упаковывает прикладное знание в форму, которой могут пользоваться агенты.
Google отдельно выделила Android Bench — свой рейтинг LLM для задач Android-разработки — и сообщила, что на этой неделе туда добавили open-weight-модели, например Gemma 4. Рейтинг не гарантирует пригодность в реальных проектах, но дает командам точку сравнения лучше, чем общие coding-бенчмарки, которые могут плохо отражать Android-специфику.
Самое смелое Android-обещание — предварительная функция Android Studio, которая мигрирует код приложения в нативное Kotlin Android-приложение независимо от того, написан ли исходник на React Native, веб-фреймворке или iOS. Google заявила, что агент анализирует код и может сокращать миграции с недель до часов.
К этому стоит относиться как к preview-заявлению, а не как к плановой предпосылке. Инструменты миграции ценны тогда, когда сохраняют архитектуру, поведение, тесты, доступность и edge cases, а не просто выдают компилируемый код. Но если Google сможет сделать надежными хотя бы частичные миграции, это изменит подход команд к кроссплатформенному техническому долгу.
Веб получает агентные hooks и инструменты на уровне браузера#
Google также показала веб как среду, в которой агенты могут выполнять действия.
Самый ясный пример — WebMCP. Google описывает его как предложенный открытый веб-стандарт, который позволяет разработчикам открывать структурированные инструменты — включая JavaScript-функции и HTML-формы, — чтобы браузерные AI-агенты выполняли сложные задачи быстрее, надежнее и точнее. Экспериментальный WebMCP origin trial стартует в Chrome 149, поддержка Gemini in Chrome появится скоро.
Ключевое слово — «предложенный». Это еще не утвержденный стандарт. Если он созреет, веб-приложения получат более чистый интерфейс для взаимодействия с агентами, чем хрупкий screen scraping или угадывание DOM. Если он останется Chrome-first или фрагментированным, разработчики будут осторожнее строить на нем критичные процессы.
Google также анонсировала Modern Web Guidance в раннем preview. Это экспертно проверенные skills для coding agents по производительности, доступности и безопасности, с поддержкой более чем 100 сценариев. По словам Google, инструмент интегрируется с Baseline targets и устанавливается в Antigravity или через CLI командой npx modern-web-guidance install.
Это еще один сигнал: качество агентов может зависеть не только от общей силы модели, но и от отобранного операционного знания. Модель важна. Инструкции к инструментам, ограничения и циклы проверки могут быть не менее важны.
Chrome DevTools for agents двигает идею туда же. Google сообщила, что агенты смогут использовать возможности DevTools, чтобы проверять, отлаживать и оптимизировать код в реальном времени. Среди описанных сценариев — автоматические аудиты качества, имитация реального пользовательского опыта, передача сессии с auto-connect и другие процессы без ручного надзора.
Это может быть полезно. Но и требования к управлению становятся выше. Агент, который может инспектировать, отлаживать и оптимизировать через браузерные инструменты, ближе к младшему оператору автоматизации, чем к пассивному помощнику. Командам понадобятся логи, воспроизводимость, права доступа и обработка сбоев, а не только впечатляющие демо.
HTML-in-Canvas нацелен на более богатый веб#
Отдельно от слоя агентной оркестрации Google анонсировала HTML-in-Canvas API в origin trial. Идея — позволить разработчикам помещать настоящие DOM-элементы прямо в canvas с WebGL и WebGPU, сохраняя поиск, доступность и интерактивность.
Это рассчитано на иммерсивные и 3D-веб-сценарии, которым все равно нужны нативные возможности браузера. Если API заработает как задумано, он может снизить привычный компромисс между качественным canvas-рендерингом и преимуществами обычного HTML для доступности и поиска.
Но это снова origin trial. Разработчикам стоит оценивать его как раннюю платформенную возможность, а не как стабильную основу для production-архитектуры без проверки поддержки и требований к fallback.
Что проверить перед внедрением#
Практический вывод из I/O 2026 не в том, что «AI напишет все». Google собирает слой выполнения вокруг AI-разработки: sandbox, CLI, managed agents, browser hooks, Android task skills, доступ к DevTools и пути деплоя. Поэтому оценивать эти анонсы стоит не по качеству демо, а по тому, насколько безопасно и воспроизводимо агент проходит реальную задачу в вашем проекте.
Минимальный план проверки для команды:
- Возьмите небольшой, но настоящий репозиторий и дайте агенту одну измеримую задачу: исправить баг, обновить зависимость, пройти Android-миграцию или добавить тест.
- Запускайте агента сначала только с read-only-доступом. Разрешение на запись, push и запуск команд добавляйте по одному, после просмотра логов и diff.
- Проверьте, какие секреты видит агент: переменные окружения, tokens, файлы конфигурации, CI/CD-настройки, локальные credentials. Секреты должны быть замаскированы или недоступны по умолчанию.
- Зафиксируйте, где выполняется код: локально, в удаленном sandbox или в managed-среде. Для managed-варианта отдельно проверьте хранение логов, срок жизни окружения, сетевой доступ и правила удаления данных.
- Требуйте воспроизводимый результат: команды, diff, тесты, логи сборки и объяснение, почему агент выбрал именно эти изменения.
- Не принимайте миграции без обычного инженерного контура: code review, unit/integration-тесты, проверка доступности, performance-профиль и ручная проверка ключевых сценариев.
- Для WebMCP и HTML-in-Canvas закладывайте fallback. Оба направления еще ранние, поэтому критичные функции не стоит привязывать к ним без проверки поддержки браузеров и статуса стандартизации.
- Если работаете с Android, сравнивайте модели через Android Bench, но финальное решение принимайте на своих задачах: сборка, миграции, Compose, Navigation, тесты и запуск на устройствах.
Хороший первый пилот — не «дать агенту весь проект», а прогнать его через одну повторяемую задачу и ответить на четыре вопроса: что он изменил, почему, какие права использовал и можно ли повторить результат без ручной магии. Самая убедительная часть анонса Google именно в этом: агенты становятся полезными, когда могут действовать через надежные интерфейсы, с понятными ограничениями и проверяемым поведением.