Агенти паралельного кодування з робочими деревами Git, Conductor та Antigravity 2.0
Агенти паралельного кодування з git worktrees, Conductor та Antigravity 2.0: координатор, по одному worktree на кожного агента та десяток функцій SRE за приблизно п’ять годин.
Джерела: Orchestrating with Antigravity: A Crescendo of Agents (Part 2)
Від керування терміналами до візуальних інструментів
Якщо 2025 рік був роком ШІ-агентів, то 2026, схоже, стане роком спільної роботи багатьох агентів, і один із інженерів Google ще на початку передбачив, що це буде рік оркестрації агентів. Для тих, хто постійно працює з терміналами, проблеми виникають швидко. Спроба координувати команду паралельних підагентів, які створюють невелику гру з годинником, використовуючи вікна tmux, завантаження репозиторіїв та наклейки на моніторі, щоб пам’ятати, яка частина роботи виконується, перетворюється на справжній когнітивний хаос.
На фото видно кілька робочих столів macOS, заповнених терміналами agy з наклейками — це гарна ілюстрація того, як виглядає керування паралельними робочими просторами агентів без належних інструментів.
Ідея створення додатків за допомогою механізму кількох агентів виникла зі посту від червня 2026 року, у якому було показано, як один запит генерує чотирьох паралельних розробничих агентів, які створюють функціональний додаток менш ніж за дві хвилини. Функціональні помічники командного рядка чудово підходять для завдань з однією смугою виконання, але кілька одночасних потоків агентів, кожен з власною гілкою, механізмом перевірки та зворотного зв’язку координатора, не вміщуються у простий буфер для відображення історії змін. Саме тому наступним кроком стало переходження до десктопного додатку Antigravity 2.0.
Додаток групує все за проектами, по суті це папки, та відображає теми під кожною з них, починаючи з найновіших. У особистому проекті може бути тема для додавання синьої кнопки входу з прихованим паролем та інша для додавання задання backend у форматі /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.
Якщо уважно прочитати, стане зрозуміло, що в ньому міститься:
- опис бажаного продукту — у цьому випадку додатку для бронювання готелів
- команда з трьох підагентів
- порядок та час їхньої взаємодії
- що відбувається наприкінці, коли система запускається для людини, яка не є безпосередньо залученою до процесу перевірки
- найважливіша річ — спільний стан файлу: загальний документ
architecture.md
Діаграма показує, як агенти взаємодіють у цьому прикладі. Це метапрограмування у чистому вигляді. У завданні не описується код, а описується команда, яка його напише. Агенти спілкуються між собою через документ у форматі Markdown, що означає, що самі специфікації є каналом комунікації.
Список бажань щодо паралельної налаштовки був ще амбітнішим: реалізація запускається через GitHub Issues (GHI), тож кожен підагент отримує реальний тикет.
Компоненти робочого процесу
Налаштування складається з кількох елементів.
- Інтеграція з тикетами. Кожен підагент має працювати над тикетом, якщо такий існує.
- Rails для ШІ. Розширення Conductor надає роботі агента певних „рейлів“, тобто чітких меж. Один лише тикет не завжди містить достатньо інформації для дій агента, і іноді людина, яка бере участь у процесі (HITL), мусить відповісти на складні запитання, що запобігає недбалості у реалізації, наприклад у вигляді фрази „Звісно, я мав на увазі лише автентифікованих користувачів.“
git worktree. Worktrees запобігають тому, щоб два або більше агентів пошкодили один і той самий репозиторій. Коли кілька агентів створюють запити на з’єднання з віддаленими гілками, доцільно також мати „гіт-консьєржа“, який об’єднує код у основну гілку. Ця роль має бути обережною. Коли агент X намагається випустити функцію X, консьєрж залишається незворушним – він є останнім захистом єдності, адже код може бути бездоганним, проте випускатися без виконання тестів чи оновлення журналу змін, і нове вікно контексту добре це помічає.Щоб повторно використовувати цю структуру в різних кодових базах, правила та автоматизація були об’єднані у відкритий код агентської навички conductor-worktree-hitl, яку прозвали condutree. Її основні компоненти:
git worktreeдля асинхронної реалізації, з одним підагентом на кожен worktree та однією доріжкою Conductor
using-git-worktrees для автоматизації ізоляції робочих деревІснує три причини, чому цю функцію представлено як окрему навичку, а команди git не вставляються безпосередньо у командний рядок координатора. По-перше, це дозволяє об’єднати всі операції з налаштування робочого простору низького рівня, створення символічних посилань та виключення файлів у один керований скрипт. По-друге, командний рядок координатора залишається коротким та зосередженим на делегуванні завдань від головного агента до підагентів та вирішенні запитань, тож агенту не доводиться морочитися синтаксисом git. По-третє, інші розробники можуть використовувати цю навичку у власних репозиторіях та інструментах, отримуючи паралельну роботу без конфліктів, не переписуючи скрипти інтеграції.
Агент, озброєний цією навичкою, вивчає чотири аспекти:
- як створювати окремі робочі дерева для одночасних завдань
- правила ефективної роботи з git, а саме створення символічних посилань на спільні папки метаданих Conductor та їх виключення на локальному рівні, щоб команда
git statusвідображала чистий стан
Версія 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/, що повністю усуває ризик конфліктів. Він також публікує запитання у вигляді коментаря до задачі на GitHub із унікальною підпискою для відстеження. Скрипт опитування Агостіни спочатку перевіряє, чи є якась локальна папка з статусомawaiting_human. Якщо таких немає, виклик API GitHub повністю пропускається, що дозволяє заощадити понад 95 відсотків квоти. Коли на GitHub з’являється відповідь, локальний статус метаданих змінюється наanswered, що активує підагента. - Спільна пам’ять у стилі вікі. Замість того, щоб заповнювати контекст кожного підагента всією історією проекту, спільний каталог
conductor/функціонує як постійна пам’ять — структурований локальний каталог, який агенти читають та записують, як сторінку вікі. Це відображає відому думку Андрея Карпаті щодо пам’яті ШІ та відповідає поширеному занепокоєнню щодо того, що погано керована пам’ять агентів перетворює асистентів на золотих рибок. - Ієрархічне вирішення конфліктів. Коли готові гілки функцій об’єднуються по одній, може виникнути ієрархія конфліктів. Гілка Маріо без проблем об’єднується з гілкою валідації, але у Луїджі виникають конфлікти. Якщо людина виправляє конфлікт Луїджі на гілці валідації, його початкова гілка функцій у робочому дереві залишається з конфліктами та застарілою. Щоб уникнути такого відхилення, Агостіна вибірково впроваджує або об’єднує рішення назад у гілку Луїджі, зберігаючи ізольоване робоче дерево у відповідності з перевіреним кодом.
- Використовувати запити на підтягування замість додавання коду до основної гілки. Якщо додати об’єднану гілку перевірки безпосередньо до
main, це дозволить обійти процедуру перевірки, тому інтеграція відбувається через PR. Підпрацівники роблять комітти локально, Агостіна їх підтягує, перевіряє та об’єднує локально, а коли тести інтеграції пройдуть, вона додає об’єднану гілку та виконує командуgh pr create --title "feat: ..." --body "...". Потім людський рецензент може переглянути відмінності та результати автоматичних перевірок у власному інтерфейсі GitHub. Агостіна записує URL PR у файліmetadata.jsonреєстру та відображає поточний статус за допомогою командgh pr listтаgh pr status. - Завершення через концептуальні конфлікти. Дві доріжки можуть бути логічно несумісними, наприклад, коли одна реалізує певну функцію, а інша переробляє її несумісним способом. Якщо Агостіна помічає це, вона може негайно завершити роботу одного з конфліктуючих підагентів. Про скасування необхідно зазначити у записі до проблеми цього агента, а саму проблему потрібно заблокувати або поєднати з проблемою іншого агента, щоб зберегти чітку історію рішень. Це траплялося лише один раз.
Життєвий цикл оркестрації
Людський оператор ніколи не спілкується безпосередньо з підагентами. Вони працюють у повній ізоляції всередині своїх робочих дерев, а оператор спілкується лише з координатором у два моменти: під час запуску процесу та для відповідей на запитання, надіслані спостерігачем HITL.
Діаграма потоку показує життєвий цикл агента та підагента у шести кроках:
- Запуск. Оператор починає виконання процесу.
- Читання статусу. Агостіна перевіряє активні проблеми у GitHub та стани траєктів у Conductor.
- Створення ресурсів. Вона створює ізольовані робочі дерева та запускає паралельних підагентів-розробників.
- Спостерігач HITL. Запити від підагентів, які потребують блокування, надсилаються людині, а відповіді повертаються назад, що забезпечує безпечний та асинхронний цикл зворотного зв’язку.
- Очищення. Коли підагенти завершують роботу та відкривають свої PR, Агостіна видаляє тимчасові каталоги робочих дерев.
- Злиття у основну версію. Вона інтегрує зміни та відкриває або зливає остаточний PR, після чого повертається до етапу очищення для виконання будь-яких залишкових завдань. Цей процес може перетворитися на складну ситуацію, але агенти краще справляються зі злиттями у git, ніж люди.
Відповідь на запитання все ще залишається дуже експериментальною, і було протестовано три підходи. Один з них — це Telegram sidecar bridge, який працює як фоновий демон, надсилає запитання чи схвалення змін у базі даних на телефон розробника через Telegram-бота та очікує на відповіді.
На діаграмі показаний асинхронний потік у Telegram. Його переваги — відповіді та схвалення, орієнтовані на мобільні пристрої, паралелізм без конфліктів, оскільки запитання зберігаються у окремих каталогах за напрямками, що уникає конкуренції за блокування файлів, та історія аудиту, адже кожне рішення зберігається у репозиторії у форматі JSON. Найпростіший підхід, який передбачав взаємодію з основним агентом через questions.json, було відкинуто, оскільки він ніколи не розблоковувався автоматично та потребував ручного запуску, хоча хуки чи майбутні версії могли б це виправити.
Кейс-стаді: дванадцять напрямків SRE за п’ять годин
Це було веб-застосунок, створений на основі розширення SRE. Багато його функцій могли виконуватися паралельно: інтерфейси користувача, серверні кінцеві точки, чат-асистент, який працює за допомогою LLM, бот у Telegram, інструменти OpenTelemetry та виявлення ресурсів GCP.
Для цього знадобилося використати дванадцять складних можливостей SRE, які були розділені на понад двадцять конкретних питань у GitHub. Потім система була запущена. Приблизно за п’ять годин, переважно без людського керування, конвеєр Conductor++ створив, протестував та об’єднав усі ці елементи у головну гілку. Обсяг роботи охоплював від налаштування відстеження дій за допомогою OpenTelemetry у Cloud Run до створення інтерактивних інструментів у Telegram для обробки інцидентів та реєстрів для схвалення поточних змін.
Інтеграція та результати об’єднання
Завдяки оркестрації паралельних завдань кожна з функцій розроблялася, тестувалася та інтегрувалася у main.
Зображення таблиці показує підсумковий звіт про статус ключових треків. Також було інтегровано ще вісім операційних треків, які охоплюють таксономію статусів інцидентів, видалення та архівування інцидентів, взаємне посилання проєктів у wiki, керування станом у кількох середовищах, міграцію стану до хмари, інтерфейс wiki з реактивною відповіддю, підключення до 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 Inspector CLI перелікнув активні траєкти та передав їх підагентам, один з яких відповідав за кімнати обговорень у 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 issues та Conductor tracks одним і тим самим. Це два ресурси, які можуть відхилятися один від одного. Агента попросили виявити такі відхилення.
На скріншоті показано огляд активних робочих дерев, гілок та призначень підагентів. Узгодження цих даних вимагає лише одного запиту в будь-якому напрямку. Один спосіб — попросити Conductor створити новий трек для кожного issue, поступово ставлячи всі необхідні запитання. Інший спосіб — переконатися, що для кожного треку Conductor існує відповідний issue.
У детальному перегляді показано запит HITL, який чекає на введення даних у GitHub Issues.
Крок 2: ізоляція паралельних робочих дерев
Кожен агент працював на своїй гілці, а секретар фіксував точні зміни у файлах та події у робочому просторі без жодних конфліктів.
Це знімок екрана файлового монітора у режимі робочого дерева під час одночасної розробки.
Інструмент відстеження потоків антигравітації відображає поточні операції — саме такий вид інформації міг би вразити користувачів первісної демонстрації з одним запитом та чотирма підагентами.
Крок 3: опитування та керування людиною
Коли агентам потрібні були уточнення, вони публікували запитання, які аналізував скрипт опитування poll_ghi_questions.py. Щоб зробити процес керування людиною придатним для мобільних пристроїв, запитання надсилалися через міст Telegram Sidecar. Оператору не доводилося сидіти за комп’ютером та оновлювати сторінку GitHub, адже міст автоматично надсилав кожне запитання на телефон для швидкого схвалення в дорозі.
На скріншоті показано цикл зворотного зв’язку щодо схвалень та діагностики у дії.
Крок 4: кінцевий стан «зеленого» кольору
Після того, як кожна функціональна гілка пройшла перевірку та була послідовно об’єднана, Агостіна створила запит на з’єднання, а остаточний аудит підтвердив, що всі дванадцять траєкторій SRE були об’єднані у гілку для продакшну. Чи пройшли вони повністю тестування, включаючи перевірку взаємодії між собою? Не зовсім, і це тема для подальшої роботи. Інструмент візуалізації під назвою Conductor At Scale також перетворює звичайну історію змін git на анімацію у стилі аркад, де траєкторії Conductor вибухають на екрані за допомогою JavaScript.
Уроки з цього процесу
Перший урок — коли це можливо, підтримувати спілкування з одним агентом та доручати підагентам лише прості, заздалегідь визначені завдання, які не вимагають взаємодії. Дві практики сприяють цьому.
- Мінімізуйте час очікування між агентом та користувачем. Команда
/roastme— це хороший спосіб заздалегідь висувати складні запитання, щоб агент міг працювати без перерв, а Conductor ефективно збирає запитання офлайн. Замість запитання кожні 5 хвилин протягом 30 секунд ви можете відповісти на всі запитання протягом однієї 30-хвилинної сесії, поїхати на велосипеді та повернутися до готового додатку.
На тому скріншоті показано, як працює /roastme у Conductor, включаючи опечатки.
- Зберігайте прості стосунки між агентом та підагентом. У професійному середовищі часто говорять про складні багатоагентні ієрархії, але у 2026 році безпечнішим вибором є прості, повторювані завдання, які вимагають багато зусиль для реалізації та мінімум неоднозначностей, що дозволяє уникнути зайвої навантаженості від оркестрації.
Існує ще й податок на оркестрацію. Написання коду — це дешево, важлива специфікація, а тестування та прийняття результатів стали новою перешкодою. Інші фахівці в цій галузі, здається, погоджуються. Команди можуть або випередити цю тенденцію, або стати її жертвами.
Для тих, хто хоче спробувати цей підхід, відправною точкою є десктопний додаток Antigravity 2.0, який заздалегідь надає можливість візуальної оркестрації кількох треків.
Пов’язані матеріали
- Вулканічні ударні хвилі в домашніх барометрах: раннє попередження на основі даних 29 334 метеостанцій — Як метеостанції Netatmo, фізика хвиль Ламбе та штучні інтелектуальні агенти визначали кратери, оцінювали потужність вибухів та надавали кілька хвилин попередження без хибних сигналів.