Как выжать максимум из подписки Google AI: параллельные агенты и кросс-модельный консенсус

Всем привет! У многих из нас куплена максимальная подписка на Google AI Ultra - правда же? Да, она стоит не копейки - по акции первые 3 месяца обходятся в $124.99/мес, а потом ценник подрастает. Но мы заставим ее отработать каждый цент.

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

Небольшое отступление про лимиты

Раньше я пробовал большинство альтернативных подписок: сидел на максималах в Cursor, потом перекатился на Claude. А потом появился Antigravity IDE - и собственно из-за нее подписался на Google AI Ultra. Причина простая: это единственная IDE, где по одной подписке доступны и топовый Claude Opus, и топовый Gemini с лимитами, которые нереально выбить. В Cursor лимиты заканчиваются быстро даже на максимальной подписке, и ты сидишь ждешь или доплачиваешь.

Если вдруг исчерпался дневной лимит на Claude - переключаешь основного агента на Gemini, и продолжаешь работу. Лучшая модель Anthropic как основной агент-оркестратор, условно безлимитный Gemini как фоновый пул воркеров, и все покрывается одной оплатой.

Плюс бонусом идет гугловская экосистема: Deep Research, NotebookLM, генераторы видео и мощные nano-бананы.

Stitch MCP - гугловский MCP-сервер для генерации UI. В связке с пулом агентов получается эффект полноценной продуктовой команды: один собирает UI через Stitch, пока другие ковыряют бекэнд или пишут бизнес-логику.

Один агент в IDE - это узкое место

Да, современные IDE (тот же Antigravity) умеют запускать субагентов для инструментов параллельно. Но это не кастомизируется и не дает такой гибкости как хотелось бы.

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

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

Наше решение: Agent-Pool-MCP

Мы написали свой MCP-сервер - пул воркеров. Он закидывает задачи фоновым агентам Gemini CLI.

Это PULL-модель. Задачи не блокируют твой основной процесс. Ты просто говоришь IDE-агенту что нужно сделать, а он сам решает: делегировать задачу фоновому воркеру через delegate_task, проконсультироваться с другой моделью через consult_peer, или сделать и то и другое. Получает task_id - и продолжает работать над другими задачами, пока фоновые процессы разбираются.

Например, пайплайн Research → Consult → Refactor:

# 1. IDE-агент кидает задачу на анализ легаси-компонентов (работает в фоне) delegate_task_readonly("Проанализируй директорию src/components/ на наличие React-хуков...") -> task_1 # 2. Пока воркер анализирует, IDE-агент продолжает выполнять другие задачи # 3. Перед рефакторингом — консультируется с другой моделью consult_peer("Предлагаю переписать компоненты с React на Symbiote.js. Вот план...") -> verdict # 4. Получает AGREE или SUGGEST_CHANGES, и только тогда делегирует рефакторинг delegate_task("Перепиши UserProfile.jsx с React на ванильный Symbiote.js...") -> task_2

Чтобы избежать коллизий, мы ввели жесткое правило: НИКТО не трогает файлы друг друга. Для синхронизации между процессами мы используем пайплайн-директорию .agent/delegation/.

.agent/delegation/ ├── findings-react-legacy.md - Сюда пишет воркер-ресерчер ├── architecture-symbiote.md - Пропозал перехода от основного агента └── review-symbiote-patterns.md - Аудит шаблонов от третьего агента

Один агент пишет туда свои находки, другой - их только читает. Пересечений нет. Но это можно настроить под любой сценарий.

Киллер-фича системы - кросс-модельный консенсус через инструмент consult_peer.

Фоновый пул работает на Gemini CLI, а значит воркеры - всегда Gemini. Чтобы получить настоящий кросс-модельный консенсус, а не разговор Gemini с самим собой, основной IDE-агент должен быть другой моделью. Вот почему мы используем Claude через Antigravity: когда он сталкивается со сложной архитектурной задачей, он формирует "пропозал" и отправляет его фоновому Gemini. Две принципиально разные архитектуры валидируют идею ДО внесения изменений в кодовую базу.

Claude предлагает решение, Gemini ищет слепые зоны и возвращает вердикт SUGGEST_CHANGES или AGREE. И все это работает в рамках единой подписки.

Фрактальная оркестрация

Взаимодействие между агентами максимально кастомизируется. Рассмотрим один из вариантов настройки рабочего процесса - мы называем его "фрактальной оркестрацией".

Суть в том, что структура повторяется на каждом уровне - как пирамида. Ты создаешь главного оркестратора, он порождает команды, у каждой из которых может быть свой оркестратор, а тот - свои подкоманды. Глубину вложенности выбираешь сам.

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

IDE-агент (Claude) └─ Оркестратор проекта (Gemini CLI) ├─ Команда бекэнда │ ├─ Оркестратор бекэнда (Gemini CLI) │ ├─ Воркер: API-логика │ └─ Воркер: тесты └─ Команда фронтенда ├─ Оркестратор фронтенда (Gemini CLI) ├─ Воркер: компоненты └─ Воркер: стили

Каждый оркестратор на своем уровне использует навык orchestrator.md, декомпозирует задачу и сам вызывает delegate_task. Воркеры пилят изолированно, результаты собираются снизу вверх. По сути - обычный GitHub-флоу, только вместо разработчиков - агенты, а вместо PR-ов - общая директория синхронизации.

Технический нюанс: чтобы рекурсия сработала, достаточно один раз прописать agent-pool-mcp в конфигурацию Gemini CLI - и фоновые агенты смогут плодить новых агентов на любую глубину.

Управление вниманием агента

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

• Есть другие задачи, но агент ждет. Вместо того чтобы переключиться на параллельную работу, он спамит get_task_result в цикле.

• Нечего делать, но агент не хочет ждать. Ему кажется, что "слишком долго", и он решает сделать работу сам - дублируя то, что уже делает фоновый воркер.

Мы решили это через параметр on_wait_hint в delegate_task. При запуске задачи передаешь инструкцию, которая вшивается в ответ при каждой проверке статуса. В зависимости от ситуации:

• "Воркер еще пишет код. Не жди - займись анализом style-guide.md" - агент переключается на полезную параллельную работу.

• "Воркер еще обрабатывает данные. Дождись результата, не пытайся сделать это сам" - агент терпеливо ждет, не дублируя работу.

Простое инженерное решение: мы перебиваем внутренние промпты IDE своими контр-инструкциями и управляем вниманием модели.

Скиллы и воркфлоу: настраиваешь один раз - работает везде

У пула есть встроенная система кастомизации через обычные .md-файлы. Никаких DSL или конфигов на YAML - просто markdown с инструкциями.

Скиллы (.gemini/skills/*.md) - задают роль и правила конкретному агенту. Написал code-reviewer.md с чеклистом по твоим стандартам - и каждый воркер, которому ты активируешь этот скилл, будет ревьюить код строго по твоим правилам. У нас, например, из простого примера, скилл проверяет, что все новые файлы - ESM, а не CommonJS, и что JSDoc на месте.

Воркфлоу (.agent/workflows/*.md) - пошаговые пайплайны. Описываешь процесс один раз ("сначала исследуй, потом напиши черновик, потом прогони AI-чек"), и любой агент в пуле - хоть IDE, хоть фоновый - может его выполнить.

Скилл подключается к задаче одним параметром - IDE-агент делает это сам, или ты можешь настроить это вручную:

# IDE-агент активирует скилл "code-reviewer" для делегированной задачи delegate_task( prompt: "Проверь src/auth/ на соответствие стандартам проекта", skill: "code-reviewer" )

Суть в том, что ты описываешь экспертизу команды в виде файлов: один скилл - один профиль специалиста. Ревьюер, тестировщик, технический писатель, архитектор - все кастомизируется под конкретный проект. При этом агенты не ограничены написанием кода: они могут выполнять скрипты, проводить ресерч, писать документацию, деплоить - в общем, любую работу, которую можно описать текстом. А воркфлоу связывают этих "специалистов" в цепочку.

Быстрый старт

Если хочешь развернуть такой пул у себя, это делается в пару кликов:

# 1. Ставим глобально официальный Gemini CLI и логинимся в свой аккаунт (нужна подписка) npm install -g @google/gemini-cli gemini --login # 2. Проверяем, что всё готово (диагностика Node.js, CLI и доступов): npx agent-pool-mcp --check

И прописываем пулер в конфиг IDE:

{ "mcpServers": { "agent-pool": { "command": "npx", "args": ["-y", "agent-pool-mcp"] } } }

Безопасность

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