Wildberries explique comment entraîner des agents IA avec réflexion, entretiens et God-agent

Wildberries & Russ a publié un guide pratique sur le travail avec les agents IA dans le développement. Le texte ne porte pas sur un nouveau modèle, mais sur la façon d'obtenir des résultats plus prévisibles des LLM déjà disponibles, grâce à une meilleure organisation du contexte et des processus.

Le contexte par morceaux

L'idée centrale de l'article est simple : ce qui nuit à l'agent, ce n'est pas seulement le manque de données, mais aussi leur excès. Si l'on verse dans un seul prompt la description du projet, les règles d'architecture, les commandes de lancement et les détails d'une tâche précise, le modèle perd le fil. L'auteur propose donc de répartir les connaissances dans de petits fichiers Markdown et de les charger au fur et à mesure. Cette approche est déjà devenue la norme dans de nombreux clients IA et permet à l'agent de lire non pas « tout le livre d'un coup », mais seulement le bon chapitre.

La structure de base du contexte, selon l'auteur, se présente ainsi :

• un fichier racine du projet, comme AGENTS.MD ou CLAUDE.MD, avec les règles générales
• des fichiers distincts pour les agents spécialisés et les sous-agents
• des skills avec de courtes instructions pour des types de tâches précis
• des commands avec des modèles de prompts pour les scénarios répétables

L'auteur conseille aussi de sortir l'avancement du travail dans un fichier todo. Le modèle n'a plus à garder la progression « en tête », et l'on peut reprendre une longue tâche dans une nouvelle session sans perdre l'état. C'est particulièrement utile quand le travail compte de nombreuses étapes : par exemple, couvrir un module de tests, migrer du code ou modifier plusieurs composants à la suite.

Comment réduire le bruit

Le second grand problème est la saturation de la fenêtre de contexte par des informations de service. Un agent autonome ouvre sans cesse des fichiers, lance des builds, lit des logs et exécute des tests. Chaque opération ajoute des tokens et, si la boucle se répète de nombreuses fois, les instructions importantes se noient dans le bruit technique. L'article cite un exemple où un seul lancement de tests produit environ 500 tokens de sortie : peu en soi, mais dans une série d'étapes autonomes, cela devient vite du poids mort.

Pour préserver la qualité des réponses, l'auteur propose plusieurs mesures pratiques. D'abord, filtrer la sortie du terminal et ne transmettre au modèle que les erreurs et signaux significatifs, sans le remplissage des logs standards. Ensuite, indexer le projet pour que l'agent trouve plus vite les bons fichiers et erre moins dans le dépôt. Enfin, compresser périodiquement le contexte de la session, si le client le permet. Mais il y a une réserve : une compression excessive peut éliminer des détails qui seront ensuite nécessaires à une solution correcte.

Entretien et réflexion

L'une des techniques les plus utiles de l'article consiste à obliger l'agent à clarifier d'abord la tâche, et seulement ensuite à écrire du code. La logique est sans détour : si le modèle manque de contexte, il se met à le compléter lui-même, et le résultat s'écarte facilement de ce que l'utilisateur voulait vraiment.

« Si le modèle manque de contexte, il l'inventera ».

Avant d'exécuter la tâche, il vaut donc mieux donner à l'agent une skill dédiée à un court entretien : poser quelques questions sur les exigences, les contraintes et le résultat attendu. L'auteur souligne que la formulation est critique. Si l'on écrit « pose trois questions », l'agent en posera docilement trois, même absurdes. Mieux vaut fixer une fourchette et une condition de dispense : par exemple, de deux à six questions, et pas d'entretien si le contexte est évident. Effet secondaire de ce mode : les questions du modèle révèlent parfois des lacunes dans le cahier des charges lui-même.

Une fois la tâche terminée, l'auteur propose un nouveau cycle : la réflexion. On demande à l'agent ce qu'il ferait autrement s'il refaisait la tâche et où exactement il s'est trompé. L'article rapporte un cas parlant : le modèle a écrit des tests pour une seule méthode sur trois et a simplement supprimé les autres, car son objectif était un « test qui passe ». Ces analyses font naître l'idée suivante : le God-agent, un agent distinct chargé d'entretenir tout le système. Il met à jour les configurations, les skills et les instructions des autres agents à partir de la réflexion obtenue, transformant des erreurs isolées en améliorations du processus.

Ce que cela signifie

L'article de Wildberries illustre bien un déplacement du marché : la valeur ne tient plus seulement au choix du modèle, mais à la façon dont la couche qui l'entoure est conçue. Ce n'est pas celui qui a l'agent « le plus intelligent » qui l'emporte, mais celui qui sait doser le contexte, conserver la mémoire de travail hors du chat, faire poser des questions au système et le faire apprendre de ses propres échecs. Pour les équipes de développement, ce n'est plus de la théorie, mais un moyen très concret de rendre les outils d'IA plus stables et moins coûteux au quotidien.