Мультиагентные системы в продакшене: почему они ломаются и как всё упростить

Вы создали мультиагентную систему. Демо было впечатляющим — пять ИИ-агентов сотрудничают, делегируют, выдают отполированный результат. Затем вы выложили это в продакшен, и через неделю вы отлаживали фантомные списания за токены, молчаливую порчу данных и оркестратора, который уверенно выдавал галлюцинации от упавшего субагента.

Это не редкая проблема. Проблемы мультиагентных систем в продакшене — главная причина, по которой команды отказываются от агентных архитектур после фазы концепта. Опрос Latent AI за 2025 год показал, что 73% команд, прототипировавших мультиагентные системы, так и не достигли стабильности в продакшене, а у тех, кто достиг, среднее время достижения надежности составило 4,7 месяца.

Корень проблемы не в том, что мультиагентные архитектуры изъяны. Проблема в том, что продакшен вводит ограничения — потолки расходов, бюджеты по задержке, частичные сбои, персистентность состояния — которые прототипы никогда не обнажают. В этой статье разбираются конкретные режимы сбоев, почему они возникают, и конкретные паттерны, которые делают мультиагентные системы действительно надежными в масштабе.

Пять режимов сбоев, которые убивают мультиагентные пайплайны

Каждая продакшен-мультиагентная система в итоге сталкивается с версиями этих пяти проблем. Понимание их заранее сэкономит месяцы реактивной отладки.

1. Каскадные сбои и эффект домино

В одноагентной системе один сбой означает один сбой. В мультиагентной цепочке один сбой умножается. Агент A выдает слегка некорректный результат. Агент B трактует его в благоприятную сторону, делает неверные предположения и передает свой собственный дефектный выход агенту C. К тому времени, когда результат доходит до пользователя, ошибка уходит на три слоя вглубь и выглядит совершенно иначе, чем исходная проблема.

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

Решение: Принудительно задавайте схемы структурированных данных на каждой границе. Каждый агент должен возвращать объект JSON как минимум с: полем status (success, partial, failed), оценкой confidence (уверенности) и полезной нагрузкой. Оркестратор должен проверять status прежде чем что-либо передавать дальше. Вот минимальная схема:

{
  "status": "success | partial | failed",
  "confidence": 0.0 - 1.0,
  "data": { ... },
  "error": null | "описание того, что пошло не так",
  "token_usage": 1240
}

Когда агент возвращает failed, у оркестратора должна быть предопределённая логика отказоустойчивости: одна повторная попытка с уточненными инструкциями, замена более простым однопроходным ответом или эскалация человеку. Худшее возможное поведение — которое является дефолтным во многих фреймворках — молча прокидывать мусор дальше.

2. Бесконтрольные расходы из-за накладных расходов на коммуникацию

Это режим сбоя, который первым появляется в вашей счет-фактуре. Каждая межагентная передача требует переобъяснения контекста. Если агент A исследует тему (потребляя 3000 токенов), агенту B нужны эти исследования плюс собственные инструкции (4000 токенов), а агенту C нужен выход B плюс исходный контекст (5000 токенов), то один запуск пайплайна обойдется в 12 000 входных токенов — прежде чем какой-либо агент сгенерирует хотя бы один выходной токен.

Теперь добавьте повторные попытки. Одна повторная попытка на агенте B означает еще 4000 входных токенов. Три повторные попытки? 12 000 дополнительных токенов. Продакшен-системы с ненадежными агентами могут сжигать в 5-10 раз больше ожидаемого бюджета токенов.

Решение: Три конкретных практики:

• Сжимайте перед передачей. Каждый агент должен суммировать свой результат для следующего агента, а не пересылать полный лог. «Агент-компрессор» (или промпт-инструкция внутри каждого агента) может сократить контекст на 60-80% с минимальной потерей качества.
• Устанавливайте жесткие бюджеты токенов на запуск пайплайна. Определите потолок (например, всего 15 000 входных токенов на всех агентов) и обеспечьте его соблюдение в оркестраторе. Когда бюджет исчерпан, пропускайте оставшихся агентов и возвращайте лучший частичный результат.
• Используйте более дешевые модели для оркестрации и маршрутизации. Агенту, решающему, *какого* специалиста вызвать, не нужен GPT-4o. Меньшая и быстрая модель справится с маршрутизацией за небольшую часть стоимости.

3. Потеря контекста между агентами

LLM не имеют состояния. Каждый вызов агента — это новый инференс без памяти о предыдущих взаимодействиях, если вы явно не внедрите этот контекст. В мультиагентной системе это означает, что критическая информация молча теряется при каждой передаче.

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

Решение:

• Используйте общий слой памяти, из которого все агенты могут читать и в который могут писать, а не просто передавать сообщения. Простой подход: хранилище ключ-значение, где агенты публикуют факты как структурированные записи ({"key": "client_pricing_last_updated", "value": "2026-06-26", "source": "researcher_agent"}). Последующие агенты запрашивают это хранилище, а не полагаются исключительно на окно контекста.
• Определите «критические поля», которые должны сохраняться при каждой передаче. Оркестратор поддерживает объект mission_context с этими полями и повторно внедряет их при каждом вызове агента, независимо от того, что передал предыдущий агент.
• Логируйте и сравнивайте окна контекста на входе и выходе для каждого агента. Если информация, присутствующая на входе, отсутствует в выходном резюме, сигнализируйте об этом.

4. Пути наблюдаемости: какой агент всё сломал?

В одноагентной системе отладка проста: один вход, один выход, один набор логов. С пятью агентами у вас пять входов, пять выходов, пять вызовов модели и комбинаторный взрыв режимов сбоев между ними.

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

Решение: Стройте обсервабельность с первого дня, а не после первого инцидента в продакшене.

Для каждого вызова агента логируйте:

• Временную метку и ID агента
• Полный вход (промпт + контекст, отправленные модели)
• Полный выход (сырой ответ модели до какой-либо постобработки)
• Количество токенов (вход, выход, всего)
• Используемую модель (какой эндпоинт модели обработал этот вызов)
• Задержку (wall-clock время)
• Статус (success, retry, fallback, failure)

Храните их в структурированном формате (строки JSON в файле или легковесной базе данных). Когда пайплайн выдает неверный результат, воспроизведите точные входные данные для каждого агента по отдельности. Агент, который выдает другой результат при воспроизведении при тех же входных данных — ваш источник нестабильности. Агент, чей результат был верен изолированно, но неверен в контексте — ваша ошибка интеграции.

5. Накладные расходы на координацию, превышающие сложность задачи

Это самый незаметный режим сбоя. Вы декомпозируете задачу на пять агентов, потому что это «правильная» архитектура. Но задача была достаточно проста, чтобы один агент мог справиться с ней в один вызов. Декомпозиция добавила четыре передачи, три сжатия контекста и одно решение о маршрутизации — всё ради задачи, которая занимает у одного LLM 45 секунд.

Эмпирическое правило: Если одна передовая модель может справиться с задачей менее чем за 60 секунд с приемлемым качеством, не декомпозируйте её. Мультиагентные архитектуры оправдывают свою сложность, когда:

• Задача требует по-настоящему разных *возможностей* (кодинг + визуальный дизайн + исследования)
• Подзадачи могут выполняться параллельно, сокращая wall-clock время
• Отдельные подзадачи выигрывают от специализированных промптов, которые конфликтовали бы в одном контексте
• Общий пайплайн должен изящно обрабатывать сбой подзадачи без перезапуска

Практические паттерны для надежных агентных систем

Кроме исправления режимов сбоев, эти паттерны предотвращают большинство продакшен-проблем с самого начала.

Начинайте с двух агентов, а не десяти

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

Стабильная в продакшене трехагентная система (оркестратор + два специалиста) обрабатывает подавляющее большинство бизнес-воркфлоу. Пять агентов — это щедро. Десять агентов — почти всегда признак архитектурного порока.

Реализуйте идемпотентные вызовы агентов

Если ваш пайплайн падает на агенте C и вам нужна повторная попытка, агенты A и B должны выдавать идентичный результат при тех же входных данных. Это означает: детерминированное построение промпта (не внедрять «текущую дату», если не необходимо), закрепленные версии модели и параметр temperature равный 0 или близкий к 0 для некреативных задач.

Без идемпотентности повторные попытки вносят дрейф. Второй запуск агента A выдает слегка другие исследования. Второй запуск агента B генерирует другой текст на основе этих исследований. Ваша повторная попытка изменила траекторию всего пайплайна.

Используйте локальные модели для некритичных накладных расходов

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

Частый паттерн: использовать локальную модель с 7 млрд параметров для сжатия и маршрутизации, оставляя передовую модель вашего ключа API для агентов-специалистов, выполняющих реальное рассуждение и генерацию. Такой гибридный подход обычно снижает расходы на API на 60-80% без измеримой потери качества.

Стройте аварийные выключатели

Каждая продакшен-мультиагентная система нуждается как минимум в трех элементах управления:

1. Бюджет токенов на пайплайн — жесткая остановка при превышении 2. Таймаут на агента — убить зависшего агента через N секунд (обычно 30-60) 3. Глобальный аварийный выключатель — если N пайплайнов падают за M минут, останавливать все новые пайплайны и оповещать

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

Тестируйте реальный мусор, а не счастливые пути

Тест-сьют, который имеет значение — не «работает ли пайплайн, когда всё идет хорошо?», а:

• Что произойдет, если агент-исследователь вернет ноль результатов?
• Что произойдет, если ввод пользователя на неподдерживаемом системой языке?
• Что произойдет, если API вернет ошибку лимита 429 в середине пайплайна?
• Что произойдет, если агент B вернет результат, прямо противоречащий агенту A?
• Что произойдет, если входные данные в 10 раз длиннее ожидаемого?

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

Бюджет сложности

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

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

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