Spring AI для BPM-ориентированных команд. BPMN.. BPMN. springai.. BPMN. springai. Анализ и проектирование систем.. BPMN. springai. Анализ и проектирование систем. Блог компании Haulmont.. BPMN. springai. Анализ и проектирование систем. Блог компании Haulmont. ии-агенты.. BPMN. springai. Анализ и проектирование систем. Блог компании Haulmont. ии-агенты. Прототипирование.

Spring AI для BPM-ориентированных команд - 1

Общая проблематика

Времена, когда для промышленного применения ИИ-моделей можно было использовать только язык Python, безвозвратно минули в прошлое. Сегодня для освоения приемов работы с LLM вообще нет необходимости знать какой-либо язык программирования.

На рынке представлено огромное число чат-ботов и low-code платформ, типа n8n (Activepieces, Zapier, Make/Integromat и множество других, их реально уже не счесть), которые позволяют быстро отточить свое мастерство «промптинга» и подключения различных «тулзов».

Однако, для корпоративного применения “as is” (в облачном варианте) проявляются ограничения:

Конфиденциальность данных.

Стоимость токенов.

Прозрачность и контроль.

Управление изменениями.

Простота интеграции с унаследованными системами.

Воспроизводимость.

Надежность.

Большинство из этих ограничений удается снять за счет переноса работы с LLM в локальную инфраструктуру «on-premise». Но без специального оборудования мы получим очень низкую производительность. Да и вопросы по требуемым уровням контроля и обеспечению простоты в разработке прикладных проектов никуда не уйдут.

Кроме того, нужно учитывать специфику отраслевых задач. Для финтеха можно выделить следующие типы:

Автоматизация продаж.

Кредитные конвейеры.

Управление лимитами.

Контроль договоров и поручений.

Логистика и выездное обслуживание.

Отработка заявок и обращений.

Клиентские системы лояльности.

Корпоративные сервисы и льготы.

Ограничения low-code инструментов, как правило, не позволяют оперативно закрывать вопросы интеграции с унаследованными системами и встраиваться в высокозащищенные контуры обработки данных. Они идеально подходят для быстро создания прототипов и MVP-решений, однако долгосрочное сопровождение и поддержка жизненного цикла финтех продуктов требуют профессиональных ресурсов и значительных усилий.

При этом в мире промышленной разработки на Java и Kotlin подобные ограничения позволяет преодолеть проект Spring AI. Это доста��очно новый фреймворк (последняя сборка 1.1.2 была опубликована 9 декабря 2025 года) который решает ключевую проблему интеграции возможностей ИИ в корпоративный ландшафт предприятия, а именно – связь унаследованных массивов данных и API с LLM-моделями.

Как известно, модель – вещь статичная. Её тренировали на каком-то наборе данных, который был актуальным на определённую дату. Отсюда следует, что LLM не обладает текущим контекстом времени. Если мы спросим LLM, сколько сейчас времени или какой сегодня день, она вам ответить не сможет или что-то попытается нафантазировать. Так же, как и человеку, для определения времени и дня недели нужны инструменты – часы и календарь. И для LLM модели потребуется предоставить к ним доступ.

Spring AI обеспечивает очень простой декларативный подход для добавления любых инструментов в контекст LLM с помощью протокола MCP (Model Context Protocol). Это уже достаточно широко распространенный открытый стандарт, разработанный и представленный компанией Anthropic 25 ноября 2024 года. Основная цель MCP — создание унифицированного набора правил взаимодействия между большими языковыми моделями (LLM) и внешними источниками данных и инструментами.

Обычно архитектура состоит из MCP-клиента, который обращается к одному или нескольким MCP-серверам. Эти сервера интегрированы с целевыми инструментами и источниками данных. Spring AI позволяет выполнить эту интеграцию в простом декларативном стиле. Вам даже не потребуется разбираться с протоколом, так как Spring будет генерировать описания инструментов автоматически. Однако очень важно будет делать подробные описания методов и их параметров, чтобы LLM понимала, что ей требуется вызывать и в какой последовательности.

Возможности Spring AI

Spring AI, в общем случае, предоставляет следующие возможности:

Поддерживаются переносимые API от разных поставщиков ИИ, как синхронные, так и потоковые. Поддерживаются все основные поставщики моделей ИИ, такие как Anthropic, OpenAI, Microsoft, Amazon, Google и Ollama.

Поддерживаются переносимые API для всех провайдеров Vector Store, включая новый API для фильтрации метаданных, аналогичный SQL. Поддерживаются решения от всех основных поставщиков векторных баз данных, таких как Apache Cassandra, Azure Cosmos DB, Azure Vector Search, Chroma, Elasticsearch, GemFire, MariaDB, Milvus, MongoDB Atlas, Neo4j, OpenSearch, Oracle, PostgreSQL/PGVector, Pinecone, Qdrant, Redis, SAP Hana, Typesense и Weaviate.

Средства для автоматической настройки Spring Boot и стартовые модули для моделей ИИ и хранилищ векторов.

Структурированные выходные данные — сопоставление выходных данных модели ИИ с POJO-объектами, а также ETL-фреймворк для загрузки документов в систему обработки данных.

ChatClient API — это гибкий API для взаимодействия с моделями чата на основе искусственного интеллекта, идиоматически схожий с API WebClient и RestClient.

Advisors API — инкапсулирует повторяющиеся шаблоны генеративного ИИ, преобразует данные, передаваемые в языковые модели (LLM) и из них, а также обеспечивает переносимость между различными моделями и сценариями использования.

Вызов инструментов/функций — позволяет модели запрашивать выполнение клиентских инструментов и функций, получая таким образом доступ к необходимой информации в режиме реального времени и предпринимая соответствующие действия.

Наблюдаемость — предоставляет информацию об операциях, связанных с искусственным интеллектом.

Оценка моделей ИИ — инст��ументы для анализа сгенерированного контента и защиты от галлюцинаций.

Мы считаем, что к 2026 году ИИ агенты достигли такого уровня зрелости, что их всерьёз следует рассматривать для разработки на Java в корпоративной среде и для выполнения реальных бизнес-задач. Например, подсистема Spring AI Agents определяет лёгкую, но мощную портативную абстракцию — AgentClient. И это лишь одна из составляющих набора инструментов, необходимых разработчику для эффективного взаимодействия с агентными системами.

Spring AI Agents предоставляет следующие абстракции, которые в совокупности позволяют добиться наилучших результатов:

Goals (Цели): задачи, которые должен будет выполнить агент.

Context (Контекст): данные и среда, в рамках которых работает агент — исходные файлы, логи, структурированные наборы данных и документация.

Tools (Инструменты): пользовательские функции, доступные модели по мере необходимости, чаще всего предоставляемые через протокол MCP.

Judges (Оценщики): механизмы проверки результатов и оценки качества на основе заданных критериев.

Sandbox (Песочница): абстракция среды, в которой агент безопасно и воспроизводимо выполняет свою работу.

Оркестрация агентов как базовая архитектура

Позапрошлогоднее исследование Anthropic “Building effective agents” подчеркивало важность простоты и модульности в разработке ИИ-агентов. Это исследование ввело важные архитектурные различия между двумя типами агентских систем:

1. Workflows: системы, в которых LLM и инструменты оркеструются через предварительно заданные пути.

2. Agents: системы, где LLM динамически направляют свои процессы и использование инструментов.

Агенты способны справляться со сложными задачами, но их реализация часто оказывается довольно простой. Как правило, это просто вызовы разных LLM, использующие инструменты, основанные на обратной связи от окружающей среды в замкнутом цикле. Агенты могут использоваться для решения задач с заранее не известным числом и типом итераций, где сложно или невозможно предсказать необходимое число шагов и где нельзя заранее задать путь.

Во время выполнения крайне важно, чтобы агенты получали из окружающей среды “истинные данные” на каждом шаге, а также промежуточную агрегированную информацию для оценки своего прогресса. Затем агенты могут делать паузы для получения обратной связи от человека, это может происходить в контрольных точках или при возникновении препятствий.

Автономный характер агентов означает более высокие вычислительные затраты и потенциал для накопления ошибок. Поэтому вводят такие понятия, как “зоны ответственности” и “координаторов” (то есть специализированных агентов или иные технические решения), которые обеспечивают синхронизацию внутри мультиагентной системы, чтобы агенты “не наступали друг другу на пятки”.

Ключевой вывод исследования состоит в том, что полностью автономные агенты могут казаться наиболее привлекательными для простых кейсов, но с ростом сложности workflows системы предоставляют лучшую предсказуемость и стабильность для выполнения регламентированных задач. Это хорошо сочетается с требованиями, предъявляемыми крупным бизнесом, где надежность и простота сопровождения являются решающими факторами.

Ключевые паттерны

В ранее упомянутом исследовании Anthropic рассматриваются пять ключевых паттернов, обеспечивающих эффективное применение агентских систем. Давайте разберем их подробнее, используя в качестве иллюстрации примеры BPMN-схем.

Workflow: Prompt chaining

Расшифровка паттерна Prompt chaining
Workflow: Routing

Расшифровка паттерна Routing
Workflow: Parallelization

Расшифровка паттерна Parallelization
Workflow: Orchestrator-workers

Расшифровка паттерна Orchestrator-workers
Workflow: Evaluator-optimizer

Расшифровка паттерна Evaluator-optimizer

По нашему мнению, все указанные паттерны оркестрации легко описываются и реализуются для исполнения посредством BPMN-схем и DMN-таблиц. А значит, имея BPM технологии в составе core архитектуры нашей компании, мы сохраняем компетенции команд разработки и при этом получаем надежные, проверенные временем решения, но базирующиеся уже на новых принципах использования ИИ-агентов.

Практические примеры

Давайте рассмотрим процесс самостоятельного создания мультиагентной системы, для этого нам потребуется:

Реализовать дизайнер агентов.

Реализовать оркестратор.

Реализовать бизнес-сущности.

Карточка агента — это всего лишь удобная UI-абстракция над возможностями, предоставляемыми SpringAI.

В модуле дизайнера вы описываете, как агент должен решать задачу, какими ресурсами и инструментами пользоваться и в каком формате выдавать ответ. Здесь же можно будет переключиться на локально развернутые LLM-модели.

Для оркестрации используем стандартный BPM-движок, со схемой, реализующей ранее упомянутый паттерн “Workflow: Orchestrator-workers”.

Связь с модулем дизайна агентов реализуем посредством сервисного таска таким образом, чтобы системному аналитику было удобно специфицировать этот “кубик”. А под капотом там пройдет автоматическое обращение к выбранному агенту.

В качестве бизнес-сущности возьмем входящие запросы, которые нужно классифицировать и потом подобрать исполнителей, часть из которых реализована агентами, а часть передается на отработку реальным сотрудникам.

Что мы получаем в итоге?

Снижаем долю ручной работы в массовых процессах. Ваши процессы не останавливаются и не ждут решения от сотрудника, они выполняются в разы быстрее и могут работать параллельно.

Централизованно управляем AI-логикой в отдельном сервисе. Вы самостоятельно проектируете ваши AI-сотрудников под конкретные задачи, вам больше не нужно искать или обучать людей определенным навыкам.

Получаем экономический эффект без усложнения BPMN-моделей. Модель осталось прежней, а токены стоят в разы меньше, чем содержание сотрудника.

Spring AI и BPMN позволяют перевести существующие процессы на новые LLM рельсы быстро и с видимым экономическим эффектом. Конечно, это можно называть “AI-washing”, но при этом команды получат практический опыт, бизнес получит реальную финансовую выгоду, а все вместе – экспертизу для AI трансформации.

Профит

Инженерный подход на базе современных российских платформ Jmix и OpenBPM сочетает в себе простоту освоения с возможностью глубокого погружения в код. За счет этого при использовании платформ проявляются следующие бизнес-эффекты:

Повышение скорости разработки и вывода продуктов на рынок;

Снижение издержек и повышение эффективности;

Повышение надежности и качества программных решений, снижение операционных рисков;

Гибкость и масштабируемость;

Повышение безопасности и соответствия требования.

Получается, что в мире Java и Kotlin:

Для использования ИИ нам не нужно переучивать команды разработки;

Мы сохраняем весь ранее выстроенный конвейер CI/CD;

Получаем простой и понятный путь согласования с ИБ;

Используем годами проверенные подходы, где все надежно;

Оказываемся впереди планеты всей по части KPI внедрения ИИ;

Практически бесплатно, без регистрации и смс.

Вы можете опробовать описанные в статье подходы самостоятельно или с привлечением наших специалистов. Для этого достаточно воспользоваться формой обратной связи по заказу демо-встреч на официальном сайте OpenBPM или написать нам в профильных Telegram-каналах.

Будем рады вашим вопросам и обратной связи.