- 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 sont les mieux adaptés
- Où les runtimes d'agent sont les mieux adaptés
- Modèles hybrides : utiliser les deux dans une seule application
- Évaluation de l'infrastructure de bac à sable 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, renvoyer un résultat, tout effacer. Les runtimes d’agent gèrent des workflows multi-étapes qui nécessitent un état persistant, un accès aux outils, un contrôle de navigateur, des entrées/sorties de fichiers ou des sessions longues. Le bon choix dépend de votre charge de travail, pas de l’étiquette utilisée par un produit pour se décrire.
Si votre objectif est un workflow d’automatisation délimité plutôt qu’une décision d’architecture d’application générale, consultez Comment automatiser des tâches avec l’IA.
Ce que fait réellement un interpréteur de code
Un interpréteur de code donne à 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é au détriment de la continuité. La frontière d’isolation est étroite car la seule chose qui doit se produire est : exécuter ce code, renvoyer ce résultat.
L’empreinte pratique est petite : un runtime Python (ou similaire) en bac à sable, 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 renvoyer des artefacts. La session peut durer 30 secondes ou 10 minutes, mais l’application la traite comme fondamentalement éphémère.
Cela correspond proprement à plusieurs charges de travail à forte valeur ajoutée :
- Exécution de script unique : l’utilisateur demande au modèle de calculer quelque chose, et le résultat revient sous forme de nombre, de tableau ou de 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 tâches similaires qui tiennent dans un seul bloc de code.
- Environnements éducatifs : où chaque exercice est isolé et il n’y a pas d’attente de continuité de session.
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, effectue une action en dehors du bac à sable, ou continue à travailler après que l’utilisateur a cessé de regarder.
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 supprimé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 dans une étape sont toujours présents dans la suivante. Un agent de codage peut créer une branche, éditer des fichiers, exécuter des tests, corriger des échecs et pousser un commit – le tout 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 environnement de développement réel plutôt qu’un bac à sable Python verrouillé.
Accès au navigateur et au web : les agents qui ont besoin de lire de la documentation, d’interagir avec des applications web, de remplir des formulaires ou d’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 de 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 de longue durée : 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 la durée d’un workflow, pas pour démarrer et démonter à chaque appel de fonction.
Orchestration multi-outils : les workflows d’agent réels impliquent l’appel de plusieurs outils en séquence – une recherche web, suivie d’une modification de fichier, suivie d’une exécution de test, suivie d’un push git. 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 à exploiter, 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 de l’interpréteur, ajouter toute cette complexité est un gaspillage.
Dimensions clés de décision
Le tableau ci-dessous présente les critères de décision pratiques. La plupart des applications se situent clairement d’un côté ; les modèles hybrides sont couverts dans la section suivante pour les cas qui chevauchent 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 | Supprimé 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 | Plusieurs sessions parallèles courtes | Moins de sessions longues |
La durée de vie de la session et les exigences d’é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 à travers plusieurs tours, utilisez un runtime.
La largeur des outils est le deuxième 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 sont les mieux adaptés
Les interpréteurs de code sont le bon choix lorsque l’exécution est délimitée et autonome. Les cas d’utilisation 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 renvoie 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 de 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 : travaux planifiés qui génèrent un rapport à partir d’une source de données et l’envoient par e-mail ou le sauvegardent. Le travail s’exécute, produit un artefact et se termine.
Génération de graphiques et de 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’environnement persistant.
Utilisation d’outils LLM en bac à sable : lorsqu’un modèle a besoin d’un outil code_interpreter pour raisonner sur des données, vérifier des calculs ou formater une 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 à exploiter 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 sont les mieux adaptés
Les runtimes d’agent sont le bon choix lorsqu’une tâche ne peut pas être terminée sans coordonner plusieurs outils au fil du temps, maintenir l’état à travers les étapes, ou prendre des actions en dehors du bac à sable 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 demande de tirage nécessite 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 navigateur et d’automatisation web : scraper du contenu dynamique, remplir des formulaires, naviguer dans des workflows web multi-étapes, extraire des données structurées d’interfaces visuelles – tout cela nécessite une session de navigateur réelle qui persiste suffisamment longtemps pour terminer le workflow.
Pipelines de recherche et de collecte de données : les agents qui récupèrent des documents à partir 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 : l’exécution 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 de session à 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 créer des points de contrôle.
Outils de codage agentiques comme les agents de style Codex ou les agents connectés à l’IDE qui agissent sur un projet réel ont besoin de la surface complète d’un environnement de développement – pas d’un interpréteur en bac à sable.
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 de session vous-même. Le runtime fournit cette infrastructure ; vous configurez la politique.
Modèles hybrides : utiliser les deux dans une seule 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 référentiel, 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 bac à sable en tant que sous-opération dans le workflow d’agent plus large.
Un produit d’analyse de données peut utiliser un runtime d’agent pour orchestrer l’ensemble du workflow – 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 bac à sable 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 contient la session, coordonne les outils et gère l’état.
- Les opérations internes qui nécessitent une isolation stricte 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 avec 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 bac à sable lorsque nécessaire.
Évaluation de l’infrastructure de bac à sable pour chaque modèle
Que vous évaluiez un fournisseur de bac à sable 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 renvoyé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 supprimé à 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 humains dans la boucle ou la gestion des coûts ?
- Existe-t-il un support de 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 de session, et comment évolue-t-il ?
- Comment les secrets sont-ils injectés et délimités ?
- Quelle observabilité existe-t-il – journaux de commandes, suivi des modifications de fichiers, métriques de ressources ?
- Comment la plateforme gère-t-elle les sessions de longue durée qui dépassent les cycles typiques de 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èle de Novita afin que les équipes qui utilisent Novita pour l’inférence LLM puissent exécuter des charges de travail en bac à sable sur la même plateforme. Pour les équipes qui évaluent l’infrastructure de bac à sable pour les workflows d’agent, la documentation de Novita Agent Sandbox couvre le modèle d’isolation, l’API de cycle de vie et la configuration des ressources.
Pour les charges de travail qui sont réellement interpréteur uniquement – script unique, éphémère, sans état – un runtime d’agent complet est une surcharge dont vous n’avez pas besoin. Utilisez l’outil 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 du 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 en bac à sable et supprime 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 au navigateur et un état de session – à travers plusieurs étapes d’un workflow. L’interpréteur répond à “exécute ce code et renvoie le résultat” ; le runtime répond à “travaille vers cet objectif à travers 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 le bac à sable, ou renvoi d’artefacts. Ce qu’elles ne prennent pas en charge, c’est un espace de travail persistant qui transporte l’état à travers les tours ou une session de navigateur qui survit à un seul appel de fonction. Si votre application a besoin de lire une page web, d’écrire un fichier, puis de 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 plus longs, accès au navigateur ou CLI – et ces composants coûtent plus cher qu’un bac à sable d’interpréteur de courte durée. Pour les charges de travail qui nécessitent réellement une coordination multi-étapes, le coût du runtime est justifié. Pour les tâches à passage unique, c’est une surcharge.
Quand dois-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’une isolation stricte. Un agent de codage qui exécute la suite de tests dans un interpréteur en bac à sable, 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 au 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’utilisation. Consultez la documentation de 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 du 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.
