Почему мы написали свою библиотеку оркестрации ИИ агентов: AgentsGraph

[openbpm_pm]

Добрый день. А почему вы не воспользовались бесплатными open-source библиотеками BPM-движков, там оркестрация AI решается элементарно: унифицированный бин на базе SpringAI и все, больше ничего делать не нужно. Аналитик просто указывает нужную спецификацию на кубике схемы процесса и не погружается в реализацию. Если пробовали такой подход, то пожалуйста расскажите с какими ограничениями столкнулись?

[budaevv]

Добрый день! Спасибо за вопрос.  наши причины в другом.

Не всё можно встроить в свой продукт. Мы поставляем софт on-premise, и оркестратор должен раствориться в нём как обычная библиотека. Camunda 8 — отдельный кластер под source-available лицензией, Camunda 7 Community — EOL, у n8n лицензия запрещает embedding в коммерческие продукты. Остаётся по сути только Flowable — и тут вторая причина.

BPM-движки тяжёлые и тащат легаси, которое дальше поддерживаете вы: job executor, десятки таблиц истории, семантика BPMN 2.0 с компенсациями и boundary events — спецификация под документооборот 2000-х, а не под LLM-пайплайны. Всё это надо обновлять, объяснять на security-аудите и держать под это экспертизу — ради маршрутизируемого DAG из пяти шагов. А ошибки всё равно всплывают в рантайме: process variables — нетипизированный мешок, и «шаг B ждёт ключ, который шаг A перестал класть» аналитик на схеме не увидит.

Для LLM-инцидентов нам важнее другое: явные контракты данных между шагами, полный входной снапшот упавшего шага (включая собранный промпт) и перезапуск с этого шага на исправленных данных. Это и есть ядро AgentsGraph — несколько небольших jar (Java 11, Apache 2.0) поверх вашего же Postgres. Если в организации уже живёт Flowable и BPM-команда — ваш путь рабочий; у нас содержать движок оказалось дороже, чем написать тонкое ядро под задачу.

[openbpm_pm]

Спасибо. Не убедили конечно. Современных встраиваемых BPM-движков очень много, практически под любые языки разработки. И занимают эти библиотеки по объему порядка 3 Мб. Ничего там отдельно обновлять и обслуживать не надо, так как это полностью встраивается в ваш прикладной агентский проект, просто как одна из зависимостей. И как раз прелесть готового оркестратора в том, что все, что связано с исполнением (стек облака переменных, управление токеном-указателем шага, мониторинг ресурсов, ретраи и разрешение инцидентов) уже доступно из коробки. Поэтому можно всецело сосредоточиться на паттернах проектирования мультиагентных систем, а не на технике исполнения.

[budaevv]

Спасибо! нужно больше фактов. По мне так BPM больше для интеграции отдельных веб сервисов , чем как встраиваемая библиотека работает.

[budaevv]

Перечитал Ваши статьи вот более подробный ответ:

OpenBPM — сильный вариант: Apache 2.0, встраивается, в реестре ПО. Различия глубже — в архитектуре:

1. Наследие движка. OpenBPM несёт всю архитектуру Camunda 7: job executor, таблицы истории, семантику BPMN 2.0. Это зрелость, но и вес — миграции, экспертиза BPMN в команде. Ядро AgentsGraph — несколько небольших jar под одну задачу: DAG из LLM/OCR-шагов.

2. Spring AI — кодовый, а не декларативный. Промпты, цепочки и tools собираются в Java-коде: правка = пересборка, аудит = чтение кода. Tools — это @Tool-бины внутри приложения; чтобы переиспользовать их между процессами или дать наружу, их скорее всего придётся выносить в отдельные сервисы — и вы снова строите инфраструктуру вокруг «простого бина». У нас промпты, пороги и параметры процессоров — строки конфигурации в БД, меняются без пересборки.

3. Контракты данных. Process variables — нетипизированный мешок. У нас поток данных объявлен в конфиге шага (output_to_next/output_to_save), require(key) падает сразу, со списком доступных ключей.

4. Разбор LLM-инцидентов. Retry в BPM повторяет делегат на текущем состоянии. У нас — полный входной снапшот шага (включая промпт), перезапуск с упавшего шага на исправленных данных, реплей в CI. Плюс LLM-специфика: таймауты от maxTokens, обрезка по токенам = ошибка.

5. Честно: user tasks и BPMN Modeler для аналитиков — зрелое преимущество BPM. Наш HITL другой: правка полей в чат-UX и продолжение с того же шага.

Итог: есть BPM-практика и процессы шире AI — берите OpenBPM + Spring AI. Нужны именно LLM-пайплайны с декларативной конфигурацией, контрактами, трейсингом и продолжением после правок человека — тонкое ядро дешевле в поддержке, чем BPMN-движок с наследием.

[Igor_hab]

почему язык Java?

[budaevv]

Java все еще является корпоративным и enterprise стандартом в большинстве финансовых организаций РФ и аудируется. К тому, же была первоначальная цель сделать прототипирование чтобы доказать гипотезу, а потом, не без помощи ИИ можно переписать на другие языки. LangChain4j  библиотека не подошла т.к. использует кодовый подход вместо декларативного и аудируется тяжелее, чем декларативная конфигурация + LangChain4j — это в первую очередь клиентский слой (модели, RAG, tools), а не оркестратор; он не конкурент, а другой уровень — его вполне можно использовать внутри процессора AgentsGraph. Противопоставлять его целиком — уязвимая позиция; противопоставляйте подход. Весь стек продукта уже на Java — оркестратор обязан жить в одном процессе с DI и транзакциями приложения. И совместимость ядра с Java 11 — для консервативных организаций это не мелочь.