У любой системы управления процессами есть одно неудобное узкое место. Между человеком, который понимает, какой процесс нужен бизнесу, и системой, где этот процесс должен работать, почти всегда стоит посредник — разработчик, интегратор или хотя бы продвинутый администратор. Владелец процесса знает, что ему нужна категория для согласования отпусков с определёнными полями и правами. Но чтобы это появилось в системе, он пишет ТЗ, ставит задачу, ждёт очереди и получает результат через несколько дней.
Мы в «Первой Форме» решили это изменить. Наша команда реализовала поддержку MCP — Model Context Protocol. Теперь настраивать категории, формы и процессы можно через диалог с ИИ-агентом: описываешь на естественном языке, что нужно, и агент через MCP это реализует. Других готовых реализаций MCP-сервера в российских BPM-системах мы пока не видели.
Меня зовут Олег Юшин, я занимаюсь ИИ-направлением в «Первой Форме». Расскажу, зачем и как мы это сделали, как устроена интеграция и что из этого уже реально работает.
Проблема: почему ИИ-агенты и BPM-системы плохо дружили
ИИ-агенты умеют вызывать инструменты — это не новость. Но на практике подключение агента к конкретной системе выглядело так: разработчик вручную описывал каждый инструмент на стороне агента. Нужно, чтобы агент написал комментарий в задаче? Пишешь кастомный инструмент: прописываешь вызов API, формат параметров, обработку ответа. Нужно, чтобы агент создал задачу? Ещё один инструмент. Настроил права? Третий.
Проблем здесь две. Во-первых, это долго. Инструментов в BPM-системе десятки, и на каждый нужно время разработчика. На практике до большинства из них просто не доходили руки. Во-вторых, всё это — описания инструментов, логика вызова, обработка ответов — жило на стороне агента. Любое изменение API ломало агента, а два источника логики приходилось держать в синхронизации. Хотелось, чтобы логика оставалась на стороне системы: она сама публикует инструменты, сама знает, как их выполнять, а агент только вызывает.
У «Первой Формы» есть обширный API, и в теории через него можно сделать всё то же самое. Но API рассчитан на разработчика, который читает документацию и сам выбирает нужный эндпоинт. Модель в таком объёме путается — контекстное окно не резиновое, а когда эндпоинтов много, агент начинает ошибаться при выборе нужного.
Что мы сделали: «Первая Форма» как MCP-сервер
MCP (Model Context Protocol) — это открытый протокол, разработанный Anthropic, который позволяет ИИ-агенту и внешней системе договориться на общем языке. Он даёт ИИ-агенту стандартизированный интерфейс к системе. Часть инструментов — обёртки над API, часть — самостоятельные, например анализ логов или выполнение скриптов автоматизации.
Мы реализовали «Первую Форму» как MCP-сервер. Это значит, что система сама отдаёт агенту список доступных инструментов с описаниями: что делает каждый инструмент, какие параметры принимает, что возвращает. Агенту не нужно знать про наш API — он получает готовый набор действий, которые может вызывать.
Со стороны агента нужен MCP-клиент — компонент, который умеет работать по протоколу. Такой клиент есть в Claude Desktop, Cursor, N8N, Dify и других платформах. В нашу реализацию клиент не входит, и в этом суть: мы даём универсальный интерфейс, а кто и как его использует — решают на стороне агента..
Как мы решали проблему контекстного окна. Инструментов у «Первой Формы» сотни. Если отдать их агенту все разом, он не справится: контекст у моделей ограничен и, когда в нём одновременно сотни описаний, качество работы падает.
Поэтому мы разбили инструменты на домены — логические группы по функциональности (управление категориями, права, отчёты и так далее). Агент подключается к одному MCP-серверу, который на старте отдаёт только каталог доменов и справку. По запросу агент подключает нужный домен и только тогда получает его инструменты. Это lazy-подход: в контексте агента в каждый момент находятся только те инструменты, которые нужны для текущей задачи.
Уровень первый: настройка системы через диалог
Главное, что даёт эта реализация, — возможность настраивать систему на естественном языке. Владелец процесса или администратор описывает, что ему нужно: «Создай категорию для согласования отпусков, добавь поля “даты отпуска”, “замещающий сотрудник” и “комментарий руководителя”, настрой права для группы “Все сотрудники”». Агент сам определяет, какие инструменты вызвать и в какой последовательности — создание категории, добавление полей, назначение прав.
Ядро ИИ-админа — шесть инструментов для базовой настройки: создание категории, создание дополнительных параметров, привязка параметров к категории, просмотр дерева, получение типов параметров и параметров категории. Для более глубокой настройки доступны ещё сотни инструментов Admin API — маршруты, права, отчёты, порталы, SmartScript и объекты базы данных.пр
Вот как это устроено. Мы не задаём агенту жёсткий алгоритм. Мы описываем каждый инструмент — что он делает, какие параметры принимает — и даём примеры использования. Дальше модель сама решает, в каком порядке их вызывать. В этом и принцип: мы не программируем последовательность, а предоставляем набор независимых действий, из которых агент собирает решение.
Уровень второй: как это работает в ежедневных задачах
MCP-сервер — это не только про администрирование. В ежедневной работе сотрудники уже используют агента для операционных задач: анализа, ревью, массовой обработки данных. Вот несколько примеров из нашей практики.
Код-ревью через диалог. Наш руководитель тестирования подключила MCP-сервер к ИИ-агенту и попросила: «Посмотри, какие задачи на код-ревью сейчас на мне. Проведи ревью по условиям: проверь на корректность, адекватность, логичность». Агент сам нашёл назначенные задачи, скачал прикреплённые файлы с кодом, проанализировал и выдал замечания. После обсуждения написал комментарий в задачу с результатами проверки и выполнил переход «Проверка выполнена». Всё через MCP, без ручного копирования между системами.
Важный нюанс: агент к тому моменту уже был погружён в контекст проекта — они работали вместе не первый день. Ему не пришлось объяснять структуру кода или правила ревью заново. По итогам был создан промт-шаблон, чтобы другие ревьюеры в команде могли использовать тот же подход.
Массовая классификация задач. Руководитель ИИ-направления проанализировал с помощью агента более 1100 открытых сценариев. Агент читал описания задач, комментарии и документацию, а затем заполнял дополнительные поля — классификацию, ограничения, признак фичи. По сути, это массовая аналитика и структурирование данных, которую один человек вручную делал бы неделями. Агент справился за часы — оставалось проверить результат и опубликовать отчёт.
Мониторинг площадок. Наш инженер сопровождения автоматизировал ежедневную проверку клиентских площадок. Агент собирает данные о состоянии системы — ошибки, отзывчивость, аномалии — и публикует результаты проверки комментарием в задачу. Раньше это требовало ручного сбора и оформления, теперь достаточно запустить промт.
Во всех этих случаях MCP выступает как мост: агент получает через протокол возможность читать задачи, писать комментарии, заполнять поля и выполнять переходы без написания отдельных скриптов для каждого действия.
Отдельная история — SmartScripts, скрипты автоматизации, которые хранятся в базе данных. Мы написали фабрику, которая при запуске сервера автоматически превращает все включённые SmartScripts в MCP-инструменты. На практике это значит: клиент создаёт свой скрипт автоматизации — и он автоматически становится доступен агенту без дополнительной разработки.
Что важно понимать: границы и честная оценка
Было бы нечестно подать MCP как магическую кнопку. Вот что нужно учитывать.
MCP — это протокол, не искусственный интеллект. Он не делает агента умнее. Он делает подключение агента к системе быстрее и стандартнее. Раньше мы тоже могли написать любой инструмент вручную, просто это занимало время и ресурсы, которых всегда не хватало. MCP снимает это ограничение: инструменты уже готовы, их нужно только подключить.
Качество зависит от двух сторон. Мы как создатели MCP-сервера влияем на качество описаний инструментов и информативность ответов — это наша зона. Но то, как агент интерпретирует задачу и выстраивает цепочку действий, — зона модели и того, кто её настраивает. Если вы строите собственного агента, можете прописать явные навыки — промпты, цепочки инструментов, правила валидации — и алгоритмы, чтобы повысить предсказуемость. Если используете готового — будьте готовы к тому, что иногда придётся поправлять его в диалоге.
Агент работает с правами конкретного пользователя, не с суперправами. Авторизация происходит через Personal Access Token (PAT) — агент видит и может делать ровно то, что разрешено этому пользователю. Административные домены требуют прав администратора, пользовательские — стандартную авторизацию. Разделение такое же, как в интерфейсе.
А если агент ошибётся? Мы понимаем этот риск, особенно если вы подключаете внешнюю модель, поведение которой не контролируете полностью. Вот что помогает его минимизировать:
Работа на dev-среде. Здесь можно экспериментировать, проверять результат и только после этого переносить на прод. Это стандартная практика для любых изменений конфигурации.
Откат изменений. Если агент создал категорию не так, как нужно, её можно удалить и попросить переделать — или скорректировать вручную. На dev-контуре это безопасно.
Понятные ответы при ошибках. Когда инструмент возвращает ошибку, мы отдаём не просто «не получилось», а конкретную причину: «у пользователя нет права на эту операцию», «категория с таким именем уже существует». Это помогает агенту скорректировать действия самостоятельно, без участия человека.
Инженерная мелочь, которая показывает, с чем приходится сталкиваться: MCP-ответы содержат кириллицу, а стандартный JSON-сериализатор экранирует её в uXXXX — нечитаемую кашу. Пришлось написать middleware, который перехватывает ответ и декодирует обратно в UTF-8. Мелочь, но без неё отладка превращалась в расшифровку.
Что это значит для рынка
На момент публикации нам не известны другие российские BPM-системы с реализованным MCP-сервером. Отдельные вендоры заявляют о планах, но готовых решений мы не видели.
Для нас это не просто техническая фича — это изменение самого подхода к настройке системы. Порог входа снижается: вместо «нужен разработчик, который напишет скрипт» появляется парадигма «нужен человек, который понимает процесс и может его описать». Это не означает, что разработчики становятся не нужны, потому что сложные сценарии, интеграции, оптимизация по-прежнему требуют экспертизы. Но типовые задачи настройки теперь может выполнить владелец процесса, который раньше мог только поставить задачу и ждать.
Мы продолжаем развивать MCP-сервер: расширяем набор инструментов, улучшаем описания и обработку ошибок, тестируем сложные сценарии настройки. Если у вас есть опыт интеграции ИИ-агентов с корпоративными системами — поделитесь в комментариях, интересно сравнить подходы.
Автор: OlegYushin
