Обзор MWS AI Agents Platform: платформы для создания ИИ-агентов

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

Обычно я пишу здесь разборы научных статей про LLM и ИИ в целом. В этот раз жанр другой: расскажу о MWS AI Agents Platform, платформе, которая как раз берет на себя обвязку, превращающую LLM и теорию из статей в работающие проекты.

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

Коротко о платформе

По сути, MWS AI Agents Platform — это среда, в которой агента можно собрать, подключить к данным и корпоративным системам, выпустить в прод и дальше за ним присматривать. Это та самая обвязка, необходимая, чтобы генИИ-решение работало в проде, только собранная заранее и в одном месте. В центре платформы — среда разработки с конструктором сценариев, песочницей, инструментами для экспериментов и «ИИ-командой», которая собирает агентов по текстовому описанию. Под ней лежат инструменты для работы с данными и моделями: RAG, память агентов, разметка, дообучение. Модели можно подключать почти любые: наши Cotype, свои или внешние, а с корпоративными системами агенты общаются через API и MCP. Через все слои проходят enterprise-требования: ролевая модель доступа, защита языковых моделей, работа в закрытом контуре и отказоустойчивость.

Ну и далее — о ключевых компонентах подробнее. 

Конструктор проектов

Это один из главных составляющих платформы, и в его основе лежит граф. Проще говоря, проект собирается из компонентов, как из кубиков лего. 

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

Внутри такого проекта может находиться и агентский цикл. В этом случае часть решений принимает LLM. 

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

 Из меню конструктора доступны и другие разделы платформы:

• AI-сервисы — тут лежат инструменты для работы с моделями AutoML (классификаторы и определение сущностей — NER).

• Диалоги — история диалогов.

• Разметка данных — инструменты для разметчиков.

• Каналы — HTTP-адаптеры, через которые собранное решение публикуется наружу.

• MCP-хаб — встроенные MCP-серверы и возможность подключить свои.

  Ниже я вам наскриншотил каждый элемент.

Начинать проект можно с пустого графа, а можно — с шаблона. Мы уже загрузили в платформу базовые темплейты сценариев. Если у вас, например, задача — собрать аналитический сценарий, то вы просто выбираете из каталога соответствующий шаблон (там встроен поиск) и правите по своему усмотрению. 

Виртуальная команда разработки

Создавать ИИ-проекты можно через конструктор и через промпт. Для этого в платформе есть группа специально обученных ИИ-агентов — AI Force или «ИИ-команда». Этот модуль вырос из внутреннего конкурсного проекта — почитать можно тут.  Агентская команда знает устройство платформы, понимает доступные внутри нее абстракции и имеет доступ к инструментарию. То есть она работает с теми же сущностями платформы, с которыми бы взаимодействовал пользователь, собирая ИИ-агента вручную.

«ИИ-команду» можно подключить с самого начала или на любом этапе:

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

Если тест не проходит или пользователь просит что-то поменять, разработчик точечно правит сценарий и снова запускает проверку и тесты. Цикл повторяется, пока проект не заработает.

Вот простой проект агента для интернет-магазина – для примера:

Вместо подробного техзадания системе дали свободное описание. Она начала уточнять: 

• кто будет обращаться к агенту; 

• нужен ли отдельный режим для менеджера;

• какие есть интеграции, документы и база знаний.

Но если у вас есть подробное ТЗ или описание API, лучше прислать его: задача будет точнее, чем в свободном описании. 

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

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

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

Базы знаний и RAG

Для проектов можно создавать базы знаний, загружать туда документы различных форматов и искать по этим данным разными способами: по векторной близости, обычным текстовым поиском, в том числе через BM25, или объединить несколько методов и даже приоритизировать их, задав веса. 

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

Тестирование

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

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

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

Безопасность и развертывание

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

MWS AI Agents Platform включена в реестр отечественного ПО. Основной вариант поставки — в локальном контуре, в том числе и для языковой модели. Если же политика компании позволяет использовать внешние LLM, то для них можно настроить собственные правила безопасности.

Как научиться проектировать агентные системы?

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

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

Инструменты для контроля действий агентов

Насколько автономно действует агент — определяет дизайн проекта. Сам агент можно представить как систему управления LLM с инструментами и контекстом, а вот какие инструменты дать агенту — решает уже пользователь платформы.

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

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

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

Ограничение заложено в логику вызова инструмента: агент не может его проигнорировать. Кроме подтверждения инструментов можно вставлять в граф точки ожидания человека или дать агенту инструмент обращения к человеку. Например: если информации недостаточно, остановить агентский цикл и запросить уточнение. Иными словами, реализовать принцип human-in-the-loop.

Память агентов

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

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

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

Часть решений о том, что именно извлекать из памяти, может принимать сам агент в пределах настроек проекта.

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

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

Профили памяти

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

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

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

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

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

Оркестрация и взаимодействие агентов

Когда в проекте больше одного агента, нужно решить, как они будут взаимодействовать и передавать друг другу работу. Есть три основные схемы:

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

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

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

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

Как система понимает, какому агенту отдать запрос? Здесь тоже нет какой-то магии: сначала в проект поступает событие — текст пользователя, файл или другой тип контента. Проект может запускаться по времени или по другому системному событию. А дальше первоначальная логика определяет, куда отправить запрос. Для этого можно использовать простые правила и регулярные выражения, применить классификатор или LLM.

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

Мониторинг и наблюдаемость

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

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

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

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

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

Кейсы внедрения

Сейчас MWS AI Agents Platform активно используется в контуре МТС. На ней, в частности, работает мультиагентное решение для автоматизации контакт-центра, состоящее из трех крупных модулей:

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

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

• ИИ-суфлер (пока находится в стадии пилота). Это помощник сотрудника контакт-центра, который ищет нужную информацию в базе знаний, подсказывает, как вести диалог с клиентом и помогает с онбордингом. 

Еще нашей платформе работает ИИ-рекрутер, автоматизирующий массовый наём. Он берет на себя первый контакт: смотрит резюме, добирает недостающую информацию и назначает собеседование. 

Отдельные модули MWS AI Agents Platform используются и в других продуктах. Так Audiogram для синтеза и распознавания речи лежит в основе голосовых сервисов МТС, а платформа разметки LabelX — основной инструмент разметчиков в MWS AI под все проекты ИИ-автоматизации. Я их в этом обзоре не стал описывать — расскажем отдельно.