Transcription
Vous avez probablement déjà entendu parler des boucles d'agents, car tout le monde en fait beaucoup l'éloge en ce moment. Et vous pourriez penser qu'il s'agit simplement d'un moyen pour ces entreprises d'IA de vous faire dépenser plus pour leurs produits, car ces boucles consomment beaucoup de jetons. Mais cela n'arrive que lorsque vous utilisez le mauvais type de boucle pour la tâche. Comme vous le savez déjà, nous sommes une entreprise de logiciels et nous avons expérimenté ces boucles dans nos tâches de codage IA. En cours de route, nous avons cartographié les différents types de boucles et les cas d'utilisation pour lesquels chacune est réellement adaptée. Ainsi, parmi toutes les boucles que nous avons configurées, nous allons partager celles que nous avons trouvées véritablement utiles. Nous vous montrerons également comment configurer chacune d'elles et comment chaque boucle va impacter votre flux de travail. Avant d'aborder les différents types de boucles, rappelons rapidement ce qu'est réellement l'ingénierie de boucles pour ceux d'entre vous qui sont nouveaux ici. Nous n'allons pas approfondir ici, mais si vous voulez l'analyse complète, nous l'avons couverte dans une vidéo précédente sur la chaîne. L'idée principale de l'ingénierie de boucles est que vous cessez d'être la personne qui écrit les invites qui pilotent l'agent et vous le transformez en un système qui écrit la boucle. elle-même. Au lieu de passer votre temps à tout configurer et à écrire des invites longues et soigneusement structurées juste pour qu'il construise, vous laissez l'agent gérer tout par lui-même. Il apprend au fur et à mesure, grandit à partir des problèmes qu'il rencontre en cours de route et détermine ce qu'il doit faire ensuite. C'est ce qu'est réellement une boucle d'agent. Dans cette vidéo précédente, nous avons divisé les boucles en deux types en fonction du résultat que vous obtenez, la boucle déterministe et la boucle non déterministe. Une boucle déterministe est le genre où vous connaissez déjà le résultat. L'agent a donc un moyen solide de vérifier son propre travail par rapport à celui-ci et il continue de travailler jusqu'à ce qu'il y parvienne. Une boucle non déterministe est le genre où vous ne le faites pas. Il n'y a donc aucun moyen solide pour l'agent de vérifier son travail, ce qui signifie que vous avez besoin d'autres moyens pour le gérer. Mais c'était une division large et nous avons montré une seule façon de configurer chacune d'elles. Elles peuvent être construites de nombreuses manières différentes et chaque configuration change ce que vous pouvez faire. Le premier type est celui que la plupart d'entre vous ont probablement déjà utilisé. C'est essentiellement le bloc de construction de toutes les autres boucles et l'exemple le plus clair est la commande objectif. Nous l'appelons la boucle sans état et cela signifie essentiellement que la boucle ne conserve rien ni ne s'améliore pendant qu'elle fonctionne. Il n'y a aucune partie où elle apprend de ce qui s'est passé et s'améliore. C'est exactement ce qui rend ces boucles les plus simples qui soient. Celle que vous avez probablement déjà vue de ce type est la boucle Ralph, et elle est sans état car elle n'a jamais conservé de mémoire. Elle exécutait simplement la même tâche encore et encore, et au moment où elle voyait que la tâche était terminée, elle s'arrêtait. Comme vous le savez peut-être déjà à propos de la commande objectif, c'est le meilleur exemple de boucle sans état. Pour l'utiliser, vous lui dites ce que vous voulez construire juste après la commande objectif. À partir de là, Claude définit cela comme objectif et commence à y travailler. Ensuite, chaque fois que l'agent principal décide qu'une tâche est terminée, il utilise un modèle plus petit pour vérifier le travail. Dans Claude code, ce modèle plus petit est haiku. Il vérifie tout ce que l'agent a fait par rapport aux exigences que vous avez données dans l'invite. Et si la tâche n'est pas entièrement terminée, il ré-invite l'agent à terminer ce qu'il a manqué. Mais il y a un problème avec cette boucle. Elle repose entièrement sur le modèle pour décider si une tâche est terminée, sans norme pour mesurer le travail. C'est pourquoi elle fonctionne mieux sur des fonctionnalités dont les exigences peuvent être vérifiées de manière concrète et tangible. Une façon de le faire est avec des tests. Comme nous en avons parlé dans notre vidéo précédente, nous écrivons les tests avant de demander à Claude de construire une fonctionnalité. De cette façon, si Claude modifie cette fonctionnalité d'une manière qu'il ne devrait pas, les tests génèrent une erreur et indiquent à Claude que son implémentation est incorrecte. Et une fois que nous avons des tests pour chaque fonctionnalité, nous pouvons donner à l'agent une véritable autonomie et le laisser travailler sans nous inquiéter qu'il casse les autres fonctionnalités ou qu'il construise celle que nous voulons de la mauvaise manière. Une fois que vous avez écrit les tests, vous pouvez demander à Claude code de définir l'objectif comme étant de faire passer cette fonctionnalité par tous les tests, et il continue d'écrire du code. Il exécute les tests pour se vérifier et continue jusqu'à ce que tous les tests soient réussis. Une fois qu'ils sont tous réussis, cela signifie que la fonctionnalité est construite correctement et Claude marquera l'objectif comme terminé. Comme l'agent travaille de manière autonome, vous voudrez ajouter une ligne à votre fichier Claude.MD. Cette ligne indique à l'agent de sauvegarder chaque version fonctionnelle de l'application. De cette façon, s'il casse l'application plus tard, il peut simplement revenir à la dernière version qui fonctionnait et continuer à partir de là au lieu d'essayer d'annuler les modifications à partir de la mémoire. Mais avant de passer à d'autres types, parlons de notre sponsor, Miniax. Minax vient de lancer M3 et c'est le premier modèle à poids ouvert à atteindre la frontière sur trois choses à la fois : le codage, un contexte de 1 million de jetons et la multimodalité native. Nous avons donc branché l'API M3 directement dans Claude code et lui avons donné un vrai travail : rechercher les meilleures voitures électriques actuellement en vente et construire un tableau de bord de comparaison en direct. M3 s'en est chargé tout seul. Il a navigué sur le web, extrait les spécifications et les prix réels, puis a livré un tableau de bord fonctionnel à partir de zéro. Vous pouvez rechercher différentes marques de VE, parcourir leurs derniers modèles, et tout se met à jour en temps réel. En navigation autonome, il surpasse Opus 4.7 et son contexte d'un million de jetons a contenu toutes les pages plus l'ensemble du code dans une seule fenêtre. Mais les exécutions d'agents comme celles-ci consomment beaucoup de jetons, et c'est là qu'intervient le plan de jetons MiniAX. Choisissez un plan de jetons pour des coûts fixes ou payez à l'usage pour plus de flexibilité. Le texte, l'image, la parole et la musique partagent le même pool de jetons avec les quotas les plus élevés. Les plans commencent à seulement 20 $ par mois. Alors, cliquez sur le premier lien dans la description et bénéficiez d'une réduction exclusive de 12 %. La boucle sans état que nous venons de parcourir ne conserve aucun état. Elle fait tout par elle-même à partir des instructions, sans auto-amélioration dans le processus. Le type suivant fonctionne de manière opposée et nous l'appelons la boucle d'apprentissage. Une boucle d'apprentissage fonctionne différemment. Au lieu de simplement accomplir une tâche et de s'arrêter comme une boucle sans état ou la commande objectif, elle se concentre sur l'amélioration de quelque chose que vous utiliserez de manière répétée, qu'il s'agisse d'une compétence ou d'un flux de travail. La façon dont elle le fait est simple. Elle exécute la compétence, observe comment elle a fonctionné, puis l'améliore en fonction de ce qu'elle a appris, en conservant un enregistrement complet de chaque leçon en cours de route. Ainsi, lorsque vous exécutez la compétence, lorsque vous l'utilisez réellement, l'agent sait ce qui a causé des problèmes par le passé, de sorte qu'il ne s'en approchera pas. Vous pouvez mettre ce type de boucle au travail pour de nombreuses choses. Par exemple, sur notre site communautaire, nous avons créé plusieurs compétences pour gérer différents flux de travail répétés tout en assemblant le site. Mais la création d'une compétence soulève une question évidente, à savoir comment sauriez-vous si elle fonctionne comme elle le devrait. Pour y répondre, nous avons mis en place une boucle d'apprentissage complète. Nous l'avons fait en créant une commande de boucle de compétence qui déclenche la boucle. Cette commande contient des instructions pour appeler un agent d'amélioration de compétence et continuer à l'appeler jusqu'à ce qu'il n'y ait plus d'améliorations possibles. Cet améliorateur de compétence est en fait un agent que nous avons créé qui améliore la compétence en évaluant sa qualité, en la testant dans plusieurs domaines et en observant les problèmes qui surviennent. Pour l'utiliser, il suffit d'exécuter la commande et de passer la compétence que vous souhaitez améliorer, et elle se met au travail. Cette boucle s'exécute en plusieurs tours. Dans chaque tour, elle exécute un ensemble de tests et de vérifications après avoir apporté ses modifications. Ensuite, elle lance une session Claude distincte qui travaille uniquement sur l'invite que vous lui passez, s'exécutant en arrière-plan sans s'arrêter pour demander la permission et renvoyant la sortie. À l'intérieur de ces sessions, elle exécute l'implémentation de deux manières, une avec la compétence et une sans. Elle peut donc mesurer l'impact réel de la compétence. Cette comparaison lui permet de déterminer exactement ce qui doit être amélioré et elle apporte ces modifications directement. Mais la partie la plus importante est le fichier learning.md qu'elle crée. Ce fichier donne à l'agent un moyen de savoir ce qui fonctionne et ce qui ne fonctionne pas, et il vit à l'intérieur de la compétence elle-même. C'est essentiellement un journal d'amélioration qui documente tout ce que l'agent apprend dans un format structuré. Il enregistre ce qu'il a essayé et quel a été le résultat, à la fois avec et sans la compétence. Ensuite, il liste les leçons qu'il a tirées de tous les tours sur lesquels il a travaillé. Et c'est ainsi qu'il continue tour après tour jusqu'à ce que la compétence soit affinée en la meilleure version possible d'elle-même. Vous pouvez utiliser la même configuration pour améliorer n'importe quel flux de travail que vous avez. Dans notre vidéo précédente, nous avons montré comment construire une boucle avec deux agents. L'un gère l'implémentation et l'autre examine le travail et renvoie les corrections à l'agent d'implémentation à appliquer. Il y a un problème avec cette configuration, c'est qu'un seul agent d'examen gère tous les aspects de l'examen par lui-même. Mais un examen ne concerne jamais un seul aspect. Il vient toujours de différentes perspectives et c'est trop de terrain pour qu'un seul agent puisse le couvrir seul. Il est préférable de les diviser entre différents agents, car lorsque plusieurs agents examinent sous plusieurs dimensions, ils couvrent les angles morts que tout agent unique manquerait, ce qui rend l'examen beaucoup plus complet. L'idée est proche du conseil LLM qu'Andre Karpathy a publié, qui est un conseil de plusieurs agents qui se parlent et débattent d'un sujet que vous leur confiez en utilisant le raisonnement de plusieurs modèles pour parvenir à la bonne réponse. Pour créer une boucle multi-agents, vous devez créer plusieurs agents. Par exemple, nous avons créé quatre agents dans la boucle que nous avons mise en place. Le premier vérifie l'exactitude factuelle et il est équipé d'outils comme la recherche web afin de pouvoir se baser sur des sources réelles. Le second est un agent de vérification de domaine qui vérifie si ce qui est examiné est réellement pertinent par rapport à ce que nous essayons de faire. Le troisième est un agent critique de sécurité qui examine les problèmes de sécurité comme le contenu sensible, ainsi que les risques de sécurité et les violations de politique qui pourraient causer des problèmes à l'avenir. Et le dernier est le critique de style, qui s'assure que le contenu est clair, bien écrit et adapté au style que nous recherchons. Vous pouvez utiliser ces agents pour n'importe quelle tâche, qu'il s'agisse de codage ou non. Ce qui relie ces quatre agents est une commande d'orchestration que nous avons créée. Cette commande contient les instructions détaillées sur la façon dont elle doit gérer et coordonner les quatre agents et traiter les commentaires que chacun renvoie. Pour démarrer la boucle, vous exécutez la commande d'orchestration et lui demandez d'examiner ce que vous voulez, et elle lance tous les agents pour le processus. La commande d'orchestration s'exécute également en plusieurs tours, lançant chaque agent à chaque tour. L'agent principal applique toutes les corrections signalées au tour 1, puis les relance toutes pour le tour suivant. À la fin du dernier passage, vous vous retrouvez avec l'application en bien meilleure forme. Si vous préférez que les agents communiquent directement, vous pouvez utiliser le flux de travail de l'équipe d'agents que nous avons couvert dans une vidéo précédente, qui vous donne plus de l'expérience du conseil LLM sans qu'un agent ne gère toute la communication. Mais nous avons choisi l'orchestrateur car un agent doit conserver le contexte des tours précédents pour coordonner correctement le flux de travail. Un autre type que nous utilisons souvent est la boucle de vérification. Elle utilise également plusieurs agents où l'un fait l'implémentation et l'autre note cette implémentation, et le travail de l'implémenteur est d'obtenir ce score aussi élevé que possible par rapport à une métrique définie. Pour configurer cela, nous avons créé une commande qui coordonne l'ensemble de la boucle en exécutant l'ensemble du flux de travail d'examen par elle-même. Comme vous le savez déjà, cursor a une revue thermonucléaire. C'est en fait une compétence de revue très puissante qui vérifie la propreté et la santé du code, de sorte qu'il reste facile à construire par la suite. Elle audite tout le code et renvoie une revue approfondie avec des normes non négociables, de sorte que vous êtes garanti la plus haute qualité de revue qu'elle puisse produire. Pour ce faire, elle exécute un flux de travail dynamique. La revue doit couvrir de nombreuses catégories et un flux de travail dynamique est la meilleure façon de gérer cela, car il répartit le travail sur plusieurs sous-agents qui prennent chacun un aspect différent à la fois. Comme nous l'avons mentionné précédemment, nous avons créé deux agents qui agissent comme les acteurs de cette boucle. Le premier est l'implémenteur dont le travail est de lire le PRD, puis de construire la fonctionnalité requise. Le second est le réviseur de code thermonucléaire et son seul travail est de renvoyer un score de revue, car tout ce qu'il fait est de réviser et de noter. Il n'a pas d'outils d'édition. Pour le déclencher, vous exécutez la commande de boucle de revue. Elle commence par comprendre ce que l'application est censée construire, puis lance une revue thermonucléaire pour le tour 1. Cette première revue signale les problèmes qu'elle trouve, y compris un problème critique qui empêche même le démarrage de l'application. Elle enregistre les conclusions dans un fichier JSON et lance l'agent d'implémentation pour les corriger. La boucle continue à partir de là. Mais gardez une chose à l'esprit, car elle examine de nombreuses dimensions, cela prend beaucoup de temps et consomme beaucoup de jetons, car le flux de travail dynamique qui la pilote répartit le travail sur un ensemble complet de sous-agents à la fois. Nous ne la recommandons donc pas, sauf si vous avez déjà construit l'ensemble de l'application à plus grande échelle et que vous souhaitez qu'elle soit examinée en profondeur. Vous pouvez également construire cette même boucle sans le flux de travail dynamique en utilisant un agent de revue normal, ce qui prend moins de temps et consomme beaucoup moins de jetons. Et si vous appréciez la vidéo jusqu'à présent, abonnez-vous à la chaîne et appuyez sur le bouton d'enthousiasme. Ce petit geste de soutien nous aide beaucoup. Parmi toutes les boucles que nous vous avons présentées jusqu'à présent, aucune d'entre elles n'avait une étape distincte pour améliorer la boucle elle-même. Mais c'est vraiment un élément central de ce qu'une boucle est censée faire. C'est là qu'intervient la boucle d'amélioration du flux de travail. Ce que fait cette boucle, c'est aller au-delà de la simple répétition de la tâche. Au lieu de simplement l'exécuter encore et encore, elle examine le processus lui-même et suggère des améliorations au flux de travail. Maintenant, vous pourriez penser que la boucle d'apprentissage précédente fait déjà cela. Mais il y a une réelle différence. La boucle d'apprentissage améliore une compétence, une partie du processus. Celle-ci améliore la boucle elle-même, l'ensemble du processus que vous avez mis en place. Le point d'entrée est une commande itérer qui agit comme l'orchestrateur de tout ce qui se passe pendant chaque exécution. Il y a trois agents cette fois. Le premier est un agent constructeur qui gère l'implémentation et livre une des exigences de l'application à chaque exécution. Le second est un évaluateur qui vérifie cette implémentation par rapport à une grille que nous avons définie pour agir comme garde-fou de la qualité de l'application et note le travail sur 100. Et le troisième est l'agent optimiseur de processus qui est celui qui gère réellement l'auto-amélioration. Normalement, une boucle suit le même cycle où elle planifie, implémente, vérifie et répète. Mais cet agent ajoute une étape supplémentaire consistant à revenir sur l'itération de la boucle et à suggérer des moyens de l'améliorer. Pour l'utiliser, il suffit d'exécuter la commande itérer tout. Par tout, nous entendons que nous implémentons l'ensemble de l'application divisée en parties au sein d'un seul flux de travail. La boucle commence par lancer l'agent constructeur. Ensuite, l'évaluateur évalue ce qu'il a construit par rapport à la grille et enregistre le score dans un fichier JSON qui suit chaque tour. Ensuite, l'agent optimiseur de processus intervient en examinant la conversation pour repérer tout ce qui pourrait améliorer le flux de travail, en s'assurant que l'application est construite avec une haute qualité et que les bonnes étapes sont suivies. Ainsi, à la fin de ce flux de travail, vous n'obtenez pas seulement une application construite. Vous obtenez un flux de travail qui a été testé et affiné, chaque étape étant validée comme étant nécessaire. Cela nous amène à la fin de cette vidéo. Si vous souhaitez soutenir la chaîne et nous aider à continuer à créer des vidéos comme celle-ci, vous pouvez le faire en utilisant le bouton super thanks ci-dessous. Comme toujours, merci d'avoir regardé et à bientôt dans la prochaine.