Como automatizar a avaliação de agentes de IA no CI/CD com Amazon Bedrock AgentCore

Você colocou um agente de IA em produção no Amazon Bedrock AgentCore, ele chama ferramentas por um servidor MCP protegido por OAuth, e agora quer que o CI avise quando uma mudança de código piora o desempenho — antes de chegar à produção. Esse é o problema que a AWS resolveu em um passo a passo detalhado: um pipeline de GitHub Actions que implanta o agente, avalia com prompts de teste e bloqueia o pull request quando a qualidade cai.

Por que isso importa

Sem avaliação automatizada, a qualidade de um agente é subjetiva. Um desenvolvedor muda o system prompt, o agente começa a dar respostas piores e ninguém percebe até os usuários reclamarem. Um quality gate captura essa regressão no momento do PR.

O desafio do OAuth no CI

O nó da questão: pipelines de CI não têm contexto de usuário. O servidor MCP espera um JWT com claims de papéis, mas um runner headless não consegue completar o fluxo interativo de consentimento OAuth. A AWS apresenta três abordagens:

• A — Avaliar traces armazenados: um pipeline de staging roda o agente, captura os traces e os commita como fixtures JSON. No PR, o CI avalia esses traces, sem invocação ao vivo. É determinístico e contorna o OAuth, mas avalia o comportamento do staging, não o código do PR atual.
• B — Conta de serviço com consentimento pré-autorizado: um usuário de teste completa o consentimento uma vez, e o refresh token fica no Secrets Manager. Testa o fluxo completo com papéis, mas exige rotação de tokens.
• C — Autenticação M2M (a abordagem do post): o servidor MCP aceita tanto tokens de máquina (M2M, via client_credentials) quanto tokens de usuário. Tokens M2M contêm escopos mas não papéis, então pulam a checagem de papéis; tokens de usuário carregam custom:roles e têm acesso restrito por ferramenta.

Autenticação em três camadas

Para a abordagem C funcionar, o servidor MCP usa três camadas: validação de JWT na plataforma (o AgentCore valida assinatura, issuer e expiração antes de o código rodar), passthrough do header (o Authorization é encaminhado intacto aos containers) e controle de acesso por papel no middleware (um AuthMiddleware lê o JWT, decodifica os claims e aplica custom:roles contra o meta de cada ferramenta).

Os avaliadores

O AgentCore pontua interações usando LLM como juiz, operando sobre traces OpenTelemetry. Os avaliadores embutidos cobrem dimensões como Helpfulness, Correctness, GoalSuccessRate, ToolSelectionAccuracy e ToolParameterAccuracy — este último essencial para agentes com ferramentas MCP, pois verifica se o agente escolheu a ferramenta certa com os parâmetros corretos. Também há avaliadores customizados, baseados em código (Lambda) e de terceiros (DeepEval, AutoEval).

Lições do teste de ponta a ponta

• Para invocar runtimes protegidos por OAuth, use POST direto no endpoint HTTPS com Bearer token, não o método invoke_agent_runtime() do boto3.
• A propagação de traces leva de 30 a 90 segundos — o script de avaliação faz retry a cada 30 segundos por até 10 minutos.
• O runtime exige imagens ARM64, mas os runners do GitHub são x86_64 — use QEMU + Docker Buildx.
• Invocações antes de o runtime ficar READY falham com 424 Failed Dependency.
• Timestamps OpenTelemetry em nanossegundos devem ser inteiros JSON, não strings, ou você recebe ValidationException.

Limitações a considerar

O pipeline leva cerca de 10 minutos (implante CDK + startup + propagação de traces + avaliação) — ótimo para gates de PR, lento demais para pre-commit. O LLM como juiz tem variância inerente: o mesmo trace avaliado duas vezes pode dar scores ligeiramente diferentes, então defina o threshold com margem. E cada rodada gera custo de chamadas ao modelo juiz (quatro avaliadores × cinco prompts = 20 chamadas por PR). Ainda assim, avaliação automatizada — mesmo imperfeita — é estritamente melhor do que nenhuma avaliação.