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

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

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

Субагенты: параллелизм через изоляцию

Субагент — это специализированный экземпляр Claude, работающий в собственном изолированном контекстном окне. Ментальная модель: представьте, что вы руководитель исследовательской группы. Вы не читаете все первичные источники сами. Вы делегируете фокусные вопросы исследователям, те возвращаются с дистиллированными выводами, а вы синтезируете все в целостный результат. Точно так работают субагенты.

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

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

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

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

Главное отличие от субагентов — прямая коммуникация между участниками. Агенты могут обмениваться сообщениями, делиться находками, сигнализировать блокировки и негоциировать без маршрутизации через лидера. Агент фронтенда может сказать агенту бэкенда: «Структура ответа API должна измениться» — и бэкенд перестраивается без ждания лидера.

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

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

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

Prompt chaining — последовательные шаги, где каждый вызов обрабатывает вывод предыдущего. Используйте, когда порядок важен и шаги зависят друг от друга. Routing — классификатор решает, какому специализированному обработчику достается задача. Простые вопросы идут на бюджетные быстрые модели, сложные — на мощные. Так контролируются расходы. Parallelization — независимые подзадачи выполняются одновременно. Orchestrator-worker — центральный агент дробит задачу, делегирует воркерам и синтезирует результаты. Это доминирующая архитектура для большинства продакшн систем. Evaluator-optimizer — один агент генерирует, другой оценивает и дает обратную связь в цикле. Нужен, когда качество важнее скорости и одного прохода недостаточно.

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

Многоагентные системы оправдывают свои затраты в трех ситуациях: защита контекста (подзадача генерирует информацию, нерелевантную для главной задачи, и ее лучше держать в субагенте); истинная параллельность (независимые исследовательские или поисковые задачи, выигрывающие от одновременного охвата); специализация (задача требует противоречащих system prompts или один агент жонглирует слишком многими инструментами и его производительность падает).

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

Первый: расплывчатые описания задач заставляют агентов дублировать работу друг друга. Каждый агент нуждается в ясной цели, ожидаемом формате вывода, руководстве по источникам and четких границах — какая область не покрывается. Без этого два агента одновременно исследуют одно и то же и не замечают.

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

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

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

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