- Ce que fait réellement un interpréteur de code
- Ce qu'un runtime d'agent ajoute
- Dimensions clés de décision
- Où les interpréteurs de code conviennent le mieux
- Où les runtimes d'agent conviennent le mieux
- Modèles hybrides : utiliser les deux dans une même application
- Évaluation de l'infrastructure sandbox pour chaque modèle
- FAQ
- Articles recommandés
Les interpréteurs de code gèrent des tâches d’exécution isolées et de courte durée — exécuter un script, retourner un résultat, tout effacer. Les runtimes d’agent gèrent des workflows multi-étapes nécessitant un état persistant, un accès aux outils, un contrôle du navigateur, des entrées/sorties fichiers ou des sessions longues. Le bon choix dépend de votre charge de travail, pas de l’étiquette qu’un produit utilise pour se décrire.
Ce que fait réellement un interpréteur de code
Un interpréteur de code offre à un modèle de langage un moyen d’exécuter du code et de voir le résultat. Le modèle écrit un script Python, l’interpréteur l’exécute en isolation, et le résultat revient sous forme de texte, de fichier ou de graphique rendu. Lorsque la session se termine — ou même entre les tours dans certaines implémentations — l’environnement est réinitialisé. Rien n’est conservé.
Cette conception est intentionnelle. Les interpréteurs de code privilégient la sécurité et la simplicité à la continuité. La barrière d’isolation est stricte car la seule chose à faire est : exécuter ce code, retourner ce résultat.
L’empreinte pratique est petite : un runtime Python (ou similaire) en sandbox, un système de fichiers limité à la session, un accès réseau suffisant pour récupérer des bibliothèques ou des données externes si le cas d’usage le nécessite, et un mécanisme pour retourner les artefacts. La session peut durer 30 secondes ou 10 minutes, mais l’application la traite comme fondamentalement éphémère.
Cela correspond clairement à plusieurs charges de travail à forte valeur :
- Exécution de script unique : un utilisateur demande au modèle de calculer quelque chose, et le résultat revient sous forme de nombre, tableau ou fichier.
- Analyse de données : télécharger un CSV, générer un résumé, produire un graphique. Le travail commence et se termine en une seule interaction.
- Calcul rapide : mathématiques, transformations de données, conversions de format et autres tâches qui tiennent dans un seul bloc de code.
- Environnements éducatifs : où chaque exercice est isolé et aucune continuité de session n’est attendue.
Ce que les interpréteurs de code ne gèrent pas bien, c’est tout ce qui nécessite que l’environnement se souvienne de quelque chose, prenne une action en dehors de la sandbox, ou continue de fonctionner après que l’utilisateur a cessé de surveiller.
Ce qu’un runtime d’agent ajoute
Un runtime d’agent est un environnement d’exécution conçu pour un travail qui s’étend sur plusieurs étapes, implique des outils externes et peut prendre des minutes ou des heures plutôt que des secondes. La session n’est pas jetée entre les étapes — c’est un espace de travail que l’agent utilise pour progresser vers un objectif.
Les ajouts pratiques par rapport à un simple interpréteur sont significatifs :
Espace de travail persistant : les fichiers écrits à une étape sont toujours là à l’étape suivante. Un agent de codage peut créer une branche, modifier des fichiers, exécuter des tests, corriger des échecs et pousser un commit — tout cela en une seule session, sans recommencer.
Paquets installés et outils système : un runtime d’agent prend généralement en charge l’installation de dépendances, l’exécution de commandes shell, l’appel de CLI, le démarrage de processus en arrière-plan, et le travail avec un véritable environnement de développement plutôt qu’une sandbox Python verrouillée.
Accès navigateur et web : les agents qui doivent lire de la documentation, interagir avec des applications web, remplir des formulaires ou automatiser des workflows web ont besoin d’un navigateur dans l’environnement d’exécution. Un interpréteur de code n’a pas de concept de session navigateur persistante.
Stockage de fichiers et persistance des artefacts : les sorties qui doivent survivre à une seule exécution — code généré, données intermédiaires, fichiers téléchargés, captures d’écran — nécessitent un système de fichiers qui persiste à travers les étapes et, dans certains cas, à travers les sessions.
Sessions longues : certaines tâches d’agent prennent 20 minutes. D’autres prennent plus de temps. Un runtime d’agent est conçu pour rester actif pendant toute la durée d’un workflow, pas pour démarrer et s’arrêter à chaque appel de fonction.
Orchestration multi-outils : les workflows d’agents réels impliquent d’appeler plusieurs outils en séquence — une recherche web, suivie d’une modification de fichier, suivie d’un test, suivie d’un git push. Un runtime d’agent est conçu pour coordonner cette chaîne de manière fiable.
Le compromis est réel : les runtimes d’agent sont plus complexes à opérer, coûtent plus cher par session qu’un interpréteur léger, et exposent une surface d’attaque plus large qui nécessite une configuration de politique minutieuse. Pour les charges de travail qui correspondent au modèle d’interpréteur, ajouter toute cette complexité est du gaspillage.
Dimensions clés de décision
Le tableau ci-dessous présente les critères de décision pratiques. La plupart des applications tombent clairement d’un côté ; les modèles hybrides sont abordés dans la section suivante pour les cas qui couvrent les deux.
| Dimension | Interpréteur de code | Runtime d’agent |
|---|---|---|
| Durée de vie de la session | Secondes à minutes, éphémère | Minutes à heures, persistante |
| État entre les étapes | Jeté ou limité | Préservé |
| Accès aux outils | Exécution de code uniquement | CLI, navigateur, E/S fichiers, API, sous-processus |
| Installation de paquets | Image fixe ou restreinte | Dynamique, avec contrôles de politique |
| Interaction navigateur/web | Non disponible | Prise en charge |
| Stockage de fichiers | Limité à la session uniquement | Persistant à travers les étapes |
| Coût par session | Faible | Plus élevé |
| Complexité de l’infrastructure | Faible | Plus élevée |
| Points de contrôle humain dans la boucle | Pas typique | Courant — approuver avant déploiement, fusion ou action externe |
| Modèle de concurrence | Beaucoup de sessions courtes en parallèle | Moins de sessions plus longues |
La durée de vie de la session et les besoins en état sont les filtres les plus rapides. Si votre charge de travail se réinitialise entre les tours, utilisez un interpréteur. Si votre charge de travail progresse vers un objectif sur plusieurs tours, utilisez un runtime.
La largeur des outils est le second filtre. Le contrôle du navigateur, les opérations git, les outils CLI et les appels API externes nécessitent un runtime. Si votre seul outil est l’exécution de code, un interpréteur suffit.
Les points de contrôle humain dans la boucle indiquent presque toujours un runtime. Mettre en pause une session pour attendre une approbation puis continuer nécessite un état persistant et une session qui peut être reprise. Les interpréteurs ne sont pas conçus pour cela.
Où les interpréteurs de code conviennent le mieux
Les interpréteurs de code sont le bon choix lorsque l’exécution est bornée et autonome. Les cas d’usage les plus forts :
Assistants d’analyse de données : l’utilisateur télécharge un fichier, pose une question, reçoit des graphiques et des résumés. Le travail est terminé lorsque le modèle retourne la sortie. Il n’y a pas d’étape suivante qui dépend de la mémoire de la précédente.
Outils de calcul et mathématiques : calculatrices, convertisseurs d’unités, analyses statistiques, simulations numériques. Ce sont des passages uniques : l’entrée entre, la sortie sort.
Rapports automatisés : tâches planifiées qui génèrent un rapport à partir d’une source de données et l’envoient par email ou le sauvegardent. La tâche s’exécute, produit un artefact et se termine.
Génération de graphiques et visualisations : le modèle écrit du code matplotlib ou similaire, l’interpréteur l’exécute, et l’utilisateur reçoit une image. Pas besoin d’un environnement persistant.
Utilisation d’outils LLM en sandbox : lorsqu’un modèle a besoin d’un outil code_interpreter pour raisonner sur des données, vérifier des calculs ou formater la sortie — et rien d’autre — un interpréteur de code est précisément ce pour quoi l’API est conçue.
L’attrait des interpréteurs dans ces scénarios est pratique : ils sont moins chers par session, plus faciles à opérer et plus simples à sécuriser. Il n’y a pas d’état persistant à gérer, pas de cycle de vie de session à suivre, et la surface d’attaque est étroite car le code s’exécute une fois et l’environnement disparaît.
Où les runtimes d’agent conviennent le mieux
Les runtimes d’agent sont le bon choix lorsqu’une tâche ne peut pas être accomplie sans coordonner plusieurs outils dans le temps, maintenir un état entre les étapes, ou prendre des actions en dehors de la sandbox d’exécution de code.
Agents de codage : un agent qui lit une base de code, écrit des modifications, exécute la suite de tests, corrige les échecs et ouvre une pull request a besoin d’un espace de travail persistant avec git, un terminal et un système de fichiers. Ceci est architecturalement incompatible avec un interpréteur éphémère.
Agents de navigation et d’automatisation web : scraper du contenu dynamique, remplir des formulaires, naviguer dans des flux web multi-étapes, extraire des données structurées d’interfaces visuelles — tout cela nécessite une véritable session navigateur qui persiste assez longtemps pour terminer le workflow.
Pipelines de recherche et de collecte de données : les agents qui récupèrent des documents de plusieurs sources, croisent des informations, écrivent des résultats intermédiaires sur le disque et produisent une sortie synthétisée finale ont besoin d’un espace de travail qui persiste à travers toutes ces étapes.
Charges de travail d’évaluation et de RL : exécuter de nombreux épisodes d’agent en parallèle, chacun maintenant son propre état, suivant les scores et écrivant des points de contrôle, nécessite un runtime conçu pour la concurrence et l’isolation des sessions à grande échelle.
Agents d’infrastructure longue durée : les agents qui provisionnent des ressources, exécutent des déploiements, surveillent les sorties et réagissent aux changements sur une fenêtre de plusieurs minutes ou heures ont besoin d’un modèle de session qui peut mettre en pause, reprendre et établir des points de contrôle.
Outils de codage agentiques comme les agents de type Codex ou les agents connectés à l’IDE qui prennent des actions sur un projet réel ont besoin de la surface complète d’un environnement de développement — pas d’un interpréteur en sandbox.
Le coût d’un runtime est justifié lorsque l’alternative est de câbler manuellement la gestion d’état, la coordination des outils et la persistance des sessions. Le runtime fournit cette infrastructure ; vous configurez la politique.
Modèles hybrides : utiliser les deux dans une même application
De nombreuses applications réelles intègrent les deux modèles. Un assistant de codage peut utiliser un runtime d’agent pour la session globale — maintenir le contexte du dépôt, suivre les fichiers modifiés, gérer une branche — tout en appelant un interpréteur de code spécifiquement pour exécuter des tests ou exécuter des scripts fournis par l’utilisateur en sandbox comme sous-opération dans le workflow de l’agent plus large.
Un produit d’analyse de données peut utiliser un runtime d’agent pour orchestrer le workflow complet — télécharger des données, les nettoyer, joindre plusieurs sources — tout en utilisant des invocations d’interpréteur isolées pour les étapes de calcul individuelles où un sandboxing strict est important et où l’état n’a pas besoin de persister.
Le modèle ressemble à ceci en pratique :
- La couche externe est un runtime d’agent : elle maintient la session, coordonne les outils et gère l’état.
- Les opérations internes qui nécessitent un fort isolement utilisent des invocations d’interpréteur de code de courte durée comme un outil parmi d’autres.
- Le runtime d’agent décide quand invoquer l’interpréteur, quelles entrées passer et quoi faire de la sortie.
Ce n’est pas un modèle architectural complexe ; c’est simplement utiliser chaque couche pour ce pour quoi elle est conçue. Le runtime d’agent gère le workflow ; l’interpréteur gère l’exécution en sandbox lorsque nécessaire.
Évaluation de l’infrastructure sandbox pour chaque modèle
Que vous évaluiez un fournisseur de sandbox géré ou que vous conceviez le vôtre, les questions auxquelles vous devez répondre diffèrent considérablement selon le modèle pour lequel vous construisez.
Pour les charges de travail d’interpréteur de code, les critères d’évaluation sont relativement étroits :
- Quelle est la latence de démarrage ? Un démarrage inférieur à la seconde est important pour une utilisation interactive.
- Quels langages et paquets sont disponibles dans l’image par défaut ?
- Les utilisateurs peuvent-ils installer des paquets supplémentaires, et cela est-il autorisé par votre modèle de sécurité ?
- Quelles sont les limites de ressources (CPU, mémoire, temps d’exécution) ?
- Comment les artefacts de session sont-ils retournés — réponse synchrone, téléchargement de fichier ou URL présignée ?
- Existe-t-il une option de système de fichiers persistant, ou tout est-il jeté à la sortie ?
Pour les charges de travail de runtime d’agent, les critères s’élargissent considérablement :
- L’environnement prend-il en charge les systèmes de fichiers persistants qui survivent à travers les étapes d’une session ?
- La session peut-elle être mise en pause et reprise — pour les workflows avec intervention humaine ou la gestion des coûts ?
- Existe-t-il un support navigateur, et comment est-il configuré ?
- Quels outils shell et CLI sont disponibles ?
- Comment l’accès réseau est-il contrôlé — politiques de sortie, filtrage DNS, listes d’autorisation sortantes ?
- Quel est le modèle de concurrence des sessions, et comment évolue-t-il ?
- Comment les secrets sont-ils injectés et délimités ?
- Quelle observabilité existe — journaux de commandes, suivi des modifications de fichiers, métriques de ressources ?
- Comment la plateforme gère-t-elle les sessions longues qui dépassent les cycles typiques requête-réponse ?
Novita Agent Sandbox est conçu pour les charges de travail de runtime d’agent — agents de codage, automatisation de navigateur, pipelines d’analyse de données, et charges de travail d’évaluation/RL qui nécessitent un état persistant, un accès aux outils et un contrôle de session. Il utilise l’isolation microVM, prend en charge Pause/Reprise, et s’intègre à la plateforme d’API de modèles de Novita afin que les équipes qui utilisent Novita pour l’inférence LLM puissent exécuter des charges de travail sandbox sur la même plateforme. Pour les équipes évaluant l’infrastructure sandbox pour les workflows d’agents, la documentation Novita Agent Sandbox couvre le modèle d’isolation, l’API du cycle de vie et la configuration des ressources.
Pour les charges de travail qui sont véritablement uniquement basées sur un interpréteur — script unique, éphémère, sans état — un runtime d’agent complet est une surcharge dont vous n’avez pas besoin. Utilisez l’outil le plus simple.
Le test pratique : votre workflow peut-il se terminer correctement si l’environnement d’exécution est détruit et reconstruit entre chaque tour de modèle ? Si oui, un interpréteur est probablement suffisant. Si non — parce que l’état, l’accès aux outils ou la continuité de la session sont importants — vous avez besoin d’un runtime.
FAQ
Quelle est la principale différence entre un interpréteur de code et un runtime d’agent ?
Un interpréteur de code exécute du code dans un environnement sandboxé et jette l’environnement lorsque la session se termine. Un runtime d’agent maintient un espace de travail persistant — avec des fichiers, des outils installés, un accès navigateur et un état de session — à travers plusieurs étapes d’un workflow. L’interpréteur répond à « exécute ce code et retourne le résultat » ; le runtime répond à « travaille vers cet objectif en autant d’étapes que nécessaire ».
Un interpréteur de code peut-il utiliser des outils comme la recherche web ou l’accès aux fichiers ?
Certaines implémentations d’interpréteur de code prennent en charge une utilisation limitée des outils — téléchargements de fichiers, appels réseau dans la sandbox ou retour d’artefacts. Ce qu’elles ne prennent pas en charge, c’est un espace de travail persistant qui transporte l’état entre les tours ou une session navigateur qui dure plus longtemps qu’un seul appel de fonction. Si votre application doit lire une page web, écrire un fichier, puis référencer ce fichier dans une étape ultérieure, vous avez besoin d’un runtime.
Un runtime d’agent est-il toujours plus cher qu’un interpréteur de code ?
Par session, oui. Les runtimes d’agent impliquent plus d’infrastructure — systèmes de fichiers persistants, processus de plus longue durée, accès navigateur ou CLI — et ces composants coûtent plus cher qu’une sandbox d’interpréteur de courte durée. Pour les charges de travail qui nécessitent véritablement une coordination multi-étapes, le coût du runtime est justifié. Pour les tâches à passage unique, c’est une surcharge.
Quand devrais-je utiliser les deux dans la même application ?
Lorsque le workflow externe nécessite un état persistant mais que les sous-opérations individuelles bénéficient d’un fort isolement. Un agent de codage qui exécute la suite de tests dans un interpréteur sandboxé, ou un pipeline de données qui délègue les étapes de calcul à des interpréteurs éphémères tandis que la couche d’orchestration maintient l’état global, sont tous deux des modèles hybrides courants.
Le Novita Agent Sandbox prend-il en charge les deux modèles ?
Novita Agent Sandbox est conçu pour les charges de travail de runtime d’agent — espaces de travail persistants, Pause/Reprise, accès navigateur et contrôle de session multi-étapes. Pour les invocations d’interpréteur isolées et éphémères, une exécution plus légère peut être plus appropriée selon votre cas d’usage. Voir la documentation Novita Agent Sandbox pour les détails actuels des capacités.
Comment savoir si ma charge de travail a besoin d’un runtime ?
Le test pratique : votre workflow peut-il se terminer correctement si l’environnement d’exécution est détruit et reconstruit entre chaque tour de modèle ? Si oui, un interpréteur suffit. Si la réponse est non — parce que l’état, l’accès aux outils, le contrôle du navigateur ou la continuité de la session sont importants — vous avez besoin d’un runtime.
