Один агент или рой: когда мультиагентность лишняя

В июне 2025 года команда Anthropic опубликовала разбор своей мультиагентной системы для Claude Research: один ведущий агент раздаёт задачи нескольким подчинённым, те параллельно роются в источниках. По их данным, такая схема на внутренних оценках обгоняла одиночный Claude Opus заметно сильнее, чем на 90 процентов — но и токенов сжигала примерно в 15 раз больше, чем обычный чат. Почти одновременно инженеры Cognition (авторы агента Devin) вышли со статьёй «Don't Build Multi-Agents» и заявили ровно обратное: параллельные подагенты чаще всего ломают контекст и приносят хрупкие результаты. Два сильных инженерных лагеря, противоположные выводы — и оба правы, потому что решают разные задачи.

Если вы проектируете что-то на LLM-агентах, выбор между одним агентом и роем — это не вопрос моды, а вопрос денег, задержки и того, насколько предсказуемо система будет падать. Ниже — как решать этот вопрос на трезвую голову.

Что скрывается за словами

Одноагентная система — это одна LLM в цикле: модель получает задачу, вызывает инструменты¹, читает результат, снова думает, и так до готового ответа. Весь контекст живёт в одной ленте сообщений. Классический пример — ReAct-цикл или обычный агент с набором функций.

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

• Оркестратор и работники — ведущий агент дробит задачу и раздаёт подагентам, потом собирает ответы. Так устроен Claude Research.
• Конвейер ролей — «планировщик», «кодер», «ревьюер» передают работу по цепочке.
• Дебаты — несколько агентов независимо решают задачу и спорят, чтобы отсеять галлюцинации.
• Рой равных — агенты общаются без явного начальника, координируясь через общее состояние.

Почему это вообще спор, а не выбор по вкусу

Главная боль LLM-агентов — контекст. Модель принимает решения только на основе того, что видит в окне. Когда вы разбиваете задачу на подагентов, каждый видит свой кусок и не видит чужих решений. Cognition приводит бытовой пример: попросили сделать игру в стиле Super Mario, один подагент нарисовал фон в мультяшной стилистике, другой — реалистичных персонажей, ведущий склеил несочетаемое. Ошибка не в модели, а в архитектуре: контекст разъехался.

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

Где мультиагентность реально окупается

Anthropic сформулировала честный критерий: рой выигрывает там, где задача распадается на независимые ветки, которые можно вести параллельно, и где ценность результата оправдывает расход токенов. Их пример — исследование: «найди всех членов совета директоров компаний из индекса S&P 500 в сфере ИТ». Каждую компанию можно копать отдельным агентом, ветки почти не пересекаются, а результат стоит дорого.

Признаки, что мультиагент оправдан:

1. Задачу можно нарезать на куски, которые почти не зависят друг от друга.
2. Много параллельного чтения или поиска — узкое место в скорости, а не в логике.
3. Одно окно контекста физически не вмещает нужный объём данных.
4. Цена ответа высока, и лишние токены — приемлемая плата за качество.

Где одного агента более чем достаточно

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

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

Сравнение по ключевым осям

Как выбирать на практике

Начинайте с одного агента всегда. Это дефолт, а не компромисс. Мультиагентность вводите только тогда, когда упёрлись в конкретное ограничение и можете назвать его словами: «одно окно не вмещает данные» или «половину времени агент ждёт последовательных запросов, которые можно распараллелить».

Если решились на рой, закладывайте три вещи с первого дня:

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

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

¹ Вызов инструментов (tool calling) — механизм, при котором модель возвращает не текст, а структурированный запрос на вызов внешней функции: поиск, запрос к базе, отправку письма. Ваш код исполняет вызов и возвращает результат обратно в контекст модели.