Spring AI Alibaba: o loop do agente deve terminar por regra, não por esperança
Grafos separam estado, geração e avaliação. O desenho útil é aquele que preserva feedback e encerra tentativas com um resultado explícito.
Um tutorial da Baeldung apresenta workflows de agentes com Spring AI Alibaba organizados como grafos: nós executam etapas, um estado transporta dados e arestas escolhem o próximo caminho.[6] O exemplo alterna geração e avaliação, encerrando quando a nota chega a 0,8 ou após três tentativas.[6]
Esse segundo critério é mais importante para a operação do que a aparência inteligente da resposta. A aplicação precisa saber quando parar mesmo se o avaliador nunca ficar satisfeito. Uma automação sem saída de falha definida ainda não tem um contrato completo.
O que muda para quem desenvolve
No exemplo, respostas, notas e contagem de tentativas usam atualização por substituição, enquanto os feedbacks do avaliador são acumulados em uma lista.[6] Os nós implementam NodeAction, recebem OverAllState e devolvem um mapa com as mudanças desejadas.[6] A continuidade fica em um EdgeAction, separado do código de geração.[6]
O benefício de engenharia é tornar explícita a diferença entre conteúdo e controle. O modelo pode propor uma nova resposta, mas a aplicação conserva a responsabilidade de decidir se existe orçamento para outra tentativa e se os critérios foram atendidos.
A estratégia de atualização também merece revisão como parte do domínio. Sobrescrever o feedback anterior dificultaria entender por que o agente insistiu numa direção. Por outro lado, acumular qualquer informação indefinidamente pode criar um estado que ninguém consegue inspecionar. Defina quais dados precisam de histórico e quais representam somente a situação atual.
Como aplicar
Adapte o desenho a uma tarefa estreita, como preparar documentação de um endpoint. Separe geração, validação de estrutura e avaliação de conteúdo. Para requisitos objetivos, como presença de campos obrigatórios, prefira um validador determinístico antes de pedir julgamento a outro modelo.
O avaliador do tutorial usa uma saída estruturada com texto e nota.[6] No seu contrato, acrescente razões de rejeição e um estado terminal que diferencie aprovado, limite de tentativas, prazo excedido e falha de serviço. Não converta todos esses casos numa resposta HTTP de sucesso indistinguível.
Um experimento verificável é substituir inicialmente o modelo por respostas programadas. Faça o avaliador rejeitar todas as versões e confirme que o fluxo termina no limite configurado. Em outro caso, aprove a segunda versão e verifique a contagem e a preservação do primeiro feedback. Depois introduza a chamada real, mantendo os mesmos testes do controle.
Estabeleça ainda um prazo máximo e um orçamento que inclua as chamadas de geração e de avaliação. O limite de iterações sozinho não descreve todo o consumo. Registre o motivo de cada transição para investigar falhas sem reconstruir a sessão a partir de texto livre.
Cuidados e limites
A demonstração simula justificativas de um funcionário avaliadas por um gerente e expõe um endpoint /excuse.[6] É um veículo didático para mostrar o ciclo, não uma recomendação de processo empresarial. As saídas ilustrativas não garantem comportamento determinístico do LLM.[6]
Cada requisição recebe um threadId aleatório na configuração apresentada.[6] Não trate esse identificador como substituto de autorização ou isolamento entre usuários. Esses controles precisam de desenho próprio.
Uma nota produzida pelo modelo também não deve virar prova automática de qualidade. O grafo torna o processo visível e limitado; a validade do critério de avaliação continua sendo responsabilidade de quem constrói o serviço.