Меня зовут Данила Катальшов, я технический лидер команды промпт‑инженеров MWS AI. В конце прошлого года мы (в значении MWS AI) выпустили собственную платформу для сборки ИИ‑агентов — MWS AI Agents Platform. Все по последней моде: интуитивно понятный low‑code/no‑code, упрощающий сборку ИИ‑решений. Наша платформа избавляет от необходимости разбираться в программировании — можно собирать нужного бота, ИИ‑агента или мультиагентную систему, просто перетаскивая блоки в визуальном конструкторе. Однако для работы на ней все равно нужно было инженерное мышление, по меньшей мере на уровне понимания циклов создания ИИ‑решений, типов данных, связей между различными компонентами и прочее.
Нам же хотелось, чтобы «порог входа» был еще ниже и рутинный инженерный цикл создания ИИ‑агентов не ложился на плечи пользователя. Иными словами, мы стремились к тому, чтобы прототип ИИ‑агента для конкретной задачи мог собрать любой уверенный пользователь ПК — в интерфейсе платформы, без программирования и без участия вендора. А самый понятный интерфейс для любого пользователя — это текстовое окно.
Сразу после выхода платформы у нас был объявлен корпоративный конкурс «Сапожник в своих сапогах». Принимались идеи и прототипы ИИ‑решений, которые упрощают жизнь себе и клиентам. Я воспользовался возможностью и в его рамках постарался закрыть общий гэп low‑code‑платформ: собрал мета‑агента — систему, где ИИ‑агент выступает архитектором и собирает других агентов по текстовому описанию. В итоге проект занял первое место и, что более важно, потом мы с командой запилили уже полноценный аналогичный (ну почти) функционал для нашей MWS AI Agents Platform.
В этой части лонгрида речь пойдет о моем конкурсном проекте. Немного порассуждаю о том, почему low‑code — это не совсем просто, расскажу, как я заставил LLM проектировать архитектуру ИИ‑агентов вместо человека и как боролся с галлюцинациями в JSON. А во второй — уже будет история о том, как реализован аналогичный вайб‑код‑функционал на платформе.
Проблема: Low‑code ≠ Easy
Мы привыкли воспринимать и представлять платформы low‑code/no‑code как «простое решение для бизнеса». В голове пользователей это выглядит так: менеджер заходит в редактор, перетаскивает пару цветных квадратиков, соединяет их стрелками — и сложный ИИ‑агент уже сам закрывает сделки, формирует письма, сочиняет симфонии, пишет картины и что‑то там еще… Но в реальности, когда бизнес‑пользователь открывает редактор, чтобы собрать какого‑нибудь ИИ‑бота, он видит пустое окно и большое количество инструментов: HTTP Request, Switch, Variables, LLM Node, Code Execution. Чтобы собрать рабочего агента, нужно обладать инженерным мышлением: понимать, что такое циклы, типы данных, структура API, как передавать контекст между нодами. Разрыв между «хочу» и «готово» пусть и сокращается, но все равно остается приличным.
Я подумал: почему пользователь должен сам двигать блоки и разбираться в переменных, если есть LLM? Пусть он скажет, что ему нужно, а «прослойка» из ИИ сама проектирует архитектуру, подбирает инструменты и собирает готовый JSON сценария.
Решение: мета‑агент (Meta Agent)
Для меня концепция звучит как I just want an agent: быстро и без технических заморочек сделать ИИ‑ассистента под себя.
Мой мета‑агент (Meta Agent) задумывался как надстройка над платформой. Это агент‑архитектор. Он встает между диалогом с пользователем и железом платформы. Пользователь общается с мета‑агентом на естественном языке. Агент задает уточняющие вопросы, думает, проектирует и отдает готовый файл конфигурации, который остается только импортировать.
Я не стал пытаться решить все одним гигантским промптом — это никогда не работает стабильно на сложных задачах. Вместо этого построил конвейер (pipeline) из нескольких узкоспециализированных агентов, где каждый отвечает за свой этап.
Процесс выглядит так:
-
User Request: запрос пользователя «Хочу агента‑аналитика».
-
Requirements: сбор и валидация требований.
-
Design: проектирование логической схемы (используем Mermaid).
-
MCP Mapping: подбор инструментов (поиск, базы данных, API).
-
Compile: сборка финального JSON для платформы.
-
Workflow: готовый бот.
Самое интересное здесь — это использование MCP и Mermaid как промежуточных языков общения между нейросетями.
Пайплайн из пяти агентов
Чтобы система работала стабильно, я разделил ее на пять специализированных этапов. Оркестратор передает контекст от одного «мини‑агента» к другому, пока на выходе не получится валидный конфиг.
Шаг 1. Сбор требований (Requirements Agent)
Ошибка новичка в промпт‑инжиниринге — сразу просить LLM «сделать бота». В 90% случаев модель нафантазирует лишнего или пропустит важное.
Первым создаем ИИ‑агента для сбора требований (Requirements Agent) — он проводит интервью. На выходе получается жесткий, нормализованный JSON с требованиями. Если пользователь ответил «не знаю», агент подставляет адекватные дефолты на основе своего опыта.
Входные параметры:
-
Триггер. Как бот должен просыпаться?
-
Входные данные. Что бот получает на старте?
-
Интеграции. С какими сервисами нужно связаться?
-
Выход. В каком формате вернуть результат?
Шаг 2. Проектирование схемы (Design Agent + Mermaid)
Я заставил агента проектировать архитектуру в формате Mermaid (Flowchart TD). На этом этапе агент решает, где нам нужна LLM‑нода для обработки смыслов, а где — простая логика или HTTP‑запрос.
Почему Mermaid?
-
Текстовый (LLM идеально пишет текст).
-
Структурированный (легко парсить).
-
Его можно тут же отрисовать пользователю для проверки: «Я планирую сделать вот такой путь данных — все верно?»
Шаг 3. Подбор инструментов (MCP Mapping)
Наша платформа поддерживает MCP. Поэтому к агенту можно подключать любые внешние инструменты: поиск в Google, доступ к Jira, базы данных или кастомные API.
MCP Map Agent анализирует архитектуру и обращается к библиотеке доступных MCP‑серверов. Например, если нужно прочитать статью из интернета, подключает fetch_url. А если нужно сложное пошаговое рассуждение — берет sequential_thinking. Агент сам прописывает эндпоинты и параметры, поэтому пользователю не нужно читать документацию к API.
Шаг 4. Компиляция (Compile Agent)
Самый сложный этап. Нужно превратить абстрактную схему и список инструментов в огромный валидный JSON‑файл, который можно загрузить прямо в платформу.
Здесь я столкнулся с главной проблемой — галлюцинациями в структуре. LLM обожают забывать закрывать кавычки или скобки в конце огромных файлов и путать ID нод при создании связей (target_node_id). Чтобы справиться с этим, я использовал Chain‑of‑Thought в системном промпте. Агент сначала описывает все ноды, присваивает им уникальные ID и только вторым проходом «протягивает» между ними связи. Параллельно я отдал агенту эталонный reference_workflow_json, чтобы он не выдумывал свои названия ключей.
Шаг 5. Документация (Summary Agent)
В конце работы вместе с файлом целевого агента пользователь получает сопроводительное письмо. Агент объясняет, что он собрал, как это запустить и какие заглушки нужно заменить. Например, вставить свой API‑ключ от Telegram.
Что дальше: от Low‑code к No‑effort
Победа во внутреннем конкурсе — это круто, но для меня важнее, что проект «не ушел в стол».
Функциональность, которую я реализовал в своем внутреннем конкурсном мини‑проекте, мы воплотили в виде полноценного вайб‑код‑инструмента в MWS AI Agents Platform, который позволил нам еще больше упростить процесс разработки ИИ‑агентов и мультиагентных систем:
-
Порог входа в платформу исчез совсем. Хочешь бота — скажи это голосом или текстом.
-
Фабрика агентов: на основе успешных запросов система будет сама формировать библиотеку шаблонов.
-
Корпоративная память: разработка RAG‑архитектур, которые позволят агентам «помнить» историю не одного диалога, а контекст целого отдела или компании.
Об этом читайте во второй части. Подпишитесь, чтобы не пропустить
Автор: Lhody
