Пять ИИ-агентов в одном проекте: почему одних Git worktree недостаточно
Orca предлагает раздать один запрос пяти coding-агентам, запустить каждого в отдельном Git worktree, сравнить изменения и слить лучший вариант. Звучит как простое ускорение разработки. Но изоляция каталогов решает только часть задачи: без общего контракта, критериев выбора и правил объединения пять веток могут произвести пять несовместимых ответов. Я разобрал публичное описание проекта и собрал управляемую схему на одном учебном калькуляторе.
◆ Что предлагает Orca
Orca — открытый инструмент для управления несколькими coding-агентами в одном рабочем пространстве. В README проекта прямо перечислены Codex, Claude Code, OpenCode и Pi; ниже приведён более широкий список поддерживаемых CLI-агентов. Главная механика — отдельный Git worktree для каждого запуска. Источник: https://github.com/stablyai/orca
Один запрос можно отправить пяти агентам, получить пять независимых изменений, сравнить их и объединить выбранный вариант. По описанию разработчиков, Orca работает на Windows, macOS и Linux, поддерживает удалённые worktree по SSH, комментарии к строкам diff, мобильный companion и Design Mode. В последнем можно выбрать элемент в окне Chromium и передать агенту его HTML, CSS и снимок.
На момент просмотра 20 сентября 2026 года GitHub показывал около 73,1 тысячи звёзд и 4,8 тысячи форков. Это хороший индикатор внимания к проекту, но не результат теста скорости, качества кода или безопасности. Репозиторий опубликован по лицензии MIT. Я не устанавливал Orca для этого материала: ниже — разбор публичного описания и вручную подготовленная схема работы.
◆ Worktree не делает пять ответов совместимыми
Git worktree даёт каждой ветке собственный рабочий каталог. Агент А может менять компонент, пока агент Б строит другой вариант того же компонента, и файлы не будут перезаписывать друг друга в процессе работы.
Но при объединении остаются три разных вида конфликта:
• текстовый: две ветки изменили одни строки;
• логический: код слился без ошибки, но одна версия считает цену за все места по последней ставке, а другая — ступенчато;
• контрактный: один агент возвращает число, второй форматированную строку, третий отправляет расчёт во внешний API.
Worktree устраняет прямую борьбу за один каталог. Он не определяет правильный результат. Поэтому сначала нужен единый контракт, а уже затем — пять запусков.
◆ Учебная задача: калькулятор цены на лендинге
Возьмём одну законченную функцию: добавить на лендинг калькулятор ежемесячной цены по количеству рабочих мест. Это учебный пример, составленный вручную. Он не является результатом запуска Orca.
Перед стартом фиксируем требования:
• ввод — целое число от 1 до 100;
• места с 1-го по 10-е стоят 900 ₽ каждое;
• места с 11-го по 50-е стоят 700 ₽ каждое;
• места с 51-го по 100-е стоят 500 ₽ каждое;
• расчёт ступенчатый: новая ставка действует только на места внутри своего диапазона;
• пустое, дробное, нулевое и слишком большое значение не рассчитывается, а получает понятную ошибку;
• калькулятор работает с клавиатуры;
• данные не уходят во внешний сервис.
Чтобы агенты не истолковали формулу по-разному, добавляем шесть эталонов:
Рабочих мест | Расчёт | Итог в месяц
1 | 1 × 900 | 900 ₽
10 | 10 × 900 | 9 000 ₽
11 | 10 × 900 + 1 × 700 | 9 700 ₽
50 | 10 × 900 + 40 × 700 | 37 000 ₽
51 | 10 × 900 + 40 × 700 + 1 × 500 | 37 500 ₽
100 | 10 × 900 + 40 × 700 + 50 × 500 | 62 000 ₽
Этот блок должен быть одинаковым во всех пяти заданиях. Если агент меняет формулу или диапазон, он не предлагает «творческую альтернативу», а нарушает контракт.
◆ Пять ролей вместо пяти одинаковых просьб
Параллельный запуск полезнее, когда у веток есть разные цели и чёткие границы.
Роль | Ветка / worktree | Что разрешено менять | Что должно получиться
1. Минимальная реализация | pricing-minimal | src/features/pricing/**, точка подключения компонента | Самый короткий корректный вариант без новых зависимостей
2. Доступность и адаптивность | pricing-accessible | те же файлы в изолированной ветке | Альтернативная реализация с клавиатурной навигацией, подписями ошибок и мобильной раскладкой
3. Альтернативная архитектура | pricing-domain | модуль расчёта и компонент в своей ветке | Отделённая чистая функция расчёта и интерфейсный слой
4. Тесты и границы | pricing-tests | только tests/pricing/** и тестовые данные | Проверки шести эталонов, ошибок ввода и границ диапазонов
5. Проверка риска | pricing-review | только reviews/pricing-review.md | Чек-лист внешних запросов, зависимостей, секретов, области diff и возможных регрессий
Первые четыре роли могут начать с одной версии брифа. Пятая готовит проверку параллельно, а после появления изменений применяет её к кандидатам. Это важная граница: оценка результата всё равно зависит от готовых diff, поэтому весь процесс не становится полностью параллельным.
Ещё одна граница — агенты не меняют общие файлы без необходимости. Обновление lock-файла, конфигурации сборки или глобальных стилей резко увеличивает вероятность конфликтов. Если изменение действительно нужно, агент объясняет его отдельно, а не прячет среди сотен строк diff.
◆ Таблица принятия результата
До запуска задаём правила выбора. Тогда симпатичный интерфейс не перекроет неверную формулу.
◆ Сначала жёсткие стоп-условия
Кандидат отклоняется, если выполняется хотя бы одно условие:
• ошибается хотя бы в одном из шести контрольных расчётов;
• принимает дробное число, ноль или значение выше 100;
• не собирается или ломает существующие обязательные проверки;
• отправляет данные наружу;
• добавляет неизвестную зависимость без отдельного обоснования;
• меняет файлы за пределами согласованной области;
• содержит секрет, токен или тестовый доступ.
◆ Затем оценка прошедших вариантов
Критерий | Вес | Что считается полным баллом
Корректность | 40 | Формула и все границы совпадают с контрактом
Проверяемость | 20 | Есть понятные тесты, включая 10/11 и 50/51
Читаемость решения | 15 | Формула отделена от отображения, имена и ошибки понятны
Доступность интерфейса | 15 | Работает клавиатура, ошибка связана с полем, состояние читается без цвета
Безопасность изменения и откат | 10 | Нет внешней передачи данных, diff ограничен, изменение легко удалить
Всего | 100 | Кандидат рассматривается при результате не ниже 80
Эта таблица заполнена требованиями, а не выдуманными результатами агентов. После реального запуска в неё добавляют факты: какие тесты прошли, какие файлы изменены, какие замечания остались. Если ни один вариант не проходит стоп-условия, «победителя» нет — задача возвращается на доработку.
◆ Пять правил merge
1. Не объединять три конкурирующие реализации. Из веток pricing-minimal, pricing-accessible и pricing-domain выбирают одну основу. Смешивание всех трёх уничтожит смысл сравнения и создаст новую, никем не проверенную версию.
2. Сначала переносить тесты в выбранную ветку. Ветка pricing-tests должна проверять контракт независимо от понравившейся архитектуры. Если тесты привязаны к внутренним именам одного кандидата, их сначала исправляют.
3. Замечания из review превращать в отдельные правки. Отчёт по безопасности и области diff не сливают как код. По каждому замечанию видно: исправлено, принято как ограничение или отклонено с причиной.
4. После объединения запускать проверку заново. Зелёные тесты в двух отдельных worktree не доказывают, что их сочетание работает. Проверка нужна на итоговой ветке с фактическим набором файлов.
5. Основную ветку меняет человек или ограниченный интеграционный шаг. Агент может подготовить commit и объяснить diff. Право объединить его в основную ветку не обязано входить в полномочия каждого параллельного исполнителя.
◆ Где появляется реальная цена параллелизма
◆ Расход и лимиты
Пять независимых сеансов читают контекст и генерируют ответы отдельно. Они могут сократить календарное ожидание, но расход запросов и лимитов складывается. Если четыре агента повторяют один очевидный вариант, команда просто покупает четыре похожих ответа.
Практическое правило: запускайте несколько кандидатов там, где действительно есть выбор архитектуры или высокий риск ошибки. Переименование поля и однострочное исправление чаще выгоднее отдать одному агенту и одному проверяющему.
◆ Конфликты
Изолированные каталоги не изолируют общие решения. Два агента могут по-разному изменить схему базы, публичный интерфейс или формат ответа. Git способен слить строки без предупреждения, хотя продукт станет противоречивым.
Для таких изменений в брифе нужен один владелец контракта. Миграции, lock-файлы и общие конфигурации лучше вынести в отдельный последовательный этап.
◆ Безопасность
Open source и MIT-лицензия не заменяют аудит. Coding-агент может запускать команды, читать доступные файлы, устанавливать пакеты и обращаться в сеть в пределах выданных ему прав. Пять worktree на одной машине также не означают пять изолированных контуров доступа.
Минимальный набор мер:
• не выдавать production-токены и платёжные ключи;
• использовать отдельные тестовые данные;
• ограничить допустимые каталоги и команды;
• проверять новые зависимости и install-скрипты;
• читать итоговый diff до merge;
• считать внешние действия отдельным разрешением, а не частью задания «почини функцию».
◆ Когда один агент разумнее пяти
Параллельная схема не нужна, если:
• результат заранее однозначен и изменение маленькое;
• нет автоматической проверки и человек не успеет сравнить варианты;
• ветки неизбежно меняют одну миграцию или один общий конфиг;
• стоимость пяти запусков выше цены ошибки;
• у команды нет человека, который отвечает за итоговый контракт и merge.
В таком случае последовательность «один агент пишет — второй проверяет» даст более понятный результат. Пять исполнителей полезны только тогда, когда различия между решениями можно измерить.
◆ Что сделать перед первым параллельным запуском
Возьмите одну функцию и подготовьте четыре вещи: неизменный бриф, эталонные примеры, границы файлов для каждой ветки и таблицу стоп-условий. Затем решите заранее, какие ветки конкурируют, а какие дополняют победителя. После этого worktree действительно становится инструментом управления: варианты разделены, причины выбора видны, а основная ветка получает один проверенный результат.
Какая часть параллельной работы coding-агентов для вас сложнее: написать общий контракт, сравнить варианты или безопасно объединить выбранный diff? В следующем разборе можно отдельно показать, как построить независимые тесты, которые не подыгрывают архитектуре одного агента.