Claude Code: несколько AI-агентов — полный процесс

Симптом знакомый: две сессии Claude Code одновременно меняют один репозиторий, после чего исправление одной задачи исчезает, тесты начинают падать, а причина конфликта обнаруживается только при слиянии.

Быстрое решение такое: для исследования используйте subagents, для параллельного редактирования — отдельный worktree на каждую задачу, для нескольких полноценных сессий — единый диспетчер agent view или ручную координацию. Надёжный рабочий процесс состоит из четырёх уровней: декомпозиция, изоляция, автоматическая проверка и ручное слияние. Официальная документация Claude Code отдельно различает subagents, agent view, agent teams и worktree, потому что они решают разные проблемы. Сравнение режимов параллельной работы в официальной документации Claude Code

Эта статья предназначена для разработчиков, уже работающих с Claude Code в терминале, руководителей, которым нужно одновременно вести функциональность, тесты и документацию, а также инженеров, планирующих запуск нескольких сессий на удалённом Mac. Если требуется только один короткий запрос к коду, описанная схема будет избыточной.

Важно: контекстная изоляция subagent и файловая изоляция worktree — не одно и то же. Первый ограничивает рабочую память исполнителя, второй разделяет каталоги и ветки Git. Для безопасного параллельного редактирования нужны оба уровня либо полноценные отдельные сессии в worktree.

Выбор режима параллельной работы

Перед запуском нескольких исполнителей нужно определить, что именно должно выполняться одновременно.

Subagents подходят для побочных задач, результатом которых становится отчёт, список найденных файлов или набор рекомендаций. Например, основной сеанс может продолжать исправлять обработчик запросов, пока отдельный subagent:

• ищет все места использования устаревшего API;
• анализирует логи падения;
• составляет список тестовых сценариев;
• проверяет потенциальные уязвимости;
• изучает структуру незнакомого модуля.

Такой исполнитель получает собственный контекст и возвращает основной сессии сводку. Он не должен заново пересказывать всю историю проекта или копировать большие фрагменты исходного кода. В задании полезно заранее указать цель, допустимые каталоги и формат ответа: например, «вернуть пять проблем, путь к файлу, уровень риска и конкретную рекомендацию». Описание subagents и их изолированного контекста

Agent teams нужны, когда несколько самостоятельных сессий должны обмениваться сообщениями, видеть общий список задач и работать как группа. В официальной модели есть руководящая сессия, отдельные исполнители, общий список задач и почтовый механизм сообщений. Такой режим удобен для независимой реализации функций, конкурентной проверки гипотез или одновременного аудита разных частей проекта. Однако каждая дополнительная сессия имеет собственный контекст, поэтому расход токенов растёт вместе с числом активных исполнителей. Архитектура agent teams

Agent view — это диспетчерская панель для фоновых сессий. Через claude agents разработчик может запускать, наблюдать, приостанавливать и открывать отдельные разговоры из одного интерфейса. Этот режим решает проблему управления, но сам по себе не гарантирует защиту файлов: если несколько сессий работают в одном каталоге, конфликт всё ещё возможен. Работа с несколькими сессиями через agent view

Worktree — основной выбор для параллельного редактирования. Каждая сессия получает отдельный каталог и ветку, а история Git и удалённый репозиторий остаются общими. Поэтому изменения физически не перезаписывают друг друга, но при слиянии всё равно могут возникнуть логические или текстовые конфликты.

Границы задач и владельцы файлов

Большинство проблем начинается не с команды запуска, а с плохого разбиения задачи. Формулировка «сделайте авторизацию, тесты и документацию» слишком широкая: разные исполнители могут изменить одну схему данных, один интерфейс или один lock-файл, не зная о действиях друг друга.

Перед запуском полезно составить карту владения:

• Agent A изменяет серверный модуль и его локальные тесты.
• Agent B работает только с клиентским экраном и фикстурами интерфейса.
• Agent C пишет документацию, примеры и сценарии запуска.
• Agent D анализирует ошибки и не меняет исходные файлы.

У каждой задачи должны быть четыре обязательных поля:

1. Цель — какой пользовательский или технический результат требуется.
2. Граница файлов — какие каталоги разрешено читать и изменять.
3. Зависимости — какие интерфейсы, схемы или команды должны существовать заранее.
4. Критерий приёмки — какая проверка покажет, что задача действительно завершена.

Особое внимание нужно уделять четырём категориям файлов:

• общие интерфейсы и типы;
• миграции базы данных;
• файлы блокировки зависимостей;
• генерируемый код и схемы.

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

Изоляция через Claude Code worktree

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

claude --worktree feature-auth

В другом терминале запускается независимая задача:

claude --worktree api-tests

Каждый вызов создаёт собственный рабочий каталог и ветку. Название лучше связывать с задачей, а не оставлять случайным: так проще сопоставить логи, результаты тестов и будущие запросы на слияние. Git описывает worktree как несколько рабочих деревьев, связанных с одним репозиторием; отдельное дерево имеет собственное состояние файлов, но использует общую историю. Справочник Git по команде worktree

Для контроля состояния используются обычные команды:

git worktree list
git status
git branch --show-current

В основной копии проекта каталог .claude/worktrees/ следует добавить в .gitignore, чтобы временные каталоги не попадали в список незатреканных файлов. Если в основном каталоге есть локальные .env или другие игнорируемые настройки, новый worktree не получает их автоматически. Для этого Claude Code поддерживает файл .worktreeinclude, где можно перечислить разрешённые шаблоны. Секреты при этом не следует коммитить и тем более передавать в промпте.

Безопасная проверка перед запуском:

• [ ] каталог является Git-репозиторием;
• [ ] рабочая область Claude Code уже подтверждена;
• [ ] .claude/worktrees/ исключён из отслеживания;
• [ ] для каждой задачи назначено уникальное имя worktree;
• [ ] локальные настройки передаются через безопасный механизм;
• [ ] секреты не записываются в Git и команды оболочки;
• [ ] для удалённого окружения существует повторяемый скрипт установки зависимостей.

Контекст subagents и качество задания

Subagents экономят основной контекст только тогда, когда им не поручают «разобраться во всём проекте». Плохо заданная задача приводит к повторному чтению репозитория, длинному отчёту и необходимости вручную отделять полезные сведения от шума.

Рабочее задание можно оформлять так:

Цель: найти причины падения тестов авторизации.
Границы: только src/auth, tests/auth и конфигурация тестового запуска.
Не изменять файлы.
Проверить: последние сообщения сборки и все вызовы функции validateToken.
Формат ответа:
1) файл и строка;
2) вероятная причина;
3) подтверждающее наблюдение;
4) минимальное исправление;
5) тест, который должен подтвердить результат.

Для исследовательских задач полезен режим plan или эквивалентный режим без записи. Для исправлений, которые должны выполняться в фоне, нужно заранее убедиться, что разрешения уже выданы: фоновые subagents не могут нормально остановиться для каждого отдельного вопроса доступа. Режим разрешений родительской сессии может наследоваться дочерними исполнителями; бездумное использование полного обхода подтверждений расширяет область потенциального ущерба.

Практическая схема выглядит так:

1. Главная сессия формулирует вопрос.
2. Subagent получает только необходимые каталоги и критерии.
3. Исполнитель возвращает структурированный отчёт.
4. Главная сессия принимает решение и только затем запускает кодовые изменения.
5. Изменения выполняются в отдельной ветке или worktree.

Так исследовательская работа не заполняет основной диалог логами, трассировками и повторными чтениями файлов.

Среда, зависимости и переменные

Каждый worktree — это новый рабочий каталог, поэтому зависимости нельзя считать общими только потому, что репозиторий один. Один Agent может установить новую версию пакета, другой — запускать тесты со старым кэшем, а третий — не иметь локального инструмента генерации кода. Итогом становится расхождение, которое ошибочно принимают за проблему исходного кода.

Для повторяемой среды нужны:

• фиксированная команда установки зависимостей;
• скрипт подготовки базы или тестовых данных;
• проверка версий компилятора и пакетного менеджера;
• единая команда линтинга и тестов;
• явное описание обязательных переменных окружения;
• очистка временных процессов после завершения задачи.

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

Некоторые ограничения можно проверять количественно. В справочнике переменных Claude Code указано, что стандартный тайм-аут длительных команд оболочки составляет 120 000 миллисекунд, а максимальный тайм-аут, который модель может запросить для команды, — 600 000 миллисекунд. Это не гарантия завершения сборки: если проекту регулярно требуется больше времени, команда должна быть разбита, вынесена в отдельный скрипт или контролироваться внешним процессом. Справочник переменных среды Claude Code

Автоматическое сжатие контекста также не заменяет декомпозицию: официальная справка указывает приблизительный порог около 95 % заполнения, после которого запускается compacting. Чем больше параллельных исследовательских задач возвращают необработанный текст, тем раньше основная сессия теряет удобную историю решений. Поэтому структурированный итог важнее длинного протокола.

Для удалённого Mac следует дополнительно проверить:

• доступность SSH и способ восстановления сессии;
• свободное место под несколько рабочих каталогов;
• возможность одновременно запускать сборку, тесты и индексатор;
• наличие одинаковых версий SDK и пакетного менеджера;
• очистку процессов после завершения Agent;
• правила хранения .env, токенов и SSH-ключей.

Не следует помещать секреты в общий файл, доступный всем сессиям, если конкретная задача их не использует. Лучше выдавать минимальный набор переменных на время выполнения и отзывать его после завершения.

Проверка результата и приёмка

Фраза Agent «задача выполнена» не является доказательством. Каждый исполнитель должен завершать работу коротким отчётом:

• какие файлы изменены;
• какие команды проверки выполнены;
• какие тесты прошли и какие не запускались;
• какие ограничения остались;
• как откатить изменение;
• есть ли миграции, новые переменные или ручные действия.

Минимальный набор команд после изменения может выглядеть так:

git diff --check
git status --short
npm test
npm run build

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

Центральная сессия должна принимать результат по артефактам, а не по уверенности формулировок. Удобно ввести единый шаблон:

Статус: готово / частично готово / заблокировано
Изменения: ...
Проверки: команда — результат
Известные ограничения: ...
Риск слияния: низкий / средний / высокий
Откат: ...

Если тесты не запускаются из-за отсутствующей зависимости или переменной окружения, статус должен быть «частично готово», а не «готово». Это особенно важно для удалённых Mac, где несколько сессий могут одновременно использовать ограниченные ресурсы сборки.

Для единой приёмки полезно разделить проверки на три уровня:

1. Локальный уровень — форматирование, линтинг, модульные тесты.
2. Интеграционный уровень — взаимодействие изменённого модуля с соседними компонентами.
3. Предрелизный уровень — сборка, миграции, основные пользовательские сценарии и проверка отката.

Agent может выполнить первый уровень, но решение о слиянии должно учитывать все три, если задача затрагивает общий интерфейс или инфраструктуру.

Слияние и восстановление после конфликта

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

Перед объединением каждой ветки следует проверить:

• [ ] ветка основана на актуальном состоянии целевой ветки;
• [ ] локальные тесты выполнены после последнего коммита;
• [ ] изменённые файлы не пересекаются с незавершённой задачей;
• [ ] миграции и lock-файлы просмотрены вручную;
• [ ] итоговый патч не содержит секретов и временных файлов;
• [ ] есть понятный способ отката.

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

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

git merge --abort
git fetch --all
git rebase origin/main

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

git worktree list
git worktree remove ../путь-к-worktree
git worktree prune

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

Контроль длительности и ресурсов

Параллельность не должна означать бесконечное число активных сессий. Для каждого Agent заранее задаются:

• условие остановки;
• максимально допустимое число повторных попыток;
• срок, после которого требуется ручное решение;
• команда проверки прогресса;
• правило освобождения worktree и фоновых процессов.

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

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

Практическая проверка перед длительным запуском:

• [ ] определено число активных сессий;
• [ ] для каждой задачи назначен рабочий каталог;
• [ ] известна примерная длительность сборки;
• [ ] есть запас диска под зависимости и артефакты;
• [ ] настроено удалённое подключение;
• [ ] есть план остановки зависших процессов;
• [ ] после завершения предусмотрена очистка.

Условия выбора режима

Решение можно принимать по следующей схеме:

• Если задача только исследовательская и должна вернуть отчёт, выбирается subagent. Если требуется изменение файлов, задача переводится в отдельный worktree.
• Если несколько исполнителей должны обмениваться статусами и зависимостями, выбираются agent teams. Если обмен не нужен, отдельные worktree обычно проще контролировать.
• Если требуется наблюдать много фоновых сессий из одного терминала, выбирается agent view. Но для записи кода каждому исполнителю всё равно назначается отдельная файловая область.
• Если задачи затрагивают одни и те же интерфейсы или миграции, параллельность сокращается: один Agent получает право изменения общего файла, остальные работают с опубликованным результатом.
• Если сборка длительная, а сессий несколько, сначала проверяется локальный запас CPU, памяти, диска и времени непрерывной работы; при нехватке ресурсов задача переносится на удалённый Mac или разбивается на меньшие этапы.
• Если результат нельзя проверить автоматической командой, вводится обязательная ручная приёмка до слияния, а не после публикации.

Такой подход предотвращает типичную ошибку: попытку решить проблему управления задачами только увеличением числа Agent.

Частые вопросы

Как одновременно запустить несколько Agent в Claude Code?

Для фоновых задач внутри одной сессии подходят subagents, а для отдельных полноценных сессий — agent view через команду claude agents или запуск claude --bg. Если параллельные исполнители должны менять код, каждому нужно назначить отдельный worktree. Перед стартом следует явно описать границы файлов, ожидаемый результат и команду проверки.

Чем subagents отличаются от worktree в Claude Code?

Subagent изолирует контекст разговора и возвращает основной сессии результат, поэтому хорошо подходит для анализа логов, поиска по репозиторию и проверки гипотез. Worktree изолирует файловое состояние и ветку Git. Это разные уровни защиты: subagent не заменяет worktree, если исполнитель должен создавать или изменять код параллельно.

Как избежать конфликтов файлов в нескольких сессиях Claude Code?

Нужно заранее разделить владельцев файлов и запускать кодовые задачи в отдельных worktree. Файлы с общими интерфейсами, миграциями, lock-файлами и генерируемым кодом не следует одновременно редактировать нескольким агентам. После каждого слияния необходимо запускать тесты, а не объединять все ветки одной большой операцией в конце.

Может ли Agent в Claude Code работать в отдельной ветке?

Да. Сессия, запущенная с --worktree, получает отдельный рабочий каталог и ветку, но использует ту же историю репозитория. Subagent также можно настроить с isolation: worktree. Поэтому ветка защищает от прямого перезаписывания файлов, однако не отменяет проверки совместимости и обычной процедуры слияния.

Что нужно для удалённого запуска нескольких Claude Code?

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

Когда переносить параллельную работу на удалённый Mac

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

Если команде требуется временная среда для параллельных Claude Code-сессий, разумнее сначала оценить длительность задач и число одновременных worktree, а затем рассмотреть аренду Mac для удалённой разработки. Перед выбором стоит также проверить доступные варианты аренды Mac mini и сопоставить их с требованиями к сборке, сетевому доступу и постоянству окружения. Такой вариант не заменяет собственный Mac для непрерывной тяжёлой работы или задач, требующих физических интерфейсов, но для временного тестового стенда и контролируемого числа параллельных сессий он позволяет не держать локальное оборудование занятым круглосуточно.

Последнее обновление: 13 августа 2026 года. Команды, параметры изоляции и поведение очистки сверены с официальной документацией Claude Code и Git в день публикации.

FAQ

Как одновременно запустить несколько Agent в Claude Code?

Для фоновых задач внутри одной сессии подходят subagents, а для отдельных полноценных сессий — agent view через команду `claude agents` или запуск `claude --bg`. Если параллельные исполнители должны менять код, каждому нужно назначить отдельный worktree. Перед стартом следует явно описать границы файлов, ожидаемый результат и команду проверки.

Чем subagents отличаются от worktree в Claude Code?

Subagent изолирует контекст разговора и возвращает основной сессии результат, поэтому хорошо подходит для анализа логов, поиска по репозиторию и проверки гипотез. Worktree изолирует файловое состояние и ветку Git. Это разные уровни защиты: subagent не заменяет worktree, если исполнитель должен создавать или изменять код параллельно.

Как избежать конфликтов файлов в нескольких сессиях Claude Code?

Нужно заранее разделить владельцев файлов и запускать кодовые задачи в отдельных worktree. Файлы с общими интерфейсами, миграциями, lock-файлами и генерируемым кодом не следует одновременно редактировать нескольким агентам. После каждого слияния необходимо запускать тесты, а не объединять все ветки одной большой операцией в конце.

Может ли Agent в Claude Code работать в отдельной ветке?

Да. Сессия, запущенная с `--worktree`, получает отдельный рабочий каталог и ветку, но использует ту же историю репозитория. Subagent также можно настроить с `isolation: worktree`. Поэтому ветка защищает от прямого перезаписывания файлов, однако не отменяет проверки совместимости и обычной процедуры слияния.

Что нужно для удалённого запуска нескольких Claude Code?

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

Читать также

• Сравнение подходов к оркестрации многоагентных систем
• Изоляция рабочей области и файловая система для AI-агентов
• Трёхслойная память агента между проектами и сессиями