Fiabilité pour Agentic Enterprise

Les agents autonomes introduisent des modèles d’exécution non déterministes fondamentalement différents de l’automatisation Salesforce traditionnelle. Alors que Salesforce Flow et Apex suivent des chemins prévisibles qui produisent des résultats répétitifs dans des conditions contrôlées, les agents raisonnent dynamiquement à travers les problèmes. Par exemple, une même question posée deux fois peut suivre différents chemins d’exécution, consommer différentes ressources et produire différents résultats. Ce non-déterminisme crée des défis de fiabilité que les approches traditionnelles de test et de surveillance ne répondent pas.

Les modes d’échec de fiabilité des agents sont catégoriquement différents des échecs Salesforce Flow ou Apex. Les services d’inférence de grand modèle de langage (LLM) représentent des dépendances externes avec des caractéristiques de disponibilité distinctes de la plate-forme Salesforce. Les agents génèrent des réponses qui violent parfois la structure attendue malgré des instructions rapides. La préparation du contexte de l’agent consomme les limites du gouverneur de façon imprévisible. La récupération de données illimitée affecte plus gravement les agents, car ils peuvent demander un contexte illimité alors que les requêtes déterministes ont un contrôle explicite de la portée.

Une architecture d’agent fiable nécessite une chaîne de secours à plusieurs niveaux qui se dégrade gracieusement, depuis les agents sophistiqués jusqu’aux agents plus simples avec un contexte réduit, en passant par les moteurs de règles déterministes et enfin la transmission humaine via Omni-Channel. Les événements de plate-forme alimentent des files d’attente durables avec des modèles de point de contrôle, ce qui permet aux workflows échoués de reprendre à partir de la dernière étape réussie. Les disjoncteurs suivent l’intégrité du service LLM dans Cache de la plate-forme pour le statut en temps réel, soutenu par des Types de métadonnées personnalisées pour les seuils et la configuration, acheminant vers des modèles de repli après des échecs consécutifs. La surveillance nécessite de suivre les taux de réussite des conversations, le temps moyen entre les échecs (MTBF), le temps moyen de récupération (MTTR) et la précision de l’ancrage. L’observabilité Agentforce fournit des traces de session, des métriques d’intégrité et de latence, ainsi que des taux d’escalade et de déviation, mais vous devez quand même instrumenter vous-même des métriques de fiabilité telles que MTBF, MTTR et la précision de l’ancrage.

Ce document présente les modifications apportées lorsque les agents sont dans l’image. Pour les modèles de fiabilité de base qui s’appliquent à toutes les solutions Salesforce (conception d’objets de niveau de service (SLO), tolérance aux pannes, mise à l’échelle et surveillance), consultez le pilier Fiabilité.

Les agents Agentforce échouent de différentes façons que Salesforce Flow ou Apex . La compréhension de ces modes d’échec détermine l’architecture de fiabilité.

Indisponibilité du service LLM : Les points de terminaison d’inférence LLM rencontrent parfois des pics de latence ou des problèmes de disponibilité. Agentforce est répertorié en tant que produit surveillé sur trust.salesforce.com avec Analytics et d’autres services Salesforce. Cependant, les métriques de latence d’inférence LLM et de performance par requête ne sont pas exposées ici. Implémentez des disjoncteurs en utilisant le cache de la plate-forme pour l’état temps réel à faible latence, soutenu par des types de métadonnées personnalisées pour les seuils et la configuration, afin de suivre l’intégrité du service LLM. Cache de la plate-forme est le meilleur effort (les entrées peuvent être expulsées avant leur heure de vie (TTL). Par conséquent, conservez l’état ouvert/déclenché dans un magasin durable, par exemple un objet personnalisé, plutôt que le cache seul. Ajustez la condition de déplacement au point de terminaison : un nombre d’échecs consécutifs (par exemple cinq) ou un taux d’erreur franchissant un seuil sur une période glissante. Lorsque le circuit se déclenche, ouvrez-le et acheminez-le vers des schémas de repli, par exemple des invites plus simples, des réponses mises en cache ou un transfert humain, jusqu’à ce qu’une demande de test réussie indique une récupération.
Échecs de validation de réponse : Les agents génèrent occasionnellement des réponses qui enfreignent la structure attendue malgré des instructions rapides. Un agent renvoie parfois un JSON malformé, omet les champs obligatoires ou inclut des types de données inattendus. Le cache de la plate-forme peut stocker des schémas de réponse validés, ce qui accélère la validation. Lorsque la validation échoue, réessayez avec des invites affinées, notamment l’erreur de validation et un exemple de structure correcte. Définissez un nombre maximal de tentatives (3 à 5) afin d’éviter une infinité de boucles de réessai.
Détection de l’hallucination : Lorsque les données d’ancrage sont incomplètes, les agents produisent des informations plausibles, mais incorrectes. Contrairement aux requêtes déterministes qui renvoient « introuvable », les agents comblent les écarts avec l’inférence. Le Journal d’audit de la couche Trust Einstein consigne chaque invite, invite masquée, réponse, résultat de la détection de la toxicité et commentaires des utilisateurs pour un examen de gouvernance a posteriori. Cependant, il ne capture pas les traces de raisonnement pas à pas. Pour la capture du raisonnement étape par étape, utilisez le Traçage de session Agentforce, qui enregistre les exécutions du moteur de raisonnement. Demandez aux agents de citer des sources de récupération Data 360 (anciennement Data Cloud) par génération augmentée de récupération (RAG). Croisez les réclamations des agents avec les sources récupérées pour détecter les écarts factuels avant l’exécution de l’action. Un contrôle en ligne ajoute peu de latence, car il s’applique à des sources déjà en contexte. Un chèque qui nécessite un aller-retour séparé, par exemple un appel de deuxième modèle ou un service externe, coûte plus cher. Réservez ces contrôles pour les écritures à fort impact, y compris les mises à jour financières ou de commande, et exécutez-les de façon asynchrone pendant la conversation en temps réel.
Pics de limite du gouverneur : La préparation du contexte de l’agent consomme de façon imprévisible les requêtes SOQL (Salesforce object query language), le temps processeur et la mémoire en tas en fonction du flux de conversation. Proactive Monitoring est un service d ’ autorisation Signature Success (anciennement Signature Support) dans le Salesforce Success Plan, où Salesforce surveille proactivement les comptes des clients. Proactive Monitoring n’est pas une alerte configurable en libre-service disponible pour tous les clients. Pour la surveillance des limites du gouverneur en libre-service, utilisez Scale Center afin d’identifier les opérations exigeantes en ressources des agents qui approchent des limites. Implémentez la pagination dans les actions des agents qui récupèrent des collections d’enregistrements volumineuses. Pour les données de référence fréquemment accédées, utilisez Cache de la plate-forme.
Asymétrie des données dans le contexte de l’agent : Les agents qui récupèrent le contexte de comptes contenant plus de 10 000 opportunités, ou de requêtes avec des historiques d’activité relativement volumineux, rencontrent les mêmes problèmes d’asymétrie des données qu’Apex par lot. Contrairement aux requêtes déterministes dans lesquelles vous contrôlez la portée, le raisonnement de l’agent peut demander « tout l’historique » de façon imprévisible. Pour éviter cela, concevez des actions d’agent avec des limites raisonnables (par exemple, un plafond de l’ordre de 200 enfants par parent) et implémentez des stratégies d’échantillonnage lorsque les limites sont dépassées. Le plafond limite la quantité de données qui entrent dans le contexte de l’agent. Associez-le à des filtres sélectifs et indexés pour que la requête reste bon marché, car un filtre non indexé ou un agrégat sur un parent asymétrique analyse l’ensemble enfant complet avant l’application du plafond.

Concevez des chaînes de secours à plusieurs niveaux, permettant aux agents de continuer à fonctionner avec des capacités réduites plutôt que de tomber en panne.

Agent principal avec le contexte complet : Agent sophistiqué avec un ancrage complet à Data 360, un historique des conversations étendu et un raisonnement complexe. La meilleure qualité, mais le risque de défaillance le plus élevé et le plus gourmand en ressources.
Agent secondaire avec un contexte réduit : Agent plus simple en utilisant un contexte condensé (par exemple, 30 derniers jours par rapport à l’ensemble de l’historique, 5 premiers résultats de recherche vectorielle par rapport aux 20 premiers). Un contexte plus petit signifie moins de jetons, une inférence plus rapide et un risque d’échec réduit, mais uniquement si le contexte réduit couvre toujours les données dont la tâche a besoin.
Moteur de règle déterministe : Logique Salesforce Flow ou Apex traditionnelle qui gère les scénarios courants lorsque le raisonnement des agents échoue. Les règles ne peuvent pas s’adapter aux nouvelles situations, mais elles gèrent de façon fiable les schémas connus. L’agent de validation de la commande revient aux règles de validation standard, tandis que l’agent de score des pistes revient au calcul du score basé sur la règle.
Transmission humaine via Omni-Channel : Acheminez vers la file d’attente humaine lorsque les options automatisées sont épuisées. Configurez l’acheminement basé sur les compétences pour vous assurer que les escalades atteignent l’expertise appropriée. Transmettez le contexte complet de la conversation (y compris les stratégies tentées, les scores de confiance que vous calculez pour l’agent et les motifs d’échec) pour permettre une intervention humaine efficace.

Implémentez une logique de repli dans l’orchestration Salesforce Flow ou Apex déclenchée par des Événements de plate-forme. Chaque niveau consigne la stratégie qui a réussi, ce qui crée une visibilité sur les modèles d’échec et l’efficacité de repli.

Tous les modèles d’événement de plate-forme de cette section supposent des types d’événement de plate-forme à haut volume, qui offrent une période de rétention de 72 heures. Les événements de plate-forme à volume standard sont conservés pendant 24 heures seulement. Utilisez des types d’événement à haut volume pour tous les modèles de résilience, de file d’attente et de point de contrôle des agents dans lesquels la durabilité de la lecture est une exigence de fiabilité. Les événements de plate-forme fournissent une messagerie durable permettant aux workflows des agents de survivre aux échecs et de récupérer automatiquement.

Progression de l’agent du point de contrôle : Les workflows d’agent à plusieurs étapes publient des événements de point de contrôle après chaque étape réussie. L’agent de traitement des contrats effectue l’extraction de documents, publie l’événement ContractParsed avec les données extraites, puis procède à l’analyse des clauses. Si l’analyse de la clause échoue, rejouez l’événement ContractParsed pour reprendre à partir des données extraites sans les analyser de nouveau. Cela fonctionne lorsque la charge de travail du point de contrôle transporte ces données et que l’abonné est idempotent, car la relecture redonne vie aux événements plutôt que de reprendre un workflow à mi-étape. Stockez l’état du point de contrôle dans la charge de travail de l’événement, y compris l’ID de corrélation, les étapes terminées et l’état requis pour la poursuite.
File d’attente de réessai avec backoff exponentiel : Les requêtes d’agent échouées sont publiées dans l’événement AgentRetryRequested avec le nombre de nouvelles tentatives dans la charge de travail. L’abonné à l’événement traite les tentatives avec des délais de retrait exponentiels (par exemple, 30 sec, 2 min, 8 min, 30 min). Après un nombre maximal de tentatives (généralement 5), acheminez vers la file d’attente lettre morte et alertez les opérations. Les événements de plate-forme à haut volume préservent une période de relecture de 72 heures. Utilisez le type d’événement haut volume pour les files d’attente de nouvel essai des agents afin de permettre aux abonnés de rattraper leur retard après les périodes de maintenance de l’organisation ou les temps d’arrêt de déploiement. Les événements de plate-forme à volume standard sont conservés pendant 24 heures seulement.
Orchestration pilotée par l’événement : Concevez des workflows d’agent comme des chaînes d’événements peu couplées. La création de pistes publie LeadCreated. L’agent de score des pistes s’abonne, calcule le score et publie LeadScored. L’agent d’acheminement des pistes s’abonne à LeadScored et l’attribue à la file d’attente appropriée. Chaque agent peut échouer et réessayer indépendamment. Une défaillance d’un seul agent ne bloque pas le workflow complet, les agents en aval traitent lorsque les dépendances se rétablissent.
Suivi de l’ID de corrélation : Insérez un ID de corrélation en tant que champ personnalisé dans toutes les charges utiles d’événements associés. Rejouez les événements en utilisant l’API Pub/Sub par replayId, un identifiant opaque et non contigu, pour reconstituer l’historique des workflows pendant la période de rétention de 72 heures. Pour activer le débogage basé sur l’ID de corrélation, implémentez un modèle côté abonné qui consigne les événements entrants avec leur replayId et leur ID de corrélation dans un objet personnalisé, ce qui active la traçabilité des événements croisés. Ce schéma de consignation est une implémentation personnalisée que vous élaborez vous-même, pas une capacité native de requête de plate-forme.

Déplacez les opérations des agents qui dépassent les limites synchrones vers un contexte asynchrone, ce qui augmente les limites du gouverneur et allonge les expirations.

Apex par lot pour les opérations en masse des agents : Un agent qui analyse plus de 1000 enregistrements bénéficie d’Apex par lot fournissant 200 requêtes SOQL, 150 instructions DML (jusqu’à 10 000 lignes DML) et 60 000 millisecondes (60 secondes) de temps processeur par méthode d’exécution. L’agent de score des pistes traite les importations de pistes nocturnes. Analyse du sentiment des requêtes dans les requêtes historiques. Prévisions d’opportunité analysant des pipelines complets.
Chaînes file d’attente pour workflows à plusieurs étapes : Les workflows d’agent complexes nécessitant plusieurs appels d’API externes, une analyse de jeux de données volumineux ou un temps de traitement étendu utilisent des chaînes Apex Queueable. Chaque tâche Queueable reçoit 60 temps processeur et 12 Mo de pile. Enchaînez au suivant Queueable pour les workflows qui dépassent les limites en tâches uniques. Suivez la progression dans Objets personnalisés afin de reprendre une tâche échouée à partir de la dernière étape terminée.
@future pour de simples transferts asynchrones : Les opérations légères des agents, telles que l’envoi de notifications, la consignation dans des systèmes externes ou des mises à jour non urgentes, utilisent des méthodes @future. Le modèle Feu et oubli s’adapte lorsqu’un workflow n’a pas besoin de résultats et peut tolérer un échec.

Surveillez la capacité de traitement asynchrone via la page Tâches Apex (Configuration → Tâches Apex) et la File d’attente Apex Flex. Un maximum de 5 tâches par lot simultanées limite le traitement des agents parallèles ; des tâches supplémentaires sont mises en file d’attente dans la File d’attente Flex Apex, qui contient jusqu’à 100 tâches sous le statut En attente. Tous les types Apex asynchrones, Batch, Future, Queueable et Scheduled Apex, partagent la même limite quotidienne de l’organisation (DailyAsyncApexExecutions) en exécutions Apex asynchrones: le plus élevé entre 250 000 et 200 fois le nombre de licences utilisateur. Lorsque vous exécutez des interrogations d’agents à haute fréquence ou réessayez des files d’attente d’abonnés, Queueables peut rapidement épuiser ce quota. Pour éviter cela, limitez ces files d’attente par lot ou par étranglement afin de respecter la limite, qui s’applique à l’ensemble de l’organisation dans tous les types Apex asynchrones, pas en tant qu’allocation séparée pour Queueable uniquement. Alertez lorsque la consommation approche ces limites afin de permettre aux équipes de gérer proactivement la capacité.

Validez la résilience des agents avant la production en utilisant des stratégies de test qui traitent du comportement non déterministe.

Test de chargement en sandbox Full Copy : Testez les performances des agents à l’échelle de production en utilisant des volumes de données complets. Simulez des conversations simultanées correspondant aux pics de demande. Mesurez la latence p95 et p99, en identifiant la dégradation des performances sous tension. Valider la limite de consommation du gouverneur reste en dessous des seuils lors des pics de charge. Les tests de chargement dans une organisation sandbox Partial Copy avec des données réduites offrent une confiance trompeuse, car le volume de données affecte directement les performances des agents. Avant d’exécuter ces tests, obtenez l’approbation de Salesforce (au moins une semaine avant pour les demandes de test de performance). Les tests non approuvés peuvent être limités ou bloqués.
Injection de défaut : Introduire délibérément des échecs dans la validation des mécanismes de récupération. Simulez les échecs d’inférence LLM dans la couche de service que votre disjoncteur surveille pour vérifier l’activation du disjoncteur. Injectez des exceptions SOQL pour tester le traitement des erreurs. Réponses corrompues des agents à la logique de validation des tests. Introduisez l’asymétrie des données (comptes avec plus de 10 000 enfants) pour tester la logique de pagination. Définissez des expirations agressives pour tester la gestion des expirations et réessayer des stratégies.
Ingénierie du chaos : Désactivez de façon aléatoire les abonnés à l’événement de plate-forme pour tester la récupération de relecture. Terminez les tâches asynchrones en cours d’exécution pour tester le redémarrage du point de contrôle. Introduisez la latence variable dans les systèmes externes pour tester des stratégies d’expiration progressive. Les expériences de chaos valident la résilience dans des combinaisons d’échec réalistes. Planifiez des journées de chaos régulières dans des environnements intermédiaires, en préservant la résilience à mesure que les agents évoluent.
Essais de stabilité à long terme : Exécutez les charges de travail des agents en continu pendant plus de 72 heures, en surveillant les défaillances temporelles. L’accumulation d’erreurs et la dégradation progressive des performances ne font surface que sous un fonctionnement soutenu. Suivez les tendances temporelles du processeur pour identifier la dégradation progressive au fil du temps.

Définissez des indicateurs de niveau de service (SLI) qui permettent de mesurer la fiabilité objective. Établissez des SLO avant les agents de construction, pas après des échecs de production.

Taux de réussite de la conversation : Pourcentage de conversations des agents terminées sans erreur ni expiration. Comptez une gracieuse transmission à un humain comme une réussite, pas un échec - l’escalade est le dernier niveau de repli par conception. Comptez les escalades échouées ou involontaires dans la métrique. C’est un signal de fiabilité utile, mais un proxy imparfait pour l’expérience utilisateur, car une approbation polie peut masquer un problème non résolu. Suivez séparément par type d’agent et cas d’utilisation, car les critères de réussite du score des pistes diffèrent de l’examen des contrats. Alertez lorsque le taux de réussite passe sous la SLO (généralement 95 à 99 %).
Délai moyen entre les échecs (MTBF) : Temps opérationnel moyen entre les défaillances des agents. Une MTBF plus élevée indique moins de pannes et une meilleure fiabilité. Calculez le nombre total d’heures opérationnelles de l’agent divisé par le nombre d’échecs. Suivez par type d’agent pour identifier les agents les moins fiables qui nécessitent un investissement en optimisation.
Délai moyen de rétablissement (MTTR) : Temps moyen entre la détection des échecs et la restauration du service. La récupération automatisée via la relecture d’événements de plate-forme et des disjoncteurs restaure le service beaucoup plus rapidement et avec moins d’erreur manuelle qu’une intervention pratique. Un MTTR inférieur réduit l’impact commercial par incident.
Précision du sol : Pourcentage de réponses factuellement correctes de l’agent basées sur la validation des données sources. Exemples de réponses aléatoires des agents pour valider les réclamations par rapport aux sources Data 360. La précision d’ancrage inférieure à 95 % indique des problèmes d’hallucination qui nécessitent un affinement rapide ou une meilleure récupération du contexte.
Écarts de lecture d’événements de plate-forme : Nombre d’événements manqués ou non livrés, par exemple un abonné hors ligne au-delà de la période de rétention. Zero gap est un signal positif d’une architecture saine pilotée par les événements. Les écarts indiquent des problèmes d’abonné, des échecs de publication d’événements ou des contraintes de capacité. Suivez ces écarts avec le schéma de consignation côté abonné décrit ci-dessus, puis enregistrez le replayId et l’ID de corrélation de chaque événement dans un objet personnalisé.

Les agents fiables conçoivent d’avance pour les échecs, en définissant des SLI/SLO, en gérant le contexte en fonction des limites du gouverneur et en créant des chaînes de secours à plusieurs niveaux, sans les boulonner par la suite. Les disjoncteurs de couche et la logique de réessai et de point de contrôle basée sur l’événement de plate-forme permettent aux workflows de récupérer automatiquement, avec le transfert humain en dernier recours. Validez cette conception par des tests systématiques de charge, d’injection de défauts et de chaos, puis continuez à surveiller les mêmes SLI en production pour vérifier qu’elle tient le coup au fil du temps.

Le guide de fiabilité du pilier Fiabilité principal s’applique aux agents avec des considérations spécifiques à la plate-forme présentées ici. Les architectures d’agents réussies équilibrent la capacité autonome et la supervision appropriée, ce qui permet de récupérer soi-même les échecs temporaires tout en s’intensifiant lorsque la confiance diminue ou lorsque des requêtes périphériques émergent.

Partagez vos commentaires sur l'infrastructure bien archivée.