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

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

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

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

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

Пять паттернов оркестрации, покрывающих большинство задач: prompt chaining (последовательные шаги), routing (классификатор направляет к нужному обработчику), parallelization (параллельное выполнение), orchestrator-worker (центральный агент делегирует и синтезирует), evaluator-optimizer (цикл генерации и оценки).

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

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

Источник: https://x.com/akshay_pachaar/status/2033167408463069526