2026-07-31T06:15:25.318Z
Teste um agente de IA em Agentforce Testing Center: exija recibos de resultados
Transforme avaliações separadas de subagentes, ações e respostas em um portão de promoção fixado por versão com aprovação e recibos de destino-resultado.
Se você precisar testar um agente de IA em Agentforce Testing Center , use suas avaliações de subagente, ação e resposta como três evidências separadas – e não como um veredicto de liberação. O padrão razoável é: executar casos positivos e negativos em uma sandbox, exigir novos passes para a rota e ações esperadas e, em seguida, verificar o efeito comercial de forma independente antes da promoção. Esse último recibo é importante. Um agente pode escolher o subagente esperado, chamar a ação esperada e produzir uma resposta aceitável enquanto a alteração de registro pretendida estiver ausente, duplicada, aplicada ao escopo errado ou ainda aguardando aprovação. Uma linha de teste verde prova o que essa linha avalia. Não prova automaticamente o resultado do destino. Este guia transforma um teste do Agentforce em um portão de promoção de oito estados. O dispositivo não armazena declarações, respostas, registros de clientes ou segredos; ele mantém apenas estados de aprovação/reprovação, atualização, estado de aprovação e um veredicto de recebimento de resultado. O resultado do Centro de Testes é uma evidência, não o veredicto de divulgação Corrente de Salesforce unidade de configuração de teste descreve casos de teste com uma expressão, subagente esperado, ações esperadas e uma resposta esperada. Isso é unidade de resultados em seguida, expõe o subagente e as ações reais, além de avaliações separadas de subagente, ação e resposta. Essa separação é útil porque cada falha aponta para um reparo diferente: Falha do subagente: o roteamento selecionou o limite de responsabilidade errado. Falha na ação: a rota era plausível, mas a operação necessária estava faltando ou era diferente. Falha na resposta: a rota e as chamadas podem estar corretas, mas a resposta não satisfez o resultado semântico esperado. Não reduza esses campos em uma única porcentagem. Suponha que um caso de atualização de contato seja aprovado na avaliação de resposta porque o agente diz que o endereço foi atualizado. Se a avaliação da ação falhar, a sentença não é evidência de que a gravação ocorreu. Mesmo quando todas as três avaliações são aprovadas, uma releitura do destino ainda é a prova mais forte de um efeito colateral. O mesmo cuidado se aplica ao frescor. Uma execução aprovada para a versão 12 do agente, revisão 4 do conjunto de testes e metadados de ação de ontem não pode certificar a versão 13 após uma alteração de instrução ou permissão. Vincule todas as decisões de promoção a pelo menos: Mantenha o recibo livre de conteúdo. Armazene identificadores, versões, carimbos de data/hora, booleanos e hashes opacos. Não copie prompts, dados de clientes, credenciais ou respostas completas do modelo em um registro de monitoramento. Há também um limite de segurança antes que qualquer pontuação seja importante. Corrente de Salesforce unidade de ferramentas e considerações de teste avisa que os testes do agente podem modificar os dados CRM e instrui os operadores a testar em uma sandbox. Trate isso como uma pré condição rígida, não como uma nota de rodapé. Use acessórios dedicados, registros reversíveis, identidades de teste com privilégios mínimos e verificação de limpeza. Um teste bem sucedido que afetou a produção por engano não é um teste saudável. Transforme um teste em um portão de promoção de oito estados O artefato inspecionável que acompanha este artigo avalia oito casos sem conteúdo em uma ordem estrita. Essa ordem evita que um campo verde downstream oculte uma falha anterior: Estado Evidência Decisão do operador RUN INCOMPLETE O trabalho de teste não foi concluído Espere; não infira fracasso ou sucesso STALE RESULT O resultado excede a idade de evidência aceita Execute novamente nas versões pretendidas SUBAGENT MISMATCH Falha na avaliação do subagente Reparar roteamento, escopo ou expectativa de teste ACTION MISMATCH Falha na avaliação da ação Inspecione permissões, instruções e plano de ação RESPONSE MISMATCH Falha na avaliação da resposta Reparar critérios de resposta ou comportamento de resposta WAITING Uma aprovação legítima é excelente Notifique o proprietário; preservar o contexto do currículo OUTCOME UNVERIFIED Os campos do Centro de Testes são aprovados, a prova de destino está ausente Leia o efeito antes da promoção HEALTHY Novas evidências de rota, ação, resposta e resultado concordam Permitir a decisão de promoção limitada Execute o artefato com Node.js: O resumo esperado é: O experimento importante é o último par de casos. Ambos têm uma execução nova e concluída e passam nas avaliações de subagente, ação e resposta. effect unverified não tem recibo de destino e resolve OUTCOME UNVERIFIED ; healthy adiciona uma leitura verificada e resolve para HEALTHY . Um campo altera o veredicto de liberação. Essa leitura deve corresponder ao resultado prometido: Para uma atualização CRM, consulte o registro pretendido com uma identidade de teste isolada e compare apenas os campos esperados. Para um e mail ou notificação, verifique a caixa de saída do sandbox ou o recibo do provedor e declare exatamente um efeito aceito. Para obter uma resposta de conhecimento, valide as citações necessárias ou os identificadores de fonte em vez de combinar a prosa palavra por palavra. Para uma transferência de fluxo de trabalho, verifique o registro de transferência durável, o proprietário, o prazo e o token de retomada. Para uma solicitação que exija autoridade, registre WAITING ; não marque o agente como travado apenas porque ele foi pausado corretamente. Este não é intencionalmente um avaliador universal. O classificador pressupõe que você mapeou os campos de resultados atuais do Agentforce em seu próprio contrato de recebimento estável. Ele não julga a qualidade factual, não simula cada frase do usuário ou prova que um sandbox reflete as permissões de produção. Ele também não pode decidir sua linha de base de taxa de aprovação aceitável. A documentação do Salesforce observa que o comportamento generativo é probabilístico e que cada organização deve definir seu próprio limite de prontidão para produção. Execute o exercício e defina o limite de produção Comece com uma tarefa de alto valor cujo resultado seja inspecionável deterministicamente. Não comece com mil prompts gerados. Um conjunto menor com expectativas confiáveis revelará mais do que um conjunto grande cujas ações esperadas foram copiadas de uma execução incidental. 1. Congele a identidade de teste. Registre a versão do agente, a revisão do pacote, a revisão dos metadados da ação, a revisão do conjunto de permissões e o identificador do sandbox. 2. Defina casos positivos e negativos. As orientações de configuração do Salesforce recomendam ambos. Inclua uma solicitação válida, uma solicitação inválida, uma solicitação não permitida, um caso de permissão ausente e um caso de aprovação necessária. 3. Execute em uma caixa de areia. Semeie registros reversíveis e comprove a limpeza. Aborte se o ambiente ou a identidade for ambíguo. 4. Inspecione as três avaliações separadamente. Repare o primeiro limite com falha. Uma reescrita de resposta não deve ocultar uma ação ausente. 5. Leia novamente o resultado. Use uma afirmação específica do destino com uma chave de idempotência ou um registro de teste estável. 6. Repita os casos saudáveis. Uma única passagem não expõe instabilidade probabilística. Mantenha a contagem de execuções e o intervalo de confiança visíveis em vez de declarar certeza. 7. Promova apenas o artefato fixado. Se as instruções, ações, permissões, configuração do modelo ou expectativas de teste mudarem, expire o recibo antigo. 8. Monitore o resultado ao vivo separadamente. A avaliação pré produção reduz o risco; ele não substitui a acessibilidade, o cronograma, o estado de espera, a permissão, o custo ou a integridade da entrega após o lançamento. Esse limite final é onde os testes e a saúde do agente divergem. O teste pergunta se os cenários selecionados se comportam de forma aceitável antes de uma mudança ser promovida. A saúde operacional pergunta se o agente em execução permanece acessível, faz progressos úteis, alcança as suas ferramentas, respeita os limites de aprovação e produz o resultado esperado agora. Você precisa de ambos, mas um não pode substituir o outro. O Sidewisp foi projetado em torno dessa camada de integridade operacional: atualização de evidências, progresso útil, acesso a ferramentas, espera versus travamento e resultados verificados. A Sidewisp está atualmente em prévia privada. O site público e a demonstração interativa são ao vivo; um adaptador Agentforce de produção, mecanismo de monitoramento em tempo real e executor de recuperação automatizado não são fornecidos. A etapa prática hoje é manter o recibo sem conteúdo ao lado do teste do Agentforce e recusar a promoção quando o resultado do destino ainda for desconhecido.