Camunda 8.10 и ProcessOS — от описания процесса к управляемой автоматизации с AI
Camunda 8.10 вышла 13 октября 2026 года. Релиз развивает подход, при котором AI участвует и в создании автоматизации, и в выполнении бизнес-процессов. Для компании это две разные задачи: сначала разобраться, как устроена работа и что стоит изменить, затем обеспечить предсказуемое управление исполнением.
ProcessOS помогает с первой задачей. Возможности оркестрации, тестирования и наблюдения за агентами — со второй. Между ними остаётся инженерная работа: проверка моделей, интеграций и поведения решения.
Статус продуктов здесь принципиален. Выпуск Camunda 8.10 не означает, что ProcessOS стал общедоступным продуктом уровня GA. На дату подготовки статьи он доступен в Early Access.
Зачем пересматривать процесс перед внедрением AI
Если встроить агента в плохо описанный процесс, часть проблем сохранится: лишние согласования, неопределённые полномочия, ручная передача данных. Поэтому полезно начинать с бизнес-результата: какое решение нужно ускорить, какие ошибки сократить и где требуется участие человека.
Например, в обработке заявки можно поручить агенту подготовку рекомендации, а обязательную проверку условий и окончательное согласование выделить в отдельные шаги. Это пример архитектурного подхода, а не готовый сценарий, который появляется после обновления платформы. Правила и границы полномочий команда должна спроектировать сама.
Пример из анонса Camunda 8.10: подсказка следующего шага и использование компонента Check Lending Policy. Источник: Camunda.
Как ProcessOS помогает перейти от материалов к решению
В анонсе Early Access путь описан через три этапа: Discover, Re-engineer и Build. Команда предоставляет существующие материалы о процессе, проверяет восстановленную модель, обсуждает изменения и получает проект для дальнейшей разработки.
Discover — восстановить текущую картину
ProcessOS использует, например, выгрузки переписки, проектных инструментов и документов. По этим материалам формируется BPMN-модель и выявляются пробелы. Вопросы направляются эксперту по процессу через Tasklist; ответы помогают уточнить результат. Это работа с предоставленным контекстом и людьми, поэтому качество исходных материалов существенно влияет на полезность модели.
Re-engineer — согласовать будущий процесс
После проверки текущей модели команда рассматривает будущую: от небольших улучшений до более глубокого пересмотра. Для миграции возможен и lift-and-shift — перенос существующего процесса без его предварительного переосмысления. Модели на этих этапах служат для обсуждения и ещё не являются исполняемым решением.
Build — подготовить исполняемые артефакты
На этапе реализации создаются модели и сопутствующие артефакты: BPMN, DMN, формы и код. Разработчики проверяют результат, тестируют его и завершают необходимые части. Получение проекта не отменяет техническую приёмку.
Документация ProcessOS Harness детализирует путь четырьмя фазами: Scope, Discover, Transform и Implement. Scope отдельно фиксирует границы работы. Между контрольными точками предусмотрены циклы экспертной проверки; управляющий процесс выполняется в Camunda, а артефакты фиксируются в Git. Три этапа в блоге и четыре фазы Harness описывают подход на разных уровнях детализации.
Что ограничено в ProcessOS Early Access
ProcessOS Harness предназначен для подготовленных клиентов и партнёров с соответствующим доступом. Анонс адресован enterprise-клиентам и сертифицированным партнёрам; инструкция установки требует Enterprise-доступа к загрузкам. Условия подключения нужно уточнять.
Текущий выпуск не включает production-развёртывание и полный жизненный цикл приложения, настройку платформы и интеграцию CI/CD, создание произвольных интерфейсов за пределами Camunda Forms, количественный анализ эффективности наподобие process mining и общую организационную память между проектами. Проекты работают локально, каждый со своей памятью.
Отдельно действуют условия Early Access: продукт ещё не предназначен для production, может менять API, зависимости и конфигурацию, не имеет полного набора функций и maintenance service. Поддержка предоставляется по принципу best efforts; гарантированного перехода на последующие версии нет. Это статус для оценки и обратной связи до GA.
В этом и состоит различие между релизом платформы и зрелостью отдельного продукта: доступность функции в материалах о 8.10 сама по себе не подтверждает её готовность к промышленному применению. Термины preview, alpha и Early Access нужно проверять для конкретного компонента; ProcessOS обозначен именно как Early Access.
Кто участвует в пилоте
Нужны технический специалист, который ведёт проект, и эксперт, знающий реальные исключения и правила процесса. Оба должны уметь читать BPMN. Поддерживаемые инструменты для AI-разработки — Claude Code CLI и GitHub Copilot CLI. Инструкция предусматривает установку Camunda CLI и соответствующего пакета Harness, а также создание проекта под контролем версий. Для одного проекта одновременно устанавливается один пакет под выбранного агента.
Camunda Hub объединяет работу команд
Camunda Hub заменяет Web Modeler и Console и становится общей точкой работы с процессными решениями. Рабочие пространства помогают организовать сотрудничество команд, а проекты объединяют материалы решения. Инструменты моделирования и управления оказываются в одном продукте.
Важна и терминология при переходе: прежний Project в Web Modeler соответствует Workspace в Hub, а Process application — Project. Поэтому при планировании обновления стоит отдельно проверить, как команда будет находить свои модели и управлять доступом.
Для организации это повод договориться о владельцах общих компонентов и порядке их повторного использования. Сам по себе единый интерфейс не определяет, кто отвечает за качество шаблона или согласует изменение процесса: эти роли по-прежнему нужно закрепить.
Рабочие пространства и навигация по средам в Camunda Hub. Источник: документация Camunda 8.10
Как процессы становятся инструментами AI-агентов через MCP
Processes MCP Server позволяет публиковать развёрнутые BPMN-процессы как инструменты Model Context Protocol. Для автоматической регистрации процесс должен использовать шаблон MCP start event. Вызов запускает новый экземпляр и сразу возвращает его ключ: это ещё не результат выполнения всего процесса.
Сервер использует модель аутентификации и авторизации Orchestration Cluster REST API. Для production и ряда других вариантов развёртывания его требуется явно включить. Также документация уточняет, что Processes MCP Server не входит в Camunda 8 public API.
Практическое следствие для архитектуры: бизнес-операцию можно оформить как процесс с проверками и обработкой исключений, а затем предоставить агенту возможность её вызвать. Но состав разрешённых операций и права вызывающего клиента необходимо определить заранее.
При проектировании аудита есть ещё одна деталь: по умолчанию журнал фиксирует пользовательские операции, а не операции клиентов. Чтобы видеть MCP-вызовы от клиента, нужно включить их регистрацию. Наличие MCP-интерфейса само по себе не заменяет настройку аудита.
Как проверять и наблюдать поведение агентов
Operate показывает исполнение и историю взаимодействий
В Operate можно просматривать состояние агента, модель, системный промпт, вызовы инструментов и метрики использования. История диалога группируется по итерациям и помогает связать действия с полученными входными данными и ответами инструментов.
При этом отображение reasoning зависит от того, возвращает ли модель соответствующий контент. Интерфейс не следует воспринимать как гарантированный доступ ко всем внутренним рассуждениям любой LLM. Для части артефактов может понадобиться дополнительная настройка.
Панель наблюдения за AI-агентом в Operate. Источник: документация Camunda 8.10.
Тесты учитывают вариативность ответа
Для AI-агента проверка точного совпадения строки часто недостаточна. Camunda Process Test поддерживает оценку через LLM-as-a-judge и семантическое сравнение, позволяя проверять качество ответа при изменении формулировок.
Такие проверки полезно сочетать с жёсткими бизнес-инвариантами. Например: агент не должен выполнять операцию без обязательного согласования, а превышение лимита должно вести в предусмотренную ветку процесса. Это рекомендации по проектированию тестов: критерии качества и допустимые действия определяет команда, а оценка другой моделью не даёт абсолютной гарантии корректности.
Что проверить перед обновлением до 8.10
Обновление требует проверки совместимости. В 8.10 удалены прежние Operate API и Tasklist API, режим Tasklist V1 и Zeebe Process Test. Для соответствующих интеграций и тестов нужно использовать актуальные замены, включая Orchestration Cluster REST API и Camunda Process Test.
Новые шаблоны AI Agent также требуют внимания. Legacy-шаблоны объявлены устаревшими, но продолжают работать. Переход на новые выполняется вручную для каждого элемента; его нельзя считать автоматическим результатом обновления кластера.
Перед переносом рабочего решения стоит проверить используемые API, коннекторы, тесты и поддерживаемую инфраструктуру, а затем пройти обновление на стенде. Это отдельная задача от эксперимента с ProcessOS.
С чего начать компании
Для первого пилота разумно выбрать один ограниченный процесс с доступными материалами и владельцем, который может проверить модель. До запуска стоит зафиксировать ожидаемый результат, обязательные согласования и критерии приёмки.
Далее — последовательно проверить текущую модель, согласовать изменения, оценить сгенерированные артефакты и провести испытания в тестовой среде. Полезный результат пилота — понимание того, какие части работы инструмент ускорил, какие потребовали исправлений и что ещё нужно для промышленного решения.
Camunda 8.10 даёт больше инструментов для такой работы. ProcessOS позволяет исследовать новый способ разработки, Hub объединяет командную среду, а MCP, тесты и Operate помогают связать AI с управляемым исполнением. Ответственность за бизнес-правила, качество интеграций и решение о запуске остаётся у команды.
Планируете обновление Camunda или пилот автоматизации с AI? Обсудите с Reunico ваш процесс, требования к контролю и критерии успешного внедрения.