Les harnais allégés et les agents qui exécutent du code conviennent mieux aux tâches ouvertes, où une orchestration trop rigide peut limiter les performances du modèle.
L’exécution de code et la mise en bac à sable sont donc désormais au cœur de l’architecture des systèmes agentiques.
Dans nos essais, le SDK Agents réduit jusqu’à six fois la complexité et la quantité de code nécessaires pour créer des agents qui exécutent du code.
Pendant longtemps, les progrès des systèmes d’agents ont découlé d’une meilleure orchestration : formulation d’invites, interfaces d’outils, gestion du contexte et flux de contrôle plus stricts. Mais à mesure que les agents de programmation gagnent en capacité, cet équilibre commence à changer.
Dans de nombreux flux de travail ouverts, le goulot d’étranglement n’est plus la boucle de l’agent, mais la couche d’exécution : le bac à sable où le modèle écrit du code, exécute des commandes, examine les résultats et recommence. À mesure que le raisonnement propre à la tâche migre vers cet environnement, l’orchestration qui l’entoure doit se simplifier pour permettre au modèle d’exprimer toutes ses capacités.
C’est précisément ce que permet la nouvelle version du SDK Agents. Lors de nos essais en accès anticipé, nous avons constaté qu’au lieu d’ajouter une autre couche de logique d’infrastructure, elle rend la couche d’exécution plus modulaire et composable afin que le reste du système demeure léger.
En ingénierie de harnais, la tendance est de réduire le harnais à sa forme efficace minimale. À un niveau général, le harnais est le logiciel qui entoure le modèle : la couche qui gère le contexte, les outils, le flux de contrôle et les boucles de rétroaction afin que le modèle puisse travailler de façon fiable.
Au cours des dernières années, de nombreuses améliorations des performances des agents sont venues du renforcement de cette couche. De meilleurs outils, une mémoire et une récupération améliorées, une décomposition plus explicite et une orchestration plus stricte ont souvent rendu les systèmes plus fiables et performants. Dans ce paradigme, progresser consistait surtout à intégrer davantage de logique propre à la tâche dans le logiciel entourant le modèle.
Cette tendance s’atténue maintenant, du moins pour une catégorie de tâches ouvertes. Un nombre croissant de projets et d’articles suggèrent que les performances ne s’améliorent pas toujours lorsque le harnais devient plus directif. Pour la programmation assistée, les tâches de longue durée, l’utilisation du navigateur et les tâches à long contexte, la même tendance revient : une fois le modèle suffisamment intelligent, imposer trop de structure à la tâche dans le logiciel environnant peut devenir une contrainte plutôt qu’un avantage.
Le rôle du harnais évolue donc. Au lieu de tenter d’anticiper la tâche par une orchestration rigide, le harnais sert de plus en plus à fournir une surface d’exécution claire : un bac à sable où le modèle peut examiner l’état, exécuter du code, récupérer après une erreur et adapter sa démarche, tout en respectant les interfaces et les mesures de protection du système. Ce changement se rapproche de celui décrit par Andrej Karpathy dans Ingénieur logiciel 3.0 : une partie de la logique qui résidait auparavant dans le logiciel remonte dans « l’invite ».
Il ne faut pas en conclure que les systèmes d’agents doivent éliminer toute structure. De nombreuses tâches profitent encore de flux de travail explicites, d’heuristiques et de garde-fous déterministes, surtout lorsqu’elles sont ciblées, volumineuses ou assorties d’un critère de réussite clair. Comme nous l’expliquions dans notre précédent article sur les heuristiques de conception des systèmes agentiques, une orchestration robuste demeure importante lorsqu’un flux logique fiable est à la fois possible et souhaitable.
Pour les tâches ouvertes, l’accent se déplace. Le défi consiste moins à concevoir des couches d’orchestration toujours plus élaborées qu’à créer des environnements d’exécution assez simples, observables et modulaires pour que le modèle y travaille efficacement.
Dès qu’un agent peut lire des fichiers, écrire du code, exécuter des commandes d’interpréteur et lancer des tâches de longue durée, le défi d’ingénierie change. La difficulté ne se limite plus à optimiser les invites ou l’acheminement vers les outils. Le fait que l’agent fonctionne maintenant sur un système réel rend ces agents beaucoup plus puissants, mais aussi plus sensibles, car leur surface de sûreté et de sécurité est plus vaste. Par exemple, un agent capable d’exécuter du code peut poser des gestes nuisibles si son environnement est mal isolé (voir le banc d’essai Sandbox Bench de l’AISI).
La mise en bac à sable devient donc un enjeu crucial pour les infrastructures d’agents. Dans les systèmes antérieurs, l’exécution était souvent considérée comme un ajout : un outil greffé au harnais. Mais dès que l’exécution devient persistante, distante ou de longue durée, cette approche commence à montrer ses limites. La gestion du bac à sable, de son cycle de vie, de son état, de ses interfaces et de son articulation avec la boucle de l’agent devient rapidement un problème de conception de système à part entière. C’est notamment pourquoi un nombre croissant de fournisseurs proposent maintenant des environnements gérés pour l’exécution de code, dont l’API Container et l’outil d’interpréteur d’OpenAI, Modal, Cloudflare, Daytona et E2B.
Cette frontière est importante, car l’exécution de code exige une isolation renforcée et un contrôle d’exécution plus strict que le reste du harnais. En pratique, des agents exécutant du code qui sont mal mis en œuvre peuvent créer trois risques critiques pour l’entreprise : des dépenses informatiques incontrôlées, des actions destructrices sur les systèmes internes et l’exposition de renseignements sensibles. Grâce à une conteneurisation, à une isolation et à des mesures de protection adéquates à l’exécution, ces risques peuvent être ramenés à un niveau acceptable pour les déploiements réels.
On peut se représenter la situation comme si l’on donnait à l’agent son propre espace de travail scellé plutôt que les clés de tout le bureau. Il peut tout de même accomplir du travail utile dans cet espace, mais seulement à l’intérieur de limites clairement définies. Vous pouvez plafonner ses ressources informatiques, limiter les systèmes et les fichiers auxquels il peut toucher et contrôler les renseignements auxquels il a accès dès le départ.
Cela n’élimine pas entièrement le risque, mais transforme le problème : plutôt qu’« un agent en liberté dans votre infrastructure », vous avez « un agent qui fonctionne dans un environnement contrôlé ». Si cette couche doit devenir une composante standard des systèmes d’agents, elle doit être prise en charge comme une fonction de premier ordre dans l’infrastructure elle-même. Le bac à sable devient ainsi une couche d’exécution modulaire dotée de primitives portables que les développeurs peuvent adopter rapidement, transférer entre fournisseurs et mettre à l’échelle sans constamment remanier la logique de l’agent.
Dès qu’un agent exécute du code, le bac à sable doit lui-même être orchestré. Passer d’une démonstration de faisabilité locale à une exécution distante, à plusieurs systèmes dorsaux ou à des sessions de longue durée augmente exponentiellement la charge opérationnelle. Il faut une méthode cohérente pour créer et arrêter les environnements, les mettre en pause et les reprendre, enregistrer des instantanés de leur état, s’y reconnecter plus tard et gérer le tout chez différents fournisseurs.
Rien de tout cela n’est particulièrement prestigieux sur le plan conceptuel, mais c’est important en pratique. C’est exactement le type d’infrastructure qui devient pénible lorsque chaque équipe reconstruit de zéro un pipeline agentique, surtout s’il n’est pas intégré à l’infrastructure d’agents…
C’est ici qu’une meilleure prise en charge par l’infrastructure devient importante. Nous avons obtenu un accès anticipé au nouveau SDK Agents d’OpenAI et l’avons utilisé pour créer nos propres agents en bac à sable. Le changement de priorité architecturale était frappant : le SDK traite l’exécution comme une couche de premier ordre plutôt que comme un outil périphérique. En pratique, vous pouvez lancer un agent en bac à sable, créer un instantané d’un bac à sable ou reprendre l’exécution avec moins de code (environ six fois moins dans certains de nos essais), puis changer de système dorsal sans réécrire la logique environnante de l’agent.
Cette séparation plus nette des responsabilités permet au harnais de rester axé sur le raisonnement, le contexte et le flux de travail. La couche d’exécution peut se concentrer sur l’isolation, la portabilité et l’état d’exécution. Cette abstraction facilite la création d’agents de programmation plus performants et plus faciles à faire évoluer, capables de passer d’une exécution locale à distante, de prendre en charge des tâches prolongées et de changer de système dorsal d’exécution sans imposer une refonte de tout le système.
À mesure que la logique propre à la tâche passe du harnais au modèle, une partie de la complexité du système la suit et descend dans la couche d’exécution. L’exécution de code et la mise en bac à sable sont désormais au cœur de l’architecture des systèmes agentiques, surtout pour les tâches ouvertes et à forte composante de programmation. Il est maintenant aussi important de concevoir le pipeline agentique que l’environnement dans lequel l’agent peut agir de façon sûre, fiable et durable.
C’est pourquoi les abstractions de haut niveau entourant l’exécution en bac à sable sont importantes. Le nouveau SDK Agents d’OpenAI va dans cette direction en traitant l’exécution comme une couche modulaire du système : portable entre les systèmes dorsaux, persistante pendant les tâches de longue durée et assez simple à utiliser sans reconstruire la même infrastructure pour chaque nouvelle configuration.
Plus généralement, la prochaine génération d’infrastructures d’agents se distinguera probablement moins par la quantité de logique d’orchestration ajoutée que par la qualité de la structure des environnements d’exécution dont les agents dépendent de plus en plus.