Как предотвратить перезапись кода несколькими кодирующими агентами
Запуск одного AI-агента для написания кода в репозитории похож на парное программирование. Запуск трех или пяти агентов в том же репозитории может превратиться в фабрику конфликтов слияния, если они все используют один и тот же checkout. Один агент меняет ветки, другой редактирует тот же файл, третий выполняет команду очистки, и внезапно никто не знает, какой diff относится к какой задаче.
Решение — не более длинный промпт. Решение — рабочий процесс. Я отношусь к агентам как к быстрым младшим разработчикам с доступом к командной строке: они полезны, но им нужны границы.
Краткая версия
- Используйте один Git worktree для каждого агента.
- Используйте одну ветку для каждой задачи.
- Назначьте каждому агенту четкие границы владения файлами или модулями.
- Разместите общие правила репозитория в
AGENTS.md,CLAUDE.mdили в обоих файлах с помощью символической ссылки. - Блокируйте деструктивные команды Git, если их не одобрит человек.
- Сливайте через pull requests с CI и защитой веток.
Этого достаточно для большинства параллельных задач агентов.
Почему общий checkout выходит из строя
Обычный Git checkout имеет один рабочий каталог (working tree), один индекс и одну текущую ветку. Это нормально для одного разработчика или одного агента. Становится беспорядочно, когда несколько агентов действуют одновременно.
Если Агент А находится на полпути рефакторинга аутентификации, а Агент Б выполняет git checkout main, рабочее пространство Агента А внезапно меняется под ним. Если Агент В выполняет git reset --hard, несохраненная работа может исчезнуть. Даже безобидные команды, такие как git stash pop, могут смешать несвязанные изменения.
Вы можете сказать агентам не делать этого, и вы должны. Но изоляция файловой системы сильнее доверия.
Используйте Git worktrees для изоляции
Git worktrees позволяют одному репозиторию иметь несколько рабочих каталогов, привязанных к одной истории. Каждый каталог может находиться на своей ветке, при этом совместно используя одну и ту же базу объектов. Вы избегаете затрат и путаницы при клонировании репозитория пять раз, но каждый агент по-прежнему получает свои собственные файлы.
git fetch origin
git worktree add ../site-auth -b agent/auth-refactor origin/main
git worktree add ../site-billing -b agent/billing-fix origin/main
git worktree add ../site-tests -b agent/test-coverage origin/main
git worktree listЗатем запустите одного агента внутри каждого каталога. Агент А работает в ../site-auth. Агент Б работает в ../site-billing. Агент В работает в ../site-tests. Они могут запускать тесты, редактировать файлы и создавать коммиты, не изменяя checkout друг друга.
Это также шаблон, который Claude Code документирует для параллельных сессий: отдельные worktrees, отдельные ветки и изолированные правки. Справочные документы Anthropic идут дальше и описывают параллельные сессии на основе worktree как распространенный рабочий процесс для опытных пользователей при одновременном запуске нескольких сессий Claude.
Назначьте каждому агенту свою область ответственности
Worktrees решают проблемы на уровне файлов. Они не решают проблемы на уровне продукта. Два агента все еще могут принимать несовместимые решения, если задача нечеткая.
Прежде чем запускать агентов параллельно, я разделяю работу по владению. Не только по именам файлов, но и по ответственности.
Вы отвечаете за src/auth/** и tests/auth/**.
Не редактируйте файлы за пределами этой области.
Не меняйте формы публичных API без предварительной остановки.
Запустите тесты аутентификации перед сообщением о завершении.
Откройте PR с сфокусированным резюме.Этот промпт скучный, именно поэтому он работает. Агентам нужны скучные границы больше, чем остроумные фразы.
Лучшее разделение происходит по естественным границам модулей: аутентификация, биллинг, поиск, документация, UI-компоненты, миграции, тесты. Худшее разделение — это когда два агента имеют пересекающиеся области ответственности за одну и ту же службу, и вы надеетесь, что Git разберется позже.
Используйте AGENTS.md и CLAUDE.md как общие правила
Инструкции репозитория должны находиться в репозитории, а не только в окне чата. CLAUDE.md — это соглашение, которое читает Claude Code. AGENTS.md — это более общее соглашение для агентов кодирования. Если вы используете оба инструмента, сохраняйте один источник истины и создайте символическую ссылку для другого имени на него.
ln -s CLAUDE.md AGENTS.mdЭтот файл должен включать команды сборки репозитория, команды тестирования, заметки по развертыванию, правила стиля и любые жесткие ограничения. Например: не редактировать сгенерированные файлы, не трогать миграции без одобрения, использовать npm run lint перед передачей, или держать блоки кода блога в одной HTML-строке с тегами <br/>.
Суть проста: каждый агент должен начинать с одинаковым локальным контекстом.
Сделайте опасные команды Git явными
Я не позволяю агентам импровизировать с деструктивным Git. Эти команды полезны в терминале под управлением человека, но рискованны в автономной работе:
git reset --hard
git checkout .
git clean -fd
git push --force
git stash popМое правило по умолчанию: читать свободно, писать узко и спрашивать перед деструктивным Git. Агенты могут выполнять git status, git diff, git log и обычные коммиты. Они не должны отбрасывать работу, принудительно отправлять или перемещать другую ветку, если это явно не требуется задачей.
Используйте pull requests как точку передачи
Не сливайте работу агентов, копируя файлы между папками. Пусть каждый агент создаст ветку и pull request.
git status
git diff
npm test
git add src/auth tests/auth
git commit -m auth-refactor
git push origin agent/auth-refactor
gh pr createНа GitHub правила защиты веток могут требовать обзоры pull request, проверки статуса, линейную историю и очереди слияния. Эти элементы управления становятся более важными, когда агенты могут быстро генерировать код. Скорость полезна только в том случае, если main остается надежным.
Мне нравятся небольшие PR от агентов. Сфокусированный diff на 200 строк поддается проверке. Смешанный рефакторинг на 4000 строк — это то место, где скрываются ошибки.
Слияние в порядке зависимостей
Если Агент А изменяет API, а Агент Б использует этот API, сначала слейте А. Затем выполните rebase для Б на обновленную базовую ветку и позвольте Б самостоятельно разрешить конфликты.
git fetch origin
git rebase origin/main
npm testЭто сохраняет чистоту ментальной модели. Агент, отвечающий за зависимую работу, несет ответственность за адаптацию к новой базе. Человек-рецензент видит один связный PR за раз.
Рабочий процесс, который я бы использовал завтра
- Обновите
main. - Создайте один worktree и ветку для каждой задачи агента.
- Запустите каждого агента внутри его собственного worktree.
- Предоставьте каждому агенту письменную границу ответственности.
- Заставьте каждого агента запускать соответствующие тесты.
- Отправьте каждую ветку и откройте PR.
- Просмотрите, слейте в порядке зависимостей, затем удалите завершенные worktrees.
git worktree remove ../site-auth
git branch -d agent/auth-refactorНесколько агентов кодирования могут работать над одной и той же кодовой базой. Они просто не должны работать в одном checkout. Используйте Git для изоляции, pull requests для обзора и файлы инструкций на уровне репозитория для общих правил. Это даст вам параллельную скорость, не превращая репозиторий в кучу загадочных diff'ов.