При использовании современных IDE сред разработка прикладных приложений и сервисов с использованием естественного языка уже становится привычным делом. Но вот с задачей создания процессных артефактов в нотации BPMN 2.0 ИИ-агенты пока еще плохо справляются. И если в визуальном представлении их схемы становятся уже более-менее адекватными, то вот заставить “работать” такие схемы получается далеко не с первого раза. Почему так происходит и как помочь ИИ-агентам в решении поставленных задач разбираемся по мотивам перевода материалов от Тима Цёллера.
Как подготовить BPM-среду к работе с ИИ-агентами: 6 базовых стратегий
Представьте ситуацию, когда ИИ-агент получает задачу добавить в процесс согласования кредита новый шаг проверки. Он анализирует XML, вносит изменения, деплоит. Синтаксически всё верно, да и визуально красиво выглядит. Однако, работает не правильно. Процесс уходит в ошибку потому что агент не разобрался который из шлюзов обслуживает приём сообщения от внешней системы. Агент переставил на схеме этот шлюз "логично", но не правильно. Это не гипотетический сценарий. Это предсказуемый результат применения ИИ-агента к среде разработки BPM-проекта, которая не была под него подготовлена.
Агентное программирование перестало быть простой генерацией блоков кода по промпту. Это уже некая автономная модель, которая планирует шаги, вызывает инструменты, получает обратную связь и итерирует до получения приемлемого результата. В разработке программного кода такой подход уже работает достаточно надёжно, но в BPM пока нет. Причина вполне конкретна: агент умеет читать XML, но он не понимает намерений его создателя. Он видит структуру, но не осознаёт, почему она именно такая.
Среда процессной разработки на базе BPMN нотации семантически насыщенна. В ней исключающий шлюз вместо параллельного — это не вопрос вкуса, это бизнес-правило или требование архитектуры. Boundary Event на сервисной задаче — не украшение схемы, а обработчик таймаута с конкретным SLA. Call Activity вместо Embedded Sub-Process — архитектурное решение, которое влияет на версионирование и переиспользование.
Агент, не осознающий этого контекста, будет его разрушать — аккуратно и уверенно.
Ниже приведены шесть стратегий, которые сделают BPM-среду более пригодной для агентной работы. Они адресованы прежде всего аналитикам и архитекторам процессов, так как в случае внедрения агентов именно они отвечают не только за качество схем, но и за качество среды, в которой эти схемы будут исполняться и развиваться.
Стратегия 1. Манифест процесса: структурированная точка входа для агентов
Агент не имеет персистентной памяти между сессиями. Каждый раз, получая задачу, он начинает с нуля, причем первое, что он делает, это строит модель того, с чем работает. Если структурированной точки входа нет, он строит её из XML. А XML не содержит намерений, ведь там только результат.
Поэтому для каждой значимой модели процесса (BPMN) или набора правил (DMN) необходим сопроводительный манифест в машиночитаемом формате, это может быть YAML или структурированный Markdown. Агент прочитает его первым, до обращения к схеме.
Манифест должен содержать:
- Бизнес-цель процесса, можно одним абзацем, без технических деталей. Агент, знающий, что процесс обслуживает выдачу розничных кредитов физлицам, не будет случайно упрощать шаги, которые кажутся ему избыточными, но обусловлены регуляторными требованиями.
- Стек исполнения, то есть конкретный BPM-движок (OpenBPM, Camunda, Flowable), версия, особенности конфигурации, которые влияют на поведение схемы.
- Иерархию процессовс пояснением того, какие подпроцессы вызываются через Call Activity, какие встроены, и почему выбрано именно такое разделение.
- Соглашения об именовании, где казано, что глаголы используем для задач, существительные для событий, префиксы для переменных. Агент, соблюдающий соглашения, генерирует схемы, которые люди потом смогут читать.
- Осознанные архитектурные решения, как самый важный раздел. Здесь фиксируется то, что агент не может вывести из схемы: «Таймаут на задаче X установлен в 4 часа по требованию SLA договора с партнёром Y. Не изменять без согласования с владельцем процесса». Или: «Параллельный шлюз здесь намеренно, несмотря на то что в 95% случаев выполняется только одна ветка — это требование аудита».
Без последнего раздела манифест будет представлять из себя просто README. А с ним он становится защитой от деструктивной «оптимизации».
Стратегия 2. Семантика внутри модели: документация, которую агент читает в контексте
Манифест даёт агенту общий контекст. Но когда он работает с конкретным элементом схемы, ему нужен локальный контекст, вот прямо там, где принимается решение об изменении. Документация должна быть встроена в XML-атрибуты элементов, а не существовать отдельно в Confluence или в комментариях к задаче. Это важно, поскольку агент воспринимает схему буквально, он взаимодействует не с BPMN, а с XML.
Представляется, что нужно будет обеспечить три уровня семантики:
Шлюзы — приоритет №1. Именно здесь агент чаще всего принимает неверные решения. Атрибут documentation на каждом шлюзе должен объяснять не условие (оно и так видно из меток на потоках), а причину выбора типа шлюза: «Исключающее ИЛИ, а не параллельное — клиент должен получить ровно одно уведомление, даже если оба условия выполнены».
Сервисные задачи с регуляторным или контрактным контекстом в которых агент плохо ориентируется и при рефакторинге склонен убирать задачи, которые выглядят избыточными. Если задача «Фиксация в журнале аудита» не задокументирована как требование (привет 152-ФЗ), агент может её удалить как дублирующую.
Зоны повышенного риска — Boundary Events, Error Flows, корреляция сообщений между процессами. Это места, где BPMN-семантика наиболее неочевидна: агент может сгенерировать синтаксически корректный XML, который семантически неисполним — например, сообщение с корреляционным ключом, которое никогда не найдёт своего получателя, потому что процесс-получатель уже завершился. Такие элементы должны быть явно помечены как «зона риска: не изменять без проверки корреляционной логики».
Стратегия 3. Модульность: границы, которые агент не пересечёт случайно
Проблема монолитных процессов для агентов — не в объёме, а в связности. Запутанный процесс из 30 шагов с неявными зависимостями между ветками опаснее линейного из 60, так как изменение в одном месте влияет на другое непредсказуемо, и агент не может это отследить без полного прогона цепочки. Он внесёт изменение, тесты на изменённом участке пройдут, а проблема потом возникнет в ветке, которую он не трогал.
Поэтому требование модульности в BPMN схемах это скорее не про стиль, а про архитектурный инструмент управления зонами риска, в том числе для агентов. Call Activity вместо Embedded Sub-Process там, где логика может развиваться независимо. При таком подходе агент сможет рефакторить подпроцесс изолированно, и родительский процесс не пострадает.
Контракт на Service Task может представлять собой фиксацию в манифесте и в документации конкретного элемента правил составления облака входных и выходных переменных. Тогда агент, меняющий реализацию задачи, не будет угадывать, что именно возвращает задача и что с этим делает следующий шлюз.
Снизить вероятность того, что агент случайно затронет логику обработки ошибок можно через изолированные подпроцессы для обработки исключений, когда эти подпроцессы вынесены, а не встроены в общую схему.
Вообще, правило, которое стоит зафиксировать в манифесте, звучит довольно просто: агент не должен менять границы между модулями (например, чтобы нельзя было изменять ранее выбранную топологию Call Activity).
Стратегия 4. Тесты как единственный критерий корректности
У агента нет способа оценить качество своей работы иначе, как через обратную связь. Без тестов он не знает, достигнут ли результат — и продолжает итерировать, ухудшая то, что уже работало. С тестами он получает однозначный сигнал и может корректировать курс самостоятельно.
В BPM это особенно критично по одной причине: агент может сгенерировать синтаксически валидный BPMN, который семантически сломан. Движок его примет, деплой пройдёт успешно — и ошибка обнаружится только при исполнении конкретного экземпляра в проде. Тест — это единственный барьер между агентом и таким исходом.
Юнит-тесты для DMN-таблиц должны фиксировать ожидаемые выходные значения для каждой значимой комбинации входных. Особое внимание стоит уделить таблицам с hit policy COLLECT и RULE ORDER, так как их поведение не интуитивно. Агент будет на них ошибаться чаще всего, потому что привычная логика «первое совпавшее правило» здесь не сработает.
Тесты на граничные случаи процесса — таймаут, исключение в сервисной задаче, отсутствие обязательной переменной на входе. Именно здесь находятся Boundary Events и Error Flows, которые агент склонен игнорировать при генерации или упрощении схемы. Тест, проверяющий поведение процесса при таймауте, гарантирует, что агент не удалит Boundary Event как «лишний» элемент.
Интеграционные тесты с зафиксированным контрактом — контракт интеграции с CRM, ERP или внешним сервисом должен быть зафиксирован в тесте, а не только в документации. Агент, меняющий сервисную задачу, должен получить немедленный сигнал, если изменение нарушает контракт.
Стратегия 5. CI/CD для моделей: детерминированная среда как условие работы агента
Агент не имеет персистентной памяти. Это означает, что в начале каждой сессии он не знает, какая версия модели сейчас в проде, было ли его предыдущее изменение применено, и в каком окружении воспроизводится ошибка, которую ему поручили исправить. В недетерминированной среде — где деплой происходит вручную, а версии не синхронизированы — агент будет делать ложные предположения о состоянии системы. Это приводит к двойным изменениям, конфликтам и регрессиям.
Надёжный пайплайн устраняет эту неопределённость: агент фиксирует изменение, а пайплайн применяет его предсказуемо, результат однозначен. При этом пайплайн для BPM-проектов должен включать:
Статический анализ перед деплоем — автоматическая проверка структурных ошибок, которые агент может внести при частичном редактировании: незакрытые потоки управления, тупиковые узлы, отсутствующие события завершения, несвязанные элементы, нарушения соглашений об именовании из манифеста.
Атомарную сборку — процесс, DMN-таблицы, формы, скрипты и конфигурации упаковываются в единый версионированный артефакт. Агент работает с версией, а не с набором файлов в неизвестном состоянии.
Автоматический откат — если тесты упали после деплоя, среда возвращается к предыдущей версии без участия агента или человека. Агент получает лог упавших тестов и начинает новую итерацию с известной точки.
Стратегия 6. Наблюдаемость: данные, по которым агент диагностирует, а не угадывает
Диагностика без данных — это угадывание. Агент, получивший задачу «разобраться, почему процесс зависает», должен иметь доступ к конкретному следу выполнения экземпляров. Лог вида «NullPointerException в задаче X» бесполезен. Лог вида «NullPointerException в задаче X экземпляра #4471, переменная contractId = null, предыдущий шаг: Gateway_CheckLimit, условие выполнено: false» уже будет достаточен для диагностики.
Трассировка через OpenTelemetry связывает выполнение шага на BPMN-схеме с вызовами внешних сервисов в единую цепочку. Агент увидит не точку сбоя, а путь к ней: какой сервис ответил с задержкой и на каком шаге процесс начал отклоняться от ожидаемой траектории.
Если event log показывает, что 30% экземпляров процесса проходят через ветку, которая по замыслу должна быть исключением — это не баг в конкретном экземпляре, это сигнал о неверном бизнес-правиле или изменившихся условиях. Здесь помогут специализированные инструменты Process Mining. Но для их применения агенту должен быть доступен не UI аналитической платформы, а выгрузки в CSV или ему подобном текстовом формате.
В качестве заключения: новая роль BPM-аналитика
Внедрение агентов не упраздняет роль BPM-аналитика, а переопределяет её.
Раньше аналитик отвечал за качество схем. Теперь он отвечает за качество среды, в которой схемы смогут развиваться автономно. Манифест процесса, семантическая документация внутри модели, модульные границы, тестовое покрытие граничных случаев, детерминированный пайплайн и структурированные логи — всё это не просто инфраструктурные задачи DevOps, это еще и зона ответственности аналитика, который понимает намерения архитектора и знает, где именно агент может их разрушить.
Агенты, работающие в правильно подготовленной среде, будут способны сопровождать полный жизненный цикл процессов: проектировать, рефакторить, диагностировать. А вот без подготовленной среды агент будет опасен, так как он “накосячит” именно там, где BPM-системы работают с наибольшей ответственностью — в обработке исключений, в правилах принятия решений и в интеграциях с внешними сервисами. Именно здесь его уверенные, синтаксически корректные изменения-ошибки будет труднее всего обнаружить.
Ну и осталось дождаться момента, когда все это реально заработает, пройдя путь от теоретических изысканий к практической пользе и экономическому эффекту.
Вы можете опробовать описанные в статье подходы самостоятельно или с привлечением наших специалистов. Для этого достаточно воспользоваться формой обратной связи по заказу демо-встреч на официальном сайтеOpenBPMили написать нам в профильных Telegram-каналах.
Будем рады вашим вопросам и обратной связи.
