Почему многоагентные LLM-системы падают?

Многоагентные LLM-системы падают не потому, что модель слабая, а по системным причинам: кривая спецификация задач и ролей, рассинхрон между агентами на передачах, отсутствие или брак верификации результата. Ровно так это раскладывает MAST (arXiv 2503.13657) — первая таксономия отказов таких систем: 14 видов отказов в трёх категориях, провалы размазаны по всем трём, единого корня нет. Чинится это дизайном — скоупом ролей, контрактами передач, независимой верификацией, — а не более крупной моделью и не добавлением ещё одного агента.

Сама работа называется «Why Do Multi-Agent LLM Systems Fail?». Писала её группа из Berkeley — Cemri, Pan, Yang и ещё десять соавторов, среди них Zaharia, Gonzalez и Stoica. Первая версия — 17 марта 2025-го, актуальная v3 — 26 октября 2025-го; принята на NeurIPS 2025 как постер. Пересказов таксономии в выдаче уже, кажется, больше, чем самих многоагентных систем в проде. Я читал работу иначе — как пострадавший: на сервере, за который я отвечаю, живут два агентных рантайма, и добрую половину видов отказа из таблицы ниже я видел не в бенчмарке, а в собственных инцидентах. Поэтому дальше не пересказ, а перевод: каждую категорию отказов — в контрол на уровне дизайна, который её закрывает. Таксономия ставит диагноз; меня интересует лечение.

Одна оговорка про слово «fail», чтобы дальше не спотыкаться. В paper это не «процесс упал». Это «система не сделала задачу или сделала не то». Самые дорогие виды отказа снаружи выглядят как успех: зелёный вывод, уверенный тон, брак внутри.

Неудобный факт: больше агентов не значит лучше

Начну с вывода, который пересказы опускают чаще всего. Дословно из статьи:

> Despite the increasing adoption of MAS, their performance gains often remain minimal compared to single-agent frameworks or simple baselines like best-of-N sampling.

Перевожу: несмотря на растущую популярность многоагентных систем, их прирост на популярных бенчмарках часто минимален — не только против одиночного агента, но и против best-of-N, то есть «прогнать одну модель N раз и взять лучший ответ». Бейзлайн проще некуда, и MAS его толком не обходит.

Для меня это главная строчка работы. Многоагентность — способ организовать работу: развести каналы, изолировать доступы, разнести роли с разными правами. Это не усилитель интеллекта. Если добавляешь агента, потому что «один не справляется», качества это, скорее всего, не прибавит, зато прибавит швов, а швы в таксономии занимают целую категорию из шести видов отказа. Я держу два рантайма не потому, что два умнее одного, а потому, что у них разная работа. И плачу за это соседство временем — ниже покажу чем.

Откуда взялась MAST

MAST — Multi-Agent System Failure Taxonomy, первая систематическая таксономия отказов многоагентных LLM-систем. Скептику важно не «что насчитали», а «как считали», поэтому метод коротко:

• Вручную размечены 150 трейсов выполнения задач; согласие экспертов-аннотаторов κ = 0.88. На новых, out-of-domain трейсах финальная таксономия держит κ = 0.79 — для такой разметки это сильно.
• Итоговый корпус MAST-Data — 1642 аннотированных трейса по семи фреймворкам: ChatDev, MetaGPT, HyperAgent, AppWorld, AG2 (MathChat), Magentic-One, OpenManus.
• Чтобы масштабировать разметку, собрали LLM-as-a-Judge на o1; с экспертами он согласуется хорошо.
• Внутри трейсов — GPT-4, Claude 3, Qwen2.5, CodeLlama; задачи — код, математика, общие агентные.

Первоисточники, чтобы проверять меня, а не обзоры: arXiv abs, PDF, OpenReview.

MAST на один экран: 3 категории, 14 видов отказа

Названия видов отказа оставляю английскими, как в paper, — по ним ищутся и сама работа, и обсуждения. Третья колонка — что это значит на практике.

Теперь про цифры распределения: здесь пересказы врут чаще всего. В paper есть проценты по каждому из 14 видов отказа (Figure 1), но нет агрегата по трём категориям. Встретил где-то «категория такая-то даёт N% всех провалов» — закрывай вкладку: это число выдумано, в первоисточнике его нет. Что есть на самом деле: ни один вид не доминирует, самые частые тянут примерно по 12–16% каждый. Отказы размазаны по всей поверхности — и это самостоятельный вывод: у провалов MAS нет единого корня, который закрывается одним фиксом.

«Дело в handoffs, не в модели» — мем против цифр

В тредах у практиков гуляет формула: провалы — это передачи, а не модель. По духу подписываюсь: самые злые мои инциденты действительно случались на швах. Но с текстом работы это не бьётся, и проверить это можно по той же Figure 1.

Если сложить проценты по категориям — подчёркиваю, это моя арифметика, сама работа такого ролл-апа не публикует, — крупнее всего выходит не координация, а спецификация и дизайн: постановка задачи, нарезка ролей, повторы шагов, потерянный контекст. Координация вторая, верификация третья. Кто пишет «главное — handoffs», тот распределение не смотрел.

Рациональное зерно у мема при этом есть. Handoffs — самый практичный срез: спецификацию и верификацию можно чинить дисциплиной вокруг одного агента, а передачи появляются только в многоагентности, и проектировать их приходится отдельно. Но «самый действенный рычаг» и «главная причина» — разные утверждения. Мем путает одно с другим.

FC1. Спецификация и дизайн: падает ещё на постановке

Пять видов отказа этой категории объединяет одно: агенту либо криво объяснили работу, либо не дали удержать её в голове. Disobey task specification: агент теряет требования самой задачи. Disobey role specification: «ревьюер» вдруг пишет код за «разработчика». Step repetition: система ходит по кругу, повторяя сделанное, — один из самых частых видов вообще. Loss of conversation history: контекст обрезался, агент откатился в «а что мы тут делали?». Unaware of termination conditions: никто не описал, как выглядит «готово», и система либо молотит впустую, либо останавливается где попало.

Заметь: всё это ломается до всякой координации. Одиночный агент с кривой спекой падает так же — многоагентность просто умножает кривую спеку на число ролей.

Контролы тут скучные, поэтому работают. Scoped-роли: у каждого агента явная зона, явные инструменты, явные границы — не «ты умный, разберись». Минимум агентов на задачу: каждая лишняя роль — ещё одна спецификация, которую можно написать криво. И границы памяти: осознанное решение, что переносится между шагами и сессиями, а что умирает вместе с сессией. Память в режиме «помним всё как-нибудь» превращается в loss of history, как только контекст обрежется в неожиданном месте. Я на этом обжигался — теперь проектирую границу памяти так же явно, как схему базы.

FC2. Рассинхрон агентов: рвётся на швах

Единственная категория, которой не бывает у одиночного агента, — та самая, которую все зовут handoffs. Шесть видов отказа. Conversation reset: диалог внезапно стартует с нуля, наработанное потеряно. Fail to ask for clarification: агент получил мутный ввод и вместо вопроса поехал делать, как сам понял. Task derailment: цепочка постепенно уезжает от исходной цели — каждый чуть-чуть переинтерпретировал, на выходе другая задача. Information withholding: агент знает то, что нужно соседу, и не передаёт; не со зла — просто никто не описал состав передачи. Ignored other agent's input: сосед ответил, ответ проигнорирован. Reasoning-action mismatch: в рассуждениях одно, в действиях другое; тоже из самых частых.

Теперь вживую. У меня на одной машине два агентных рантайма (разбирал эту связку отдельно), и всё худшее в их соседстве происходило не внутри агентов, а между ними. После рестартов разъезжаются токены между управляющим слоем и gateway: по отдельности оба сервиса здоровы, вместе уже не авторизуются. Апдейт одного рантайма роняет соседний. Оба хватаются за один порт или за один мессенджер. Ни один из этих инцидентов не выглядит как «модель сглупила» — модель вообще ни при чём. Рвётся шов.

Контрол — handoff-контракт, явный и записанный заранее, до передачи: кто владеет задачей в каждый момент; что именно передаётся, а что не передаётся; что логируется, чтобы потом найти, где порвалось. Звучит как бюрократия. И работает как бюрократия, то есть надёжнее энтузиазма.

FC3. Верификация: «прошло» не значит «поднялось»

Три вида отказа, через которые брак доезжает до результата. Premature termination: система решила, что готово, раньше, чем стало готово. No or incomplete verification: результат приняли, не проверив или проверив кусок. Incorrect verification: проверка была — и пропустила брак.

Мой самый дорогой урок из этой категории — из обновлений. «Команда завершилась успешно» и «система реально работает на новой версии» — два разных утверждения, и второе из первого не следует: живой процесс вполне может остаться в старом состоянии при зелёном выводе. Узнаёшь об этом позже и не оттуда, откуда ждал. С тех пор правило простое: после любого success-сигнала проверять фактическое состояние отдельным, независимым способом — в разборе про обновления оно расписано по шагам. По таксономии это ровно premature termination плюс incomplete verification, только в проде, а не в бенчмарке.

Второй контрол — approval на необратимое. В своей песочнице агент пусть работает молча; действие наружу — письмо от твоего имени, деньги, всё, что тихо не откатишь, — только после явного «да» человека. Approval — не вежливость, а верификация последствий, встроенная в конструкцию. Автономный агент, жмущий «отправить» вопреки собственным же рассуждениям, — это reasoning-action mismatch и no verification одним действием; про место approval в дизайне ассистента я писал отдельно.

Почему агент-верификатор — не серебряная пуля

Первый рефлекс после FC3: поставим ещё одного агента, пусть проверяет. Paper этот рефлекс ломает дважды.

Во-первых, верификация — сама по себе категория отказов. Верификатор — такой же агент: он умеет проверить не всё и умеет проверить неверно, приняв брак с уверенным «всё хорошо». Проверяющий, которому веришь без оснований, хуже, чем совсем без проверяющего: он выключает твою собственную паранойю.

Во-вторых, авторы прямо пишут, что решения нетривиальны: координационные отказы требуют более глубокого «social reasoning» между агентами, а не просто лучших протоколов и более длинного контекста. «Добавить ещё структуры» — не ответ по умолчанию. Это согласуется и с первым неудобным фактом: если бы отказы лечились добавлением агентов, MAS не проигрывали бы best-of-N.

Что реально снижает число провалов

Ничего революционного — и в этом суть: отказы организационные, значит, и контролы организационные. Четыре — по одному на каждое больное место.

1. Scoped-роли и минимум агентов. Явная зона, инструменты и границы у каждого; новый агент добавляется, когда без него нельзя, а не «пусть будет». Бьёт по FC1 и не даёт расти поверхности FC2. 2. Handoff-контракты. Кто владеет задачей, что передаётся, что логируется — записано заранее, а не восстанавливается по логам после инцидента. Бьёт по FC2. 3. Независимая верификация плюс approval. Результат проверяется не тем, кто его делал, и не по его success-сигналу; необратимое и внешнее — через человека. Бьёт по FC3. 4. Границы памяти. Явное решение, что персистит между шагами и сессиями, а что нет. Бьёт по loss of history — и заодно делает отказы воспроизводимыми, потому что состояние перестаёт быть случайным.

Это принципы для любой команды агентов: самописной, на фреймворке из paper, на чём угодно. Ни один не требует модели крупнее. Все четыре требуют думать до запуска — потому и встречаются реже, чем «добавим агента».

Чего MAST не говорит

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

• MAST — не закон природы. Таксономия построена на семи research-фреймворках и на задачах по коду, математике и общих агентных бенчмарках. Твоя система — не ChatDev; распределение отказов у тебя будет своё.
• Проценты — по их корпусу. 1642 трейса конкретных фреймворков на конкретных задачах. Структуру категорий переносить на свою систему можно и полезно; цифры — нельзя.
• Персональный ассистент — не swarm-бенчмарк. Пара агентов у одного владельца живёт в другом режиме, чем рой, решающий бенчмарк. Категории те же, частоты и цена ошибки другие.
• Таксономия описывает, а не чинит. Работа даёт язык для разговора об отказах и прямо говорит, что решения нетривиальны. Контролы выше — мой перевод в практику; за него отвечаю я, а не авторы.
• Мой прод-маппинг — опыт одного оператора. Два рантайма на одной машине — иллюстрация к таксономии, а не датасет. n = 1, держи это в голове.

Частые вопросы

Почему многоагентные LLM-системы падают? Не из-за слабой модели, а системно. Таксономия MAST (arXiv 2503.13657) выделяет 14 видов отказов в трёх категориях: спецификация и дизайн системы, рассинхрон между агентами (handoffs), верификация задачи. Провалы размазаны по всем трём — единой корневой причины нет.

Что такое MAST? Multi-Agent System Failure Taxonomy — первая таксономия отказов многоагентных LLM-систем. Построена на ручной разметке 150 трейсов (согласие аннотаторов κ = 0.88), затем применена к 1642 трейсам семи фреймворков, от ChatDev до Magentic-One. Принята на NeurIPS 2025.

Многоагентная система лучше одиночного агента? Не автоматически. По paper, прирост MAS на популярных бенчмарках часто минимален по сравнению с одиночным агентом и даже с best-of-N сэмплингом. Многоагентность оправдывается структурой работы — каналы, роли, изоляция доступов, — а не надеждой на прирост качества.

Какие виды отказа самые частые? Ни один не доминирует: самые частые тянут примерно по 12–16% каждый. В топе — повтор шагов (step repetition), расхождение рассуждений и действий (reasoning-action mismatch), нарушение спецификации задачи, слабая или неверная верификация.

Как снизить число провалов в многоагентной системе? Дизайном, а не числом агентов: scoped-роли и минимум агентов на задачу, явные handoff-контракты (кто владеет задачей, что передаётся, что логируется), независимая верификация результата, approval человека на необратимые действия, явные границы памяти.

Это проблема модели или системы? В основном системы: категории MAST — спецификация, передачи, верификация — про организацию работы, а не про качество модели. Поэтому и чинится это организацией работы, а не переходом на модель крупнее.

Спасает ли отдельный агент-верификатор? Не серебряная пуля. Верификация в MAST — сама по себе категория отказов: проверка бывает неполной или неверной. А координационные отказы, по paper, требуют более глубокого «social reasoning», а не просто ещё одного протокола или ещё одного проверяющего.

Я пишу это, потому что сам строю и держу в проде многоагентную систему ([Cain](https://cain-ai.com)) — и получаю по рукам, когда швы рвутся. Это заметки оператора о paper, а не замена первоисточнику: цифры и формулировки сверяй по [arXiv 2503.13657](https://arxiv.org/abs/2503.13657).