Что происходит, когда два AI-агента одновременно редактируют один файл

Кратко: Когда два и более AI-кодинг-агента одновременно редактируют один файл, каждое следующее сохранение перезаписывает предыдущее. Решение — координирующий слой по протоколу MCP с механизмом блокировок файлов и очередей сообщений между агентами.

Один файл api/routes.py, два AI-агента, два сохранения подряд — и работа первого агента исчезает без следа. Мы воспроизвели этот сценарий на реальном проекте за 11 минут. Не потому что агенты глупые — они просто не знают друг о друге. Cursor, Windsurf, Claude Code — каждый из них отлично справляется в одиночку, но стоит запустить два параллельных сеанса на одном репозитории, и вы получаете гонку записей, которую ни один из них не умеет разрешать самостоятельно.

Проблема не в качестве генерации кода. Проблема в отсутствии координации. И вот как мы её решали.

Почему несколько AI-агентов без координации начинают уничтожать работу друг друга?

Сцена занимает секунды. Claude Code открывает api/routes.py и добавляет новый эндпоинт /users/export. Параллельно Codex открывает тот же файл — и рефакторит блок маршрутов авторизации. Claude Code сохраняет первым. Через четыре секунды Codex записывает свою версию поверх. Эндпоинт /users/export исчезает — тихо, без единого предупреждения в консоли. Никакого конфликта в Git нет — потому что до коммита дело ещё не дошло. Потеря произошла раньше, на уровне файловой системы.

Вот что здесь ломается: у Claude Code, Codex и Gemini CLI нет общего контекста. Ни один из них не видит, что соседний агент держит тот же файл открытым. Нет Jira-тикета, нет pull request-а, нет сигнала «файл занят». Каждый агент работает так, будто он единственный разработчик в проекте. Мы привыкли думать, что merge-конфликт в Git — это страховка. Но конфликт фиксируется при слиянии веток, а перезапись в рабочей директории происходит до любого git add.

Ирония в том, что совместное редактирование одного документа стало нормой для людей совсем недавно. Google Docs появился в 2006-м — до этого больше 30 лет компьютеры фактически не поддерживали одновременную работу нескольких авторов над одним файлом. А мы в 2026 году ожидаем от AI-агентов того, чему люди учились десятилетиями. Разница в том, что агенты пишут код в десятки раз быстрее — и окно для конфликта записи сужается до секунд. Три агента без координатора — это три слепых машинистки за одной клавиатурой.

Что такое «почтовый офис» для AI-агентов и зачем он нужен?

Три базовые сущности делают командную разработку возможной у людей: адресация (кому писать), блокировки (кто занял файл) и история (что уже сделано). Jira хранит задачи и исполнителей. GitHub фиксирует, кто открыл pull request и какие файлы затронуты. Code review не даёт влить изменения без проверки. AI-агентам для совместной работы нужны ровно те же примитивы — просто упакованные иначе.

«Почтовый офис» — это MCP-сервер-посредник. Не чат между агентами, а инфраструктура координации. Агент при запуске регистрируется через этот сервер и получает уникальный адрес во внутренней сети. Дальше работают три механизма.

Первый — адрес для сообщений. Каждый агент знает, куда отправить запрос соседу. Это аналог @-упоминания в Jira, только машиночитаемый.

Второй — список занятых ресурсов. Перед редактированием агент резервирует файл. Остальные видят блокировку и ждут или берут другую задачу. Похоже на CODEOWNERS + lock в Git LFS, но срабатывает до коммита — там, где мы теряли изменения в примере с api/routes.py.

Третий — общая история действий. Лог того, кто что менял и в каком порядке. Без него два агента через минуту потеряют контекст.

Хочу быть точным: этот слой не заменяет Git, не делает code review и не принимает архитектурных решений. Он решает одну конкретную задачу — убирает человека-посредника из рутины «подожди, этот файл сейчас трогает другой агент». Координация, не управление.

Как устроены inbox, outbox и file lease внутри такой системы?

Три механизма — сообщения, аренда файлов, история действий — закрывают три разных класса проблем. Разберём каждый отдельно.

Сообщения: inbox и outbox. У каждого агента два почтовых ящика. Outbox — исходящие, inbox — входящие. Агент не «разговаривает» с соседом напрямую. Он кладёт сообщение в свой outbox, сервер маршрутизирует его в inbox адресата. Вот два примера из реального кейса мультиагентной сборки:

— «Gemini, я закончил с модулем авторизации, можешь брать в работу.»

— «Codex, я изменил интерфейс функции, которую ты используешь — вот новая сигнатура.»

Первое сообщение — передача эстафеты. Второе — предупреждение о сломанном контракте. Без inbox/outbox агенты остаются изолированными исполнителями. С ними — становятся участниками координируемой цепочки, где Codex не начнёт вызывать функцию со старой сигнатурой.

File lease: аренда файла. Механика простая. Агент запрашивает lease на файл. Если файл свободен — получает его. Если занят — встаёт в очередь и берёт другую задачу. Lease снимается, когда агент завершает запись.

Ближайшая аналогия для людей — курсор соавтора в Google Docs. Вы видите, что коллега печатает в третьем абзаце, и не лезете туда. Разница: в Google Docs два человека технически могут писать в одно место. File lease жёстче — он блокирует доступ полностью. Это решает самую дорогую проблему мультиагентной записи: перезапись чужих изменений до того, как Git вообще узнал о конфликте. Lease не ловит логические ошибки и не проверяет архитектуру. Он предотвращает именно физическую потерю байтов.

История действий. Лог фиксирует, какой агент какой файл менял и когда. Если Claude Code подключается к проекту через 10 минут после старта — он читает историю и видит: Gemini уже переписал auth.py, Codex добавил три эндпоинта в routes.py. Агент не начинает с нуля. Он встраивается в изменившийся контекст за секунды, а не за минуты повторного анализа всей кодовой базы.

На практике мы видели, что без истории действий агент тратит до 40% контекстного окна на повторное «понимание» проекта. С логом — сразу переходит к своей задаче. Иначе никак.

Почему для такой координации выбрали именно MCP, а не кастомный протокол?

MCP — Model Context Protocol — открытый стандарт связи AI-агентов с внешними инструментами, предложенный Anthropic и поддержанный сообществом. Claude Code, Codex и Gemini CLI уже умеют работать с MCP-серверами из коробки. Это главная причина выбора: три агента подключаются к одному серверу координации без единой строчки клей-кода под каждого.

Кастомный протокол — не всегда плохое решение. Для двух жёстко связанных сервисов он может быть проще. Но наш случай другой: сегодня три агента, завтра — десять. Каждый новый агент с кастомной интеграцией — это отдельный адаптер, отдельные тесты, отдельная документация. При трёх агентах это три адаптера. При десяти — десять. С MCP адаптер один, потому что протокол стандартный. Стоимость добавления нового агента падает практически до нуля — если он поддерживает MCP, он просто подключается.

Есть и второй аргумент, менее очевидный. Стандартный протокол — это ставка на срок жизни инфраструктуры. Кастомные интеграции ломаются при каждом обновлении API агента. MCP фиксирует контракт взаимодействия: пока агент совместим со стандартом, сервер координации работает без изменений. Поддержка кастомных коннекторов к двум LLM-провайдерам съедала около 15 часов в месяц — это примерно полтора рабочих дня, которые инженер проводил не за разработкой, а за отладкой чужих breaking changes. После перехода на стандартизированный протокол — ноль часов на рутину совместимости.

Здесь я могу ошибаться, но MCP не покрывает, например, стриминг больших артефактов или сложную авторизацию между агентами. Но для координации — inbox, outbox, file lease — его спецификации достаточно. А переносимость между Claude Code, Codex и Gemini CLI делает архитектуру независимой от того, какой агент окажется сильнее через полгода.

Какой стек понадобился, чтобы это было инфраструктурой, а не игрушечным прототипом?

В январе 2026 года мы собрали рабочий стек из шести компонентов: FastAPI, FastMCP, PostgreSQL, Redis, Docker и интеграции с тремя LLM-провайдерами. Каждый компонент закрывал конкретный архитектурный слой, а не попал в список ради длины резюме.

Разделение простое. FastAPI отвечает за HTTP-слой — через него внешние клиенты и дашборды общаются с сервером координации. FastMCP обслуживает агентов по стандартному протоколу: inbox, outbox, file lease. Два входа в одну систему, два разных контракта. Попытка склеить оба в один фреймворк — путь к хрупкому коду, мы это проверили на практике.

PostgreSQL хранит состояние: историю действий агентов, метаданные задач, результаты. Это долговременная память. Redis — короткая: lease-блокировки файлов живут секунды, очереди задач обновляются постоянно. Держать lease в PostgreSQL — значит добавлять 5–15 мс латентности на каждую операцию блокировки. При десятках запросов в минуту от трёх агентов это ощутимо — особенно когда агенты ждут друг друга и эта задержка начинает накапливаться.

Docker изолирует сервер координации от хост-машины. Без контейнеризации воспроизводимость деплоя — вопрос везения. С ней — один docker compose up и одинаковое поведение на любом сервере.

Отдельный выбор — мультивендорность. Интеграции с OpenAI, Google Gemini и Anthropic Claude заложены с первого коммита. Не «поддержим потом». Система проектировалась так, чтобы смена или добавление провайдера не требовала переписывания координационного слоя. Агент подключается через MCP — серверу всё равно, какая модель за ним стоит.

Масштаб решения определяется не количеством технологий, а наличием отдельных слоёв для API, состояния, быстрых операций, изоляции и внешних подключений. Уберите любой — получите прототип для демо, а не инфраструктуру для работы.

Что сломалось в file lease раньше всего и как это исправили через TTL?

Самая опасная ошибка в координации агентов — не конфликт записи, а вечная блокировка файла после падения агента. Модель «взял файл — отпустил файл» выглядит надёжной ровно до первого сбоя. Агент падает посреди задачи. Или зависает на вызове к LLM-провайдеру. Или теряет сетевое соединение. Файл остаётся заблокированным навсегда, потому что «отпустить» некому.

Это не редкий edge case. В распределённых системах это базовый сценарий.

Мы столкнулись с ним в первую же неделю тестирования — вернее сказать, он сам нас нашёл. Три агента работали параллельно. Один из них завис на ответе от API — и заблокированный им файл стал недоступен для остальных двух на 40 минут, пока мы не заметили проблему вручную. Ручная разблокировка через базу? Работает один раз. На десятый инцидент за день это уже не решение, это просто раздражает.

Ответ — TTL (time-to-live) на каждый lease. Если агент не продлил аренду в течение N секунд, файл автоматически освобождается. Lease превращается из вечной блокировки в самоочищающийся механизм. Redis, где хранятся lease-записи, поддерживает TTL нативно — технически это одна строка кода.

Но одна строка кода потянула за собой архитектурные последствия. Пришлось переработать всю логику истечения аренд. Агент теперь обязан периодически отправлять heartbeat — подтверждение, что он жив и работает с файлом. Нет heartbeat — lease истекает, файл свободен. Появился отдельный слой мониторинга активных агентов: какой агент держит какой файл, когда последний раз продлил аренду, сколько раз терял lease за сессию.

TTL не решает все проблемы. Агент может потерять прогресс — он работал над файлом, завис, lease истёк, другой агент забрал файл. Частично выполненная работа пропадает. Это цена, которую мы приняли сознательно: потерять прогресс одной задачи лучше, чем заблокировать файл для всей системы на неопределённый срок.

Из нашего опыта: TTL — это не мелкая доработка. Это точка, после которой lease становится production-ready механизмом, а не демонстрационной абстракцией.

Какой практический вывод из этого кейса важен командам, которые хотят внедрять AI-агентов в 2026 году?

Главный вопрос для команд в 2026 году — не «какого агента выбрать», а «как не дать нескольким агентам мешать друг другу». Мы обнаружили это на собственном проекте: 80% времени ушло не на подключение моделей, а на предотвращение конфликтов между ними. Выбор между Claude и Gemini занял день. Отладка ситуации, когда оба одновременно правят один файл, — недели.

Ошибки при слиянии кода легко создать, трудно обнаружить и ещё труднее исправить. Это давно описанная проблема в разработке распределённых систем. Сместить контроль конфликтов на ранний этап дешевле, чем разгребать последствия. Даже при нулевом бюджете на инфраструктуру: один слой координации стоит меньше, чем повторная работа после каждого потерянного изменения.

Минимально жизнеспособная мультиагентная система начинается с трёх дисциплин, а не с автогенерации кода:

• Inbox/outbox — агенты общаются через очередь сообщений, а не напрямую. Один упал — остальные продолжают.
• File lease с TTL — блокировка ресурса с автоматическим освобождением. Без этого зависший агент парализует всю систему.
• История действий — каждый шаг записан. Без лога невозможно понять, кто что сломал и когда.

Протокол MCP снимает отдельную боль: вместо написания плагинов под каждого провайдера вы подключаете агентов через единый стандарт. Серверу координации всё равно, OpenAI за агентом или Anthropic. Это не абстрактное удобство — это конкретная экономия на поддержке интеграций при смене или добавлении модели.

Один вывод, который я бы забрал из этого кейса: не начинайте с «умного агента». Начните с тупой, надёжной шины между агентами. Магия автокода бесполезна, если результат перезаписывается соседним процессом.

Почему следующий прорыв — не в агентах, а между ними?

Индустрия вкладывает миллиарды в то, чтобы каждый отдельный агент генерировал код лучше. Мы потратили полгода и убедились: это не то место, где буксует мультиагентная разработка.

Код генерируется нормально. Проблема начинается, когда три агента одновременно лезут в один файл, не знают о решениях друг друга и молча ломают чужую работу. TTL-блокировки, shared context, lease-механизмы — вся эта невидимая обвязка съела 80% нашего времени. Не потому что мы плохо спланировали. А потому что координация машин — это и есть настоящая инженерная задача, а не подключение очередного «умного» ассистента.

Смена оптики простая. Перестаньте выбирать между Claude, GPT и Gemini как между «лучшим кодером». Начните проектировать слой, который делает любого из них ответственным участником общей работы. Без этого слоя каждый новый агент не ускоряет команду, а умножает хаос.

Конкурентное преимущество в 2026 году — не у тех, кто подключил самую дорогую модель, а у тех, кто научил свои модели не мешать друг другу.

Часто задаваемые вопросы

Сколько AI-агентов можно запускать параллельно на одном репозитории без конфликтов? На практике мы видели стабильную работу 3–5 агентов одновременно, если каждый работает в изолированной ветке и касается разных модулей. При 6+ агентах количество merge-конфликтов растёт нелинейно — даже при разделении по файлам агенты начинают конфликтовать на уровне общих зависимостей и конфигов.

Какие AI-кодинг-агенты лучше всего работают в связке друг с другом? Cursor, Cline и Aider на апрель 2026 года чаще всего используются в мультиагентных сетапах, потому что у них предсказуемый формат коммитов и поддержка работы через CLI. Связка Claude Code + Aider хорошо показала себя в наших проектах для разделения «архитектор — исполнитель». Главное — не сам агент, а возможность задать ему чёткие границы: конкретные файлы, ветку и набор тестов для проверки.

Как предотвратить ситуацию, когда один AI-агент переписывает код другого? Жёсткое правило — один агент, одна ветка, один модуль. Используйте CODEOWNERS или аналогичный механизм, чтобы агент физически не мог коммитить в чужую зону ответственности. Автоматический CI-прогон тестов перед мержем ловит 80–90% случаев, когда агенты ломают работу друг друга.

Нужен ли человек-ревьюер при работе нескольких AI-агентов? Да, и это не перестраховка — это необходимость. Из нашего опыта, без человеческого ревью мультиагентные сетапы за 2–3 дня накапливают «тихий» технический долг: дублирование логики, несогласованные интерфейсы между модулями, раздувание зависимостей. Минимальный контроль — ревью каждого merge request перед попаданием в main.

Сколько стоит запуск нескольких AI-кодинг-агентов параллельно? Расход токенов при 3–4 параллельных агентах на базе Claude или GPT-4o составляет примерно $15–40 в день в зависимости от размера контекста и частоты запросов. Основная статья расходов — не сами токены, а CI/CD: каждый агент генерирует коммиты, каждый коммит запускает пайплайн. По данным наших клиентов, бюджет на CI при мультиагентной разработке вырастает в 2–3 раза по сравнению с одним агентом.