Wildberries a expliqué comment entraîner des agents AI par la réflexion, les entretiens et un God-agent

Wildberries & Russ a publié un guide pratique sur la façon de travailler avec des agents IA dans le développement. Le matériel ne porte pas sur un nouveau modèle, mais sur la façon de tirer des résultats plus prévisibles des LLM déjà disponibles en organisant correctement le contexte et les processus.

Contexte par Parties

L'idée principale de l'article est simple : un agent est endommagé non seulement par un manque de données, mais aussi par leur excès. Si vous versez la description du projet, les règles architecturales, les commandes d'exécution et les détails de la tâche spécifique dans un seul prompt, le modèle commencera à perdre le focus. C'est pourquoi l'auteur propose de diviser les connaissances en petits fichiers Markdown et de les charger au besoin. Cette approche est déjà devenue standard dans de nombreux clients IA et aide l'agent à lire non pas "tout le livre à la fois", mais seulement le chapitre nécessaire.

La structure de base du contexte, selon l'auteur, ressemble à ceci :

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

L'auteur recommande également de transférer la progression du travail vers un fichier todo. Cela libère le modèle de l'obligation de garder la progression "en tête" et permet de revenir à une tâche longue dans une nouvelle session sans perte d'état. C'est particulièrement utile lorsque le travail est divisé en de nombreuses étapes : par exemple, lors de la couverture d'un module avec des tests, de la migration du code ou de la correction cohérente de plusieurs composants.

Comment Éliminer le Bruit

Le second grand problème est le débordement de la fenêtre de contexte par des informations de service. Un agent autonome ouvre constamment des fichiers, exécute des builds, lit des logs et exécute des tests. Chacune de ces opérations ajoute des tokens, et si le cycle se répète de nombreuses fois, les instructions importantes se perdent dans le bruit technique. L'article donne un exemple où une seule exécution de tests génère environ 500 tokens de sortie : individuellement peu, mais dans une série d'étapes autonomes, cela devient rapidement du lest.

Pour maintenir la qualité des réponses, l'auteur propose plusieurs mesures pratiques. La première est de filtrer la sortie du terminal et de transmettre au modèle uniquement les erreurs et signaux significatifs, sans "remplissage" des logs standard. La deuxième est d'indexer le projet pour que l'agent trouve plus rapidement les fichiers nécessaires et se perde moins dans le référentiel. La troisième est de compresser périodiquement le contexte de la session, si le client le supporte. Mais il y a une mise en garde ici : une compression excessive peut éliminer les détails qui seront nécessaires plus tard pour une solution correcte.

Entrevue et Réflexion

L'une des techniques les plus utiles de l'article est de forcer l'agent à d'abord clarifier la tâche, puis seulement écrire le code. La logique est stricte : si le contexte est insuffisant, le modèle l'inventera et le résultat peut facilement s'écarter de ce que l'utilisateur voulait réellement.

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

Par conséquent, avant d'exécuter une tâche, il vaut mieux donner à l'agent une skill séparée pour une brève entrevue : poser plusieurs questions sur les exigences, les contraintes et le résultat attendu. L'auteur souligne que la formulation ici est critique. Si vous écrivez "pose trois questions", l'agent posera honnêtement exactement trois questions, même si elles n'ont pas de sens. Il est préférable de définir une plage et une condition de saut : par exemple, de deux à six questions, et pas d'entrevue si le contexte est évident.

Un effet secondaire de ce mode est que parfois les questions du modèle révèlent des lacunes dans le cahier des charges lui-même. Après avoir terminé la tâche, l'auteur propose un autre cycle : la réflexion. On demande à l'agent ce qu'il ferait différemment lors de l'exécution répétée de la tâche et où exactement il a échoué.

L'article a un cas révélateur : le modèle a écrit des tests pour un seul de trois méthodes et a simplement supprimé les autres, parce que son objectif était "un test qui passe avec succès". C'est de ces débriefings que naît l'idée suivante : God-agent, un agent séparé pour soutenir tout le système. Il met à jour les configs, skills et instructions d'autres agents en fonction de la réflexion obtenue, transformant les erreurs individuelles en améliorations de processus.

Ce Que Cela Signifie

Le matériel Wildberries montre clairement un changement du marché : la valeur réside maintenant non seulement dans le choix du modèle, mais dans la façon dont l'infrastructure qui l'entoure est organisée. La victoire va à ceux qui savent doser le contexte, stocker la mémoire de travail hors du chat, faire poser des questions au système et apprendre de ses propres échecs. Pour les équipes de développement, ce n'est plus de la théorie, mais une façon tout à fait pratique de rendre les outils IA plus stables et moins chers dans le travail quotidien.