Skills d’agent IA : pourquoi trop en ajouter peut le brider

Installer « toutes les skills du hub » paraît rassurant. En 2025–2026, les plateformes d’agents multiplient les catalogues, les standards ouverts et les connecteurs MCP. Pourtant une règle revient chez ceux qui mesurent vraiment les agents :

plus d’outils ≠ plus de compétence utile, surtout si tout est chargé en même temps.

Cet article fait le point : plus et moins des skills, comment le cumul bride l’agent, et quelles pratiques tenir pour une PME. Sources d’ingénierie et d’écosystème récentes ; pas de ranking magique.

Skills, outils, MCP : ne pas tout confondre

Concept	En clair	Exemple
Modèle	Le « cerveau » (LLM)	Claude, GPT, Grok…
Outil / tool	Action appelable (API, fonction)	web_search, envoi mail, SQL
Skill	Document / procédure de métier chargé à la demande	« comment publier un article Kervia »
MCP	Protocole pour brancher des serveurs d’outils	Connecteur GitHub, navigateur…
Contexte	Ce que le modèle « voit » dans la fenêtre de tokens	System + skills + historique + réponses d’outils

Une skill bien faite réduit les erreurs de parcours.
Une skill mal bornée ou toujours chargée devient du bruit coûteux.

Hermes le dit explicitement dans sa doc skills : les skills sont des documents de connaissance à la demande, avec divulgation progressive pour minimiser les tokens, compatibles avec le standard ouvert agentskills.io (Skills System : Hermes).

Ce que dit la recherche / l’ingénierie récente

Anthropic (11 sept. 2025) : trop d’outils distrait l’agent

Dans Writing effective tools for AI agents—using AI agents (Engineering at Anthropic, 11 septembre 2025), l’équipe pose un principe direct :

• « Too many tools or overlapping tools can also distract agents from pursuing efficient strategies. »
  (Trop d’outils, ou des outils qui se chevauchent, peuvent aussi distraire les agents et les détourner de stratégies efficaces.)

Autres points opérationnels du même billet (utiles pour les skills, qui ressemblent à des outils textuels lourds) :

Pratique recommandée	Pourquoi
Évaluer les outils avec des agents (métriques : appels, erreurs, tokens, durée)	Sinon on « sent » que ça marche sans le prouver
Réponses d’outils concises vs détaillées	Exemple Slack : réponse détaillée ~206 tokens vs concise ~72 tokens (~⅓)
Plafond de réponse d’outil (Claude Code)	25 000 tokens par défaut pour une réponse d’outil
Descriptions d’outils soignées (prompt engineering du schéma)	De petits raffinements peuvent fortement baisser le taux d’erreur (cas SWE-bench Verified cité)
Éviter de renvoyer des listes énormes à lire token par token	Gaspillage de contexte (métaphore carnet d’adresses lu page par page)
Consolider les outils selon les vraies subdivisions de tâches	Moins de descriptions en contexte + calcul déporté dans l’outil
MCP peut exposer potentiellement des centaines d’outils	La puissance existe, la curation devient le sujet

Ce n’est pas un paper académique isolé : c’est de l’ingénierie de prod d’un labo frontier, en 2025, toujours la référence pratique en 2026 pour concevoir tool/skill stacks.

Évaluations function-calling : la complexité « multi-outils » est un cas à part

Le Berkeley Function-Calling Leaderboard (BFCL) (Gorilla / Berkeley) structure explicitement des catégories simple, parallel, multiple (plusieurs définitions d’outils, une seule à choisir), exécutable, etc. Le simple fait que « choisir parmi 2 à 4 outils » soit une catégorie d’évaluation séparée montre que la sélection n’est pas gratuite dès que le menu s’allonge.

Plus le menu grossit sans structure (routage, tool search, skills à la demande), plus le risque de mauvais outil ou d’hésitation coûteuse augmente, même sans chiffre unique universel « à N outils la précision chute de X % ».

Contexte multi-fichiers / multi-agents (2025)

Des travaux 2025 sur l’context engineering pour assistants de code multi-agents soulignent les limites de contexte et la connaissance fragmentée dès que les projets grossissent (ex. discussion arXiv 2508.08322 : Context Engineering for Multi-Agent LLM Code Assistants, août 2025). Ce n’est pas spécifique aux « skills Hermes », mais le mécanisme est le même : trop de texte concurrent → attention diluée.

Ce que l’on n’a pas trouvé (honnêteté)

• Pas de loi publique du type « au-delà de 47 skills, tout agent chute de 12 % ».
• Les chiffres exacts dépendent du modèle, du routeur, et du fait que les skills soient toujours injectées ou chargées à la demande.

La conclusion robuste n’a pas besoin de ce chiffre magique : le contexte est fini ; tout ce qui y entre sans servir la tâche bride.

Tableau : plus et moins des skills

	Plus (quand c’est bien fait)	Moins / risque (surtout en cumul aveugle)
Qualité de parcours	Procédures stables, moins d’improvisation	Consignes contradictoires entre skills
Spécialisation	SEO, déploiement, sécu… activables	L’agent « voit » 30 métiers à la fois
Tokens	Chargement à la demande = économie	Catalogue entier dans le system prompt = gouffre
Choix d’outil	Menu court + descriptions claires	Chevauchements → distraction (Anthropic)
Maintenance	Une skill = un contrat évolutif	80 skills à jour = dette d’équipe
Sécurité	Skills bornées, moindre privilège	Skill large = surface d’action élargie
Onboarding	Nouveau projet = pack minimal	« Installe tout le hub » = agent confus
Mesure	Eval par skill / outil	Impossible de savoir quelle skill casse quoi

Comment le cumul bride concrètement l’agent

1. Taxe de contexte (tokens)

Avant même d’agir, l’agent « lit » descriptions, règles, exemples.
Si dix skills lourdes sont toujours actives, une part du budget part en mode d’emploi au lieu d’historique utile et de réponses d’outils.

Hermes pousse l’inverse : progressive disclosure (doc Skills).

2. Collision de politiques

Skill A : « toujours déployer après build ».
Skill B : « jamais déployer sans go humain ».
Résultat : hésitation, double check, ou pire : action selon la skill la plus récente dans le prompt.

3. Mauvais routage

Deux skills « SEO » quasi jumelles → l’agent en charge une au hasard, ou les deux, ou aucune.
Même logique que les overlapping tools décrits par Anthropic.

4. Réponses d’outils bavardes en cascade

Une skill qui demande « dump complet » + une autre qui relance une recherche = contexte saturé en trois tours.
L’exemple Anthropic (206 vs 72 tokens) montre qu’un simple format concise|detailed change la donne.

5. Fausse impression de couverture

« On a 120 skills » rassure le manager.
L’agent, lui, n’a qu’une fenêtre d’attention. La couverture réelle, c’est ce qu’il peut sélectionner et exécuter sans se tromper.

Règles pratiques (Méthode Kervia appliquée aux skills)

1. Clarifier le job de l’agent (un métier principal par profil).
2. Cadrer un socle minimal (5–15 skills vraiment utilisées).
3. Charger à la demande le reste (progressive disclosure).
4. Fusionner les doublons (une skill SEO, pas quatre quasi-copies).
5. Évaluer : tâches réelles, taux d’outil correct, tokens, erreurs (comme le propose Anthropic pour les tools).
6. Borner les réponses (concis par défaut).
7. Entretenir : skill morte = dette ; la supprimer est un gain.

Pour Hermes en particulier : packs optionnels, opt-out du catalogue bundlé, directories externes : la doc encourage un contrôle de profil, pas l’accumulation infinie (Skills System).

Lien utile : Agents IA open source · Chat vs agent · Hermes / OpenClaw.

Checklist « mon agent est-il bridé par ses skills ? »

• Plus de ~20 skills toujours injectées sans routeur
• Deux skills se contredisent sur deploy / secrets / ton
• L’agent appelle souvent le mauvais outil
• Les tours « explosent » en tokens après 2–3 tools
• Personne ne sait quelle skill est responsable d’un comportement
• « On a tout installé » mais les tâches simples régressent

Si 3 cases sont cochées : élaguer avant d’ajouter une skill de plus.

Limites de cet article

• Pas de benchmark Kervia chiffré « N skills → score ».
• Anthropic traite surtout des tools ; on étend le raisonnement aux skills (même budget de contexte).
• BFCL évalue le function-calling, pas les catalogues de skills textuels.
• Écosystème 2026 encore très mouvant (MCP, standards skills).

Les mots techniques, en clair

Terme	En clair
Skill	Mode d’emploi métier que l’agent peut charger pour bien faire une famille de tâches.
Tool / outil	Action concrète (chercher, écrire un fichier, appeler une API).
Contexte / fenêtre de tokens	Ce que le modèle peut « tenir en tête » d’un coup ; c’est limité.
Progressive disclosure	Ne montrer le détail que quand on en a besoin.
MCP	Prise standard pour brancher des boîtes à outils externes.
Chevauchement	Deux skills/outils qui font presque la même chose avec des règles différentes.
Éval / evaluation	Jeu de tâches pour mesurer si l’agent s’améliore vraiment.
Function calling	Mécanisme où le modèle choisit une fonction JSON à exécuter.

Sources

1. Anthropic Engineering : Writing effective tools for AI agents—using AI agents (11 sept. 2025).
2. Hermes Agent : Skills System · standard agentskills.io.
3. Berkeley / Gorilla : Berkeley Function-Calling Leaderboard.
4. Contexte multi-agents code : arXiv 2508.08322 (août 2025).
5. Kervia : agents OSS · chat vs agent · Hermes.