Модели умеют писать валидный BPMN XML. Но файл, который открылся, ещё может описывать неправильный процесс. Storm даёт модели инструменты, хранение и правила рисования; проверка условий и сценариев остаётся за аналитиком. Разберём, где это видно на одном зайце и 84 попытках.
Я отправил 14 конфигураций моделей рисовать процесс про Петра и зайца. Сначала — через Storm MCP. Потом забрал инструменты и попросил написать BPMN XML напрямую. По три попытки каждым способом, с сохранением ответов и исходных схем.
Поначалу хотелось найти рабочую лошадь: кто быстрее, дешевле по токенам и реже ошибается. Но открываешь результат — и появляется другой вопрос. Хорошо, модель написала XML. Кто теперь проверит процесс, поправит схему и сохранит её так, чтобы к ней можно было вернуться?
Покажу на конкретной ошибке. Для неё даже не нужно разбираться в XML.
Пётр, заяц и ошибка в одном условии
Пётр собирается ловить зайца. Ему нужны кирпич и перец. Если перца нет на верхней полке, он ждёт час и проверяет снова. Зинаида, заметив повторяющиеся поиски, перекладывает перец снизу наверх. Пётр устраивает засаду. Заяц принимает кирпич за морковь, чихает и теряет сознание от удара головой. Если за восемь часов заяц не появился, Пётр уходит домой.
У Opus все три прямых XML прошли проверку по XSD и открылись без предупреждений. При этом во всех трёх таймер ожидал потери сознания зайцем вместо его появления.
Проверка на границе
Заяц пришёл на 7:59 и потерял сознание на 8:01. По условию он успел. На схеме Пётр уже уходит домой. Файл валиден, диаграмма открылась, бизнес-условие изменено.
Посмотреть эту ошибку у Opus →
Что даёт Storm помимо генерации XML
Через MCP модель получает доступ к операциям сервиса. В нашем случае Storm предлагал два пути: передать эскиз на расширенном Mermaid для преобразования в BPMN или создавать и менять элементы по отдельности. Модель могла прочитать диаграмму, внести правки и получить результат проверки. Расположением элементов занимался сервис.
Правила рисования и ограничения были прямо в описаниях инструментов. Там же — ссылки на полные руководства, но их чтение моделями журналы не подтверждают.
На выходе — сохранённая диаграмма с идентификатором, элементами, координатами и описаниями. Модель может обратиться к ней снова. Это видно в журналах:
- Sonnet, первая попытка. После эскиза переименовал задачу, превратил другую задачу в шлюз «Перец найден?» и достроил стрелки. Правки есть в выгруженном XML.
- Astra, первая попытка. Получила ошибку при построении эскиза, перешла к созданию и редактированию по элементам, затем прочитала ту же сохранённую диаграмму.
Это и есть практическая ценность связки: управление диаграммой, её хранение и заданный способ рисования. Гайдлайны и интерфейс инструментов направляют модель; сервис берёт на себя часть работы с форматом и расположением элементов. Часть описаний элементов Storm хранит отдельно от экспортируемого XML — её мы тоже собирали при проверке.
Через Storm
описание → модель → инструменты → сохранённая диаграмма
↳ чтение и правки
Напрямую
описание → модель → XML → импорт в редактор
↳ проверка, правки и хранениеВторой путь вполне рабочий технически: BPMN XML можно импортировать в совместимый редактор, хранить как файл и включить в свой процесс работы. Сам XML не запрещает ни редактирование, ни хранение. Просто соответствующие инструменты и порядок действий надо организовать отдельно. Storm — один из вариантов такой среды; другие среды в этом эксперименте мы не сравнивали.
А что потом делать с голым XML?
Во втором этапе модель сама писала и структуру процесса, и BPMN DI — координаты фигур и линий. Мы запретили ей Storm, Mermaid и внешние инструменты. После ответа получили файл, который ещё нужно было проверить и показать на экране.
Для сравнения пришлось собрать просмотрщик: импорт XML, масштабирование, переключение попыток, скачивание исходников, показ предупреждений и замечаний. На практике эта работа никуда не исчезает: её выполняет готовый редактор или ваша собственная обвязка.
Дальше остаётся проверка процесса. Сохранены ли исполнители и условия? Как устроен повтор? Какое именно событие прекращает ожидание? Что произойдёт на альтернативной ветке? Ни успешный импорт, ни валидность XML на эти вопросы целиком не отвечают.
А после проверки начинаются правки. Попросить модель перерисовать всё заново можно, но сохранность уже правильных участков надо проверять снова. Точечное изменение существующей диаграммы — отдельная задача. В первом этапе мы видели правки во время первоначального построения. Полный цикл после этого — «изменить требование → внести правку → проверить отсутствие регрессии» — здесь ещё не измеряли.
Посмотрите на результаты сами
В сравнении доступны исходные результаты каждого запуска: со Storm и без него. Можно открыть конкретную попытку, увеличить схему и прочитать разбор. Начните с Opus, попытка 1: найдите, какое событие останавливает восьмичасовое ожидание. Затем сравните с исходным условием.
А с инструментами ошибки исчезли?
Storm снял значительную часть технических проблем: в нашей серии все результаты через него прошли XSD и открылись без предупреждений. У прямого XML были пустые ответы, ошибки формата и проблемы отображения. Но наличие инструментов не обеспечило правильного понимания истории.
Например, модели часто превращали помощь Зинаиды в обязательный шаг после часа ожидания. Пётр больше не мог продолжать свои почасовые проверки, пока она ещё не заметила проблему. Для нашего прочтения текста это изменение процесса. Если принять другое допущение — что она обязательно помогает после первого часа, — оценка такой ветви изменится.
У Sonnet напрямую одна попытка поддержала все три выбранных сценария, но в ней остался поток сообщений, направленный в шлюз. В другой попытке событийный шлюз соединён с обычной задачей вместо допустимого ожидающего элемента. XSD и просмотрщик это пропустили.
Посмотреть событийный шлюз Sonnet →
Даже технически аккуратный результат может потребовать содержательной правки. Надёжность здесь зависит от конкретной связки, задачи и последующей проверки. Три удачных повтора одного примера не дают гарантии для следующего процесса или следующего изменения.
Можно ли запустить такую схему в движке?
Дополнительное BPMN-ревью обнаружило, что во всех таймерных определениях экспортированного из Storm XML выражения времени не заполнены. На рисунке есть «один час» и «восемь часов», но соответствующие значения XML не заполнены.
Картинка и исполняемый процесс
Описательную диаграмму делают, чтобы обсуждать процесс с людьми. Для этой задачи подписи таймера может быть достаточно. Но движку нужно выражение времени: текст «один час» на рисунке его не заменяет. Это ограничение есть и у лучших результатов первого этапа.
У Astra напрямую час и восемь часов записаны как PT1H и PT8H. При этом календарный старт во второй попытке использует cron без указанного диалекта. Заполненный XML тоже нужно проверять под выбранную среду исполнения. Мы процессы в движке не запускали.
Поэтому наши сценарные оценки описывают чтение графа, подписей и пояснений. Они не означают «готово к эксплуатации». Подробный разбор BPMN →
Что делать с результатом на своей задаче
Я бы начинал с небольшого процесса, требования к которому можно проверить вручную:
- Открыть схему. Проверить, что видны все участники, задачи и стрелки. Успешный импорт — только первый шаг.
- Пройти условия из текста. Что происходит сразу, после ожидания и на альтернативной ветке? Для таймера отдельно проверить событие, которое прекращает ожидание.
- Исправить найденное и сохранить версию. В Storm или другом редакторе. Повторно пройти сценарии после правки.
- Если нужен запуск — проверить настройки движка. Таймеры, условия, сообщения и привязки задач. В этом эксперименте до запуска мы не доходили.
Как читать шлюзы и потоки — разобрал в методичке по BPMN. Почему результат зависит от приложения вокруг модели — в статье про агентов и harness. Здесь сошлись обе темы.
Что я из этого вынес
Генерация XML у сильных моделей уже получается. Надёжный процесс работы со схемой этим ещё не обеспечен. Валидный файл оказался вполне достижимым результатом, но в нём всё ещё встречаются неверные условия, потерянные действия и ограничения нотации.
Storm полезен как среда для работы модели с диаграммой. Хранение, инструменты чтения и изменения, инструкции и раскладка дают больше, чем один ответ с XML. По нашему опыту запусков эта связка позволила стабильно получать технически открываемые схемы. Стабильность бизнес-логики и экономию времени на всём цикле работы мы этим не доказали.
Практическое применение сейчас — помощник в создании и доработке первоначального черновика под контролем аналитика. Результат генерации стоит рассматривать как предложение модели: открыть его, пройти ключевые сценарии и исправить найденные ошибки. Применимость к изменению существующего процесса ещё нужно проверять отдельно.
«Рабочую лошадь» я бы выбирал уже на этом полном цикле. Получить ответ быстрее — полезно, но если потом приходится искать подменённое условие и заново проверять схему, одних секунд генерации для выбора мало. Поэтому скорость и токены оставил в приложении: это данные о генерации, а не о стоимости готового процесса.
Следующий содержательный тест — взять сохранённую схему, поменять одно требование, попросить внести ограниченную правку и проверить, что остальное поведение сохранилось. Тогда станет понятнее, помогает ли связка вести процесс дальше первого рисунка.
А как справятся ещё более мелкие модели или — (крестится) — российские модели? Интересно проверить их уже на всём этом пути.
Данные и границы эксперимента
Цифры сохранены, но отвечают на узкие вопросы о наших запусках. Скорость ответа и расход токенов не показывают полную стоимость работы аналитика. Ниже можно раскрыть методику, таблицу и графики; исходники и неудачные ответы также остались на месте.
Как проводили эксперимент и что именно проверяли
Один процесс, 14 конфигураций моделей, три повтора через Storm и три напрямую: всего 84 попытки. Во втором этапе — одинаковый промпт, новые сеансы, предел 900 секунд, без внешних инструментов, подсказок координатора и исправления XML. Исходные координаты сохранены.
Проверяли XML, официальную XSD BPMN 2.0.2, импорт в bpmn-js 18.28.0 и геометрию. Для описательной логики разбирали три ситуации: независимый поиск перца до реакции Зинаиды; появление зайца против тайм-аута отсутствия; отсутствие лишней блокирующей ветви, когда перец найден сразу. Эти сценарии не покрывают все требования и ограничения BPMN.
Сценарные проверки развивались при анализе первого этапа и были перенесены во второй. Это исследовательский разбор, а не заранее зарегистрированный исполняемый бенчмарк. Оценивали AI-агенты одной модельной семьи с видимыми именами авторов. Дополнительное экспертное AI-ревью просмотрело все 84 панели; подробные и выборочные проверки перечислены в отчёте. Полной формальной валидации всех процессов не заявляем.
Результат ограничен одним кейсом. Вместе со Storm убраны его инструменты, инструкции, проверки и раскладка; изменились и доступные способы моделирования. Это сравнение двух способов работы целиком. Мы не измеряли совместную работу команды, долговременную поддержку схем, стоимость правок или выполнение процессов в движке.
Второй этап шёл 20 и 29 сентября 2026 года с перерывом из-за подписки. Единственный доказанный отказ подписки до ответа сохранён отдельно и повторён после восстановления. Версии клиентов закреплены: Codex 0.155.1, Claude Code 2.1.278, OpenCode 1.18.31; изменения серверной стороны исключить нельзя. Codex и Claude Code — medium, OpenCode — настройки провайдера. Идентификаторы моделей сохранены как сообщённые клиентами, не как независимая аттестация бэкенда.
Полный одинаковый промпт и исходный кейс → · Аудит сохранённых результатов →
Что показали проверки формата и сценариев
Через Storm: 42 результата прошли XSD и импорт без предупреждений. Напрямую: 34 извлечённых XML, 33 строгих разбора, 25 прохождений XSD, 28 импортов без предупреждений. Просмотрщик сообщил ещё о шести импортах с предупреждениями; в одном случае получились пустые пулы, поэтому такой «успех» не означает пригодной схемы.
У Astra все три выбранных описательных сценария поддержаны во всех повторах обоих этапов. Это лучший результат в нашей узкой проверке. Sonnet через Storm быстрее, но во всех трёх попытках требует исправления независимого поиска перца. Этого недостаточно, чтобы объявить любую из связок лучшей по продуктивности реального аналитика.
Дополнительный пересчёт таймеров: у Storm 96 пустых определений в 40 схемах, в двух остальных таких событий нет; напрямую — четыре пустых определения из 79. Это добавленная после эксперимента диагностика, прежние статусы не переписаны. Полные данные о таймерах →
Все 14 конфигураций: сводная таблица
| Идентификатор модели | Секунды Storm / XML | XSD XML | Чистый импорт XML | Все 3 сценария: Storm → XML |
|---|---|---|---|---|
| opencode-go/deepseek-v4.1-flash | 53 / 69 | 3/3 | 3/3 | 0/3 → 0/3 |
| claude-opus-5 | 106 / 234 | 3/3 | 3/3 | 0/3 → 0/3 |
| opencode-go/glm-5.3 | 278 / 326 | 0/3 | 0/3 | 0/3 → 0/3 |
| gpt-6-astra | 224 / 369 | 3/3 | 3/3 | 3/3 → 3/3 |
| opencode-go/kimi-k3 | 159 / 211 | 3/3 | 3/3 | 0/3 → 0/3 |
| gpt-5.6-luna | 80 / 172 | 1/3 | 1/3 | 0/3 → 0/3 |
| opencode-go/qwen3.8-flash | 289 / 570 | 0/3 | 0/3 | 0/3 → 0/3 |
| gpt-5.6-sol | 245 / 245 | 3/3 | 3/3 | 0/3 → 0/3 |
| opencode-go/mimo-v2.5 | 122 / 219 | 1/3 | 2/3 | 0/3 → 0/3 |
| gpt-5.6-terra | 207 / 387 | 2/3 | 3/3 | 0/3 → 0/3 |
| opencode-go/minimax-m3 | 86 / 348 | 0/3 | 0/3 | 0/3 → 0/3 |
| opencode-go/glm-5.3-flash | 64 / 145 | 1/3 | 2/3 | 0/3 → 0/3 |
| claude-haiku-4-5-20251001 | 76 / 215 | 3/3 | 3/3 | 0/3 → 0/3 |
| claude-sonnet-5 | 58 / 89 | 2/3 | 2/3 | 0/3 → 1/3 |
Последняя колонка — число попыток с тремя pass из трёх. Она не учитывает все дополнительные дефекты BPMN и пропущенные детали. Они перечислены рядом с исходными схемами.
Время и токены: наблюдения, а не цена готового процесса
Например, медиана Sonnet — 58 секунд через Storm и 89 напрямую; Astra — 224 и 369 секунд. Это время попытки до ответа, без последующей проверки и правки аналитиком. На графике показаны все три запуска, включая неудачные, а не только лучший.
Без MCP вход заметно сократился, а у большинства конфигураций вырос выход: модель сама писала XML и координаты. У Sonnet медианный вход — 153 тысячи против 9,6 тысячи токенов, выход — 4,7 против 13,4 тысячи.
Вход — сумма обращений за попытку, включая повторно прочитанные кэшированные префиксы, а не размер одного промпта. Кэш учитывается один раз на обращение, выход включает reported reasoning без двойного сложения. Служебные шаги без измерений отмечены в метриках; ноль в поле reasoning не доказывает отсутствие внутренних рассуждений. Клиентские счётчики не являются ценой подписки или сопоставимым счётом в рублях.
Машиночитаемое сравнение · Все статусы по попыткам
Графики отдельными картинками: время · токены · формат и импорт · сценарии. Ответы и XML скачиваются из сравнения; полные логи сохранены в материалах эксперимента.