Google Antigravity: как перенести локальные задачи до 5 октября

Что именно меняется в Google Antigravity

Речь идёт об управляемом агенте Antigravity в Gemini API. Это не обновление Antigravity IDE, которую устанавливают на компьютер.

Оба продукта используют общие компоненты среды выполнения — отсюда и одинаковое название. Но в данном случае меняется идентификатор агента, который приложение передаёт в Interactions API Google, а в некоторых интеграциях — ещё и обработка вызовов встроенных инструментов. Обновление IDE само по себе контракт API не изменит.

Новый агент называется antigravity-preview-09-2026. По умолчанию он использует модель рассуждений Gemini 3.8 Flash, хотя в руководстве по Antigravity Agent показано, как выбрать другую поддерживаемую модель через agent_config. В предыдущем разборе Gemini Managed Agents описаны размещённая у Google рабочая среда, фоновые задачи и цикл вызова инструментов. Нынешняя миграция лежит уровнем ниже: от неё зависит, смогут ли задачи вообще запускаться, а вызовы инструментов — выполняться.

В примечании к выпуску от 17 сентября Google разделила миграцию на два сценария:

• Для задачи в удалённой песочнице, которая читает только output_text или model_output, достаточно заменить строку с идентификатором агента.
• Задаче, которая использует local_environment или разбирает шаги function_call, потребуется также обновить адаптер инструментов.

Именно это различие определяет объём работ. Адаптер — небольшой фрагмент прикладного кода: он принимает название инструмента и аргументы, проверяет их, запускает локальное действие и возвращает результат.

Контракт локальных инструментов изменился в пяти местах

Старый агент в основном сводил работу с файлами к общим операциям чтения и записи. В сентябрьской версии файловые операции получили более узкие названия и аргументы. Кроме того, ключи аргументов перешли со snake_case на PascalCase.

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

Новый контракт редактирования стал точнее. Вместо отправки целого файла ради небольшой правки агент указывает диапазон строк, ожидаемый текст и замену. Если TargetContent уже не совпадает с содержимым файла, адаптер должен отклонить вызов. Иначе задача, выполнившаяся с задержкой, способна затереть более свежую правку человека.

Каким задачам нужна полноценная миграция Antigravity

Независимый разработчик с удалённой задачей для отчётов

Допустим, ночная задача поручает Antigravity собрать данные в песочнице Google, сохранить отчёт и вернуть итоговый текст. Приложение читает output_text и не анализирует внутренние шаги.

Это простой сценарий миграции. Замените antigravity-preview-05-2026 на antigravity-preview-09-2026, параллельно запустите один типичный отчёт на старом и новом агентах, сравните итоговый артефакт и лишь затем переведите расписание. Перестраивать несуществующий диспетчер локальных инструментов незачем.

Платформенная команда запускает инструменты на своих машинах

Теперь представим воркер репозитория, чьи вызовы инструментов выполняются в собственном раннере компании. Он читает файлы, ищет по коду, меняет конфигурацию и возвращает результаты инструментов в текущее взаимодействие.

Здесь объём миграции больше. Диспетчер должен распознавать новые имена, проверять аргументы в PascalCase, соблюдать политики для путей и команд, безопасно применять правки по диапазонам строк и возвращать результат в ожидаемом формате. Результат этих усилий — непрерывная работа: ревью кода, генерация отчётов и задачи обслуживания продолжат выполняться после отключения майской конечной точки.

Команда наблюдаемости обрабатывает каждый шаг

Некоторые приложения выполняют все действия удалённо, но всё равно копируют шаги function_call в журнал аудита, интерфейс прогресса, очередь согласования или панель расходов. Такие приложения нельзя считать потребителями только конечного результата.

Даже если встроенную файловую операцию выполняет Google, парсер может по-прежнему ожидать write_file, path и content. Обновите список разрешённых вызовов и фикстуры: иначе панель может принять реальное редактирование за неизвестную операцию, потерять его аргументы или отправить вызов не по той политике согласования.

Владелец эксплуатации с автоматическими триггерами

Запуски по расписанию несут наибольший риск: в момент вызова за ними никто не наблюдает. Триггер связывает агента, окружение, промпт и cron-расписание. Если в сохранённой конфигурации взаимодействия всё ещё указан майский агент, расписание может выглядеть исправным, хотя стоящее за ним выполнение начнёт завершаться с ошибкой после отключения.

Проверьте идентификатор агента во всех определениях триггеров, а не только в вызове SDK основного приложения. Затем проведите теневой запуск одной задачи для каждого отдельного паттерна инструментов. Отчёт и исправление репозитория требуют разных тестов миграции, даже если обе задачи используют Antigravity.

Минимальный контрактный тест редактирования файла

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

Этот пример был запущен в Node с опубликованным Google названием replace_file_content и полями PascalCase. Это локальный тест адаптера, а не реальный вызов Gemini API.

import assert from "node:assert/strict";
import { mkdtempSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

function applyReplaceFileContent(call) {
  assert.equal(call.name, "replace_file_content");

  const {
    TargetFile,
    StartLine,
    EndLine,
    TargetContent,
    ReplacementContent,
  } = call.arguments;

  const lines = readFileSync(TargetFile, "utf8").split("\n");
  const current = lines.slice(StartLine - 1, EndLine).join("\n");
  assert.equal(current, TargetContent, "line window no longer matches");

  lines.splice(
    StartLine - 1,
    EndLine - StartLine + 1,
    ...ReplacementContent.split("\n"),
  );
  writeFileSync(TargetFile, lines.join("\n"));
}

const dir = mkdtempSync(join(tmpdir(), "antigravity-adapter-"));
const file = join(dir, "scheduled-job.env");
writeFileSync(file, "owner=ops\nstatus=old\nmode=scheduled\n");

applyReplaceFileContent({
  name: "replace_file_content",
  arguments: {
    TargetFile: file,
    StartLine: 2,
    EndLine: 2,
    TargetContent: "status=old",
    ReplacementContent: "status=ready",
  },
});

assert.equal(
  readFileSync(file, "utf8"),
  "owner=ops\nstatus=ready\nmode=scheduled\n",
);
console.log("PASS: line 2 changed from status=old to status=ready");

Тест пройден. Что важнее, после изменения TargetContent в фикстуре он останавливается, а не вносит правку в устаревшее содержимое.

Экономика миграции: трудозатраты против пропущенной работы

Google не объявляла о новой цене за токен в связи с этой миграцией агента. Изменилась другая строка бюджета — время разработчиков и эксплуатационной команды.

Используйте две простые формулы:

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

Не превращайте это в выдуманную универсальную оценку в часах. У простого генератора отчётов и локального агента для программирования разный набор инструментов, логика согласований и цена сбоя. Подставьте в формулы полную стоимость часа специалиста и ценность одного запуска для бизнеса. Так у финансовой команды будет реальное основание для решения, а не перечень функций поставщика.

Что важно сказать прямо

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

Кроме того, эта миграция требует разного объёма работы от разных пользователей Antigravity:

• Действуйте на этой неделе, если производственная задача указывает antigravity-preview-05-2026, использует local_environment, разбирает шаги function_call или автоматически запускается по расписанию.
• Выбирайте простой сценарий, если задача работает в удалённой песочнице и использует только output_text или model_output. Замените ID и проведите теневой запуск.
• Сразу начинайте с нового ID, если вы пока только оцениваете API и у вас нет майских агентов в продакшене.
• Эта миграция вас не касается, если вы пользуетесь только Antigravity IDE и не вызываете управляемого агента через Gemini API.

Что сделать в понедельник

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

Затем перенесите по одной типичной задаче из каждой группы. Приостановите старое расписание, но не удаляйте его, пока проверяете сентябрьский запуск; после этого переносите остальные задачи по семействам рабочих процессов и настройте оповещение о неизвестных вызовах инструментов до 5 октября. Результат понедельника — не презентация, а инвентаризация с ответственными, успешный теневой запуск и дата переноса каждой оставшейся задачи.

Больше практических разборов изменений, способных нарушить реальные рабочие процессы, — в рассылке.