De l’interpréteur de code à l’ordinateur agent : pourquoi les agents ont besoin de sandboxes avec état

Les agents ont besoin de sandboxes avec état lorsqu’une tâche nécessite des fichiers persistants, des dépendances installées, un accès au navigateur ou à un aperçu, des commandes longues, et une révision reproductible des résultats au-delà d’une simple exécution de code. Un interpréteur de code reste utile pour les calculs limités, les graphiques et les scripts ponctuels. Dès qu’un agent doit modifier un dépôt, relancer un test qui échoue, conserver des artefacts générés, inspecter une interface web ou remettre le travail à un humain, il a besoin de quelque chose qui se rapproche davantage d’un espace de travail ou d’un ordinateur agent.

Qu’est-ce qui a changé entre l’interpréteur de code et l’ordinateur agent ?

Les premières fonctionnalités d’« interpréteur de code » résolvaient un problème étroit mais important : permettre à un modèle d’écrire et d’exécuter du code, généralement Python, sur des fichiers attachés à une conversation. Cela suffit pour de nombreuses tâches de données. Un utilisateur peut télécharger un CSV, demander une transformation, obtenir un graphique et télécharger le résultat.

Le travail des agents couvre une surface plus large. Un agent de codage peut avoir besoin de cloner un projet, d’installer des dépendances, de modifier des fichiers, d’exécuter des tests, d’inspecter des logs, de lancer un serveur de développement, d’ouvrir un aperçu, de corriger le résultat et de conserver l’état suffisamment longtemps pour qu’un réviseur vérifie ce qui a changé. Un agent navigateur peut avoir besoin de cookies, de fichiers téléchargés, de captures d’écran, de l’état du DOM et d’un moyen de rejouer une étape qui a échoué. Un agent de recherche ou d’évaluation peut avoir besoin de centaines de workers isolés qui conservent les artefacts et les logs pour une inspection ultérieure.

C’est pourquoi le vocabulaire évolue :

• Interpréteur de code désigne un outil d’exécution géré pour des scripts courts et des sorties générées.
• Sandbox désigne un environnement isolé où du travail non fiable ou généré par un agent peut s’exécuter loin du système hôte.
• Espace de travail désigne un environnement basé sur des fichiers où l’état de la tâche peut s’accumuler entre les étapes.
• Ordinateur agent désigne un environnement d’exécution plus complet avec des fichiers, des commandes, des packages, un accès au navigateur ou à l’interface utilisateur, des logs, des aperçus, des artefacts, des contrôles de cycle de vie et des options de réinitialisation ou d’instantané.

Ces termes se chevauchent. La distinction utile n’est pas une question de marque ; c’est la quantité d’état et de surface de révision dont l’agent a besoin.

Que signifient les termes fondamentaux ?

Concept	Rôle principal	Modèle d’état typique	Meilleure adaptation
Interpréteur de code	Exécuter le code généré et renvoyer les résultats	État de session de courte durée	Calculs, transformations de fichiers, graphiques, petits scripts
Sandbox	Isoler l’exécution de l’hôte et des autres sessions	Éphémère ou persistante	Exécution de code non fiable, exécution de commandes, automatisation du navigateur
Espace de travail	Conserver les fichiers et le contexte de l’environnement ensemble	Système de fichiers persistant ou image restaurable	Agents de codage, projets de données, transfert de tâche, révision reproductible
Ordinateur agent	Donner à un agent un environnement de tâche avec des outils et des contrôles de cycle de vie	Environnement d’exécution avec état, logs, artefacts, aperçus et chemins de réinitialisation/instantané	Tâches logicielles en plusieurs étapes, agents navigateurs, évaluations, workflows de longue durée

Un même produit peut couvrir plusieurs cases. Une sandbox avec état peut se comporter comme un espace de travail. Un espace de travail avec terminal, navigateur, artefacts et gestion du cycle de vie commence à ressembler à un ordinateur agent. La question d’évaluation est de savoir ce que l’agent peut faire, quel état subsiste et avec quelle fiabilité les humains peuvent inspecter ou réinitialiser le résultat.

Quand l’exécution de code éphémère est-elle suffisante ?

L’exécution éphémère reste le bon choix par défaut lorsque la tâche est petite, limitée et facile à vérifier à partir du résultat final.

Utilisez un environnement de type interpréteur de code à courte durée de vie lorsque :

• Les fichiers d’entrée sont fournis au départ.
• La tâche peut être terminée en une ou quelques exécutions de script.
• Le résultat est un graphique, un tableau, un fichier transformé ou un calcul.
• Aucune installation de package au-delà de l’environnement géré n’est requise.
• L’utilisateur n’a pas besoin d’inspecter une application en cours d’exécution, l’état du navigateur ou un long journal de commandes.
• La session peut être supprimée une fois la réponse fournie.

Par exemple, un analyste du support qui demande à un assistant de regrouper les tickets par catégorie n’a pas besoin d’un espace de travail persistant. Un analyste de données qui demande une visualisation ponctuelle n’a peut-être pas besoin d’un accès au navigateur ou d’instantanés. Ajouter plus d’infrastructure que nécessaire peut rendre la gestion du cycle de vie, les coûts et la révision de sécurité plus difficiles.

Quand les agents ont-ils besoin d’une sandbox avec état ?

Les sandboxes avec état deviennent importantes lorsque l’agent ne se contente pas de calculer une réponse, mais opère à travers un workflow.

Les fichiers doivent survivre à plusieurs étapes

Les agents créent souvent des fichiers intermédiaires : données sources téléchargées, code généré, fixtures de test, artefacts de build, captures d’écran, rapports et logs. Si chaque exécution part d’une ardoise vierge, l’agent doit reconstruire le contexte à plusieurs reprises ou compresser trop d’état dans le prompt du modèle.

Un système de fichiers avec état donne à l’agent une mémoire de travail en dehors de la fenêtre de contexte. Il donne également aux humains quelque chose de concret à inspecter.

Les dépendances doivent être installées ou réutilisées

De nombreuses tâches réelles dépendent de packages qui ne sont pas présents dans un environnement d’exécution par défaut. Un agent de codage peut avoir besoin de npm ci, pip install, un navigateur Playwright, un compilateur ou un binaire spécifique au projet. Un agent de données peut avoir besoin d’une version de bibliothèque qui correspond à la production.

Si ces dépendances disparaissent après chaque commande, l’agent perd du temps et crée plus de points de défaillance. Les modèles et les instantanés aident les équipes à démarrer à partir d’un environnement connu au lieu de tout reconstruire à chaque exécution.

Les commandes peuvent durer plus longtemps qu’un seul tour de modèle

Les builds, tests, crawlers, migrations, tâches d’entraînement et évaluations peuvent durer plus longtemps qu’un seul cycle de réponse. Les agents doivent pouvoir lancer une commande, regarder la sortie, se remettre d’une défaillance partielle et capturer les logs.

Cela nécessite un état de processus. Cela nécessite également des contrôles de timeout, une annulation et un moyen de récupérer les résultats après que le modèle est passé à l’étape suivante.

L’accès au navigateur et aux aperçus fait partie de la tâche

De nombreux workflows d’agents sont visuels ou orientés web :

• Un agent de codage démarre une application web locale et vérifie la page rendue.
• Un agent navigateur parcourt un site, télécharge des fichiers, remplit des formulaires ou capture des captures d’écran.
• Un agent de révision vérifie qu’un graphique, un rapport ou une page de démonstration s’affiche correctement.

Pour ces tâches, l’environnement a besoin de plus que stdout. Il a besoin de ports, d’URLs d’aperçu, d’automatisation du navigateur, de captures d’écran ou d’une autre piste d’artefact qui permet à l’agent et au réviseur de voir le résultat.

La révision humaine a besoin de preuves reproductibles

Un agent peut dire « les tests ont réussi » ou « l’application a l’air correcte », mais les équipes de production ont besoin de preuves reproductibles. Un bon environnement d’exécution conserve les logs, les fichiers générés, les captures d’écran et les liens d’aperçu suffisamment longtemps pour qu’une autre personne ou un autre processus puisse les examiner.

C’est là que les sandboxes avec état changent le modèle de collaboration. La sandbox n’est pas seulement un outil pour le modèle ; c’est aussi un artefact de révision.

Que doit préserver une sandbox avec état pour agent ?

L’état n’est utile que lorsqu’il est intentionnel. Une sandbox avec état doit clarifier ce qui survit, ce qui se réinitialise et ce qui peut être transformé en point de départ réutilisable.

État du système de fichiers

Le système de fichiers est l’unité de base du travail de l’agent. Il doit contenir les fichiers sources, les sorties générées, les artefacts de test, les logs, les captures d’écran et les entrées téléchargées. Il doit également être facile de lister, lire, écrire, télécharger et télécharger des fichiers via un SDK, une CLI ou une interface utilisateur.

État de l’environnement d’exécution et des packages

L’environnement d’exécution doit prendre en charge les langages et les gestionnaires de packages dont la tâche a besoin. Pour les agents de codage, cela signifie généralement des commandes shell, des dépendances au niveau du projet et la possibilité de réutiliser un environnement préparé. Pour les agents navigateurs, cela peut inclure des binaires de navigateur et des frameworks d’automatisation.

Accès réseau et web

L’accès réseau nécessite une politique attentive, pas une ouverture vague. Certains agents ont besoin de téléchargements de packages sortants, d’appels API ou de navigation web. D’autres doivent fonctionner avec des règles de sortie plus strictes. Les équipes doivent évaluer si l’environnement d’exécution leur permet de décider ce que la sandbox peut atteindre et comment ces choix sont journalisés.

Capture d’aperçus et d’artefacts

La sortie de l’agent comprend souvent plus que du texte. Recherchez le support des fichiers, captures d’écran, sessions de navigateur, ports exposés, aperçus web et journaux de commandes. Ces artefacts sont la façon dont les réviseurs passent de la confiance dans l’affirmation de l’agent à la vérification du résultat réel.

Contrôles du cycle de vie

Avec état ne signifie pas permanent. L’environnement d’exécution doit prendre en charge la création, le timeout, la pause ou la reprise le cas échéant, la terminaison et le nettoyage. Il doit également prendre en charge les modèles ou les instantanés afin qu’un environnement préparé puisse être réutilisé sans conserver chaque session pour toujours.

Chemins de réinitialisation et d’instantané

Les agents commettent des erreurs. Un ordinateur agent pratique a besoin d’un chemin de réinitialisation propre et d’un moyen de capturer un bon état avant un travail risqué. Les instantanés sont utiles après la configuration, après l’installation des dépendances ou avant une longue exécution d’évaluation.

Comment les équipes doivent-elles évaluer un environnement d’exécution pour agent ?

Les critères d’évaluation doivent être séparés des affirmations des fournisseurs. Le bon environnement d’exécution dépend du workflow, du profil de risque et du processus de révision.

Critère	Que demander	Pourquoi c’est important
Cycle de vie	Comment les environnements sont-ils créés, mis en pause, repris, temporisés et supprimés ?	Empêche les sessions abandonnées et les coûts incontrôlés
Système de fichiers	L’agent et le réviseur peuvent-ils inspecter les fichiers et artefacts ?	Rend le travail multi-étapes révisable
Installation de packages	Les dépendances peuvent-elles être installées, mises en cache, modélisées ou instantanées ?	Réduit la répétition de configuration et la dérive
Exécution de commandes	Les logs, codes de sortie, timeouts et tâches d’arrière-plan sont-ils accessibles ?	Rend les défaillances débogables
Accès navigateur ou aperçu	L’agent peut-il inspecter la sortie rendue ou automatiser un navigateur ?	Prend en charge les applications web, les tâches UI et la révision visuelle
Politique réseau	Quel accès sortant est autorisé et comment est-il contrôlé ?	Réduit les risques liés aux téléchargements de packages, à la navigation web et aux appels externes
Isolation	Quelle barrière sépare les sandboxes les unes des autres et de l’hôte ?	Détermine le type de code et de données pour lequel l’environnement d’exécution est adapté
Modèles et instantanés	Les équipes peuvent-elles réutiliser des environnements connus comme bons ?	Améliore la reproductibilité
Transfert humain	Un réviseur peut-il voir les mêmes fichiers, logs, captures d’écran ou aperçus ?	Transforme l’environnement d’exécution en artefact révisable
Modèle de coût	La facturation est-elle liée au temps de session, CPU, mémoire, stockage ou concurrence ?	Évite les surprises de coût lorsque les agents s’exécutent en parallèle

Les questions sensibles à la sécurité méritent une documentation précise et une révision du produit. Évitez de traiter une sandbox comme une protection magique. L’isolation, l’accès réseau, la gestion des secrets et les logs nécessitent tous des choix de conception explicites.

Où se situe Novita Agent Sandbox ?

Novita Agent Sandbox est conçu pour les workflows d’agents qui ont besoin d’environnements d’exécution isolés et avec état. La vue d’ensemble d’Agent Sandbox décrit les sandboxes comme des environnements où les agents peuvent exécuter des commandes, lire et écrire des fichiers, installer des dépendances et utiliser des workflows basés sur le navigateur. Elle définit également des modèles pour des environnements de départ préparés et des instantanés pour sauvegarder l’état configuré de la sandbox.

Cela fait de Novita un choix à évaluer lorsque votre charge de travail d’agent nécessite :

• une exécution de code dans un environnement isolé ;
• un accès aux fichiers sur plusieurs étapes ;
• une installation de dépendances et des environnements préparés réutilisables ;
• des workflows orientés navigateur ;
• des artefacts générés que les humains peuvent inspecter ;
• des contrôles de cycle de vie via SDK ou CLI ;
• une direction de plateforme qui combine les API de modèles et l’infrastructure de sandbox pour agents.

Cela ne signifie pas que chaque agent a besoin d’une sandbox avec état. Si votre application n’a besoin que d’une exécution Python ponctuelle sur un fichier téléchargé par l’utilisateur, un modèle d’interpréteur de code peut être plus simple. Si votre équipe dispose déjà d’un environnement d’exécution interne avec des règles de sortie strictes, la gestion des secrets, l’audit et les flux de révision, la question est de savoir si une sandbox externe améliore la vitesse de développement sans affaiblir ces contrôles.

Utilisez Novita Agent Sandbox dans le cadre d’une décision d’architecture, pas comme un remplacement générique de tous les chemins d’exécution.

Une règle de décision pratique

Posez une question avant de choisir l’environnement d’exécution :

Une deuxième personne ou un deuxième agent pourrait-il reprendre, inspecter ou reproduire ce travail à partir de l’environnement après la fin du premier tour de modèle ?

Si la réponse est non et que le résultat est toujours utile, l’exécution éphémère est probablement suffisante. Si la réponse doit être oui, la tâche s’oriente vers une sandbox avec état ou un ordinateur agent.

Pour les systèmes d’agents en production, cela devient souvent le modèle par défaut :

1. Démarrer à partir d’un modèle ou d’un instantané propre.
2. Laisser l’agent travailler dans un environnement d’exécution isolé.
3. Capturer les fichiers, logs, captures d’écran, aperçus et résultats de commandes.
4. Conserver l’environnement suffisamment longtemps pour la révision.
5. Réinitialiser, supprimer ou instantané en fonction du résultat.

Ce workflow donne au modèle la liberté d’agir tout en gardant le résultat inspectable.

Articles recommandés

• Construire un agent de codage avec Novita Agent Sandbox
• Héberger Clawdbot avec le modèle de sandbox Novita
• Quel fournisseur d’inférence choisir pour les agents IA

FAQ

Un interpréteur de code est-il identique à une sandbox pour agent ?

Non. Un interpréteur de code se concentre généralement sur l’exécution de code généré et le renvoi de résultats à l’intérieur d’une session gérée. Une sandbox pour agent est un environnement isolé plus large pour les commandes, les fichiers, les dépendances, les workflows navigateur, le contrôle du cycle de vie et les artefacts révisables.

Tous les agents IA ont-ils besoin de sandboxes avec état ?

Non. Les transformations de données simples, les calculs et les scripts ponctuels peuvent bien fonctionner avec une exécution éphémère. Les agents ont besoin de sandboxes avec état lorsque le workflow dépend de fichiers persistants, de packages installés, de processus longs, d’un accès au navigateur ou aux aperçus, ou d’une révision humaine des artefacts.

Qu’est-ce qu’un ordinateur agent ?

Un ordinateur agent est un environnement de tâche qui donne à un agent IA des outils de type informatique : système de fichiers, shell, packages, accès au navigateur ou à l’interface utilisateur, logs, artefacts, contrôles de cycle de vie et options de réinitialisation ou d’instantané. C’est un concept utile pour le travail d’agent de longue durée et révisable.

Pourquoi les instantanés sont-ils importants pour les workflows d’agents ?

Les instantanés permettent aux équipes de sauvegarder un environnement configuré et de le réutiliser plus tard. Ils réduisent le travail de configuration répété, améliorent la reproductibilité et fournissent un point de retour propre avant que l’agent n’effectue des actions risquées ou expérimentales.

Comment les équipes doivent-elles envisager la sécurité des sandboxes ?

Traitez la sécurité des sandboxes comme une décision d’architecture. Examinez le modèle d’isolation, l’accès réseau, la gestion des secrets, les logs, le nettoyage du cycle de vie et le processus de révision humaine avant d’exécuter des charges de travail sensibles ou du code non fiable.