Google Antigravity запускает /swarm: AI-программирование переходит от выполнения одним агентом к командной работе нескольких агентов — разбор 4 типов ролей

От автора: в статье я опираюсь на официальный блог Google Antigravity и документацию по использованию. Разбираю, как в /swarm распределяются роли между несколькими агентами, как они взаимодействуют, как устроено визуальное управление и где проходят границы применения.

10 ноября 2026 года вышла в открытый доступ Gemini 4 Carbon. В тот же день команда Google Antigravity представила функцию многоагентной работы /swarm (Preview). Одна эта команда превращает обычный диалог в небольшую инженерную команду из ИИ: кто-то разбивает задачу на части, кто-то пишет код, кто-то проверяет результат, а кто-то следит, не застрял ли процесс.

У функции есть публичное подтверждение. Официальный блог Antigravity и документация по Swarm уже опубликованы, а Google говорит, что его инженеры пользуются ею внутри компании около 5 недель. /swarm — это не просто несколько чатов, открытых одновременно. Это попытка построить систему, которая сама разбивает задачу на части, выполняет их параллельно, делится прогрессом, перепроверяет работу и продолжает исправлять ошибки.

Главная польза: из статьи вы узнаете, как именно /swarm выполняет задачи, как взаимодействуют роли, как пользователю наблюдать за процессом и вмешиваться в него, а также какие ограничения по квотам и правам доступа есть на практике.

Ключевые термины Google Antigravity /swarm

В /swarm появилось несколько ролей. Сначала разберёмся с понятиями, и дальше механика будет понятнее.

Что такое Google Antigravity /swarm: краткая сводка

/swarm вышел одновременно с открытием доступа к Gemini 4 Carbon, но это разные вещи. Первое — функция оркестрации нескольких агентов в Antigravity, второе — модель. В таблице ниже собрано всё, что Google уже обнародовал официально.

Почему одному агенту трудно справиться с крупной инженерной задачей

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

Ещё одна сложность — распределение работы. Один агент действует строго последовательно: пока не закончена правка в модуле A, расследование в модуле B стоит на паузе. А многие инженерные задачи прекрасно распараллеливаются, например исправление упавших тестов в разных пакетах. Делать это по очереди — значит терять время.

Но проще всего упустить из виду проверку. Когда агент, написавший код, сам же его и проверяет, он, как правило, опирается на те же исходные допущения и не замечает ошибок в самом подходе. В человеческих командах для этого есть Code Review: код смотрит другой человек. /swarm переносит такое разделение ролей в процесс AI-программирования.

Как Google Antigravity /swarm запускает команду агентов

Согласно официальной документации, после запуска /swarm <task> всё происходит в таком порядке:

1. Текущий диалог превращается в Coordinator. Агент, с которым вы сейчас общаетесь, становится координатором и отвечает за понимание общей задачи.
2. Работа разбивается на части. Coordinator делит задачу на несколько подзадач, исходя из её структуры.
3. Создаются независимые Worker. На каждую подзадачу приходится свой Worker с отдельным контекстом и общедоступным описанием задачи.
4. Выполнение и проверка. Worker меняют код или проводят исследование. Verifier проверяет изменения в коде, запускает тесты и возвращает замечания соответствующему Worker.
5. Цикл исправлений. Worker вносят правки по замечаниям, после чего их работа снова проходит проверку.
6. Итоговый отчёт. Coordinator собирает результаты всех участников и докладывает пользователю.

У каждого Worker свой контекст, в котором лежит только информация о его части задачи. Из-за этого длинные контексты меньше «загрязняют» друг друга. Описание задачи открыто, поэтому остальные участники видят, кто чем занят, и у разделения труда появляются чёткие границы.

/swarm: распределение ролей в команде — Coordinator, Worker, Verifier и Monitor

Согласно официальной документации, Swarm-команда обычно состоит из четырёх ролей. Важно понимать: это типичная схема, которую описывают авторы, а не жёсткая архитектура, которую применяют к любой задаче. Сколько Worker создать и нужны ли дополнительные участники, решает Coordinator, исходя из задачи.

Как работают Verifier и Monitor в /swarm

В официальном блоге Verifier называют «состязательным агентом для верификации». Его задача — искать проблемы: проверять изменения других агентов, запускать тесты и ставить под сомнение неоправданные правки. Worker получает обратную связь, исправляет код и отправляет его на повторную проверку. Так выполнение и верификация замыкаются в цикл.

Monitor закрывает риск другого рода. Когда работает несколько агентов, легко попасть в ситуацию, где все чего-то ждут и никто не двигается вперёд. Monitor обычно спит, но если замечает, что вся команда остановилась, а задача не выполнена, он будит нужных участников. Благодаря этому, если команда застряла, не обязательно ждать, пока пользователь вмешается вручную.

Разные роли в /swarm могут использовать разные модели

В официальном блоге Google советует подбирать модель под особенности роли, а не гонять всех агентов на самой дорогой модели:

• Gemini 4 Carbon: общее проектирование архитектуры, координация задач, проверка безопасности, аудит сложного кода
• Более быстрые и лёгкие модели: обычная реализация кода, параллельные правки файлов
• Специализированные агенты для верификации: автоматическое тестирование и проверка

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

💡 Совет по выбору: если вы собираете собственный мультиагентный конвейер и хотите подбирать модели под роли, сначала протестируйте разные модели на этапах планирования, реализации и ревью через APIYI (apiyi.com) с одним и тем же API-ключом. Когда определитесь, какая модель лучше подходит для каждой роли, зафиксируйте конфигурацию — при переключении достаточно поменять параметр model.

/swarm: как несколько агентов работают вместе и не мешают друг другу

Общая доска сообщений: открытое общение агентов

Все агенты используют одну общую доску сообщений (Shared Message Board), куда только дописываются новые записи. Там фиксируются и ход совместной работы, и прогресс по задачам. Сообщения не перезаписываются, поэтому всю историю общения команды можно проследить от начала до конца. Пока агент ждёт других участников, он может «уснуть», а когда понадобится его вклад, его разбудят. По заявлению Google, простой в ожидании не расходует токены.

Так получается прозрачнее, чем если бы агенты вызывали друг друга за кулисами. Обратная связь от Verifier к Worker и решения Coordinator о распределении задач лежат на виду. Когда пользователь потом разбирает, что пошло не так, он видит, на каком звене произошёл сбой.

Общее рабочее пространство и отдельные рабочие копии

В этом месте официальный блог и документация описывают всё немного по-разному, и тут легко ошибиться. Блог подчёркивает, что параллельные Worker могут работать в изолированных Git Worktree и не лезть в один и тот же каталог. Документация объясняет правила подробнее:

• По умолчанию: Workers используют общее текущее рабочее пространство.
• Изоляция по необходимости: если нескольким Worker нужно одновременно менять или собирать проект, Coordinator может выдать каждому отдельную рабочую копию кода.
• Удалили Worker — удалили копию: при удалении Worker его рабочая копия тоже удаляется, поэтому результаты нужно сначала слить или закоммитить.

Поэтому точнее будет сказать так: система подбирает изолированные рабочие копии под нужды параллельных задач. Это не значит, что у каждого агента с самого начала есть собственный полностью независимый Git Worktree. Если задача только исследует проект и ничего не правит, хватит общего рабочего пространства. Когда же несколько Worker одновременно меняют код и запускают сборку, отдельные копии помогают избежать конфликтов файлов.

Как наблюдать за командой /swarm в Antigravity и управлять ею

Когда несколько агентов работают параллельно, главная проблема в том, что пользователь не видит, что у них происходит внутри. Для этого в Antigravity есть три основных представления, а в CLI — соответствующие быстрые действия.

Вы можете не только смотреть на результат. Через эти точки входа можно изучить ход работы каждого агента, зайти прямо в нужный Worker и вмешаться, а также скорректировать требования к задаче у Coordinator. Сочетания Alt + J и Ctrl + K показывают, что подтверждение вызовов инструментов остаётся за человеком: если агенту нужно выполнить чувствительную операцию, он остановится и дождётся вашего подтверждения.

Какие сложные инженерные задачи решает /swarm

Google называет три основных сценария внутреннего использования: миграция сразу нескольких пакетов, поиск первопричины проблемы на стыке подсистем и редизайн сложной архитектуры ПО. Их объединяет одно: работы много, её можно разбить на части, а результат нужно проверять.

Примеры из официальной документации ближе к повседневной разработке:

• изменить несколько API-обработчиков (Handler) по отдельности и настроить для каждого свои тесты;
• параллельно разобраться, почему медленно стартует CLI;
• сгруппировать упавшие тесты большого проекта по пакетам и раздать разным агентам на исправление;
• поручить одной модели написание кода, а другой, независимой, его проверку.

Google также показала официальное демо. С помощью многоагентной работы в Antigravity Carbon обработал 7 открытых PDF с городскими планами и выделил из них 206 видов инженерных чертежей. В итоге получилась интерактивная модель здания на Three.js примерно из 906 000 треугольных граней. Всего потребовалось 10 ночных итераций. Это официальный кейс Google, а не независимая проверка третьей стороной. Но он хорошо показывает, как несколько агентов делят между собой долгую задачу.

Стоимость, права доступа и ограничения Preview у /swarm

Расход квоты при работе нескольких агентов

Агенты, которые просто ждут, токены не расходуют. Но это не значит, что /swarm экономит деньги. Каждый Worker — отдельный агент, и когда несколько участников работают одновременно, общая квота тратится заметно быстрее, чем в обычном диалоге с одним агентом. Сам Google на это тоже обращает внимание.

Есть и ещё одна ловушка: если у какого-то Worker закончилась квота, он встаёт на паузу, и даже после восстановления квоты сам не продолжит работу — придётся запускать его вручную. Поэтому перед стартом долгой большой задачи лучше заранее прикинуть, хватит ли квоты.

Права на функцию Swarm ≠ права на модель Carbon

Здесь проще всего запутаться. Если вам доступен /swarm, это ещё не значит, что внутри Swarm можно пользоваться Carbon.

Проще говоря, пользователи Pro могут попробовать механизм совместной работы в Swarm, но то, какие модели смогут использовать агенты, по-прежнему определяется правами модели в их подписке.

Анализ влияния: /swarm переводит AI-программирование от помощника к команде

Влияние на разработчиков

• Смена роли: разработчик из «человека, который задаёт вопросы модели» превращается в «человека, который организует AI-команду». Качество разбиения задач и критерии приёмки напрямую влияют на результат.
• Проверка в начале процесса: механизм Verifier делает тесты и ревью обязательной частью пайплайна, а не доработкой постфактум, после генерации.
• Управление затратами становится важнее: параллельная работа нескольких Worker-ов означает, что нужно следить за лимитами, подбором моделей и гранулярностью задач, а не только за удобством отдельного диалога.

Влияние на индустрию

• Совместная работа нескольких моделей становится направлением развёртывания: сильная модель занимается планированием и ревью, быстрая — массовым выполнением. Такое разделение труда будет перенимать всё больше Agent-фреймворков.
• Фокус конкуренции смещается на доставку результата: соревнование моделей переходит от баллов в одношаговых вопросах и ответах к способности планировать, выполнять, проверять и доводить до конца долгие задачи.

Воспроизводим идею /swarm через API: минимальный пример

Если хочется попробовать в своём проекте подход «координатор разбивает задачу, исполнители её выполняют», можно написать минимальный прототип на OpenAI-совместимом интерфейсе. Код ниже показывает только структуру взаимодействия агентов и не является реализацией Antigravity /swarm. Названия моделей замените на те, что доступны в вашем аккаунте.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

def ask(model, prompt):
    resp = client.chat.completions.create(
        model=model, messages=[{"role": "user", "content": prompt}]
    )
    return resp.choices[0].message.content

plan = ask("STRONG_MODEL", "把“修复 3 个 API Handler 的失败测试”拆成独立子任务，每行一个")
for task in [t for t in plan.splitlines() if t.strip()]:
    print(ask("FAST_MODEL", f"完成这个子任务并给出补丁：{task}"))

import concurrent.futures as cf
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI-совместимый интерфейс APIYI
)

COORDINATOR_MODEL = "STRONG_MODEL"   # Планирование и сводка: подставьте модель с сильными способностями к рассуждению
WORKER_MODEL = "FAST_MODEL"          # Массовое выполнение: подставьте быструю и лёгкую модель
VERIFIER_MODEL = "REVIEW_MODEL"      # Независимая проверка: лучше взять модель, отличную от Worker
board = []                           # Общая доска сообщений, только добавление записей

def ask(model, system, prompt):
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

def worker(task, max_rounds=3):
    patch = ask(WORKER_MODEL, "你是 Worker，只负责分配给你的子任务。", task)
    for i in range(max_rounds):
        review = ask(VERIFIER_MODEL,
                     "你是 Verifier，检查补丁问题。没有问题只回复 PASS。",
                     f"任务：{task}\n补丁：\n{patch}")
        board.append(f"[Verifier] {task[:20]}... 第{i+1}轮：{review[:60]}")
        if review.strip().startswith("PASS"):
            return patch
        patch = ask(WORKER_MODEL, "根据审查意见修复补丁。",
                    f"任务：{task}\n原补丁：{patch}\n意见：{review}")
    return patch + "\n# 未通过验证，需人工检查"

goal = "为 users、orders、payments 三个 API Handler 补充输入校验并修复失败测试"
plan = ask(COORDINATOR_MODEL, "你是 Coordinator，把目标拆成互不重叠的子任务，每行一个。", goal)
tasks = [t.strip() for t in plan.splitlines() if t.strip()]
board.append(f"[Coordinator] 拆分为 {len(tasks)} 个子任务")

with cf.ThreadPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(worker, tasks))

summary = ask(COORDINATOR_MODEL, "汇总各 Worker 结果，列出完成情况与风险。",
              "\n\n".join(results))
print("\n".join(board))
print(summary)

🚀 Быстрый старт: когда будете собирать такой многоролевой прототип, проще всего взять API-ключ и бесплатный пробный лимит для новых пользователей на APIYI apiyi.com. Платформа даёт OpenAI-совместимый интерфейс, так что из одного и того же кода можно вызывать OpenAI, Claude, Gemini и другие модели — удобно проверить, подходит ли вашему проекту связка «сильная модель планирует, быстрая исполняет, сторонняя модель проверяет».

Частые вопросы (FAQ)

Google Antigravity /swarm: ключевые выводы (Key Takeaways)

• Механизм выполнения: команда /swarm <task> превращает текущий диалог в Coordinator, который разбивает задачу и создаёт независимых Worker
• Типичное распределение ролей: Coordinator, Worker, Verifier, Monitor; обычно на каждые 2–4 Worker приходится один Verifier
• Способ взаимодействия: агенты общаются открыто через общую доску сообщений с дозаписью (append-only), а простаивающие в ожидании агенты не тратят токены
• Правила рабочего пространства: по умолчанию используется общее рабочее пространство, а при параллельных изменениях по необходимости выдаются отдельные рабочие копии
• Визуальное управление: три представления — Board, Members, Graph, плюс CLI-команды вроде /swarm board и /agents
• Реальные ограничения: статус Preview, при работе нескольких Worker квота расходуется быстро, а права Swarm не равны правам Carbon
• Собственная практика: через APIYI (apiyi.com) можно объединять несколько моделей единым интерфейсом и собрать свой прототип с несколькими ролями

Итоги

Главное о Google Antigravity /swarm:

1. От параллельности к сотрудничеству: ценность /swarm не только в параллельном выполнении — это полный цикл: разбиение задач, независимый контекст, состязательная проверка и мониторинг прогресса.
2. Изоляция по необходимости: общее рабочее пространство и независимые рабочие копии переключаются в зависимости от задачи, поэтому пользователю важно следить за моментом слияния.
3. Возможности и стоимость идут рядом: несколько агентов лучше справляются со сложными инженерными задачами, но квота расходуется быстрее, а управление ресурсами усложняется. Пока это всё ещё Preview.

Для разработчика /swarm означает смену подхода к работе: вы не просто задаёте вопросы модели, а собираете команду ИИ, которая умеет распределять задачи, выполнять, проверять и сдавать результат. Даже если Antigravity вам пока не нужен, идею «назначать модели по ролям и делать проверку независимой от исполнения» можно применить в собственных агентных системах. Чтобы быстро проверить, как работают сочетания разных моделей, рекомендуем APIYI (apiyi.com): платформа даёт бесплатную тестовую квоту и единый интерфейс ко многим моделям.

📚 Справочные материалы

1. Официальная документация Google Antigravity Swarm: механизм выполнения /swarm, настройка ролей, рабочие копии и операции через CLI
2. Ссылка: antigravity.google/docs/swarm

3. Описание: первоисточник по Coordinator, Verifier и Monitor, а также по представлениям Board / Members / Graph

4. Официальный блог Google Antigravity: Gemini 4 Carbon in Google Antigravity

5. Ссылка: antigravity.google/blog/gemini-4-carbon-in-google-antigravity

6. Описание: анонс /swarm, мультиагентная архитектура, рекомендации по распределению моделей между ролями

7. Официальный анонс Google: Gemini 4 Carbon is now available

8. Ссылка: blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available

9. Описание: кому именно открыт доступ к Carbon и в каком контексте вышло превью /swarm

10. Страница с преимуществами подписок Google AI: доступ к моделям в AI Pro и Ultra

11. Ссылка: one.google.com/about/google-ai-plans

12. Описание: как уровень подписки влияет на доступ к модели Carbon

13. Материал The Verge о релизе: Google releases Gemini 4 Carbon with agent swarm feature

14. Ссылка: theverge.com/ai-artificial-intelligence/1030787/google-gemini-4-carbon-public-rollout
15. Описание: взгляд независимого издания на контекст релиза и ограничения доступа

Автор: техническая команда APIYI
Обратная связь: пишите нам на главной странице APIYI apiyi.com, если хотите обсудить практику работы с мультиагентными системами. Больше материалов по подключению — в центре документации docs.apiyi.com

Читайте также

• Разбор релиза Gemini 4 Carbon: 59 баллов, обошла Opus 5.5 и победила в 15 из 17 тестов, но вызвать модель невозможно: Gemini 4 Carbon возглавила сводный индекс интеллекта Artificial Analysis с 59 баллами и победила в 15 из 17 официальных сравнений, но у неё нет ID модели для API и графика доступа; в статье разбираются оценка, причины недоступности и альтернатива gemini-4-argon для разработчиков в Китае.