L'un des premiers agents que j'ai construits était extrêmement simple : Il récupérait des informations d'un magasin de vecteurs, les formatant en HTML, et les envoyait par e-mail à l'utilisateur. Il n'y a pas plus simple que ça, et pourtant, cet agent échouait environ 1 % du temps. Pas d'erreur. Pas d'avertissement. Il renvoyait juste des données inutilisables. Voici la dure vérité : Les agents échouent beaucoup. Et ils échouent silencieusement. Tout le temps. Vous ne pouvez tout simplement pas faire confiance à un LLM pour faire la bonne chose à chaque fois. À ce jour, j'ai construit et déployé une couple de douzaines d'agents, et voici quelques-unes des choses qui fonctionnent réellement : 1. Observabilité dès le premier jour. Si vous ne pouvez pas voir ce que fait votre agent, vous ne pouvez pas le déboguer, l'améliorer ou lui faire confiance. Chaque agent devrait produire des traces montrant le flux de requêtes complet, les interactions avec le modèle, l'utilisation des tokens et les métadonnées de timing. 2. Barrières sur les entrées et les sorties. Tout ce qui entre et sort d'un LLM devrait être vérifié par un code déterministe. Même les choses qui ne sont pas susceptibles de casser finiront par casser. 3. Évaluation LLM-en-juge. Vous pouvez construire un juge simple en utilisant un LLM pour évaluer automatiquement les sorties de votre agent. Étiquetez un ensemble de données, rédigez le prompt d'évaluation, et itérez jusqu'à ce que votre juge détecte la plupart des échecs. 4. Analyse des erreurs. Vous pouvez collecter des échantillons d'échecs, les catégoriser et diagnostiquer les erreurs les plus fréquentes. 5. Ingénierie du contexte. Souvent, les agents échouent parce que leur contexte est bruyant, surchargé ou non pertinent. Apprendre à garder le contexte pertinent est énorme. 6. Boucles de rétroaction humaine. Parfois, la meilleure barrière est un humain dans la boucle, surtout pour des décisions à enjeux élevés.