Schlankere Harnesses und Code ausführende Agenten eignen sich besser für frei formulierte Aufgaben, bei denen eine zu starre Orchestrierung die Leistung des Modells einschränken kann.
Damit sind Codeausführung und Sandboxing zu zentralen architektonischen Aspekten agentenbasierter Systeme geworden.
Das Agents SDK reduziert die Komplexität und den Codeaufwand bei der Entwicklung Code ausführender Agenten. In unseren Tests war bis zu sechsmal weniger Code nötig.
Lange Zeit beruhte der Fortschritt bei Agentensystemen auf einer besseren Orchestrierung: einer besseren Prompt-Gestaltung, besseren Tool-Schnittstellen, einem besseren Kontextmanagement und einer strafferen Ablaufsteuerung. Doch mit den zunehmenden Fähigkeiten von Coding-Agenten beginnt sich dieses Verhältnis zu verschieben.
Bei vielen offenen Workflows ist nicht mehr die Agentenschleife selbst der Engpass, sondern die Ausführungsebene: die Sandbox, in der das Modell Code schreibt, Befehle ausführt, Ergebnisse prüft und iteriert. Je mehr aufgabenbezogenes Reasoning in diese Umgebung verlagert wird, desto einfacher muss die umgebende Orchestrierung werden, damit das Modell seine Fähigkeiten voll entfalten kann.
Genau diesen Wandel ermöglicht die neue Version des Agents SDK. Unsere Tests während des Early Access haben gezeigt: Statt eine weitere Ebene mit Framework-Logik hinzuzufügen, gestaltet sie die Ausführungsebene modularer und kombinierbar, sodass der Rest des Systems schlank bleiben kann.
Beim Harness Engineering liegt es im Trend, das Harness auf seine kleinste wirksame Form zu reduzieren. Grundsätzlich ist das Harness die Software um das Modell: die Ebene, die Kontext, Tools, Ablaufsteuerung und Feedbackschleifen verwaltet, damit das Modell zuverlässig Aufgaben erledigen kann.
In den vergangenen Jahren gingen viele Leistungssteigerungen bei Agenten auf die Stärkung dieser Ebene zurück. Bessere Tools, ein besseres Gedächtnis und besserer Abruf, eine explizitere Zerlegung und eine straffere Orchestrierung machten Systeme häufig zuverlässiger und leistungsfähiger. In diesem Paradigma bedeutete Fortschritt vor allem, mehr Aufgabenlogik in der Software um das Modell abzubilden.
Dieses Muster verliert nun zumindest bei einer bestimmten Klasse offener Aufgaben an Bedeutung. Immer mehr Projekte und Veröffentlichungen deuten darauf hin, dass sich die Leistung nicht immer verbessert, wenn das Harness mehr Vorgaben macht. Beim unterstützten Programmieren, bei lang laufenden Aufgaben, der Browsernutzung, und Aufgaben mit langem Kontext zeigt sich immer wieder dasselbe Muster: Sobald das Modell intelligent genug ist, kann zu viel vorgegebene Aufgabenstruktur in der umgebenden Software eher zur Einschränkung als zum Vorteil werden.
Die Rolle des Harnesses verändert sich daher. Statt die Aufgabe durch starre Orchestrierung vorwegzunehmen, stellt das Harness zunehmend eine übersichtliche Ausführungsumgebung bereit: eine Sandbox, in der das Modell Zustände prüfen, Code ausführen, Fehler beheben und seinen Ansatz anpassen kann, während es an die Schnittstellen und Schutzmechanismen des Systems gebunden bleibt. Das ähnelt dem Wandel, den Andrej Karpathy in Software Engineer 3.0 beschrieben hat: Ein Teil der Logik, die zuvor in der Software steckte, wandert eine Ebene höher in den „Prompt“.
Daraus folgt nicht, dass Agentensysteme überall auf Struktur verzichten sollten. Viele Aufgaben profitieren weiterhin von expliziten Workflows, Heuristiken und deterministischen Schutzmechanismen, insbesondere wenn sie eng umrissen sind, in großer Zahl anfallen oder ein klares Erfolgskriterium haben. Wie wir in unserem vorherigen Beitrag über Heuristiken für die Gestaltung agentenbasierter Systeme dargelegt haben, bleibt eine starke Orchestrierung wichtig, wenn ein zuverlässiger logischer Ablauf möglich und wünschenswert ist.
Bei offenen Aufgaben verlagert sich der Schwerpunkt. Die Herausforderung besteht weniger darin, immer aufwendigere Orchestrierungsebenen zu entwerfen. Wichtiger ist es, Ausführungsumgebungen zu entwickeln, die einfach, beobachtbar und modular genug sind, damit das Modell darin effektiv arbeiten kann.
Sobald ein Agent Dateien lesen, Code schreiben, Shell-Befehle ausführen und lang laufende Aufgaben starten kann, verändert sich die technische Herausforderung. Die Schwierigkeit liegt nicht mehr allein in der Optimierung von Prompts oder der Weiterleitung an Tools. Da der Agent nun auf einem realen System arbeitet, sind solche Agenten deutlich leistungsfähiger. Gleichzeitig sind sie sicherheitskritischer, weil sie eine größere Angriffs- und Gefahrenfläche schaffen. Ein Agent, der Code ausführen kann, kann beispielsweise schädliche Aktionen vornehmen, wenn seine Umgebung unzureichend isoliert ist. Das zeigt auch die Sandbox Bench des AISI.
Sandboxing wird daher zu einem entscheidenden Aspekt von Agenten-Frameworks. In früheren Systemen wurde die Ausführung häufig als Zusatz behandelt: als ein an das Harness angefügtes Tool. Sobald die Ausführung jedoch zustandsbehaftet, lang laufend oder remote erfolgt, stößt dieser Ansatz an seine Grenzen. Die Verwaltung der Sandbox selbst, ihres Lebenszyklus, ihres Zustands, ihrer Schnittstellen und ihrer Anbindung an die Agentenschleife wird schnell zu einer eigenständigen Aufgabe der Systemarchitektur. Das ist einer der Gründe, warum immer mehr Anbieter verwaltete Umgebungen für die Codeausführung bereitstellen, darunter die Container API und das Shell-Tool von OpenAI, Modal, Cloudflare, Daytona und E2B.
Diese Abgrenzung ist wichtig, weil die Codeausführung eine stärkere Isolation und eine strengere Laufzeitkontrolle erfordert als der Rest des Harnesses. In der Praxis können schlecht implementierte Code ausführende Agenten drei geschäftskritische Risiken verursachen: unkontrollierte Rechenkosten, destruktive Aktionen in internen Systemen und die Offenlegung vertraulicher Informationen. Durch geeignete Containerisierung, Isolation und Schutzmechanismen für die Laufzeit lassen sich diese Risiken auf ein für den Praxiseinsatz vertretbares Maß begrenzen.
Man kann es sich so vorstellen, dass der Agent einen eigenen abgeschlossenen Workspace erhält statt der Schlüssel zum gesamten Büro. Innerhalb dieses Bereichs kann er weiterhin nützliche Aufgaben erledigen, aber nur in klar definierten Grenzen. Du kannst seine Rechenleistung begrenzen, festlegen, auf welche Systeme und Dateien er zugreifen darf, und steuern, welche Informationen ihm überhaupt zur Verfügung stehen.
Das beseitigt das Risiko nicht vollständig, verändert aber die Ausgangslage: Aus „ein Agent bewegt sich frei in deiner Infrastruktur“ wird „ein Agent arbeitet in einer kontrollierten Umgebung“. Wenn diese Ebene zum Standardbestandteil von Agentensystemen werden soll, muss das Framework sie direkt unterstützen. So wird die Sandbox zu einer modularen Ausführungsebene mit portablen Grundbausteinen, die Entwicklungsteams schnell einsetzen, anbieterübergreifend austauschen und skalieren können, ohne die Agentenlogik ständig zu überarbeiten.
Sobald ein Agent Code ausführt, muss auch die Sandbox selbst orchestriert werden. Der Wechsel von einem lokalen Machbarkeitsnachweis zu Remote-Ausführung, mehreren Backends oder lang laufenden Sitzungen erhöht den Betriebsaufwand exponentiell. Du brauchst eine einheitliche Methode, um Umgebungen zu erstellen, zu beenden, anzuhalten und fortzusetzen, ihren Zustand in Snapshots zu sichern, später erneut eine Verbindung herzustellen und all das anbieterübergreifend zu verwalten.
Nichts davon klingt besonders spannend, ist in der Praxis aber wichtig. Genau diese Art von Infrastruktur wird mühsam, wenn jedes Team eine agentenbasierte Pipeline von Grund auf neu entwickelt, insbesondere wenn sie nicht in das Agenten-Framework integriert ist …
Hier wird eine bessere Unterstützung durch das Framework wichtig. Wir erhielten Early Access zum neueren OpenAI Agents SDK und entwickelten damit selbst Agenten in Sandboxes. Auffällig war die Verschiebung des architektonischen Schwerpunkts: Das SDK behandelt die Ausführung als eigenständige Ebene und nicht als nebensächliches Tool. In der Praxis kannst du damit mit weniger Code einen Agenten in einer Sandbox starten, einen Snapshot der Sandbox erstellen oder die Ausführung fortsetzen. In einigen unserer Tests war etwa sechsmal weniger Code nötig. Anschließend kannst du das Backend wechseln, ohne die umgebende Agentenlogik neu zu schreiben.
Durch diese klarere Trennung der Zuständigkeiten kann sich das Harness auf Reasoning, Kontext und Workflow konzentrieren. Die Ausführungsebene kann sich auf Isolation, Portabilität und Laufzeitzustand konzentrieren. Diese Abstraktion erleichtert die Entwicklung leistungsfähigerer Coding-Agenten, die sich zugleich einfacher weiterentwickeln lassen. Sie können zwischen lokaler und Remote-Ausführung wechseln, länger laufende Aufgaben unterstützen und das Ausführungs-Backend ändern, ohne dass das gesamte System neu gestaltet werden muss.
Je mehr Aufgabenlogik vom Harness in das Modell verlagert wird, desto mehr Systemkomplexität wandert mit ihr in die Ausführungsebene. Codeausführung und Sandboxing sind heute zentrale architektonische Aspekte agentenbasierter Systeme, insbesondere bei programmierintensiven und offenen Aufgaben. Die Gestaltung der agentenbasierten Pipeline ist heute ebenso wichtig wie die Gestaltung der Umgebung, in der der Agent sicher, zuverlässig und über längere Zeit arbeiten kann.
Deshalb sind übergeordnete Abstraktionen für die Ausführung in Sandboxes wichtig. Das neuere OpenAI Agents SDK bewegt sich in diese Richtung und behandelt die Ausführung als modulare Systemebene: portabel zwischen Backends, zustandsbehaftet bei lang laufenden Aufgaben und einfach genug, um sie zu nutzen, ohne für jede neue Konfiguration dieselbe Infrastruktur neu aufzubauen.
Die übergreifende Erkenntnis lautet: Die nächste Generation von Agenten-Frameworks wird sich wahrscheinlich weniger dadurch auszeichnen, wie viel Orchestrierungslogik sie hinzufügt, sondern vielmehr dadurch, wie gut sie die Ausführungsumgebungen strukturiert, auf die Agenten zunehmend angewiesen sind.