I just want an agent. Часть 1. Как я научил ИИ собирать ИИ‑агентов за пользователей и выиграл конкурс

Меня зовут Данила Катальшов, я технический лидер команды промпт‑инженеров MWS AI. В конце прошлого года мы (в значении MWS AI) выпустили собственную платформу для сборки ИИ‑агентов — MWS AI Agents Platform. Все по последней моде: интуитивно понятный low‑code/no‑code, упрощающий сборку ИИ‑решений. Наша платформа избавляет от необходимости разбираться в программировании — можно собирать нужного бота, ИИ‑агента или мультиагентную систему, просто перетаскивая блоки в визуальном конструкторе. Однако для работы на ней все равно нужно было инженерное мышление ^[1], по меньшей мере на уровне понимания циклов создания ИИ‑решений, типов данных, связей между различными компонентами и прочее.

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

Сразу после выхода платформы у нас был объявлен корпоративный конкурс «Сапожник в своих сапогах». Принимались идеи и прототипы ИИ‑решений, которые упрощают жизнь себе и клиентам. Я воспользовался возможностью и в его рамках постарался закрыть общий гэп 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)

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

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

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

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

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

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

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

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

Я заставил агента проектировать архитектуру в формате Mermaid (Flowchart TD). На этом этапе агент решает, где нам нужна LLM‑нода для обработки смыслов, а где — простая логика ^[4] или 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 обожают забывать ^[5] закрывать кавычки или скобки в конце огромных файлов и путать ID нод при создании связей (target_node_id). Чтобы справиться с этим, я использовал Chain‑of‑Thought в системном промпте. Агент сначала описывает все ноды, присваивает им уникальные ID и только вторым проходом «протягивает» между ними связи. Параллельно я отдал агенту эталонный reference_workflow_json, чтобы он не выдумывал свои названия ключей.

Шаг 5. Документация (Summary Agent)

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

Что дальше: от Low‑code к No‑effort

Победа во внутреннем конкурсе — это круто, но для меня важнее, что проект «не ушел в стол». 

Функциональность, которую я реализовал в своем внутреннем конкурсном мини‑проекте, мы воплотили в виде полноценного вайб‑код‑инструмента в MWS AI Agents Platform, который позволил нам еще больше упростить процесс разработки ИИ‑агентов и мультиагентных систем:

• Порог входа в платформу исчез совсем. Хочешь бота — скажи это голосом или текстом.

• Фабрика агентов: на основе успешных запросов система будет сама формировать библиотеку шаблонов.

• Корпоративная память ^[6]: разработка RAG‑архитектур, которые позволят агентам «помнить» историю не одного диалога, а контекст целого отдела или компании.

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