Quête du bâtisseur d'agents : 10 missions pour maîtriser la conception d'agents IA

Un agent conversationnel qui trouve un créneau de réunion pour des gens dans des villes différentes, avec trois petits tools. Vous apprenez la boucle de base : le modèle choisit un tool, votre code l'exécute, le résultat revient, jusqu'à la réponse finale.

Schémas de toolsLa boucle d'agentConditions d'arrêt

Ce que vous construisez

1. Écrivez trois fonctions pures : city_to_timezone(city), convert_time(time, from_tz, to_tz), working_hours_overlap(zones).
2. Décrivez chacune comme un tool avec un nom clair, une description et des paramètres typés.
3. Lancez la boucle : envoyez les messages et les tools, exécutez chaque appel de tool, ajoutez le résultat, recommencez.
4. Arrêtez sur une réponse texte finale ou après 6 étapes au maximum, selon ce qui arrive en premier.
5. Affichez chaque appel de tool et son résultat pour pouvoir lire la trajectoire.

👾 Niveau boss: Renvoyez les erreurs de tool sous forme de messages lisibles (ville inconnue, nom ambigu) et vérifiez que le modèle se rattrape en posant une question plutôt qu'en devinant.

Construis en [LANGAGE] un agent en ligne de commande qui trouve une plage horaire de réunion, avec [FOURNISSEUR LLM AVEC APPEL DE TOOLS]. Tools : city_to_timezone(city), convert_time(time, from_tz, to_tz), working_hours_overlap(zones, start_hour, end_hour). Implémente la boucle d'agent à la main : appelle le modèle avec les tools, exécute les tools demandés, ajoute les résultats, recommence jusqu'à une réponse finale ou [MAX ÉTAPES] étapes. Journalise chaque étape. Les erreurs de tool doivent être renvoyées au modèle comme messages clairs, jamais lancées en exception.

Une seule porte d'entrée, quatre spécialistes : un assistant regex, un générateur d'expressions cron, un explicateur SQL et un assistant de commandes git. Un classificateur peu coûteux envoie chaque demande au bon prompt spécialisé. Vous apprenez que router vaut mieux qu'un prompt géant.

ClassificationSortie structuréeRoutes de repli

Ce que vous construisez

1. Écrivez un petit prompt routeur qui renvoie du JSON : route, confiance, raison courte.
2. Écrivez quatre prompts spécialisés ciblés, chacun avec ses exemples et son format de sortie.
3. Envoyez vers le spécialiste choisi; si la confiance est faible, posez une question de clarification.
4. Ajoutez une route « non supporté » qui décline poliment tout ce qui est hors sujet.
5. Créez un fichier de test de 30 demandes étiquetées et mesurez la précision du routage.

👾 Niveau boss: Utilisez un modèle plus petit et moins cher pour le routeur et un plus fort pour les spécialistes, puis comparez coût et précision avec un seul gros prompt.

Construis en [LANGAGE] un standard d'aide aux devs avec [FOURNISSEUR LLM]. Un appel routeur classe chaque demande dans : regex, cron, sql_explain, git, unsupported, et renvoie du JSON {route, confidence, reason}. Chaque route a son propre prompt spécialisé avec [N] exemples. Si la confiance est sous [SEUIL], pose une seule question de clarification. Inclus un jeu de test étiqueté de [N] demandes et un script qui affiche la précision du routage et une matrice de confusion.

Donnez-lui un CSV en désordre et un objectif comme « une ligne par client, dates ISO ». Un planificateur rédige une liste d'étapes; un exécutant applique chaque étape avec un petit ensemble d'opérations sûres. Vous apprenez à séparer la réflexion de l'action, et quand replanifier.

Plan sous forme de donnéesOpérations contraintesReplanification

Ce que vous construisez

1. Définissez une liste blanche d'opérations : rename_column, drop_column, parse_dates, trim, dedupe, split_column.
2. Faites produire au planificateur un plan JSON : étapes ordonnées, chacune avec une opération et ses arguments.
3. Validez le plan contre la liste blanche avant d'exécuter quoi que ce soit.
4. Exécutez étape par étape sur une copie des données, en notant le nombre de lignes avant/après chaque étape.
5. Si une étape échoue, renvoyez l'erreur et le schéma actuel au planificateur pour un plan révisé (2 replanifications au max).

👾 Niveau boss: Montrez le plan à l'utilisateur sous forme de liste lisible et laissez-le retirer ou réordonner des étapes avant l'exécution.

Construis en [LANGAGE] un outil de nettoyage CSV planificateur-exécutant avec [FOURNISSEUR LLM]. Entrée : un fichier CSV et un objectif en langage courant. Le planificateur voit les noms de colonnes et [N] lignes d'exemple et renvoie un plan JSON qui utilise seulement ces opérations : [LISTE D'OPÉRATIONS]. Valide le plan, puis exécute-le sur une copie des données en journalisant le nombre de lignes à chaque étape. En cas d'échec, replanifie avec le message d'erreur, au plus [N] fois. Écris le fichier nettoyé et un rapport markdown des changements.

Un rédacteur écrit un README pour un petit dossier de projet, un critique le note selon une grille, et le rédacteur révise jusqu'à la note de passage ou la fin des tours. Vous apprenez à faire vérifier son travail par un modèle sans boucler à l'infini.

Grilles d'évaluationPrompts de critiqueBudgets de boucle

Ce que vous construisez

1. Écrivez une grille de 5 critères : installation, exemple d'utilisation, configuration, limites, exactitude par rapport au code.
2. Appel rédacteur : lire l'arborescence et les fichiers clés, rédiger le README.
3. Appel critique : noter chaque critère de 0 à 2 avec une justification d'une ligne, en JSON.
4. Boucle : réviser seulement les critères en échec, arrêter à la note de passage ou après 3 tours.
5. Sauvegardez chaque version et chaque note pour voir si les révisions améliorent vraiment les choses.

👾 Niveau boss: Ajoutez une vérification déterministe (les commandes du README existent-elles dans les scripts du projet?) et donnez son résultat au critique.

Construis en [LANGAGE] un rédacteur de README avec boucle de réflexion, avec [FOURNISSEUR LLM]. Entrée : le chemin d'un dossier de projet. Étape 1 : un rédacteur écrit README.md à partir de l'arborescence et de [FICHIERS CLÉS]. Étape 2 : un critique note le brouillon selon cette grille [CRITÈRES], en renvoyant du JSON avec une note et une raison par critère. Étape 3 : le rédacteur révise seulement les critères en échec. Arrête quand le total atteint [NOTE DE PASSAGE] ou après [MAX TOURS] tours. Sauvegarde chaque brouillon et chaque note dans un dossier de sortie.

Un agent qui répond à « pourquoi on a fait ça comme ça? » à partir des registres de décisions d'architecture de votre équipe, en citant le paragraphe exact. Une deuxième passe vérifie que chaque citation appuie vraiment l'affirmation. Vous apprenez que la recherche n'est que la moitié du travail; l'ancrage est l'autre moitié.

DécoupageRecherche comme toolVérification des citationsDire « introuvable »

Ce que vous construisez

1. Découpez chaque registre de décision en paragraphes avec des ID stables (fichier + titre + index).
2. Exposez search(query, k) comme tool pour que l'agent puisse chercher plusieurs fois avec des formulations différentes.
3. Exigez des réponses où chaque phrase se termine par un ID de citation.
4. Lancez une passe de vérification : pour chaque affirmation et son paragraphe cité, répondre appuyée / non appuyée.
5. Retirez ou signalez les affirmations non appuyées, et répondez « absent des registres » quand rien de pertinent n'est trouvé.

👾 Niveau boss: Détectez les conflits : quand deux registres se contredisent (une ancienne décision a été remplacée), l'agent doit le dire et privilégier la plus récente.

Construis en [LANGAGE] un agent augmenté par la recherche sur un dossier de registres de décisions d'architecture au format [FORMAT]. Découpe par paragraphe avec des ID stables. Donne à l'agent un tool search(query, k) basé sur [MÉTHODE DE RECHERCHE]. Chaque phrase de la réponse doit citer un ID de fragment. Ajoute un appel vérificateur qui contrôle chaque affirmation contre son fragment cité et retire les affirmations non appuyées. Si rien de pertinent n'est trouvé, réponds que les registres ne couvrent pas la question. Inclus [N] questions de test, dont certaines sans réponse dans les registres.

Un tuteur qui vous questionne sur un sujet de votre choix et se souvient, d'une session à l'autre, des concepts que vous ratez encore. Vous apprenez à décider quoi stocker, comment le récupérer et quand laisser les souvenirs s'estomper.

Schéma de mémoireRègles d'écriture et de lectureOubli progressif

Ce que vous construisez

1. Définissez un enregistrement de mémoire par concept : nom, dernière révision, bonnes réponses, mauvaises réponses, courte note.
2. Après chaque réponse, laissez l'agent appeler update_memory avec un changement structuré, pas du texte libre.
3. Au début de la session, chargez seulement les concepts les plus faibles et les plus en retard dans le contexte.
4. Donnez des intervalles de révision plus courts aux concepts faibles et laissez les concepts maîtrisés sortir de la rotation.
5. Ajoutez une commande « montre ce que tu sais de moi » et une commande « oublie ».

👾 Niveau boss: Séparez deux types de mémoire : les faits sur l'apprenant (préférences, objectifs) et la performance par concept, chacun avec ses propres règles d'écriture.

Construis en [LANGAGE] un agent tuteur de révision espacée avec [FOURNISSEUR LLM] et [STOCKAGE] pour la mémoire. Sujet : [SUJET]. Enregistrement de mémoire par concept : {concept, last_seen, correct, wrong, note}. L'agent questionne l'utilisateur, corrige les réponses et appelle update_memory(concept, change) après chacune. Au début de la session, charge seulement les [N] concepts les plus faibles ou les plus en retard. Ajoute des commandes pour consulter et supprimer les souvenirs. Persiste entre les exécutions.

Pointez-le vers un inventaire fictif de ressources infonuagiques et il propose des actions de nettoyage : arrêter les machines inactives, supprimer les vieux instantanés, réduire les disques surdimensionnés. Les actions sûres s'exécutent, les risquées attendent votre approbation. Vous apprenez les niveaux de risque, les points d'approbation et les pistes d'audit.

Niveaux de risquePoints d'approbationSimulationsJournal d'audit

Ce que vous construisez

1. Créez un inventaire JSON de fausses ressources avec propriétaire, dernière utilisation, taille et étiquettes.
2. Classez chaque tool par risque : lecture (auto), changement réversible (auto avec journal), destructif (approbation requise).
3. Pour les actions destructives, mettez en pause et affichez un diff de simulation avec la raison de l'agent; l'humain approuve, modifie ou refuse.
4. Renvoyez les refus à l'agent pour qu'il ajuste le reste de son plan.
5. Ajoutez chaque proposition, décision et résultat à un fichier de journal d'audit.

👾 Niveau boss: Appliquez le point d'approbation dans le code, pas dans le prompt : le tool de suppression refuse de s'exécuter sans jeton d'approbation valide, et écrivez un test qui le prouve.

Construis en [LANGAGE] un agent de nettoyage avec humain dans la boucle, avec [FOURNISSEUR LLM]. Entrée : [FICHIER D'INVENTAIRE] décrivant des ressources infonuagiques fictives. Tools : list_resources(), stop_instance(id), delete_snapshot(id), resize_disk(id, size). Étiquette les tools par niveau de risque. Les tools destructifs doivent faire une pause, afficher un diff de simulation et la raison de l'agent, puis attendre approuver / modifier / refuser. La vérification d'approbation vit dans le code du tool, pas dans le prompt. Écris chaque étape dans un journal d'audit en ajout seulement.

Décrivez une fonctionnalité livrée et un orchestrateur passe le relais à des spécialistes : rédacteur de notes de version, responsable de la doc, rédacteur d'annonce, créateur de liste de vérification QA. Vous apprenez les contrats de handoff, l'état partagé et comment éviter que les spécialistes se marchent sur les pieds.

Contrats de handoffOrchestrationÉtat partagéÉtape de fusion

Ce que vous construisez

1. Définissez un contrat de handoff : tâche, entrées, format de sortie attendu, et ce que le spécialiste ne doit pas modifier.
2. Donnez à chaque spécialiste son propre prompt court et seulement les tools dont il a besoin.
3. Laissez l'orchestrateur décider quels spécialistes appeler et dans quel ordre, en lançant les indépendants en parallèle.
4. Rassemblez les sorties dans un objet d'état partagé, puis vérifiez leur cohérence (même version, même nom de fonctionnalité).
5. Journalisez chaque passage de relais avec ses entrées et sorties pour pouvoir rejouer un spécialiste seul.

👾 Niveau boss: Permettez à un spécialiste de renvoyer la balle à l'orchestrateur avec une question quand il manque des entrées, au lieu d'inventer des détails.

Construis en [LANGAGE] un assistant de lancement multi-agents avec [FOURNISSEUR LLM]. Entrée : une description de fonctionnalité et [DIFF OU CHANGELOG]. Un orchestrateur répartit le travail entre des spécialistes : release_notes, docs_update, announcement, qa_checklist. Chaque passage de relais suit ce contrat : {task, inputs, output_format, constraints}. Les spécialistes peuvent renvoyer une question au lieu d'une réponse. Stocke les résultats dans un objet d'état partagé, vérifie la cohérence de toutes les sorties et affiche une trace de chaque passage de relais.

Enveloppez un agent de revue de migrations de base de données derrière un serveur de tools pour que d'autres agents (et votre agent de code) puissent appeler review_migration et obtenir un verdict structuré. Vous apprenez à concevoir l'interface publique d'un agent : entrées, sorties, limites et erreurs.

Conception d'interfaceProtocoles de toolsDélais d'expirationVersionnage

Ce que vous construisez

1. Construisez l'agent interne : il lit une migration SQL et signale les risques de verrouillage, les retours arrière manquants et les pertes de données.
2. Définissez un tool avec un schéma d'entrée strict et un verdict JSON : niveau de risque, constats, correctif suggéré.
3. Servez-le avec un protocole de tools standard (MCP ou votre propre endpoint HTTP) avec délai d'expiration et limite d'étapes.
4. Renvoyez les erreurs sous forme de résultats structurés sur lesquels l'agent appelant peut raisonner.
5. Branchez-le à un autre agent et regardez-le utiliser votre réviseur comme n'importe quel autre tool.

👾 Niveau boss: Versionnez le contrat du tool, ajoutez un deuxième tool (explain_finding) et gardez l'ancienne version fonctionnelle pour les appelants existants.

Construis en [LANGAGE] un agent de revue de migrations SQL et expose-le comme serveur de tools avec [PROTOCOLE DE TOOLS OU FRAMEWORK HTTP]. Tool : review_migration(sql, dialect) qui renvoie du JSON {risk: low|medium|high, findings: [{line, issue, fix}]}. L'agent interne a des tools en lecture seule pour [SOURCE DU SCHÉMA]. Impose un délai de [N] secondes et une limite de [N] étapes, renvoie des erreurs structurées et inclus un petit agent client qui appelle le tool sur [N] migrations d'exemple.

Mission boss : prenez un agent construit pendant cette quête et rendez-le digne de la production. Chaque exécution est tracée, une suite d'evals de trajectoire roule avant chaque changement, et les régressions bloquent le merge. Vous apprenez à prouver qu'un agent fonctionne, pas juste à l'espérer.

TracingEvals de trajectoireBarrières anti-régressionSuivi des coûts

Ce que vous construisez

1. Tracez chaque exécution : chaque appel au modèle, appel de tool, arguments, résultat, latence et nombre de tokens, liés par un ID d'exécution.
2. Construisez une commande de rejeu qui réexécute une trace stockée étape par étape.
3. Écrivez 25 cas d'eval qui vérifient la réponse finale et le chemin : bons tools, aucun appel interdit, moins de N étapes.
4. Exécutez chaque cas plusieurs fois et rapportez des taux de réussite, pas des résultats uniques.
5. Ajoutez une tâche CI qui compare avec la dernière référence et échoue en cas de régression, plus un petit tableau de bord coût et latence par exécution.

👾 Niveau boss: Transformez chaque mauvaise trace de production en nouveau cas d'eval en une seule commande, pour que la suite grandisse à partir des vrais échecs.

Ajoute de l'observabilité de production et des evals à mon agent en [LANGAGE] situé à [CHEMIN DE L'AGENT]. 1) Trace chaque appel au modèle et appel de tool (entrées, sorties, latence, tokens) sous un ID d'exécution, stocké dans [STOCKAGE DES TRACES]. 2) Ajoute une commande de rejeu pour une exécution stockée. 3) Crée une suite de [N] cas d'eval qui vérifient la sortie finale et la trajectoire (tools attendus, tools interdits, étapes max), en exécutant chaque cas [N] fois. 4) Ajoute une étape CI qui compare les taux de réussite à une référence sauvegardée et échoue en cas de régression. 5) Affiche le coût et la latence par exécution.