Como treinar um agente LLM de infraestrutura para não mentir

Foi construído um agente LLM interno somente leitura para responder a perguntas de infraestrutura como 'por que o serviço está retornando 502?'. Ele usou Go, sem LangChain, e chamou os modelos DeepSeek-V4-Flash e Qwen3.6-27B-FP8 por meio de API compatível com OpenAI. A primeira versão usava um loop ReAct livre e produzia respostas formalmente corretas, mas frequentemente enganosas. Por exemplo, quando um erro 502 era causado por um cabeçalho de resposta superdimensionado no proxy, o agente concluía 'nenhum erro no nível da aplicação', perdendo a causa real. Foram identificadas cinco classes de erros: escopo errado, semântica temporal errada, conclusões negativas erradas, perda de evidências e replanejamento não controlado. A solução foi incorporar o LLM dentro de um framework de aplicação estrito. As chamadas de ferramentas são governadas por um contrato estendido x-agent que define evidência, tipo de saída, atualidade, semântica negativa e status somente leitura. O planejador primeiro constrói objetivos (por exemplo, symptom.http_502, route.edge_to_ingress) e uma condição de parada: todo objetivo obrigatório deve ser resolvido ou explicitamente indisponível. Um guardião de evidência impede que o finalizador conclua antes que todos os objetivos sejam atendidos. A seleção de ferramentas é feita em etapas: filtro de política, pré-filtro lexical, reranqueamento LLM (top 8) e, em seguida, porta de relevância do objetivo. Intenções arriscadas têm pré-rotas determinísticas. Na avaliação final, 44 de 45 cenários passaram (29 de 29 obrigatórios), executados duas vezes cada. O único teste que falhou foi um formato opcional de relatório de capacidade. O agente permanece somente leitura; humanos decidem sobre mudanças em produção.