OpenAI erweitert das Agents SDK um zwei Bausteine, die beim Schritt von Demo zu Produktion oft fehlen: einen stärker modellnahen Harness für den Agent-Loop und eine native Sandbox-Schicht, in der Agenten Dateien, Shell-Befehle und Code sicher ausführen können. Ziel ist weniger Bastel-Infrastruktur, mehr kontrollierbare Ausführung, auch bei langen, mehrstufigen Aufgaben.
Übersicht:
Was sich im Agents SDK im April 2026 ändert
Die zentrale Änderung ist organisatorisch, nicht kosmetisch: Das Agents SDK bekommt eine standardisierte Laufzeit-Schicht, damit Agenten zuverlässig über viele Schritte hinweg arbeiten können, mit Dateien, Tools und kontrollierter Ausführung. Neu sind dafür ein ausgebauter Harness für den Agent-Loop und native Sandbox-Ausführung, beides als SDK-Bausteine statt als Eigenbau.
Der Hintergrund ist ein bekanntes Produktionsproblem: Prototypen laufen mit beliebigen Frameworks schnell an, scheitern später aber an Sichtbarkeit, Sicherheit und Wiederholbarkeit. In der Praxis landen Teams dann in einem der drei klassischen Kompromisse: flexible, modellagnostische Frameworks mit weniger Modellnähe, providernahe SDKs mit blinden Flecken im Laufzeitsystem, oder gemanagte Agent-APIs, die zwar Deployment vereinfachen, aber Ausführungsort und Datenzugriff stark einschränken.
Als grobe Markteinordnung hilft ein einfaches Schichtenbild:
- Modell: entscheidet, plant, ruft Tools auf.
- Harness: orchestriert Tool-Calls, Speicher, Dateien, Trace, Regeln.
- Compute: führt riskante Aktionen aus, zum Beispiel Shell und Code, idealerweise isoliert.
Ein Einstiegspunkt für die offiziellen Leitlinien ist die Seite Agents SDK im OpenAI API Guide.
Der neue Harness für lange Agentenläufe
Der Harness ist die „Steuerung“ des Agenten: Er sorgt dafür, dass ein Agent nicht nur Antworten generiert, sondern über viele Schritte hinweg verlässlich arbeitet, mit nachvollziehbarem Ablauf. In der aktuellen Ausbaustufe gehören dazu konfigurierbarer Arbeitsspeicher, Orchestrierung mit Sandbox-Bezug und Dateisystem-Tools, die auf Coding-Agent-Workflows zugeschnitten sind.
Wichtig ist die Standardisierung von Bausteinen, die sich 2026 in Agent-Systemen etabliert haben. Dazu zählen Tool-Anbindung über Model Context Protocol, progressive Offenlegung über „Skills“, sowie zusätzliche Projektanweisungen über Dateien wie AGENTS.md. Die Idee dahinter ist simpel: Agenten sollen nicht alles gleichzeitig sehen und dürfen nicht alles gleichzeitig tun, sie sollen kontrolliert in die nächste Komplexitätsstufe geführt werden.
Für praktische Tool-Mechaniken, etwa kontrollierte Shell-Ausführung und geprüfte Datei-Patches, sind die SDK-Dokumentationen ein guter Ausgangspunkt, zum Beispiel Tools im Agents SDK und die Sandbox-Übersicht Sandbox Guide (Python).
Klare Entscheidungsregel: Wenn ein Agent mehr als ein oder zwei Tool-Calls hintereinander zuverlässig ausführen muss, oder wenn er Dateien und Befehle koordiniert, lohnt sich ein Harness mit Trace, Speicherregeln und Approval-Gates. Bei Einzelschritten, zum Beispiel „API anrufen, Ergebnis formatieren“, ist ein leichterer Ansatz oft ausreichend.
Native Sandbox-Ausführung und Manifest
Viele nützliche Agenten brauchen einen Arbeitsplatz, der sich wie ein kleiner, kontrollierter Rechner verhält: Dateien lesen und schreiben, Abhängigkeiten installieren, Skripte laufen lassen. Genau dafür bringt das Agents SDK eine native Sandbox-Schicht mit, statt dass Teams diese Sicherheits- und Laufzeitlogik selbst zusammenstecken müssen.
Damit das nicht an einen einzelnen Anbieter kettet, führt das SDK eine Manifest-Abstraktion ein. In einem Manifest wird beschrieben, welche Ordner gemountet werden, wo Outputs landen, und welche Datenquellen verfügbar sind. So kann ein lokaler Prototyp mit denselben Strukturregeln in eine Produktionsumgebung wandern, ohne dass der Agent „raten“ muss, wo Inputs liegen oder wohin Ergebnisse gehören.
Unterstützt werden sowohl eigene Sandboxes als auch verschiedene Anbieter, darunter Cloudflare, Daytona, E2B, Modal, Runloop, Vercel und Blaxel. Beispiele für deren öffentliche Einstiegsseiten sind Cloudflare Sandbox, Daytona, E2B, Modal Sandboxes, Runloop, Vercel Sandbox und Blaxel.
Warum die Trennung von Harness und Compute zählt
Agent-Systeme sollten so gebaut werden, als ob sie angegriffen werden, insbesondere durch Prompt-Injection und Datenabfluss. Wenn der Harness die „Regelmaschine“ ist und die Sandbox das „Ausführungsgehäuse“, dann ist die Trennung zwischen beiden der Sicherheitsgurt: Credentials und sensible Steuerlogik bleiben außerhalb der Umgebung, in der modellgenerierter Code läuft.
Dazu kommt Robustheit: Wenn Agent-Status und Zwischenergebnisse außerhalb des Containers gehalten werden, ist ein abgebrochener Sandbox-Container kein Totalschaden. Das SDK setzt hier auf Snapshotting und Rehydration, also auf Wiederaufnahme aus einem Checkpoint in einem frischen Container, falls eine Umgebung ausfällt oder ausläuft.
Und schließlich Skalierung: Agent-Läufe können bei Bedarf mehrere isolierte Sandboxes nutzen, Sub-Aufgaben in getrennte Umgebungen schicken und parallel arbeiten, statt seriell durch einen einzigen Prozess zu schleppen. Das ist besonders relevant für Workflows, die viele Tools kombinieren oder große Dateibestände auswerten.
Praxisbeispiel Dataroom-Analyse mit Quellenpflicht
Ein typisches Szenario ist „Dataroom-Analyse“: Der Agent soll nur auf einen klar abgegrenzten Ordner zugreifen und Aussagen ausschließlich daraus ableiten. Das lässt sich im Agents SDK als Sandbox-Agent aufziehen, mit einer Manifest-Mount-Regel für den Datenordner und einer Anweisung, Quellen über Dateinamen zu belegen.
Vereinfacht sieht der Ablauf so aus:
- SDK installieren: zum Beispiel die Python-Bibliothek aus dem Agents-SDK-Ökosystem.
- Workspace erstellen: temporärer Ordner, darin ein Unterordner wie data/ mit Dateien.
- Sandbox-Agent konfigurieren: Modell, Regeln, Manifest-Mounts, Sandbox-Client.
- Aufgabe geben: Vergleich zweier Jahre aus einer Markdown-Tabelle.
Als Mini-Datenbasis reicht eine Datei mit Kennzahlen. Aus einer Tabelle mit FY2024 und FY2025 lassen sich die wichtigsten Veränderungen sauber herausarbeiten:
| Kennzahl | FY2024 | FY2025 | Veränderung |
|---|---|---|---|
| Umsatz | 98,7 Mio. USD | 124,3 Mio. USD | +25,6 Mio. USD (ca. +25,9%) |
| Betriebsergebnis | 12,4 Mio. USD | 18,6 Mio. USD | +6,2 Mio. USD (ca. +50,0%) |
| Operativer Cashflow | 17,9 Mio. USD | 24,1 Mio. USD | +6,2 Mio. USD (ca. +34,6%) |
Klare Entscheidungsregel: Sobald ein Agent „nur aus diesen Dateien“ arbeiten soll, ist eine Sandbox mit gemountetem Verzeichnis plus strikter Instruktion zur Quellbindung die robuste Standardwahl. Alles andere ist schwer prüfbar, weil der Agent ansonsten leicht unbemerkt externes Wissen, Tools oder ungewollte Dateien einmischt.
Preis, Verfügbarkeit und Roadmap
Die neuen Fähigkeiten sind laut OpenAI allgemein über die API verfügbar und werden nach Standard-API-Logik abgerechnet, also token- und toolbasiert, ohne separates Preismodell nur für den SDK-Teil. Die neuen Harness- und Sandbox-Funktionen starten zuerst im Python-Stack, TypeScript ist für eine spätere Version angekündigt.
In der Roadmap werden zusätzliche Agent-Fähigkeiten wie „Code Mode“ und Subagents genannt, außerdem mehr Integrationen und weitere Sandbox-Anbieter. OpenAI positioniert das SDK damit als Infrastruktur, die Agenten produktionsfähig macht, ohne Teams in einen einzigen Ausführungsort oder eine starre Managed-API zu zwingen.
Dass das nicht nur Theorie ist, zeigen frühe Tests mit Unternehmen aus stark regulierten oder dokumentenlastigen Bereichen, darunter Oscar Health, LexisNexis und Thomson Reuters. Oscar Health beschreibt den Nutzen vor allem als gesteigerte Zuverlässigkeit beim Automatisieren komplexer Klinikakten, inklusive sauberer Abgrenzung einzelner Behandlungsabschnitte in langen Dokumenten.