Als nächstesNächster Leitfaden
Entwerfen von Tools für LLM-Agenten
Technisch
Technischer Leitfaden
Eine Codeausführungs-Sandbox ist eine isolierte Umgebung, in der ein KI-Agent den von ihm geschriebenen Code ausführen kann, ohne den Host-Computer zu beschädigen, auf Daten zuzugreifen, die er nicht sehen sollte, oder unbegrenzte Ressourcen zu nutzen.
Dies ist wichtig, da ein Agent, der Code ausführen kann, weitaus leistungsfähiger ist (er kann Dateien berechnen, analysieren und seine eigene Arbeit testen), modellgeschriebener Code jedoch standardmäßig nicht vertrauenswürdig ist und fehlerhaft, verschwenderisch oder durch sofortige Injektion manipuliert sein kann.
Wenn ein Agent Code generiert, muss ihn etwas ausführen. Das direkte Ausführen dieses Codes auf einem Entwickler-Laptop oder Produktionsserver ist riskant: Der Code könnte Dateien löschen, Anmeldeinformationen aus Umgebungsvariablen lesen, Software installieren, Kryptowährung schürfen oder Netzwerkverbindungen öffnen. Eine Sandbox setzt eine Grenze zwischen dem Code und allem anderen. Es gibt mehrere Isolationsebenen mit unterschiedlichen Kompromissen. Standardcontainer (z. B. Docker) verwenden Linux-Namespaces und Cgroups, um Code eine eigene Sicht auf Prozesse, Dateien und Netzwerk zu geben und CPU und Speicher zu begrenzen. Sie starten schnell, aber jeder Container teilt sich den Kernel des Hosts, sodass eine Kernel-Schwachstelle dazu führen kann, dass Code entweicht. gVisor, ein Open-Source-Projekt von Google, fügt einen User-Space-Kernel hinzu, der Systemaufrufe abfängt und so verringert, was nicht vertrauenswürdiger Code mit dem echten Kernel in Berührung kommen kann. MicroVMs wie Firecracker, ursprünglich von AWS für Lambda und Fargate entwickelt, geben jedem Workload eine eigene, leichtgewichtige virtuelle Maschine und einen eigenen Kernel und booten gleichzeitig in Sekundenbruchteilen. Gehostete Sandbox-Dienste für Agenten wie E2B bauen auf diesem MicroVM-Ansatz auf. Im einfachsten Fall können WebAssembly-Laufzeiten und -Tools wie Pyodide Python in einem Browser oder einer Wasm-Sandbox ohne direkten Systemzugriff ausführen. Die Isolationstechnologie ist nur die Hälfte des Designs. Gute Sandboxes schränken außerdem das Netzwerk ein (häufig standardmäßig mit einer Zulassungsliste verweigern), mounten das Dateisystem mit Ausnahme eines Scratch-Verzeichnisses schreibgeschützt, halten Geheimnisse vollständig aus der Umgebung fern und erzwingen Zeit-, Speicher-, Prozessanzahl- und Festplattenlimits. Sie sind normalerweise kurzlebig: Sie werden pro Aufgabe erstellt und anschließend zerstört. Ein weit verbreitetes Missverständnis ist, dass eine Sandbox einen Agenten sicher macht. Es begrenzt den Schaden, der durch den Code selbst verursacht wird, hält einen Agenten jedoch nicht davon ab, falsche Antworten zu geben, und alle Tools oder Anmeldeinformationen, die Sie an die Sandbox übergeben, werden für den dort ausgeführten Code erreichbar, einschließlich Code, der als Reaktion auf injizierte Anweisungen geschrieben wurde.
Architekturentscheidungen beeinflussen über Jahre hinweg die Leistung und die Betriebskosten.
Technische Schulungen helfen Teams dabei, den richtigen Stack auszuwählen, nicht nur den neuesten.
Bessere technische Entscheidungen reduzieren Zuverlässigkeitsvorfälle in der Produktion.
Die Codeausführung entwickelt sich zu einer Standardfunktion für KI-Assistenten und -Agenten, sodass Sandboxing wahrscheinlich eher zu einem Massendienst mit sinnvollen Standardeinstellungen wird und nicht zu etwas, das jedes Team von Grund auf neu erstellt. Erwarten Sie weitere Arbeiten an einem schnelleren Start, Snapshot und Wiederaufnahme sowie detailliertere Richtlinien für den Netzwerk- und Dateizugriff, die pro Aufgabe angepasst werden können. Das schwierigere offene Problem ist die Politik und nicht die Isolation: Es muss entschieden werden, was ein Agent erreichen darf, und die Benutzer werden darüber informiert, wenn Agenten längere autonome Aktionen ausführen. Die Isolation bleibt neben Berechtigungen, Protokollierung und menschlicher Überprüfung eine Ebene unter mehreren.
Ein Datenanalyseassistent empfängt eine hochgeladene CSV-Datei, schreibt Pandas-Code, um sie zu bereinigen und Trends darzustellen, und führt diesen Code in einer Einweg-Sandbox aus, die am Ende der Sitzung gelöscht wird.
Ein Codierungsagent führt die Testsuite eines Repositorys in einem Container ohne ausgehenden Netzwerkzugriff aus, sodass ein bösartiges Abhängigkeitsskript keinen Quellcode oder Geheimnisse an einen externen Server senden kann.
Auf einer Bildungsplattform können Schüler einen KI-Tutor bitten, Python-Beispiele auszuführen, wobei jeder Lauf auf ein paar Sekunden CPU-Leistung und ein festes Speicherlimit begrenzt ist, damit eine versehentliche Endlosschleife den Dienst nicht zum Stillstand bringen kann.
Ein Forschungsteam stellt einem Agenten eine MicroVM mit einer schreibgeschützten Kopie eines Datensatzes und einem einzigen beschreibbaren Ausgabeordner zur Verfügung, sodass der Agent Ergebnisse erstellen kann, ohne die Originaldaten zu ändern oder zu löschen.
Die Optimierung eines Benchmarks kann umfassendere Systemschwächen verbergen.
Infrastruktur- und Wartungskosten werden oft unterschätzt.
Sicherheits- und Beobachtbarkeitslücken können größer werden, wenn die Systeme komplexer werden.
Definieren Sie vor der Implementierung Latenz-, Qualitäts- und Kostenziele.
Benchmark unter realistischen Last- und Datenbedingungen.
Instrumentenüberwachung auf Fehler, Drift und Benutzereinflüsse.
Bereiten Sie vor der Skalierung Rollback- und Incident-Response-Pfade vor.
Free newsletter
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Eine Codeausführungs-Sandbox ist eine isolierte Umgebung, in der ein KI-Agent den von ihm geschriebenen Code ausführen kann, ohne den Host-Computer zu beschädigen, auf Daten zuzugreifen, die er nicht sehen sollte, oder unbegrenzte Ressourcen zu nutzen. Dies ist wichtig, da ein Agent, der Code ausführen kann, weitaus leistungsfähiger ist (er kann Dateien berechnen, analysieren und seine eigene Arbeit testen), modellgeschriebener Code jedoch standardmäßig nicht vertrauenswürdig ist und fehlerhaft, verschwenderisch oder durch sofortige Injektion manipuliert sein kann.
Der Leitfaden erklärt, dass modellgeschriebener Code Fehler enthalten, überschüssige Ressourcen verbrauchen oder eingefügten Anweisungen folgen kann, sodass er innerhalb einer Grenze und nicht direkt auf einem Host ausgeführt werden sollte.
Container verwenden Namespaces und Cgroups, aber alle teilen sich den Host-Kernel, sodass eine Kernel-Schwachstelle einen Escape-Zugriff ermöglichen kann. MicroVMs geben jeder Arbeitslast einen eigenen Kernel.
gVisor von Google führt einen User-Space-Kernel aus, der Systemaufrufe verarbeitet und so reduziert, wie viel nicht vertrauenswürdiger Code des echten Host-Kernels erreichen kann.
Firecracker wurde für serverlose Workloads wie Lambda und Fargate entwickelt, bei denen viele isolierte Workloads schnell starten müssen.
Wenn eingeschleuste Anweisungen dazu führen, dass der Agent bösartigen Code schreibt, verhindert ein standardmäßiges Deny-Netzwerk, dass dieser Code Daten herausfiltert.
Lerne weiter
Weitere Leitfäden zu diesem Thema ausgewählt
Als nächstesNächster Leitfaden
Entwerfen von Tools für LLM-Agenten
Technisch