Traitement asynchrone des agents REDA AI
Que signifie « asynchrone » ici ?
REDA AI exécute par défaut la boucle de l’agent de façon synchrone. Le message arrive, la plateforme appelle le modèle, l’agent utilise des outils, le modèle produit une réponse finale et la conversation est mise à jour, le tout dans la transaction initiale. L’utilisateur, le flux ou le système externe reçoit directement cette réponse.
Certaines demandes dépassent les possibilités d’une seule transaction. Le cas le plus courant est un fichier dont la taille excède les limites de traitement synchrone de Salesforce. Lorsque la plateforme détecte cette situation, elle passe au traitement asynchrone au lieu de faire échouer la demande.
Ce que reçoit l’appelant
Les demandes orientées vers le traitement asynchrone renvoient immédiatement une réponse avec les champs suivants :
| Champ | Signification |
|---|---|
isAsync | true si la demande a été confiée à un traitement en arrière-plan. |
asyncRequestId | L’identifiant de l’enregistrement de demande asynchrone qui suit le traitement. |
conversationId | La conversation à laquelle la demande appartient. La réponse finale de l’agent y est ajoutée sous forme de nouveau message. |
Le champ synchrone response est vide lorsque isAsync vaut true, car la réponse n’a pas encore été produite. Les appelants doivent vérifier isAsync, puis contrôler l’achèvement du traitement ou attendre le nouveau message dans la conversation.
Cycle de vie d’une demande asynchrone
Chaque demande traitée en arrière-plan crée un enregistrement de demande asynchrone, mis à jour au fil du traitement :
| Statut | Signification |
|---|---|
| File d'attente | La tâche Queueable est en attente ; le traitement n’a pas encore commencé. |
| Traitement | Le traitement en arrière-plan a pris en charge la demande et appelle le modèle. |
| Complet | Le traitement a réussi ; la réponse est disponible dans la conversation. |
| Erreur | Le traitement a échoué. Le champ Message d'erreur indique la raison. |
Les autres champs donnent le contexte complet : conversation et message utilisateur associés, définition d’agent utilisée, enregistrement de contexte, identifiants des fichiers traités, compteurs de tentatives et date de fin du traitement.
Gestion des échecs
Une demande asynchrone en échec n’est pas relancée automatiquement. En cas d’erreur, le traitement inscrit Erreur dans le statut de la demande et sa raison dans Message d'erreur, puis s’arrête. Aucune remise en file n’a lieu, même pour une erreur transitoire du modèle ou un appel interrompu.
Prévoyez votre propre reprise si le traitement est important. Un flux qui suppose une réponse asynchrone garantie perdra l’échange en cas d’échec transitoire. Vérifiez le statut de la demande et relancez l’appel si nécessaire en cas d’Erreur.
L’enregistrement comporte des champs Nombre de tentatives et Nombre maximal de tentatives. Le premier est incrémenté une fois à la prise en charge, mais il n’est pas comparé au second pour déclencher une reprise. Ces champs ne modifient donc pas actuellement le comportement de relance.
Les erreurs restent visibles : sauf si l’appelant a désactivé la journalisation des incidents, l’échec figure dans les journaux d’incidents IA, avec ses informations de diagnostic. Commencez vos recherches à cet endroit.
Prise en charge selon le canal
Interface Salesforce interne : widget sur une page d’enregistrement
Le widget détecte isAsync et affiche un état d’attente. Il se met à jour lorsque le nouveau message de l’agent arrive dans la conversation. L’utilisateur constate un bref délai, mais le reste de la conversation ne change pas.
Widget externe
Le widget du site web détecte isAsync et affiche également un état d’attente. Comme il vérifie périodiquement le résultat plutôt que de recevoir un flux continu, la réponse apparaît quelques secondes après la fin du traitement.
Appelants par flux ou API
Les flux et les appels API directs doivent gérer explicitement les réponses asynchrones. Une solution simple consiste à créer un flux déclenché par enregistrement sur l’objet de demande asynchrone. Lorsque le statut passe à Complet, exécutez la suite nécessaire : transmettre la réponse à une messagerie, modifier un enregistrement ou envoyer un e-mail. Consultez Intégration des canaux de messagerie pour le parcours complet.
Canal e-mail — Réception
Les e-mails entrants de collecte de documents sont toujours traités de façon asynchrone. Le service de messagerie stocke les pièces jointes et lance une tâche Queueable ; l’agent travaille en arrière-plan. Consultez Canal e-mail — Réception.
Suivre le traitement
- La demande asynchrone constitue la référence principale : statut, nombre de tentatives, message d’erreur et date de fin.
- La conversation affiche immédiatement le message utilisateur, puis la réponse de l’agent une fois le travail terminé, sans message intermédiaire de progression.
- Le débogueur de conversations aide à analyser les messages et traces disponibles avec une reconstruction de la configuration actuelle. Il ne fournit pas une copie exhaustive du prompt historique ; consultez les transactions de crédits pour la consommation.
- Le journal d’incidents consigne les échecs du traitement lorsque la journalisation est activée. Consultez Journaux d’incidents IA.
Concevoir des agents adaptés à l’asynchrone
La plupart des agents n’exigent aucune conception particulière : le routage est automatique et le comportement conversationnel reste identique. Deux points méritent toutefois votre attention :
Budget de jetons. Une tâche Queueable possède ses propres limites Salesforce. Des boucles d’agent très longues ou des prompts trop volumineux peuvent encore atteindre ces limites. Gardez un budget réaliste et répartissez les traitements longs sur plusieurs échanges lorsque c’est possible.
Cartes de confirmation. Les canaux sans interface, comme la réception d’e-mails ou les exécutions par flux, ne peuvent pas afficher une carte. Les requêtes automatisées peuvent exécuter directement les outils autorisés : limitez le périmètre et les droits en conséquence. Autoriser les requêtes automatisées ouvre le mode d’appel ; cela n’ajoute pas une approbation. Consultez Confirmation des actions.
Bonnes pratiques
Vérifiez isAsync dans vos appelants personnalisés. Traiter une réponse comme synchrone alors que isAsync vaut true laisse l’appelant attendre une réponse qui ne sera jamais présente dans ce résultat immédiat.
Utilisez un flux déclenché sur la demande asynchrone pour les suites de traitement. Il permet de réagir à la fin de l’exécution : lancer un rappel, transmettre une réponse par un autre canal ou modifier un statut.
Ne comptez pas sur des reprises automatiques. Si une demande passe en Erreur, commencez le diagnostic par le journal d’incidents. Examinez la cause avant de mettre en place une relance : répéter une demande ne corrige pas une erreur persistante.
Surveillez la file d’attente. Une accumulation d’enregistrements File d'attente indique que les demandes arrivent plus vite qu’elles ne sont traitées. Allégez d’abord les outils et les budgets de jetons avant d’augmenter la concurrence des traitements.
Automatisation et fiabilité
Les appels groupés depuis Flow peuvent retourner des identifiants de demandes différées plutôt qu’une réponse immédiate. Examinez les éléments suivants qui attendent réponse, crédits ou résultats dans la même transaction. Les actions automatiques conservent canal et mode configurés, et leurs résultats réels restent dans le contexte ; cela ne garantit pas un tour narratif supplémentaire. Les décalages horaires explicites sont préservés dans les chemins pris en charge pour événements, planifications, écritures de champs et CSV. Sans décalage, l’interprétation de l’utilisateur exécutant reste applicable. Le mode Système ne crée pas d’avertissement du seul fait de son utilisation ; journaux et notifications ERROR demeurent. L’extraction respecte la limite de sortie, les couleurs fonctionnent dans les thèmes Salesforce pris en charge et les tests évitent les références statiques bloquant l’installation sans types d’enregistrement Compte.
Questions fréquentes
Le déclencheur le plus courant est un fichier trop volumineux pour les limites de traitement synchrone Salesforce. La plateforme le détecte avant l’appel au modèle et confie la demande à une tâche en arrière-plan.
La plateforme décide selon les caractéristiques de la demande ; l’appelant ne choisit pas ce mode par un simple paramètre. Pour organiser un travail sans utilisateur en attente, appelez l’action invocable depuis un flux et laissez la plateforme décider entre traitement direct et traitement en arrière-plan.
L’appel au modèle coûte autant ; l’asynchrone change uniquement le lieu d’exécution du travail. Si votre intégration relance une demande en échec, chaque nouvel appel au modèle consomme normalement des crédits. Il n’existe pas de relance automatique des demandes asynchrones.
Le widget affiche un état d’attente pendant le traitement. Pour un canal sans interface, prévoyez un indicateur dans l’intégration : saisie en cours dans une messagerie, e-mail d’accusé de réception ou champ de statut sur l’enregistrement suivi par le flux.
La demande passe en Erreur avec un message explicatif. Un incident est journalisé si cette journalisation est activée. La conversation peut contenir le message utilisateur sans réponse finale. Avant une relance, vérifiez les opérations déjà réalisées afin d’éviter les doublons ; l’intégration doit signaler clairement l’échec.
Oui. La même boucle d’agent s’exécute et les outils restent soumis au canal et aux autorisations applicables. Les canaux sans interface peuvent exécuter directement les actions autorisées. Limitez les outils à la lecture si le traitement doit rester en lecture seule, et prévoyez séparément toute approbation humaine.
Consultez les messages et traces de la conversation, puis utilisez le débogueur pour analyser les éléments disponibles. Il reconstruit une partie de la configuration actuelle et ne garantit pas l’affichage de chaque appel ou du prompt historique complet. Les transactions de crédits fournissent la consommation enregistrée.
Prochaines étapes
Consultez Intégration des canaux de messagerie pour un parcours complet utilisant l’asynchrone, ou Appeler REDA AI depuis des flux pour la gestion côté flux.