Un plus grand nombre d’outils disponibles peut réduire la fiabilité de la planification d’un agent lorsque des choix non pertinents ou redondants monopolisent son attention et brouillent la prochaine action valide.
Un agent d’IA domestique peut commencer avec la recherche, les fichiers, les calendriers et la messagerie, puis intégrer progressivement des dizaines d’intégrations spécialisées. Le catalogue plus vaste semble offrir davantage de capacités, mais une tâche simple peut devenir moins prévisible, car la sélection, la construction des arguments et la récupération partagent désormais le même budget de planification. La variable importante n’est pas seulement la capacité totale, mais le nombre d’outils plausibles qui restent visibles à chaque étape.
Le nombre d’outils modifie la surface de décision avant l’exécution
Le nombre d’outils influence la planification avant même l’exécution d’une API. Chaque nom visible, chaque description, chaque schéma et chaque exemple devient une action candidate que le modèle doit comparer à son état actuel. L’ajout d’un outil clairement sans rapport peut avoir peu d’effet, tandis que l’ajout de plusieurs outils sémantiquement proches crée davantage de branches qui semblent localement raisonnables.
Les recherches sur les problèmes liés à l’exposition aux outils distinguent la pertinence sémantique de la nécessité causale. Un outil peut sembler lié à la demande tout en étant prématuré, inexécutable ou incapable de faire progresser l’état actuel vers l’objectif. Le planificateur doit donc écarter les distractions plausibles, et pas seulement trouver un élément pertinent.
La taille brute du catalogue constitue donc un indicateur incomplet. La fiabilité dépend davantage du nombre et de la similarité des outils exposés au point de décision, ainsi que de la possibilité de distinguer leurs prérequis et leurs effets. Un registre volumineux placé derrière un routeur sélectif peut être plus facile à utiliser pour planifier qu’un petit menu plat de fonctions redondantes.
Des schémas qui se chevauchent transforment les erreurs de sélection en erreurs de planification
Choisir le mauvais outil n’est que le premier mode d’échec. Les outils étroitement liés réutilisent souvent des champs tels que la requête, le chemin, le destinataire ou la date, mais leur attribuent des significations différentes. Une fois engagé sur un candidat, le planificateur peut reprendre des modèles d’arguments d’un outil voisin et produire un appel syntaxiquement plausible, mais opérationnellement incorrect.
Une analyse pratique de la sélection d’outils à grande échelle décrit les appels erronés, le mélange de schémas et les tâches bloquées lorsque les catalogues s’agrandissent. Ces erreurs se propagent : une observation mal formée modifie l’état disponible à l’étape de planification suivante, si bien qu’une erreur locale de sélection devient une trajectoire incorrecte plus longue.
Le symptôme visible n’est pas toujours un échec manifeste. L’agent peut lancer une recherche générale au lieu d’une consultation précise, répéter une opération via deux connecteurs similaires ou inventer un paramètre manquant. La fiabilité de la planification doit donc inclure l’exactitude de l’outil, la validité des arguments, le taux d’étapes inutiles et la capacité à atteindre l’état final sans détours cachés.
La fiabilité de la planification dépend de l’organisation, pas d’une limite magique
Il n’existe pas de nombre universel d’outils à partir duquel un agent devient peu fiable. Les capacités du modèle, le format de l’invite, la qualité des descriptions, l’ambiguïté de la tâche et la similarité entre les outils déplacent tous cette limite. Dix actions de base de données presque identiques peuvent être plus difficiles à utiliser que cinquante outils répartis dans des domaines clairement définis et propres à chaque tâche.
Une étude sur la récupération hiérarchique des outils décrit des niveaux correspondant aux domaines, aux catégories et aux API, qui permettent d’effectuer la sélection dans un espace de recherche plus restreint. La hiérarchie remplace la comparaison de chaque outil avec tous les autres par une suite de décisions plus ciblées, même si une mauvaise branche initiale peut toujours masquer la bonne option.
La relation est donc conditionnelle : un catalogue plus vaste tend à accroître la confusion lorsque l’exposition reste inchangée, mais une bonne organisation peut absorber une grande partie de cette pression. La fiabilité s’améliore lorsque le routage élimine les domaines non pertinents, que les schémas utilisent des noms et des effets distincts et que le planificateur peut récupérer après le rejet d’une branche sans recommencer toute la tâche.
L’exposition dynamique préserve les capacités avec moins de choix locaux
L’exposition dynamique distingue ce qu’un agent pourra éventuellement utiliser de ce qu’il devrait prendre en compte maintenant. Un registre peut conserver chaque intégration tandis qu’un routeur n’expose que les outils dont les prérequis sont satisfaits et dont les effets font progresser le sous-objectif actuel. Le menu évolue à mesure que les observations complètent l’état manquant.
Il s’agit d’une extension utile des frontières d’exécution des outils : les capacités, les autorisations et la visibilité pour la planification ne doivent pas nécessairement être identiques. Un agent domestique peut découvrir un événement du calendrier avant de voir les outils d’invitation, ou préparer une modification de fichier avant d’obtenir l’accès à l’action qui la valide.
La mise en œuvre par étapes réduit le nombre de branches locales sans faire comme si les outils omis n’existaient pas. Elle améliore également l’auditabilité, car chaque décision d’exposition peut être reliée à l’état, au risque et à la progression vers l’objectif. La limite réside dans la qualité du routeur : un filtre trop agressif qui masque un outil nécessaire protège l’attention, mais empêche l’achèvement. Il faut donc mesurer le rappel de la frontière valide des prochaines actions.
Évaluez le catalogue au moyen de tests de planification contrôlés
Un test pertinent conserve le modèle, l’ensemble de tâches, les implémentations des outils et les critères de réussite constants, tout en ne modifiant que le catalogue visible ou la politique de routage. Utilisez des tâches nécessitant un seul outil, plusieurs outils dépendants et une récupération délibérée après un appel échoué. Des exécutions répétées sont nécessaires, car une seule trace réussie peut masquer une sélection instable.
Une analyse orientée production du routage des outils à grande échelle souligne que les menus plus vastes peuvent augmenter le coût en jetons et le risque d’appels erronés. Suivez le taux d’achèvement, l’exactitude du premier choix, la validité des arguments, les appels redondants, les nouvelles tentatives, la latence et le point où le plan s’écarte du chemin d’état prévu.
L’objectif pratique n’est pas de disposer du plus petit catalogue possible. Il s’agit de maximiser la surface de capacités utiles tout en conservant des trajectoires stables dans le cadre de tâches représentatives. Si la fiabilité diminue, commencez par réduire l’exposition simultanée et le chevauchement des schémas ; si le taux d’achèvement baisse, augmentez le rappel de la récupération ou ajoutez une voie de secours au lieu de supprimer définitivement les outils utiles.
Centre Tech & IA
Plus à lire

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

