- Ce qu'un interpréteur de code apporte à une application IA
- Architecture de référence
- Flux de mise en œuvre
- Gérer les fichiers, les sorties et les artefacts générés
- Définir la politique de paquets et de réseau
- Appliquer les limites, les journaux, le nettoyage et la révision
- Où Novita Agent Sandbox s'intègre
- Liste de vérification pour l'évaluation
- Conclusion
- FAQ
- Articles recommandés
Ajoutez un interpréteur de code à une application IA en routant l’exécution de code demandée par le modèle dans un bac à sable isolé avec des fichiers délimités, une politique de paquets claire, des limites de ressources et de temps, des sorties capturées, et une révision côté application avant que les résultats soient affichés ou conservés. Le modèle peut décider quand le code est utile, mais votre application doit posséder la frontière d’exécution : téléchargez uniquement les fichiers nécessaires à la tâche, créez ou réutilisez une session de bac à sable éphémère, exécutez Python avec des limites strictes, capturez stdout, stderr, les fichiers générés et les journaux, renvoyez un résultat structuré au modèle, et nettoyez la session une fois le flux de travail terminé.
Ce qu’un interpréteur de code apporte à une application IA
Un interpréteur de code transforme un modèle de langage d’un assistant purement textuel en une application utilisant des outils qui peut calculer, transformer des fichiers, inspecter des données, générer des graphiques et produire des artefacts révisables. Au lieu de demander au modèle de raisonner sur une feuille de calcul à partir d’une invite, l’application peut laisser le modèle écrire du Python, l’exécuter sur le fichier téléchargé, inspecter la sortie et expliquer le résultat.
Le modèle utile n’est pas « laisser le modèle exécuter n’importe quoi ». Le modèle utile est une exécution contrôlée. Votre application accepte une tâche utilisateur, laisse le modèle demander un appel d’outil tel que run_python, puis exécute cette demande à l’intérieur d’un bac à sable plutôt que dans le processus principal de l’application. Le bac à sable devient l’établi pour les fichiers temporaires, les installations de paquets, les scripts, les graphiques et les journaux.
Les fonctionnalités d’interpréteur de code sont particulièrement utiles pour :
- l’analyse de CSV, Excel, JSON et de journaux
- la génération de graphiques à partir de données téléchargées
- la conversion de format et le nettoyage de données
- les tâches mathématiques et de simulation qui nécessitent un calcul exact
- les extraits de code qui doivent être testés avant que le modèle les explique
- les flux de travail d’agent en plusieurs étapes où les sorties d’une étape deviennent les entrées de la suivante
Ils sont mal adaptés aux tâches qui nécessitent des identifiants de production non restreints, un accès à long terme à des systèmes privés, ou une exécution silencieuse sans piste d’audit visible par l’utilisateur. Si le résultat peut affecter l’argent, l’infrastructure, la sécurité ou le contrôle d’accès, ajoutez des points de révision avant que tout effet de bord quitte le bac à sable.
Architecture de référence
Une architecture pratique d’interpréteur de code comporte cinq parties :
| Couche | Responsabilité | Choix de conception courant |
|---|---|---|
| Interface utilisateur | Télécharger des fichiers, afficher la progression, montrer les artefacts, demander l’approbation | Gardez les fichiers téléchargés dans le périmètre de la conversation ou du projet en cours |
| Serveur d’application | Authentifier les utilisateurs, appliquer la politique, créer des sessions de bac à sable, stocker les journaux | N’exposez jamais les identifiants bruts du bac à sable au navigateur |
| Orchestration du modèle | Décider quand appeler les outils de code et résumer les résultats | Utilisez des appels d’outil structurés plutôt que d’analyser du texte libre |
| Exécution du bac à sable | Exécuter Python, conserver les fichiers temporaires, installer les paquets autorisés | Exécutez avec des contrôles de ressources, de délai d’attente et de nettoyage |
| Stockage d’artefacts | Préserver les sorties approuvées telles que graphiques, CSV, rapports et journaux | Stockez uniquement les sorties que l’application ou l’utilisateur a acceptées |
Le modèle ne doit pas contrôler directement l’infrastructure. Il doit demander un appel d’outil. Votre application décide si cet appel d’outil est autorisé, quels fichiers sont attachés, combien de temps il peut s’exécuter, quels paquets sont disponibles et quelles sorties sont renvoyées.
Cette séparation maintient le modèle utile sans en faire la frontière de sécurité.
Flux de mise en œuvre
Un flux de mise en œuvre solide commence avant toute exécution de code.
1. Accepter la tâche et les fichiers de l’utilisateur
Lorsque l’utilisateur télécharge un fichier, stockez-le sous un enregistrement de fichier au niveau de l’application avec le propriétaire, l’espace de travail, le type de contenu, la taille et la politique de conservation. N’exposez pas immédiatement chaque fichier du compte de l’utilisateur à l’interpréteur. Le bac à sable ne doit recevoir que les fichiers nécessaires à la tâche en cours.
Par exemple, un utilisateur pourrait demander :
“Analysez ce CSV, trouvez les principaux moteurs de revenus, et renvoyez un graphique plus une courte explication.”
Votre application peut attacher le CSV téléchargé au prochain tour du modèle en tant que fichier disponible, mais les octets du fichier réel ne doivent être déplacés dans le bac à sable que lorsque l’exécution du code est approuvée.
2. Laisser le modèle demander un appel d’outil
Définissez une surface d’outil étroite. Une première version typique n’a besoin que de quelques outils :
{
"name": "run_python",
"arguments": {
"code": "import pandas as pd\n...",
"input_files": ["sales.csv"],
"expected_outputs": ["summary.json", "revenue_chart.png"],
"timeout_seconds": 30
}
}
Gardez le schéma explicite. Le modèle doit déclarer le code, les fichiers d’entrée, les sorties attendues et une demande de délai d’attente. L’application peut raccourcir le délai, rejeter les fichiers inconnus ou bloquer les commandes qui entrent en conflit avec la politique.
3. Créer ou réutiliser une session de bac à sable
Pour une réponse d’assistant unique, créez une nouvelle session de bac à sable, téléchargez les fichiers d’entrée, exécutez le code, collectez le résultat et terminez la session. Pour une expérience utilisateur de type notebook, gardez une session active pour la conversation en cours afin que les cellules ultérieures puissent réutiliser les variables et fichiers précédents.
Les sessions de courte durée sont plus faciles à raisonner. Les sessions avec état sont plus ergonomiques pour les tâches d’analyse. Choisissez délibérément et montrez à l’utilisateur quand un état existe.
4. Exécuter Python et capturer les résultats
Exécutez le code via l’API d’exécution du bac à sable ou votre propre worker dans le bac à sable. Capturez la sortie d’exécution structurée :
{
"status": "success",
"stdout": "Loaded 12,448 rows\n",
"stderr": "",
"artifacts": [
{
"path": "revenue_chart.png",
"type": "image/png",
"size_bytes": 84231
},
{
"path": "summary.json",
"type": "application/json",
"size_bytes": 1260
}
],
"duration_ms": 1840
}
Renvoie ce résultat structuré au modèle. Le modèle peut alors expliquer ce qui s’est passé, citer les fichiers générés et demander si l’utilisateur souhaite une autre passe.
5. Renvoyer les résultats à l’utilisateur
Ne forcez pas l’utilisateur à lire les journaux bruts sauf en cas d’échec. Une bonne interface montre la réponse, le graphique ou fichier généré, et une petite divulgation que du code a été exécuté. Fournissez un journal d’exécution extensible pour révision.
Pour les exécutions échouées, montrez une erreur concise et laissez le modèle réviser le code. Évitez de déverser de longues traces d’appel dans le chat principal, sauf si l’utilisateur débogue.
Gérer les fichiers, les sorties et les artefacts générés
La gestion des fichiers est là où de nombreux projets d’interpréteur de code deviennent désordonnés. Traitez les entrées et les sorties comme des objets séparés.
Les fichiers d’entrée doivent être copiés dans le bac à sable sous des chemins stables et assainis. Évitez de conserver les noms de chemin fournis par l’utilisateur qui contiennent des espaces, des caractères de shell ou des répertoires imbriqués. Conservez un mappage du nom d’affichage au chemin du bac à sable dans l’état de l’application.
Les fichiers générés doivent être analysés et classifiés avant de devenir des artefacts téléchargeables. Une image de graphique, un CSV nettoyé, un résumé JSON ou un rapport PDF peuvent être présentés directement. Un script généré, un fichier exécutable ou une archive doivent nécessiter une gestion plus stricte.
Pour la génération de graphiques, demandez au modèle de sauvegarder les fichiers image explicitement au lieu de se fier uniquement à l’affichage en ligne. Pour l’analyse de données, demandez un fichier de résumé lisible par machine ainsi qu’une explication en langage naturel. Cela donne à votre application quelque chose de stable à valider et à stocker.
Une politique d’artefact utile ressemble à ceci :
| Type d’artefact | Gestion par défaut |
|---|---|
Graphiques .png, .jpg, .webp, .svg |
Aperçu dans l’interface après vérification de la taille et du type |
Sorties de données .csv, .json, .xlsx |
Proposer en téléchargement et résumer les modifications |
Rapports .txt, .md, .pdf |
Aperçu ou téléchargement selon la taille |
.py, .sh, binaires, archives |
Ne pas exécuter ou ouvrir automatiquement ; nécessiter une révision explicite |
Si votre application prend en charge les projets persistants, stockez les artefacts acceptés en dehors du bac à sable. Le bac à sable doit rester jetable.
Définir la politique de paquets et de réseau
La plupart des flux de travail d’interpréteur de code ont besoin de paquets tels que pandas, NumPy, matplotlib, seaborn, scikit-learn ou openpyxl. La question est de savoir si les paquets sont préinstallés, installés à la demande ou intégrés dans des modèles de bac à sable personnalisés.
Les paquets préinstallés maintiennent l’exécution prévisible. Les installations à la demande sont flexibles mais peuvent ralentir les tâches et introduire une dérive des dépendances. Les modèles personnalisés sont généralement la meilleure voie de production une fois que vous connaissez vos charges de travail courantes.
Définissez une politique de paquets avant le lancement :
- quels paquets sont toujours disponibles
- si le modèle peut demander des installations de paquets
- si les installations peuvent atteindre les index de paquets publics
- si des versions fixes sont requises
- combien de temps les installations peuvent s’exécuter
- si les paquets compilés ou natifs sont autorisés
La politique réseau compte tout autant. De nombreuses tâches de données n’ont pas besoin d’accès Internet après le téléchargement des fichiers. Si un flux de travail a besoin d’API externes, acheminez les identifiants via des outils approuvés par l’application plutôt que de déposer des secrets larges dans le bac à sable. Le modèle ne doit pas recevoir de variables d’environnement non restreintes par défaut.
Appliquer les limites, les journaux, le nettoyage et la révision
Un interpréteur de code est une fonctionnalité de production, pas un exécuteur de cellule de démonstration. Mettez des limites autour dès le début.
Les contrôles minimaux doivent inclure :
- temps d’exécution maximum par cellule ou appel d’outil
- taille de sortie maximum pour stdout et stderr
- taille d’artefact maximum et nombre de fichiers
- limites CPU et mémoire appropriées pour la tâche
- extensions de fichier autorisées pour l’aperçu et le téléchargement
- limites de concurrence par utilisateur et par espace de travail
- règles de nettoyage pour les sessions et fichiers temporaires
Les journaux doivent répondre à trois questions : qui a demandé l’exécution, quel code a été exécuté et quelles sorties ont été produites. Stockez assez pour déboguer et auditer le flux de travail, mais évitez de conserver les données privées téléchargées plus longtemps que ne l’exige votre politique produit.
La révision humaine ou utilisateur est le contrôle final. Pour les analyses à faible risque, la révision peut signifier que l’utilisateur voit le graphique avant de le télécharger. Pour les flux de travail d’agent qui peuvent mettre à jour des tickets, écrire dans des bases de données ou appeler des API externes, la révision doit avoir lieu avant l’effet de bord, pas après.
Où Novita Agent Sandbox s’intègre
Novita Agent Sandbox est conçu pour les agents IA qui ont besoin d’environnements d’exécution isolés pour l’exécution de code, les flux de travail de navigateur, les tâches de type computer-use, les évaluations, les environnements d’apprentissage par renforcement et les flux de travail de longue durée. Pour une fonctionnalité d’interpréteur de code, cela signifie que le bac à sable peut servir de couche d’exécution pendant que votre application reste responsable de l’authentification utilisateur, de l’orchestration du modèle, de la politique de fichiers, de la révision et de la conservation spécifique au produit.
La documentation du bac à sable de Novita inclut des flux de travail du système de fichiers pour lire, écrire, télécharger, télécharger et surveiller des fichiers dans un bac à sable. Ces capacités correspondent directement aux besoins de l’interpréteur de code : déplacer les fichiers utilisateur dans l’environnement d’exécution, laisser le code générer des graphiques ou des données transformées, puis ramener les sorties sélectionnées dans l’application. Voir la documentation du système de fichiers du bac à sable Novita pour l’aperçu actuel des opérations sur les fichiers.
Si votre interpréteur dépasse un simple exécuteur Python, les modèles de bac à sable personnalisés peuvent aider à standardiser les dépendances et la configuration d’exécution. Cela est utile lorsque chaque session nécessite la même pile d’analyse, les mêmes outils en ligne de commande internes ou les mêmes bibliothèques spécifiques au projet. Commencez avec un petit ensemble de paquets autorisés, puis déplacez la configuration répétée dans des modèles une fois la charge de travail stabilisée.
Gardez les décisions d’intégration spécifiques à Novita séparées de l’architecture générale. Votre interpréteur de code a toujours besoin de politiques au niveau de l’application pour la visibilité des fichiers, l’installation de paquets, l’accès réseau, la conservation des journaux et la révision. Le bac à sable fournit l’exécution contrôlée ; votre produit définit comment cette exécution est utilisée.
Liste de vérification pour l’évaluation
Avant de livrer, testez la fonctionnalité avec des flux de travail réels et des invites contradictoires.
| Question | Que vérifier |
|---|---|
| Les utilisateurs peuvent-ils télécharger les bons fichiers ? | Taille du fichier, vérifications de type, vérifications du propriétaire et messages d’erreur clairs |
| Le modèle peut-il demander une exécution proprement ? | Appels d’outil structurés avec code, entrées, sorties attendues et délai d’attente |
| Le bac à sable est-il correctement délimité ? | Seuls les fichiers et variables d’environnement approuvés sont disponibles |
| Les paquets sont-ils prévisibles ? | Les paquets courants fonctionnent, les paquets refusés échouent clairement, les installations ont des limites |
| Les sorties sont-elles utilisables ? | Les graphiques s’affichent, les fichiers se téléchargent, les résumés correspondent aux artefacts générés |
| Les échecs sont-ils récupérables ? | Les traces d’appel sont capturées, le modèle peut réviser le code, les utilisateurs voient des erreurs concises |
| Les limites sont-elles appliquées ? | Les boucles infinies, les sorties énormes, les tâches gourmandes en mémoire et les installations longues se terminent |
| La révision est-elle intégrée ? | Les utilisateurs peuvent inspecter le code, les journaux et les artefacts avant les effets de bord importants |
| Le nettoyage est-il fiable ? | Les fichiers et sessions temporaires sont supprimés ou expirés selon le calendrier |
La meilleure première version est généralement étroite : exécution Python, un petit ensemble de paquets, téléchargement de fichiers, graphiques et fichiers téléchargeables, limites claires et un journal d’exécution. Ajoutez des installations de paquets plus larges, des sessions persistantes, un accès API externe et des effets de bord agentiques seulement après que la boucle de base est observable et fiable.
Conclusion
Un interpréteur de code fonctionne mieux lorsque le modèle peut demander une exécution, mais que votre application contrôle le bac à sable, les fichiers, les limites et l’étape de révision. Commencez avec un outil Python étroit, gardez les entrées et sorties explicites, et développez seulement après que le flux est stable.
FAQ
Quelle est la façon la plus sûre d’ajouter un interpréteur de code ?
Utilisez un bac à sable isolé, délimitez les fichiers d’entrée, limitez le temps d’exécution et la mémoire, et renvoyez des sorties structurées au lieu d’un accès shell brut.
Le modèle doit-il contrôler les installations de paquets ?
Uniquement selon une politique que vous définissez. De nombreuses applications commencent avec un ensemble de paquets fixe et ajoutent des installations plus tard si la charge de travail les nécessite.
Toutes les tâches d’interpréteur de code ont-elles besoin d’un accès réseau ?
Non. De nombreux flux de travail d’analyse fonctionnent entièrement hors ligne une fois que les fichiers de l’utilisateur sont téléchargés, ce qui maintient le modèle d’exécution plus simple.
Que doit voir l’utilisateur après l’exécution ?
Le résultat, les artefacts générés et un résumé concis du journal ou des erreurs, avec la possibilité d’inspecter le code ou de relancer la tâche.
