Como testar um agente de IA pelas ferramentas usadas e pelo estado final

O que você vai levar deste guia

• Escreva estados finais e ações proibidas para cada cenário.
• Aceite caminhos equivalentes sem exigir uma sequência única por conveniência.
• Use ambientes e ferramentas de teste que permitam simular falhas sem efeitos reais.

Defina a tarefa como uma mudança verificável

Uma avaliação de agente começa descrevendo o resultado que deve existir fora da conversa. Se a tarefa é reagendar uma visita, o estado esperado inclui a visita certa, o novo intervalo e as condições necessárias à alteração. “O agente respondeu educadamente” pode ser uma qualidade importante, mas não prova que o trabalho aconteceu. Da mesma forma, uma mudança correta não basta se foi realizada sem a autorização necessária ou em um recurso diferente do solicitado.

Considere o exemplo fictício da empresa Serviço Próximo, que prepara um agente para organizar retornos de manutenção. Em um cenário de teste, a pessoa pede para mover a visita da unidade leste para uma data disponível, preservando o técnico responsável. A avaliação precisa conferir qual visita foi encontrada, se a disponibilidade foi consultada e qual alteração ficou registrada. Uma frase como “pronto, reagendei” só é válida se corresponder ao resultado confirmado pelas ferramentas.

O Google Cloud descreve avaliação de agentes considerando tanto a resposta final quanto a trajetória de ações e chamadas. O método deste tutorial usa essa distinção e acrescenta verificações operacionais do estado de teste. Não depende de um fornecedor específico: o importante é conseguir observar o que o agente recebeu, decidiu, chamou e deixou registrado, com critérios definidos antes da execução.

Prepare cenários com contexto suficiente e incertezas deliberadas

Cada cenário deve incluir pedido, estado inicial, permissões, recursos disponíveis e comportamento das ferramentas. Use dados fictícios coerentes, com identificadores distintos e relações conhecidas. Se houver duas visitas parecidas, declare qual informação permite diferenciá-las ou marque que o agente deve pedir esclarecimento. Não resolva toda ambiguidade na descrição interna enquanto o pedido visível continua ambíguo; isso cria uma referência impossível para o agente e distorce a avaliação.

No exemplo, uma variante contém duas unidades chamadas Centro. O comportamento esperado é esclarecer qual delas, não adivinhar pela primeira resposta da busca. Outra variante identifica a visita de forma completa, e pedir confirmação de dados já suficientes pode representar atrito desnecessário. A avaliação deve distinguir falta real de informação de hesitação excessiva. Autonomia adequada significa avançar quando as condições estão atendidas e parar quando a decisão depende de uma informação ausente.

Crie famílias de casos: caminho normal, recurso ausente, múltiplos candidatos, indisponibilidade, mudança concorrente e autorização insuficiente. Inclua pedidos que não exigem ferramenta, como explicar o horário de atendimento a partir de informação já fornecida, quando isso fizer parte do escopo. Um agente que consulta serviços para toda frase pode aumentar custo e exposição sem melhorar o resultado. O conjunto deve representar a distribuição de uso e reservar espaço para falhas de maior consequência.

Escreva invariantes e ações proibidas

Para cada cenário, registre o que precisa permanecer verdadeiro. A visita deve continuar vinculada à mesma empresa; uma alteração não pode criar uma segunda visita; um horário indisponível não deve ser confirmado. Esses invariantes são mais robustos que exigir uma frase específica. Eles permitem reconhecer caminhos válidos diferentes e localizar efeitos que uma avaliação textual deixaria passar. Inclua também o que não pode acontecer, como alterar o técnico quando o pedido exige preservá-lo.

Separe pré-condições de preferências. Consultar disponibilidade antes de confirmar pode ser uma dependência obrigatória do contrato. Fazer uma segunda consulta de leitura depois da confirmação pode ser opcional se a própria ferramenta já retorna o estado confirmado. Exigir chamadas redundantes em todos os testes ensina um caminho mais caro sem necessidade. A trajetória de referência deve representar a lógica indispensável, não uma gravação arbitrária da primeira execução que funcionou.

Defina efeitos proibidos mesmo quando o estado final parece correto. Um agente que apaga e recria a visita pode acabar com data e técnico esperados, mas perder histórico ou disparar notificações indevidas. O teste precisa observar essas ações intermediárias. No Serviço Próximo fictício, reagendamento deve preservar a identidade da visita. Essa regra transforma uma diferença de implementação em um critério explícito, porque a continuidade do histórico é parte da tarefa.

Use ferramentas de teste com respostas e efeitos controlados

Prepare adaptadores que representem os contratos reais sem enviar mensagens ou alterar operações de clientes. A ferramenta de teste deve validar argumentos, modificar um estado isolado quando apropriado e registrar o resultado. Respostas sempre positivas escondem grande parte da dificuldade. Inclua erros de validação, ausência de recurso, demora e confirmação incerta conforme os cenários. O propósito é avaliar a reação do agente, não apenas verificar se ele sabe escolher o nome de uma função.

Mantenha fidelidade ao contrato que será usado. Se a ferramenta real exige um identificador e devolve um estado específico, o simulador não deve aceitar qualquer texto e inferir o resto. Essa permissividade cria agentes que passam no laboratório e falham na integração. Ao mesmo tempo, não reproduza detalhes irrelevantes que tornem os testes frágeis. Registre quais comportamentos foram simulados e quais ainda exigem validação com o serviço de teste do fornecedor.

Reinicie o estado entre execuções ou mantenha isolamento explícito por caso. Uma visita alterada em um teste não deve influenciar outro sem que essa dependência seja intencional. Guarde a semente ou a descrição do cenário quando houver variação de dados, permitindo reproduzir falhas. Nenhuma chamada de avaliação deve alcançar um destino real por uma configuração herdada. Verifique o isolamento antes de rodar lotes, especialmente se o agente dispõe de ferramentas que produzem efeitos externos.

Avalie argumentos e decisões em cada fronteira

Confira se o agente escolheu a ferramenta adequada e se seus argumentos correspondem ao pedido e aos resultados anteriores. Um nome de ferramenta correto com identificador de outra visita é uma falha material. Uma data no formato aceito pode ainda representar o dia errado por interpretação de contexto. Compare valores com o cenário e com as regras do negócio. Não reduza qualidade de chamada à validação sintática do objeto enviado.

Observe como o agente usa respostas. Se a consulta informa indisponibilidade, a próxima ação precisa respeitar esse fato. Se aparecem dois candidatos, não deve selecionar um sem base suficiente. Se uma ferramenta devolve conteúdo textual externo, esse conteúdo deve ser tratado conforme sua função de dado, sem ganhar autoridade para mudar o escopo da tarefa. Inclua cenários em que uma descrição de registro contém instruções estranhas, verificando que o agente mantém as regras e o pedido legítimo.

Identifique tentativas desnecessárias e ciclos. Uma ferramenta que retorna o mesmo erro de validação não deve ser chamada repetidamente com os mesmos argumentos sem nova informação. Defina um limite de trabalho por cenário e registre por que a execução terminou. Encerrar com uma explicação honesta pode ser o resultado correto diante de uma limitação. Declarar sucesso para evitar admitir falha é um problema distinto e deve aparecer na classificação.

Confira o estado final e a fidelidade da comunicação

Depois da execução, consulte o estado isolado de forma independente da resposta do agente. Verifique identidade, campos alterados, relações e quantidade de efeitos. Essa checagem não deve confiar apenas no resumo produzido pelo próprio sistema avaliado. No exemplo fictício, o verificador confirma que a visita original mudou de intervalo, manteve o técnico e não gerou outra visita. Se a ferramenta registra tentativas e confirmações separadas, confira qual delas representa o efeito real.

Compare a resposta final com esse estado. O agente deve distinguir concluído, pendente e não realizado. Se houve uma falha após confirmação incerta, a mensagem não pode inventar certeza. Também não deve afirmar que nenhuma mudança aconteceu quando a ferramenta confirmou o efeito. Essa fidelidade é essencial para a operação decidir se precisa agir manualmente. Um erro de comunicação pode produzir trabalho duplicado mesmo quando a ação técnica foi correta.

Avalie clareza sem impor uma redação única. A resposta pode ser curta e suficiente se informa a visita, a data confirmada e uma limitação relevante. Não penalize sinônimos nem exija frases de cortesia específicas, salvo quando fazem parte de uma necessidade do produto. O foco é saber se a pessoa entende o que aconteceu e o próximo passo. A Tironi Tech pode integrar verificadores de estado e revisão de comunicação para que a avaliação acompanhe o processo completo.

Compare versões com repetição e critérios de gravidade

Agentes podem variar entre execuções, então uma única passagem não caracteriza bem a confiabilidade de um cenário difícil. Repita casos selecionados em condições registradas e observe distribuição de resultados. A quantidade necessária depende do objetivo e dos recursos disponíveis; apresente o número de execuções e evite concluir estabilidade a partir de uma amostra mínima. Preserve versões de instruções, ferramentas e modelo para explicar diferenças entre experimentos.

Classifique falhas por consequência. Alterar a empresa errada não deve ser compensado por respostas elegantes em vários casos simples. Defina critérios que bloqueiam a liberação e critérios de qualidade que podem ser melhorados depois, conforme o escopo de uso. Mostre taxas por família e exemplos revisados. Uma média agregada pode esconder uma falha rara e grave, especialmente quando o conjunto contém muitos pedidos fáceis e poucos casos de autorização ou ambiguidade.

Quando usar avaliação automática de linguagem, confronte amostras com revisão humana e verificações determinísticas de estado. Um avaliador pode se impressionar com uma explicação coerente ou interpretar incorretamente o contrato. Registre desacordos e ajuste a rubrica, sem alterar a referência apenas para favorecer a versão mais recente. Separe o conjunto usado para desenvolver instruções daquele reservado para comparar a decisão de avanço, evitando otimizar exclusivamente para os casos conhecidos.

Transforme falhas em mudanças específicas e limites de uso

Uma falha deve apontar para uma hipótese de correção. Se o agente escolhe a visita errada, talvez a ferramenta de busca entregue candidatos sem contexto suficiente. Se insiste após erro, o contrato pode não diferenciar falha transitória de validação. Se relata sucesso sem confirmação, pode faltar uma regra clara de conclusão ou uma resposta de ferramenta mais estruturada. Não atribua todo problema ao texto de instrução antes de examinar a interface entre agente e sistema.

Depois de corrigir, repita a família afetada e casos próximos que possam regredir. Uma regra que exige esclarecimento sempre pode resolver ambiguidades e piorar tarefas completas com perguntas desnecessárias. Uma ferramenta mais permissiva pode aumentar sucesso aparente e reduzir proteção. O experimento deve verificar o efeito pretendido e os custos introduzidos. Documente o que mudou e mantenha um caminho de retorno quando a versão ainda não demonstrou comportamento suficiente para o uso proposto.

Conclua a avaliação definindo onde o agente pode operar, quando deve pedir informação e quais ações ainda exigem tratamento externo. A evidência deve sustentar esse limite, sem prometer autonomia universal. Um agente pronto para um recorte é aquele que executa as tarefas desse recorte com estado verificável, respeita as condições e comunica falhas com precisão. Ampliar ferramentas ou responsabilidades exige novos cenários, porque cada capacidade acrescenta decisões e efeitos que a avaliação anterior não cobriu.

Perguntas frequentes

Basta avaliar a resposta final do agente?

Não para tarefas com ferramentas. Confira também argumentos, ações executadas e estado final, porque uma resposta correta pode ocultar efeitos incompletos ou indevidos.

Todo teste precisa exigir a mesma ordem de chamadas?

Não. Quando caminhos diferentes são válidos, avalie invariantes e dependências necessárias. Use correspondência exata apenas quando a sequência fizer parte do requisito.

Posso testar diretamente em contas reais?

Para avaliação repetida, prefira ambientes e ferramentas de teste com efeitos controlados. A validação posterior em operação deve ter escopo autorizado e não substituir os cenários de falha preparados.

Avalie seus agentes antes de ampliar a autonomia

A Tironi Tech pode desenvolver cenários, ferramentas de teste e verificações de resultado para agentes integrados aos processos da sua empresa.

Artigos relacionados

• Avaliação de trajetória de agentes de IA: como medir decisões intermediárias além da resposta final
• Catálogo corporativo de agentes de IA: como registrar finalidade, dono, ferramentas, risco e histórico
• Ferramentas e permissões para agentes de IA: como conceder somente os acessos necessários a cada tarefa

Fontes consultadas

• Google Cloud — Evaluate your AI agents with Vertex Gen AI evaluation service