Сбер представил три открытых инструмента для ИИ-агентов и JVM-приложений

ИИ-агент написал код, но потерял архитектурные ограничения. Сервис обновил заказ, упал перед отправкой события — и соседняя система ничего не узнала. В дайджесте Сбера представлены три открытых инструмента для таких инженерных проблем: HG SDLC, Spring AI GigaChat и Schedulex. Они отвечают за разные участки работы: передачу контекста между агентами, подключение модели к приложению и выполнение фоновых задач после сбоев.

Полезнее всего читать этот анонс через конкретный вопрос: какую часть инфраструктуры команда сейчас поддерживает сама и может ли готовый проект сократить эту работу? В опубликованном описании есть достаточно технических деталей для первого отбора. Но приведённые оценки эффективности остаются заявлениями авторов.

HG SDLC: передавать агенту задачу вместе с контекстом

Представьте обычную доработку: аналитик подготовил требования, разработчик выбрал архитектуру, агент изменил код, тесты нашли ошибку. Теперь нужно вернуть задачу на доработку так, чтобы агент получил требования, ограничения и результаты проверки. Если всё это живёт в разных чатах, связность процесса приходится поддерживать человеку.

HG SDLC предлагает описывать последовательность работы YAML-графом. В нём есть узлы с заданиями агентам, автоматические проверки и точки, где решение принимает человек. Оркестратор хранит контекст, артефакты и историю выполнения, управляет переходами и позволяет возвращать работу на предыдущий этап.

По описанию команды, инструмент работает поверх кодинг-агентов, совместимых с Agent Client Protocol. Для локального запуска указаны Java 21, Node.js 22, PostgreSQL и совместимый агент. Это отдельный компонент инфраструктуры, который тоже придётся настраивать и обслуживать.

Авторы оценивают рост эффективности разработки от сочетания агентов, разработки по спецификациям и HG SDLC в 16–30%. Выделить вклад самого оркестратора они не могут. Поэтому использовать эту цифру как обещание ускорения для своей команды было бы преждевременно. Первый предмет проверки здесь — сколько ручных передач контекста действительно исчезает.

Spring AI GigaChat: встроить модель в существующее приложение

Второй проект рассчитан на команды с Java или Kotlin и Spring Boot. Прямой запрос к модели написать несложно. Дальше появляются история диалога, поиск по документам, вызовы функций, потоковые ответы и метрики. Поддержка всего этого отдельным слоем интеграции быстро превращается в самостоятельную задачу.

Spring AI GigaChat оформлен как Spring Boot Starter и связывает API GigaChat с интерфейсами Spring AI. Приложение обращается к модели через ChatClient, а связанные компоненты экосистемы помогают организовать работу с документами, историей сообщений и инструментами.

Понятный сценарий — помощник по внутренней документации, который отвечает сотруднику и при необходимости вызывает функцию приложения. Бизнес-логика остаётся Java-кодом; интеграция с моделью проходит через Spring AI. В материале также описана аннотация @GigaTool для объявления доступных модели функций.

Перед подключением нужно проверить совместимость версий стартера, Spring Boot и Spring AI. Авторы отдельно отмечают влияние изменений API на интеграцию. Открытая библиотека также не отменяет настройку доступа к GigaChat API и доверия серверным сертификатам.

Schedulex: пережить перезапуск и сохранить согласованность данных

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

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

Граница гарантии принципиальна: транзакция базы не делает внешний HTTP-вызов атомарным. Если получатель обработал запрос, а отправитель не успел зафиксировать успех, повтор может создать дубль. Значит, внешним операциям нужна идемпотентность — безопасная обработка повторного запроса.

Авторы приводят результат около 30,7 тысячи выполнений в секунду, но с пустыми обработчиками и заранее созданными задачами. Это не прогноз производительности реального сервиса.

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