Привет, Хабр! Меня зовут Данила Катальшов, я технический лидер команды промпт-инженеров 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) из нескольких узкоспециализированных агентов, где каждый отвечает за свой этап.

Процесс выглядит так:

1. User Request: запрос пользователя «Хочу агента-аналитика».

2. Requirements: сбор и валидация требований.

3. Design: проектирование логической схемы (используем Mermaid).

4. MCP Mapping: подбор инструментов (поиск, базы данных, API).

5. Compile: сборка финального JSON для платформы.

6. Workflow: готовый бот.

Самое интересное здесь — это использование MCP и Mermaid как промежуточных языков общения между нейросетями. 

Пайплайн из пяти агентов

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

Шаг 1. Сбор требований (Requirements Agent)

Ошибка новичка в промпт-инжиниринге — сразу просить LLM «сделать бота». В 90% случаев модель нафантазирует лишнего или пропустит важное. 

Первым создаем ИИ-агента для сбора требований (Requirements Agent) — он проводит интервью. На выходе получается жесткий, нормализованный JSON с требованиями. Если пользователь ответил «не знаю», агент подставляет адекватные дефолты на основе своего опыта.

Входные параметры: 

• Триггер. Как бот должен просыпаться? 

• Входные данные. Что бот получает на старте? 

• Интеграции. С какими сервисами нужно связаться? 

• Выход. В каком формате вернуть результат?

Шаг 2. Проектирование схемы (Design Agent + Mermaid)

Я заставил агента проектировать архитектуру в формате Mermaid (Flowchart TD). На этом этапе агент решает, где нам нужна LLM-нода для обработки смыслов, а где — простая логика или HTTP-запрос.

Почему Mermaid?

1.  Текстовый (LLM идеально пишет текст).

2.  Структурированный (легко парсить).

3.  Его можно тут же отрисовать пользователю для проверки: «Я планирую сделать вот такой путь данных — все верно?»

Шаг 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-архитектур, которые позволят агентам «помнить» историю не одного диалога, а контекст целого отдела или компании.

Об этом читайте во второй части. Подпишитесь, чтобы не пропустить