Команды агентов Claude Code: когда использовать множественных агентов и как это сделать

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

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

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

В материале рассматриваются следующие аспекты:

• Почему большинству команд пока не нужно несколько агентов, и какая распространённая ошибка заключается в выборе более мощных команд.
• Четыре конкретных признака того, что у одного агента исчерпаны возможности.
• Четыре способа комбинирования агентов в таксономии, независимой от поставщика: оркестратор, конвейер, параллельные специалисты и стая.
• Стек Anthropic для команд агентов, позволяющий разделять стабильные решения от экспериментальных или предварительных версий.
• Что такое команды агентов Claude Code и в чём они отличаются от сабагентов.
• Как агенты взаимодействуют: три формата, четыре схемы времени и что передаётся между ними.
• Восемь способов сбоев с практическими методами их устранения.
• Чертеж для принятия решений относительно использования нативной, самостоятельной или гибридной оркестрации.

Большинству команд достаточно одного агента

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

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

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

1. Работа слишком объемна для одного окна контекста, даже при передаче задач подагентам.
2. Для разных частей работы требуются совершенно разные специализации, что означает необходимость доступа к разным инструментам и наличие разных ограничений в поведении, а не просто разные указания.
3. Часть работы может выполняться параллельно, и здесь важна продолжительность времени.
4. Качество результата требует независимой оценки, например, со стороны второго агента, который не видел процесса рассуждений первого.

Ни одно из этих утверждений не касается возможностей. Все они связаны с архитектурой. Когда применяется тот или иной подход, дополнительные агенты оправданы. Когда их не применяют, они лишь создают помехи, и если невозможно указать конкретный вариант, путь с использованием одного агента по-прежнему доступен.

Четыре фактора, вызывающих необходимость использования агентов, с примерами

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

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

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

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

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

Четыре способа объединения агентов

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

Последовательная схема

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

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

Центральный оркестратор или планировщик-исполнитель

Основной агент разделяет задачу на части, поручает их исполнителям и синтезирует полученные результаты. Исполнители не координируют действия друг с другом; они отчитываются перед организатором. Это самый распространённый и полезный стандартный вариант. Используйте его, когда структура подзадач неизвестна заранее, но важно чёткое определение ответственности на высшем уровне. Функция Research в Anthropic работает именно по этой схеме: основной агент анализирует запрос, одновременно запускает специализированные подагентов, а затем объединяет полученные ими данные.

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

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

Параллельные специалисты, дебаты и команда атак

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

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

Стая, или децентрализованный общий контекст

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

Для большинства пользователей первые два подхода охватывают практически всё.

Что предлагает Anthropic сегодня

Прежде чем создавать собственную систему, стоит проверить, что уже предоставляет Anthropic и чему учат его решения. Существует несколько способов выполнения задач с использованием агентов, и они не являются взаимозаменяемыми. Представьте себе лестницу, ведущую от прямого управления до централизованного управления. Ниже приведена картина ситуации примерно на апрель 2026 года, при этом эти продукты быстро меняются.

1. API Messages. Вы полностью контролируете весь процесс. Существует возможность использования инструментов, но логику выполнения пишете вы сами, причем встроенной поддержки нескольких агентов нет. Это самый гибкий уровень, но и требующий наибольших усилий.

Claude Agent SDK. Цикл работы агента, инструменты, обработка контекста, сабагенты, хуки и отслеживание затрат предоставлены Anthropic, но работают на инфраструктуре, которой вы управляете. Сабагенты являются встроенными элементами, а любые многокомпонентные решения создаются в основном вами самими. Аутентификация осуществляется через Bedrock, Vertex AI и Azure Foundry, поэтому это самый универсальный вариант.

Claude Managed Agents. Anthropic обеспечивает работу среды выполнения за вас: контейнеры, компактация данных, кэширование промптов, история событий, сессии с сохранением состояния и набор встроенных инструментов. Использование одного агента уже сформировалось как стабильная практика, тогда как многокомпонентные сессии находятся в отдельном превью-режиме с ограниченным доступом.

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

Подагенты Claude Code. Изолированные рабочие контексты внутри одной основной сессии, которые сообщают результаты обратно. Это официальная функция, но не позволяет формировать группы типа «процессор-процессор».

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

На практике утверждение «Claude поддерживает команды агентов» верно, в то время как утверждение «Claude предоставляет оркестрацию нескольких агентов производственного уровня для общего использования на любых платформах» — нет.

Команды агентов Claude Code на практике

Краткий обзор различий:

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

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

Настройка

1. Конфигурация команды находится по пути ~/.claude/teams/{name}/config.json.
2. Общий список задач находится по пути ~/.claude/tasks/{name}/.
3. Участники команды определяются в файлах агентов, которые можно использовать повторно; это по сути определения подагентов с присвоенными ролями участников команды.
4. Хуки могут служить контрольными точками качества при переходе между задачами.

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

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

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

Как агенты общаются друг с другом

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

1. Сообщения простым языком. Самая очевидная форма, но самая ненадежная в масштабном использовании. Коллеги в Claude Code обмениваются сообщениями напрямую через почтовый ящик. Это гибко, но естественный язык менее точен по сравнению со структурированными запросами, что создает больше возможностей для неправильного понимания между агентами.
2. Структурированные запросы. Использование определений инструментов в формате JSON Schema и строгое соблюдение правил их применения. Определения инструментов от Anthropic гарантируют, что аргументы соответствуют заданной структуре. Этот уровень обеспечивает надежность обмена сообщениями между агентом и инструментом, а тот же механизм делает вызовы между агентами более точными, когда они моделируются как вызовы инструментов вместо сообщений свободного формата.

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

Время выполнения имеет такое же значение, как и формат. Выделяются четыре подхода:

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

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

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

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

То, как агенты передают друг другу данные, влияет на надежность всей системы. Передача полной истории разговора обеспечивает максимальную преемственность, но линейно увеличивает затраты и задержки. Часто более эффективным является сжатый краткий обзор, и именно это делают подагенты Claude Code по замыслу разработчиков. Передача специфических для задач объектов, таких как структурированные файлы вывода, патчи кода, списки функций в формате JSON и сохраненные отчеты, как правило, представляет собой практически оптимальный вариант. Агент, принимающий данные, может напрямую изучить эти объекты вместо того, чтобы полагаться на краткий обзор, что позволяет обеспечить аудитируемость системы на уровне, недостижимом при передаче данных в формате разговора.

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

Восемь причин неудач команд агентов

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

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

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

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

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

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

Неправильное использование инструментов и нарушения безопасности. Чем больше открытых сред, тем больше точек входа для инъекции промптов, а чем больше инструментов, тем больше способов для злоумышленника действовать после проникновения. Исследования Anthropic по надежным агентам классифицируют инъекцию промптов как вектор кибератаки, а не как экстремальный случай; кроме того, в ходе тестов на проникновение от команды METR были обнаружены новые уязвимости даже в хорошо обеспеченной внутренней системе. Для снижения рисков необходимо использовать ограниченные права доступа, инструменты, соответствующие требованиям задачи, и получать утверждение человека перед выполнением значимых действий.

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

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

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

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

1. Нативные управляемые решения означают, что Anthropic контролирует среду выполнения и механизмы координации: Claude Managed Agents, а также более узко — Managed Agents для работы с несколькими агентами или команды агентов Claude Code. Преимущества заключаются в меньшей нагрузке на инженеров и наличии хостинговой инфраструктуры, которую не нужно обслуживать. Недостатки — ограниченная переносимость (доступ к Managed Agents возможен только через прямой API Claude), экспериментальный или ограниченный превью интерфейса для работы с несколькими агентами, а также зависимость от стороннего поставщика. Выбирайте этот вариант, когда проблема заключается в инфраструктуре, а ограничения, связанные с Anthropic, являются приемлемыми.

DIY означает, что вы сами контролируете логику оркестрации, а часто и среду выполнения; наиболее ярким примером служит API Messages. Этот подход обеспечивает наибольший уровень контроля, но сопряжен с самыми высокими техническими затратами. Выберите его, если ваша бизнес-логика нестандартна, правила соответствия строги, маршрутизация специфична для вашей области деятельности или необходима возможность переноса решения на другого поставщика.

Гибридный вариант означает, что Anthropic предоставляет цикл обработки и инструменты, пока вы проектируете систему, причем наиболее ярким примером является Claude Agent SDK. Вы получаете механизмы управления агентами, работу с контекстом, хуки, подагентов и возможности для отслеживания действий от Anthropic, при этом сохраняя контроль над высокоуровневой архитектурой. Аутентификация через Bedrock, Vertex AI и Azure Foundry обеспечивает значительное преимущество в переносимости по сравнению с встроенными решениями. Выбирайте этот вариант, когда хотите использовать механизмы Anthropic, но не желаете полностью привязывать свою архитектуру к текущему подходу компании к работе многоподразделенных систем.

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

Вопрос архитектуры

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

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

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