Sept leçons d'ingénierie pour construire des agents de chat IA en production

Les ingénieurs de Trigger.dev ont publié une rétrospective détaillée sur la construction d'un agent de chat IA de qualité professionnelle pour leur tableau de bord développeur. Sorti en octobre 2026, l'article expose sept leçons critiques apprises lors de la mise en œuvre de fonctionnalités telles que le débogage, la génération de graphiques et la recherche dans la documentation. Les conclusions se concentrent sur les décisions architecturales qui améliorent l'expérience utilisateur et la fiabilité du système.

Ce qui s'est passé

L'équipe a développé un outil interne permettant aux utilisateurs d'interagir avec leur plateforme via le langage naturel. Cet agent exécute des tâches complexes comme l'inspection des logs d'exécution, la génération de visualisations et l'interrogation de la documentation. Étant donné que ces opérations impliquent des traitements lourds tels que l'exécution en sandbox et l'accès aux fichiers, les ingénieurs ont rencontré des défis spécifiques liés à la latence et à la gestion de l'état.

Ils ont identifié que les modèles standard requête-réponse étaient insuffisants pour les tâches d'agents de longue durée. Pour y remédier, ils ont implémenté une architecture scindée où une réponse initiale légère est diffusée immédiatement tandis que la logique plus lourde de l'agent s'initialise en arrière-plan. Cette approche garantit que les utilisateurs reçoivent un retour instantané, par exemple en voyant apparaître un appel d'outil comme get_run("abc123") en moins d'une seconde, plutôt que de fixer un indicateur de chargement statique.

L'article détaille également comment ils ont géré la compaction des conversations, la logique de nouvelle tentative (retry) et la durabilité du flux. En partageant leur code et leurs exemples de configuration, ils fournissent un modèle pour les autres développeurs confrontés à des problèmes similaires lorsqu'ils font passer des prototypes IA vers des environnements de production où la fiabilité et la performance perçue sont primordiales.

Comment cela fonctionne

Le mécanisme central repose sur le découplage de l'interaction utilisateur initiale de l'exécution complète de l'agent. Lorsqu'un message arrive, une route de serveur web standard gère le premier appel au modèle. Cet appel renvoie instantanément une réponse au client, contenant souvent un indicateur d'appel d'outil. Simultanément, le système démarre l'environnement complet de l'agent. Une fois prêt, l'agent prend le relais sur le contexte de conversation, incluant les appels d'outils initiaux, assurant ainsi la continuité sans dupliquer les messages ni changer le ton.

Pour l'intégrité des données, le système utilise des flux durables soutenus par un stockage objet. Chaque fragment de la réponse reçoit un numéro de séquence. Si un client se déconnecte puis se reconnecte, il envoie l'ID de la dernière séquence reçue. Le serveur rejoue ensuite tous les fragments manquants depuis le stockage avant de reprendre le flux en direct. Cela empêche la perte de données et évite la situation inconfortable de devoir recommencer une longue génération depuis le début.

Le comptage des tokens pour la gestion de la fenêtre de contexte est optimisé en ne suivant que les tokens d'entrée de la dernière étape. Puisque la sortie d'une étape devient l'entrée de la suivante, sommer les entrées de chaque étape entraînerait un surcomptage massif. Cette méthode garantit que la compaction ne se déclenche que lorsque nécessaire, préservant le contexte pertinent sans résumé prématuré.

Détails clés

• Initialisation scindée : Le premier appel au modèle s'exécute dans le gestionnaire de requêtes pour la rapidité, tandis que l'agent lourd démarre en arrière-plan, réduisant de moitié le temps jusqu'à la première mise à jour utile.
• Comptage précis des tokens : La logique de compaction n'utilise que le nombre de tokens d'entrée de la dernière étape pour éviter de compter plusieurs fois l'historique répété de la conversation.
• Limites de nouvelle tentative : Les outils implémentent des compteurs internes de retry avec de courtes périodes de backoff pour les microcoupures réseau, plafonnant les échecs consécutifs pour prévenir les boucles infinies.
• Streaming durable : Les fragments de réponse sont stockés avec des ID de séquence dans le stockage objet, permettant aux clients de reprendre les flux interrompus sans heurt.
• Versionnage des prompts : Les prompts sont définis dans le code avec contrôle de version, permettant des mises à jour sans déploiement et des tests A/B via un tableau de bord.
• Évaluations en arrière-plan : Dix pour cent des tours de conversation terminés sont envoyés à un modèle juge pour être notés sur la pertinence factuelle, la qualité de la réponse et la concision.

Pourquoi c'est important

Pour les ingénieurs logiciels construisant des interfaces IA, la latence perçue est souvent plus critique que le temps d'exécution total réel. Les utilisateurs abandonnent les outils qui semblent non réactifs, même si le backend travaille dur. Le modèle d'initialisation scindée décrit ici offre une solution concrète à ce problème d'UX. Il démontre qu'il n'est pas nécessaire d'attendre que toute la pile de l'agent soit prête avant de fournir de la valeur à l'utilisateur. Montrer les étapes intermédiaires, telles que les invocations d'outils, crée la confiance et maintient l'engagement de l'utilisateur pendant les opérations plus longues.

La fiabilité des connexions de streaming est un autre point de douleur majeur dans les applications réelles. L'instabilité réseau est courante, surtout pour les utilisateurs mobiles ou ceux ayant des connexions précaires. Implémenter des flux durables avec reprise basée sur les séquences transforme une connexion HTTP fragile en une session robuste. Cela réduit les tickets de support et améliore la qualité globale de l'interaction, donnant à l'agent l'impression d'être une partie native de l'application plutôt qu'un service externe instable.

Enfin, l'accent mis sur l'observabilité et les évaluations souligne le passage d'une IA expérimentale à des systèmes d'ingénierie. Sans évaluation structurée et prompts versionnés, itérer sur le comportement de l'agent devient du tâtonnement. En traitant les prompts comme du code et en évaluant les sorties systématiquement, les équipes peuvent apporter des améliorations basées sur les données. Cette rigueur est essentielle pour maintenir des réponses de haute qualité à mesure que la complexité des outils et des requêtes utilisateurs augmente.

Ce que vous pouvez faire

• Implémentez un gestionnaire de réponse en deux étapes où le premier appel diffuse un retour immédiat pendant que l'agent principal s'initialise en arrière-plan.
• Auditez votre logique de comptage des tokens pour vous assurer que vous ne sommez pas les entrées de chaque étape historique, ce qui conduit à une compaction prématurée du contexte.
• Ajoutez des ID de séquence à vos réponses de streaming et stockez les fragments dans un stockage durable pour permettre la reprise côté client après les déconnexions.
• Définissez des limites explicites de nouvelle tentative dans vos définitions d'outils pour empêcher les agents de boucler indéfiniment sur des erreurs transitoires.
• Versionnez vos prompts dans le code et créez un mécanisme pour changer de version sans redéployer l'application entière.
• Mettez en place des jobs d'évaluation en arrière-plan qui notent un échantillon de conversations à l'aide d'un modèle juge.