Sber apresenta três ferramentas de código aberto para agentes de IA e aplicações JVM

Um agente de IA escreveu o código, mas perdeu de vista as restrições de arquitetura. Um serviço atualizou um pedido e caiu antes de enviar o evento, deixando um sistema conectado sem saber da mudança. O resumo da Sber apresenta três ferramentas de código aberto para problemas de engenharia como esses: HG SDLC, Spring AI GigaChat e Schedulex. Elas atendem a diferentes partes do trabalho: transferir contexto entre agentes, conectar um modelo a uma aplicação e executar tarefas em segundo plano após falhas.

A maneira mais útil de ler esse anúncio é partir de uma pergunta concreta: que parte da infraestrutura a equipe mantém por conta própria hoje, e um projeto existente poderia reduzir esse trabalho? A descrição publicada traz detalhes técnicos suficientes para uma avaliação inicial. Mas as estimativas de eficiência continuam sendo afirmações dos autores.

HG SDLC: entregar ao agente uma tarefa junto com seu contexto

Imagine uma melhoria rotineira: um analista preparou os requisitos, um desenvolvedor escolheu a arquitetura, um agente alterou o código e os testes encontraram um erro. Agora é preciso devolver a tarefa para ajustes, garantindo que o agente receba os requisitos, as restrições e os resultados dos testes. Se tudo isso estiver espalhado por diferentes conversas, uma pessoa terá de manter a continuidade do processo.

O HG SDLC permite descrever o fluxo de trabalho como um grafo YAML. Ele contém nós com tarefas para os agentes, verificações automáticas e pontos em que uma pessoa toma a decisão. O orquestrador armazena o contexto, os artefatos e o histórico de execução, gerencia as transições e permite devolver o trabalho a uma etapa anterior.

Segundo a equipe, a ferramenta funciona sobre agentes de programação compatíveis com o Agent Client Protocol. Os requisitos indicados para execução local são Java 21, Node.js 22, PostgreSQL e um agente compatível. É um componente de infraestrutura separado, que também precisará de configuração e manutenção.

Os autores estimam um ganho de eficiência no desenvolvimento de 16–30% com a combinação de agentes, desenvolvimento orientado por especificações e HG SDLC. Eles não conseguem isolar a contribuição do próprio orquestrador. Portanto, seria prematuro tratar esse número como uma promessa de aceleração para a equipe. O primeiro ponto a verificar é quantas transferências manuais de contexto realmente deixam de ser necessárias.

Spring AI GigaChat: integrar um modelo a uma aplicação existente

O segundo projeto é voltado a equipes que usam Java ou Kotlin e Spring Boot. Escrever uma requisição direta ao modelo é simples. Depois surgem o histórico da conversa, a busca em documentos, as chamadas de funções, as respostas em streaming e as métricas. Manter tudo isso em uma camada de integração separada rapidamente se torna uma tarefa por si só.

O Spring AI GigaChat é distribuído como um Spring Boot Starter e conecta a API do GigaChat às interfaces do Spring AI. A aplicação acessa o modelo por meio do ChatClient, enquanto componentes relacionados do ecossistema ajudam a gerenciar documentos, histórico de mensagens e ferramentas.

Um caso de uso claro é um assistente de documentação interna que responde a um funcionário e, quando necessário, chama uma função da aplicação. A lógica de negócio continua em código Java; a integração com o modelo passa pelo Spring AI. O artigo também descreve a anotação @GigaTool para declarar as funções disponíveis ao modelo.

Antes da integração, é necessário verificar a compatibilidade entre as versões do starter, do Spring Boot e do Spring AI. Os autores destacam especificamente o impacto das mudanças na API sobre a integração. A biblioteca de código aberto também não elimina a necessidade de configurar o acesso à API do GigaChat e a confiança nos certificados do servidor.

Schedulex: sobreviver a reinicializações e preservar a consistência dos dados

A terceira ferramenta cuida do trabalho em segundo plano na JVM. O exemplo central é um serviço que altera o status de um pedido e cria uma tarefa para enviar um evento em uma única transação de um banco de dados compartilhado. Se houver rollback, nenhuma das alterações será salva. Após um commit bem-sucedido, o registro da tarefa permanecerá no banco, mesmo que a aplicação seja reiniciada.

O Schedulex oferece tarefas individuais, grafos de processos e CodeFlow: uma forma de descrever um processo com código convencional, condições, esperas e ramificações paralelas. Segundo os autores, a recuperação do CodeFlow se apoia em um log dos resultados das etapas e no estado armazenado no banco de dados. Ao atualizar a aplicação, é preciso considerar a compatibilidade do novo código com o histórico salvo.

O limite da garantia é fundamental: uma transação de banco de dados não torna uma chamada HTTP externa atômica. Se o destinatário processou a requisição, mas o remetente não conseguiu registrar o sucesso, uma nova tentativa pode gerar uma duplicidade. Por isso, operações externas precisam de idempotência: a capacidade de processar com segurança uma requisição repetida.

Os autores relatam cerca de 30,7 mil execuções por segundo, mas com handlers vazios e tarefas criadas antecipadamente. Isso não é uma previsão do desempenho de um serviço real.

O próximo passo prático é escolher um cenário problemático: perda de contexto, integração do modelo ou reinicialização de um processo em segundo plano. Testá-lo dará uma base mais sólida para a escolha do que um número geral de aceleração.