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

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

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

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

1. Для задачи нужен огромный контекст

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

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

Anthropic называет такой поиск задачей компрессии. Во внутренней оценке компании связка Claude Opus 4 и субагентов на Sonnet 4 превзошла одиночный Opus 4 на 90,2%. Цена — примерно в 15 раз больше токенов, чем у обычного диалога.

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

2. Независимую работу можно выполнять параллельно

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

Команда Google Research проверила 180 конфигураций. В финансовой задаче, которую можно было разделить на отдельные части, централизованная команда агентов показала улучшение на 80,9%. В последовательном планировании те же подходы ухудшили результат на 39–70%. Когда каждый следующий шаг зависит от предыдущего, передача состояния съедает весь выигрыш.

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

3. Автору нужен независимый проверяющий

Модель, подготовившая решение, уже построила объяснение, почему оно правильное. При повторной проверке она легко проходит по той же цепочке рассуждений и пропускает ту же ошибку.

Cognition запускает Devin Review в чистом контексте: проверяющий получает изменения и сам восстанавливает замысел автора. По внутренним данным компании, он находит в среднем две ошибки на запрос на слияние; 58% из них серьезные.

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

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

4. Одному агенту доступно слишком многое

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

Ограничивать инструменты можно и в рамках одного агента. Разделение полезно, когда эти границы нужно превратить в отдельные компоненты с понятными разрешениями.

Роль задается не словами «ты опытный архитектор», а контекстом, инструментами и правами. GitHub предлагает проектировать границы между агентами как программные интерфейсы: типизированные сообщения, узкие схемы действий, проверка передач и журнал состояния. Их формулировка: treat agents like code, not chat interfaces.

Это продолжает тему информационной топологии, о которой я писал раньше. Иногда надежность растет именно потому, что агент знает меньше и физически не может сделать лишнего.

Когда агентов становится слишком много

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

В экспериментах Google координация давала убывающую или отрицательную отдачу, когда одиночный агент уже решал больше 45% задач. Независимые агенты усиливали ошибки до 17,2 раза, а централизованная проверка снижала показатель до 4,4. Это не универсальные константы, но направление вполне понятное: сильному одиночному агенту мультиагентность часто добавляет больше шума, чем интеллекта.

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

Если конкретного дефицита нет, мультиагентность пока не нужна.