AWS deixa o agente de IA reprovar no pull request

AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → publicou uma implementação de referência que testa agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → dentro do GitHub Actions. O fluxo executa avaliações automáticas no meio do pipeline de CI/CD. Além disso, ele interrompe a execução quando a nota do agente fica abaixo de um limite configurado. Na prática, o comportamento do agente passa a ser tratado como qualquer outra verificação antes do merge.

AWS coloca o agente na mesma fila do lint

O time já conhece o ritual. Testes rodam, o lint reclama, a build quebra e o merge trava. Agora o agente entra nessa mesma fila. Para isso, o repositório configura a tarefa de avaliação como verificação de status obrigatória do GitHub. Em seguida, proteção de branch ou rulesets impedem que alguém mescle a alteração com a checagem falhando.

A base técnica é o Amazon Bedrock AgentCore Evaluations. Ele avalia o agente depois de mudanças no código, no prompt do sistema, no modelo ou na configuração de ferramentas. O exemplo, publicado em 8 de setembro, implanta o agente em ambiente de desenvolvimento, invoca com prompts de teste e avalia os rastreamentos gerados. Depois, devolve o resultado para o workflow.

Vale lembrar que as Avaliações do AgentCore chegaram ao público geral em 31 de março de 2026. Desde então, a empresa aponta a avaliação sob demanda como caminho para testes de regressão em pipeline.

Quatro avaliadores decidem o destino do seu merge (AWS)

O pipeline de referência usa um agente Strands rodando no AgentCore Runtime. Ele se conecta a um servidor MCP, enquanto o código em CDK provisiona runtime, recursos do Cognito e roles do IAM.

Quando a tarefa roda, ela sobe o ambiente e invoca o agente com prompts definidos antes. Os rastreamentos OpenTelemetry saem do CloudWatch e vão para o AgentCore Evaluations.

São quatro avaliadores nativos: GoalSuccessRate, Correctness, ToolSelectionAccuracy e ToolParameterAccuracy. Ou seja, o teste cobre conclusão da tarefa, qualidade da resposta, escolha da ferramenta e origem dos parâmetros. Cada verificação recebe nota separada.

AWS mostra o que quebra quando o prompt muda

A empresa montou uma regressão proposital para demonstrar o efeito. Ela alterou o prompt do sistema e observou o resultado. Três avaliadores falharam: GoalSuccessRate, Correctness e ToolParameterAccuracy. Enquanto isso, o ToolSelectionAccuracy continuou passando.

Esse detalhe importa para quem depura agente em produção. Afinal, a ferramenta certa ainda pode ser chamada com o parâmetro errado. O limite do exemplo está em 0,8. Quando alguma métrica cai abaixo disso, o script encerra com falha. Depois de restaurar o prompt original, as quatro avaliações passaram.

Da checagem solta para uma suíte de regressão de verdade

Cinco prompts fixos resolvem uma demo. Porém, uma suíte de regressão pede bem mais. Por isso, o AgentCore traz avaliação por dataset, hoje em prévia pública.

O schema aceita resposta esperada, asserções em linguagem natural e trajetória esperada de ferramentas. Assim, cada campo se conecta a uma checagem diferente. Correctness compara a resposta gerada com a esperada, GoalSuccessRate avalia asserções da sessão e os avaliadores de trajetória confrontam as chamadas reais com o caminho previsto.

Existem três modos de trajetória: ordem exata, ordem parcial e qualquer ordem. Além disso, dá para versionar datasets. O Draft atual vira uma versão numerada e imutável, enquanto a edição continua no rascunho.

Outro ponto prático: a avaliação olha a sessão inteira, um trace específico ou spans de chamada de ferramenta.

AWS avisa que o juiz de LLM tem variância

Modelos grandes são não determinísticos. A mesma requisição gera caminhos de execução e saídas diferentes entre execuções. Consequentemente, o mesmo rastreamento recebe notas ligeiramente distintas em avaliações repetidas.

A recomendação é direta: deixe margem ao definir o limite. Checagens de trajetória escapam desse problema, já que usam comparação programática sem chamar modelo. Avaliadores personalizados em Lambda, escritos em Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → ou JavaScript, entregam regras determinísticas para o caso específico do seu app.

O custo real de rodar isso a cada pull request

O exemplo completo leva cerca de 10 minutos. Deploy, inicialização do runtime, propagação de rastreamento e avaliação acontecem tudo dentro do workflow. Só a propagação consome de 30 a 90 segundos nos testes. Por isso, a implementação tenta coletar o trace a cada 30 segundos, por até 10 minutos.

Existe também o custo por token. Quatro avaliadores rodando cinco prompts geram 20 invocações de modelo por pull request. Essas chamadas entram na conta do Bedrock. Logo, trajetória e avaliadores em código ajudam a segurar o gasto.

Um alívio para o bolso: o workflow destrói a stack de desenvolvimento ao fim da tarefa, inclusive quando a avaliação falha.

A saída para quem prefere manter o agente fora do PR

A documentação registra um segundo caminho. O time captura rastreamentos representativos em staging e avalia os spans armazenados na CI. Dessa forma, o pull request dispensa a invocação do runtime vivo. Ainda assim, fica um alerta: essa avaliação olha o comportamento capturado no staging, então o código do pull request atual permanece fora do escopo.

Na autenticação, o pipeline usa OpenID Connect do GitHub Actions para assumir uma role do IAM. Assim, credenciais de longa duração ficam fora do repositório. Quando o agente precisa de ferramentas MCP protegidas por OAuth, o exemplo obtém um token máquina a máquina via Cognito. Vale o aviso da própria empresa: a configuração de exemplo libera todas as ferramentas ao pipeline e deixa controles de acesso por papel sem teste.

Por onde começar na segunda de manhã

Primeiro, escolha de cinco a dez cenários que representam o uso real do agente. Depois, defina trajetórias esperadas para os fluxos críticos. Assim, você reduz a dependência de juiz de LLM logo de cara.

Em seguida, ajuste o limite com margem para a variância. Por fim, ative a verificação de status obrigatória apenas quando a suíte estiver estável. Do contrário, o time aprende rápido a ignorar a checagem vermelha.

Agente de IA em produção envelhece a cada troca de modelo, prompt ou ferramenta. Com avaliação no pipeline, essa mudança aparece no pull request. Sem ela, aparece no cliente.

Acompanhe nosso perfil no Instagram!