Google в течение 11 часов без участия операторов проверяла Gemini 4 Argon на собственном Agent Development Kit и приняла в кодовую базу две оптимизации производительности. Подготовка сессий в памяти в длинных сессиях ускорилась примерно на 40%, а холодный импорт пакетов стал быстрее на 21%. Результат важен тем, что агент работал с уже существующим крупным проектом, а не создавал код с нуля.
Как проходил ночной запуск на кодовой базе ADK
Объектом стал код на Python объемом более 200 тысяч строк примерно в 800 файлах, покрытый почти 17 тысячами модульных тестов. Инженеры Google поставили задачу проверить, как модель справляется с существующей кодовой базой, и назвали это более сложным делом, чем создание приложений с нуля из пустой папки. Работу над производительностью выбрали намеренно, поскольку замедление редко находится в том файле, где проявляется симптом. Поэтому агенту требовалось удерживать карту всей системы в течение долгого запуска.
Сначала команда провела короткий пробный запуск, чтобы понять, что нужно включить в запрос для соблюдения правил модульного тестирования и замеров производительности. Затем правила конкретного репозитория оформили в файлах. agents/skills, которые описаны как руководство по адаптации нового инженера. Агенту поручили загружать только тот навык, который нужен для задачи, чтобы не переполнять контекстное окно. Итоговый запрос выполнили в Antigravity в режиме /goal, который сохраняет цель при уплотнении контекста.
По данным Google, журналы показали полный рабочий цикл: агент прочитал правила репозитория, зафиксировал базовые показатели, предложил оптимизации, проверил собственные изменения и выполнил все 16 892 модульных теста с открытым кодом. Принятые изменения отфильтровывают события перед копированием истории сессий и вводят ленивую загрузку, при которой тяжелые пакеты подключаются только по мере необходимости. Google противопоставляет это профайлеру: он показывает, что копирование сессий и импорт пакетов занимают время, но не прослеживает вызывающие стороны, подмены в тестах и общие ссылки в 40 файлах. Такая межмодульная проверка нужна, чтобы ускорение не нарушило работу существующих приложений.
Что дают бизнесу ускорения на 40% и 21%
Для компаний, чьи агенты ведут многоинструментальные диалоги длиной в десятки и сотни итераций, небольшая экономия на каркасе складывается от шага к шагу. Google приводит запуск из 158 обращений к инструментам, где изменения сократили общее время с 65,6 до 56,1 секунды, убрав почти 10 секунд накладных расходов каркаса. Экономия в 28 мс или 78 мс незаметна на фоне одного вызова LLM длительностью в секунды. В длинных сессиях с многократной подготовкой сессий сокращение издержек копирования на 40% влияет на пропускную способность и стоимость работы.
Тот же эффект распределяется неравномерно в зависимости от размера компании и нагрузки. Небольшая команда с короткими запусками и малым числом инструментов почти не заметит ускорения холодного импорта и обработки сессий, поскольку доминирует задержка модели. Крупная эксплуатация с долгоживущими ассистентами, частым копированием состояния сессий и тяжелыми зависимостями выигрывает больше от улучшения импорта на 21% и ленивой загрузки. Решающими остаются форма нагрузки: длина сессий, число вызовов инструментов и частота перезапусков процессов определяют, стоит ли оптимизировать накладные расходы каркаса.
Четыре другие правки из того же запуска были отклонены после проверки разработчиками из-за сомнений в надежности, поддерживаемости, совместимости или измеримой пользе. Поэтому проверка результата остается за людьми, включая разбор запросов на слияние, отладку и тестирование. Прежде чем переносить такие предложения агента в промышленную эксплуатацию, следует запросить базовые замеры, методику тестов, покрытие тестами и перечень затронутых вызовов и подмен. Показателем станет то, проходят ли будущие изменения полный набор модульных тестов и проверку людьми без доработки, а также сколько правок принимается за один запуск.
