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

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

Субагент — отдельный помощник, которому основная сессия передаёт ограниченную часть работы. У него собственный контекст, инструкции и доступные инструменты. После выполнения он возвращает результат. Конкретные способы передачи контекста и ограничения зависят от продукта и настройки; их стоит посмотреть до запуска.

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

Где появляется экономия времени

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

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

Практический вопрос перед делением: «Какой конкретный файл или отчёт вернёт каждый исполнитель и что ему потребуется для старта?» Если ответ размытый, основному агенту полезнее сначала выполнить короткое исследование самому.

Четыре рабочих схемы

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

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

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

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

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

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

Основной агент сначала смотрит устройство проекта. Он выясняет, что расчёт скидки находится в discount.ts, форматирование — в money.ts, сообщения — в validation.ts. Общий компонент формы использует все три функции. Проверки отдельных функций можно раздать, а изменение общей формы оставить координатору.

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

Результат планирования удобно представить небольшой таблицей:

Исполнитель	Область владения	Проверка
Агент 1	Тесты discount.ts	Нулевая скидка, предел, округление
Агент 2	Тесты money.ts	Ноль, дробная сумма, большие значения
Координатор	Общая форма и итоговая сборка	Полный расчёт и отображение результата

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

Как написать самостоятельное задание

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

Твоя задача — проверить расчёт скидки в калькуляторе. Владеешь только tests/discount.test.ts. Прочитай src/discount.ts и существующие примеры тестов. Покрой нулевую скидку, согласованный максимум и округление итоговой суммы. Основной код и настройки тестов не меняй. Ты работаешь рядом с другими исполнителями: сохраняй их изменения. Если обнаружишь дефект, верни доказательство и остановись перед правкой общего кода. Сдай список сценариев, изменённый файл, команду проверки и её результат.

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

Изоляция файлов и worktree

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

Для изменений с более широким воздействием полезен Git worktree: отдельный рабочий каталог того же репозитория. У каждого исполнителя может быть собственная ветка и набор файлов. После завершения координатор переносит согласованные коммиты и проверяет совмещённый результат.

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

Запуск через терминал

Неинтерактивный режим Claude Code с флагом -p позволяет передать запрос и получить результат. Его актуальные параметры описаны в CLI reference. Для первого опыта выберите чтение и анализ без правок:

claude -p "Прочитай src/discount.ts. Верни сценарии проверки скидки. Файлы не меняй." > discount-report.txt &
claude -p "Прочитай src/money.ts. Верни сценарии проверки цены. Файлы не меняй." > money-report.txt &
wait

Пример запускается из корня учебного проекта. & отправляет процесс в фон, wait ожидает завершения фоновых задач. Имена отчётов должны быть свободны: перенаправление > перезаписывает существующий файл. После ожидания прочитайте оба результата и проверьте сообщения об ошибках; ожидание само по себе не подтверждает успешность работы каждого процесса.

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

Как собрать результат

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

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

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

Стоимость и типичные ошибки

Расход зависит от объёма входного контекста, длительности работы, модели, повторных попыток и интеграции. Пять агентов могут стоить как больше, так и меньше условного пятикратного запуска: простого постоянного множителя здесь нет. Полезно сравнивать измеренный расход на одинаково принятый результат.

Измеряйте время от начала до общей проверки, число конфликтов, количество переделок и фактическую стоимость, если она доступна. Для честного сравнения последовательного и параллельного подхода используйте одинаковую исходную версию и критерии качества. Повторная работа по уже готовому решению исказит эксперимент.

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

Начните с двух независимых проверок. Завершите их общей проверкой пользовательского пути и только после этого оценивайте экономию. Если передача и сборка результатов занимают большую часть времени, уменьшите число участников или объедините связанные части в одну задачу.