|
Professor Seleznov
|
Привет, Хабр! Меня зовут Данила Катальшов, я технический лидер команды промпт-инженеров 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, чтобы он не выдумывал свои названия ключей.
Сборка финального артефакта. Самый сложный и ответственный этап для LLM
Шаг 5. Документация (Summary Agent)
В конце работы вместе с файлом целевого агента пользователь получает сопроводительное письмо. Агент объясняет, что он собрал, как это запустить и какие заглушки нужно заменить. Например, вставить свой API-ключ от Telegram.
Что дальше: от Low-code к No-effort
Победа во внутреннем конкурсе — это круто, но для меня важнее, что проект «не ушел в стол».
Функциональность, которую я реализовал в своем внутреннем конкурсном мини-проекте, мы воплотили в виде полноценного вайб-код-инструмента в MWS AI Agents Platform, который позволил нам еще больше упростить процесс разработки ИИ-агентов и мультиагентных систем:
— Порог входа в платформу исчез совсем. Хочешь бота — скажи это голосом или текстом.
— Фабрика агентов: на основе успешных запросов система будет сама формировать библиотеку шаблонов.
— Корпоративная память: разработка RAG-архитектур, которые позволят агентам «помнить» историю не одного диалога, а контекст целого отдела или компании.
Об этом читайте во второй части. Подпишитесь, чтобы не пропустить-Источник
|
