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