Sur la base des retours des développeurs et de notre propre expérience en matière de développement de Codex et d'agents internes, nous publions un nouvel ensemble de primitives d'agent qui rendent le travail à long terme plus pratique :
Compétences (alignées sur la norme ouverte Agent Skills) : instructions réutilisables et versionnées que vous pouvez monter dans des conteneurs afin que les agents puissent exécuter des tâches de manière plus fiable.
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 sorties (par exemple, des rapports et des artefacts).
Compactage côté serveur : un moyen simple de compacter automatiquement les longues exécutions d’agents afin de ne jamais atteindre les limites de contexte.
La documentation et la référence API traitent chaque point ci-dessus individuellement. Cet article se concentre sur les astuces et les modèles moins évidents qui se sont avérés les plus efficaces jusqu'à présent, tant dans le cadre de nos travaux chez OpenAI qu'en production chez Glean, un de nos premiers clients ayant utilisé nos services de compétences.
Un bref modèle mental
Compétences : « Procédures » que le modèle peut charger à la demande
Une compétence est un ensemble de fichiers, accompagné d'un SKILL.mdmanifeste contenant les métadonnées et les instructions. Imaginez : un manuel de procédures versionné que le modèle peut consulter lorsqu'il s'agit de passer à l'action.
nameLorsque des compétences sont disponibles, la plateforme expose les métadonnées de chaque compétence descriptionau pathmodèle. Ce dernier utilise ces métadonnées pour déterminer s'il convient d'appeler une compétence. Le cas échéant, il analyse SKILL.mdle flux de travail complet.
Outil Shell : « Exécution » pour les agents
L'outil shell permet aux modèles de fonctionner dans un véritable environnement de terminal, soit :
Conteneurs hébergés et gérés par OpenAI.
Un environnement d'exécution shell local que vous exécutez vous-même (même sémantique d'outil, mais vous contrôlez la machine).
Le shell hébergé s'exécute via l'API Responses, ce qui signifie que vos requêtes incluent des opérations avec état, des appels d'outils, une continuation multi-tours et des artefacts.
Compactage : Maintenez le mouvement des longues pistes
À mesure que les flux de travail s'allongent, ils atteignent les limites de la fenêtre de contexte. La compression côté serveur permet de fluidifier les longs traitements en gérant la fenêtre de contexte et en compressant automatiquement l'historique des conversations.
La fonction de compactage de l'API Responses vous offre deux façons de gérer cela :
Compactage côté serveur (nouveau) : lorsque le contexte dépasse le seuil, le compactage s’exécute automatiquement en flux continu, il n’y a donc pas d’appel de compactage séparé.
Point de terminaison compact autonome : à utiliser /responses/compactlorsque vous souhaitez un contrôle explicite sur le moment où la compaction a lieu.
Pourquoi ils sont mieux ensemble
Les compétences réduisent la complexité des instructions en regroupant les procédures et exemples stables dans un ensemble réutilisable.
Shell fournit un environnement d'exécution complet, vous permettant d'installer du code, d'exécuter des scripts et d'écrire des résultats.
La compaction préserve la continuité sur les longues exécutions, permettant ainsi au même flux de travail de continuer à s'exécuter sans intervention manuelle sur le contexte.
Ensemble, vous obtenez des flux de travail reproductibles avec une exécution réelle, sans transformer l'invite de commande de votre système en un méga-document fragile.
Conseils et astuces
1) Rédigez des descriptions de compétences telles que la logique de routage (et non un texte marketing).
La description de votre compétence constitue en fait la limite de décision du modèle. Elle doit répondre à la question suivante :
Quand dois-je utiliser ceci ?
Quand ne dois-je pas utiliser ceci ?
Quels sont les résultats attendus et les critères de réussite ?
Une méthode pratique consiste à inclure un court bloc « À utiliser quand / À ne pas utiliser quand » directement dans la description, et à le rendre concret (entrées, outils impliqués, artefacts attendus).
2) Ajouter des exemples négatifs et des cas limites pour réduire les erreurs de détection.
Un mode de défaillance surprenant est que la mise à disposition des compétences peut initialement réduire le déclenchement correct. Une solution qui s'est avérée efficace consiste à utiliser des exemples négatifs et à couvrir les cas limites.
Concrètement, cela implique de rédiger quelques cas explicites du type « Ne pas appeler cette compétence lorsque… » (et les alternatives). Cela permet un routage plus clair du modèle, notamment lorsqu'il existe plusieurs compétences qui se ressemblent au premier coup d'œil.
Glean l'a constaté directement : le routage basé sur les compétences a initialement fait chuter le déclenchement d'environ 20 % dans les évaluations ciblées, puis s'est rétabli après l'ajout d'exemples négatifs et d'une couverture des cas limites dans les descriptions.
3) Intégrez des modèles et des exemples dans la compétence (ils sont pratiquement gratuits lorsqu'ils ne sont pas utilisés).
Si vous avez l'habitude d'insérer des modèles dans l'invite de commandes système, arrêtez.
Les modèles et les exemples concrets intégrés aux compétences présentent deux avantages :
Elles sont disponibles précisément au moment opportun (lorsque la compétence est activée).
Ils n'ajoutent pas de jetons pour les requêtes non liées.
Cela est particulièrement efficace pour les résultats du travail intellectuel, comme :
Rapports structurés.
Résumés de triage en cas d'escalade.
Formules de compte.
Rédaction des analyses de données.
Glean a indiqué que ce modèle avait permis d'obtenir certains de leurs plus importants gains en termes de qualité et de latence en production, car ces exemples ne sont chargés que lorsque la compétence se déclenche.
4) Concevoir dès le départ des installations pour de longues durées de vie, avec réutilisation et compactage des conteneurs.
Les agents à long terme fonctionnent rarement comme des incitations ponctuelles. Prévoyez la continuité dès le départ :
Réutilisez le même conteneur entre les étapes lorsque vous souhaitez des dépendances stables, des fichiers mis en cache et des sorties intermédiaires.
Transmettez cette instruction previous_response_idafin que le modèle puisse continuer à fonctionner dans le même thread.
Utilisez la compaction comme une primitive par défaut à long terme, et non comme une solution de repli d'urgence.
Cette combinaison réduit les redémarrages et assure la cohérence des tâches en plusieurs étapes à mesure que le thread s'étend.
5) Lorsque vous avez besoin de déterminisme, indiquez explicitement au modèle d'utiliser la compétence
Par défaut, le modèle décide quand utiliser une compétence. C'est souvent ce que l'on souhaite.
Mais lorsque vous gérez un flux de production avec un contrat clair (et que vous préférez être déterministe plutôt qu'ingénieux), dites simplement :
«Utilisez vos
C'est le levier de fiabilité le plus simple à actionner. Il transforme le routage flou en un contrat explicite.
6) Considérer les compétences et le réseautage comme une combinaison à haut risque (conception pour contenir les risques)
Voici un conseil de sécurité qu'il est facile de négliger maintenant et difficile de corriger plus tard.
L'association de compétences et d'un accès réseau ouvert crée un risque élevé d'exfiltration de données. Si vous utilisez le réseau, veillez à la stricte conformité de vos listes d'autorisation, considérez que les résultats des outils ne sont pas fiables et évitez l'accès à Internet ouvert ainsi que les procédures complexes dans les parcours clients où ces derniers exigent des contrôles de confirmation rigoureux.
Une posture par défaut forte :
Compétences : autorisées
Shell : autorisé
Réseau : activé uniquement avec une liste blanche minimale , par requête, pour des tâches à portée limitée.
7) Définissez /mnt/datavotre limite de transfert pour les artefacts
Pour les flux de travail en ligne de commande hébergée, considérez-les /mnt/datacomme l'emplacement standard pour écrire les résultats que vous récupérerez, examinerez ou réutiliserez dans les étapes suivantes. Il peut s'agir, par exemple, de rapports, d'ensembles de données nettoyés et de feuilles de calcul finalisées.
Un bon modèle mental : les outils écrivent sur le disque, les modèles raisonnent sur le disque, les développeurs récupèrent les données du disque.
8) Comprendre les listes blanches comme un système à deux niveaux (niveau de l'organisation et niveau de la requête)
Le réseau est contrôlé à deux endroits :
Une liste blanche au niveau de l'organisation (configurée par un administrateur), qui définit le nombre maximal de destinations autorisées.
Une requête de niveau network_policyqui doit être un sous-ensemble de la liste blanche de l'organisation.
Deux implications importantes sur le plan opérationnel :
Limitez la liste blanche de l'organisation à une taille réduite et à une stabilité optimale (l'ensemble des « destinations approuvées auxquelles vous faites confiance »).
Réduisez encore la taille des listes d'autorisation des requêtes (l'ensemble des « destinations nécessaires pour cette tâche »).
Si une requête inclut des domaines ne figurant pas sur la liste blanche de l'organisation, une erreur sera générée.
9) À utiliser domain_secretspour les appels authentifiés (éviter les fuites d'informations d'identification)
Si un domaine autorisé nécessite des en-têtes d'authentification, utilisez-les domain_secretsafin que le modèle ne voie jamais les informations d'identification brutes.
Lors de l'exécution, le modèle détecte des espaces réservés (par exemple, `
10) Utilisez les mêmes API dans le cloud et en local.
Vous pouvez utiliser les deux primitives sans vous engager à tout héberger :
Ces compétences fonctionnent en mode shell hébergé et en mode shell local.
Shell possède un mode d'exécution local où vous vous exécutez shell_callvous-même et revenez shell_call_outputensuite au modèle.
Si vous utilisez le kit de développement logiciel Agents (SDK), vous pouvez également intégrer votre propre exécuteur de commandes shell.
Un cycle de développement pratique ressemble à ceci :
Démarrage local (itération rapide, accès aux outils internes, débogage facile).
Passez aux conteneurs hébergés lorsque vous souhaitez garantir la reproductibilité, l'isolation et la cohérence du déploiement.
Conserver les mêmes compétences dans les deux modes (le flux de travail reste stable même lorsque l'exécution change).
Trois modèles de construction
N'hésitez pas à expérimenter avec ces nouvelles primitives d'agents ; voici trois exemples de leur combinaison pour créer des applications utiles.
Modèle A : Installation -> récupération -> écriture de l’artefact
Voici la manière la plus simple de tirer parti d'un shell hébergé : un agent installe les dépendances, récupère les données externes et produit un livrable concret.
Par exemple:
Installez quelques bibliothèques.
Extraire des données ou appeler une API.
Rédigez un rapport à /mnt/data/report.md.
Ce modèle constitue la base des agents de travail réel car il crée une limite de révision claire : votre application peut afficher l’artefact à l’utilisateur, l’enregistrer, le comparer ou l’intégrer à une étape ultérieure.
Modèle B : Compétences + structure pour des flux de travail reproductibles
Une fois que vous aurez mis en place un ou deux flux de travail shell fonctionnels, vous remarquerez le problème suivant : cela fonctionne, mais la fiabilité se dégrade lorsque les invites dérivent.
C’est là que les compétences entrent en jeu. Voici une structure solide à suivre :
Encodez le flux de travail (étapes, garde-fous, modèles) dans une compétence.
Intégrez cette compétence dans votre environnement shell.
Faites en sorte que l'agent utilise la compétence pour produire des artefacts de manière déterministe.
Cela est particulièrement efficace pour des flux de travail comme :
Analyse ou modification de feuilles de calcul.
Nettoyage des données et génération de résumés.
Génération de rapports standardisés pour les processus métier récurrents.
Modèle C (avancé) : Compétences en tant que vecteurs de flux de travail d’entreprise
L'une des premières tendances observées est une perte de précision entre l'utilisation d'un outil unique et son orchestration multiple. Les compétences permettent de combler cet écart en rendant le raisonnement sur les outils plus procédural, sans pour autant surcharger les invites système.
Un exemple concret tiré de Glean :
Une compétence axée sur Salesforce a augmenté la précision de l'évaluation de 73 % à 85 % et a réduit le temps d'obtention du premier jeton de 18,1 % .
Les tactiques pratiques incluaient un routage soigné, des exemples négatifs et l'intégration de modèles/exemples au sein de la compétence.
Glean utilise également ses compétences pour intégrer les tâches récurrentes dans les flux de travail d'entreprise, notamment la planification des comptes, le triage des escalades et la génération de contenu aligné sur la marque.
C’est là que les choses prennent toute leur importance. Les compétences deviennent des procédures opérationnelles standard (POS) vivantes : mises à jour au fur et à mesure de l’évolution de votre organisation et appliquées de manière cohérente par les agents.
Construisez une fois, exécutez partout
Les agents fonctionnant en continu deviennent nettement plus utiles lorsqu'ils peuvent à la fois suivre des procédures et effectuer un travail concret sur un ordinateur. Les compétences, le shell hébergé et la compaction constituent cette base. En résumé :
Utiliser ses compétences pour coder le comment (procédures, modèles, garde-fous).
Utilisez le shell pour exécuter la commande (installer, exécuter, écrire les artefacts).
Utilisez la compaction pour maintenir la cohérence des longues séquences (sans gestion manuelle du contexte).
Commencez localement lorsque vous itérez rapidement.
Passez aux conteneurs hébergés lorsque vous souhaitez une exécution reproductible et isolée.
Sécurisez le réseau grâce à des listes blanches au niveau de l'organisation et des requêtes, et utilisez des secrets de domaine pour les appels authentifiés.
Commencez par créer votre propre application. Consultez la documentation sur les compétences , la documentation du shell et la documentation sur la compaction pour en savoir plus.