Comment les agents IA implementent reellement les competences : comparaison complete multiplateforme

Introduction

Chaque framework d’agents IA est confronte a la meme question fondamentale : comment rendre un LLM competent dans un domaine specifique ? Le modele lui-meme possede de vastes connaissances generales, mais lorsque vous avez besoin qu’il effectue une revue de code, deploie une infrastructure ou navigue dans Minecraft, il a besoin d’instructions specialisees, d’un acces aux outils et d’un contexte de domaine.

C’est le probleme de l’injection de competences. Et chaque grand framework le resout differemment.

Certaines plateformes chargent tout dans le prompt systeme des le depart. D’autres utilisent le chargement paresseux, ne revelant les capacites que lorsque l’agent en a besoin. Quelques-unes utilisent des bases de donnees vectorielles pour recuperer les competences pertinentes par similarite semantique. Les differences ne sont pas academiques — elles affectent directement les couts en tokens, la fiabilite des agents et le nombre de competences qu’un agent peut realistement gerer.

Nous avons analyse 11 grandes plateformes d’agents IA pour comprendre exactement ou les competences atterrissent dans le prompt, quand elles se chargent, combien elles coutent en tokens et comment elles survivent lorsque la fenetre de contexte se remplit. Ce n’est pas une comparaison superficielle de fonctionnalites. Nous avons examine le code source, la documentation et les diagrammes d’architecture pour cartographier les mecanismes d’injection precis de chaque plateforme.

Tableau de comparaison principal

Voici l’apercu complet avant de plonger dans les details.

Mecanismes d’injection : ou, quand et comment

Persistance, cout en tokens et comportement permanent

Prêt à développer votre entreprise?

Commencez votre essai gratuit aujourd'hui et voyez les résultats en quelques jours.

Demander une démo Se connecter

Ce que signifie reellement « l’injection de competences »

Avant de plonger dans la comparaison, definissons l’espace du probleme. La fenetre de contexte d’un agent IA — le texte total que le LLM voit a chaque appel — a une taille fixe. Chaque token d’instruction, d’historique de conversation, de definition d’outil et de donnees recuperees est en concurrence pour l’espace dans cette fenetre.

Une « competence » dans le contexte d’un agent est tout ensemble structure d’expertise qui modifie le comportement de l’agent. Cela peut etre :

• Des instructions indiquant a l’agent comment aborder un domaine specifique (directives de revue de code, listes de verification de deploiement)
• Des definitions d’outils donnant a l’agent des fonctions appelables (integrations API, operations sur les fichiers)
• Des exemples few-shot montrant a l’agent a quoi ressemble une bonne sortie
• Des connaissances recuperees a partir de bases de donnees vectorielles ou de documents externes

Le mecanisme d’injection — ou et quand ce contenu entre dans le contexte — determine trois proprietes critiques :

1. Efficacite en tokens : combien de tokens la competence consomme-t-elle, et ce cout est-il paye meme quand la competence n’est pas necessaire ?
2. Fiabilite : l’agent utilisera-t-il systematiquement la competence quand elle est pertinente, ou pourrait-il manquer le signal ?
3. Scalabilite : combien de competences l’agent peut-il utiliser avant que le gonflement du contexte ne degrade les performances ?

Chaque framework fait des compromis differents sur ces trois dimensions. Examinons chacun d’entre eux.

Le spectre de l’injection : du permanent au ponctuel

Sur les 11 plateformes, les approches d’injection de competences s’echelonnent le long d’un spectre allant de « tout charge d’emblee » a « rien charge tant que ce n’est pas explicitement necessaire ».

A une extremite, des plateformes comme CrewAI, SuperAGI et CAMEL-AI injectent le contenu complet de chaque competence activee dans chaque appel LLM. L’agent dispose toujours de son expertise complete. Simple, fiable, mais couteux en tokens.

A l’autre extremite, Claude Code, LangChain Deep Agents et l’API Responses d’OpenAI utilisent la divulgation progressive — l’agent ne voit que les noms et de courtes descriptions des competences au demarrage, et le contenu complet se charge a la demande. Efficace, scalable, mais necessite que l’agent reconnaisse quand il a besoin d’une competence.

Au milieu, AutoGen Teachability et Voyager utilisent la recherche semantique pour n’injecter que les competences les plus pertinentes par tour, creant un modele d’injection dynamique et sensible au contexte.

Et il y a des approches uniques : DSPy compile des exemples few-shot optimises hors ligne et les integre de maniere permanente dans les prompts des modules. MetaGPT encode les competences comme des modeles d’action qui ne s’activent que lorsqu’un role specifique passe a une action specifique.

Examinons chacun en detail.

Rejoignez notre newsletter

Recevez gratuitement les derniers conseils, tendances et offres.

Adresse e-mail

S'abonner

Claude Code : divulgation progressive a trois couches

Claude Code implemente l’une des architectures d’injection de competences les plus sophistiquees, utilisant un systeme de divulgation progressive a trois couches qui equilibre la visibilite avec l’efficacite en tokens.

Couche 1 : toujours dans le contexte

Au demarrage de la session, le nom et la description de chaque competence disponible sont injectes dans un message system-reminder — un bloc de metadonnees que le modele voit toujours. Cela coute environ 250 caracteres par competence, consommant environ 1 % du budget de la fenetre de contexte pour toutes les descriptions de competences combinees (environ 8K caracteres comme budget de secours, configurable via la variable d’environnement SLASH_COMMAND_TOOL_CHAR_BUDGET).

De meme, les outils differes — des outils dont les schemas JSON complets n’ont pas encore ete charges — apparaissent sous forme de liste de noms dans les blocs system-reminder. A partir de Claude Code v2.1.69, meme les outils systeme integres comme Bash, Read, Edit, Write, Glob et Grep sont differes derriere ToolSearch, reduisant le contexte des outils systeme d’environ 14-16K tokens a environ 968 tokens.

L’agent en voit suffisamment pour savoir ce qui est disponible sans payer le cout en tokens des definitions completes.

Couche 2 : a l’activation

Lorsqu’un utilisateur tape une commande slash (par ex., /commit) ou que le modele fait correspondre automatiquement une competence en fonction de sa description, le corps complet du SKILL.md est charge comme message de conversation via l’outil Skill. Ce corps contient les instructions completes — parfois des milliers de tokens de directives detaillees.

Detail important : le preprocessing shell s’execute en premier (toute directive !command dans le fichier de competence s’execute et sa sortie remplace la directive), et une fois charge, le corps de la competence reste dans la conversation pour le reste de la session.

Couche 3 : a la demande

Les ressources supplementaires — documents de reference, scripts, fichiers d’assets — ne sont lues que lorsque le modele decide explicitement d’utiliser l’outil Read pour y acceder. Elles ne se chargent jamais automatiquement.

Comportement de compaction du contexte

Lorsque la conversation approche de la limite de contexte et que la compaction se declenche, Claude Code re-attache les competences les plus recemment invoquees avec un budget de 5K tokens par competence et un maximum combine de 25K. Les competences les plus recemment invoquees sont prioritaires. Les competences plus anciennes peuvent etre completement supprimees.

Cette architecture a trois couches signifie qu’un agent avec plus de 20 competences disponibles paie un cout initial minimal mais peut acceder a l’expertise complete de n’importe laquelle d’entre elles en un seul tour.

CrewAI : injection complete dans chaque prompt de tache

CrewAI adopte l’approche opposee a la divulgation progressive. Lorsqu’une competence est activee pour un agent, son contenu complet est injecte dans chaque prompt de tache que l’agent execute.

Fonctionnement

Les competences dans CrewAI sont des repertoires autonomes, chacun avec un fichier SKILL.md contenant un frontmatter YAML (nom, description, licence, compatibilite, outils autorises) et un corps en markdown. Le systeme de competences distingue les competences des outils : les competences injectent des instructions et du contexte qui faconnent la reflexion de l’agent, tandis que les outils fournissent des fonctions appelables pour les actions.

Lors de l’initialisation de l’agent, Agent.set_skills() appelle discover_skills() pour scanner les repertoires de competences au niveau des metadonnees, puis activate_skill() pour lire les corps complets des competences. Au moment de l’execution de la tache, _finalize_task_prompt() appelle format_skill_context() pour chaque competence activee et ajoute tout le contenu formate des competences au prompt de la tache.

Le LLM recoit : [message systeme] + [prompt de tache + TOUS les corps de competences]

Implications en tokens

CrewAI impose un avertissement souple a 50 000 caracteres par competence mais aucune limite stricte. La documentation recommande de garder les competences focalisees et concises car les injections de prompt volumineuses diluent l’attention du modele — une preoccupation reelle compte tenu des recherches sur la degradation du contexte.

Le compromis est simple : l’agent dispose toujours de l’expertise complete (haute fiabilite), mais le cout en tokens augmente lineairement avec le nombre de competences par tache (faible efficacite). Pour les agents avec 1-2 competences focalisees, cela fonctionne bien. Pour les agents necessitant de larges ensembles de capacites, cela devient rapidement couteux.

Pas de persistance inter-taches

Chaque tache recoit une injection fraiche. Il n’y a pas d’accumulation de contenu de competences entre les taches — ce qui est en fait un avantage, pas un inconvenient. Cela signifie que chaque tache demarre avec un contexte propre, evitant les problemes d’obsolescence que la persistance basee sur la session peut creer.

LangChain Deep Agents : chargement controle par l’agent via SkillsMiddleware

LangChain Deep Agents implemente un systeme de competences sophistique base sur un middleware ou l’agent lui-meme decide quand charger le contenu complet des competences — un veritable modele de divulgation progressive ou l’agent controle l’activation.

Les trois niveaux

Niveau 1 (Index) : SkillsMiddleware analyse tous les frontmatters SKILL.md au demarrage et injecte un index leger dans le prompt systeme. Cet index contient uniquement les noms et descriptions, coutant environ 278 tokens par competence contre 3 302 tokens pour le contenu complet.

Niveau 2 (Contenu complet) : Lorsque l’agent determine qu’une competence est pertinente, il appelle read_file() sur le chemin du SKILL.md de la competence. C’est un appel d’outil classique — le framework n’injecte pas le corps ; l’agent prend la decision deliberee de le charger. Le contenu complet entre dans l’historique de conversation comme resultat d’outil.

Niveau 3 (Approfondissement) : Les materiaux de support, documents de reference et scripts ne sont accedes que lorsque l’agent les lit explicitement.

Efficacite en tokens en pratique

Avec 12 competences, la divulgation progressive reduit le contexte d’environ 30 000 tokens (tout charge) a environ 600 tokens (index seul), s’etendant a 2 000-5 000 lorsque les competences pertinentes sont chargees pour une tache specifique. C’est une reduction potentielle de 83-98 % de la consommation de tokens liee aux competences.

Plusieurs sources de competences peuvent etre superposees, et en cas de collision de noms, la derniere source l’emporte. Les fichiers de plus de 10 Mo sont automatiquement ignores.

La difference cle avec Claude Code

Alors que Claude Code utilise un outil Skill dedie pour declencher le chargement, Deep Agents reutilise l’outil read_file existant de l’agent. Cela signifie que le mecanisme de chargement est transparent — l’agent lit les fichiers de competences de la meme maniere qu’il lit tout autre fichier. L’inconvenient est qu’il n’y a pas de comportement de compaction special : le contenu des competences qui entre dans l’historique de conversation est soumis au trimming standard des messages LangChain, sans traitement prioritaire.

OpenAI Responses API et Agents SDK : chargement differe gere par la plateforme

OpenAI implemente l’injection de competences via deux mecanismes distincts mais philosophiquement alignes : le type d’outil tool_search de l’API Responses et le ToolSearchTool du SDK Agents.

API Responses : tool_search

Le type d’outil tool_search (disponible sur GPT-5.4+) permet aux developpeurs de differer de larges surfaces d’outils jusqu’a l’execution. Trois strategies de report sont disponibles :

• Report de fonction individuelle : @function_tool(defer_loading=True) — le modele voit le nom et la description de la fonction mais le schema des parametres est differe. Economise des tokens au niveau des parametres.
• Report par espace de noms : tool_namespace(name=..., description=..., tools=[...]) — regroupe les fonctions sous un seul espace de noms. Le modele ne voit que le nom et la description de l’espace de noms, economisant significativement plus de tokens.
• Report de serveur MCP : HostedMCPTool(tool_config={..., "defer_loading": True}) — differe l’ensemble des surfaces d’outils du serveur MCP.

Lorsque le modele determine qu’il a besoin d’un outil specifique, il emet un appel tool_search. L’API renvoie 3-5 definitions d’outils pertinentes, injectees a la fin de la fenetre de contexte pour preserver la mise en cache du prompt.

SDK Agents : ToolSearchTool

Le SDK Agents fournit un equivalent programmatique. Les espaces de noms d’outils sont enregistres mais pas charges :

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

A l’execution, l’agent ne voit que les noms des espaces de noms. Il appelle ToolSearchTool("crm") pour decouvrir et charger les schemas complets, puis peut appeler les outils individuels au sein de cet espace de noms.

Pas de persistance inter-requetes

Chaque requete API est independante. Les outils decouverts ne persistent pas entre les appels. C’est l’approche la plus sans etat de notre comparaison — propre, previsible, mais necessitant une re-decouverte a chaque requete si les outils changent.

AutoGen Teachability : recherche semantique par tour

La capacite Teachability d’AutoGen adopte une approche fondamentalement differente de tous les autres frameworks de cette comparaison. Au lieu d’injecter du contenu de competences statique, elle recupere dynamiquement des « memos » pertinents a partir d’une base de donnees vectorielle ChromaDB a chaque tour.

La boucle de recuperation par tour

Teachability enregistre un hook sur process_last_received_message qui intercepte chaque message utilisateur entrant avant que l’agent ne le traite :

1. Un TextAnalyzerAgent extrait les concepts cles du message entrant
2. Ces concepts sont utilises pour interroger ChromaDB (utilisant par defaut les embeddings Sentence Transformer)
3. Les K memos les plus pertinents sont recuperes (configurable via max_num_retrievals, par defaut 10)
4. Les memos recuperes sont ajoutes au texte du message avant que l’agent ne le voie

Point crucial : le message modifie ne se propage pas dans l’historique de conversation stocke — seul le message original est stocke. Cela empeche le contenu des memos de s’accumuler entre les tours.

Boucle d’apprentissage

Apres que le LLM repond, un second hook analyse la reponse pour de nouveaux apprentissages :

1. Le TextAnalyzerAgent identifie les nouvelles connaissances dans la reponse
2. De nouveaux memos sont extraits sous forme de paires cle-valeur (texte d’entree -> texte de sortie)
3. Ces memos sont stockes dans ChromaDB, disponibles pour les tours et sessions futurs

Cela cree une veritable boucle d’apprentissage ou l’agent accumule de l’expertise au fil du temps.

Persistance inter-sessions

AutoGen Teachability est l’une des trois seules plateformes de notre comparaison (avec Voyager et DSPy) qui persiste les competences entre les sessions. La base de donnees ChromaDB reside sur le disque, ce qui signifie qu’un agent peut apprendre des interactions du lundi et appliquer ces connaissances le vendredi.

Le parametre recall_threshold (par defaut 1.5) controle le degre de similarite necessaire entre un message et un memo stocke pour la recuperation, et reset_db peut effacer toute la memoire si necessaire.

Efficacite en tokens

Comme seuls les memos pertinents sont injectes par tour (generalement 3-5), le cout en tokens est naturellement borne independamment de la taille de la base de memos. Un agent avec 10 000 memos stockes ne paie que pour la poignee la plus pertinente au tour en cours.

Semantic Kernel : schemas de plugins comme definitions d’outils permanentes

Semantic Kernel de Microsoft adopte une approche directe : les plugins sont des collections d’objets KernelFunction enregistres aupres du Kernel, et leurs schemas sont exposes au LLM comme definitions d’outils d’appel de fonction.

Deux chemins d’injection

Appel de fonction : Lorsque ToolCallBehavior.AutoInvokeKernelFunctions est defini, toutes les fonctions enregistrees sont envoyees au LLM comme outils disponibles dans chaque requete API. Le LLM decide lesquelles appeler ; Semantic Kernel gere l’invocation et le routage des resultats.

Modeles de prompt : La syntaxe de modele de Semantic Kernel ({{plugin.function}}, Handlebars ou Liquid) permet d’appeler des fonctions en ligne pendant le rendu du prompt. Les resultats sont directement integres dans le texte du prompt avant qu’il n’atteigne le LLM — une forme d’evaluation anticipee plutot que d’appel d’outil paresseux.

Pas de divulgation progressive

Chaque schema de plugin enregistre est inclus dans chaque appel API. Il n’y a pas de chargement differe integre, de regroupement par espace de noms ou d’activation a la demande. La documentation recommande explicitement de n’importer que les plugins necessaires pour un scenario specifique afin de reduire la consommation de tokens et les appels errones.

Cela fait de Semantic Kernel l’une des plateformes les plus previsibles — vous savez toujours exactement a quoi l’agent a acces — mais cela limite la scalabilite. Un agent avec 50 fonctions enregistrees paie le cout complet des schemas a chaque appel.

Persistance

L’enregistrement des plugins est par instance de Kernel et en memoire. Il n’y a pas de mecanisme integre pour la persistance des competences inter-sessions.

MetaGPT : modeles d’action au sein de procedures operationnelles standard basees sur les roles

MetaGPT encode les competences non pas comme des packages autonomes mais comme des modeles d’action integres dans des procedures operationnelles standard (SOP) qui regissent le comportement des roles.

Architecture Role et Action

Chaque Role dans MetaGPT possede un prefixe de persona injecte dans les prompts et un ensemble de classes Action. Chaque Action contient un proxy LLM invoque via aask(), qui utilise des modeles de prompt en langage naturel pour structurer l’appel LLM.

Lorsque Role._act() se declenche, il prend en charge trois modes de reaction :

• "react" : Le LLM selectionne dynamiquement les actions dans des boucles reflexion-action
• "by_order" : Les actions s’executent sequentiellement dans un ordre predetermine
• "plan_and_act" : L’agent planifie d’abord, puis execute les actions selon le plan

Fenetre d’injection etroite

Seul le modele de prompt de l’Action en cours est actif a un moment donne. L’agent ne voit pas les modeles des autres actions — il ne voit que son prefixe de role plus le contexte de l’action specifique. C’est la fenetre d’injection la plus etroite de tous les frameworks que nous avons examines.

Les fonctions d’analyse de contexte au sein des classes Action extraient les informations pertinentes des entrees, de sorte que chaque action recoit un sous-ensemble organise du contexte disponible plutot que l’historique complet de la conversation.

Persistance a un seul tour

Le modele est rendu a nouveau pour chaque execution d’action. Il n’y a pas d’accumulation ni de persistance inter-sessions. Cela garde chaque action focalisee mais signifie que l’agent ne peut pas s’appuyer sur du contenu de competences precedemment charge au sein d’un meme workflow.

Voyager : recherche de competences par embedding pour l’apprentissage continu

Voyager, l’agent d’exploration Minecraft de NVIDIA et Caltech, implemente l’une des architectures d’injection de competences les plus elegantes : une bibliotheque croissante de programmes verifies recuperes par similarite d’embedding.

La bibliotheque de competences

Lorsque Voyager ecrit du code qui passe l’auto-verification (le JavaScript Mineflayer genere fonctionne reellement dans le jeu), le code et sa chaine de documentation sont stockes dans une base de donnees vectorielle. L’embedding de la docstring devient la cle de recuperation.

Recuperation par tache

A chaque nouvelle tache proposee par le curriculum automatique :

1. La description de la tache et le feedback de l’environnement sont convertis en embeddings
2. Recherche par similarite cosinus contre tous les embeddings de competences stockes
3. Les 5 competences les plus pertinentes sont recuperees
4. Le code des competences recuperees est inclus dans le prompt de l’agent d’action comme exemples few-shot

Le prompt ressemble a ceci :

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Le code genere peut appeler les competences recuperees par nom, permettant la construction compositionnelle de competences — des comportements complexes construits a partir de primitives plus simples et verifiees.

Persistance a vie

La bibliotheque de competences est le mecanisme central d’« apprentissage continu ». Elle croit tout au long de la vie de l’agent, et les nouvelles competences s’appuient sur les anciennes. Contrairement a la plupart des frameworks ou les competences sont redigees par des humains, les competences de Voyager sont generees, verifiees et stockees par l’agent lui-meme.

Le cout en tokens est naturellement borne : que la bibliotheque contienne 50 ou 5 000 competences, chaque tache ne paie que pour les 5 recuperations les plus pertinentes.

DSPy : exemples few-shot compiles comme competences figees

DSPy adopte une approche radicalement differente de tous les autres frameworks. Au lieu d’injecter des competences a l’execution, DSPy compile des demonstrations few-shot optimales hors ligne et les integre de maniere permanente dans les prompts des modules.

Le processus de compilation

Deux optimiseurs principaux gerent la compilation :

BootstrapFewShot : Utilise un module enseignant pour generer des traces a travers le programme. Les traces qui satisfont une metrique definie par l’utilisateur sont conservees comme demonstrations. Chaque module dspy.Predict au sein du programme recoit son propre ensemble organise de demonstrations.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2) : Un processus en trois phases :

1. Bootstrap : Generer des ensembles candidats de demonstrations
2. Proposition : Generer des textes d’instructions candidats qui tiennent compte a la fois de la distribution des donnees et des demonstrations
3. Recherche : Optimisation bayesienne sur l’espace combine des instructions x demonstrations a travers tous les modules

Les parametres comme max_bootstrapped_demos (exemples generes) et max_labeled_demos (a partir des donnees d’entrainement) controlent combien d’exemples finissent dans le prompt de chaque module.

Fixe apres compilation

Une fois compilees, les demonstrations sont stockees dans l’attribut demos de chaque module Predict et formatees dans le prompt a chaque appel LLM. Elles ne changent pas a l’execution — la « competence » est figee.

Cela signifie que les competences DSPy sont les plus previsibles de notre comparaison : le cout en tokens est connu apres compilation, il n’y a pas de variance entre les tours, et l’agent voit toujours les memes demonstrations. L’inconvenient est l’inflexibilite — pour changer les competences, vous devez recompiler.

Persistance

Les programmes compiles se serialisent en JSON, incluant toutes les demonstrations. Ils sont entierement persistants et chargeables entre les sessions, faisant de DSPy l’un des mecanismes de stockage de competences les plus durables.

SuperAGI : enregistrement initial base sur les toolkits

SuperAGI utilise un modele de toolkit traditionnel ou tous les outils sont enregistres a l’initialisation de l’agent.

Chaque toolkit etend BaseToolkit avec :

• Des attributs name et description
• Une methode get_tools() retournant une liste d’instances BaseTool
• get_env_keys() pour les variables d’environnement requises

Les toolkits sont installes a partir de depots GitHub via le gestionnaire d’outils de SuperAGI. A l’initialisation de l’agent, BaseToolkit.get_tools() retourne tous les outils, et leurs schemas complets sont exposes au LLM comme definitions d’appel de fonction.

Il n’y a pas de chargement differe, pas de divulgation progressive et pas de filtrage par tour. Chaque schema d’outil enregistre est present dans chaque appel. C’est le modele d’injection le plus simple et fonctionne bien pour les agents avec des ensembles d’outils focalises et reduits, mais ne se met pas a l’echelle pour les agents necessitant des dizaines de capacites.

CAMEL-AI : enregistrement d’outils ChatAgent

CAMEL-AI suit un modele d’enregistrement initial similaire. Les outils de divers toolkits (par ex., MathToolkit, SearchToolkit) sont passes sous forme de liste a ChatAgent(tools=[...]) a l’initialisation.

Le framework souligne que les fonctions personnalisees necessitent des noms d’arguments clairs et des docstrings completes pour que le modele puisse comprendre l’utilisation — le schema d’outil est le seul contenu de « competence » que le modele voit. Il n’y a pas de mecanisme d’injection d’instructions separe.

Les ajouts recents incluent la prise en charge MCP (Model Context Protocol) via MCPToolkit, permettant a ChatAgent de se connecter a des serveurs MCP et d’enregistrer des outils externes. Cela elargit la surface d’outils disponible mais ne change pas le modele d’injection — tous les outils MCP decouverts sont toujours enregistres d’emblee.

Comparaison multiplateforme

Quand les competences sont injectees

Modeles de persistance

Survie a la compaction du contexte

Le modele de divulgation progressive

La tendance architecturale la plus significative a travers ces plateformes est l’adoption de la divulgation progressive — un concept emprunte au design d’interface utilisateur ou l’information est revelee incrementalement en fonction du besoin.

Pourquoi la divulgation progressive est importante

Une approche naive de l’injection de competences — tout charger d’emblee — cree deux problemes :

1. Gaspillage de tokens : La plupart des competences ne sont pas pertinentes pour la plupart des tours. Charger 20 corps complets de competences quand seulement 1-2 sont necessaires par tour gaspille plus de 90 % des tokens lies aux competences.
2. Dilution de l’attention : Les recherches sur la degradation du contexte montrent que les LLM performent moins bien quand leur contexte contient de grandes quantites d’informations non pertinentes. Plus de competences dans le contexte peut en fait reduire la qualite de l’application des competences.

La divulgation progressive resout les deux problemes en maintenant un index leger des competences disponibles tout en ne chargeant le contenu complet que lorsque necessaire.

Variations d’implementation

Claude Code utilise un systeme dedie : metadonnees des competences dans les messages system-reminder, un outil Skill pour l’activation, et ToolSearch pour les schemas d’outils differes. Le framework gere l’injection automatiquement avec une compaction basee sur les priorites.

LangChain Deep Agents utilise la capacite de lecture de fichiers existante de l’agent : SkillsMiddleware injecte l’index, et l’agent charge le contenu complet via read_file(). C’est plus transparent mais offre moins d’optimisation au niveau du framework.

L’API Responses d’OpenAI utilise un regroupement par espace de noms avec une recherche geree par la plateforme : les espaces de noms d’outils fournissent des descriptions de haut niveau, et tool_search renvoie les schemas pertinents. La plateforme gere entierement la logique de recherche.

Economies de tokens en pratique

Les chiffres sont convaincants. Avec 12 competences :

• Injection permanente (style CrewAI/SuperAGI) : ~30 000 tokens
• Index de divulgation progressive seul : ~600 tokens
• Index + 2 competences activees : ~2 000-5 000 tokens

C’est une reduction de 83-98 % de la consommation de tokens liee aux competences par tour. Sur une longue session avec des centaines de tours, les economies se cumulent considerablement.

Modeles architecturaux et compromis

En examinant les 11 plateformes, quatre modeles architecturaux distincts emergent :

Modele 1 : injection permanente

Utilise par : CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Fonctionnement : Le contenu complet des competences ou les schemas d’outils sont presents dans chaque appel LLM.

Avantages :

• Fiabilite maximale — l’agent dispose toujours de l’expertise complete
• Implementation la plus simple — pas de logique d’activation necessaire
• Couts en tokens previsibles — identiques a chaque tour

Inconvenients :

• Le cout en tokens augmente lineairement avec le nombre de competences
• Dilution de l’attention avec de nombreuses competences
• Ne se met pas a l’echelle au-dela de ~5-10 competences par agent

Ideal pour : Les agents focalises avec 1-3 competences de base toujours pertinentes.

Modele 2 : divulgation progressive

Utilise par : Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Fonctionnement : Metadonnees legeres toujours presentes ; contenu complet charge a la demande.

Avantages :

• Se met a l’echelle pour des dizaines ou centaines de competences disponibles
• Cout minimal en tokens quand les competences ne sont pas necessaires
• Preserve le cache du prompt quand les schemas complets sont ajoutes a la fin

Inconvenients :

• L’agent pourrait manquer le signal pour activer une competence pertinente
• Latence supplementaire due a l’etape d’activation
• Implementation du framework plus complexe

Ideal pour : Les agents polyvalents qui necessitent l’acces a de nombreuses capacites mais n’en utilisent que quelques-unes par tache.

Modele 3 : recherche semantique

Utilise par : AutoGen Teachability, Voyager

Fonctionnement : Des requetes dans une base de donnees vectorielle font remonter les competences/connaissances pertinentes basees sur la similarite semantique avec le contexte actuel.

Avantages :

• Cout en tokens naturellement borne quelle que soit la taille de la bibliotheque
• La pertinence du contenu s’ameliore au fil du temps a mesure que la bibliotheque grandit
• Apprentissage et accumulation inter-sessions
• Pas d’activation explicite necessaire — la pertinence est calculee automatiquement

Inconvenients :

• La qualite de la recuperation depend de la qualite du modele d’embedding
• Risque de recuperer des informations obsoletes ou subtilement incorrectes
• Necessite une infrastructure de base de donnees vectorielle
• Moins previsible — differents tours chargent des contenus differents

Ideal pour : Les agents qui apprennent de l’experience et doivent accumuler des connaissances de domaine au fil du temps.

Modele 4 : injection compilee/statique

Utilise par : DSPy, MetaGPT

Fonctionnement : Les competences sont compilees en contenu de prompt fixe (DSPy) ou activees via des modeles d’action rigides (MetaGPT).

Avantages :

• Comportement le plus previsible — meme contenu a chaque fois
• L’optimisation peut etre faite hors ligne (compilation de DSPy)
• Pas de surcharge a l’execution pour la selection des competences
• Efficacite prouvee pour les taches bien definies et repetables

Inconvenients :

• Inflexible — changer les competences necessite une recompilation (DSPy) ou des modifications de code (MetaGPT)
• Ne peut pas s’adapter a des situations nouvelles en dehors des exemples compiles
• Le processus de compilation de DSPy necessite lui-meme de nombreux appels LLM

Ideal pour : Les pipelines de production avec des taches bien definies ou la fiabilite prime sur la flexibilite.

Implications pratiques pour les constructeurs d’agents

Choisir le bon modele

La bonne architecture d’injection de competences depend du profil de votre agent :

Si votre agent a un role etroit et bien defini (par ex., un bot de revue de code, un agent de support client pour un seul produit), l’injection permanente (modele CrewAI/SuperAGI) est la plus simple et la plus fiable. Le cout en tokens de 2-3 competences toujours presentes est gerable, et vous evitez la complexite de la logique d’activation.

Si votre agent necessite de larges capacites mais n’en utilise que quelques-unes par interaction (par ex., un assistant developpeur, un agent d’automatisation polyvalent), la divulgation progressive (modele Claude Code/Deep Agents) est le choix evident. Les economies de 83-98 % en tokens a grande echelle sont trop significatives pour etre ignorees.

Si votre agent doit apprendre et s’ameliorer a partir des interactions (par ex., un assistant personnel, un expert de domaine qui accumule des connaissances), la recherche semantique (modele AutoGen Teachability) fournit la boucle d’apprentissage que les autres modeles n’offrent pas. Assurez-vous simplement d’avoir des controles de qualite sur ce qui entre dans la base de connaissances.

Si votre agent execute des pipelines bien definis (par ex., traitement de donnees, generation de rapports, workflows standardises), l’injection compilee (modele DSPy) vous donne le comportement le plus previsible et optimise.

L’approche hybride

Pour les equipes d’agents en production ou les agents doivent fonctionner immediatement, nous recommandons une approche hybride :

Competences de base (1-2 par agent, definissant leur expertise de domaine principale) : toujours injectees dans le prompt systeme, a la maniere de CrewAI. Ce sont des capacites non negociables dont l’agent a besoin a chaque tour.

Competences etendues (capacites supplementaires dont l’agent pourrait avoir besoin) : metadonnees uniquement dans le prompt systeme, chargees via un mecanisme de recherche/chargement quand necessaire, a la maniere de Deep Agents. Celles-ci etendent l’ensemble des capacites de l’agent sans payer le cout en tokens quand elles ne sont pas pertinentes.

Connaissances acquises (expertise de domaine accumulee) : stockees dans une base de donnees vectorielle et recuperees semantiquement par tour, a la maniere d’AutoGen. Cela permet a l’agent de s’ameliorer au fil du temps sans redaction manuelle de competences.

Cette architecture en couches correspond naturellement a la facon dont un prompt systeme est construit : date -> persona -> instructions systeme -> competences de base -> index des competences -> contexte du role/equipe. Les competences de base et l’index ajoutent un cout en tokens previsible et gerable, tandis que les corps complets des competences n’apparaissent que lorsque necessaire.

Meilleures pratiques de budget de tokens a travers les frameworks

Quel que soit le modele d’injection que vous utilisez, ces strategies de gestion de tokens s’appliquent universellement :

Ordre favorable au cache

Empilez le contexte immuable (instructions systeme, schemas d’outils) au debut du prompt. Sur les fournisseurs qui prennent en charge la mise en cache des prompts, les tokens en cache coutent 75 % de moins. Claude Code et OpenAI injectent tous deux les schemas d’outils decouverts a la fin du contexte specifiquement pour preserver les hits de cache sur le prefixe statique.

Dechargement

Resumez les reponses des outils plutot que de conserver les resultats complets dans le contexte. Stockez les donnees completes dans des references externes que l’agent peut lire a la demande. C’est particulierement important pour les agents qui effectuent de nombreux appels d’outils par session.

Reduction

Compactez l’historique de conversation par la summarisation. Extrayez les faits cles de longs echanges en representations condensees. Chaque framework avec persistance basee sur la session beneficie d’une gestion agressive de l’historique.

Recuperation plutot que prechargement

Recuperez dynamiquement les informations pertinentes a l’execution plutot que de tout charger d’emblee. Cela s’applique aux competences, aux bases de connaissances et meme a l’historique de conversation. Les etudes montrent que cela peut reduire la taille des prompts jusqu’a 70 %.

Isolation

Utilisez des sous-agents pour des taches specifiques afin que le contexte de chaque agent reste focalise. Plutot que de donner a un seul agent 20 competences, creez une equipe de 5 agents avec 4 competences chacun. Chaque agent maintient une fenetre de contexte legere, et l’equipe couvre collectivement l’ensemble complet des capacites.

Conclusion

La facon dont les frameworks d’agents IA injectent les competences dans le contexte est l’une des decisions architecturales les plus consequentes dans la conception d’agents — pourtant elle est rarement discutee a ce niveau de detail.

Le domaine converge clairement vers la divulgation progressive comme modele prefere pour les agents polyvalents, avec Claude Code, LangChain Deep Agents et OpenAI arrivant tous independamment a des architectures similaires a trois niveaux. Pendant ce temps, des modeles specialises comme la recherche semantique (AutoGen, Voyager) et l’injection compilee (DSPy) servent des niches importantes que la divulgation progressive seule ne couvre pas.

Pour les praticiens construisant des systemes d’agents aujourd’hui, l’insight cle est que l’injection de competences n’est pas un probleme a solution unique. La bonne approche depend du role de votre agent, du nombre de competences dont il a besoin, de s’il doit apprendre au fil du temps, et de votre tolerance aux compromis entre couts en tokens et fiabilite.

Les systemes de production les plus robustes combineront probablement plusieurs modeles — injection permanente pour les capacites de base, divulgation progressive pour les competences etendues, et recherche semantique pour les connaissances accumulees — creant des agents a la fois efficaces et experts.