Skip to main content
Utilisez cette recette lorsqu’un workflow de support doit :
  • hériter des paramètres de routage et de prompt d’un preset du tableau de bord
  • renvoyer une sortie structurée stricte
  • suspendre les cas à risque pour examen humain
  • laisser les échecs du gateway visibles dans les journaux au lieu de les masquer dans le code de l’agent

1. Commencez par un preset

Créez un preset tel que support-triage qui gère :
  • le modèle routé par défaut ou la cible du routeur
  • les préférences de fournisseur
  • le prompt système du support
  • les paramètres de décodage stables
Le code de l’agent peut ainsi se concentrer sur le workflow au lieu de dupliquer les règles des requêtes.

2. Définissez un contrat de triage précis

Gardez le format de la première sortie assez simple pour que les opérateurs puissent l’examiner rapidement.

3. Créez l’agent piloté par un preset

Le SDK résout preset: "support-triage" sous la forme d’alias du gateway @support-triage.

4. Configurez l’adaptateur connecté au gateway

Utilisez les valeurs par défaut de l’adaptateur pour les éléments qui doivent rester fixes à chaque exécution du triage :

5. Exécutez le workflow avec un nombre limité de tentatives

Si l’exécution se met en pause pour vérification, reprenez-la explicitement :

6. Traitez les échecs du gateway comme des événements opérationnels

Ne masquez pas les échecs en les absorbant dans la chaîne de callbacks de l’agent. Interceptez plutôt explicitement AgentGatewayError :
Ensuite :
  1. laissez le runtime enregistrer l’état failed de l’exécution et des étapes
  2. Lors des reprises ultérieures, consultez loaded.run.errorDetails ou loaded.steps[n].errorDetails lorsque l’exception d’origine n’est plus en mémoire
  3. examinez les détails de la requête pour vérifier :
    • l’application des guardrails
    • les détails du routage
    • l’exécution des plugins
    • les identifiants de requête et les données du fournisseur
C’est particulièrement important lorsque :
  • un guardrail bloque la requête
  • la liste d’autorisation du preset rejette le modèle demandé
  • les identifiants du fournisseur ou les filtres d’activation éliminent les candidats routés
  • la réparation de réponse ne parvient pas à rétablir un JSON valide selon le schéma

7. Points à vérifier

Après une exécution réussie et une exécution volontairement risquée, vérifiez les points suivants :
  • la vue détaillée de la requête affiche la cible définie par le preset
  • les cas à haut risque sont suspendus avec le statut waiting_for_human
  • les étapes de modèle réessayées conservent modelAttempts
  • les échecs liés aux guardrails ou au preset restent visibles dans les détails de la requête, et ne sont pas masqués dans les exceptions de l’agent

Guides associés

Dernière modification le 2 octobre 2026