Разработка мультиагентных систем: архитектура, которая не разваливается

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

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

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

Гипотеза: мультиагентность — это распределённый процесс, а не «много промптов»

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

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

Проблема: демо живёт на «хорошем сценарии», прод — на исключениях

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

В этих условиях у системы из связанных промптов проявляются три устойчивых отказа.

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

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

Третий — тихий рост стоимости. Чтобы «не терять качество», в контекст каждого агента подкладывают всю историю переписки между агентами. Длина запроса растёт от шага к шагу, и счёт за модели растёт быстрее, чем число обработанных задач.

Почему обычные подходы не работают

Естественная реакция на эти отказы — «добавить ещё агента» или «улучшить промпт координатора». Это не помогает, потому что лечится симптом, а не причина.

Добавление агента увеличивает число связей в системе. Если связи неявные (агенты «договариваются» свободным текстом), каждая новая связь — это новый источник неоднозначности. Система становится не умнее, а запутаннее: отлаживать её всё труднее, а поведение всё менее предсказуемо.

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

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

Инженерная модель: четыре опоры архитектуры

Мультиагентная система, которая держится в проде, стоит на четырёх опорах. Ни одна из них не про выбор модели.

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

Зафиксированное состояние процесса. У каждой задачи есть состояние, которое живёт вне отдельного вызова модели: что уже сделано, какие шаги пройдены, какие данные получены. Состояние делает шаги идемпотентными — повтор шага не портит результат и не удваивает действие. Оно же обеспечивает воспроизводимость: один и тот же вход проходит по одному и тому же маршруту, а не собирается заново каждый раз.

Явная координация вместо переговоров текстом. Должно быть понятно, кто принимает решение о следующем шаге. Это либо координатор с маршрутизацией по результату предыдущего шага, либо событийная схема, где шаг порождает событие, а на событие подписан следующий участник. В обоих случаях маршрут задан архитектурой, а не выводится моделью из свободной переписки. У координации есть лимиты: предельное число итераций, таймауты, ранний выход при низкой уверенности. Цикл, который не сходится, останавливается и эскалируется человеку, а не жжёт токены до таймаута.

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

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

Практический вывод для бизнеса

Для руководителя из этого следует несколько прикладных вещей.

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

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

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

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

Приложить это к вашим процессам — обсудить с инженером → .

Открытые вопросы

Честно обозначить границы тоже часть инженерной позиции.

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

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

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

Если у вас есть процесс, где люди в основном координируют — распределяют задачи, сводят данные, следят за статусами, — это и есть кандидат на мультиагентную систему. Обсудить ваш процесс → — разберём, что автоматизируется в первую очередь и как считать эффект.