Агенты параллельной кодировки с рабочими деревьями Git, Conductor и Antigravity 2.0

От работы с терминалами до визуальных инструментов управления

Если 2025 год стал годом ИИ-агентов, то 2026, по-видимому, станет годом совместной работы множества таких агентов. Один из инженеров Google ещё рано предсказал, что это будет год оркестрации агентов. Для тех, кто постоянно работает в терминалах, проблемы возникают быстро: попытка координировать работу группы параллельных подагентов, создающих небольшую игру-часы, с использованием окон tmux, загрузки репозиториев и листовок на мониторе для отслеживания действий каждого агента, превращается в настоящий когнитивный хаос.

На фотографии показаны несколько рабочих столов macOS, заполненных терминалами agy с листовками — это наглядный пример того, как выглядит управление параллельными рабочими пространствами агентов без соответствующих инструментов.

Идея создания приложений с использованием механизма многокомпонентного управления возникла из поста от июня 2026 года, в котором показывалось, как один запрос запускает четыре параллельных агента-разработчика, позволяя создать рабочее приложение менее чем за две минуты. Инструменты командной строки с жесткими правилами отлично подходят для однопоточных задач, но несколько одновременных потоков агентов, каждый из которых имеет собственную ветку, механизмы проверки изменений и циклы обратной связи координатора, не помещаются в обычный буфер отката. Именно поэтому следующим шагом стало переход на десктопное приложение Antigravity 2.0.

Приложение группирует всё по проектам, фактически создавая папки, и отображает треды внутри каждой из них в порядке от новых к старым. Личный проект может содержать тред для добавления синей кнопки входа с скрытым паролем и другой тред для добавления бэкенд-маршрута /checkout/, в то время как рабочий проект включает треды для написания файла doc/PRD.md и добавления тестов на безопасность. Треды можно архивировать, чтобы они сохранялись после перезагрузки, и тогда больше не нужны физические стикеры.

Как только визуальная среда начинает работать, следующим вопросом становится масштабируемость. Одиночная песочница и простая игра — это просто. Данная конфигурация позволяет расширить десктопное приложение до симуляции SRE с 12 треками с использованием Git worktrees, оркестратора в стиле Rails под названием Conductor++ и агента-консьержа под названием Agostina.

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

То, что стало толчком

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

Let's build a hotel room booking app [..].

First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.

Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS>  to interact with the API <details>.

[..] How to sync the 3 sub-agents [..]

Finally, spin up both components and a browser so I can test the live app.

При внимательном прочтении становится ясно, что в нём содержится:

1. описание желаемого продукта — в данном случае приложения для бронирования отелей
2. команда из трёх подагентов
3. порядок и временные рамки их взаимодействия
4. то, что происходит в конце, когда система запускается для человека, который не полностью вовлечён в процесс для проверки
5. самый важный элемент — общее состояние файла: общий документ architecture.md

Диаграмма показывает, как агенты взаимодействуют в этом примере. Это метапрограммирование в чистом виде. Задание не описывает код, а описывает команду, которая будет его писать. Агенты общаются друг с другом через документ в формате Markdown, что означает, что сами спецификации являются каналом связи.

Список пожеланий относительно параллельной настройки был ещё более амбициозным: реализация должна запускаться посредством GitHub Issues (GHI), чтобы каждый сабагент получал реальный тикет.

Компоненты рабочего процесса

Настройка состоит из нескольких элементов.

• Интеграция с тикетами. Каждый сабагент должен работать над тикетом, если таковой существует.
• Rails для ИИ. Расширение Conductor предоставляет агентам чёткие рамки действий, то есть определённые границы. Один лишь тикет не всегда содержит достаточно информации для действий агента, и иногда человек, участвующий в процессе (HITL), должен отвечать на сложные вопросы, что предотвращает небрежность в реализации, например фразы вроде «Конечно, я имел в виду только авторизованных пользователей».

git worktree. Worktrees предотвращают ситуацию, когда два или более агента портят один и тот же репозиторий. Когда N агентов отправляют запросы на слияние в удаленные ветки, целесообразно также иметь специальный агент git, который обрабатывает код и вносит его в основную ветку. Этот агент должен действовать осторожно. Пока агент X пытается выпустить функцию X, этот специальный агент остается невозмутимым и служит последней линией защиты целостности кода, поскольку код может быть безупречным, но быть выпущенным без выполнения тестов или обновления чанглога, а новое окно контекста помогает это заметить.

Чтобы использовать всю эту структуру в разных проектах, правила и автоматизация были объединены в open-source навык агента conductor-worktree-hitl, прозванный condutree. Его основные компоненты:

• git worktree для асинхронной реализации, при этом на каждый worktree выделяется по одному подагенту, а также существует один трек Conductor

GitHub Issues в сочетании с Conductor для четкого определения границ реализации

Antigravity 2.0 в качестве визуального интерфейса управления

состояние сохраняется на диске, поэтому контекст агента сохраняется между запусками; совместимо с Conductor, но добавляет файловое хранение состояния для связи задач и экспериментальную систему вопросов и ответов для сабагентов

по желанию — плагин, предоставляющий функцию using-git-worktrees для автоматизации изоляции рабочих деревьев

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

Агент, обладающий этим навыком, учится четырем вещам:

1. как создавать независимые рабочие деревья для одновременного выполнения задач
2. правилам корректной работы с git, а именно созданию символических ссылок на общие папки метаданных Conductor и их исключению локально, чтобы команда git status отображала чистую структуру

двухуровневый реентрантный протокол HITL для публикации комментариев к задачам, чтения локальных реестров и запроса ответов без исчерпания квоты API

как выполнять коммиты локально и записывать подтверждения в виде примечаний Git без прямой отправки данных на удаленный сервер

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

Эта иллюстрация, созданная с помощью ИИ, иллюстрирует ситуацию «слишком много поваров на кухне»: толпа подагентов, занимающихся программированием, создает беспорядок в одной ветке из-за отсутствия изоляции рабочих деревьев.

Тест на нагрузку: симулятор инцидентов SRE

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

• Загрязнение символическими ссылками. В конфигурации Conductor++ каждый параллельный агент имеет собственную рабочую директорию, например .worktrees/telegram_incident_creation/. Поскольку подагенты передают метаданные координатору, корневая директория conductor/ символически связывается с каждой рабочей директорией с помощью команды ln -s ../../conductor conductor. Все файлы, кроме тех, что находятся в этой папке, отличаются в каждой рабочей директории, и поскольку каждый поток находится в своей собственной поддиректории conductor, проблемы с слиянием файлов встречаются крайне редко.
• Координатор. Главный «гит-консьерж» — это Агостина, спокойная и организованная итальянка, работающая на эспрессо; она поддерживает синхронизацию таких подагентов, как Марио и Луиджи, не позволяя им мешать друг другу. Она намеренно итальянка, и её имя немного напоминает «Антигравитацию».
• Секретарь. Преданный агент по имени Амануэнсе, названный в честь латинского слова, обозначающего писца, записывает информацию о создании каталогов, изменениях в коде и взаимодействии агентов с точными временными метками в единый центральный файл аудита, чтобы было видно, кто что сделал, когда и в каком рабочем дереве. Этот файл был создан для проверки эффективности синхронизации подагентов и для предоставления точных временных меток и журналов событий для отчетов.

Запуск нескольких ИИ-агентов в одном репозитории требует строгой изоляции, а также способа общения без конфликтов.

Здесь Агостина сливает изменения от Марио и Луиджи, в то время как третий, желтый подагент продолжает работать над своей собственной веткой.

Правила, сохраняющие порядок в репозитории

Несколько дизайнерских решений сыграли ключевую роль.

• Запрещены прямые отправки данных на удаленный сервер. Если множество подагентов одновременно выполняют команду git push, это приводит к конфликтам при работе с удаленными референсами и может привести к попаданию непроверенного кода в продакшн. Подагенты коммитят изменения только в локальные ветки feature/ и пишут краткие примечания в Git. Только координатор имеет право отправлять данные, брать ветку для проверки и сливать функциональные ветки.
• Двойной протокол задач с возможностью повторного входа. Один глобальный файл questions.json мог бы привести к конкурентным ситуациям при одновременном задавании вопросов подагентами. Вместо этого каждый подагент записывает свой вопрос в свою локальную папку conductor/tracks//metadata.json, что полностью исключает такие конфликты. Кроме того, вопрос публикуется в виде комментария к задаче на GitHub с уникальной подписью для отслеживания. Скрипт опроса Агостины сначала проверяет, есть ли в локальных папках статус awaiting_human. Если таких нет, запрос к API GitHub полностью пропускается, что позволяет сэкономить более 95 процентов квоты. Как только на GitHub появляется соответствующий ответ, локальный статус метаданных меняется на answered, что пробуждает подагента.
• Общая память в стиле вики. Вместо того чтобы заполнять контекст каждого подагента всей историей проекта, общая директория conductor/ служит постоянной памятью — структурированной локальной директорией, в которую агенты читают и записывают данные, как на странице вики. Это отражает известное мнение Андрея Карпати о памяти больших языковых моделей, а также отвечает на распространённую обеспокоенность тем, что плохо управляемая память агентов превращает помощников в золотых рыбок.
• Каскадное решение конфликтов. При постепенном слиянии завершенных фичных веток может возникнуть каскад конфликтов. Ветка Марио сливается без проблем с веткой валидации, но у Луиджи возникают конфликты. Если человек устраняет конфликты Луиджи на ветке валидации, его исходная фичная ветка в рабочей структуре остается с конфликтами и устаревшей. Чтобы избежать такого смещения, Агостина выбирает необходимые изменения вручную или сливает решение обратно в ветку Луиджи, сохраняя согласованность изолированной рабочей структуры с проверенным кодом.
• Используются запросы на пул-репозиторий вместо прямой записи в основной репозиторий. Прямая запись объединенной ветки проверки в main позволила бы обойти процедуру ревью, поэтому интеграция осуществляется через PR. Подагенты делают коммиты локально, Агостина их забирает, проверяет и объединяет локально, а после прохождения тестов на интеграцию она записывает объединенную ветку и выполняет команду gh pr create --title "feat: ..." --body "...". Человек-рецензент может затем просмотреть различия и результаты проверок CI в собственном интерфейсе GitHub. Агостина записывает URL PR в файл metadata.json реестра и отображает текущий статус с помощью команд gh pr list и gh pr status.
• Прекращение работы из-за концептуальных конфликтов. Два подагента могут быть логически несовместимы, например, когда один реализует ту же функцию, что и другой, но делает это несовместимым способом. Если Агостина обнаруживает это, она может немедленно прекратить работу одного из конфликтующих подагентов. Об этом прекращении необходимо записать в задачу соответствующего агента, а сама задача должна быть связана с задачей другого агента для сохранения четкой истории принятия решений. Это произошло ровно один раз.

Жизненный цикл оркестрации

Человек-оператор никогда не общается напрямую с подагентами. Они работают в полной изоляции внутри своих рабочих деревьев, а оператор общается только с координатором в двух моментах: при запуске процесса и при ответе на вопросы, переданные наблюдателем HITL.

Диаграмма потока показывает жизненный цикл агента и подагента в шести этапах:

1. Запуск. Оператор начинает процесс.
2. Проверка статуса. Агостина аудитирует активные задачи в GitHub и состояния треков в Conductor.
3. Подготовка. Она создаёт изолированные рабочие деревья и запускает параллельных подагентов-разработчиков.
4. Наблюдатель HITL. Вопросы, блокируемые подагентами, направляются человеку, а ответы возвращаются обратно, что обеспечивает безопасность и асинхронность цикла обратной связи.
5. Очистка. Когда подагенты заканчивают работу и открывают свои PR, Агостина удаляет временные каталоги рабочих деревьев.
6. Слияние с основной веткой. Она интегрирует изменения и открывает или сливает окончательный PR, затем возвращаясь к этапу очистки для выполнения оставшихся задач. Этот процесс может превратиться в настоящую битву, но агенты справляются с слиянием в Git лучше, чем люди.

Ответы на вопросы пока находятся на этапе экспериментов, и было протестировано три подхода. Один из них предусматривает использование Telegram Sidecar Bridge в качестве фонового демона, который отправляет вопросы или подтверждения изменений в базе данных на телефон разработчика через бота Telegram и проверяет наличие ответов.

На диаграмме показан асинхронный поток работы с Telegram. Его преимущества — возможность отвечать и утверждать запросы с учетом особенностей мобильных устройств, параллельная обработка без конфликтов, поскольку вопросы хранятся в отдельных каталогах для каждого трека, что исключает конкуренцию за блокировку файлов, а также наличие журнала аудита, поскольку каждое решение сохраняется в репозитории в формате JSON. Самый простой вариант, предполагающий взаимодействие с основным агентом через файл questions.json, был отклонен, так как он никогда не снимал блокировку автоматически и требовал ручного запуска, хотя хуки или будущие обновления могли бы это исправить.

Пример применения: двенадцать треков SRE за пять часов

Тестовая среда представляла собой веб-приложение, построенное на основе расширения SRE. Большинство его функций могли выполняться параллельно: интерфейсы пользователя, серверные конечные точки, чат-ассистент, работающий с помощью большой языковой модели, бот в Telegram, инструменты OpenTelemetry для мониторинга и обнаружение ресурсов GCP.

Для реализации проекта было задействовано двенадцать сложных функций SRE, которые были разделены на более двадцати конкретных задач в GitHub. Затем система была запущена автономно. Примерно за пять часов, в основном без прямого контроля, конвейер Conductor++ создал, протестировал и объединил все эти элементы в основную ветку. Область работы включала настройку отслеживания с помощью OpenTelemetry в Cloud Run, создание интерактивных вспомогательных инструментов в Telegram для решения проблем, а также реестров для утверждения ожидающихся изменений.

Результаты интеграции и объединения

Благодаря оркестрации параллельных задач каждая функция разрабатывалась, тестировалась и интегрировалась в ветку main.

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

Через две недели после выполнения можно проверить статус Conductor с помощью одной команды task-runner, которая запускает инспектор для анализа репозитория и выводит краткое описание рабочего пространства.

$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short

🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS      |  PROGRESS  | RATIO |  GHI  |   AGENT    |   CHANGED   | TRACK ID                                           |  🌳
==============================================================================================================================
NEW         | ░░░░░░░░░░ |  0/25 |  #23  |            |  💻 15days   | managed_agents_sandbox_20260616                    |
NOT_READY   | ░░░░░░░░░░ |  0/17 |  #22  |            |  💻 15days   | mcp_streamline_abilities_20260616                  |
NOT_READY   | ░░░░░░░░░░ |  0/11 |  #15  |            |  💻 15days   | migrate_tf_cb_logic_20260616                       |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #21  |            |  💻 15days   | ai_engineering_practices_20260616                  |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #19  |            |  💻 15days   | workspace_agent_installation_20260616              |
NEW         | ░░░░░░░░░░ |  0/15 |  #31  | antigravity|  🐙 16days   | disable_mock_fallback_dev_20260616                 |
==============================================================================================================================
TOTAL       |            |  0/86 |       |            |              | 0 completed, 6 open (6 total)                      | 0 🌳

График работы

Пошаговый обзор процесса показывает, как координатор, секретарь и параллельные подагенты избегали взаимных конфликтов.

Шаг 1: инициализация треков и рабочих деревьев

На хост-машине главный координатор подготовил рабочие пространства. Затем интерфейс командной строки инспектора Conductor перечислил активные треки и передал их назначенным подагентам: один отвечал за чаты Discord, а другой — за незавершённые мутации. Флаг, включающий все треки, позволяет одному инструменту отображать ветки и статусы агентов для каждого параллельного рабочего пространства.

./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all

Ниже приведен вывод терминала, зафиксированный при инициализации.

================================================================================
  CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
  Worktree: .worktrees/issue-29-telegram-wizard
  Branch:   feature/issue-29
  Agent:    pinocchio
  Status:   AWAITING_HUMAN (Question: "Verify Telegram Token config?")
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/29

[Track: unified_incident_lifecycle_observability_20260607]
  Worktree: .worktrees/issue-18-discord-warrooms
  Branch:   feature/issue-18
  Agent:    grazia
  Status:   RUNNING
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================

В этом списке сабагент, отвечающий за обработку ожидающих изменений, заблокирован и ждет ответа от HITL.

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

На скриншоте показан обзор активных рабочих деревьев, веток и назначений сабагентов. Синхронизация этих данных осуществляется с помощью одного запроса в любом направлении. В одном случае от Conductor требуется создать новый трек для каждой задачи, задавая все необходимые вопросы по одному треку за раз. В другом случае проверяется наличие задачи для каждого трека Conductor.

На детальном виде отображается ожидающий ответ HITL вопрос, требующий ввода данных из GitHub Issues.

Шаг 2: изоляция параллельных рабочих деревьев

Каждый агент работал на своей ветке, а секретарь фиксировал точные изменения в файлах и события в рабочем пространстве без каких-либо конфликтов.

На этом скриншоте показан монитор файлов рабочего дерева во время одновременной разработки.

Инструмент отслеживания потоков антигравитации отображает текущие задачи — что-то вроде того, что могло бы впечатлить первоначальную демонстрацию с одним запросом и четырьмя подагентами.

Шаг 3: опросы и управление человеком

Когда агентам требовалось уточнение, они публиковали вопросы, которые анализировал скрипт опросов poll_ghi_questions.py. Чтобы упростить управление с мобильных устройств, вопросы передавались через мост Telegram Sidecar. Оператору не нужно было сидеть за компьютером и обновлять страницу GitHub, поскольку мост отправлял каждый вопрос на телефон для быстрого одобрения в пути.

На скриншоте показан цикл обратной связи по одобрению и диагностике в действии.

Шаг 4: окончательное «зеленое» состояние

После того как каждая функциональная ветка прошла проверку и была последовательно объединена, Агостина открыла запрос на слияние, а окончательная проверка подтвердила, что все двенадцать треков SRE были включены в производственную ветку. Были ли они все полностью протестированы, включая взаимодействие между ними? Не совсем, и это тема для дальнейшей работы. Инструмент визуализации под названием Conductor At Scale преобразует обычную историю изменений git в анимацию в стиле аркадных игр, при этом треки Conductor взрываются на экране с использованием JavaScript.

Уроки, извлеченные из процесса

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

• Сократите время ожидания между агентом и человеком. Команда /roastme — хороший способ заранее выявить сложные вопросы, чтобы агент мог работать без прерываний, а Conductor эффективно собирает вопросы в автономном режиме. Вместо того чтобы задавать вопрос каждые пять минут по 30 секунд, вы можете ответить на все в течение одного 30-минутного интервала, сходить на велосипеде и вернуться к уже готовому приложению.

На этом скриншоте показано, как работает /roastme внутри Conductor, включая опечатки.

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

Существует также налог на оркестрацию. Написание кода стоит недорого, важна спецификация, а тестирование и проверка результатов стали новым узким местом. Похоже, другие специалисты в этой области согласны с этим. Команды могут опередить этот тренд или оказаться под его давлением.

Для тех, кто хочет попробовать этот подход, отправной точкой может стать десктопное приложение Antigravity 2.0, которое сразу предоставляет возможность визуальной оркестрации на нескольких треках.