Code-Interpreter bearbeiten isolierte, kurzlebige Ausführungsaufgaben – ein Skript ausführen, ein Ergebnis zurückgeben, alles verwerfen. Agent-Runtimes bewältigen mehrschrittige Workflows, die persistenten Zustand, Tool-Zugriff, Browsersteuerung, Datei-E/A oder langlebige Sitzungen erfordern. Die richtige Wahl hängt von Ihrem Workload ab, nicht von der Bezeichnung, die ein Produkt für sich selbst verwendet.
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, da die einzige Anforderung ist: Führe diesen Code aus, gib dieses Ergebnis zurück.
Der praktische Fußabdruck ist klein: eine abgesicherte Python- (oder ähnliche) Laufzeit, 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 lebt vielleicht 30 Sekunden oder 10 Minuten, aber die App behandelt sie als grundsätzlich flüchtig.
Dies passt sauber zu mehreren hochwertigen Workloads:
- Einzelskript-Ausführung: Ein Benutzer bittet das Modell, etwas zu berechnen, und das Ergebnis kommt als Zahl, Tabelle oder Datei zurück.
- Datenanalyse: Laden Sie eine CSV hoch, generieren Sie eine Zusammenfassung, erstellen Sie ein Diagramm. Die Arbeit beginnt und endet innerhalb einer Interaktion.
- Schnelle Berechnungen: Mathematik, Datentransformationen, Formatkonvertierungen und ähnliche Aufgaben, die in einen einzelnen Codeblock passen.
- Bildungsumgebungen: In denen jede Übung isoliert ist und keine Erwartung an Sitzungskontinuität besteht.
Was Code-Interpreter nicht gut handhaben, ist alles, was erfordert, dass sich die Umgebung an etwas erinnert, eine Aktion außerhalb der Sandbox ausführt oder weiterarbeitet, nachdem der Benutzer aufgehört hat zuzusehen.
Was eine Agent-Runtime hinzufügt
Eine Agent-Runtime ist eine Ausführungsumgebung, die für Arbeiten ausgelegt ist, die mehrere Schritte umfassen, externe Tools einbeziehen und Minuten oder Stunden statt Sekunden dauern können. Die Sitzung wird zwischen den Schritten nicht verworfen – sie ist ein Arbeitsbereich, den der Agent nutzt, um auf ein Ziel hinzuarbeiten.
Die praktischen Erweiterungen gegenüber einem einfachen Interpreter sind erheblich:
Persistenter Arbeitsbereich: In einem Schritt geschriebene Dateien sind im nächsten Schritt noch vorhanden. Ein Codierungsagent kann einen Branch erstellen, Dateien bearbeiten, Tests ausführen, Fehler beheben und einen Commit pushen – alles innerhalb einer Sitzung, ohne von vorne beginnen zu müssen.
Installierte Pakete und Systemtools: Eine Agent-Runtime unterstützt typischerweise die Installation von Abhängigkeiten, das Ausführen von Shell-Befehlen, das Aufrufen von CLIs, das Starten von Hintergrundprozessen und das Arbeiten mit einer echten Entwicklungsumgebung anstelle einer eingeschränkten Python-Sandbox.
Browser- und Webzugriff: Agenten, 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 persistenten Browsersitzung.
Dateispeicher und Artefaktpersistenz: Ausgaben, die eine einzelne Ausführung überdauern müssen – generierter Code, Zwischendaten, heruntergeladene Dateien, Screenshots – benötigen ein Dateisystem, das über Schritte und in einigen Fällen über Sitzungen hinweg persistent ist.
Langlebige Sitzungen: Einige Agentenaufgaben dauern 20 Minuten. Manche länger. Eine Agent-Runtime ist darauf ausgelegt, für die Dauer eines Workflows aktiv zu bleiben, nicht für jeden Funktionsaufruf hoch- und herunterzufahren.
Multi-Tool-Orchestrierung: Echte Agenten-Workflows beinhalten das sequenzielle Aufrufen mehrerer Tools – eine Websuche, gefolgt von einer Dateibearbeitung, gefolgt von einem Testlauf, gefolgt von einem Git-Push. Eine Agent-Runtime ist darauf ausgelegt, diese Kette zuverlässig zu koordinieren.
Der Kompromiss ist real: Agent-Runtimes sind komplexer zu betreiben, kosten pro Sitzung mehr als ein leichtgewichtiger Interpreter und setzen eine größere Angriffsfläche aus, die eine sorgfältige Richtlinienkonfiguration erfordert. Für Workloads, die dem Interpreter-Modell entsprechen, ist das Hinzufügen all dieser Komplexität Verschwendung.
Wichtige Entscheidungsdimensionen
Die folgende Tabelle zeigt die praktischen Entscheidungskriterien. Die meisten Apps fallen klar auf eine Seite; hybride Muster werden im nächsten Abschnitt für Fälle behandelt, die beide Bereiche abdecken.
| Dimension | Code-Interpreter | Agent-Runtime |
|---|---|---|
| Sitzungslebensdauer | Sekunden bis Minuten, flüchtig | Minuten bis Stunden, persistent |
| Zustand zwischen Schritten | Verworfen oder eingeschränkt | Beibehalten |
| Tool-Zugriff | Nur Code-Ausführung | CLI, Browser, Datei-E/A, APIs, Unterprozesse |
| Paketinstallation | Festes Image oder eingeschränkt | Dynamisch, mit Richtlinienkontrollen |
| Browser-/Web-Interaktion | Nicht verfügbar | Unterstützt |
| Dateispeicher | Nur sitzungsbezogen | Über Schritte hinweg persistent |
| Kosten pro Sitzung | Niedrig | Höher |
| Infrastrukturkomplexität | Niedrig | Höher |
| Human-in-the-Loop-Kontrollpunkte | Nicht typisch | Üblich – Genehmigung vor Deployment, Merge oder externer Aktion |
| Nebenläufigkeitsmodell | Viele parallele kurze Sitzungen | Weniger, längere 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 mehrere Durchläufe auf ein Ziel hinarbeitet, verwenden Sie eine Runtime.
Die Tool-Breite ist der zweite Filter. Browsersteuerung, Git-Operationen, CLI-Tools und externe API-Aufrufe erfordern eine Runtime. Wenn Ihr einziges Tool die Code-Ausführung ist, ist ein Interpreter ausreichend.
Human-in-the-Loop-Kontrollpunkte weisen fast immer auf eine Runtime hin. Das Anhalten einer Sitzung, um auf eine Genehmigung zu warten, und dann das Fortsetzen erfordert einen persistenten Zustand und eine Sitzung, die fortgesetzt werden kann. Interpreter sind dafür nicht ausgelegt.
Wo Code-Interpreter am besten passen
Code-Interpreter sind die richtige Wahl, wenn die Ausführung begrenzt und in sich geschlossen ist. Die stärksten Anwendungsfälle:
Datenanalyse-Assistenten: Der Benutzer lädt eine Datei hoch, stellt eine Frage, erhält Diagramme und Zusammenfassungen zurück. Die Arbeit ist abgeschlossen, wenn das Modell die Ausgabe zurückgibt. Es gibt keinen nächsten Schritt, der von der Erinnerung an den vorherigen abhängt.
Mathematik- und Berechnungstools: Taschenrechner, Einheitenumrechner, statistische Analysen, numerische Simulationen. Diese sind einstufig: Eingabe rein, Ausgabe raus.
Automatisierte Berichterstellung: Geplante Aufgaben, die aus einer Datenquelle einen Bericht generieren und per E-Mail versenden oder speichern. Der Job läuft, erzeugt ein Artefakt und beendet sich.
Diagramm- und Visualisierungserstellung: Das Modell schreibt matplotlib- oder ähnlichen Code, der Interpreter führt ihn aus, und der Benutzer erhält ein Bild. Keine Notwendigkeit für eine persistente Umgebung.
Sandboxed LLM-Tool-Nutzung: Wenn ein Modell ein code_interpreter-Tool benötigt, um über Daten nachzudenken, Berechnungen zu überprüfen oder Ausgaben zu formatieren – und sonst nichts –, ist ein Code-Interpreter genau das, wofür die API entwickelt wurde.
Der Reiz von Interpretern in diesen Szenarien ist praktisch: Sie sind billiger pro Sitzung, einfacher zu betreiben und einfacher zu sichern. Es gibt keinen persistenten Zustand, der verwaltet werden muss, keinen Sitzungslebenszyklus, der nachverfolgt werden muss, und die Angriffsfläche ist schmal, da der Code einmal ausgeführt wird und die Umgebung verschwindet.
Wo Agent-Runtimes am besten passen
Agent-Runtimes sind die richtige Wahl, wenn eine Aufgabe nicht abgeschlossen werden kann, ohne mehrere Tools über die Zeit zu koordinieren, den Zustand über Schritte hinweg zu halten oder Aktionen außerhalb der Code-Ausführungs-Sandbox durchzuführen.
Codierungsagenten: Ein Agent, der eine Codebasis liest, Änderungen schreibt, die Testsuite ausführt, Fehler behebt und einen Pull-Request öffnet, benötigt einen persistenten Arbeitsbereich mit Git, einem Terminal und einem Dateisystem. Dies ist architektonisch inkompatibel mit einem flüchtigen Interpreter.
Browser- und Web-Automatisierungsagenten: Dynamische Inhalte scrapen, Formulare ausfüllen, mehrschrittige Web-Workflows navigieren, strukturierte Daten aus visuellen Schnittstellen extrahieren – all dies erfordert eine echte Browsersitzung, die lange genug besteht, um den Workflow abzuschließen.
Forschungs- und Datensammel-Pipelines: Agenten, die Dokumente aus mehreren Quellen abrufen, Informationen kreuzreferenzieren, Zwischenergebnisse auf die Festplatte schreiben und eine endgültige synthetisierte Ausgabe produzieren, benötigen einen Arbeitsbereich, der über all diese Schritte hinweg persistent ist.
Evaluierungs- und RL-Workloads: Viele Agenten-Episoden parallel ausführen, jede mit eigenem Zustand, Punktestände verfolgen und Checkpoints schreiben, erfordert eine Runtime, die für Nebenläufigkeit und Sitzungsisolation im großen Maßstab ausgelegt ist.
Langlaufende Infrastrukturagenten: Agenten, die Ressourcen bereitstellen, Deployments ausführen, Ausgaben überwachen und auf Änderungen über ein mehrminütiges oder mehrstündiges Fenster reagieren, benötigen ein Sitzungsmodell, das pausieren, fortsetzen und Checkpoints setzen kann.
Agentic Coding Tools wie Codex-artige Agenten oder IDE-verbundene Agenten, die Aktionen an einem echten Projekt durchführen, benötigen die volle Oberfläche einer Entwicklungsumgebung – keine sandboxed Interpreter.
Die Kosten einer Runtime sind gerechtfertigt, wenn die Alternative darin besteht, Zustandsverwaltung, Tool-Koordination und Sitzungspersistenz manuell zusammenzustellen. Die Runtime bietet diese Infrastruktur; Sie konfigurieren die Richtlinien.
Hybride Muster: Verwendung beider in einer App
Viele reale Anwendungen implementieren beide Muster. Ein Codierungs-Assistent könnte eine Agent-Runtime für die gesamte Sitzung verwenden – Repository-Kontext pflegen, nachverfolgen, 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 sandboxed benutzergenerierten Skripten als Teiloperation innerhalb des größeren Agenten-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 Sandboxing wichtig ist und der Zustand nicht persistent sein muss.
Das Muster sieht in der Praxis so 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 Isolation erfordern, verwenden kurzlebige Code-Interpreter-Aufrufe als ein Tool unter vielen.
- 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 bedeutet lediglich, jede Schicht für das zu verwenden, wofür sie entwickelt wurde. Die Agent-Runtime verwaltet den Workflow; der Interpreter übernimmt bei Bedarf die sandboxed Ausführung.
Bewertung der Sandbox-Infrastruktur für jedes Modell
Unabhängig davon, ob Sie einen verwalteten Sandbox-Anbieter evaluieren oder Ihre eigene Sandbox entwerfen, unterscheiden sich die Fragen, die Sie beantworten müssen, 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? Eine Startzeit unter einer Sekunde ist für die interaktive Nutzung wichtig.
- Welche Sprachen und Pakete sind im Standard-Image verfügbar?
- Können Benutzer zusätzliche Pakete installieren, und ist dies durch Ihr Sicherheitsmodell erlaubt?
- Welche Ressourcengrenzen gibt es (CPU, Arbeitsspeicher, Ausführungszeit)?
- Wie werden Sitzungsartefakte zurückgegeben – synchrone Antwort, Dateidownload oder Presigned-URL?
- Gibt es eine Option für ein persistentes Dateisystem, oder wird alles beim Beenden verworfen?
Für Agent-Runtime-Workloads erweitern sich die Kriterien erheblich:
- Unterstützt die Umgebung persistente Dateisysteme, die über mehrere Schritte in einer Sitzung hinweg erhalten bleiben?
- Kann die Sitzung pausiert und fortgesetzt werden – für Human-in-the-Loop-Workflows oder Kostenmanagement?
- Gibt es Browserunterstützung, und wie ist diese konfiguriert?
- Welche Shell-Tools und CLIs sind verfügbar?
- Wie wird der Netzwerkzugriff kontrolliert – Ausgangsrichtlinien, DNS-Filterung, ausgehende Zulassungslisten?
- Wie ist das Sitzungs-Nebenläufigkeitsmodell, und wie skaliert es?
- Wie werden Secrets injiziert und abgegrenzt?
- Welche Beobachtbarkeit gibt es – Befehlsprotokolle, Dateiänderungsverfolgung, Ressourcenmetriken?
- Wie geht die Plattform mit langlebigen Sitzungen um, die typische Request-Response-Zyklen überdauern?
Novita Agent Sandbox ist für Agent-Runtime-Workloads konzipiert – Codierungsagenten, Browserautomatisierung, Datenanalyse-Pipelines und Evaluierungs-/RL-Workloads, die persistenten Zustand, Tool-Zugriff und Sitzungskontrolle benötigen. Es verwendet microVM-Isolation, unterstützt Pause/Resume und integriert sich in die Novita-Modell-API-Plattform, sodass Teams, die Novita für LLM-Inferenz nutzen, Sandbox-Workloads auf derselben Plattform ausführen können. Für Teams, die Sandbox-Infrastruktur für Agenten-Workflows evaluieren, deckt die Novita Agent Sandbox Dokumentation das Isolationsmodell, die Lebenszyklus-API und die Ressourcenkonfiguration ab.
Für Workloads, die wirklich nur Interpreter sind – einzelne Skripte, flüchtig, zustandslos – ist eine vollständige Agent-Runtime ein 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 Modelldurchlauf zerstört und neu aufgebaut wird? Wenn ja, ist ein Interpreter wahrscheinlich ausreichend. Wenn nein – 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 sandboxed Umgebung aus und verwirft die Umgebung, wenn die Sitzung endet. Eine Agent-Runtime unterhält einen persistenten 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, über so viele Schritte wie nötig".
Kann ein Code-Interpreter Tools wie Websuche oder Dateizugriff verwenden?
Einige Code-Interpreter-Implementierungen unterstützen eine begrenzte Tool-Nutzung – Datei-Uploads, Netzwerkaufrufe innerhalb der Sandbox oder die Rückgabe von Artefakten. Was sie nicht unterstützen, ist ein persistenter Arbeitsbereich, der den Zustand über Durchläufe hinweg trägt, oder eine Browsersitzung, die einen einzelnen Funktionsaufruf überdauert. Wenn Ihre App 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 beinhalten mehr Infrastruktur – persistente Dateisysteme, langlebigere Prozesse, Browser- oder CLI-Zugriff – und diese Komponenten kosten mehr als eine kurzlebige Interpreter-Sandbox. Für Workloads, die wirklich eine mehrschrittige Koordination erfordern, sind die Runtime-Kosten gerechtfertigt. Für einstufige Aufgaben sind sie Overhead.
Wann sollte ich beide in derselben Anwendung verwenden?
Wenn der äußere Workflow einen persistenten Zustand erfordert, aber einzelne Teiloperationen von einer engen Isolation profitieren. Ein Codierungsagent, der die Testsuite in einer sandboxed Interpreter ausführt, oder eine Datenpipeline, die Berechnungsschritte an flüchtige Interpreter delegiert, während die Orchestrierungsschicht den Gesamtzustand hält, sind beides übliche Hybridmuster.
Unterstützt Novita Agent Sandbox beide Modelle?
Novita Agent Sandbox ist für Agent-Runtime-Workloads konzipiert – persistente Arbeitsbereiche, Pause/Resume, Browserzugriff und mehrschrittige Sitzungskontrolle. Für isolierte, flüchtige Interpreter-Aufrufe kann eine leichtgewichtigere Ausführung je nach Anwendungsfall angemessener sein. Siehe die Novita Agent Sandbox Dokumentation für aktuelle Funktionsdetails.
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 Modelldurchlauf 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.
