Apprenez à créer et à utiliser des agents IA

Presque tous les agents, quelle que soit la structure qui les a produits, sont assemblés à partir de la même poignée de pièces. Apprendre à les distinguer constitue l'essentiel du débogage, car les échecs se localisent clairement le long d'eux.

Le modèle est le moteur du raisonnement. Il lit l'état actuel et décide de la suite. Le choix du modèle est une véritable décision d'ingénierie plutôt qu'un défaut : un modèle plus grand résiste mieux aux instructions ambiguës, un modèle plus petit coûte une fraction et répond plus rapidement. Les agents matures en utilisent souvent plusieurs, réservant le modèle coûteux aux étapes qui nécessitent véritablement du jugement.

Les instructions, généralement fournies sous forme d'invite système, constituent un contrat plutôt qu'une personnalité. Ils établissent le rôle, les contraintes, le format de sortie et surtout la définition du fait. Les instructions vagues sont la cause la plus courante des agents qui tournent en rond ou s’arrêtent à mi-chemin.

Le contexte correspond à tout ce que le modèle peut voir au cours de cette étape particulière : la tâche elle-même, les enregistrements que vous avez récupérés, les résultats des appels d'outils précédents. Traitez-le comme un budget plutôt que comme un conteneur. Chaque jeton dépensé pour du matériel non pertinent coûte de l’argent, ajoute de la latence et dilue l’attention du modèle sur la seule ligne qui compte réellement.

La mémoire est ce qui survit entre les étapes et entre les exécutions. La mémoire à court terme n’est généralement que la transcription en cours. La mémoire à long terme est un acte délibéré : un résumé que vous persistez, un enregistrement des décisions passées, un profil de l'utilisateur. En confondant les deux, les agents finissent soit par devenir amnésiques entre les sessions, soit par se noyer lentement dans leur propre histoire.

Les outils sont l'espace d'action, les fonctions typées que l'agent est autorisé à appeler. Leurs noms et descriptions font partie de l'invite, car le modèle sélectionne un outil en les lisant. Un outil appelé processData sans description sera mal choisi et imputé au modèle.

L'étape de décision est le moment où le modèle émet soit un appel d'outil avec des arguments, soit une réponse finale. Tout existe en amont pour bien faire ce choix.

L'exécution est le moteur d'exécution : le composant qui appelle réellement l'outil, applique les limites de boucles et de nouvelles tentatives, attache les informations d'identification, gère les erreurs et enregistre ce qui s'est passé. Les frameworks vous remettent les éléments de raisonnement. Le temps d’exécution est ce qui permet de présenter le résultat en toute sécurité à d’autres personnes.

Assemblé, le cycle se lit comme suit : observer l'état, choisir une action, l'exécuter, observer le résultat, répéter. Lorsque quelque chose ne va pas, le symptôme pointe généralement vers une partie. Une mauvaise réponse en toute confiance manque normalement de contexte. Une action inappropriée est normalement une mauvaise description de l'outil. Une course qui ne se termine jamais est normalement une définition manquante de ce qui est terminé.

La capacité d’un agent dépend des actions et des informations que vous lui transmettez. C’est là que réside la majeure partie de l’ingénierie pratique.

Concevoir des outils étroits et en forme de verbe. Un outil qui lit les commandes des clients bat celui qui gère la base de données. Les outils étroits produisent des décisions claires, sont faciles à autoriser et échouent d’une manière que vous pouvez interpréter. Les outils larges invitent le modèle à improviser, et c'est l'improvisation qui fait mal.

Écrivez la description du modèle, pas celle de vos collègues. Il doit indiquer ce que fait l'outil, quand l'utiliser, quand ne pas l'utiliser et ce qu'il renvoie. Tapez les arguments et validez-les. Un schéma n'est pas ici de la bureaucratie, c'est la différence entre un appel rejeté et une écriture mal formée dans un système de production.

Résistez à l’ajout d’outils de manière spéculative. La qualité de la sélection se dégrade à mesure que l’espace d’action s’agrandit : avec trente outils disponibles, le modèle raisonne sur le choix plutôt que sur la tâche, et se trompe plus souvent. Si deux outils se chevauchent, fusionnez-les ou supprimez-en un.

Le contexte doit être récupéré et non vidé. Récupérez les enregistrements spécifiques dont cette tâche a besoin et transmettez-les. Lorsque la source est volumineuse, divisez-la judicieusement et récupérez-la par pertinence plutôt que de coller l'intégralité du document. Demandez des citations afin qu'une réponse puisse être attribuée au passage qui l'a produite.

Séparez la lecture de l’écriture. La plupart des agents ont besoin d'un accès large en lecture et d'un accès très restreint en écriture, et les traiter comme une seule autorisation est la façon dont un agent de synthèse finit par pouvoir supprimer des enregistrements. Là où une écriture est irréversible, placez un humain devant elle.

C'est dans les intégrations que cela devient un problème d'organisation plutôt qu'un problème de codage. Chaque équipe connectant sa propre connexion au même système en amont produit des informations d'identification en double, des politiques incohérentes et aucune piste d'audit unique. Un standard ouvert tel que MCP permet à tout agent compatible de réutiliser les mêmes intégrations gouvernées, avec une liaison par système en amont au lieu d'une par équipe.

Les informations d’identification méritent leur propre règle, et elle est courte : l’agent n’a jamais de secret. Il demande l'action et la plateforme joint les informations d'identification au moment de l'appel sortant. De cette façon, une invite divulguée, un journal détaillé ou une transcription partagée ne devient jamais une clé divulguée.

Enfin, prévoyez un échec partiel. Les systèmes réels limitent le débit, paginent, expirent et renvoient une demi-réponse. Un agent qui traite chaque réponse de l'outil comme un succès ne s'appuiera en toute confiance sur rien. Renvoyez les erreurs sous forme de données structurées sur lesquelles le modèle peut raisonner et décidez à l'avance quelles défaillances doivent arrêter l'exécution plutôt que d'être contournées.

Un agent qui s'exécute uniquement sur la machine sur laquelle il a été écrit est un prototype. L'emballage est ce qui le transforme en quelque chose qu'une autre personne, une équipe ou un environnement peut exécuter sans vous poser de questions.

Commencez par la reproductibilité. Épinglez vos dépendances plutôt que d’accepter la dernière solution. Tapez les entrées et les sorties avec un schéma afin que les appelants sachent exactement quoi envoyer et ce qui revient. Conservez la configuration en dehors du code, afin que le même artefact puisse être exécuté lors de la préparation et de la production sans modification.

Soyez explicite sur ce qui ne doit pas voyager avec. Des secrets, évidemment, mais aussi des points de terminaison spécifiques à l'environnement, des identifiants de compte codés en dur et des chemins absolus. Si l'agent ne peut pas démarrer sans valeur, il doit échouer bruyamment au démarrage en indiquant quelle valeur manque, plutôt qu'à mi-chemin d'une exécution.

Déclarez le contrat dont l'agent a besoin pour fonctionner : quels outils il attend, quelles autorisations ces outils nécessitent, quel modèle il assume et ce qu'il coûte approximativement par exécution. Un réviseur devrait être en mesure de décider s’il doit l’approuver à partir de cette seule déclaration.

Versionnez-le comme un logiciel, car c'est ce que c'est. Conservez-le dans Git, pointez sur une version spécifique plutôt que sur une branche, comparez deux versions pour voir ce qui a changé dans l'invite ainsi que dans le code, et soyez capable de revenir en arrière dans une commande lorsqu'un changement s'avère pire qu'il n'y paraissait.

Expédiez l’ensemble d’évaluation avec l’agent. C'est la seule description honnête de ce que l'agent est censé faire, et elle permet à celui qui en hérite de vérifier que son environnement se comporte comme le vôtre avant de faire confiance à la sortie.

Enfin, écrivez les limites en langage clair : à quoi sert cet agent, ce qu’il ne doit jamais faire, à qui appartient-il et que faire en cas d’échec. Cette note coûte dix minutes et fait la différence entre un agent qui est adopté et un autre qui est discrètement abandonné.

Un agent est un projet. Trente agents représentent un problème opérationnel, et cela arrive plus tôt que prévu par la plupart des équipes, généralement sans que personne ne décide que cela devrait être le cas.

Le changement est qualitatif plutôt que quantitatif. Avec un seul agent, vous vous souvenez de ce qu'il fait. Avec trente, réparties dans des équipes qui ont chacune choisi leur propre cadre, personne ne détient la vision globale, et les questions importantes deviennent sans réponse : qu'est-ce qui fonctionne, à qui appartient-il, que peut-il toucher, qu'a-t-il fait et combien cela nous coûte-t-il.

L’inventaire passe avant tout, car tout le reste en dépend. Chaque agent porte une identité, un propriétaire et une version, quel que soit celui qui l'a produit. Les agents créés en dehors de la plateforme sont catalogués selon les mêmes conditions que ceux créés sur celle-ci, ce qui est la seule manière pour que l'inventaire reste honnête.

Le contrôle est appliqué de manière centralisée et appliqué de manière uniforme. Une équipe de plateforme définit la politique une seule fois, et le runtime l’applique aux agents de chaque équipe au moment de l’action. C'est l'arrangement qui résout le bras de fer habituel entre l'ingénierie, qui ne veut pas demander la permission pour chaque agent, et la sécurité, qui ne peut pas approuver ce qu'elle ne peut pas voir.

L’observabilité à l’échelle de la flotte signifie bien plus que la simple conservation des journaux. Les traces vous permettent de rejouer n'importe quelle course individuelle. Une piste d'audit immuable enregistre l'utilisateur agissant, les informations d'identification utilisées et les résultats produits. Le score d'évaluation s'exécute en permanence en fonction des critères que vous définissez, couvrant le comportement, la structure, la latence et le coût, et un échec de vérification critique arrête l'agent plutôt que de déposer un rapport à ce sujet. C'est l'étape de la journalisation passive à l'application active de la qualité.

Le coût est la dimension que les équipes découvrent en dernier et regrettent le plus. Les dépenses attribuées par agent, espace de travail, utilisateur, fournisseur et modèle, en devise plutôt qu'en jetons, transforment une facture inexplicable en une liste de décisions. Les budgets des disjoncteurs permettent alors d'agir : avertir à quatre-vingts pour cent, bloquer à cent et arrêter le dépassement au lieu de le signaler ensuite. Les alertes vous préviennent ; seul un disjoncteur arrête réellement la dépense.

Une fois que les coûts sont visibles, ils peuvent être réduits systématiquement plutôt que de manière anecdotique. L'optimisation fonctionne sur quatre leviers : essayer un modèle plus petit, réduire les invites et le contexte, supprimer les outils qui augmentent les coûts sans améliorer les résultats et déplacer les étapes déterministes hors du modèle vers le code ordinaire. Chaque recommandation est mesurée par rapport à vos propres évaluations avant d'être appliquée, de sorte que les économies ne s'achètent jamais tranquillement avec la qualité.

Les intégrations sont régies de la même manière centrale. Une liaison par système en amont, un catalogue approuvé que les équipes peuvent demander, et une piste d'audit unique pour l'ensemble de celui-ci, plutôt que chaque équipe ait sa propre connexion et sa propre copie des informations d'identification.

La coordination devient une véritable préoccupation à grande échelle. Les agents travaillent à la main, se dupliquent lorsque deux équipes résolvent le même problème indépendamment et se disputent les mêmes limites de taux. Un catalogue partagé avec des agents et des compétences réutilisables est la solution la moins chère en cas de duplication, et c'est également ce qui permet à un ingénieur d'expédier son premier agent en quelques heures plutôt qu'en quelques semaines.

Enfin, considérez la flotte comme ayant un cycle de vie. Les agents sont promus de l'expérimentation à la production, obsolètes lorsqu'un meilleur existe et mis à la retraite lorsque leur tâche disparaît. Mesurer l'adoption par équipe, le coût par agent et les performances par rapport aux évaluations est ce qui fait passer la conversation au-delà des expériences de comptage et vers l'exploitation de l'IA plutôt que de simplement l'utiliser.