Что такое мультиагентные системы?

В 2025–2026 годах вокруг ИИ снова начался знакомый по микросервисам шум: «агенты», «оркестраторы», «мультиагентные платформы». Как и в случае с микросервисами, часть хайпа пока не подкреплена практикой. При этом под шумом есть вполне прагматичная идея: перевести ИИ из режима «умного чата» в режим «автономного участника системы», у которого есть цели, инструменты, ответственность и место в архитектуре.

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

Для начала важно отметить, что агентные системы – это не новое, не новейшее и не инновационное явление. Ему уже минимум 50 лет и, скорее всего, все инженеры в университетах строили агентные модели. И я изучал в университете агентное моделирование, затем по работе строил модели в AnyLogic, после чего еще на обучение в Institute of Complexity строил агентные модели для описания сложных адаптивных систем и в дальнейшем использовал в работе. Теория и практика агентного моделирования сложная и «скучная» в том смысле, что это кропотливая научная и инженерная работа.

Одновременно и отрадно от того, что эта область пошла в массы и немного беспокойно от осознания того, насколько там все не просто под капотом и как это все просто преподносится в публичном пространстве.

Это вводная статья с прицелом в агентные системы с использованием LLM (появился и новый термин – Agentic AI) и она должна быть простой, сложные темы оставим на потом.

Что такое ИИ‑агент?

Большинство людей уже давно знакомы с чат-ботами: открыл сайт, написал вопрос – получил ответ. Архитектурно это, как правило, один сервис (или связка сервисов), который обрабатывает текстовый запрос и возвращает текстовый ответ. Все. В лучшем случае такой бот умеет вытаскивать справочную информацию из базы знаний:

• реагирует только на входящее сообщение пользователя
• живет внутри заранее заданных сценариев (FAQ, скрипты поддержки)
• почти не помнит контекст (каждый диалог как с чистого листа или с минимальной «памятью»)
• сам по себе ничего не делает

Я намеренно упрощаю, в действительности даже архитектура подобных чат-ботов может быть очень сложной:

Однако, ИИ-агент – это уже совсем другое существо:

• у него есть цель
• он может планировать последовательность шагов, а не просто отвечать на реплики в режиме запрос-ответ
• он обладает доступом к инструментам: API, БД, файловым системам, очередям, сервисам компании
• у него есть память о прошлом опыте
• он может инициировать действия без прямого запроса человека

Если провести аналогию с традиционной архитектурой, то чат‑бот – это внешний интерфейс к вашей системе (тонкий слой UI), а ИИ‑агент – полноценный участник бизнес‑процесса, ближе к сервису, который вдобавок умеет «думать» в терминах естественного языка и знаний из модели.

Анатомия ИИ‑агента

Весьма полезная привычка – вместо абстрактных обсуждений посмотреть на «внутренности» компонента. ИИ‑агент не исключение. Типовая «анатомия» может выглядеть так:

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

Планировщик – это модуль, который берет цель, текущий контекст и состояние среды и превращает все это в план работ: последовательность шагов, развилки, запросы уточнений и проверки. В простых системах планировщик похож на workflow‑движок с шаблонами и правилами. В более гибких роль планировщика частично или полностью берет на себя LLM, которая умеет декомпозировать задачу, выбирать инструменты и корректировать план по результатам выполнения. Критический элемент здесь – критерии завершения, потому что агент должен уметь остановиться и признать результат «достаточно хорошим» (или, наоборот, понять, что без человека нельзя), иначе он либо будет бесконечно улучшать ответ, либо начнет делать лишние и рискованные действия.

Набор инструментов (тулинги) – это контролируемый интеграционный слой, который дает агенту руки: врапперы над REST/gRPC API, базами данных, очередями, файловыми хранилищами и другими внешними системами. На уровне предметной области это выглядит как набор примитивов или функций – создать тикет, получить баланс, подобрать тариф, пересчитать маршрут, отправить письмо. На уровне техники остается тем же, чем всегда и была интеграция, только теперь вызовы инициирует не человек и не прописанный детерминированный процесс, а агент в рамках своего плана. Поэтому качество дизайна инструментов (контракты, валидация параметров, идемпотентность, права) напрямую определяет надежность агента. Причем, порой значительно сильнее, чем «умность» самой модели.

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

• Краткосрочная память хранит рабочий контекст текущей задачи (диалог, промежуточные результаты, текущие допущения), 
• Долгосрочная память хранит историю взаимодействий, полезные факты, предпочтения, а также собственные ошибки и их разбор. 

Реализуется это по‑разному: от классической БД и журналов событий до векторных индексов для семантического поиска, а архитектурный смысл один – дать агенту возможность извлекать релевантное прошлое в момент принятия решения и не тащить всю историю целиком в окно контекста модели. В мультиагентных сценариях память становится еще и средством координации ( часть знаний может быть общей, часть – строго локальной конкретному агенту).

Модель мышления превращает текстовую постановку задачи в намерения, шаги плана, уточняющие вопросы и решения о том, какой инструмент вызывать и как интерпретировать ответ от внешней системы. В простом варианте это одна универсальная модель, а в более зрелой архитектуре – связка специализированных моделей (например, отдельная для планирования, отдельная для генерации пользовательского ответа, отдельная для проверки/верификации), чтобы снизить стоимость, повысить устойчивость и лучше контролировать качество. Модель не должна владеть системой, она должна работать внутри правил, инструментов и мониторинги/наблюдаемости, иначе вы получаете непредсказуемый компонент, который сложно эксплуатировать.

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

Интерфейсы могут быть входящими, исходящими и интеграционными:

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

• Синхронная оркестрация через API 
• Асинхронная координация через события, с разными свойствами 

Хорошо спроектированные интерфейсы делают агента заменяемым и эволюционно-управляемым компонентом.

Кейсы и сценарии применения

Полезнее всего думать об ИИ‑агентах как о новом типе исполнителя в существующих процессах (индустрия пока еще спорит о том, это все-таки «компонент» или «действующее лицо (actor)»).

Типичные сценарии для одного агента:

• Найди свободные даты в календаре и запланируй встречу
• Заведение тикета на основе обращения клиента
• Подготовить раз в месяц сводный отчет на основе данных из разных источников
• Подготовить презентацию на основе материалов

Под каждый такой сценарий вы можете спроектировать специализированного агента с ограниченным набором инструментов и четко определенной зоной ответственности.

С точки зрения технологической стратегии, архитектуры и здравого смысла рекомендуется всегда начинать с отдельных агентов, – это позволит наработать опыт и подготовить инфраструктуру, выявить проблемы на единичном компоненте и исправить их и начать получать полезный эффект раньше.

Если обобщить классы задач, для которых подходят единичные агенты, то это будут:

• Классификация документов
• Извлечение данных
• Простые аналитические отчеты
• Ответы на простые вопросы пользователя
• Обработка входных данных из форм
• …

Логика, думаю, понятна. С точки зрения требований и архитектуры, наиболее подходящие кандидаты – это области, в которых определен линейный процесс (делай раз, делай два, делай три), сама последовательность шагов предсказуема с небольшим числом ветвлений. При этом оптимально иметь 2-5 инструментов, один источник данных и преимущественно операции чтения данных. У всего, что я перечислил есть рациональные и логичные объяснения, но об этом в другой раз, чтобы не перегружать статью.

Мультиагентные системы

Один агент полезен, пока задача относительно проста, но любая система, если она полезна, будет развиваться и в какой-то момент потребуется:

• сочетать разные компетенции
• работать с длинными, разветвленными бизнес‑процессами
• масштабировать решение по командам и продуктам

и это неизбежно приведет к мультиагентным системам.

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

• имеют свои цели и инструменты
• взаимодействуют друг с другом через согласованные протоколы
• координируются (или самоорганизуются) для решения общей задачи

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

Здесь легко провести осторожную параллель с микросервисной архитектурой:

• вместо «огромного универсального агента на все случаи жизни» набор специализированных агентов
• появляется оркестратор / агент-менеджер, который разбивает задачу на части и распределяет их по специалистам
• встает вопрос топологии взаимодействия

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

Микросервисный архитектурный стиль, который, будучи архитектурным, затянул в себя и организационную структуру и процессы (как ранее Domain Driven Design и другие подходы). Технически – это обычная распределенная система, в которой необычным образом проведены границы. Необычным, – это таким образом, чтобы каждый микросервис был границей согласованности некоторой модели, что избавляет от самой возможности появления блокирующих зависимостей на уровне предметной области.

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

• Агенты могут конкурировать по целям
• Агенты могут дублировать работу друг друга
• Агенты могут мешать друг другу
• Агенты могут зацикливаться в общении друг с другом

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

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

Заключение

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

• от монолитов к микросервисам;
• от жестких процессов к адаптивным;
• от ручной интеграции к самоорганизующимся, но управляемым системам

И вот они, ИИ-агенты (Agentic AI), – новый тип компонента в архитектуре, – автономный, умеющий планировать и действовать. Мультиагентная система – это новый вызов, новый уровень сложности, сеть агентов, объединенных общей целью. Однако, как и раньше и как и всегда, успех будет зависеть не от модности термина, а от того, насколько аккуратно эти сущности будут встроены в бизнес, архитектуру и операционные и продуктовые процессы.