Shell + Skills + Compactage : conseils pour des agents capables de mener des tâches concrètes de longue durée

Nous passons d’assistants limités à un seul échange à des agents capables de mener des tâches intellectuelles concrètes de longue durée : lire de grands jeux de données, mettre à jour des fichiers et développer des applications.

En nous appuyant sur les retours des développeurs et sur notre expérience du développement de Codex et d’agents internes, nous lançons un nouvel ensemble de primitives agentiques qui facilitent les tâches de longue durée :

• Skills (alignées sur le standard ouvert Agent Skills) : des instructions réutilisables et versionnées que vous pouvez monter dans des conteneurs pour permettre aux agents d’exécuter leurs tâches de manière plus fiable.
• L’outil shell amélioré : un conteneur hébergé par OpenAI avec un accès Internet contrôlé, dans lequel un agent peut installer des dépendances, exécuter des scripts et écrire des résultats (par exemple, des rapports et des artefacts).
• Compactage côté serveur : un moyen simple de compacter automatiquement les longues exécutions agentiques pour ne jamais atteindre les limites de contexte.

La documentation et la référence de l’API présentent chacun de ces éléments séparément. Cet article se concentre sur les conseils et les approches moins évidents qui ont donné les meilleurs résultats jusqu’ici, tant dans nos travaux chez OpenAI qu’en production chez Glean, l’un des premiers clients à utiliser les skills.

Les concepts en bref

Skills : des « procédures » que le modèle peut charger à la demande

Une skill regroupe des fichiers et un manifeste SKILL.md contenant des métadonnées en frontmatter et des instructions. Voyez-la comme un guide pratique versionné que le modèle peut consulter au moment de passer à l’action.

Lorsque des skills sont disponibles, la plateforme expose au modèle les champs name, description et path de chacune. Le modèle s’appuie sur ces métadonnées pour décider s’il doit invoquer une skill. Si c’est le cas, il lit SKILL.md pour accéder au workflow complet.

Outil shell : l’« exécution » pour les agents

L’outil shell permet aux modèles de travailler dans un véritable environnement de terminal, selon deux modalités :

• Des conteneurs hébergés et gérés par OpenAI.
• Un environnement d’exécution shell local que vous faites fonctionner vous-même (l’outil conserve la même sémantique, mais vous contrôlez la machine).

Le shell distant fonctionne via l’API Responses : vos requêtes bénéficient ainsi de la conservation de l’état du travail, d’appels d’outils, de la poursuite du travail sur plusieurs échanges et d’artefacts.

Compactage : poursuivez les longues exécutions

À mesure que les workflows s’allongent, ils se heurtent aux limites de la fenêtre de contexte. Le compactage côté serveur permet aux longues exécutions de se poursuivre en gérant la fenêtre de contexte et en compressant automatiquement l’historique de la conversation.

Le compactage dans l’API Responses vous offre deux façons de gérer cette situation :

• Compactage côté serveur (nouveau) : lorsque le contexte dépasse le seuil, le compactage s’exécute automatiquement dans le flux, sans appel de compactage distinct.
• Point de terminaison de compactage autonome : utilisez /responses/compact lorsque vous souhaitez contrôler explicitement le moment du compactage.

Pourquoi les combiner

• Les skills évitent l’enchevêtrement des prompts en regroupant les procédures stables et les exemples dans un ensemble réutilisable.
• Le shell fournit un environnement d’exécution complet qui vous permet d’installer du code, d’exécuter des scripts et d’écrire des résultats.
• Le compactage assure la continuité des longues exécutions : le même workflow peut ainsi se poursuivre sans remanier manuellement le contexte.
• Ensemble, ces éléments vous donnent des workflows reproductibles capables d’exécuter des tâches concrètes, sans transformer votre prompt système en un document démesuré et fragile.

Conseils et astuces

1) Rédigez les descriptions des skills comme une logique de routage (pas comme un texte marketing)

La description de votre skill détermine en pratique les critères de décision du modèle. Elle doit répondre aux questions suivantes :

• Quand dois-je l’utiliser ?
• Quand dois-je éviter de l’utiliser ?
• Quels sont les résultats attendus et les critères de réussite ?

Une approche pratique consiste à inclure directement dans la description un court bloc « Utilisez cette skill lorsque… / Ne l’utilisez pas lorsque… », en restant concret (entrées, outils utilisés, artefacts attendus).

2) Ajoutez des exemples négatifs et des cas limites pour réduire les erreurs de déclenchement

Un échec surprenant peut se produire : rendre des skills disponibles peut, dans un premier temps, réduire la fréquence des déclenchements corrects. Une solution que nous avons vue fonctionner consiste à ajouter des exemples négatifs et à couvrir les cas limites.

En pratique, cela revient à rédiger quelques cas explicites de type « N’appelez pas cette skill lorsque… », en précisant quoi faire à la place. Cela aide le modèle à choisir plus précisément la bonne skill, surtout lorsque plusieurs se ressemblent à première vue.

Glean l’a constaté directement : le routage fondé sur les skills a d’abord fait baisser les déclenchements d’environ 20 % dans des évaluations ciblées. Leur fréquence est ensuite remontée après l’ajout d’exemples négatifs et de cas limites dans les descriptions.

3) Placez les modèles de documents et les exemples dans la skill (leur coût est pratiquement nul lorsqu’ils ne sont pas utilisés)

Si vous surchargez le prompt système de modèles de documents, arrêtez.

Placer les modèles de documents et les exemples détaillés dans les skills présente deux avantages :

• Ils sont disponibles au moment précis où ils sont nécessaires (lorsque la skill est invoquée).
• Ils n’augmentent pas le nombre de tokens pour les requêtes sans rapport.

Cette approche est particulièrement efficace pour les livrables issus du travail intellectuel, comme :

• Les rapports structurés.
• Les synthèses du triage des escalades.
• Les plans de compte.
• Les comptes rendus d’analyse de données.

Glean indique que cette approche lui a apporté certains de ses gains les plus importants en matière de qualité et de latence en production, car ces exemples ne sont chargés que lorsque la skill se déclenche.

4) Prévoyez les longues exécutions dès le départ grâce à la réutilisation des conteneurs et au compactage

Les agents chargés de tâches de longue durée réussissent rarement à tout accomplir en une seule étape à partir d’un prompt. Prévoyez la continuité dès le départ :

• Réutilisez le même conteneur d’une étape à l’autre pour conserver des dépendances stables, les fichiers en cache et les résultats intermédiaires.
• Transmettez previous_response_id pour que le modèle puisse poursuivre le travail dans le même fil.
• Utilisez le compactage comme une primitive par défaut pour les longues exécutions, pas comme une solution de secours d’urgence.

Cette combinaison réduit les reprises à zéro et préserve la cohérence des tâches en plusieurs étapes à mesure que le fil s’allonge.

5) Lorsque vous avez besoin de déterminisme, demandez explicitement au modèle d’utiliser la skill

Par défaut, le modèle décide quand utiliser une skill. C’est souvent le comportement souhaité.

Mais lorsque vous exécutez un workflow en production avec un contrat clair (et que vous préférez le déterminisme à l’ingéniosité), dites simplement :

« Utilisez la skill <skill name>. »

C’est le moyen le plus simple d’améliorer la fiabilité. Vous remplacez ainsi un routage approximatif par un contrat explicite.

6) Considérez l’association des skills et du réseau comme une combinaison à haut risque (prévoyez le confinement dès la conception)

C’est un conseil de sécurité facile à négliger aujourd’hui, mais les problèmes qui en découlent seront difficiles à corriger plus tard.

Combiner des skills avec un accès réseau ouvert crée un risque élevé d’exfiltration de données. Si vous utilisez le réseau, maintenez des listes d’autorisation réseau strictes, considérez les sorties des outils comme non fiables et évitez d’associer un accès Internet ouvert à des procédures puissantes dans les parcours destinés au grand public, où les utilisateurs attendent des mécanismes de confirmation rigoureux.

Une configuration sûre par défaut :

• Skills : autorisés
• Shell : autorisé
• Réseau : activé uniquement avec une liste d’autorisation minimale, définie pour chaque requête, pour des tâches au périmètre restreint

7) Faites de /mnt/data le point de transfert de vos artefacts

Pour les workflows utilisant le shell distant, utilisez /mnt/data comme emplacement standard pour écrire les résultats que vous récupérerez, examinerez ou réutiliserez aux étapes suivantes. Il peut s’agir de rapports, de jeux de données nettoyés ou de feuilles de calcul finalisées.

Une façon simple de voir les choses : les outils écrivent sur le disque, les modèles raisonnent à partir des fichiers sur le disque et les développeurs y récupèrent les résultats.

8) Abordez les listes d’autorisation comme un système à deux niveaux (organisation et requête)

L’accès au réseau est contrôlé à deux niveaux :

• Une liste d’autorisation au niveau de l’organisation (configurée par un administrateur), qui définit l’ensemble des destinations pouvant être autorisées.
• Une politique network_policy au niveau de la requête, dont les destinations doivent être un sous-ensemble de la liste d’autorisation de l’organisation.

Deux conséquences importantes en pratique :

1. Gardez la liste d’autorisation de l’organisation restreinte et stable (l’ensemble des « destinations approuvées auxquelles vous faites confiance »).
2. Limitez encore davantage les listes d’autorisation des requêtes (l’ensemble des « destinations nécessaires à cette tâche précise »).

Si une requête inclut des domaines absents de la liste d’autorisation de l’organisation, elle échoue avec une erreur.

9) Utilisez domain_secrets pour les appels authentifiés (évitez les fuites d’identifiants)

Si un domaine autorisé nécessite des en-têtes d’authentification, utilisez domain_secrets pour que le modèle ne voie jamais les identifiants réels.

Lors de l’exécution, le modèle voit des espaces réservés (par exemple, $API_KEY), et un sidecar injecte les valeurs réelles uniquement pour les destinations approuvées. C’est une bonne pratique à adopter par défaut chaque fois que votre agent doit appeler une API protégée depuis un conteneur.

10) Utilisez les mêmes API dans le cloud et en local

Vous pouvez utiliser ces deux primitives sans devoir tout héberger :

• Les skills fonctionnent aussi bien avec le shell distant qu’en mode shell local.
• Le shell propose un mode d’exécution local dans lequel vous exécutez vous-même shell_call et renvoyez shell_call_output au modèle.
• Si vous utilisez l’Agents SDK, vous pouvez également intégrer votre propre moteur d’exécution shell.

Voici un cycle de développement pratique :

1. Commencez en local (itérations rapides, accès aux outils internes, débogage facile).
2. Passez aux conteneurs hébergés lorsque vous recherchez la reproductibilité, l’isolation et la cohérence des déploiements.
3. Conservez les mêmes skills dans les deux modes (le workflow reste stable même lorsque l’environnement d’exécution change).

Trois approches de développement

N’hésitez pas à expérimenter avec ces nouvelles primitives agentiques. Voici trois exemples de façons de les combiner pour créer des applications utiles.

Approche A : installez -> récupérez -> écrivez un artefact

C’est la façon la plus simple de tirer parti du shell distant : un agent installe des dépendances, récupère des données externes et produit un livrable concret.

Par exemple :

• Installez quelques bibliothèques.
• Extrayez des données de pages web ou appelez une API.
• Écrivez un rapport dans /mnt/data/report.md.

Cette approche est la base des agents qui accomplissent un travail concret, car elle crée un point de révision clair : votre application peut montrer l’artefact à l’utilisateur, le consigner, le comparer à une autre version ou l’utiliser à une étape ultérieure.

Approche B : skills + shell pour des workflows reproductibles

Une fois que vous aurez créé un ou deux workflows shell qui fonctionnent bien, vous rencontrerez le problème suivant : la solution fonctionne, mais sa fiabilité se dégrade à mesure que les prompts s’écartent de leur formulation initiale.

C’est là que les skills interviennent. Voici une structure pérenne à suivre :

1. Formalisez le workflow (étapes, garde-fous, modèles de documents) dans un skill.
2. Montez le skill dans votre environnement shell.
3. Demandez à l’agent de suivre le skill pour produire des artefacts de manière déterministe.

Cette approche est particulièrement efficace pour des workflows tels que :

• L’analyse ou la modification de feuilles de calcul.
• Le nettoyage de jeux de données et la génération de synthèses.
• La génération de rapports standardisés pour des processus métier récurrents.

Approche C (avancée) : les skills comme supports des workflows d’entreprise

Nous avons rapidement observé une perte de précision lors du passage de l’appel d’un seul outil à l’orchestration de plusieurs outils. Les skills peuvent combler cet écart en structurant davantage le raisonnement lié aux outils autour de procédures, sans alourdir les prompts système.

Un exemple concret chez Glean :

• Un skill dédié à Salesforce a fait passer la précision des évaluations de 73 % à 85 % et a réduit le délai avant le premier token de 18,1 %.
• Les techniques employées comprenaient un routage soigneusement défini, des contre-exemples et l’intégration de modèles de documents et d’exemples dans le skill.
• Glean utilise également les skills pour formaliser des tâches récurrentes dans les workflows d’entreprise, notamment la planification des comptes clients, le tri des demandes remontées et la génération de contenu conforme à l’identité de marque.

C’est là que cette approche révèle tout son potentiel. Les skills deviennent des procédures opérationnelles standard (SOP) vivantes : mises à jour au fil de l’évolution de votre organisation et exécutées de manière cohérente par les agents.

Développez une fois, exécutez partout

Les agents qui exécutent des tâches de longue durée deviennent beaucoup plus utiles lorsqu’ils peuvent à la fois suivre des procédures et accomplir un travail concret sur un ordinateur. Les skills, le shell distant et le compactage constituent cette base. En résumé :

• Utilisez les skills pour formaliser la méthode (procédures, modèles de documents, garde-fous).
• Utilisez le shell pour passer à l’action (installer, exécuter, écrire des artefacts).
• Utilisez le compactage pour préserver la cohérence des exécutions de longue durée (sans gérer le contexte manuellement).
• Commencez en local lorsque vous voulez itérer rapidement.
• Passez aux conteneurs hébergés lorsque vous souhaitez une exécution reproductible et isolée.
• Restreignez strictement l’accès au réseau avec des listes d’autorisation au niveau de l’organisation et de chaque requête, et utilisez des secrets associés aux domaines pour les appels authentifiés.

Lancez-vous dans votre propre application. Consultez la documentation sur les skills, la documentation sur le shell et la documentation sur le compactage pour découvrir comment procéder.