Теперь разработчики могут запускать несколько сессий агентов-разработчиков одновременно, не опасаясь перезаписи файлов состояния или конфликтов скрытых файлов. Рекомендательный паттерн «share-nothing» изолирует рабочее пространство каждого агента и предупреждает о потенциальных конфликтах. Этот подход заменяет жесткие блокировки на легковесный реестр, который помечает пересекающуюся работу до того, как она начнется, позволяя конвейерам продолжать работу даже в случае сбоя сессии.

Почему параллельные агенты создают проблемы

Запуск более чем одного автоматизированного помощника по написанию кода в одном репозитории ускоряет генерацию, тестирование или рефакторинг кода. На практике сразу возникают две проблемы.

  • Повреждение состояния — два агента пишут в один и тот же файл состояния; последующая запись перезаписывает предыдущую, стирая прогресс.
  • Конфликт файлов — два агента редактируют один и тот же исходный файл, не зная о существовании друг друга. Конфликт проявляется позже, когда diff показывает расходящиеся изменения.

Обе проблемы тратят время разработчика и могут привести к трудноотслеживаемым багам.

Правило «share nothing»

Основная идея проста: каждый агент получает свой собственный приватный черновик на диске и пишет только в файлы, принадлежащие этой сессии. Допускается только один намеренно общий файл на ветку, и для него действует правило «последний записавший побеждает» (last-writer-wins) — контент определяется тем агентом, который записал данные последним.

Слой присутствия (presence layer) отслеживает каждую активную сессию:

  • Имя ветки
  • Список задействованных файлов
  • Метка времени последней активности

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

Рекомендательные блокировки против блокирующих

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

Рекомендательная модель мягче. Она выдает предупреждение при обнаружении потенциального конфликта, но не останавливает новую сессию. Если запись в реестре устарела — то есть процесс, создавший её, больше не существует — система все равно лишь выдает предупреждение, позволяя разработчику самому решить, продолжать или нет.

Как реализовать этот паттерн

  1. Разделяйте состояние по автору — выделите каждому агенту собственную директорию для временных файлов и состояния. Зарезервируйте общие файлы только для действительно глобальных данных и применяйте правило «последний записавший побеждает» только там.
  2. Обеспечьте осведомленность при запуске — перед началом работы агента прочитайте реестр присутствия и сравните запрошенный список файлов с существующими записями. Прервите работу или выдайте предупреждение, если обнаружено пересечение.
  3. Проверяйте активность при чтении — при обращении к записи в реестре проверяйте, запущен ли соответствующий ID процесса в ОС. Удаляйте записи, принадлежащие завершенным процессам.
  4. Отдавайте предпочтение рекомендательным блокировкам — оставьте контроль разработчикам. Предупреждение позволяет им продолжить, приостановить или отменить действие, избегая взаимной блокировки (deadlock).
  5. Отслеживайте состояния ожидания — когда активно много агентов, внимание разработчика становится «узким местом». Отображайте, какие агенты ждут ввода данных человеком, чтобы можно было перераспределить приоритеты задач.

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

Риски и контраргументы

Some teams may argue that a hard lock guarantees safety: no two agents can ever write to the same file. The trade-off is reduced resilience—crashed sessions leave orphaned locks that stall the whole workflow.

На что обратить внимание

Если вы используете несколько ИИ-помощников для написания кода, рекомендательный паттерн «share nothing» предлагает прагматичный способ сделать так, чтобы они не мешали друг другу. Изолируя состояние, заранее раскрывая намерения и позволяя человеку решать, когда продолжать, этот метод балансирует между безопасностью и гибкостью, которой требуют современные конвейеры разработки.