Gemini 4 Argon сам прискорив код Google на 40%

Раунд без правил: де агент оступився

Спочатку Google дала Argon мінімальний запит без жодних інструкцій про те, як команда ADK ревʼює код: Make ADK add no noticeable overhead to any agent: at startup, in long sessions, in multi-agent and workflow setups. Keep what the model receives and the public API unchanged, and back each change with a test that would catch a regression.

Раунд тривав близько двох годин: за 7 хвилин агент написав власний скрипт для бенчмарків, ще 70 хвилин вимірював і читав код, перш ніж торкнутися хоч одного рядка ADK. Він знайшов ті самі вузькі місця — копіювання сесій і завантаження пакетів, і частина цього коду згодом увійшла у фінальний коміт.

Але без знання конвенцій ревʼю агент наробив помилок: прикріпив хук до моделі автентифікації, який непомітно змінив публічну JSON-схему, пропустив крайні випадки з тестовими моками у власному копіювальнику, прогнав лише 216 суміжних тестів із майже 17 тисяч і не додав цифри бенчмарків до опису PR.

Що змінили для другого раунду

Команда поклала правила мейнтейнерів у каталог .agents/skills — за принципом онбордингу для нового інженера. Кожен навик починається з короткого індексу SKILL.md, що веде до профільних файлів за потреби, щоб не перевантажувати контекст моделі на кожному кроці. Перед правками агент прочитав visibility.md про правило приватних модулів з префіксом «_» та imports.md про перевірки лінивого завантаження.

Також увімкнули /goal-режим у Google Antigravity: він утримує мету навіть після стискання контексту, тож агент не «забуває» задачу під час довгого прогону. До запиту додали прохання відкрити (але не мерджити) один pull request з цифрами «до і після» в описі — саме той пункт, якого не було в першому раунді.

Що сталося за 11 годин

Прогін почався о 21:11 і тривав усю ніч. Перед тим як торкнутися коду, Argon прочитав 12 файлів правил і прогнав базовий бенчмарк на чотирьох навантаженнях — старт пакета, розмова на 200 кроків, тестова програма з 20 підагентами та воркфлоу з 12 вузлів, кожен по 30 разів. За три хвилини до завершення агент ще аудитував власний diff, знайшов баг у власному кеші для мультиагентних сценаріїв і перепрогнав усі 16 892 тести, перш ніж зупинитися самостійно.

Усього PR запропонував шість оптимізацій на 32 файлах. У фінальний коміт, який прийняла команда ADK, увійшли найкращі частини обох раундів — 22 файли та 17 нових тестових функцій, із позначкою «Argon generated these changes».

Де виграш не відчутний

Прискорення стосується лише InMemorySessionService — служби сесій у памʼяті, яка працює в InMemoryRunner, локальних циклах оцінювання, CI-тестах і деплоях на Cloud Run чи GKE за замовчуванням, якщо не вказано URI зовнішньої бази. Сховища на SQLite, Firestore, Redis чи платформі Gemini десеріалізують дані зі збереженого стану, а не копіюють у памʼяті, — для них час читання не змінився.

На одному виклику моделі, що триває секунди, людина не відчує різниці в 28 чи 78 мс. Ефект накопичується лише на довгих ланцюжках: на незалежному тесті bench_turn.py, який Argon ніколи не бачив, прогін на 158 внутрішніх кроків викликів інструментів скоротився з 65,6 до 56,1 секунди — майже 10 секунд чистих накладних витрат фреймворку.

Перш ніж довіряти результату агента на своєму репозиторії, варто перевірити:

• чи змінює правка публічний API або схему даних — у першому раунді це сталося непомітно
• чи прогнано повний набір тестів, а не лише суміжні — 216 замість 16 892 нічого не гарантують
• чи є в описі PR цифри «до і після» для кожної заявленої оптимізації
• чи враховані крайні випадки в кастомному коді, зокрема тестові заглушки й моки