- Was ein Code-Interpreter tatsächlich tut
- Was eine Agent Runtime hinzufügt
- Wesentliche Entscheidungsdimensionen
- Wo Code-Interpreter am besten geeignet sind
- Wo Agent Runtimes am besten geeignet sind
- Hybride Muster: Beide in einer Anwendung nutzen
- Bewertung der Sandbox-Infrastruktur für jedes Modell
- FAQ
- Empfohlene Artikel
Code-Interpreter übernehmen isolierte, kurzlebige Ausführungsaufgaben – ein Skript ausführen, ein Ergebnis zurückgeben, alles verwerfen. Agent-Runtimes hingegen verwalten mehrstufige Workflows, die dauerhaften Zustand, Tool-Zugriff, Browsersteuerung, Datei-I/O oder langlebige Sitzungen erfordern. Die richtige Wahl hängt von Ihrem Workload ab, nicht von der Bezeichnung, die ein Produkt für sich verwendet.
Wenn es Ihnen um einen begrenzten Automatisierungsworkflow und nicht um eine allgemeine Architekturentscheidung für Anwendungen geht, lesen Sie How to Automate Tasks with AI.
Was ein Code-Interpreter tatsächlich tut
Ein Code-Interpreter bietet einem Sprachmodell die Möglichkeit, Code auszuführen und die Ausgabe zu sehen. Das Modell schreibt ein Python-Skript, der Interpreter führt es isoliert aus, und das Ergebnis wird als Text, Datei oder gerendertes Diagramm zurückgegeben. Wenn die Sitzung endet – oder in manchen Implementierungen sogar zwischen den Durchläufen – wird die Umgebung zurückgesetzt. Nichts bleibt erhalten.
Dieses Design ist beabsichtigt. Code-Interpreter priorisieren Sicherheit und Einfachheit vor Kontinuität. Die Isolationsgrenze ist eng, weil nur eines passieren muss: diesen Code ausführen, dieses Ergebnis zurückgeben.
Der praktische Footprint ist klein: eine isolierte Python-Laufzeitsumgebung (oder ähnlich), ein auf die Sitzung beschränktes Dateisystem, ausreichend Netzwerkzugriff, um bei Bedarf Bibliotheken oder externe Daten abzurufen, und ein Mechanismus zur Rückgabe von Artefakten. Die Sitzung kann 30 Sekunden oder 10 Minuten leben, aber die Anwedung behandelt sie als grundsätzlich vergänglich.
Dies passt zu mehreren hochwertigen Workloads:
- Einzelskript-Ausführung: der Benutzer bittet das Modell um eine Berechnung, und das Ergebnis wird als Zahl, Tabelle oder Datei zurückgegeben.
- Datenanalyse: CSV hochladen, Zusammenfassung generieren, Diagramm erstellen. Die Arbeit beginnt und endet innerhalb einer Interaktion.
- Schnelle Berechnungen: Mathe, Datentransformationen, Formatkonvertierungn und ähliche Aufgaben, die in einen einzelen Codeblock passen.
- Bildungsumgebungen: in denen jede Übung isoliert ist und keine Erwartung einer Sitzungskontinuität besteht.
Was Code-Interpreter nicht gut handhaben, ist alles, was erfordert, dass sich die Umgebung etwas merkt, eine Aktion außerhalb der Sandbox ausführt oder nach Bedigung der Benutzerinteraktion weiterarbeitet.
Was eine Agent Runtime hinzufügt
Eine Agent Runtime ist eine Ausführungsumgebung, die für Arbeiten konzipiert ist, die mehrere Schrite umfassen, externe Tools einbeziehen und Minuten oder Stund statt Sekunden dauern können. Die Sitzung wird nicht zwischen den Schritten verworfen – sie ist ein Arbeitsbereich, den der Agent nutzt, um auf ein Ziel hinzuarbeiten.
Die praktischen Erweiterungen gegenüber einem einfachen Interpreter sind erheblich:
- Dauerhafter Arbeitsbereich: Dateien, die in einem Schritt geschrieben wurden, sind im nächsten Schritt noch voranden. Ein Codierungagnt kann einen Branch erstellen, Dateien bearbeiten, Tests ausführen, Fehler beheben und einen Commit pushen – alles in einer Sitzung, ohne von vorne beginnen zu müssen.
- Installierte Pakete und Systemtools: Eine Agent Runtime unterstützt typischerweise die Installation von Abhängigkeiten, die Ausführung von Shell-Befehlen, den Aufruf von ClIs, das Starten von Hintergrundprozessen und die Arbeit mit einer echten Entwicklungsumgebung anstatt einer eingeschränkten Python-Sandbox.
- Browser- und Webzugrift: Ageneten, die Dokumentation lesen, mit Web-Apps interagieren, Formulare ausfüllen oder Web-Workflows automatisieren müssen, benötigen einen Browser in der Ausführungsumgebung. Ein Code-Interpreter hat kein Konzept einer permanenten Browsersitzung.
- Dateispeicher und Beständigkeit von Artefakten: Ausgaben, die länger als eine einzle Ausführng bestehen bleiben sollen – generierter Code, Zwischendaten, heruntergeladene Dateien, Sreenshots – benötigen ein Dateisystem, das über Schrite und in einigen Fällen über Sitzungen hinweg persistent ist.
- Langlebige Sitzungen: Manche Agent-Aufgaben dauern 20 Minuten. Manche längr. Eine Agent Rutime ist darauf ausgelegt, für die Dauer eines Workflows am Leben zu bleiben, nicht für jeden Funkionsaufruf hoch- und herunterzufahren.
- Multi-Tool-Orchestrierung: Echte Agent-Workflows umfassen den sequenziellen Aufruf mehrrer Tools – eine Websuche, gefolgt von einer Dateibearbeitung, gefolgt von einem Testlauf, gefolgt von einem Git-Push. Eine Agent Rutime ist für die zuverlässige Koordiation dieser Kette ausgelegt.
Der Trade-off ist real: Agent Rutimes sind komplexer im Betrieb, kosten pro Sitzng mehr als ein leichtigwichtiger Interpreter und legen eine größe Angriffsfläce offen, die eine sorgfältige Richtliniengonfiguration erfordert. Für Workloads, die in das Interpreter-Modell passen, ist das Hinzufügen dieser Komplexität Veschwendung.
Wesentliche Entscheidungsdimensionen
Die folgende Tabelle zeigt die praktischen Entscheidungskriterien. Die meisten Anwendungen fallen klar auf eine Seite; hybride Muster werden im nächsten Abschnitt für Fälle behandelt, die beide Bereiche umfassen.
| Dimenion | Code-Interpreter | Agent Runtime |
|---|---|---|
| Sitzungslebensdauer | Sekunden bis Minuten, vergänglich | Minuten bis Stundn, dauerhaft |
| Zustand zwischen Schriten | Verworfen oder eingeschränkt | Erhalten |
| Tool-Zugriff | Nur Code-Ausführung | CLI, Browser, Datei-I/O, APIs, Unterprozesse |
| Paketinstallation | Festes Image oder eingeschränkt | Dynamisch, mit Richtlinienkontrollen |
| Browser-/Web-Interaktion | Nicht verfügbar | Untertützt |
| Dateispeicher | Nur sitzungsbezogen | Über Schrite hinweg dauerhaft |
| Kostn pro Sitzung | Niedrig | Höher |
| Infrastrukturkomplexität | Niedrig | Höher |
| Human-in-the-loop-Kontrollpunkte | Nicht typisch | Häfig – Genehmigung vor Deployment, Merge oder externer Aktion |
| Paralelitätmodell | Viele paralelle kurze Sitzungen | Weniger, aber länger Sitzungen |
Sitzungslebensdauer und Zustandsanforderungen sind die schnellsten Filter. Wenn Ihr Workload zwischen den Durchläufen zurückgesetzt wird, verwenden Sie einen Interpreter. Wenn Ihr Workload über mehrre Durchläufe hinweg auf ein Ziel hinarbeitet, verwenden Sie eine Rutime.
Die Tool-Breite ist der zweite Filter. Browsersteuerung, Git-Operationen, CLI-Tools und externe API-Aufrufe erfordern eine Rutime. Wenn Ihr einzige Tool die Code-Ausführung ist, ist ein Interpreter ausreichend.
Human-in-the-loop-Kontrollpunkte weisen fast immer auf eine Rutime hin. Das Anhalten einer Sitzung, um auf Genehmigung zu warten, und so das Fortsezen erfordert einen dauerhaften Zustand und eine Sitzung, die fortgesetzt werden kann. Interpreter sind dafür nicht ausgelegt.
Wo Code-Interpreter am besten geeignet sind
Code-Interpreter sind die richtige Wahl, wenn die Ausführung begrenzt und in sich geschlossn ist. Die stärksten Anwendungsfälle:
- Datenanalyse-Assistenten: Der Benutzer lödt eine Datei hoch, stellt eine Frage und erhält Diagramme und Zusammenfassungen zurück. Die Arbeit ist erledigt, wenn das Modell die Ausgabe zurückgibt. Es gibt keinen nächsten Schrit, der von der Erinerung an den vorherigen abhängt.
- Mathe- und Berechnungstools: Taschenrechner, Einheitenumrechner, statisische Analysen, numerische Simuliationen. Diese sind einmalig: Eingabe rein, Ausgabe raus.
- Automatisierte Berichterstellung: Geplante Jobs, die einen Bericht aus einer Datenquelle generieren und per E-Mail versenden oder speichern. Der Job läuft, erzeugt ein Artefakt und wird beendet.
- Diagramm- und Visualisierungserstellung: Das Modell schreibt matplotlib- oder ähnlichen Code, der Interpreter führt ihn aus und der Benutzer erhält ein Bild. Keine dauerhafte Umgebung erforderlich.
- Sandbox-LLM-Tool-Nutzung: Wen ein Modell ein
code_interpreter-Tool benötigt, um über Daten nachzudenken, Berechnungen zu überprüfen oder Ausgaben zu formatieren – und sonst nichts – dann ist ein Code-Interpreter genau das, wofür die API entwickelt wurde.
Der Reiz von Interpretern in diesen Szenarien ist praktisch: Sie sind pro Sitzung günstiger, einfacher zu betreiben und einfacher zu sichern. Es gibt keinen dauerhaften Zustand, der verwaltet werden muss, keinen Sitzungslebenszyklus, der verfolgt werden muss, und die Angriffsfläche ist schmal, weil der Code einmal ausgeführt wird und die Umgebung verschwindet.
Wo Agent Runtimes am besten geeignet sind
Agent Runtimes sind die richtige Wahl, wenn eine Aufgabe nicht abgeschlossen werden kann, ohne mehrre Tools über die Zeit zu koordinieren, den Zustand über Schrite hinweg zu erhalten oder Aktionen außerhalb der Codeausfühungs-Sandbox durchzuführen.
- Codierungsagnten: Ein Agent, der eine Codebasis list, Änderungen schreibt, die Testsuite ausführt, Fehler behebt und einen Pull-Request eröffnet, benötigt einen dauerhaften Arbeisbereich mit Git, einem Terminal und einem Dateisystem. Dies ist architektonisch inkompatibel mit einem flüchtigen Interpreter.
- Browser- und Webautomatisiuerungsagenten: Dynamishe Inhalte scrapen, Formulare ausfüllen, mehrstufige Web-Workflows navigieren, strukturiere Daten aus visuellen Oberflächn extrahieren – all dies erfordert eine echte Browser-Sitzung, die lange genug besteht, um den Workflow abzuschließen.
- Recherche- und Datensammelpipelinen: Ageneten, die Dokumete aus mehrren Quellen abrufen, Informtionen krezreferenzieren, zwische Ergebnis auf Festplate schreiben und eine endgültige synthetisierte Ausgabe produziren, benötigen einen Arbeisbereich, der über alle dies Schriten hinweg beständig ist.
- Evalutions- und RL-Workloads: Viele Agenten-Episoden paralell ausführen, jede mit eigenem Zustand, Bewertungen verfolgen und Kontrollpukte schreiben – erfordert eine Rutime, die für Pralelität und Sitzungsisolierung in grßem Maßstab ausgelegt ist.
- Langlebige Infrastrukturagenten: Agenten, die Ressourcen bereitstelen, Bereitstellungen ausführen, Ausgaben überwachen und über ein mehrmintütiges oder mehstündiges Fenster auf Änderungen reagieren, benötigen ein Sitzungsodell, das pausieren, forsetzen und Kontrollpunkte sezen kann.
- Agentische Codierungstools wie Codex-artige Agenten oder IDE-verbundene Agenten, die Aktionen an einem echten Projekt durchführen, benötigen die vollständige Oberfläche einer Entwicklungsumgebung – keine Sandbox-Interpreter.
Die Kosten einer Rutime sind gerechtfertigt, wenn die Alternitive darin besthet, Zustandsverwaltung, Tool-Koordination und Sitzungspersistenz selbst manuell zusammenzustellen. Die Runtime stellt diese Infrastruktur bereit; Sie konfigurieren die Richtlinien.
Hybride Muster: Beide in einer Anwendung nutzen
Viele reale Anwendungen integrieren beide Muster. Ein Codierungsassistent könnte eine Agent Runtime für die gesamte Sitzung verwenden – Repository-Kontext verwalten, verfolgen, welche Dateien geändert wurden, einen Branch verwalten – während er einen Code-Interpreter speziell zum Ausführen von Tests oder zum Ausführen von Sandbox-Benutzerskripten als Unteroperation innerhalb des größeren Agent-Workflows aufruft.
Ein Datenanalyseprodukt könnte eine Agent Runtime verwenden, um den gesamten Workflow zu orchestrieren – Daten herunterladen, bereinigen, mehrere Quellen zusammenführen – während isolierte Interpreter-Aufrufe für die einzelnen Berechnungsschritte verwendet werden, bei denen eine enge Sandbox-Isolierung wichtig ist und der Zustand nicht persistent sein muss.
Das Muster sieht in der Praxis wie folgt aus:
- Die äußere Schicht ist eine Agent Runtime: Sie hält die Sitzung, koordiniert Tools und verwaltet den Zustand.
- Innere Operationen, die eine enge Isolierung erfordern, verwenden kurzlebige Code-Interpreter-Aufrufe als eines von vielen Tools.
- Die Agent Runtime entscheidet, wann der Interpreter aufgerufen wird, welche Eingaben übergeben werden und was mit der Ausgabe geschehen soll.
Dies ist kein komplexes architektonisches Muster; es verwendet lediglich jede Schicht für das, wofür sie entwickelt wurde. Die Agent Runtime verwaltet den Workflow; der Interpreter übernimmt bei Bedarf die Sandbox-Ausführung.
Bewertung der Sandbox-Infrastruktur für jedes Modell
Ob Sie einen verwalteten Sandbox-Anbieter bewerten oder Ihren eigenen entwerfen, die Fragen, die Sie beantworten müssen, unterscheiden sich erheblich je nachdem, für welches Modell Sie entwickeln.
Für Code-Interpreter-Workloads sind die Bewertungskriterien relativ eng gefasst:
- Wie hoch ist die Startlatenz? Sub-second-Start ist für interaktive Nutzung wichtig.
- Welche Sprachen und Pakete sind im Standardimage verfügbar?
- Können Benutzer zusätzliche Pakete installieren, und ist das durch Ihr Sicherheitsmodell erlaubt?
- Welche Ressourcenlimits gibt es (CPU, Arbeitsspeicher, Ausführungszeit)?
- Wie werden Sitzungsartefakte zurückgegeben – synchrone Antwort, Dateidownload oder presignierte URL?
- Gibt es eine Option für ein dauerhaftes Dateisystem oder wird alles beim Beenden verworfen?
Für Agent-Runtime-Workloads erweitern sich die Kriterien erheblich:
- Unterstützt die Umgebung dauerhafte Dateisysteme, die über Schritte in einer Sitzung hinweg erhalten bleiben?
- Kann die Sitzung angehalten und fortgesetzt werden – für Human-in-the-Loop-Workflows oder Kostenmanagement?
- Gibt es Browser-Unterstützung und wie ist diese konfiguriert?
- Welche Shell-Tools und CLIs sind verfügbar?
- Wie wird der Netzwerkzugriff kontrolliert – Ausgangsrichtlinien, DNS-Filterung, Ausgangs-Whitelists?
- Wie ist das Sitzungs-Parallelitätsmodell und wie skaliert es?
- Wie werden Geheimnisse injiziert und abgegrenzt?
- Welche Beobachtbarkeit existiert – Befehlsprotokolle, Dateiänderungsverfolgung, Ressourcenmetriken?
- Wie handhabt die Plattform langlebige Sitzungen, die typische Request-Response-Zyklen überdauern?
Novita Agent Sandbox wurde für Agent-Runtime-Workloads entwickelt – Codierungsagenten, Browserautomatisierung, Datenanalysepipelines und Evaluations-/RL-Workloads, die dauerhaften Zustand, Tool-Zugriff und Sitzungssteuerung benötigen. Es verwendet microVM-Isolierung, unterstützt Pause/Resume und integriert sich in die Modell-API-Plattform von Novita, sodass Teams, die Novita für LLM-Inferenz nutzen, Sandbox-Workloads auf derselben Plattform ausführen können. Für Teams, die die Sandbox-Infrastruktur für Agent-Workflows bewerten, deckt die Novita Agent Sandbox Dokumentation das Isolationsmodell, die Lebenszyklus-API und die Ressourcenkonfiguration ab.
Für Workloads, die wirklich nur Interpreter-basiert sind – Einzelskript, vergänglich, zustandslos – ist eine vollständige Agent-Runtime Overhead, den Sie nicht benötigen. Verwenden Sie das einfachere Tool.
Der praktische Test: Kann Ihr Workflow korrekt abgeschlossen werden, wenn die Ausführungsumgebung zwischen jedem Modell-Durchlauf zerstört und neu aufgebaut wird? Wenn ja, ist ein Interpreter wahrscheinlich ausreichend. Wenn nicht – weil Zustand, Tool-Zugriff oder Sitzungskontinuität wichtig sind – benötigen Sie eine Runtime.
FAQ
Was ist der Hauptunterschied zwischen einem Code-Interpreter und einer Agent Runtime?
Ein Code-Interpreter führt Code in einer Sandbox-Umgebung aus und verwirft die Umgebung, wenn die Sitzung endet. Eine Agent Runtime unterhält einen dauerhaften Arbeitsbereich – mit Dateien, installierten Tools, Browserzugriff und Sitzungszustand – über mehrere Schritte eines Workflows hinweg. Der Interpreter beantwortet “führe diesen Code aus und gib das Ergebnis zurück”; die Runtime beantwortet “arbeite auf dieses Ziel hin, so viele Schritte wie nötig.”
Kann ein Code-Interpreter Tools wie Websuche oder Dateizugriff nutzen?
Einige Code-Interpreter-Implementierungen unterstützen eine begrenzte Tool-Nutzung – Dateiuploads, Netzwerkaufrufe innerhalb der Sandbox oder die Rückgabe von Artefakten. Was sie nicht unterstützen, ist ein dauerhafter Arbeitsbereich, der den Zustand über Durchläufe hinweg überträgt, oder eine Browser-Sitzung, die einen einzelnen Funktionsaufruf überdauert. Wenn Ihre Anwendung eine Webseite lesen, eine Datei schreiben und dann in einem späteren Schritt auf diese Datei verweisen muss, benötigen Sie eine Runtime.
Ist eine Agent Runtime immer teurer als ein Code-Interpreter?
Pro Sitzung, ja. Agent Runtimes umfassen mehr Infrastruktur – dauerhafte Dateisysteme, langlebigere Prozesse, Browser- oder CLI-Zugriff – und diese Komponenten kosten mehr als eine kurzlebige Interpreter-Sandbox. Für Workloads, die tatsächlich eine mehrstufige Koordination erfordern, sind die Runtime-Kosten gerechtfertigt. Für einmalige Aufgaben ist es Overhead.
Wann sollte ich beide in derselben Anwendung verwenden?
Wenn der äußere Workflow einen dauerhaften Zustand erfordert, aber einzelne Unteroperationen von einer engen Isolierung profitieren. Ein Codierungsagent, der die Testsuite in einem Sandbox-Interpreter ausführt, oder eine Datenpipeline, die Berechnungsschritte an flüchtige Interpreter delegiert, während die Orchestrierungsschicht den Gesamtzustand hält, sind beides übliche hybride Muster.
Unterstützt Novita Agent Sandbox beide Modelle?
Novita Agent Sandbox wurde für Agent-Runtime-Workloads entwickelt – dauerhafte Arbeitsbereiche, Pause/Resume, Browserzugriff und mehrstufige Sitzungssteuerung. Für isolierte, flüchtige Interpreter-Aufrufe kann je nach Ihrem Anwendungsfall eine leichtere Ausführung angemessener sein. Weitere Informationen zu den aktuellen Funktionen finden Sie in der Novita Agent Sandbox Dokumentation.
Wie erkenne ich, ob mein Workload eine Runtime benötigt?
Der praktische Test: Kann Ihr Workflow korrekt abgeschlossen werden, wenn die Ausführungsumgebung zwischen jedem Modell-Durchlauf zerstört und neu aufgebaut wird? Wenn ja, ist ein Interpreter ausreichend. Wenn die Antwort nein ist – weil Zustand, Tool-Zugriff, Browsersteuerung oder Sitzungskontinuität wichtig sind – benötigen Sie eine Runtime.
