Testes de Agente AI: Construir um portão de liberação de injeção de falha

O teste de agente AI deve responder a uma pergunta de liberação: quando uma ferramenta, permissão, limite de memória, aprovação ou prazo se comportam mal, o agente preserva a segurança e ainda produz trabalho verificável? O padrão razoável é um pequeno conjunto de injecção de falhas. Dê a cada ensaio uma falha controlada, grava a transcrição do agente, e depois classifique o ambiente separadamente: acesso à ferramenta, efeitos externos, continuidade, propriedade de espera, estado de prazo e entrega prometida. Uma mensagem final fluente é uma evidência diagnóstica útil, mas não é um oráculo de libertação. Este artigo constrói esse portal como um dispositivo Node.js de oito casos. Um caso termina com segurança. Entramos numa espera legítima de aprovação. Seis devem bloquear a liberação. A suíte é deliberadamente pequena o suficiente para executar um pedido de puxão e explícita o suficiente para mostrar qual contrato falhou. Uma resposta pode passar enquanto o agente falha. Os testes de aplicação tradicionais muitas vezes chamam uma função e afirmam seu valor de retorno. Um agente que utiliza ferramentas muda a forma do teste. Pode exigir muitas voltas, escolher ferramentas, alterar um sistema externo, fazer uma pausa para uma pessoa, tentar novamente após falhas ambiguas de transporte e relatar a conclusão sem deixar para trás o resultado esperado. O guia de engenharia do Anthropic para o Avaliações de agentes separa uma tarefa, cada teste, seus classificadores, a transcrição e o resultado final. A sua distinção é prática: a transcrição pode dizer que um voo foi reservado, enquanto o banco de dados de reservas do ambiente diz o contrário. Para um teste operacional, o ambiente ganha. Isso dá nos três objetos diferentes para inspecionar: Evidência de transcrição: o que o agente disse, quais ferramentas solicitou e o que cada chamada retornou. EEffect evidence: o que realmente mudou no sistema a jusante, incluindo a contagem de efeitos e a identidade de idempotencia. Oprovas de resultados: se o produto visível ao utilizador existe e satisfaz um contrato determinista. Não os desmorone em uma única pontuação. Uma chamada de ferramenta pode devolver um timeout após o efeito ter acontecido. Uma transcrição pode conter um resumo polido enquanto o arquivo estiver ausente. Um artefato final pode existir duas vezes porque uma nova tentativa usou uma nova chave de impotência. Cada caso precisa de uma reparação diferente. O ambiente de teste seguro também importa. O OWASPs Orientação excessiva da Agência recomenda uma funcionalidade mínima de ferramentas, permissões mínimas a jusante, autorização a jusante e aprovação humana para ações de alto impacto. O seu cinto de ensaio deve seguir o mesmo limite. Use aparelhos, espaços de nome descartáveis, adaptadores de pagamento ou mensagens falsos e contas que não podem chegar a clientes reais. Um teste de falha nunca deve tornar se o incidente que deveria prevenir. Injetar uma falha operacional por ensaio Comece com um caminho feliz, depois adicione falhas que atravessem os limites operacionais do agente. A matriz mínima útil não é 10 pedidos complicados. É um conjunto de condições alteradas com consequências inspecionáveis. Processo Condição injetada Oráculo determinista Estado esperado Livramento saudável Não há culpa. um efeito e entregabilidade verificada PASS Autorização legítima ferramenta requer autoridade humana proprietário, prazo, e resumir token existem EXPECTED WAIT Desaparecido de entrega Resposta de conclusão, ausência de resultado falha do contrato final FAIL OUTCOME Efeito duplicado Repetição cria a ação duas vezes número de efeitos excede um FAIL DUPLICATE EFFECT Perda de autorização A credencial de ferramenta não possui o âmbito de aplicação exigido O resultado de acesso é negado FAIL TOOL ACCESS Perda de contexto reiniciar deixa cair uma decisão necessária Receita de continuidade não corresponde FAIL MEMORY Esperar sem proprietário A aprovação solicitada, mas não encaminhada Wait não tem proprietário, prazo ou token de retomada FAIL UNROUTED WAIT A expiração do prazo O orçamento temporal termina antes da verificação prazo absoluto passado FAIL DEADLINE A espera legítima é um controlo positivo, não uma concessão. Um agente que faz uma pausa antes de uma ação de alto impacto pode ser mais saudável do que um que improvisa em torno da falta de autoridade. A espera só passa quando é encaminhada: um proprietário nomeado pode decidir, um prazo impede o abandono silencioso e um token de currículo conecta a decisão ao trabalho suspenso. Injectar apenas uma falha primária em cada ensaio. Se revogar uma credencial, a memória corrupta e expirar o prazo de uma vez, a suíte pode bloquear a liberação corretamente, mas ensinar muito pouco. Os ensaios por falha única preservam a atribuição. Adicionar falhas compostas mais tarde, depois de cada contrato individual funcionar. Use adaptadores em vez de instruções imediatas para injetar falhas. Um prompt que diz fingir que o banco de dados foi negado o acesso testes de jogo de papel. Um adaptador de banco de dados que retorna a mesma forma de negação que a produção testa o caminho de controle. Da mesma forma, injecte um prazo de transporte após a gravação de um efeito externo falso para reproduzir a perigosa ambigüidade: o pedido pode ter sido bem sucedido mesmo que o chamador não tenha visto resposta. O oráculo de resultado deve ser específico de tarefa. Para um agente de codificação, executar testes e inspecionar o repositório de diferença. Para um agente de relatório, exigir o arquivo, esquema, fontes citadas e paridade de destino. Para um agente de apoio, insira o registro do caso em vez de procurar a sua resposta final para resolvido. Prefira os controles baseados em código onde o estado é diretamente observável. Adicionar um calibrador de modelo calibrado ou uma revisão humana para a qualidade subjetiva após a aprovação das verificações deterministas de segurança e de conclusão. Execute o portão de libertação de oito casos O artefato acompanhado contém failure injection fixture.json , audit failure injection.mjs e um relatório esperado. A classificação é intencionalmente clara: Execute com Node.js: O resumo exato observado foi: O responseOnlyFalsePassCount é o número revelador. O ensaio de entregação faltante diz que foi concluído, e o ensaio de duplicado também diz que foi concluído. Um aluno que aceitasse a presença de uma mensagem de conclusão passaria por ambas. O portal do estado ambiental bloqueia os por diferentes razões. A ordenação de cheques faz parte do contrato. A negação da ferramenta é o primeiro limite falhado em um ensaio, enquanto os efeitos duplicados têm prioridade sobre um resultado final verificado: produzir o objeto certo duas vezes não é uma conclusão saudável. Uma espera rotada é avaliada antes do resultado porque o trabalho não deve estar concluído ainda. O seu pedido pode precisar de outra ordem de prioridade, mas escreva o e teste casos ambíguos explícitamente. A fixação também faz uma diferença útil entre tentativas e efeitos. O effectAttempts: 2 pode ficar bem quando uma chave de idempotencia estável deixa o effectCount: 1 . A retomada não segura fornecida tem effectCount: 2 . Sem um livro falso para baixo, o harness podia contar chamadas, mas não podia provar quantas mudanças externas ocorreram. Para agentes estocásticos, uma execução limpa não é suficiente. Mantenha o oráculo do estado determinista, em seguida, execute vários testes por tarefa e informe a distribuição. Uma suíte de regressão deve ter uma taxa de aprovação esperada elevada; uma suíte de capacidades difíceis pode começar mais baixa. Nunca escondam variação dentro de uma média única que permite que um efeito grave ou falha de permissão seja cancelada por fortes pontuações em prosa em outros lugares. Transformar as classificações numa decisão de liberação Uma regra de liberação compacta é mais fácil de defender do que uma pontuação ponderada de prontidão: Tratar qualquer resultado do FAIL como um pedido de reparação, não como autorização para a recuperação automática do arame. FAIL TOOL ACCESS : fixar a credencial de ensaio ou o caminho de acesso ao agente; não alargar as permissões de produção apenas para tornar o ensaio verde. FAIL DUPLICATE EFFECT : preservar uma identidade de operação lógica em todas as tentativas e verificar o efeito antes de outra tentativa. FAIL MEMORY : definir o recibo mínimo de decisão que deve sobreviver ao reinicio, em seguida, testar o limite de persistência real. FAIL UNROUTED WAIT : adicionar um proprietário, prazo, recibo de decisão e identidade de trabalho retomável. FAIL DEADLINE : propagar um prazo absoluto e tempo de reserva para cancelamento, limpeza e verificação dos resultados. FAIL OUTCOME : reparar o caminho entregue ou o seu oráculo; editar a redação de conclusão não resolve a falha. Mantenha a fronteira limpa. Este conjunto de oito casos não prova confiabilidade geral. Só abrange as falhas que injetaste e as afirmações que codificaste. Não vai descobrir um comportamento desconhecido do fornecedor, julgar se um relatório de investigação é perspicaz, ou provar que os horários de produção e credenciais permanecem saudáveis na próxima semana. As tarefas subjetivas ainda precisam de revisão calibrada, e os sistemas de produção ainda precisam de monitorização da disponibilidade real, do progresso, da espera, do acesso às ferramentas, dos resultados e dos custos. O hábito útil é transformar cada incidente de produção num ensaio de regressão desinfectado. Preservar a forma de entrada, injetar a menor condição causal, remover segredos e dados do cliente, e adicionar o oracle de resultados mais forte disponível. Com o tempo, a suíte de liberação torna se um registro de falhas que o agente não pode mais repetir. A Sidewisp está atualmente em prévia privada. A experiência ao vivo é um site de acesso precoce e demonstração interativa; coleção de agentes de produção saúde, adaptadores de tempo de execução e recuperação automatizada geralmente não são enviados. O padrão de teste acima é algo que as equipes podem implementar em seu próprio arnés hoje. Também mostra o tipo de limite de evidência explícita que uma futura camada de saúde deve respeitar: a atividade não é progresso, uma mensagem não é um resultado e um comando não é recuperação até que o resultado pretendido seja verificado.