Всем привет! Недавно я писал про мультиагентный комбайн, который работает на одной подписке Google AI - с делегацией задач в фоновый пул и кросс-модельным консенсусом в качестве киллер-фичи. Тогда всю оркестрацию приходилось делать вручную. Сейчас расскажу, как мы это автоматизировали.

Важный момент: agent-pool - это MCP-сервер, который работает и в IDE, и внутри самого Gemini CLI. Воркер может сам делегировать задачи дальше - создавать подгруппы и запускать своих воркеров. На этом строится вся фрактальная оркестрация.

Проблема: агент-оркестратор тратит себя на ожидание

Когда шаги зависят друг от друга (анализ → рефакторинг → тесты), основной агент вынужден вручную следить за цепочкой: дергать get_task_result, парсить ответ, запускать следующего. Вместо полезной работы он сидит диспетчером.

Pipeline: автоматические цепочки

Инструмент create_pipeline собирает шаги заранее. Фоновый демон сам стартует воркеров и прокидывает зависимости. Процесс демона полностью отвязан (detached) и выживает при перезагрузке IDE.

Триггеры связывают агентов:

  • on_complete - старт после конкретного шага

  • on_complete_all - fan-in, ждем группу воркеров

  • on_file - реагируем на появление файла на диске

          ┌─ frontend ─┐
research ─┤            ├── deploy
          └─ backend  ─┘

Signals и Bounce-back: агенты общаются

Просто запустить процесс недостаточно. Внутри пайплайна агенты получают вызов signal_step_complete. Команда сообщает демону, что шаг готов и можно дергать следующий.

Иногда на вход прилетает неполная информация. Инструмент bounce_back возвращает задачу на предыдущий этап с подробной причиной ошибки. Это прямой аналог "Request Changes" в GitHub. Воркер получает фидбек "не хватает логов", дорабатывает файл и снова сигнализирует о готовности. От бесконечных циклов защищает лимит maxBounces.

Cron scheduler

Иногда нужно просто запускать агента по расписанию. Инструмент schedule_task вешает задачу на стандартный cron (0 9 * * *).

Планировщик висит в фоне. Он ставит атомарные файловые блокировки на выполнение. Открой десять окон IDE одновременно - скрипт все равно выполнится ровно один раз. Результаты аккуратно складываются в .agents/scheduled-results/. Можно повесить чек серверов каждый час или сбор недельного отчета.

SSH runners: агенты на удаленном сервере

По умолчанию воркеры крутятся локально. Но можно прописать SSH-раннер в agent-pool.config.json - и задачи полетят на удаленный сервер:

{
  "runners": {
    "remote": {
      "type": "ssh",
      "host": "dev-server.company.com",
      "user": "agent",
      "geminiPath": "/home/agent/.nvm/versions/node/v22.0.0/bin/gemini"
    }
  }
}

delegate_task(
  prompt: "Прогони тесты в изолированном окружении",
  runner: "remote"
)

Запустил задачу, закрыл ноутбук - процессы продолжаются. На удаленке крутится фрактальная группа агентов, которые читают код, принимают решения и пишут файлы. Стандартный сценарий: агенты работают в отдельной ветке, делают коммиты, пушат результат. Утром открываешь PR и ревьюишь.

Сессии: передача контекста

У Gemini CLI есть встроенные сессии. Каждая сессия хранит полную историю разговора. Пул это использует: когда один агент заканчивает ресерч и записывает результат, следующий агент может подхватить его сессию:

# Первый агент исследует кодовую базу
delegate_task(prompt: "Проанализируй src/auth/") -> task_1

# Достаем session_id из результата
get_task_result(task_1) -> { session_id: "abc-123" }

# Второй агент продолжает с того же места
delegate_task(
  prompt: "Используя результаты анализа, напиши тесты",
  session_id: "abc-123"
)

При этом можно посмотреть все активные сессии через list_sessions и подключиться к любой из них.

Политики: ограничение прав

Не каждому воркеру нужен полный доступ. Параметр policy ограничивает набор инструментов:

# Ревьюер только читает - не может менять файлы
delegate_task_readonly(
  prompt: "Проверь src/auth/ на уязвимости",
  policy: "read-only"
)

# Редактор может править файлы, но не запускать команды
delegate_task(
  prompt: "Исправь типы в src/models/",
  policy: "safe-edit"
)

Встроенные шаблоны read-only и safe-edit покрывают базовые сценарии. Для сложных случаев - пиши свой YAML-файл с точным списком разрешенных инструментов.

Параметр include_dirs работает в паре: по умолчанию агент видит только рабочую директорию. Нужен доступ к конфигам в другом месте - добавляешь путь явно.

Группы: фрактальные команды

Когда одни и те же настройки (раннер, скилл, политика) повторяются в каждом вызове - это сигнал вынести их в группу:

create_group({
  name: "backend",
  runner: "remote",
  skill: "node-dev",
  policy: "safe-edit",
  max_agents: 3
})

# Отправляем двух агентов из группы
delegate_to_group("backend", "Отрефактори auth-модуль", count: 2)

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

Группы сохраняются в .agents/groups.json и переживают перезагрузку IDE.

Группы также нативно интегрированы в Пайплайны. Можно передать group и count прямо в конфигурацию шага:

create_pipeline({
  name: "Build & Test",
  steps: [{
    name: "run_tests",
    group: "backend",
    count: 3,
    prompt: "Запусти набор тестов для своей части"
  }]
})

В этом случае демон пайплайнов автоматически запустит трех параллельных агентов (каждому пробросится AGENT_INDEX). Демон дождется успешного завершения всех воркеров, а благодаря встроенной fail-fast семантике - если хотя бы один из них упадет с ошибкой (или вернет bounce-back), остальные процессы будут немедленно принудительно отменены, экономя время и ресурсы.

Что дальше + установка

В следующих версиях добавим in-memory состояние для пайплайнов и прямой обмен сообщениями между агентами.

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

npx agent-pool-mcp --check

Код, документация и примеры скиллов - на GitHub и в npm.