Conception, perfectionnement et maintenance des agent skills chez Perplexity

Les produits d'agents pionniers de Perplexity reposent sur un ensemble de savoir-faire et d'expertise sectorielle regroupés dans des Agent Skills modulaires. Nous maintenons une bibliothèque soigneusement sélectionnée de Skills dans nos environnements techniques. Ces Skills comprennent nombre d'utilitaires polyvalents qui alimentent Perplexity Computer ; des capacités propres à certains secteurs tels que la finance, le droit et la santé ; ainsi qu'une longue traîne de modules pour répondre aux besoins des utilisateurs. Certains Skills sont rarement invoqués mais s'avèrent critiques lorsqu'ils le sont. Afin de garantir une expérience utilisateur constamment excellente, l'équipe des agents de Perplexity accorde autant d'importance à la qualité des Skills qu'à celle du code.

Les intuitions et les meilleures pratiques nécessaires pour développer un Skill de haute qualité diffèrent sensiblement de celles requises pour concevoir des logiciels traditionnels. L'équipe des agents examine de nombreuses demandes de tirage (pull requests) provenant d'excellents ingénieurs qui développent des Skills dans le cadre de leur travail. Le résultat s'accompagne presque toujours de nombreux commentaires et suggestions de révision. Cela s'explique par le fait que de nombreux modèles utiles pour l'écriture de code deviennent des anti-modèles lors de la création de Skills.

Par exemple, si l'on reprend certains aphorismes de PEP20 – Le Zen de Python, on comprend rapidement que rédiger du bon code Python ne ressemble en rien à la rédaction de bons Skills. Sur les 20 lignes de sagesse, au moins la moitié s'avèrent complètement fausses ou activement trompeuses lors de la rédaction de Skills. En voici cinq :

Cinq contrastes entre le zen de Python et les conseils de l’article pour rédiger des Skills.

Ce guide est le document que les ingénieurs de tout Perplexity utilisent lors du développement et de la révision des Skills. Nous publions également ce guide auprès du grand public afin que nos découvertes et nos apprentissages puissent faire profiter la communauté au sens large. Que vous soyez un ingénieur concevant des Skills de production dans votre travail quotidien, un utilisateur de Computer cherchant à développer votre propre Skill dans un domaine que vous maîtrisez le mieux, ou les deux, ce guide est fait pour vous.

Qu'est-ce qu'un Skill ?

Lorsque vous écrivez un Skill, vous n'écrivez pas un simple logiciel ordinaire (même si les Skills font désormais partie des moteurs logiques principaux des systèmes d'agents). Vous construisez plutôt un contexte pour les modèles et leurs environnements. Un Skill obéit à des contraintes différentes et à des principes de conception distincts. Si vous écrivez un Skill comme du code, vous échouerez.

Un Skill remplit au moins quatre rôles, en particulier dans le contexte de notre façon de les concevoir chez Perplexity.

Un Skill est un répertoire

Un Skill n'est pas seulement un fichier unique SKILL.md. Dans de nombreux cas, un Skill comprend plusieurs fichiers. Sous le répertoire portant le nom de votre Skill, vous pourriez avoir :

SKILL.md : en-tête (frontmatter) et instructions

scripts/ : code exécuté par l'agent, et non réinventé

references/ : documentation lourde, chargée de manière conditionnelle

assets/ : modèles, schémas et données

config.json : configuration utilisateur lors de la première exécution

Ce modèle en étoile (hub-and-spoke) vous permet de garder des Skills très ciblés et concis, et l'on peut exploiter la structure des dossiers de manière très créative. Parfois, des Skills particulièrement complexes bénéficient de plusieurs niveaux de hiérarchie pour aider le modèle à mieux naviguer. Supposons qu'un Skill exige des connaissances réparties sur 300 sujets, regroupables en 20 domaines thématiques. Choisir de manière fiable le bon sujet parmi 300 demeure un défi non résolu, même pour les meilleurs modèles pionniers d'aujourd'hui. C'est un problème de choix beaucoup plus simple pour un modèle de cibler l'un des 20 domaines plutôt que de chercher parmi les 15 sujets que contient ce domaine.

À titre d'exemple de la valeur apportée par une hiérarchie à plusieurs niveaux, notre équipe a employé trois niveaux d'imbrication thématique au sein des Skills alimentant les capacités de déclaration de revenus aux États-Unis de Computer lors de la dernière saison fiscale. Cette hiérarchie s'est avérée absolument indispensable compte tenu de la complexité du droit fiscal : lors de nos premiers tests, présenter au modèle un seul dossier contenant l'ensemble des 1 945 sections du code des impôts américain (Internal Revenue Code) a entraîné des performances inférieures à celles obtenues sans charger le Skill du tout. Organiser l'information en subdivisions logiques s'est avéré indispensable pour garantir des opérations de lecture d'une grande précision.

Pourtant, cette hiérarchie n'était pas gratuite. Des niveaux croissants de hiérarchie exigent des niveaux croissants de curation au sein de l'architecture de l'information pour gérer l'indirection qui en résulte. Nous avons conçu des guides de référence rapide, des utilitaires de recherche personnalisés et d'autres outils pour aider le modèle à localiser l'information avec un minimum d'indirection. Dans ce cas, accomplir le travail difficile de curation a fini par produire un résultat final positif : un Skill qui a permis aux modèles d'exécuter des tâches liées à la fiscalité avec beaucoup plus d'efficacité qu'en utilisant de simples outils généraux seuls.

Agrandir

Un Skill est un format

Un Skill est un format. Le fichier racine principal SKILL.md doit comporter à la fois un nom et une description. De plus, le Skill doit correspondre exactement au nom du répertoire dans lequel il se trouve. Le nom doit être composé exclusivement de caractères minuscules, ne comporter aucun espace et peut utiliser des traits d'union. La description constitue le déclencheur de routage. Il s'agit d'un point de défaillance courant : la description ne sert pas de documentation interne expliquant ce que fait le Skill. Elle équivaut à des instructions destinées au modèle indiquant quand charger le Skill. Par conséquent, vous verrez fréquemment « Charger lorsque » (Load when) plutôt que « Ce Skill fait » (This Skill does). Cela est important en raison de la manière dont la plupart des implémentations injectent la description dans le contexte du modèle.

Au sein de l'en-tête (frontmatter), on trouve également « depends: », qui permet de créer des dépendances hiérarchiques entre les Skills, et « metadata: », qui est utilisé pour les examens et les évaluations. Différents systèmes d'agents peuvent même définir leurs propres champs d'en-tête, à utiliser d'une manière propre à ces systèmes. Alternativement, les métadonnées spécifiques aux Skills peuvent être regroupées dans un fichier de configuration auxiliaire JSON ou YAML. C'est souhaitable lors de la construction de systèmes d'agents qui doivent faciliter différents types de comportements d'exécution par Skill sans polluer le contexte du modèle avec des détails superflus. Enfin, un comportement similaire peut être obtenu en supprimant l'en-tête du Skill lors de la lecture. Computer utilise cette méthodologie, ce qui permet de préserver la configuration dans le fichier racine SKILL.md. Une attention minutieuse aux détails est requise dans la logique d'analyse, et l'on peut souhaiter mettre en œuvre une suppression conditionnelle s'il existe certains champs qu'il est utile de conserver dans le contexte du modèle.

Un Skill est invocable

Un Skill est invocable. L'agent charge un Skill à l'exécution (runtime). Fait important, les Skills ne sont pas toujours intégrés d'office dans le contexte. Par défaut, la plupart des systèmes d'agents déploient les Skills de manière progressive selon un besoin spécifique.

Il existe au moins trois niveaux de coûts de contexte dans la façon dont nous avons implémenté les Skills dans Computer. Voici le processus :

Computer appelle load_skill(name="...")

Computer copie le répertoire du Skill dans l'environnement d'exécution isolé (bac à sable)

Computer charge automatiquement et de manière récursive les dépendances indiquées dans la balise « depends: »

Computer supprime ensuite l'en-tête (frontmatter) et l'agent ne voit ainsi que le corps et les fichiers supplémentaires

Différents systèmes d'agents peuvent choisir d'exposer le contenu des Skills de différentes manières. Par exemple, certains systèmes peuvent choisir de ne pas exposer du tout la hiérarchie des fichiers, laissant au modèle le soin de la découvrir par le biais d'opérations sur le système de fichiers. D'autres systèmes peuvent choisir de fournir au modèle une mise en correspondance de toute l'arborescence des fichiers jusqu'à une limite de troncature et/ou de profondeur déterminée. Pour garder un contexte propre, Computer omet les hiérarchies de fichiers complètes du contexte d'invocation ; toutefois, cela peut être outrepassé pour chaque Skill individuellement.

Un Skill est progressif

Les Skills sont progressifs. Dans Computer, il existe trois niveaux différents de coûts de contexte, et nous supportons les trois à divers stades :

Les trois niveaux de contexte d’une Skill : index, chargement complet de la Skill et fichiers de référence à l’exécution.

Computer construit un index de Skills qui contient le nom et la description de chaque Skill disponible. Le budget alloué à cet effet est d'environ 100 jetons par Skill (plus c'est court, mieux c'est). C'est si serré parce que vous payez ce coût à chaque session, pour chaque utilisateur. Ceci est injecté dans l'invite système (system prompt) au tout début de la conversation. Le modèle a accès à un ensemble de Skills nommés et de descriptions afin qu'il puisse décider s'il doit appeler « load_skill() ». Le seuil d'accès à cet index est extrêmement élevé. Votre Skill doit être très utile, et la description doit être extrêmement dense et concise, car tout le monde en paie le coût en permanence.

Une fois que le système d'agents a chargé le Skill, le corps complet du SKILL.md entre en jeu. Idéalement, le texte principal ne dépasse pas 5 000 jetons. Même dans ce cas, vous voulez que chaque phrase compte, car une fois qu'un Skill est chargé, le reste de la conversation doit en supporter le coût jusqu'à ce que vous atteigniez la limite de compactage. De nombreux fils de discussion (threads) chargent entre trois et cinq Skills différents, ce qui multiplie d'autant ce coût. Les Skills comportant beaucoup de superflus dégraderont presque coup sûr les autres Skills ainsi que les capacités globales des agents. En bref, si votre Skill se charge et ne fait pas ce qu'il faut, il s'agit d'un contexte gâché.

Le niveau final de progression concerne les scripts ou les cas particuliers, tels que les sous-compétences ou la mise en forme. C'est là que vous souhaitez placer une logique de branchement conditionnelle illimitée. L'agent ne l'utilisera que lorsqu'il en aura besoin, ce qui signifie que le seuil d'exigence pour ce que vous souhaitez y inclure est beaucoup plus bas.

Dans l'index, chaque jeton a son importance. Le corps du Skill chargé est plus souple, et l'exécution l'est encore plus. Cela peut représenter 20 000 jetons ou zéro jeton. C'est à ce niveau que vous pouvez envisager d'élargir le contexte du modèle de manière progressive.

Quand a-t-on besoin d'un Skill ?

L'équipe des agents est souvent sollicitée pour donner son avis sur la question de savoir si un Skill est réellement nécessaire pour un domaine ou un cas d'utilisation donné. Nous n'avons que très rarement une réponse définitive reposant uniquement sur des principes premiers. La seule façon de s'en assurer vraiment est de démarrer avec votre agent sans le Skill, d'exécuter plusieurs requêtes de référence (hero queries), puis de déterminer si l'agent fait du bon travail.

Quand vous avez besoin d'un Skill

De nombreuses tâches relèvent de la distribution normale pour les modèles entraînés. Vous n'avez besoin d'appliquer un Skill que si vous souhaitez modifier ce comportement d'une manière spécifique qu'il n'est pas possible d'obtenir avec, disons, une seule phrase dans votre invite. Par conséquent, vous avez besoin d'un Skill lorsque l'agent commettra des erreurs en l'absence d'un contexte spécial, ou s'il existe une incohérence ou un manque de déterminisme nécessitant une constance absolue d'une exécution à l'autre.

Il se peut que vos connaissances soient durables mais absentes des données d'entraînement. Il peut y avoir des dates limites de coupure (cutoffs) ou des flux de travail propres à une entreprise, ou bien il peut s'agir d'une question de goût. Par exemple, nous avons plusieurs Skills liés à la conception dans Computer rédigés par Henry Modisett (notre responsable du design). Si chaque jeton existe dans ces Skills, c'est parce qu'Henry possède un excellent goût en matière de conception de sites Web et de fichiers PDF. Henry spécifie quelles polices utiliser et lesquelles éviter, comment ces polices se ressentent (feel), ainsi que d'autres questions de jugement que le modèle ne peut pas apprendre des seules données d'entraînement.

Quand vous n'avez pas besoin d'un Skill

Nous voyons de nombreux Skills dans lesquels des ingénieurs ont rédigé une série de commandes git devant être exécutées dans l'ordre. C'est inutile, car le modèle sait déjà comment faire ; cela donne donc une excellente documentation, mais un piètre Skill.

Nous voyons des exemples où des Skills répètent des instructions issues de l'invite système. Vous n'avez pas besoin d'un Skill pour cela. Les connaissances pertinentes pour la majorité des requêtes doivent être incluses dans le contexte global, et non dans un Skill chargé de manière conditionnelle.

S'il y a quelque chose qui évolue plus vite que vous ne pouvez le maintenir, vous n'avez pas besoin d'un Skill. Par exemple, si vous accédez à un point de terminaison MCP distant et que ses outils ou les versions de ces outils changent fréquemment, vous ne devriez pas les injecter dans un Skill. Si vous le faites, vous finirez simplement par créer un décalage (drift) et le modèle commettra des erreurs.

Chaque Skill représente une taxe

Voici un test utile que vous pouvez appliquer à chaque phrase de votre Skill : « L'agent commettrait-il une erreur sans cette instruction ? » Si la phrase n'a pas besoin d'être là, elle ne peut pas se permettre d'y être, car tout le monde paie ce coût à chaque fois. Lorsque vous décidez d'ajouter ou non un Skill, rappelez-vous de cette taxe dans laquelle chaque session et chaque utilisateur consomment des jetons.

La citation célèbre suivante, qui sonne beaucoup mieux en français, se traduit approximativement par « Je n'ai fait cette lettre plus longue que parce que je n'ai pas eu le temps de la faire plus courte. »

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Tout comme Pascal, vous devez investir du temps dans chaque Skill. Il est difficile d'écrire un Skill court. Si votre Skill est facile à écrire, c'est qu'il est probablement trop long ou qu'il ne devrait pas exister. Un bon Skill doit être aussi court que possible.

Si vous vous surprenez à essayer de générer un Skill du premier coup (one-shot) et à soumettre des demandes de tirage (PR) en cinq minutes, les résultats seront presque certainement décevants. En fait, des recherches préliminaires ont montré que si vous utilisez des LLM pour rédiger des Skills, le LLM n'en tirera probablement aucun profit : « Les Skills générés automatiquement n'apportent aucun avantage en moyenne, ce qui montre que les modèles ne peuvent pas rédiger de manière fiable les connaissances procédurales qu'ils tirent profit à consommer. »

Comment construire un Skill

Autrement dit, vous devez injecter votre avis dans tout Skill que vous écrivez. Suivez ces étapes.

Étape 0 : Rédiger les évaluations (Evals)

Rédigez d'abord certaines évaluations. Vous pouvez sourcer vos cas d'évaluation à partir de :

Requêtes d'utilisateurs réels : échantillonnez à partir de la production ou de votre groupe d'experts (brain trust)

Échecs connus : L'agent a échoué parce que le Skill n'existait pas

Confusion avec les voisins : Proche de la limite de votre domaine mais routé vers un autre Skill

À tout le moins, vous devez vous assurer de tester que le Skill se charge lorsqu'il le faut. Idéalement, vous en échantillonnez certains, peut-être à partir d'un environnement de production. Vous pourriez également envisager des cas d'erreur connus : la raison même pour laquelle vous avez entrepris d'écrire le Skill est peut-être liée à un échec spécifique que vous avez remarqué, ou vous effectuez peut-être une refactorisation et il existe une certaine confusion entre deux domaines proches couverts par un seul Skill.

Commencez par des exemples négatifs et positifs similaires. Les exemples négatifs sont extrêmement puissants et peuvent compter plus que les exemples positifs.

Étape 1 : La description

Il s'agit de la ligne la plus difficile du Skill. C'est un déclencheur de routage, et non de la documentation. Pour obtenir le bon nom et la bonne description, le contenu du Skill vous importe peu. Vous vous souciez uniquement de savoir si le Skill est chargé et injecté aux bons endroits et s'il est exempt d'effets secondaires hors cible, ce qui constitue le mode de défaillance numéro un. Chaque fois que vous ajoutez un Skill supplémentaire, vous risquez de rendre chaque autre Skill un peu moins bon ; vous devez donc veiller à minimiser la régression.

Encore une fois, une mauvaise description décrit ce que fait le Skill ou pourquoi il est utile. Une bonne description indique quand l'agent doit charger le Skill. Par exemple, disons que vous avez un outil pour surveiller les demandes de tirage. N'écrivez pas ce que fait le Skill. Écrivez ce que disent les ingénieurs lorsqu'ils sont frustrés et qu'ils veulent que vous veilliez à ce que leur PR fonctionne, comme « faire du baby-sitting », « surveiller l'intégration continue (CI) » ou « s'assurer que cela aboutit ».

Voici une liste de contrôle rapide :

Commence par « Charger lorsque... » (Load when...)

Visez 50 mots ou moins

Décrit l'intention de l'utilisateur, idéalement à partir de requêtes réelles

Ne résume pas le flux de travail

Les requêtes réelles sont ce que vous pouvez couvrir selon la règle du 80-20. Généralement, deux ou trois exemples fonctionnent bien. Il n'est pas facile d'ajouter exactement et uniquement ce dont vous avez besoin.

Étape 2 : Rédiger le corps

Ensuite, rédigez le contenu du Skill lui-même. Remarquez qu'il ne s'agit ni de l'étape 0 ni de l'étape 1.

Communiquer des flux de travail à un LLM est complètement différent de communiquer des flux de travail à un collègue, ou même à votre système d'exécution. Lors de l'apprentissage d'un nouvel outil logiciel, un ingénieur peut avoir besoin de lire la documentation, d'obtenir une démonstration guidée par quelqu'un d'expérimenté et d'apprendre à utiliser l'outil. En revanche, pour presque tous les outils logiciels qui existent depuis au moins un an, il suffit de mentionner son nom et le LLM dispose de toutes les informations dont il a besoin.

Lorsque vous rédigez le corps, passez sous silence les choses évidentes. De nombreux ingénieurs ont beaucoup d'expérience dans la rédaction de fichiers readme.md qui énumèrent toutes les commandes qu'une personne doit exécuter. Il est facile de retomber dans travers lorsque l'on écrit un Skill parce qu'on a l'impression d'écrire de la documentation, mais si vous faites cela, votre Skill sera nul. Par conséquent, n'écrivez pas une suite de commandes.

Par exemple, vous n'avez pas besoin d'écrire : « git log # trouver la validation (commit) ; git checkout main ; git checkout -b <branche-propre> ; git cherry-pick <validation> ; »

À la place, écrivez : « Appliquez par cherry-pick la validation sur une branche propre. Résolvez les conflits en préservant l'intention. S'il est impossible de l'intégrer proprement, expliquez pourquoi. »

Le modèle fera un travail bien meilleur avec cette dernière formulation qu'avec la série de commandes excessivement prescriptive de la première, en particulier lorsque des problèmes surviennent. Ne faites pas de dirigisme et ne soyez pas excessivement prescriptif, ce qui est fragile ; montrez-vous plutôt flexible là où de multiples approches peuvent fonctionner. Encore une fois, une bonne documentation pour les humains s'avère le plus souvent être une mauvaise documentation pour les modèles.

Ensuite, concentrez-vous sur les pièges ou les exemples négatifs. Il s'agit de contenus à très haute valeur ajoutée, car ils guident souvent le modèle sur ce qu'il ne faut pas faire. Si vous ajoutez une ligne chaque fois que l'agent commet un faux pas, vous apprendrez en l'exécutant et les pièges se multiplieront de manière organique.

Enfin, s'il y a une partie qui est conditionnelle ou très lourde en contenu, retirez-la du SKILL.md, qui est le moyeu (hub), et placez-la dans l'un des rayons. Mettez-la dans un fichier accessoire qui peut être chargé de manière progressive, ce que nous allons aborder ensuite.

Étape 3 : Utiliser la hiérarchie

Tirez parti de la hiérarchie des Skills lorsque vous disposez d'un script, de références ou que vous utilisez un outil spécifique :

Utilisations suggérées des scripts, des références, des ressources et de la configuration dans une Skill.

Pour tout ce qui est conditionnel ou qui se ramifie à partir du Skill principal, isolez-le dans un dossier. Rappelez-vous également que la hiérarchie à plusieurs niveaux peut être utilisée pour des Skills particulièrement complexes. Pour ceux-ci, vous voudrez réfléchir mûrement à la question de savoir si la fonctionnalité doit être implémentée de manière monolithique ou sous forme de collection de Skills (éventuellement avec des relations de chargement basées sur depends:).

Étape 4 : Itérer

Ensuite, effectuez une série d'itérations sur une branche. Partez de la branche principale sans Skill, faites quelques itérations, construisez votre jeu de requêtes de référence et exécutez une volée d'évaluations. Quiconque examine votre code de Skill vous remerciera d'avoir soumis un ensemble de modifications complet accompagné d'un jeu d'évaluation. L'examen de modifications incrémentielles consécutives (sauf pour un nouveau piège) est très difficile, essayez donc de le minimiser.

Vous effectuerez probablement de nombreux petits changements de mots. De petits changements de mots dans les descriptions peuvent avoir un impact disproportionné sur le routage (y compris des effets de débordement sur d'autres Skills) ; effectuez donc tout ce travail avant l'étape 5.

Étape 5 : Livrer

Livrez-le.

Comment maintenir un Skill

Maintenant que vous avez écrit un Skill, vous devez le maintenir.

Le volant cinétique des pièges (Gotchas Flywheel)

À partir de ce moment, votre liste de pièges a tendance à croître ou à changer considérablement. Nous voyons souvent des ingénieurs qui soumettent des demandes de tirage (PR) sans évaluation, et qui modifient par exemple la description. Si vous modifiez la description après que votre Skill a été fusionné, vous faites fausse route. Si vous apportez des modifications à l'élément qui décide du routage de votre Skill, vous devez rédiger des évaluations qui soutiennent ces modifications.

Les Skills s'enrichissent principalement par ajouts. La section des pièges accumule le plus de valeur au fil du temps :

L'agent échoue sur quelque chose → Ajouter un piège

L'agent charge le Skill hors cible → Affiner la description et ajouter des évaluations négatives

L'agent ne charge pas le Skill quand il le devrait → Ajouter des mots-clés et des évaluations positives

L'invite système change → Vérifier s'il y a des conflits ou des duplications

Il est facile de remarquer un cas d'échec unique lors de tests internes ou en production et d'ajouter un piège. C'est un exemple négatif, donc cela ne modifie pas réellement les directives explicites, mais cela fait savoir au modèle : « Hé, il y a ce problème connu. »

À mesure que vous passez de la règle du 80-20 à l'atteinte d'un taux de réussite de 99,9 % ou 99,99 %, il est facile de faire croître cette liste de pièges. À mesure que vous observez ces exemples négatifs, vous devriez principalement ajouter des éléments à la section des pièges. Vous ne devriez pas ajouter d'instructions plus longues ni modifier la description.

Suites d'évaluation (Eval Suites)

Chez Perplexity, nous exécutons de nombreuses suites d'évaluation pour vérifier différents aspects. Il y a le chargement de Skills et la lecture de fichiers de Skills, ce qui permet de vérifier la précision (precision), le rappel (recall) et les contrôles d'interdiction du chargement de Skills proprement dit. L'agent acheminera-t-il votre Skill lorsqu'il est censé le faire ? Celles-ci garantissent que les nouveaux Skills ne brisent pas les frontières existantes.

Il existe également des évaluations permettant de vérifier le chargement progressif approprié. L'agent peut charger le Skill, mais lit-il le ou les fichiers accessoires ? Par exemple, si vous avez un Skill lié à la finance pour des requêtes financières, lit-il le fichier spécial FORMATTING.md ?

Il existe également des évaluations de Skills qui testent l'achèvement de tâches de bout en bout au sein des domaines. Nous exécutons la boucle complète de l'agent et faisons appel à un juge LLM pour noter les résultats sur la base d'une grille d'évaluation aux critères bien définis.

Enfin, il est important d'exécuter ces évaluations par rapport à différents modèles. Computer prend en charge au moins trois familles de modèles d'orchestration différents : GPT, Claude Opus et Claude Sonnet. Vous souhaitez exécuter le chargement de vos Skills et les Skills de domaine face à ces différents orchestrateurs d'agents pour vous assurer de ne pas obtenir de comportements divergents. Sonnet et GPT se comportent de manière assez différente en ce qui concerne les Skills.

Dernières réflexions et points à retenir

Plus vous construisez de Skills, plus vous deviendrez habile à les concevoir. Si vous n'automatisez pas ou n'essayez pas de rendre plus reproductibles les tâches que vous effectuez au jour le jour à l'aide de Skills, commencez immédiatement.

L'acte de construire des Skills vous rend meilleur dans la construction d'autres Skills, et ils sont également extrêmement efficaces pour automatiser les processus opérationnels. Si vous pouvez décrire quelque chose que vous faites chaque semaine avant votre réunion debout (standup), à la fin de chaque sprint, ou toute tâche que vous effectuez en tant qu'ingénieur sur une base quotidienne, hebdomadaire, voire trimestrielle, vous devriez rédiger un Skill pour regagner du temps.

Pouvez-vous automatiser les bilans post-incident (postmortems) ? Pouvez-vous examiner des demandes de tirage ? Pour toute tâche que vous pouvez accomplir, vous pouvez au moins faire en sorte qu'une première passe soit réalisée par un Agent Skill. Cela vous fera gagner un temps considérable.

Cela étant dit, rappelez-vous qu'un Skill n'est ni facile ni même toujours nécessaire. Moins, c'est plus. Quelques autres points à retenir :

Rédigez les évaluations avant le Skill. Incluez des exemples négatifs et des charges interdites pour les compétences adjacentes mais distinctes.

La description est la partie difficile. « Charger lorsque... » (chaque mot coûte en attention).

Les pièges (gotchas) constituent un contenu à très haute valeur ajoutée. Commencez léger, faites croître à mesure que l'agent échoue.

N'oubliez pas qu'il est facile de briser d'autres Skills préexistants en ajoutant un nouveau Skill, même si vous n'y avez pas touché (attention aux actions à distance).

Utilisez tous les outils disponibles chaque fois que vous écrivez et maintenez un Skill. Si vous souhaitez en savoir plus, le site Web des Agent Skills propose de nombreux bons exemples, et notre dépôt interne tout comme l'écosystème public contiennent de multiples exemples de Skills bien conçus.

Citation

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}