Google Antigravity: как связать rules, skills и workflows для надёжных AI-агентов

Google Antigravity постепенно превращает AI-помощника из автодополнения в настраиваемого инженерного агента: вместо разовых подсказок разработчик задаёт ему правила работы, отдельные навыки и готовые сценарии, а затем запускает повторяемый QA-процесс одной командой. На практике это означает, что проверка кода, рефакторинг и генерация тестов могут быть собраны в локальный пайплайн без внешних оркестраторов и без постоянного ручного надзора на каждом шаге. Ключевая идея строится вокруг трёх сущностей.

Rules задают базовые ограничения для агента: стиль кода, принятые практики и технологические рамки проекта. Skills выступают как переиспользуемые пакеты знаний под конкретную задачу, например ревью, деплой или написание тестов. Workflows связывают всё это в последовательность действий, которую можно вызывать по slash-команде.

В документации Google workflows сравнивают с сохранёнными промптами, а rules — с системными инструкциями. Такой разнос по слоям нужен затем, чтобы агент не тащил в контекст весь набор указаний сразу и подключал специализированные инструкции только по необходимости. Отдельно Google делает ставку на progressive disclosure.

Skill не висит постоянно в контексте модели: сначала агент видит только краткое описание навыка, а полные инструкции подтягивает лишь тогда, когда задача действительно совпадает с его назначением. Это снижает перегрузку лишними инструментами и правилами, уменьшает задержки и помогает не размывать поведение модели. Сам skill при этом может быть не просто текстовой заметкой, а небольшой проектной папкой с файлом SKILL.

md, дополнительными скриптами, справочными материалами и ассетами. Навыки можно хранить глобально для всех проектов или локально внутри конкретного workspace, если они завязаны на стек и процессы одной команды. Практический сценарий, который разбирается для Antigravity, довольно приземлённый: QA-проверка Python-кода.

В рабочем пространстве создаются папки .agents/rules и .agents/skills, после чего для Python добавляется правило с требованиями PEP 8, использованием black для форматирования и ограничением на бесплатные open-source зависимости.

Это правило можно повесить на glob-маску для всех .py-файлов, чтобы оно автоматически применялось к любому Python-коду. Отдельно заводится skill под генерацию тестов: он лежит в собственной директории, содержит обязательный файл SKILL.

md и описывает, как агент должен писать покрытие для уже проверенного кода. Такой подход делает настройку модульной: проектные стандарты живут отдельно от одноразовых команд в чате. Дальше поверх этих блоков собирается workflow с названием вроде qa-check.

В нём агенту последовательно поручают открыть текущий Python-файл, найти баги и нарушения стиля, при необходимости упростить неэффективные места, затем вызвать тестовый skill и в финале вывести готовые unit-тесты с рекомендацией прогнать pytest в терминале. Для демонстрации берётся намеренно небрежная функция деления с плохим форматированием и без обработки деления на ноль. После запуска workflow агент не просто переписывает код в более аккуратном виде, но и предлагает тестовый набор для нормальных, отрицательных и дробных значений, а также отдельный кейс на деление на ноль с ожидаемой ошибкой.

Это важный момент: Antigravity здесь не ограничивается косметическим рефакторингом, а доводит задачу до проверяемого результата, где качество подтверждается тестовой логикой. У такого подхода есть два практических следствия. Во-первых, команды могут собирать внутри IDE повторяемые инженерные ритуалы без отдельного слоя автоматизации поверх редактора.

Во-вторых, AI-агент начинает работать не как универсальный собеседник, а как специализированный исполнитель с понятной зоной ответственности. Для разработки это означает меньше ручного переключения между ревью, правками и тестированием, а для Google — ещё один шаг к тому, чтобы Antigravity конкурировал не только с кодовыми ассистентами, но и с целыми агентными рабочими средами.