Я прогнал шесть мультиагентных паттернов на трёх бенчмарках и трёх моделях. Под командой агентов тут понимаются связки вроде критика-актора или оркестратора с подчинёнными. Почти везде такая команда проиграла одиночному агенту. Проиграла и по точности, и по цене, а по цене иногда вчетверо.

Это была бы скучная заметка в духе «МАС не нужен, расходимся». Но нашлось исключение. Чем труднее задача для модели, тем больше у команды появляется шанс на выигрыш. Так что вопросов у меня два. Влияет ли вообще топология системы на результат? И если влияет, можно ли автоматически выбирать подходящий паттерн под конкретную задачу? Ответ на второй вопрос пока отрицательный, и самое любопытное здесь именно почему.

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

Когда пишешь библиотеку, рано или поздно упираешься в движок. Не в красивый внешний интерфейс и не в обёртки, а в ту часть внутри, которая гоняет процесс. Пара флагов, цикл while, большой if посередине, и через месяц вы уже сами не помните, какие переходы там вообще возможны и почему одна из веток недостижима.

Недавно я пробовал собрать ровно такой движок и наткнулся на библиотеку, которая делает эту работу заметно аккуратнее. Называется pydantic-graph. Про неё почти не пишут, хотя на ней стоит весь pydantic-ai, агентский фреймворк от авторов Pydantic. Дальше я расскажу про неё на конкретном примере, харнессе надёжности для слабых языковых моделей.

Сразу оговорюсь про термин, потому что он сейчас на слуху. Харнесс это не только MCP, скиллы и память. Это все что заставляет модель работать хорошо как агент. Именно эту часть я и беру за основу. Но статья не столько про модели, сколько про сам подход и библиотеку. Основной посыл в том, что это интересный способ собрать движок для чего угодно, где есть состояния и переходы, и при этом не утонуть в собственном цикле.

Весь код оформлен в библиотеку и, вместе с бенчмарком, доступен на GitHub.

Решая соревнования на Kaggle начинаешь замечать паттерн. Baseline сделать просто: загрузить данные, запустить CatBoost или LightGBM, получить baseline метрику. Это занимает полчаса. Но чтобы попасть в топ решений, нужно перепробовать десятки вариантов препроцессинга, сотни комбинаций фичей и тысячи наборов гиперпараметров.

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

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

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

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