OpenAI révolutionne la gouvernance avec son SDK en bac à sable

OpenAI introduit l'exécution en bac à sable pour une gouvernance améliorée

OpenAI a récemment dévoilé une nouvelle fonctionnalité d'exécution en bac à sable dans son SDK des agents, une avancée qui permet aux équipes de gouvernance d'entreprise de déployer des flux de travail automatisés tout en maintenant un contrôle rigoureux des risques. Cette innovation répond à un besoin crucial pour les entreprises qui passent des phases de prototypage à la production, souvent confrontées à des choix difficiles concernant l'architecture de leurs opérations.

Traditionnellement, les entreprises utilisaient des cadres agnostiques aux modèles pour bénéficier d'une flexibilité initiale, mais ces cadres ne parvenaient pas à exploiter pleinement les capacités des modèles avancés. Les SDK fournis par les éditeurs de modèles restaient proches du modèle de base, mais manquaient souvent de visibilité suffisante sur le cadre de contrôle. Les API d'agents gérées simplifiaient le déploiement, mais limitaient sévèrement l'emplacement et la manière dont les systèmes accédaient aux données sensibles.

Pour remédier à ces limitations, OpenAI a introduit de nouvelles capacités dans son SDK des agents, offrant aux développeurs une infrastructure standardisée avec un cadre natif au modèle et une exécution en bac à sable intégrée. Cette mise à jour aligne l'exécution avec le modèle opérationnel naturel des modèles sous-jacents, améliorant ainsi la fiabilité des tâches nécessitant une coordination entre divers systèmes.

Oscar Health et l'efficacité des données non structurées

Oscar Health, un fournisseur de soins de santé, illustre l'efficacité de cette nouvelle infrastructure en l'appliquant à l'automatisation d'un flux de travail de dossiers cliniques. Les approches antérieures ne pouvaient pas gérer ce processus de manière fiable. L'équipe d'ingénierie d'Oscar Health a exigé que le système automatisé puisse extraire correctement les métadonnées tout en comprenant les limites des rencontres des patients dans des fichiers médicaux complexes.

Grâce à l'automatisation de ce processus, Oscar Health a pu analyser plus rapidement les antécédents des patients, accélérant ainsi la coordination des soins et améliorant l'expérience globale des membres. Rachael Burns, ingénieure principale et responsable technique IA chez Oscar Health, a déclaré que le SDK mis à jour a rendu viable l'automatisation d'un flux de travail critique que les approches précédentes ne pouvaient pas gérer de manière suffisamment fiable.

Optimisation des flux de travail IA avec un cadre natif au modèle

Pour déployer ces systèmes, les ingénieurs doivent gérer la synchronisation des bases de données vectorielles, contrôler les risques d'hallucination et optimiser les cycles de calcul coûteux. Sans cadres standard, les équipes internes ont souvent recours à la construction de connecteurs fragiles sur mesure pour gérer ces flux de travail.

Le nouveau cadre natif au modèle aide à atténuer cette friction en introduisant une mémoire configurable, une orchestration consciente du bac à sable et des outils de système de fichiers similaires à Codex. Les développeurs peuvent intégrer des primitives standardisées, telles que l'utilisation d'outils via MCP, des instructions personnalisées via AGENTS.md, et des modifications de fichiers à l'aide de l'outil apply patch.

La divulgation progressive via des compétences et l'exécution de code à l'aide de l'outil shell permet également au système d'effectuer des tâches complexes de manière séquentielle. Cette standardisation permet aux équipes d'ingénierie de passer moins de temps à mettre à jour l'infrastructure de base et de se concentrer sur la création de logique spécifique au domaine qui profite directement à l'entreprise.

Intégration fluide avec les systèmes de stockage majeurs

L'intégration d'un programme autonome dans une pile technologique héritée nécessite un routage précis. Lorsqu'un processus autonome accède à des données non structurées, il s'appuie fortement sur des systèmes de récupération pour extraire le contexte pertinent.

Pour gérer l'intégration de diverses architectures et limiter la portée opérationnelle, le SDK introduit une abstraction de manifeste. Cette abstraction standardise la manière dont les développeurs décrivent l'espace de travail, leur permettant de monter des fichiers locaux et de définir des répertoires de sortie.

Les équipes peuvent connecter ces environnements directement aux principaux fournisseurs de stockage d'entreprise, y compris AWS S3, Azure Blob Storage, Google Cloud Storage et Cloudflare R2. Établir un espace de travail prévisible donne au modèle des paramètres exacts sur l'endroit où localiser les entrées, écrire les sorties et maintenir l'organisation pendant de longues exécutions opérationnelles.

Renforcement de la sécurité avec l'exécution en bac à sable native

Le SDK prend en charge nativement l'exécution en bac à sable, offrant une couche prête à l'emploi pour que les programmes puissent s'exécuter dans des environnements informatiques contrôlés contenant les fichiers et dépendances nécessaires. Les équipes d'ingénierie n'ont plus besoin de rassembler manuellement cette couche d'exécution. Elles peuvent déployer leurs propres bacs à sable personnalisés ou utiliser le support intégré pour des fournisseurs tels que Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop et Vercel.

L'atténuation des risques reste la principale préoccupation pour toute entreprise déployant l'exécution de code autonome. Les équipes de sécurité doivent supposer que tout système lisant des données externes ou exécutant du code généré sera confronté à des attaques par injection de prompt et à des tentatives d'exfiltration.

OpenAI aborde cette exigence de sécurité en séparant le cadre de contrôle de la couche de calcul. Cette séparation isole les identifiants, les tenant complètement à l'écart des environnements où le code généré par le modèle s'exécute. En isolant la couche d'exécution, une commande malveillante injectée ne peut pas accéder au plan de contrôle central ni voler les clés API principales, protégeant ainsi le réseau d'entreprise plus large contre les attaques de mouvement latéral.

Cette séparation aborde également les problèmes de coût de calcul liés aux pannes système. Les tâches de longue durée échouent souvent en cours de route en raison de délais d'attente réseau, de pannes de conteneurs ou de limites d'API. Si un agent complexe prend vingt étapes pour compiler un rapport financier et échoue à l'étape dix-neuf, relancer toute la séquence consomme des ressources de calcul coûteuses.

Si l'environnement plante sous la nouvelle architecture, perdre le conteneur de bac à sable ne signifie pas perdre l'ensemble de l'exécution opérationnelle. Étant donné que l'état du système reste externalisé, le SDK utilise un instantané intégré et une réhydratation. L'infrastructure peut restaurer l'état dans un nouveau conteneur et reprendre exactement à partir du dernier point de contrôle si l'environnement d'origine expire ou échoue. Éviter la nécessité de redémarrer des processus coûteux et de longue durée se traduit directement par une réduction des dépenses de calcul dans le cloud.

La mise à l'échelle de ces opérations nécessite une allocation dynamique des ressources. L'architecture séparée permet aux exécutions d'invoquer un ou plusieurs bacs à sable en fonction de la charge actuelle, de diriger des sous-agents spécifiques dans des environnements isolés et de paralléliser des tâches sur plusieurs conteneurs pour des temps d'exécution plus rapides.

Ces nouvelles capacités sont généralement disponibles pour tous les clients via l'API, utilisant une tarification standard basée sur les tokens et l'utilisation d'outils sans exiger de contrats d'approvisionnement personnalisés. Les nouvelles capacités de cadre et de bac à sable sont lancées en premier pour les développeurs Python, avec un support TypeScript prévu pour une future version.

OpenAI prévoit d'apporter des capacités supplémentaires, y compris le mode code et les sous-agents, aux bibliothèques Python et TypeScript. Le fournisseur a l'intention d'élargir l'écosystème plus large au fil du temps en soutenant des fournisseurs de bac à sable supplémentaires et en offrant plus de méthodes pour que les développeurs intègrent directement le SDK dans leurs systèmes internes existants.