Несколько ИИ-агентов в одном репозитории
Несколько агентов могут делить репозиторий, если запись координируется: агент объявляет пути, которые собирается затронуть, сервер выделяет их ему и отказывает всем остальным, пока он их не отпустит. Без этой координации второй агент сотрёт работу первого, и ничто об этом не сообщит.
Случай, который всё ломает
Два агента получают две задачи, затрагивающие один и тот же файл. Первый читает файл, думает двадцать секунд, пишет. Второй прочитал ту же версию до того, как первый записал, и пишет поверх. Ничего не сломалось, никто не предупредил, а работа первого исчезла.
Этот случай не редкость, как только агентов становится больше одного, потому что агенты читают широко и пишут быстро. Именно поэтому почти все инструменты выбирают изоляцию: одна машина на агента, одна ветка на агента.
Что делают остальные: worktree на агента
Обычный ответ на эту проблему, разбиение: каждому агенту дают собственный git worktree, полную копию файлов со своим индексом, и следят, чтобы зоны не пересекались. Так делают Windsurf, Conductor и OpenHands, и это рекомендует большинство руководств.
Это работает, и у этого есть ровно один недостаток: разбиение, это обещание, а не гарантия. Никто не проверяет, что зоны не пересекаются, а когда они пересекаются, об этом узнают при слиянии, когда оба агента закончили и уже никто не помнит рассуждений.
Резервирование, в трёх шагах
Перед тем как писать, агент объявляет пути, которые собирается затронуть. Доска выделяет их ему, если они свободны, и отказывает, если заняты. У файла всегда только один владелец.
Во время работы наблюдатель следит за реальными записями на диске и связывает каждую с её автором. Запись по пути, занятому кем-то другим, снимается снимком до того, как попадает на диск: предыдущая версия сохраняется, поэтому ничего не теряется, даже если правило обошли.
В конце агент отпускает свои пути. Файл снова становится доступным для следующего, без слияния, потому что живых версий никогда не было одновременно две.
Что видно на экране
Каждое окно показывает своего агента за работой, а доска показывает, кто что держит. Видно, что агент ждёт, и почему. Застрявший агент виден до того, как он успевает навредить, и это настоящая разница с невидимой очередью.
Люди тоже учитываются. Несколько человек на одном канвасе управляют своими агентами и видят курсоры друг друга, у каждого своё имя.
Когда эта форма не подходит
Если ваши задачи действительно независимы и продолжительны, изоляция по машинам остаётся разумной: нечего координировать, нечего ждать. Совместное использование побеждает, когда задачи соприкасаются, а это происходит, как только несколько человек работают над одной функцией. Сравнения разбирают этот выбор по каждому инструменту.
Прямые ответы
Нужно ли использовать git worktree, чтобы запускать несколько агентов?
Это ответ, который дают большинство руководств, и он работает: один worktree на агента, у каждого свой индекс и свои файлы, поэтому столкновение невозможно. У него есть цена, и она всегда одна и та же: столько копий, сколько агентов, и одно слияние на копию в конце. Единый каталог с резервированием файлов устраняет и то, и другое, ценой того, что агент иногда ждёт тридцать секунд.
Почему бы не дать каждому агенту отдельную ветку?
Это распространённое решение, и оно переносит цену на конец. Три ветки создают три слияния, а конфликты появляются, когда все три агента закончили, то есть в момент, когда уже никто не помнит рассуждений. Общий каталог решает конфликт в момент, когда он возникает.
Что происходит, если агент игнорирует резервирование?
У него нет выбора: правило применяет сервер, а не предлагает модели. Наблюдатель следит за записями и связывает каждую с её автором, а запись по пути, занятому кем-то другим, снимается снимком до того, как попадает на диск, поэтому обе версии по-прежнему существуют.
Сколько агентов можно запустить одновременно?
Пять окон агентов на тарифе Pro, и больше на тарифах выше. Практический предел не машина, а число независимых задач, которые проект содержит в данный момент.