Симптом: несколько задач запущены одновременно, но агенты меняют одни и те же файлы, а итоговое слияние превращается в ручной ремонт.
Самое быстрое решение: начните с двух низкосвязанных задач, назначьте каждой отдельную ветку или Git worktree, заранее ограничьте права и критерии готовности, а затем объединяйте изменения только после тестов и человеческого ревью.
Последнее обновление: 28 июля 2026 года. Проверка выполнена по актуальной документации GitHub о сессиях агентов, рабочих деревьях, режимах выполнения и облачных песочницах.
Эта статья предназначена для вас, если вы регулярно переключаетесь между несколькими Issue, поддерживаете несколько репозиториев или хотите выделить для агентов отдельную вычислительную среду. Она также пригодится платформенным командам, которые оценивают, где запускать долгие тесты и сборки.
Базовая схема параллельной работы
GitHub Copilot App поддерживает изолированные Agent Sessions. Для каждой сессии можно выбрать отдельную ветку, рабочее дерево или облачную песочницу, а также настроить режим взаимодействия, модель и уровень рассуждений. Это позволяет вести несколько потоков разработки одновременно, но изоляция файлов сама по себе не устраняет логические зависимости между задачами. (документация GitHub о работе с Agent Sessions)
Вам нужно разделять не «агентов вообще», а законченные рабочие единицы. Хорошая единица имеет:
- один измеримый результат;
- понятный набор входных файлов;
- список файлов, которые нельзя менять;
- отдельную проверку;
- назначенного человека, который принимает решение по PR;
- понятное условие остановки, если агент выходит за границы задачи.
Например, обновление README и добавление независимого набора тестов обычно подходят для первого запуска. Одновременная переработка маршрутизации, схемы базы данных и слоя авторизации — плохой эксперимент: даже при отдельных ветках агенты будут принимать решения на основе несовместимых предположений.
Два первых задания
Для первой проверки настройте две сессии:
| Сессия | Задача | Граница изменений | Критерий готовности |
|---|---|---|---|
| A | Обновить документацию API | Только Markdown и примеры запросов | Ссылки проверены, команды соответствуют текущему интерфейсу |
| B | Добавить независимые тесты | Только каталог тестов и тестовые фикстуры | Тесты проходят, рабочий код не изменён |
В каждой инструкции явно укажите название ветки, допустимые каталоги, команды проверки и формат отчёта. Попросите агента в конце вывести изменённые файлы, выполненные тесты, нерешённые вопросы и возможные риски. Такой отчёт важнее красивого описания результата: по нему вы быстро поймёте, не вышла ли сессия за пределы задачи.
Не начинайте с большого числа потоков. Если две сессии уже создают очередь на ревью, конфликтуют за общие фикстуры или требуют ручного исправления после каждого запуска, дальнейшее масштабирование только увеличит задержку.
Одновременный запуск нескольких Agent Sessions
Запуск в GitHub Copilot App выполняется через создание новой сессии рядом с разделом Sessions. Затем вы выбираете проект, место исполнения, режим, модель и уровень рассуждений. Доступны локальный репозиторий, новое рабочее дерево и облачная песочница; каждая полноценная сессия работает в изолированном рабочем пространстве. (официальная последовательность запуска сессии)
Рабочая последовательность выглядит так:
- Зафиксируйте исходное состояние репозитория и убедитесь, что локальные изменения либо сохранены, либо явно переданы в задачу.
- Создайте первую сессию для задачи A и выберите отдельную ветку или новое рабочее дерево.
- Вставьте инструкцию с входными файлами, запретами, командами тестирования и ожидаемым результатом.
- Создайте вторую сессию для задачи B, не копируя ей полномочия и область изменения первой.
- После завершения каждой сессии проверьте diff, историю коммитов, тесты и список нерешённых рисков.
- Откройте PR или подготовьте изменения к PR только после того, как результат прошёл независимую проверку.
Для первой пары лучше использовать режим Plan или Interactive. В Plan агент сначала формирует план, который вы проверяете до внесения изменений. В Interactive агент предлагает действия и ждёт вашего участия. Autopilot оставьте для хорошо описанных и обратимых задач: например, для добавления тестов, исправления локальной ошибки сборки или обновления повторяющихся документов. Различия между режимами описаны в руководстве GitHub о сессиях приложения.
| Режим | Когда выбирать | Что должен делать человек | Когда остановить сессию |
|---|---|---|---|
| Interactive | Неясные требования, исследование неизвестного кода | Подтверждать направление и спорные изменения | Агент начинает предлагать изменения вне согласованной области |
| Plan | Задача понятна, но затрагивает несколько компонентов | Проверить план, зависимости и порядок шагов | В плане появились миграции, новые права или незаявленные зависимости |
| Autopilot | Обратимая задача с однозначными тестами | Контролировать разрешения и итоговый diff | Тесты не проходят после нескольких итераций или агент меняет контракт |
Выбор модели также должен зависеть от задачи, а не от желания назначить одну модель всем сессиям. Для простого обновления документации важнее следование формату и аккуратная работа с файлами. Для изменения нескольких связанных модулей важнее способность удерживать контекст и объяснять влияние на интерфейсы. Если в приложении включён автоматический выбор, он может подбирать модель с учётом сложности задачи; при необходимости вы можете выбрать модель вручную.
Конфликт изменений в одном репозитории
Отдельная ветка или Git worktree снижают вероятность физического конфликта файлов: одна сессия не должна перезаписывать незакоммиченные изменения другой. Но они не предотвращают логический конфликт. Два агента могут изменить разные файлы и всё равно сломать один и тот же API, формат данных, контракт тестов или порядок запуска миграций.
Перед параллельным запуском распределите ответственность по слоям:
- один агент меняет публичный интерфейс, второй только добавляет тесты;
- один агент работает с документацией, второй — с реализацией;
- один агент обновляет зависимость, остальные не трогают lock-файл;
- общий конфигурационный файл назначается только одной сессии;
- изменения схемы данных выполняются последовательно, даже если другие задачи независимы.
Сделайте коммиты небольшими и тематическими. Коммит «исправить всё после тестов» усложняет ревью и не показывает, какая часть изменения была необходима. Для каждой сессии полезно заранее задать формат:
Цель:
Допустимые каталоги:
Запрещённые файлы:
Команды проверки:
Ожидаемый результат:
Не выполнять:
Остановиться, если:
Останавливайте параллельную работу, если два агента начинают менять общий контракт, один из них добавляет временное решение, которое второй должен учитывать, или тесты требуют общего набора фикстур. В этот момент последовательная работа быстрее: сначала завершите изменение контракта, затем передайте обновлённую ветку следующей сессии.
Рабочее дерево и облачная песочница
Git worktree подходит, когда вам нужно видеть файлы рядом с локальным проектом, запускать привычные команды и использовать установленные инструменты. Это хороший выбор для коротких исправлений, локального отладки и задач, где вы должны быстро открыть результат в установленной среде.
Облачная песочница подходит для изолированного выполнения, продолжения сессии с другого устройства и параллельных задач, которые не должны занимать локальную среду. Документация GitHub указывает, что облачные и локальные песочницы находятся в публичной предварительной версии, поэтому интерфейс, политики и доступность функций могут меняться. (описание облачных и локальных песочниц)
| Условие задачи | Рабочее дерево | Облачная песочница |
|---|---|---|
| Нужна локальная IDE и отладчик | Предпочтительный вариант | Не первый выбор |
| Нужно запускать несколько независимых задач без нагрузки на локальную систему | Подходит при достаточных ресурсах | Предпочтительный вариант |
| Нужны macOS, Xcode или локальные системные инструменты | Выбирайте контролируемый Mac | Не предполагайте совместимость |
| Требуется продолжить сессию на другом устройстве | Неудобно без подготовки среды | Естественный сценарий |
| Репозиторий содержит чувствительные данные | Проверяйте политики и права | Сначала подтвердите разрешение организации |
| Зависимости требуют нестандартного локального окружения | Обычно проще | Возможны ограничения среды |
Если задача требует macOS или Xcode, Linux-подобная облачная среда не должна считаться полноценной заменой. Это особенно важно для сборки приложений Apple, запуска симуляторов, проверки системных фреймворков и сценариев, завязанных на локальные сертификаты. В таком случае выделите задачу на контролируемый Mac и ограничьте сессию только необходимыми репозиториями и секретами.
Локальные ресурсы нужны не столько для «самого агента», сколько для рабочей директории, индексации, установки зависимостей, тестов и сборки. Если два параллельных задания одновременно компилируют проект, запускают браузерные тесты или создают крупные артефакты, узким местом становятся память, процессор, диск и пропускная способность локальной среды. Точного универсального объёма ресурсов нет: он определяется стеком, размером репозитория и командами, которые вы разрешили выполнять.
Используйте такую развилку:
- Если задача короткая, требует локальной IDE и не запускает тяжёлую сборку — выбирайте Git worktree.
- Если нужно продолжить работу с другого устройства или разгрузить локальный компьютер — рассматривайте облачную песочницу.
- Если необходимы macOS-инструменты — используйте контролируемый Mac.
- Если сессия изменяет чувствительные данные, устанавливает неизвестные скрипты или работает с ключами — сначала оставьте Interactive или Plan.
- Если тесты и сборки постоянно конкурируют за ресурсы — остановите параллельность и перенесите долгий поток в отдельную среду.
- Если организация ещё не разрешила облачные песочницы — не обходите политику, а согласуйте доступ с владельцем среды.
Межрепозиторные зависимости
Параллельная работа с несколькими репозиториями требует отдельного плана. Нельзя просто поручить одному агенту изменить основной проект, второму — библиотеку, а затем ожидать, что порядок публикации определится автоматически.
Сначала зафиксируйте контракт: имя пакета, версию, публичные типы, формат ответа или команды совместимости. Затем определите, какой репозиторий является источником изменения. Если библиотека должна изменить интерфейс, её ветка и тесты должны быть готовы до обновления основного проекта. Если основной проект лишь адаптируется к уже опубликованному интерфейсу, его можно вести параллельно, но версия зависимости должна быть зафиксирована.
Перед запуском проверьте:
- каким способом каждый репозиторий клонируется;
- есть ли доступ к приватным зависимостям;
- где хранятся токены и как они передаются процессу;
- может ли тестовый скрипт отправлять данные во внешние сервисы;
- какая версия SDK или компилятора требуется;
- кто подтверждает публикацию изменённой зависимости.
Для сессии, которая видит несколько приватных репозиториев, используйте минимальные права. Не выдавайте доступ ко всей организации, если задача требует только основной проект и одну библиотеку. Не помещайте секреты в промпт, коммиты, логи или временные файлы. Если агент просит разрешение на неизвестный установочный скрипт, остановите сессию и сначала проверьте содержимое команды.
Долгие тесты и сборки
Долгая задача должна иметь промежуточные контрольные точки. В инструкции укажите, что агент обязан:
- сначала проверить окружение;
- затем выполнить быстрый набор тестов;
- только после этого запускать полную сборку;
- сохранить краткий результат каждой стадии;
- остановиться при изменении входных условий.
Так вы отличите ошибку кода от ошибки окружения. Если агент сразу запускает полный конвейер, а затем сообщает только о неудаче, вам придётся повторно восстанавливать контекст вручную.
Для локальной сессии заранее решите, можно ли ей устанавливать зависимости, менять системные настройки и обращаться к сети. Для облачной среды проверьте политики организации и сохранение состояния. Официальная документация описывает состояния облачной сессии как активное, остановленное и удалённое: остановленная сессия сохраняет состояние для продолжения, а удалённая теряет окружение и сохранённые данные. (состояния облачных и локальных песочниц)
Не оставляйте долгую сессию в Autopilot только потому, что она «уже почти закончила». Укажите условие остановки: несколько последовательных неудачных тестов, изменение публичного контракта, попытка установить новый инструмент или обнаружение отсутствующего доступа. Скорость без точки остановки превращается в накопление непроверенных изменений.
Права и высокоавтономные режимы
Вопрос не в том, может ли агент выполнить команду, а в том, должен ли он иметь право выполнить её без дополнительного подтверждения. Для документации и независимых тестов можно разрешить больше действий внутри ограниченного каталога. Для публикации, миграции базы данных, работы с секретами и неизвестных скриптов контроль должен оставаться ручным.
Для рискованных задач применяйте последовательность:
- Interactive — исследование и уточнение требований;
- Plan — фиксация плана, затронутых файлов и зависимостей;
- ручная проверка разрешений;
- выполнение ограниченного шага;
- проверка тестами и diff;
- только затем переход к следующему действию.
Autopilot уместен, когда задача хорошо описана, обратима и имеет проверяемый результат. Документация GitHub отдельно отмечает, что автономный режим может выполнять последовательные действия без постоянного ожидания пользователя, поэтому ограничения разрешений и лимит продолжений становятся частью безопасности, а не просто настройкой удобства. (руководство по Autopilot)
Не используйте высокую автономность для:
- миграций в рабочей базе;
- публикации пакетов;
- изменения правил доступа;
- операций с ключами и токенами;
- неизвестных установочных скриптов;
- удаления или массового перемещения файлов;
- изменений, которые невозможно быстро откатить.
PR, проверка и остановка параллельности
Каждая сессия должна завершаться не фразой «готово», а проверяемым комплектом:
- ссылка или идентификатор ветки;
- список изменённых файлов;
- описание принятого решения;
- команды и результаты тестов;
- известные ограничения;
- вопросы для ревьюера;
- предложение по порядку слияния.
Сначала принимайте изменения, которые создают основу для остальных. Если один PR меняет публичный контракт, а другой адаптирует клиента, первым обычно проверяется контракт. Если один PR добавляет документацию, а другой меняет реализацию, документацию лучше просматривать после подтверждения фактического поведения.
Оценивайте стратегию не количеством запущенных агентов, а результатом:
- сколько раз возникал конфликт;
- какие причины приводили к доработке;
- сколько времени занимало человеческое ревью;
- сколько тестов пришлось перезапустить;
- сколько изменений пришлось отклонить;
- сколько задач завершилось без расширения области.
Параллельность следует остановить, если стоимость ревью выше времени последовательной реализации, если агенты начинают спорить через несовместимые изменения или если вы не можете быстро определить владельца каждого результата. Один хорошо принятый PR лучше нескольких сессий, которые оставили после себя общий нестабильный слой.
После первого двойного запуска вернитесь к собственной среде и измерьте, что именно стало ограничением: локальные ресурсы, тестовая инфраструктура, доступ к приватным репозиториям, macOS-сборка или время ревью. Если проблема только в переключении окон, менять инфраструктуру не нужно. Если долгие сборки блокируют рабочую машину, можно изучить варианты удалённой среды в разделе настройки заказа Mac. Общую информацию о доступных сценариях Macstripe можно посмотреть на главной странице сервиса.
На практике текущий локальный вариант часто проигрывает не из-за самого GitHub Copilot App, а из-за трёх ограничений: одна машина одновременно конкурирует за процессор и память, окружение трудно воспроизвести для всей команды, а macOS-сборки нельзя надёжно заменить произвольной Linux-песочницей. Поэтому аренда Macstripe имеет смысл как временная выделенная среда для долгих сборок, тестов и параллельных Mac-задач — но только после того, как вы подтвердили необходимость такой среды на двух низкосвязанных сессиях. Если же ваши задачи короткие, локальные и не требуют macOS, отдельная аренда будет лишней: сначала используйте Git worktree и строгие границы Agent Sessions.
