Testez un agent IA dans Agentforce Testing Center : exigez des reçus de résultat

Si vous avez besoin de tester un agent IA dans Agentforce Testing Center , utilisez ses évaluations de sous agent, d'action et de réponse comme trois éléments de preuve distincts et non comme un seul verdict de libération. La valeur par défaut raisonnable est la suivante : exécuter les cas positifs et négatifs dans un bac à sable, exiger de nouvelles passes pour l'itinéraire et les actions attendus, puis vérifier l'effet commercial de manière indépendante avant la promotion. Ce dernier reçu compte. Un agent peut choisir le sous agent attendu, appeler l'action attendue et produire une réponse acceptable alors que la modification d'enregistrement prévue est absente, dupliquée, appliquée à la mauvaise portée ou encore en attente d'approbation. Une ligne de test verte prouve ce que cette ligne évalue. Cela ne prouve pas automatiquement le résultat de la destination. Ce guide transforme un test Agentforce en une porte de promotion à huit états. L'appareil ne stocke aucun énoncé, réponse, enregistrement client ou secret ; il ne conserve que les états réussite/échec, la fraîcheur, l'état d'approbation et un verdict résultat réception. Le résultat du centre de test constitue une preuve, pas le verdict de libération Courant de Salesforce unité de configuration de test décrit les cas de test avec un énoncé, un sous agent attendu, des actions attendues et une réponse attendue. C'est unité de résultats expose ensuite le sous agent et les actions réels, ainsi que des évaluations distinctes de sous agent, d'action et de réponse. Cette séparation est utile car chaque panne indique une réparation différente : Échec du sous agent : le routage a sélectionné la mauvaise limite de responsabilité. Échec de l'action : l'itinéraire était plausible, mais l'opération requise manquait ou était différente. Échec de la réponse : l'itinéraire et les appels sont peut être corrects, mais la réponse n'a pas satisfait au résultat sémantique attendu. Ne réduisez pas ces champs en un seul pourcentage. Supposons qu'un cas de mise à jour de contact réussisse l'évaluation de la réponse parce que l'agent indique que l'adresse a été mise à jour. Si l'évaluation de l'action échoue, la phrase ne constitue pas une preuve que l'écriture a eu lieu. Même lorsque les trois évaluations réussissent, une relecture de destination reste la preuve la plus solide d’un effet secondaire. La même prudence s’applique à la fraîcheur. Une exécution réussie pour l'agent version 12, la révision 4 de la suite de tests et les métadonnées d'action d'hier ne peuvent pas certifier la version 13 après une modification d'instruction ou d'autorisation. Liez chaque décision de promotion à au moins : Gardez le reçu sans contenu. Stockez les identifiants opaques, les versions, les horodatages, les booléens et les hachages. Ne copiez pas les invites, les données client, les informations d'identification ou les réponses complètes du modèle dans un enregistrement de surveillance. Il existe également une limite de sécurité avant qu'un score ne compte. Courant de Salesforce unité d'outils et de considérations de test avertit que les tests d'agent peuvent modifier les données CRM et demande aux opérateurs de tester dans un bac à sable. Considérez cela comme une condition préalable stricte et non comme une note de bas de page. Utilisez des appareils dédiés, des enregistrements réversibles, des identités de test de moindre privilège et une vérification de nettoyage. Un test réussi qui a touché par erreur la production n’est pas un test sain. Transformez un test en une porte de promotion à huit États L’artefact inspectable accompagnant cet article évalue huit cas sans contenu dans un ordre strict. Cet ordre empêche un champ vert en aval de masquer une défaillance antérieure : État Preuve Décision de l'opérateur RUN INCOMPLETE Le travail de test n'est pas terminé Attendez; ne pas en déduire l'échec ou le succès STALE RESULT Le résultat dépasse l’âge de preuve accepté Réexécuter avec les versions prévues SUBAGENT MISMATCH L'évaluation du sous agent a échoué Itinéraire, portée ou attente de test de réparation ACTION MISMATCH L'évaluation de l'action a échoué Inspecter les autorisations, les instructions et le plan d'action RESPONSE MISMATCH L'évaluation de la réponse a échoué Réparer les critères de réponse ou le comportement de réponse WAITING Une approbation légitime est en attente Aviser le propriétaire ; préserver le contexte du CV OUTCOME UNVERIFIED Les champs du centre de test sont réussis, la preuve de destination est absente Relisez l'effet avant la promotion HEALTHY De nouvelles preuves sur l'itinéraire, l'action, la réponse et les résultats concordent Autoriser la décision de promotion limitée Exécutez l'artefact avec Node.js : Le résumé attendu est : L’expérience importante concerne la dernière paire de cas. Les deux ont une nouvelle exécution terminée et réussissent les évaluations de sous agent, d’action et de réponse. effect unverified n'a pas de reçu de destination et décide de OUTCOME UNVERIFIED ; healthy ajoute une relecture vérifiée et résout HEALTHY . Un champ modifie le verdict de libération. Cette relecture devrait correspondre au résultat promis : Pour une mise à jour CRM, interrogez l'enregistrement prévu avec une identité de test isolée et comparez uniquement les champs attendus. Pour un e mail ou une notification, vérifiez la boîte d'envoi du bac à sable ou le reçu du fournisseur et affirmez exactement un effet accepté. Pour une réponse de connaissances, validez les citations ou les identifiants de source requis plutôt que de faire correspondre la prose mot pour mot. Pour un transfert de flux de travail, vérifiez l’enregistrement de transfert durable, le propriétaire, la date limite et le jeton de reprise. Pour une demande nécessitant une autorisation, enregistrez WAITING ; ne marquez pas l'agent bloqué simplement parce qu'il s'est correctement mis en pause. Il ne s’agit intentionnellement pas d’un évaluateur universel. Le classificateur suppose que vous avez mappé les champs de résultats actuels d'Agentforce dans votre propre contrat de réception stable. Il ne juge pas la qualité factuelle, ne simule pas chaque formulation d'utilisateur ou ne prouve pas qu'un bac à sable reflète les autorisations de production. Il ne peut pas non plus décider de votre taux de réussite de base acceptable. La documentation de Salesforce indique que le comportement génératif est probabiliste et que chaque organisation doit définir son propre seuil de préparation à la production. Exécutez l'exercice, puis définissez la limite de production Commencez par une tâche de grande valeur dont le résultat est inspectable de manière déterministe. Ne commencez pas avec mille invites générées. Une suite plus petite avec des attentes fiables révélera plus qu'une grande suite dont les actions attendues ont été copiées à partir d'une exécution fortuite. 1. Gelez l’identité du test. Enregistrez la version de l'agent, la révision de la suite, la révision des métadonnées d'action, la révision de l'ensemble d'autorisations et l'identifiant du bac à sable. 2. Définir les cas positifs et négatifs. Les conseils de configuration du Salesforce recommandent les deux. Incluez une demande valide, une demande non valide, une demande refusée, un cas d'autorisation manquante et un cas d'approbation requise. 3. Courez dans un bac à sable. Semez des enregistrements réversibles et prouvez le nettoyage. Abandonnez si l’environnement ou l’identité est ambigu. 4. Inspectez les trois évaluations séparément. Réparez la première limite défaillante. Une réécriture de réponse ne doit pas masquer une action manquante. 5. Relisez le résultat. Utilisez une assertion spécifique à la destination avec une clé d'idempotence ou un enregistrement de test stable. 6. Répétez les cas sains. Un seul passage ne révèle pas de flocons probabilistes. Gardez le nombre d'exécutions et l'intervalle de confiance visibles plutôt que de déclarer une certitude. 7. Promouvez uniquement l’artefact épinglé. Si les instructions, actions, autorisations, configuration du modèle ou attentes de test changent, l'ancien reçu expire. 8. Surveillez le résultat en direct séparément. L'évaluation de pré production réduit les risques ; il ne remplace pas l'accessibilité, la planification, l'état d'attente, l'autorisation, le coût ou l'état du livrable après le lancement. Cette dernière frontière est celle où les tests et la santé des agents divergent. Les tests demandent si les scénarios sélectionnés se comportent de manière acceptable avant qu’un changement ne soit promu. La santé opérationnelle demande si l'agent en cours reste joignable, fait des progrès utiles, atteint ses outils, respecte les limites d'approbation et produit maintenant le résultat attendu. Vous avez besoin des deux, mais l’un ne peut pas remplacer l’autre. Sidewisp est conçu autour de cette couche de santé opérationnelle : fraîcheur des preuves, progrès utiles, accès aux outils, attente ou blocage et résultats vérifiés. Sidewisp est actuellement en préversion privée. Le site public et la démonstration interactive sont en direct ; un adaptateur Agentforce de production, un moteur de surveillance en direct et un exécuteur de récupération automatisée ne sont pas livrés. L'étape pratique aujourd'hui consiste à conserver le reçu sans contenu à côté de votre test Agentforce et à refuser la promotion lorsque le résultat de la destination est encore inconnu.