большая часть задач ломается не из-за нехватки агентов, а из-за слабого дизайна потока
Команды часто думают, что сложная система станет лучше, если разделить ее на пять агентов с красивыми ролями. На практике проблема чаще в другом: не хватает контекста, плохо определен результат, нет ограничений на инструменты, а ошибки не наблюдаются на уровне этапов.
Если задача линейная и ее можно описать как один поток с несколькими шагами, начинать стоит с самого простого варианта. Один агент с инструментами, строгим форматом выхода и понятной последовательностью шагов обычно проще в отладке, дешевле и надежнее, чем преждевременная многоагентная архитектура.
когда single-agent или workflow выигрывает у multi-agent
Single-agent хорошо подходит для задач вроде классификации, сводок, ресерча по ограниченному набору источников, извлечения данных из документов, заполнения систем и маршрутизации обращений. Здесь ценность дает не распределение ролей, а качество входного контекста, retrieval и проверок на выходе.
Часто еще эффективнее оказывается обычный workflow: шаг 1 извлечь данные, шаг 2 проверить формат, шаг 3 выполнить действие, шаг 4 сохранить результат. Такой контур проще сделать наблюдаемым, покрыть тест-кейсами и привязать к бизнес-метрикам, чем называть каждый этап отдельным агентом.
в каких случаях multi-agent все-таки оправдан
Многоагентный подход имеет смысл, когда в процессе реально есть независимые роли или ветви работы: например, отдельный исследователь, отдельный критик, отдельный исполнитель действий и отдельный контролер качества. Еще один частый случай это сложные маршруты, где разным типам задач нужны разные инструменты, бюджеты и правила допуска.
Но даже тогда важно спрашивать не «можем ли мы сделать multi-agent», а «какую проблему это решает». Если архитектура не повышает надежность, не упрощает масштабирование и не снижает стоимость ошибки, она превращается в сложный инженерный театр. Для production это обычно плохая сделка.