model-hierarchy

Vue d’ensemble de la compétence model-hierarchy

Ce que fait model-hierarchy

La compétence model-hierarchy aide un agent à confier le travail au modèle le moins coûteux capable de le traiter correctement. Elle est conçue pour les situations où vous voulez mieux maîtriser les coûts sans perdre en qualité sur les tâches courantes. Si votre workflow dépense des tokens premium pour des lectures de fichiers, des vérifications d’état, du formatage ou des recherches simples, cette compétence vous donne un guide model-hierarchy concret au lieu de vous fier uniquement à l’intuition.

Qui devrait l’installer

Installez model-hierarchy si vous exécutez un workflow d’agent qui lance des sous-agents, change souvent de modèle ou facture une multitude de petites tâches. C’est particulièrement utile pour Workflow Automation, les configurations de type Claude Code, et tout environnement où un mauvais choix de modèle gonfle discrètement la facture. C’est moins pertinent si vous avez déjà une logique de routage stricte dans le code ou si vous changez rarement de modèle.

Ce qui le différencie

La compétence ne se limite pas à dire « utilisez un modèle moins cher ». Elle encode une règle de décision simple : les tâches routinières vont sur un niveau bas, les tâches intermédiaires restent sur un niveau moyen, et seules les vraies difficultés justifient un raisonnement premium. Cela rend model-hierarchy plus actionnable qu’un prompt générique, parce qu’il donne à l’agent une habitude de classification répétable et un défaut clair pour le travail des sous-agents.

Comment utiliser la compétence model-hierarchy

Installer model-hierarchy

Le dépôt est conçu comme une compétence que vous copiez dans le répertoire de compétences de votre agent ou dans son contexte de prompt. Pour OpenClaw, le README du dépôt montre comment copier SKILL.md dans le chemin des skills, puis redémarrer la passerelle. Pour les systèmes de type Claude Code / Codex, l’installation la plus pratique consiste à coller les règles de routage dans CLAUDE.md ou dans les instructions du projet. Si vous évaluez model-hierarchy install, vérifiez si votre agent lit les compétences depuis des fichiers, des instructions globales ou une configuration locale au dépôt.

Commencer avec la bonne entrée

model-hierarchy usage fonctionne mieux si vous donnez trois éléments à l’agent : le type de tâche, le résultat attendu, et le fait que la tâche s’inscrit ou non dans un workflow plus large. Entrée faible : « aide-moi avec ce dépôt ». Entrée plus solide : « Classe ceci comme routinier ou intermédiaire, puis choisis le modèle le moins cher capable de lire config.json en toute sécurité, de résumer le résultat et d’indiquer le risque si la classification est erronée. » Cela donne à la compétence assez de contexte pour router correctement.

Lire ces fichiers en premier

Commencez par SKILL.md pour les règles de routage, puis consultez README.md pour les schémas d’installation et examples/claude-code.md ou examples/openclaw.md pour l’usage propre à chaque plateforme. Si vous voulez comprendre le comportement dans les cas limites, tests/scenarios.json est utile, car il montre comment la compétence classe les tâches routinières par rapport aux tâches intermédiaires. C’est le chemin le plus rapide pour comprendre la model-hierarchy skill sans lire chaque ligne du dépôt.

L’utiliser dans un workflow

Un workflow model-hierarchy pratique consiste à : classer la tâche, décider si elle est routinière, intermédiaire ou complexe, puis choisir le modèle acceptable le moins coûteux avant l’exécution. Pour les sous-agents, partez du plus économique par défaut, sauf si la tâche exige un raisonnement profond ou de la vision. Soyez explicite quand la tâche inclut des images, la lecture de graphiques ou d’autres travaux non textuels, car les modèles texte seuls ne doivent pas être utilisés dans ces cas. Cette frontière compte davantage que le coût en tokens.

FAQ sur la compétence model-hierarchy

model-hierarchy est-il réservé à OpenClaw ?

Non. OpenClaw est un schéma d’intégration pris en charge, mais la compétence est aussi pertinente pour Claude Code, Codex et d’autres piles d’agents qui permettent de définir un comportement de routage dans les instructions. Si votre système peut suivre une politique de sélection de modèle, model-hierarchy peut généralement s’y intégrer.

En quoi cela diffère-t-il d’un prompt classique ?

Un prompt classique demande un comportement ponctuel. La compétence model-hierarchy vous donne une règle de routage réutilisable qu’un agent peut appliquer avant chaque tâche. C’est donc mieux adapté aux opérations répétées, aux agents d’arrière-plan et aux workflows sensibles aux coûts, où le choix du modèle fait partie du travail.

Est-ce adapté aux débutants ?

Oui, si vous savez distinguer les tâches routinières, intermédiaires et complexes. La compétence est plus simple qu’un moteur de politique complet, mais il faut rester honnête sur la difficulté réelle des tâches. Si vous sous-classez un débogage difficile ou un travail de vision en tâche routinière, les économies disparaissent dès que le modèle échoue et qu’il faut relancer.

Quand ne faut-il pas l’utiliser ?

N’utilisez pas model-hierarchy comme stratégie générale de downgrade pour tout. Si le travail demande un débogage poussé, des choix d’architecture, une revue de sécurité ou une entrée multimodale, le modèle le moins cher est généralement le mauvais choix. C’est aussi un mauvais ajustement si votre organisation impose déjà la sélection de modèle dans le code avec des garde-fous solides.

Comment améliorer la compétence model-hierarchy

Donner des libellés de tâche plus précis

Le moyen le plus rapide d’améliorer les résultats de model-hierarchy est d’annoncer d’emblée la catégorie de la tâche. Les bonnes consignes nomment l’action et la complexité attendue : « recherche de fichier routinière », « brouillon de code intermédiaire » ou « débogage complexe avec échec précédent ». Cela réduit les approximations et aide l’agent à appliquer le bon niveau dès le premier passage.

Décrire les contraintes qui influencent le routage

Le choix du modèle change quand vous mentionnez la taille du contexte, une entrée multimodale ou la tolérance à l’échec. Par exemple : « Il s’agit d’une tâche de résumé texte seul à partir d’un journal de 200 lignes » ou « Cela demande une analyse de capture d’écran, donc évitez les modèles texte seuls. » Ces détails comptent, parce qu’ils révèlent des cas d’inadéquation que la compétence ne doit pas chercher à lisser.

Itérer après le premier passage

Si la première réponse paraît trop sophistiquée, demandez à l’agent de reclasser la tâche et d’expliquer pourquoi il a choisi ce niveau. Si elle paraît trop faible, demandez une montée de niveau et faites préciser les signaux manquants : raisonnement entre plusieurs fichiers, ambiguïté ou échec précédent. Le model-hierarchy guide fonctionne mieux quand vous l’utilisez comme contrôle de routage, et non comme verdict unique et définitif.

Surveiller les modes d’échec courants

Le principal mode d’échec consiste à traiter comme routinières des tâches qui semblent simples alors qu’elles cachent des dépendances, des cas limites ou des besoins de vision. Un autre consiste à copier la compétence dans un workflow sans dire à l’agent où trouver la politique ni quand la contourner. Pour améliorer model-hierarchy for Workflow Automation, gardez la règle de routage proche de la source de la tâche et rendez explicite le chemin d’escalade.