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