OpenAI Agents SDK oder Google ADK: Kein pauschaler Testsieger

Für Agenten, deren Werkzeuge, Zustand und Freigaben eng an ein bestehendes Backend gebunden sind, ist das OpenAI Agents SDK ein direkter Ausgangspunkt. Sein Agentenlauf findet in der eigenen Anwendung statt; Deployment, Werkzeugimplementierungen, Zustandsspeicher und Freigabeentscheidungen bleiben beim Anwendungsserver. So grenzt die OpenAI-Übersicht zum Agents SDK dessen Betriebsmodell ab.

Google ADK passt besonders dann, wenn feste Mehragentenabläufe und Entwicklungswerkzeuge eine wichtige Rolle spielen. Die technische ADK-Übersicht nennt Workflow-Agenten, Sitzungen mit Ereignissen und Zustand, eine Entwickleroberfläche sowie lokale Evaluation. Beide SDKs können Werkzeuge und Agenten koordinieren. Die Entscheidung hängt daran, wie derselbe fachliche Ablauf fortgesetzt, freigegeben, beobachtet und betrieben werden soll.

Laufzeit und Orchestrierung

Beim OpenAI Agents SDK führt ein Runner die Agentenschleife aus: Das Modell kann Werkzeuge aufrufen und Aufgaben an andere Agenten übergeben. Die Anwendung stellt die Werkzeuge bereit und kontrolliert die Umgebung, in der sie laufen. Für ein Backend mit bestehenden Berechtigungen und Geschäftsregeln ist das ein klarer Zuschnitt: Eine schreibende Aktion kann an der Grenze des eigenen Anwendungscodes geprüft werden.

ADK organisiert Ausführungen ebenfalls über einen Runner, bildet den Gesprächsverlauf aber ausdrücklich als Ereignisse einer Sitzung mit zugehörigem Zustand ab. Für mehrere Agenten stehen modellgesteuerte Weitergaben und feste Ablaufbausteine wie SequentialAgent, ParallelAgent und LoopAgent zur Verfügung. Eine vorgegebene Reihenfolge lässt sich damit im Workflow ausdrücken. Beim OpenAI SDK muss für dieselbe Aufgabe entschieden werden, ob ein Spezialagent die Antwort übernimmt oder als Werkzeug an den aufrufenden Agenten zurückliefert.

Modellwahl und Bereitstellung

ADK ist auf Gemini ausgerichtet und sieht über seine BaseLlm-Schnittstelle weitere Modelle vor. Auch beim OpenAI Agents SDK können Modelle und Anbieter konfiguriert werden. Diese Offenheit ersetzt keinen Funktionstest: Ein anderes Modell kann Werkzeugargumente, Übergaben oder Antworten anders erzeugen. Für einen fairen SDK-Vergleich sollten fachliche Anweisungen, Testanfragen und Datenquelle gleich bleiben; ein Modellwechsel ist eine eigene Variable.

Beim Deployment bietet ADK dokumentierte Wege zu Agent Runtime, Cloud Run und Google Kubernetes Engine sowie zu anderer containerfähiger Infrastruktur. Die ADK-Deploymentoptionen unterscheiden dabei einen verwalteten Agentendienst, einen Containerdienst und einen Kubernetes-Betrieb. Beim OpenAI Agents SDK wählt das Team die Laufzeit seiner Anwendung selbst. Wer bereits eine passende Anwendungsumgebung betreibt, kann diesen Zuschnitt bevorzugen; wer einen der beschriebenen ADK-Pfade nutzen will, muss dessen Betriebsanforderungen in die Entscheidung einbeziehen.

Ein Referenzablauf für beide SDKs

Ein hypothetisches Referenzprojekt macht die Unterschiede greifbar. Ein Agent beantwortet eine Frage zu einem Auftrag. Ein lesendes Werkzeug liefert dessen Status, ein schreibendes Werkzeug schlägt eine Änderung vor. Bevor die Änderung ausgeführt wird, entscheidet ein Mensch über die Freigabe. Nach einer Unterbrechung soll der Ablauf mit seinem bisherigen Zustand weitergehen und einen auswertbaren Trace liefern.

Im OpenAI Agents SDK erhält ein Agent dieselbe fachliche Anweisung und zwei typisierte Funktionstools. Das lesende Tool gibt strukturierte Auftragsdaten zurück. Das schreibende Tool prüft die Argumente und darf den Status erst nach der Freigabe ändern.
In ADK erhält ein LlmAgent die entsprechende Anweisung und zwei FunctionTools. Beide Implementierungen verwenden dieselbe simulierte Auftragsdatenquelle. So verändert ein abweichender Datenbestand nicht unbemerkt die Antwort.
Beide Varianten führen eine neue Nutzernachricht mit der bisherigen Unterhaltung zusammen. Zusätzlich wird die schreibende Aktion angehalten und nach einer Entscheidung fortgesetzt. Gesprächsfortsetzung und Wiederaufnahme eines unterbrochenen Laufs sind dabei getrennte Fälle.
Ein Exportadapter ordnet Werkzeugargumente, Freigabe, Ergebnis und Trace demselben Auftrag zu. Dieser Adapter ist Teil des Referenzprojekts: Eine lokale Ablaufansicht allein legt noch nicht fest, welche Daten im eigenen Monitoring ankommen.

Der gemeinsame Ablauf verlangt keine künstlich große Agentenhierarchie. Er legt offen, wer die Sitzung hält, wo eine ausstehende Aktion gespeichert wird und welche Komponente eine Schreibberechtigung durchsetzt. Falls später Spezialagenten hinzukommen, bleibt der Auftrag als fachlicher Testfall erhalten. Dann lässt sich zusätzlich beobachten, ob eine Übergabe den Kontext und die Zuständigkeit wie beabsichtigt verändert.

Freigabe und Zustand nach einer Pause

Die Freigabe ist der schärfste Unterschied im Referenzprojekt, weil eine falsche Fortsetzung eine reale Änderung auslösen könnte. Beim OpenAI Agents SDK entscheidet die Anwendung über die ausstehende Werkzeugaktion und muss den fortsetzbaren Zustand aufbewahren, wenn die Entscheidung später eintrifft. In der Implementierung gehören deshalb die Zuordnung zum Auftrag, die Prüfung der vorgeschlagenen Argumente und eine eindeutige Behandlung von Zustimmung oder Ablehnung zusammen.

ADK kann eine Werkzeugaktion ebenfalls für eine Bestätigung anhalten. Die ADK-Dokumentation zur Tool-Bestätigung kennzeichnet diese Funktion als experimentell und schließt DatabaseSessionService sowie VertexAiSessionService derzeit dafür aus. Wird ein gestoppter Lauf wieder aufgenommen, muss die Bestätigungsantwort zudem zur ursprünglichen Invocation gehören. Für Projekte, die einen der ausgeschlossenen Sitzungsdienste benötigen, ist diese Einschränkung schon bei der Architekturwahl relevant.

Was Traces und ADK Arena aussagen

Ein brauchbarer Trace verbindet Modellschritte, Werkzeugaufrufe, Unterbrechung und Ergebnis mit dem richtigen Auftrag. ADK bietet dafür Ablaufansichten und Tracing im Entwicklungsumfeld; das OpenAI Agents SDK führt Tracing als Teil seiner Beobachtungswerkzeuge. Für den Betrieb zählt zusätzlich, ob die benötigten Ereignisse exportiert und mit passenden Zugriffsrechten ausgewertet werden können. Das Referenzprojekt behandelt den Export deshalb als eigene Integrationsaufgabe.

Die als laufende Arbeit gekennzeichnete ADK-Arena-Studie untersuchte 51 Python-Frameworks: Die automatische Agentengenerierung bestand in 57 Prozent der Läufe ihre Validierung, die durchschnittlichen Generierungskosten streuten zwischen Frameworks um den Faktor 5,6, und kein Framework dominierte alle Aufgaben. Der Versuchsaufbau ließ KI-Modelle Agentencode schreiben und prüfte die entstandenen Agenten auf mehreren Benchmarks. Er ist kein isolierter Vergleich dieser beiden SDKs im hier beschriebenen Auftragsablauf.

Innerhalb dieses Aufbaus beeinflusste auch das Modell, das den Agentencode schrieb, die Aufgabenlösung deutlich, obwohl die erzeugten Agenten auf demselben Ausführungsmodell liefen. Versuche mit Dokumentation, Quellcode oder ohne Referenzmaterial zeigten außerdem, dass der Zugang zu einer einzelnen Informationsquelle den Erfolg nicht allein bestimmte. Für die SDK-Wahl folgt daraus eine begrenzte, aber nützliche Einsicht: API, erzeugter Code und Testumgebung wirken zusammen. Ob OpenAI Agents SDK oder Google ADK im eigenen Projekt besser passt, entscheidet vor allem der konkrete Ablauf mit seinen Werkzeugen, Freigaben und Betriebsbedingungen.

Lesen Sie auch: