O agente terminou mesmo? Como verificar o resultado sem confiar na resposta final

A ação não é o resultado

Um agente pode responder «pronto» sem que o objetivo tenha sido alcançado. Também pode enviar uma chamada a uma ferramenta, receber uma resposta a indicar que o pedido foi aceite e, ainda assim, deixar o trabalho pendente ou incompleto. São afirmações diferentes e exigem evidências diferentes.

É útil distinguir três estados. Primeiro, o agente tentou executar uma ação: por exemplo, enviou uma instrução para alterar um registo. Segundo, o sistema que recebeu o pedido aceitou-o ou respondeu-lhe. Terceiro, o estado final pedido pela pessoa existe e cumpre as condições acordadas. Só o terceiro estado demonstra, por si só, que o objetivo foi alcançado.

Esta distinção é importante porque uma resposta de sucesso pode referir-se apenas a uma parte do processo. «Pedido recebido» não significa necessariamente «alteração guardada»; «teste executado» não significa que todos os requisitos da alteração foram cumpridos; e «reserva solicitada» não equivale a uma reserva confirmada. A resposta do agente pode resumir o que aconteceu, mas não deve ser a única prova do que aconteceu.

A avaliação de agentes procura verificar se sistemas que executam ações conseguem realizar um trabalho de forma fiável. Neste artigo, o foco é mais específico: decidir que evidências permitem aceitar uma tarefa concreta como concluída. As recomendações e os exemplos seguintes constituem um método prático, não uma afirmação de que existe um sinal universal válido para todos os agentes ou ferramentas.

Passo 1: transformar o pedido num estado final observável

Antes de executar uma tarefa, reformule o pedido como uma descrição de como o mundo deve estar no final. «Atualiza o registo» é ambíguo: não indica que campo deve mudar, qual é o valor esperado nem se outros dados devem permanecer intactos. «Faz a alteração no código» também não especifica o comportamento esperado nem as condições que devem continuar a ser cumpridas.

Uma formulação útil identifica o objeto afetado, o estado pretendido, as condições que devem ser preservadas e quaisquer limites relevantes. Não é necessário transformar todos os pedidos numa especificação extensa. É, contudo, necessário resolver as ambiguidades que poderiam alterar a decisão de considerar a tarefa concluída.

O resultado observável deve poder ser descrito sem depender da intenção do agente. Em vez de «o agente tratou da reserva», especifique o que teria de existir para afirmar que está confirmada. Em vez de «o agente corrigiu o código», defina que comportamento esperado deve funcionar e que verificações são pertinentes para a alteração.

Defina também o que fica fora do âmbito. Se foi pedido que um campo fosse atualizado, não presuma que o agente também devia alterar outros campos, avisar terceiros ou rever todo o histórico. Este limite ajuda a evitar dois erros opostos: aceitar como concluída uma tarefa parcial e alargar o pedido sem autorização.

Passo 2: acordar critérios de aceitação antes de agir

Os critérios de aceitação especificam o que deve ser observado para considerar o pedido cumprido. É melhor defini-los antes de executar a ação: mais tarde, torna-se mais fácil confundir um resultado conveniente com uma prova adequada ou baixar o padrão para justificar um resultado parcial.

Um critério útil é específico e verificável. «O registo está correto» deixa demasiada margem para interpretação. «O campo de estado apresenta o valor acordado no registo identificado» indica um estado e um objeto. Se também for importante preservar outros campos, isso deve ser expresso como um critério adicional.

Nem todos os requisitos podem ser verificados com um único sinal. Uma alteração pode exigir que o valor exista e que outro atributo não tenha sido modificado. Uma reserva pode exigir tanto uma confirmação como os dados corretos. Um teste de código pode abranger um comportamento importante sem demonstrar, por si só, que todos os requisitos do pedido foram implementados. A lista deve refletir as condições reais do pedido, e não apenas as mais fáceis de medir.

No caso de pedidos abertos, pode ser necessário pedir primeiro um esclarecimento. Se houver várias interpretações razoáveis e a diferença afetar o resultado aceitável, o agente não deve escolher silenciosamente uma delas e tratá-la depois como se fosse a única. O critério acordado também determina quando uma tarefa está apenas parcialmente concluída e que informação deve ser comunicada.

Passo 3: escolher evidências adequadas à afirmação

A evidência deve responder à pergunta concreta: o que permite afirmar que o estado final pretendido existe? A saída de uma ferramenta pode ser adequada para saber que um pedido chegou a determinado componente, mas não necessariamente para demonstrar que o resultado foi persistido ou que cumpre todos os requisitos. Não atribua a um sinal mais significado do que aquele que realmente tem.

Sempre que possível, verifique o estado através de uma leitura pertinente do sistema afetado ou de uma verificação que avalie diretamente o resultado. Para alguns trabalhos, a evidência pode ser um teste automatizado; para outros, uma confirmação visível na fonte que gere o estado. «Independente» nem sempre significa «de outro fornecedor»: significa que a afirmação do próprio agente de que concluiu a tarefa não é usada como única prova.

A independência também existe em diferentes graus. Perguntar novamente ao agente se terminou pode apenas repetir a sua afirmação, em vez de a verificar. Consultar uma vista do registo pode fornecer uma observação do estado, mas é importante saber o que essa vista representa e se corresponde ao objeto correto. Uma fonte separada pode oferecer mais elementos de comparação, desde que meça realmente o resultado pedido.

A evidência deve estar associada ao critério e ao objeto corretos. Um teste de código bem-sucedido não comprova automaticamente requisitos que não abrange. Uma resposta de confirmação de reserva só é útil se disser respeito à reserva solicitada e os dados coincidirem com o que foi acordado. Se não for possível estabelecer essa ligação, expresse a incerteza em vez de preencher as lacunas com suposições.

Passo 4: separar a execução da verificação

O componente que executa uma ação e aquele que verifica o seu resultado têm funções diferentes. Num fluxo simples, o mesmo agente pode chamar uma ferramenta e depois consultar o sistema afetado. Ainda assim, a segunda operação deve fornecer uma observação do estado, e não limitar-se a repetir que a primeira foi bem-sucedida.

Em sistemas com maior impacto, pode ser preferível que a verificação siga um caminho diferente do da execução ou que seja revista por uma pessoa. A separação reduz o risco de uma única resposta ser tratada simultaneamente como ação e prova. Não é uma regra absoluta: o grau de separação adequado depende do risco, da ambiguidade da tarefa e da qualidade dos sinais disponíveis.

A automatização pode ser suficiente quando os critérios são claros, a verificação abrange o resultado relevante e as possíveis consequências dos erros são limitadas. A revisão humana torna-se mais importante quando as instruções admitem várias interpretações, as consequências são significativas, a evidência não é conclusiva ou é necessário um juízo contextual que um teste automatizado não representa.

Pedir uma revisão humana não torna automaticamente correta uma conclusão. A pessoa precisa de saber o que foi pedido, que critérios foram acordados e que evidências foram observadas. Uma aprovação sem esses elementos pode transformar-se noutro «sim» sem fundamento. A revisão deve resolver uma dúvida concreta, e não ser uma formalidade desligada do resultado.

Três exemplos práticos

Os exemplos seguintes ilustram o método através de critérios hipotéticos. Não descrevem uma ferramenta ou um produto específico, e os sinais disponíveis variam consoante o sistema. Em cada caso, o essencial é não transformar uma resposta de aceitação numa prova de conclusão sem verificar o que essa resposta significa.

Numa atualização de registo, o pedido pode consistir em alterar um campo específico. A ação enviada demonstra uma tentativa; uma resposta de aceitação pode indicar que o sistema recebeu o pedido. Para declarar o trabalho concluído, é necessário observar o registo correto e verificar o valor acordado. Se também tiver sido pedido que outros dados fossem preservados, esses dados devem fazer parte da verificação. Se o sistema mostrar apenas que a alteração está pendente, o resultado ainda não cumpre um critério que exija que o valor já apareça no registo.

Numa alteração de código, a tarefa não fica definida pelo facto de ter sido produzido um patch ou recebida uma resposta de sucesso. Antes de a executar, esclareça que comportamento é esperado e que condições fazem parte do pedido. Em seguida, utilize verificações pertinentes para esse comportamento e reveja os critérios que os testes não abrangem. Um teste terminar sem erros é uma evidência sobre o que esse teste executou; não demonstra automaticamente que todos os requisitos funcionais ou de qualidade do pedido foram cumpridos.

Numa reserva, é essencial distinguir entre pedir e confirmar. O agente pode enviar um pedido e receber uma resposta que não esclareça se a reserva foi confirmada. A evidência deve permitir identificar a reserva relevante e comparar os detalhes com o que foi acordado. Se houver apenas um pedido pendente ou não for possível confirmar os dados necessários, a mensagem final deve dizê-lo, em vez de apresentar a reserva como concluída.

Resultados parciais, contraditórios ou impossíveis de verificar

Se apenas parte dos critérios for cumprida, descreva essa parte como parcial. Não transforme «a ação foi aceite» em «a tarefa está concluída» apenas para oferecer um fecho mais convincente. Evite também o extremo oposto: se houver evidências válidas para alguns requisitos, indique quais são, em vez de apresentar todo o trabalho como desconhecido.

Se dois sinais forem contraditórios, suspenda a conclusão até esclarecer o que cada um mede e a que estado corresponde. Uma resposta positiva pode referir-se à receção do pedido, enquanto outra observação mostra que o estado final ainda não mudou. Essa diferença não é necessariamente uma contradição real: pode corresponder a etapas diferentes. No entanto, enquanto não for esclarecida, não sustenta uma afirmação de sucesso completo.

Se não houver uma forma adequada de observar o resultado, a conclusão correta é que não foi possível verificá-lo — não que o agente tenha necessariamente falhado, nem que tenha tido sucesso. Comunique a ação tentada, a resposta observada e o critério que continua por cumprir. A ausência de evidência sobre o estado final não demonstra, por si só, qual é esse estado.

Mantenha a descrição do resultado proporcional à evidência. «Pedido enviado» é diferente de «pedido aceite»; «alteração observada no campo» é diferente de «todos os requisitos verificados»; e «testes selecionados concluídos» é diferente de «não resta qualquer problema». Uma mensagem precisa ajuda quem recebe o resultado a decidir se deve esperar, rever ou aceitar a tarefa.

Lista de verificação para conceber um fluxo

A avaliação de agentes pode analisar se um sistema que executa ações realiza um trabalho de forma fiável, e os testes podem ajudar a interpretar execuções específicas. Porém, uma pontuação, um estado de execução ou uma resposta da ferramenta não substituem a definição do resultado que importa numa tarefa concreta. A equipa deve traduzir o pedido em critérios observáveis e relacionar cada conclusão com as evidências que a sustentam.

Antes de aceitar ou comunicar uma tarefa como concluída, percorra esta lista. Se não conseguir responder a uma pergunta, isso nem sempre significa que a tarefa falhou; significa, sim, que poderá ser necessário limitar a afirmação, obter as evidências em falta ou pedir uma revisão proporcional ao impacto.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.