Am 5. Februar 2026 hat OpenAI das wichtigste Update seines Agents SDK veröffentlicht, und die meisten Entwickler haben es übersehen. Version 0.8.0 bringt drei Features, die das SDK vom Experimentierstatus in die Produktionsreife heben: Tool-Level-Genehmigungen über needs_approval, vollständige Zustandsserialisierung durch RunState, und codex_tool-Integration für Agenten, die eigenständig Code schreiben und ausführen.
Vor v0.8 war ein Genehmigungsworkflow mit dem OpenAI Agents SDK ein Workaround-Festival. Tool-Aufrufe abfangen, State selbst verwalten, alles wieder zusammenflicken, wenn der Mensch endlich reagiert hat. Jetzt ist es ein First-Class-Feature. Drei Zeilen Code reichen für ein produktionsreifes Human-in-the-Loop-Muster.
Was sich geändert hat, warum es relevant ist, und wie jedes Feature mit funktionierendem Code aussieht.
Was v0.8.0 und v0.8.1 konkret mitbringen
Das v0.8.0-Release umfasst über 30 Pull Requests von 13 Mitwirkenden. Die Hauptfeatures sind HITL-Support und RunState-Management, aber das Release enthält auch Änderungen, die bestehenden Code betreffen.
Breaking Changes, die man kennen muss:
Synchrone Tool-Funktionen laufen jetzt auf Worker-Threads über asyncio.to_thread() statt auf dem Event Loop. Wenn ein Tool auf Thread-Local-State oder Thread-Affinität angewiesen ist, bricht es lautlos. Die Lösung: auf async migrieren oder Thread-Abhängigkeiten explizit machen.
MCP-Tool-Fehler werden jetzt anders behandelt. Das Standardverhalten gibt einen für das Modell sichtbaren Fehlerstring zurück, statt eine Exception zu werfen. Wer mit Exception-Handling für MCP-Tool-Aufrufe arbeitet, setzt mcp_config={"failure_error_function": None} für das alte Fail-Fast-Verhalten.
Weitere Neuerungen in v0.8.0:
- Strukturierter Agent-Tool-Input für typisierte Parameter
- Max-Turns-Error-Handler für kontrolliertes Scheitern statt
MaxTurnsExceeded - Session-Customization für persistente Konversationen
- MCP-Tool-Meta-Resolver für dynamische Tool-Discovery
- Bild-Antworten von MCP-Servern
- Konfigurierbare Tool-Fehlerformatierung
Version 0.8.1, einen Tag später am 6. Februar veröffentlicht, bringt vier Fixes: codex_tool-Thread-Reuse innerhalb von Run-Kontexten, konfigurierbare Max-Turns in der REPL, Persistence-Fixes für gestreamte Run-Again-Tool-Items, und Rückwärtskompatibilität für Handoff-Target-Resolution in Run-State-Agent-Maps.
Seitdem liefert das SDK im Wochentakt weiter. Auf PyPI steht seit März 2026 Version 0.12.5. Aber v0.8.0 ist die Version, ab der das SDK für Enterprise-Workflows tatsächlich brauchbar wurde.
needs_approval: Menschliche Kontrolle auf Tool-Ebene in drei Zeilen
Das einfachste HITL-Muster in jedem Framework. needs_approval=True an den Tool-Decorator, und der Agent pausiert vor der Ausführung. Keine State Machines. Keine Custom-Middleware. Keine Webhook-Infrastruktur.
from agents import Agent, Runner, function_tool
@function_tool(needs_approval=True)
def vertrag_senden(kunde_id: str, vertrag_typ: str, betrag: float):
"""Vertrag an Kunden senden. Erfordert menschliche Genehmigung."""
return vertrags_api.senden(kunde_id, vertrag_typ, betrag)
agent = Agent(
name="Vertragsagent",
instructions="Unterstütze bei der Vertragsverwaltung.",
tools=[vertrag_senden],
)
result = await Runner.run(agent, input="Sende den Servicevertrag über 15.000€ an Kunde K-4521")
Wenn der Agent vertrag_senden aufrufen will, pausiert der Run. Das result-Objekt enthält eine interruptions-Liste mit allen ausstehenden Genehmigungen:
if result.interruptions:
for item in result.interruptions:
print(f"Agent: {item.agent.name}")
print(f"Tool: {item.raw_item.name}")
print(f"Argumente: {item.raw_item.arguments}")
# Mensch prüft und entscheidet
result.state.approve(item) # oder result.state.reject(item)
# Fortsetzen ab dem Punkt, wo der Agent pausiert hat
result = await Runner.run(agent, state=result.state)
Dynamische Genehmigung per Funktion. Nicht jede Aktion braucht eine Genehmigung. Ein Vertrag über 500 Euro ist Routine. Ein Vertrag über 50.000 Euro braucht einen Menschen. Statt eines Booleans kann man eine Funktion übergeben:
async def betrag_pruefen(run_context, params, call_id):
import json
args = json.loads(params)
return args.get("betrag", 0) > 5000
@function_tool(needs_approval=betrag_pruefen)
def vertrag_senden(kunde_id: str, vertrag_typ: str, betrag: float):
"""Vertrag an Kunden senden."""
return vertrags_api.senden(kunde_id, vertrag_typ, betrag)
Jetzt verarbeitet der Agent kleine Verträge automatisch, pausiert aber bei allem über 5.000 Euro. Dieses Muster macht HITL im Unternehmensalltag praktikabel: Nicht jede Aktion braucht einen Menschen, nur die, die eine Risikoschwelle überschreiten. Besonders für DACH-Unternehmen, die unter dem EU AI Act menschliche Kontrolle für bestimmte KI-Anwendungen nachweisen müssen, ist das relevant.
RunState: Agent pausieren, serialisieren, morgen fortsetzen
Der Genehmigungsablauf oben funktioniert innerhalb eines einzigen Prozesses. Aber Produktions-Workflows bleiben selten in einem Prozess. Ein Mitarbeiter stellt eine Anfrage um 14 Uhr. Der Compliance-Beauftragte prüft sie am nächsten Morgen um 9 Uhr. Der Server kann dazwischen neu starten, ein Deployment erhalten oder herunterskaliert werden.
RunState löst dieses Problem, indem der gesamte Agent-Ausführungszustand serialisierbar wird. Man kann ihn in eine Datenbank, eine Message Queue oder eine Datei schreiben und den exakten Ausführungskontext später rekonstruieren.
# Agent trifft auf einen Genehmigungspunkt
result = await Runner.run(agent, input="Lösche alle inaktiven Kundendatensätze")
if result.interruptions:
# Gesamten Zustand serialisieren
state_json = result.state.to_json()
# Irgendwo speichern
await datenbank.speichern("ausstehend_123", json.dumps(state_json))
# --- Stunden oder Tage später, anderer Prozess ---
state_data = json.loads(await datenbank.laden("ausstehend_123"))
restored_state = await RunState.from_json(state_data, starting_agent=agent)
# Prüfen und genehmigen
for item in restored_state.get_interruptions():
restored_state.approve(item)
# Ausführung fortsetzen
result = await Runner.run(agent, state=restored_state)
Was serialisiert wird. RunState erfasst: die aktuelle Turn-Nummer, den aktiven Agenten, alle generierten Items und Modellantworten, den ursprünglichen User-Input, Genehmigungsstatus, Nutzungsmetriken und Session-IDs. Es ist ein vollständiger Snapshot des Agenten zum Zeitpunkt der Pause.
Kontext-Serialisierung. Bei einem eigenen Context-Objekt handhabt RunState gängige Typen automatisch: Dictionaries werden direkt durchgereicht, Pydantic-Modelle über model_dump() serialisiert und Dataclasses per asdict(). Für eigene Objekte gibt man explizite Serializer- und Deserializer-Funktionen an:
state_json = result.state.to_json(
context_serializer=lambda ctx: {"user_id": ctx.user_id, "session": ctx.session_id},
)
restored = await RunState.from_json(
state_data,
starting_agent=agent,
context_deserializer=lambda d: MeinKontext(user_id=d["user_id"], session=d["session_id"]),
)
Teilweise Genehmigung. Man muss nicht alle ausstehenden Genehmigungen auf einmal abarbeiten. Zwei von fünf genehmigen, fortsetzen, und der Agent führt die genehmigten Aufrufe aus, während die übrigen drei pausiert bleiben. Das ermöglicht mehrstufige Genehmigungsketten, bei denen ein Teamleiter Routineaktionen freigibt und ein Abteilungsleiter die kritischen übernimmt.
Das Codex Tool: Agenten, die Code schreiben und ausführen
Die codex_tool-Integration, in v0.8.1 mit Thread-Reuse verfeinert, verbindet den Agenten mit OpenAIs Codex für workspace-bezogene Aufgaben. Der Agent kann Shell-Befehle ausführen, Dateien bearbeiten und MCP-Tools eigenständig aufrufen.
Das ist kein simples “Code generieren und einfügen”. Das codex_tool erstellt eine Sandbox-Umgebung, in der der Agent:
- Shell-Befehle in einem kontrollierten Workspace ausführen kann
- Dateien innerhalb des Scopes lesen und ändern kann
- MCP-Tools in der Umgebung nutzen kann
- Kontext über mehrere Operationen hinweg beibehalten kann (Thread-Reuse, hinzugefügt in v0.8.1)
Thread-Reuse war der entscheidende v0.8.1-Fix. Ohne ihn startete jeder codex_tool-Aufruf von null. Mit ihm baut der Agent über eine Konversation hinweg Kontext auf: Datei lesen, Codebase verstehen, Änderungen vornehmen, verifizieren, alles im selben Thread.
codex_tool mit needs_approval kombinieren. Die eigentliche Stärke zeigt sich, wenn man beide Features mischt. Den Agenten frei Code schreiben lassen, aber Genehmigung vor der Ausführung verlangen:
from agents_extensions.experimental.codex import codex_tool
code_tool = codex_tool(needs_approval=True)
agent = Agent(
name="DevOps-Agent",
instructions="Unterstütze Entwickler bei Infrastrukturänderungen.",
tools=[code_tool],
)
Der Agent erstellt ein Datenbank-Migrationsskript, pausiert, zeigt dem Menschen das exakte SQL, das er ausführen will, und fährt erst nach Genehmigung fort. Genau dieses Muster braucht jedes Team, das KI-gestütztes DevOps betreibt.
Wie v0.8 im Vergleich zur Konkurrenz dasteht
Die HITL-Landschaft sieht nach v0.8 anders aus. LangGraph hat interrupt() für Graph-Level-Checkpoints seit Mitte 2025, und dieser Ansatz bietet mehr Kontrolle darüber, wo in einem komplexen Graph der Agent pausiert. CrewAI bietet human_input=True auf Task-Ebene. Pydantic AI integriert Genehmigungen in seine typsicheren Tool-Definitionen.
Der Ansatz des OpenAI Agents SDK ist gezielter und enger: Tool-Level-Genehmigung mit serialisierbarem State. Man bekommt nicht LangGraphs Graph-Level-Interrupts oder CrewAIs Task-Level-Human-Input. Aber man bekommt ein einfacheres mentales Modell und wohl die sauberste API für den häufigsten Anwendungsfall: “Pausiere, bevor dieses spezifische Tool ausgeführt wird.”
Das v0.8-Release ist auch wegen der Auslieferungsgeschwindigkeit bemerkenswert. Das SDK ging in etwa sieben Wochen von v0.0.1 auf v0.12.5. Das ist keine reine Versionsinflation. Jedes Release hat substanzielle Features hinzugefügt: MCP-Support, Handoffs, Guardrails, Tracing, WebSocket-Transport, Tool-Search-Integration. Für Teams, die bereits im OpenAI-Ökosystem arbeiten, wird das SDK zunehmend schwer zu ignorieren.
Für DACH-Unternehmen kommt ein weiterer Aspekt hinzu: Der EU AI Act verlangt für bestimmte KI-Systeme menschliche Aufsicht. Ein SDK, das HITL als nativen Baustein mitbringt statt als nachträglichen Workaround, vereinfacht die Compliance-Argumentation erheblich. Die DSGVO-konforme Speicherung des serialisierten RunState sollte dabei natürlich ebenfalls bedacht werden.
Häufig gestellte Fragen
Was ist needs_approval im OpenAI Agents SDK?
needs_approval ist ein Parameter am @function_tool-Decorator, der das SDK anweist, den Agent-Run vor der Tool-Ausführung zu pausieren. Er akzeptiert entweder True (immer Genehmigung erforderlich) oder eine async-Funktion, die einen Boolean für dynamische, bedingte Genehmigung zurückgibt. Der Run gibt dann Interruptions zurück, die ein Mensch über RunState.approve() und RunState.reject() genehmigen oder ablehnen kann.
Wie serialisiert und setzt man einen Agent-Run im OpenAI Agents SDK fort?
Mit RunState.to_json() serialisiert man den gesamten Ausführungszustand in ein JSON-kompatibles Dictionary, speichert es in einer Datenbank oder Queue, und rekonstruiert es später mit RunState.from_json(). Der serialisierte Zustand enthält die aktuelle Turn-Nummer, den aktiven Agenten, alle generierten Items, Modellantworten, Genehmigungsstatus und Nutzungsmetriken. Nach dem Wiederherstellen löst man ausstehende Genehmigungen auf und übergibt den State zurück an Runner.run().
Was ist das codex_tool im OpenAI Agents SDK?
Das codex_tool verbindet einen Agenten mit OpenAIs Codex für Shell-Befehle, Dateibearbeitung und MCP-Tool-Aufrufe in einem Sandbox-Workspace. Version 0.8.1 fügte Thread-Reuse hinzu, sodass der Agent Kontext über mehrere Operationen innerhalb derselben Konversation beibehält, anstatt jedes Mal von vorn zu beginnen.
Wie unterscheidet sich das OpenAI Agents SDK HITL von LangGraph interrupt?
LangGraphs interrupt() arbeitet auf Graph-Ebene und pausiert die Ausführung an bestimmten Knoten in einem Zustandsgraphen. Das needs_approval des OpenAI Agents SDK arbeitet auf Tool-Ebene und pausiert vor bestimmten Tool-Aufrufen. LangGraph bietet mehr Kontrolle über komplexe mehrstufige Workflows. Das OpenAI SDK bietet eine einfachere API für den häufigsten Fall: Stoppen vor einem sensiblen Tool.
Welche Version des OpenAI Agents SDK führte Human-in-the-Loop ein?
Version 0.8.0, veröffentlicht am 5. Februar 2026, führte Human-in-the-Loop-Support mit dem needs_approval-Parameter, RunState-Serialisierung und Interruption-Handling ein. Version 0.8.1 folgte am nächsten Tag mit codex_tool-Thread-Reuse und weiteren Fixes.