Мультиагентная схема выглядит убедительно на доске. Один агент планирует, второй пишет, третий проверяет, четвёртый сводит результат. Роли понятны, ответственность разделена, картинка похожа на устройство команды — и именно это сходство обманывает.
Мы разбирали такие сборки достаточно, чтобы заметить: рассыпаются они почти всегда в одном и том же месте.
Почему это вообще пробуют
Причина первая, техническая: у одного агента с двадцатью инструментами качество выбора падает. Чем длиннее список доступных действий, тем чаще модель берёт не то. Разделить инструменты между несколькими агентами — прямой и разумный ответ.
Причина вторая, тоже настоящая: разные шаги требуют разного поведения. Планирование выигрывает от широкого взгляда, исполнение — от узкого и точного, проверка — от недоверчивого. Одной инструкцией это не описывается.
Причина третья, ложная, но самая частая: сходство с организацией. Раз люди работают ролями, значит и агентам нужны роли. Отсюда берутся схемы с менеджером, исполнителями и ревьюером, где роли скопированы из штатного расписания, а не выведены из задачи.
Тупик: раздать роли по образцу команды
Первое, что пробуют, — назначить каждому агенту профессию и надеяться, что взаимодействие сложится само. Не работает это по вполне называемой причине: люди договариваются в общем контексте, которого у агентов нет.
Двое коллег, обсуждая задачу, помнят весь предыдущий разговор, видят одно и то же и переспрашивают, когда не поняли. Между агентами передаётся текст — и только он. Всё, чего в тексте нет, теряется на каждой границе.
Дальше начинается характерное: агент-исполнитель получает задание, понимает его иначе, чем имел в виду планировщик, делает не то, отчитывается словами «готово», проверяющий читает отчёт, а не результат, и одобряет. Ошибка не обнаруживается ни на одном шаге, потому что каждый шаг отработал корректно относительно того, что до него дошло.
Где именно рассыпается
На границе между шагами. Каждая передача — это пересказ. Пересказ теряет детали и добавляет уверенности: то, что было гипотезой, становится в следующем сообщении фактом. Через три передачи исходное условие узнать невозможно.
На проверке отчёта вместо результата. Проверяющий агент видит текст, который написал исполнитель. Написать «всё сделано, тесты проходят» дешевле, чем сделать, и никакая настойчивость в инструкции этого не меняет — проверять надо не отчёт, а артефакт.
На потере ответственности. Когда шагов много, исчезает место, где принимается решение. Планировщик считает, что решает исполнитель, исполнитель — что решение уже принято в задании, проверяющий смотрит на соответствие заданию, а не на смысл. В результате никто не отвечает за то, нужно ли было делать это вообще.
На цене. Каждый шаг — это полный контекст заново. Схема из четырёх агентов расходует кратно больше, чем один агент с тем же объёмом работы, и растёт это быстрее, чем кажется на прототипе с короткими задачами.
На отладке. Когда результат неверен, у вас несколько журналов и вопрос, на каком шаге исказился смысл. Восстанавливать это дольше, чем сделать работу руками.
На молчаливом зацикливании. Два агента, у которых нет общего критерия готовности, могут долго передавать задачу друг другу, каждый раз слегка переформулируя. Без внешнего ограничителя это заканчивается только тогда, когда кто-то смотрит на счёт.
Когда схема всё-таки работает
Мы видели работающие сборки, и у них есть общие черты.
Разделение проходит по инструментам, а не по профессиям. Агент, у которого есть доступ к базе, и агент, у которого есть доступ к почте, — это осмысленное разделение: оно уменьшает список действий и границу прав. Агент-«архитектор» и агент-«разработчик» — не разделение, а метафора.
Передача идёт структурой, а не прозой. Не «опиши, что нужно сделать», а объект с полями: что, где, с какими ограничениями, что считать готовым. Структура не даёт пересказу расти.
Проверка смотрит на артефакт. Тесты запускаются, файл читается, запрос выполняется. Проверяющий агент, который не может посмотреть на результат своими инструментами, бесполезен.
Есть жёсткий ограничитель шагов и стоимости, и его срабатывание считается отказом, а не мелочью.
И схема остаётся мелкой. Один координатор и несколько исполнителей — работает. Иерархия из трёх уровней — почти никогда: цепочка пересказов становится длиннее, чем сама задача.
Как это выглядит в эксплуатации
Прототип мультиагентной схемы почти всегда производит хорошее впечатление, и это отдельная ловушка. На коротких задачах пересказ ещё не успевает исказить смысл, стоимость незаметна, а зацикливание не проявляется. Проблемы начинаются на задачах, где шагов больше десятка, — то есть ровно там, где схему и собирались применять.
Второе, что видно только в эксплуатации, — стоимость сопровождения инструкций. У каждого агента своя, и они начинают противоречить друг другу по мелочам: один требует подробных отчётов, другой — краткости, третий велит не доверять входным данным. Изменение в одной инструкции меняет поведение всей схемы способом, который не виден в диффе.
Третье — время ответа. Последовательные шаги складываются, и схема, которая на бумаге экономила человеческий труд, на практике отвечает настолько долго, что человек успевает сделать работу сам. Это особенно обидно, потому что оптимизировать здесь нечего: время уходит на сами шаги.
Отсюда практическое правило, к которому мы пришли: сначала соберите однопроцессную версию, доведите её до работающей и только потом делите. Разделение легко сделать позже, а вот собрать обратно то, что изначально спроектировано как несколько ролей, почти невозможно — знание о задаче оказывается размазано по инструкциям.
Что мы попробовали бы иначе
Прежде чем строить несколько агентов, стоит проверить два более дешёвых варианта.
Первый — один агент, но с сокращённым списком инструментов на каждом шаге. Часто вся выгода мультиагентности сводится именно к этому, а цена в разы ниже.
Второй — обычный код вместо оркестровки моделью. Если порядок шагов известен заранее, его не нужно выбирать моделью: пусть шаги вызываются программой, а модель отвечает только за то, что действительно требует суждения. Это не мультиагентность, это конвейер с моделью внутри, и он предсказуемее.
Позиция редакции
Мы считаем, что мультиагентность оправдана как способ ограничить инструменты и права, а не как способ воспроизвести структуру команды. Практический вывод: если вы не можете назвать, какие инструменты доступны каждому агенту и чем именно проверяется его результат, схема ещё не спроектирована — у неё есть только роли.
Мы неправы, если задача по своей природе состоит из независимых частей, которые можно выполнять параллельно и сводить механически: обход большого списка, разбор множества документов, широкий поиск. Там несколько одинаковых агентов работают отлично — но это и не мультиагентность в том смысле, в каком её обычно обсуждают, а параллельная обработка.