Запускати агентів паралельно

У цьому посібнику показано, як запускати кілька агентів одночасно, щоб вони не перезаписували роботу одне одного.

Одиниця ізоляції — простір, а не агент

Коли в просторі починається робота, Control Center готує по одному checkout із copy-on-write для кожного зареєстрованого репозиторію під власним коренем цього простору, на гілці, похідній від шаблону гілки робочого простору. Далі кожен агент у просторі отримує власний робочий каталог оверлею — але ці оверлеї спільно використовують каталог repos/ цього простору.

Отже:

Два агенти в різних просторах працюють у різних checkout, на різних гілках. Це справжня ізоляція.
Два агенти в одному просторі працюють у тому самому checkout, на тій самій гілці. Їхні шляхи оверлеїв відрізняються, тож блокування шляху диспетчеризації (яке серіалізує запуски лише тоді, коли вони запитують ідентичний робочий каталог) їх теж не серіалізує. Вони можуть писати в ті самі файли одночасно.

Звідси правило: один простір на паралельне завдання.

Запускайте завдання паралельно — окремі простори

Відкрийте простір з агентом A і надішліть йому завдання.
Відкрийте другий простір з агентом B і надішліть йому інше завдання.
Обидва запускаються негайно — кожен у власному checkout простору на власній гілці.

Це рецепт, який варто застосовувати щоразу, коли агенти редагуватимуть файли.

Працюйте разом в одному просторі — кілька згадок

В одному просторі @-згадайте більше ніж одного агента:

@alice refactor the auth module. @bob review what alice lands.

Обидва агенти запускаються паралельно й потоком надсилають дані в той самий простір, з позначкою відправника. Оскільки вони спільно використовують checkout простору, використовуйте це для співпраці — один пише, інший читає, або двоє агентів міркують про те саме дерево — а не для двох незалежних редагувань.

Розгалуження з конвеєра

Вбудований шаблон pr_review — це готовий приклад розгалуження: кілька вузлів-рев’юерів виконуються одночасно від одного тригера, а вузол Consolidate (join) згортає їхні висновки в один звіт. Запустіть його з екрана конвеєрів — і кожен рев’юер запуститься паралельно.

Редактор конвеєрів ховає термінальний сторожовий елемент і перепростоює його так, щоб той чекав на кожен живий стік, коли ви додаєте або з’єднуєте крок, — тож гілки, які ви намалюєте самі, справді виконуються.

Спостерігайте, як вони працюють

Спостережуваність → Наживо (нижній колонтитул бічної панелі → «Спостережуваність», далі вкладка «Наживо») показує список агентів цього робочого простору, який оновлюється щосекунди: стан (виконується / очікує / припарковано / перервано), що робить кожен із них, токени й вартість останнього запуску та керування завершенням для процесу, що виконується. Вибір рядка закріплює висувну панель зі стенограмою.

Налаштування → Робочий простір → Агенти показує той самий список з іншим словником станів, де на першому місці увага, який виводиться з історії запусків кожного агента — виконується, заблоковано, не вдалося, неактивний, запусків ще немає — і відсортований так, що все, що потребує уваги, спливає вгору. Вкладка Журнали кожного агента містить його власну історію запусків.

Обидві поверхні обмежено активним робочим простором.

Розв’язуйте конфлікти

У різних просторах кожен простір перебуває на власній гілці, тож зіткнення постає як звичайний конфлікт злиття Git, коли ви зливаєте другий pull request. Розв’яжіть його так само, як будь-який конфлікт злиття.

Усередині одного простору немає ні межі гілок, ні блокування: агенти пишуть у ті самі файли наживо, і той, хто програв, просто перезаписується. Якщо вам кортить, щоб два агенти редагували в одному просторі, натомість розділіть роботу на два простори.

Щоб зменшити зіткнення в обох випадках:

Дайте кожному агенту окрему ділянку — різні файли, різні модулі.
Перш ніж запускати, перевірте через граф коду, чого торкається зміна. Див. Пошук коду через граф коду.
Своєчасно переглядайте та зливайте pull request кожного агента.

Міркування щодо ресурсів

Кожен агент, що виконується, коштує:

Checkout простору — мізерні витрати на диску, поки доступний copy-on-write; у Windows — git worktree. Файлова система, яка не вміє reflink, провалює підготовку, а не копіює.
Процес на хості сервера
Токени моделі, які накопичуються на кожного агента

Витрати потрапляють у Спостережуваність → Інсайти. Зауважте, що звичайний інтерактивний хід не має обмеження витрат; див. Керувати витратами, щоб дізнатися про дві команди, які його мають.