Дайджест open source Сбера

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

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

Как сохранить контекст между этапами разработки с ИИ-агентами?
Как встроить GigaChat в Java-приложение?
Как связать фоновую задачу с бизнес-транзакцией и восстановить работу после перезапуска?

Каждое из решений отвечает на один из этих вопросов. Поехали!

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

ИИ-агенты уже умеют писать код, исправлять ошибки и помогать с тестированием. Но есть нюанс: разработка — это не одна задача, которую можно передать модели и забыть о ней. Команда HG SDLC столкнулась с тем, что агенты хорошо выполняют отдельные задачи, но между этапами разработки постоянно теряется контекст.

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

Команда рассматривала OpenSpec, BMAD и Spec Kit — инструменты для разработки на основе спецификаций (Specification-Driven Development, SDD). Требовалось дополнить их знаниями конкретного проекта: архитектурными ограничениями, требованиями к надёжности и безопасности, связями между требованиями и проверками. Кроме того, нужно было явно задать точки решения человека и сохранять состояние процесса при возврате на доработку. Универсальные BPM-движки требовали дополнительной инфраструктуры.

Поэтому команда решила создать собственный оркестратор задач для ИИ-агентов.

HG SDLC (Human Guided SDLC) работает поверх кодинг-агентов, совместимых с Agent Client Protocol (ACP) — протоколом взаимодействия редакторов кода и кодинг-агентов. Разработчик описывает процесс версионированным YAML-графом. Его элементы можно объединить в три группы:

• ИИ-узлы, выполняющие задачи с помощью агентов;

• автоматические проверки;

• точки согласования, где решение принимает человек.

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

В первые месяцы использования оркестратора команды начали объединять в единые процессы работу со спецификацией, архитектурную проработку, реализацию и E2E-тестирование. Затем стали двигаться в сторону всего жизненного цикла продукта (PDLC): переносить начало сценария на более ранние этапы (shift left) — подготовку документа с продуктовыми требованиями (PRD) и проработку корпоративной архитектуры.

Главное достоинство инструмента — прозрачность: можно увидеть, как выполнялась задача, на каком этапе возникла ошибка, почему потребовалась доработка и кто принимал решение. Это полезно там, где недостаточно получить от агента ответ «готово»: нужно понимать, что он сделал, что проверил и почему процесс перешёл к следующему шагу.

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

Для локального запуска нужны Java 21, Node.js 22, PostgreSQL и совместимый кодинг-агент. Доступны установка из исходников и запуск через Docker Compose. Исходный код и инструкция по запуску: HG SDLC на GitVerse

Правила участия и подготовки изменений описаны в файле CONTRIBUTING репозитория.

Spring AI GigaChat: подключаем языковую модель без собственного SDK

Spring AI GigaChat пригодится, если вы используете Spring Boot и хотите добавить GigaChat в Java- или Kotlin-приложение: например, сделать поиск с ответами по документации, помощника с историей диалога или агента, вызывающего функции приложения. Интеграция позволяет использовать интерфейсы Spring AI и готовые компоненты его экосистемы, а не собирать отдельный клиент для каждого сценария.

В одной из команд Сбера такая потребность появилась при создании ИИ-агентов для внутренних задач. Прямой HTTP-запрос к модели решал только первый шаг. Для полноценного приложения нужны были история сообщений, поиск по документам, векторные хранилища, вызов функций, потоковая генерация и наблюдаемость. Поддержка собственного слоя интеграции потребовала бы отдельной работы.

Вместо этого разработчики выбрали Spring AI — фреймворк, предоставляющий общие интерфейсы для работы с генеративными моделями и связанные компоненты. Оставалось встроить в эти абстракции особенности GigaChat, которых не хватало в стандартных интерфейсах. Сам Spring AI в тот период активно развивался, и изменения его API влияли на совместимость интеграции.

Решение оформили как Spring Boot Starter. Он связывает компоненты Spring AI с API GigaChat и позволяет использовать модель через привычные абстракции фреймворка. Архитектурно цепочка выглядит так: Spring Boot-приложение → Spring AI GigaChat Starter → GigaChat API.

Через стартер и компоненты экосистемы Spring AI можно использовать:

• ChatClient для диалогов с моделью;

• EmbeddingModel для получения эмбеддингов;

• VectorStore и Advisors для организации поиска по документам и работы с историей диалога;

• вызов функций и подключение инструментов через Model Context Protocol (MCP);

• наблюдаемость, включая метрики и трейсы.

Библиотека поддерживает синхронные запросы и потоковое генерирование, работу с файлами и изображениями, вызов функций и MCP. При этом разработчик не обязан самостоятельно реализовывать каждый из этих механизмов поверх HTTP API.

С помощью аннотации @GigaTool можно описать в Java-методах функции, которые модель может вызывать в ходе работы. Дополнительные параметры позволяют передавать настройки, специфичные для GigaChat. Это упрощает интеграцию инструментов агента с существующим приложением: бизнес-логика остаётся обычным кодом на Java, а взаимодействие с моделью проходит через инфраструктуру Spring AI.

Для примера ниже используем стартер 2.0.1. В README для него указаны Java 17+, Spring Boot 4.1 и Spring AI 2.0.1. Перед подключением проверьте таблицу совместимости для своей версии приложения.

Для проекта, использующего Gradle, зависимость можно объявить так:

dependencies { implementation( "chat.giga:spring-ai-starter-model-gigachat:2.0.1" ) }Затем в application.yml задаём ключ API и модель. Значение scope выбираем для своего типа доступа к GigaChat API:spring: ai: gigachat: auth: bearer: api-key: ${GIGACHAT_API_KEY} scope: GIGACHAT_API_PERS chat: options: model: GigaChat-3-Ultra

После настройки модель можно вызвать через ChatClient:

@Bean CommandLineRunner runner(ChatClient.Builder builder) { return args -> { ChatClient chatClient = builder.build(); String answer = chatClient .prompt("Кратко объясни, что такое RAG") .call() .content(); System.out.println(answer); }; }

То есть идея в том, что разработчик пишет запрос через API Spring AI, не заботясь о низкоуровневых подробностях вызова GigaChat.

В реальном проекте нужно также настроить авторизацию и доверие сертификатам сервера. Подробности и варианты конфигурации описаны в README репозитория

Обновления Spring AI могут влиять на совместимость интеграции, поэтому версии зависимостей стоит подбирать вместе.

Репозиторий: Spring AI GigaChat на GitVerse.

Schedulex сохраняет фоновые задачи при перезапуске

Третья история связана не с ИИ, а с одной из классических проблем распределённых систем: «Как надёжно выполнять работу, которая выходит за пределы текущего HTTP-запроса?» Например, сервис изменил статус заказа и должен отправить событие другому сервису. Или требуется повторить неудачный интеграционный вызов. Или бизнес-процесс должен дождаться оплаты, ответа внешней системы либо истечения тайм-аута. На первый взгляд, достаточно запустить фоновую задачу. Но если приложение перезапустится, то задача не должна потеряться. А если бизнес-данные уже изменились, то связанное с ними событие нужно доставить согласованно с этим изменением.

Предположим, сервис обновляет заказ в базе данных, а затем создаёт фоновую задачу для отправки события. Если эти действия не объединены общей транзакцией, то между ними возникает окно сбоя. Заказ уже изменён, а задача ещё не создана. После падения приложения событие может так и не уйти.

Возможен и обратный сценарий: фоновая задача зарегистрирована, но бизнес-транзакция откатилась. Тогда обработчик выполняет работу, основанную на изменении, которого в базе в итоге нет.

Так появилась Schedulex — JVM-библиотека для фоновых задач и долгоживущих процессов. Автор хотел совместить несколько требований: участие в транзакциях приложения, восстановление после сбоев, удобный API для Java и Kotlin, поддержку корутин и возможность обходиться без отдельного сервиса оркестрации. Состояние выполнения хранится в реляционной базе данных. Несколько экземпляров приложения могут совместно обрабатывать задачи, а после сбоя — подхватывать оставшуюся работу.

В библиотеке предусмотрены три модели:

• Task подходит для отдельной операции, в том числе с повторными попытками;

• Workflow позволяет явно описать процесс в виде графа шагов;

• CodeFlow позволяет описывать процесс обычным кодом: использовать условия, циклы, параллельные ветви и ожидание событий.

Для простой отложенной операции не требуется конструировать полноценный процесс, а для сложного сценария не обязательно вручную собирать управление состояниями из множества независимых обработчиков.

Ключевой архитектурный принцип — общая транзакционная граница между бизнес-данными и фоновой работой. Изменение данных и создание задачи можно зафиксировать одной транзакцией. Аналогично бизнес-изменение можно объединить с завершением задачи.

Изменение в базе данных и запись об успешном выполнении шага фиксируются вместе. Если транзакцию откатят, то система не оставит в базе половину логической операции. А если транзакция успешно завершилась, то состояние задачи будет согласовано с соответствующим изменением бизнес-данных.

Здесь важно понимать, что общая транзакция защищает операции только в одной базе данных. Она не делает автоматически атомарным HTTP-вызов или обращение к внешнему сервису. Для таких действий по-прежнему нужна идемпотентность и корректная обработка повторов.

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

Kotlin-корутины помогают описывать ожидания и конкурентные ветви без необходимости удерживать отдельный поток на каждое ожидание. При этом устойчивость к перезапускам обеспечивается не сохранением корутины в памяти, а журналом и состоянием в базе данных.

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

Schedulex уже используется в семи системах, в том числе командами за пределами первоначального проекта. Мы пока не измеряли, насколько эта библиотека ускоряет разработку, но команды применяют её в системах, где важна надёжная фоновая работа, согласование с бизнес-транзакциями и восстановление после сбоев.

По данным автора, в локальном тесте производительности обработка 300 тысяч независимых задач заняла около 9,8 секунды — примерно 30,7 тысячи выполнений в секунду. Тест проводили на Макбуке с процессором M5 Pro, база данных PostgreSQL, 48 потоков обработчиков и 49 JDBC-соединений. Обработчики были пустыми, задачи подготовили заранее, а измеряли с учётом устойчивого завершения задач в базе.

Этот результат относится к тесту с пустыми обработчиками и заранее созданными задачами; по нему нельзя оценить пропускную способность прикладной системы с реальной бизнес-логикой.

Schedulex можно рассмотреть для таких сценариев:

• transactional outbox и доставка событий;

• отложенные и периодические операции;

• повторные попытки интеграционных вызовов;

• последовательная обработка задач по бизнес-ключу;

• процессы, ожидающие внешнего ответа.

Для Spring Boot предусмотрена автоконфигурация: нужно подключить зависимости, применить миграции и объявить обработчик. Для приложений без Spring доступна программная сборка. Встроенные диалекты есть для PostgreSQL и H2.

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

Как соотносится с альтернативами?

Для долгоживущих процессов есть Temporal: он восстанавливает выполнение по истории событий и использует Temporal Service вместе с процессами-воркерами. Сервис можно эксплуатировать самостоятельно или использовать Temporal Cloud. Schedulex, по описанию автора, встраивается в JVM-приложение и позволяет объединить запись задачи с изменением бизнес-данных в одной транзакции общей базы. Это различие в архитектуре и эксплуатации, которое стоит оценить при выборе.

Если нужны прежде всего отложенные и периодические задания, среди альтернатив стоит оценить Quartz и db-scheduler. Quartz также поддерживает JTA-транзакции и кластеризацию. В Schedulex интерес представляет сочетание задач, графовых процессов и CodeFlow в одной библиотеке с интеграцией в транзакции приложения. Сравнивать решения стоит на собственных сценариях восстановления, повторов и миграции процессов.

Репозиторий: Schedulex на GitVerse.

С чего начать и как предложить изменения?

Для первого знакомства выберите один небольшой сценарий и проверьте инструмент на нём. Точки входа собрали в таблице.

Проект

Репозиторий

Первый шаг

HG SDLC

GitVerse

Изучить README и запустить простой процесс

Spring AI GigaChat

GitVerse

Подключить стартер и выполнить первый запрос

Schedulex

GitVerse

Изучить примеры для Java, Kotlin, корутин и транзакций

Если при проверке инструмента нашли ошибку, создайте issue в его репозитории: укажите версию, шаги воспроизведения, ожидаемый и фактический результат. Так команде будет проще разобраться в проблеме.

Хотите предложить изменение кода или документации?

Для HG SDLC начните с CONTRIBUTING. В Spring AI GigaChat pull request по умолчанию направляют в ветку main. Перед отправкой проверьте правила проекта, совместимость версий и необходимые проверки.

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

Следите за нашими обновлениями!

Источник: habr.com