agent-pool pour Google AI et Gemini CLI lancé avec pipelines, cron et bounce-back

Для Google AI и Gemini CLI появился новый open-source слой оркестрации агентов. MCP-сервер agent-pool собирает разрозненные делегации в пайплайны, умеет возвращать задачи на доработку, запускать их по расписанию и выносить выполнение на удалённые машины.

Автоматическая оркестрация

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

Через create_pipeline шаги и зависимости описываются заранее, а сам процесс остаётся жить даже после перезапуска IDE. Ключевая идея — не просто запустить воркера, а дать агентам язык координации. После завершения этапа исполнитель отправляет сигнал о готовности, а если данных не хватает, задача может вернуться назад на доработку с объяснением причины.

Такой bounce-back похож на Request Changes в code review: предыдущий шаг дополняет артефакт и снова отдаёт его в цепочку. Это делает пайплайн не линейным скриптом, а управляемым циклом с ограничением по числу возвратов.

«Воркер может сам делегировать задачи дальше — на этом строится вся фрактальная оркестрация».

В статье описаны основные механизмы такой схемы: on_complete — запускает следующий шаг после завершения конкретного воркера on_complete_all — ждёт всю группу и делает fan-in перед следующим этапом on_file — реагирует на появление файла на диске signal_step_complete — сообщает демону, что шаг действительно завершён * bounce_back — возвращает задачу назад, а maxBounces ограничивает число циклов ## Cron и SSH Отдельно вынесено расписание. Инструмент schedule_task использует обычный cron-формат, поэтому агента можно поставить на ежедневный или почасовой запуск без отдельного планировщика. Важно, что демон ставит атомарные файловые блокировки: даже если открыть несколько окон IDE одновременно, одно и то же задание выполнится только один раз.

Результаты складываются в папку scheduled-results, так что сценарий можно использовать и для рутинных проверок серверов, и для периодической сборки недельных отчётов. Если локальной машины мало, воркеров можно отправить на удалённый сервер по SSH. Раннер описывается в конфиге agent-pool, после чего конкретные задачи начинают исполняться на выделенной машине с установленным Gemini CLI.

Практический смысл понятен: тесты, рефакторинг или массовый анализ кода продолжаются даже после того, как ноутбук закрыт. Автор описывает типичный поток работы так: агенты трудятся в отдельной ветке, делают коммиты, пушат результат, а утром разработчик просто открывает pull request и ревьюит итог.

Контекст и контроль

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

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

Если этого мало, правила задаются точнее через отдельный YAML-файл. Параметр include_dirs дополняет эту модель: по умолчанию воркер видит лишь рабочую директорию, а доступ к внешним конфигам или дополнительным папкам нужно включать явно. Такой подход делает автоматизацию заметно безопаснее, чем безусловный полный доступ ко всему проекту.

Наконец, agent-pool вводит группы — по сути шаблоны фрактальных команд. В группу можно один раз записать раннер, навык, политику и лимит max_agents, а затем отправлять из неё сразу несколько исполнителей без дублирования настроек. Эти группы сохраняются между перезапусками IDE и напрямую подключаются к пайплайнам.

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

Что это значит

Для разработчиков это сигнал, что AgentOps начинает спускаться с уровня экспериментов на уровень повседневных инструментов. Когда пайплайны, планировщик, удалённые раннеры и контроль прав собираются вокруг одной подписки Google AI, мультиагентные сценарии становятся не демонстрацией, а рабочей инфраструктурой для кода, тестов и рутинной автоматизации.