Один агент или рой: сколько нужно для реальной задачи

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

Что вообще считать «агентом»

Под агентом здесь понимается экземпляр LLM с собственным контекстом, набором инструментов и правом самостоятельно решать, какой шаг делать дальше¹. Это отличает его от простой цепочки вызовов, где каждый шаг жёстко прописан разработчиком. Когда вы добавляете второго агента, вы добавляете не «ещё одну голову», а ещё один изолированный контекст, который нужно наполнять, синхронизировать и как-то сводить обратно.

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

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

Цена каждого дополнительного агента

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

• Токены. Ведущий агент вынужден описывать подзадачу словами, подчинённый — пересказывать результат. По оценке Anthropic, мультиагентная связка расходовала около 15× токенов относительно одиночного чата. Это прямые деньги.
• Задержка. Если агенты работают последовательно, время суммируется. Параллельность помогает, но упирается в лимиты API и в этап сведения результатов.
• Точки отказа. Каждый агент может уйти в галлюцинацию или неверно интерпретировать задачу. В цепочке из пяти ошибка на втором шаге ломает три следующих.
• Отладка. Понять, почему система из семи агентов выдала чушь, на порядок сложнее, чем проследить один диалог.

Когда одного агента достаточно

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

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

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

Когда несколько агентов оправданы

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

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

Ориентир по числу

Жёсткого правила нет, но есть здравый диапазон.

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

Как подобрать число под свою задачу

Практичнее всего идти от одного агента и наращивать только под доказанную боль.

1. Соберите базовую версию на одном агенте с нужными инструментами и замерьте качество и стоимость.
2. Найдите, где именно она проваливается: не хватает проверки, теряется контекст, задача слишком широкая для одного прохода.
3. Добавьте ровно одного агента, который закрывает конкретно эту боль — ревьюера, планировщика или ветку поиска.
4. Сравните новые метрики со старыми. Если прирост качества не оправдывает рост токенов и задержки — откатитесь.
5. Повторяйте, пока каждый следующий агент перестанет окупаться.

Этот подход защищает от главной ошибки — проектирования сложной оркестрации до того, как доказано, что простая не справляется.

Частая ошибка: агенты вместо инструментов

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

¹ Агент (в контексте LLM) — экземпляр языковой модели, который в цикле сам выбирает действия: вызвать инструмент, задать уточнение, завершить работу. В отличие от фиксированной цепочки промптов, где порядок шагов задаёт разработчик.