Недавно я писал про мультиагентный комбайн, работающий на одной подписке Google AI, с делегацией задач в фоновый пул и кросс-модельным консенсусом в качестве ключевой функции. Тогда оркестрацию приходилось делать вручную. Теперь процесс полностью автоматизирован.
Агент-оркестратор и проблема ожидания
Когда шаги зависят друг от друга — например, анализ → рефакторинг → тесты — основной агент вынужден вручную отслеживать цепочку: запрашивать результаты, парсить ответы, запускать следующие шаги. Вместо полезной работы он превращается в диспетчера.
Pipeline: автоматизация цепочек задач
Инструмент create_pipeline позволяет заранее определить последовательность шагов. Фоновый демон автоматически запускает воркеров и передаёт зависимости. Процесс работает автономно и сохраняется после перезагрузки IDE.
Триггеры связывают агентов:
- on_complete — запуск после завершения конкретного шага
- on_complete_all — fan-in, ожидание группы воркеров
- on_file — реакция на появление файла в файловой системе
Signals и Bounce-back: коммуникация между агентами
Внутри пайплайна агенты могут вызывать signal_step_complete, чтобы сообщить демону о завершении шага и запуске следующего.
Если на вход поступает неполная информация, используется bounce_back — инструмент возвращает задачу на предыдущий этап с подробным описанием ошибки. Это аналог «Request Changes» в GitHub. Агент дорабатывает результат и снова сигнализирует о готовности. Чтобы избежать зацикливания, установлен лимит maxBounces.
Cron-планировщик
Инструмент schedule_task позволяет запускать агентов по расписанию, используя стандартный cron-синтаксис (например, 0 9 * * *).
Планировщик работает в фоне и использует атомарные файловые блокировки. Даже при одновременном открытии нескольких окон IDE задача выполнится ровно один раз. Результаты сохраняются в директорию .agents/scheduled-results/. Можно, например, настроить ежечасную проверку серверов или еженедельный сбор отчётов.
SSH-раннеры: запуск агентов на удалённых серверах
По умолчанию воркеры работают локально. Но в файле agent-pool.config.json можно указать SSH-раннер, и задачи будут выполняться на удалённой машине.
Запустил задачу — закрыл ноутбук, процессы продолжают работать. На удалённой стороне может работать фрактальная группа агентов: они анализируют код, принимают решения, создают файлы. Типичный сценарий: агенты работают в отдельной ветке, делают коммиты и пушат результат. Утром вы открываете PR и проводите ревью.
Сессии: передача контекста между агентами
В Gemini CLI есть встроенные сессии, где сохраняется полная история диалога. Пул использует их для передачи контекста: когда один агент завершает исследование и сохраняет результат, следующий может подхватить его сессию.
Активные сессии можно посмотреть командой list_sessions и подключиться к любой из них.
Политики: ограничение прав агентов
Не все воркеры должны иметь полный доступ. Параметр policy ограничивает набор доступных инструментов.
Встроенные шаблоны read-only и safe-edit покрывают базовые сценарии. Для сложных случаев можно создать свой YAML-файл с точным списком разрешённых инструментов.
Параметр include_dirs работает в паре с политиками: по умолчанию агент видит только рабочую директорию. Чтобы открыть доступ к конфигурационным файлам в других местах — нужно явно добавить путь.
Группы: фрактальные команды агентов
Когда одни и те же настройки (раннер, скилл, политика) повторяются — это сигнал вынести их в группу.
Каждый агент в группе автоматически наследует конфигурацию: раннер, скилл, политику. Не нужно дублировать параметры в каждом delegate_task. Параметр max_agents защищает от бесконтрольного роста числа процессов.
Группы сохраняются в .agents/groups.json и переживают перезагрузку IDE.
Группы интегрированы в пайплайны: можно передать group и count прямо в конфигурацию шага.
В этом случае демон запустит указанное число параллельных агентов (каждому передаётся AGENT_INDEX). Демон ждёт успешного завершения всех. При встроенной fail-fast семантике — если хотя бы один агент завершится с ошибкой или вернёт bounce-back, остальные процессы будут немедленно остановлены, что экономит время и ресурсы.
Что дальше
В следующих версиях появится in-memory состояние для пайплайнов и прямой обмен сообщениями между агентами.