Всем привет! У многих из нас куплена максимальная подписка на 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-серверу как к потенциальному источнику опасности — через них могут прилететь промпт-инъекции. Фиксируй версии, обновляй только после аудита. Настраивай режимы одобрения и ограничивай доступ агентов к файловой системе. Не передавай секреты в промптах и ревьюй результаты перед мержем.

З. Ы. Если хочешь посмотреть, как все устроено под капотом — заглядывай на GitHub или ставь из npm.