Il existe deux voies complètement différentes pour que les agents d'IA deviennent plus performants. L'une d'elles est la compétence, qui consiste à s'équiper de compétences et à intégrer directement de nouvelles capacités dans son cerveau. L'autre approche est celle du sous-agent, qui consiste à envoyer un subordonné effectuer le travail tandis que vous ne consultez que les rapports. Ces deux approches peuvent sembler rendre l'agent plus performant, mais elles s'appliquent à des scénarios différents. Si vous utilisez la mauvaise, votre agent risque de devenir plus lent et plus chaotique au fil de son utilisation. Les compétences sont comme des plugins pour l'agent principal. Par exemple, si votre agent ne pouvait jusqu'à présent que discuter et que vous souhaitez qu'il puisse créer des présentations PowerPoint, Skills intègre cette fonctionnalité en incluant dans le contexte de l'agent principal la description de la création de présentations, le mode d'emploi de l'outil et des notes importantes. L'agent principal acquiert ainsi cette compétence grâce à ce contexte et peut ensuite créer des présentations PowerPoint de manière autonome. Le deuxième type est appelé SubAgent, ce qui s'apparente à l'externalisation. De même, lors de la création d'une présentation PowerPoint, l'approche par sous-agent fonctionne comme suit : l'agent principal assigne la tâche à un sous-agent dédié à la création de la présentation, qui réalise ensuite la tâche de manière autonome et soumet le résultat. L'agent principal ne participe pas à l'exécution proprement dite ; il est uniquement responsable de l'assignation de la tâche et des tests d'acceptation. L'une relève des compétences internes, l'autre des compétences externalisées. Toutes deux semblent capables de gérer la tâche, alors quelle est la différence ? La différence réside dans la gestion du contexte, où le contexte est la mémoire de l'IA. On peut comparer le contexte de l'IA à un établi. La taille de cet établi est fixe ; plus on y place d'objets, plus il devient difficile de trouver le document recherché. C'est le problème de la capacité contextuelle. En mode Compétences, toutes les descriptions de capacités sont présentées dans un même tableau. L'avantage réside dans le partage d'informations : l'agent principal peut visualiser tous les résultats intermédiaires et le raisonnement est cohérent. L'inconvénient est que le tableau se surcharge rapidement, les instructions s'allongent, des conflits peuvent survenir entre les capacités et l'IA commence à se perdre. En mode Sous-agent, ce dernier travaille sur une table distincte. Une fois son travail terminé, il transmet les résultats, laissant sur place tous les brouillons et fichiers intermédiaires générés pendant le processus. Le bureau de l'agent principal reste ainsi vierge. En contrepartie, le transfert d'informations doit être soigneusement conçu ; à défaut, des données critiques risquent d'être perdues lors de la transmission. C’est le problème de la pollution contextuelle. Cette pollution n’est pas une métaphore exagérée, mais un véritable goulot d’étranglement en ingénierie. Quand faut-il utiliser quelle méthode ? Les critères d'évaluation sont en réalité assez simples : la complexité de la sous-tâche et la nécessité des informations générées lors de son exécution. Ces compétences conviennent aux scénarios où la tâche elle-même n'est pas trop complexe, ou lorsque vous avez besoin que l'agent principal ait un contrôle total. Par exemple, l'Agent peut servir de point d'entrée, chargeant différents « modes de scénario » selon les demandes de l'utilisateur, comme le mode résumé YouTube ou le mode rédaction de rapport. C'est là que le chargement différé des compétences prend tout son sens : seuls le nom et la description de la compétence sont chargés initialement, la description complète n'étant affichée que lorsque la compétence est réellement nécessaire. Contrairement à MCP, qui intègre toute la documentation détaillée de chaque outil dans le contexte. SubAgent convient aux scénarios où les sous-tâches sont lourdes, chronophages et où les processus intermédiaires sont verbeux. L'exemple le plus typique est celui des outils de débogage de navigateur. La fonctionnalité MCP de Chrome DevTools est puissante, mais sa documentation est trop volumineuse, et son intégration à l'agent principal consommerait énormément de ressources. En l'encapsulant dans un sous-agent, il suffit de lui indiquer de « vérifier les journaux, prendre des captures d'écran et les analyser », et il exécutera le processus et renverra les résultats de l'analyse. Toutes les captures d'écran, les détails de l'arborescence DOM et les détails des requêtes réseau restent dans le sous-agent, sans encombrer le contexte de l'agent principal. Jeu avancé Il est intéressant de noter que les modes Compétences et Sous-agent peuvent être combinés. J'ai appris cette technique grâce à @yan5xu (https://t.co/uSkwSUvNiJ). La première approche est appelée « expansion d'abord, puis compression ». Imaginez par exemple une séance de brainstorming de deux heures, où le tableau blanc est couvert de brouillons, d'arguments et de solutions rejetées. Au final, seules trois conclusions sont consignées dans le compte rendu. Ces étapes intermédiaires sont certes importantes pour parvenir aux conclusions, mais elles ne représentent qu'un bruit de fond pour ceux qui les mettront en œuvre ultérieurement. L'agent peut également fonctionner de cette manière. L'agent principal détecte le besoin d'une compétence spécifique, la charge, effectue une série d'opérations et obtient le résultat. Ensuite, l'ensemble du processus, du chargement de la compétence à l'obtention du résultat, est condensé, ne conservant que la conclusion finale. Pour les analyses ultérieures, c'est comme tenir une réunion et n'en conserver que le compte rendu. La seconde approche consiste à utiliser un système de fichiers comme « station de transfert ». Imaginez que vous gérez une équipe d'externalisation. Vous n'enverriez pas tous les détails des exigences dans un seul message WeChat ; vous diriez plutôt : « Le document des exigences se trouve à ce lien, allez y jeter un œil. » De même, l'équipe d'externalisation ne se contenterait pas de copier-coller le code source dans votre livraison ; elle dirait plutôt : « Le code se trouve dans ce dépôt, et la documentation de déploiement est ici. » Les agents peuvent également collaborer de cette manière. Lorsqu'un agent principal délègue une tâche, il n'inclut pas d'informations contextuelles détaillées dans la commande ; il la stocke plutôt dans un document et n'envoie qu'une seule adresse. Le sous-agent répond de la même façon : en fournissant un bref résumé de l'état d'avancement (« Terminé/Bloqué/Nécessite votre décision ») ainsi qu'une adresse de document détaillée. L'agent principal décide alors, en fonction de la situation, de consulter ou non les détails. Cela permet de maintenir un contexte concis pour les deux parties. Le troisième type concerne les techniques pratiques du Code Claude. Lorsque le contexte est presque épuisé, demandez à Claude de résumer le travail accompli dans un document. Utilisez ensuite la fonction de retour en arrière pour revenir à l'état antérieur à la tâche, en indiquant : « J'ai terminé cette tâche et je l'ai consignée dans ce fichier. » À quoi cela équivaut-il ? C’est comme courir un marathon et se rendre compte de son épuisement près de l’arrivée. On repère alors le parcours déjà effectué, on l’enregistre, puis on se « téléporte » au point de départ, plein d’énergie, en se disant : « Je sais comment y aller, la carte est là. » Le contexte est effacé, mais les résultats sont conservés. Cette méthode permet de rattraper le coup avant que le contexte ne disparaisse. enfin La concurrence entre les agents évolue : elle ne porte plus sur le nombre d’outils pouvant être utilisés, mais sur la manière de gérer ces outils avec élégance. Nombreux sont ceux qui recherchent les frameworks d'agents les plus récents et les extensions de fonctionnalités les plus sophistiquées, mais ils négligent un point fondamental : la mémoire de travail de l'IA est limitée, et son organisation détermine sa complexité. Les compétences et les sous-agents ne sont pas des choix incompatibles, mais plutôt deux outils qui ne révèlent tout leur potentiel que dans le contexte approprié. En définitive, la conception d'architectures d'agents et la conception d'architectures logicielles présentent de nombreuses similitudes. La logique doit-elle être écrite dans une fonction unique et gigantesque, ou décomposée en microservices modulaires ? Est-il plus facile de partager les variables globales ou de maintenir la propreté grâce à une isolation stricte ? Ces vieux problèmes sont réapparus sous une nouvelle forme.
