Was ist OpenAI AgentKit

OpenAI AgentKit ist ein Bündel von Tools zum Erstellen, Bereitstellen und Messen von KI-Agenten auf der OpenAI-Plattform. Wenn Sie jemals einen Agenten manuell eingerichtet haben, indem Sie Orchestrierungscode, Konnektoren und Evaluierungsskripte jonglierten, war AgentKit OpenAIs Antwort auf diese Fragmentierung. Es gibt eine wichtige Einschränkung im Jahr 2026, die Sie vor einer Verpflichtung kennen sollten. Dieser Leitfaden erläutert daher, was AgentKit beinhaltet, für wen es gedacht ist, einen übergeordneten Erstellungsablauf und wo API-Testtools wie Apidog ins Spiel kommen, wenn Ihr Agent externe Dienste aufruft.

Was AgentKit ist

OpenAI stellte AgentKit auf dem DevDay am 6. Oktober 2025 vor. Es war kein einzelnes Produkt, sondern eine Reihe von Komponenten, die auf der bestehenden OpenAI API und dem OpenAI Agents SDK aufsetzen und darauf abzielen, die Lücke zwischen „Ich habe eine Agentenidee“ und „Ich habe einen Agenten, der vor Benutzern läuft“ zu schließen.

Vor AgentKit bedeutete der Aufbau eines Agenten in der Regel, Orchestrierungslogik ohne Versionierung, benutzerdefinierte Konnektoren für jede Datenquelle, selbst entwickelte Evaluierungspipelines, manuelle Prompt-Anpassungen und eine beträchtliche Menge an Frontend-Arbeit zusammenzufügen, bevor etwas ausgeliefert wurde. AgentKit bündelte Lösungen für diese Probleme unter einem Dach.

Eines vorweg, da es die Art und Weise verändert, wie Sie damit umgehen sollten: Am 3. Juni 2026 kündigte OpenAI an, zwei Teile von AgentKit, Agent Builder und Evals, einzustellen. Weitere Details zu den Daten finden Sie unten. Die wichtigste Erkenntnis ist, dass der dauerhafte, Code-first-Ansatz durch AgentKit das Agents SDK ist, und darauf sollten Sie aufbauen, wenn Sie etwas Nachhaltiges schaffen wollen.

Die Komponenten von AgentKit

AgentKit wurde mit vier Hauptkomponenten ausgeliefert. Hier erfahren Sie, was jede einzelne davon leistet und wie ihr aktueller Status ist.

Agent Builder

Agent Builder ist eine visuelle Oberfläche zum Entwerfen mehrstufiger Agenten-Workflows. Sie ziehen Knoten für jeden Schritt per Drag & Drop, verbinden sie zu einem Flow, können Ausführungen mit realen Eingaben vorab überprüfen und versionierte Snapshots des Workflows veröffentlichen. Es ist der „keine leere Seite“-Einstiegspunkt, mit Vorlagen, von denen Sie ausgehen können.

Ein nützliches Detail für Entwickler: Agent Builder ist keine Sackgasse abseits des Codes. Es verfügt über einen Agents SDK-Tab, der Ihren Workflow als ausführbares Python oder TypeScript exportiert, sodass Sie das visuelle Design übernehmen und in Ihrer eigenen Umgebung erweitern können.

Der Status ist hier wichtig. OpenAI stellt den Agent Builder ein, mit einem Plattform-Abschaltdatum am 30. November 2026, gemäß seiner Deprecations-Seite. Wenn Sie heute neu anfangen, behandeln Sie die visuelle Oberfläche als Prototyping-Hilfe und planen Sie, im SDK-Code zu landen.

ChatKit

ChatKit ist eine einbettbare Chat-Oberfläche, um Ihren Agenten vor Benutzer zu bringen. Anstatt eine Chat-UI von Grund auf neu zu erstellen, fügen Sie eine Webkomponente ein, verweisen sie auf eine veröffentlichte Workflow-ID und passen Design und Verhalten an. Es verarbeitet Streaming-Antworten, Threads und die übliche Chat-Infrastruktur.

ChatKit bleibt verfügbar und ist der empfohlene Weg, eine Chat-basierte Agenten-Erfahrung bereitzustellen. Es ist der Teil von AgentKit, der am wenigsten von den Änderungen im Jahr 2026 betroffen ist.

Konnektoren-Registry

Die Konnektoren-Registry ist eine administratororientierte Stelle zur Verwaltung, wie Daten und Tools über OpenAI-Produkte hinweg, einschließlich ChatGPT und der API, verbunden werden. Sie konsolidiert vorgefertigte Konnektoren (denken Sie an Dropbox, Google Drive, SharePoint, Microsoft Teams) und MCP-Server von Drittanbietern in einem einzigen Panel, sodass ein Administrator steuert, worauf ein Agent zugreifen kann.

Wenn Sie die MCP-Seite dieses Bildes verstehen möchten, erläutert unser Leitfaden zu MCP-Servern und dem OpenAI Agents SDK, wie Agenten Tools über das Model Context Protocol aufrufen.

Evals und Optimierung

Die Evals-Funktionen fügten Datensätze, Trace-Bewertung (Bewertung jedes Schritts eines Multi-Agenten-Laufs), automatisierte Prompt-Optimierung und die Möglichkeit hinzu, gegen Drittanbieter-Modelle, nicht nur die von OpenAI, zu bewerten. Ziel war es, die Agentenqualität zu messen und Prompts anzupassen, ohne ein eigenes Evaluierungs-Framework zu erstellen.

Wie Agent Builder wird auch Evals eingestellt. Es wird für bestehende Benutzer am 31. Oktober 2026 schreibgeschützt und am 30. November 2026 abgeschaltet.

Wie AgentKit mit dem Agents SDK zusammenhängt

Dies ist der Teil, den man richtig verstehen sollte, denn er bestimmt, worauf Sie aufbauen.

Das Agents SDK ist das Framework auf Code-Ebene. Hier definieren Sie Agenten, Tools, Übergaben und Guardrails in Python oder TypeScript. AgentKits Agent Builder sitzt darüber als visuelle Ebene, die SDK-Code generiert. ChatKit sitzt daneben als Bereitstellungsoberfläche.

OpenAIs Migrationsanleitung ist klar: Für Workflows, die als Code existieren sollen, wechseln Sie zum Agents SDK. Für natürlichsprachliche Anwendungsfälle, die keinen Code benötigen, verwenden Sie Workspace Agents in ChatGPT. Wenn Sie dies lesen, um zu entscheiden, wo Sie investieren sollen, ist das Agents SDK die Antwort für Engineering-Teams.

Für wen AgentKit gedacht ist

AgentKit zielte auf mehrere Gruppen ab. Produktteams, die schnell einen Agenten bereitstellen wollten, ohne Orchestrierungscode zu schreiben, setzten auf Agent Builder und ChatKit. Unternehmen, die einen kontrollierten Zugriff auf interne Daten benötigten, nutzten die Konnektoren-Registry. Entwicklungsteams, die volle Kontrolle wollten, griffen direkt zum Agents SDK und nutzten Evals zur Qualitätsmessung.

Angesichts der Veralterungen ist die klarste Lesart für 2026 diese: Wenn Sie als Ingenieur etwas bauen, das gewartet werden soll, beginnen Sie mit dem Agents SDK. Wenn Sie Prototypen entwickeln und einen visuellen Vorsprung wünschen, bevor die Oberfläche verschwindet, exportiert der Agent Builder immer noch brauchbaren Code.

Ein übergeordneter Erstellungsablauf

Ob Sie visuell oder im Code beginnen, die Form des Agentenaufbaus ist ähnlich. Hier ist der Ablauf, dem die meisten Teams folgen.

1. Definieren Sie die Aufgabe des Agenten. Welches Ziel verfolgt er und welche Tools benötigt er? Tools sind in der Regel externe API-Aufrufe: ein Such-Endpunkt, ein CRM-Lookup, ein interner Mikroservice.
2. Stellen Sie den Workflow zusammen. Im Agent Builder ziehen Sie Knoten; im Agents SDK definieren Sie Agenten und fügen Tools und Übergaben im Code an.
3. Fügen Sie Guardrails hinzu. OpenAI liefert eine Open-Source, modulare Guardrails-Schicht, die PII maskieren oder kennzeichnen, Jailbreak-Versuche erkennen und andere Prüfungen anwenden kann. Sie können diese als Workflow-Knoten oder als eigenständige Bibliothek verwenden.
4. Verbinden Sie Daten und Tools. Über die Konnektoren-Registry oder durch die Registrierung von MCP-Servern und Funktionstools, die der Agent aufrufen kann.
5. Testen und bewerten Sie. Führen Sie den Agenten mit realen Eingaben aus, bewerten Sie Traces und passen Sie Prompts an.
6. Bereitstellen. Betten Sie ihn über ChatKit mit einer veröffentlichten Workflow-ID ein oder führen Sie Ihren exportierten Agents SDK-Code in Ihrer eigenen Infrastruktur aus.

Schritt 4 und Schritt 5 sind die Bereiche, in denen die meisten realen Probleme liegen und in denen API-Tests sich bewähren.

Ein realistisches Beispiel: die Tools, die Ihr Agent aufruft

Ein Agent ist nur so gut wie die Tools, die er aufrufen kann, und diese Tools sind fast immer HTTP-APIs. Wenn Sie ein Funktionstool beim Agents SDK registrieren, beschreiben Sie es mit einem JSON-Schema, damit das Modell weiß, wann und wie es aufgerufen werden soll. Ein Tool, das die letzten Bestellungen eines Kunden abruft, könnte so definiert werden:

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "Look up a customer's recent orders by customer ID.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The customer's unique identifier"
      },
      "limit": {
        "type": "integer",
        "description": "How many orders to return",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

Wenn das Modell entscheidet, get_recent_orders aufzurufen, empfängt Ihr Code die Argumente, stellt eine tatsächliche Anfrage an Ihre Bestell-API und gibt das Ergebnis an den Agenten zurück. Diese Anfrage könnte so aussehen:

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"

Hier liegt der Haken. Das Verhalten des Agenten hängt vollständig davon ab, was diese API zurückgibt. Wenn die Bestell-API langsam ist, nicht erreichbar ist oder eine Form zurückgibt, die das Modell nicht erwartet hat, gerät die Argumentation des Agenten ins Stocken. Und während der Entwicklung existiert die Bestell-API möglicherweise noch nicht, oder Sie möchten die Produktion nicht mit Testläufen überlasten. Das ist die Stelle, an der Apidog ansetzt.

Wo API-Tests und Mocking ins Spiel kommen

Apidog ist kein Agenten-Framework und erstellt keine Agenten. Das tun AgentKit und das Agents SDK. Was Apidog tut, ist die darunterliegende Schicht: Es testet, mockt und dokumentiert die APIs und Tools, die Ihr Agent aufruft. Drei konkrete Aufgaben tauchen ständig auf.

Erstens, mocken Sie die externen APIs, bevor sie fertig sind. Wenn Ihr Agent einen Bestellservice aufrufen muss, den das Backend-Team noch nicht fertiggestellt hat, können Sie eine Mock-API bereitstellen, die realistische Antworten liefert, die dem vereinbarten Schema entsprechen. Ihr Agent entwickelt sich gegen einen stabilen Vertrag, anstatt auf das Backend zu warten, und Sie kontrollieren die Grenzfälle, leere Ergebnisse, Fehler und langsame Antworten nach Bedarf.

Zweitens, stellen Sie sicher, dass jedes Tool das zurückgibt, was der Agent erwartet. Ein Tool-Aufruf, der einen 200er-Status mit falschen Feldnamen zurückgibt, ist schlimmer als ein direkter Fehler, da das Modell versuchen wird, über Müll zu argumentieren. Indem Sie API-Testfälle schreiben, die Statuscodes, Antwortform und spezifische Feldwerte validieren, erkennen Sie Vertragsabweichungen an jedem Endpunkt, den Ihr Agent berührt, bevor sie das Modell erreichen.

Drittens, verwalten Sie Umgebungsschlüssel und Basis-URLs über Entwicklungs-, Staging- und Produktionsumgebungen hinweg. Agenten-Tools enthalten Geheimnisse wie $ORDERS_API_KEY. Diese in Umgebungsvariablen zu halten und sie pro Umgebung auszutauschen, ohne Schlüssel in den Code einzufügen, ist genau die Art von Aufgabe, die eine API-Plattform sauber handhabt. Sie können Apidog herunterladen und Ihre Tool-Endpunkte in ein Projekt ziehen, um sie isoliert, außerhalb der Agenten-Laufzeit, zu testen.

Wenn Sie eine detaillierte Anleitung zur Behandlung der Tool-Aufrufe eines Agenten als testbare APIs wünschen, haben wir eine in „Wie man die Tool-Aufrufe eines KI-Agenten testet“ beschrieben. Die Kurzfassung: Jedes Tool, das Ihr Agent aufruft, ist eine API, und APIs verdienen Tests.

Häufig gestellte Fragen

Ist OpenAI AgentKit kostenlos?

Die Tools von AgentKit basieren auf Ihrer OpenAI API-Nutzung, daher zahlen Sie für die zugrunde liegenden Modell-Tokens und alle Tool-Aufrufe, die der Agent tätigt. Es gibt keine separate AgentKit-Abonnementposition; die Kosten sind die Modell- und API-Nutzung, die Ihr Agent generiert. Überprüfen Sie immer die aktuellen Preise auf der OpenAI-Plattform, da sich die Modelltarife ändern können.

Was ist der Unterschied zwischen AgentKit und dem Agents SDK?

Das Agents SDK ist das Code-Framework zur Definition von Agenten, Tools und Guardrails. AgentKit ist ein breiteres Bündel, das den visuellen Agent Builder, ChatKit, die Konnektoren-Registry und Evals zusätzlich zu diesem SDK umfasste. Da Agent Builder und Evals Ende 2026 eingestellt werden, ist das Agents SDK der dauerhafte, Code-first-Ansatz. Unser Agents SDK-Leitfaden deckt es von A bis Z ab.

Wird Agent Builder eingestellt?

Ja. OpenAI kündigte am 3. Juni 2026 an, den Agent Builder und die Evals-Plattform einzustellen. Beide werden am 30. November 2026 abgeschaltet, und Evals wird am 31. Oktober 2026 schreibgeschützt. ChatKit bleibt verfügbar, und OpenAI empfiehlt, Code-first-Workflows auf das Agents SDK und natürlichsprachliche Workflows auf Workspace Agents in ChatGPT umzustellen.

Kann ich die APIs testen, die mein AgentKit-Agent aufruft?

Ja, und das sollten Sie auch. Jedes Tool, das ein Agent aufruft, ist eine HTTP-API mit einer Anfrage und einer Antwort. Sie können diese APIs mocken, während sie noch entwickelt werden, sicherstellen, dass ihre Antworten dem von Ihrem Agenten erwarteten Schema entsprechen, und die benötigten Schlüssel verwalten. Eine Plattform wie Apidog erledigt all dies, damit die Tools Ihres Agenten vorhersehbar funktionieren, bevor sie einen echten Benutzer erreichen.

Fazit

AgentKit bot OpenAI-Entwicklern einen schnelleren Einstieg in den Aufbau von Agenten: eine visuelle Oberfläche im Agent Builder, eine einbettbare Benutzeroberfläche in ChatKit, verwaltete Konnektoren in der Konnektoren-Registry und Messungen durch Evals. Ende 2026 werden Agent Builder und Evals eingestellt, sodass die dauerhafte Option für Entwicklungsteams das Agents SDK ist, zusammen mit ChatKit und der Konnektoren-Registry.

Welchen Weg Sie auch einschlagen, die Zuverlässigkeit Ihres Agenten hängt von den APIs ab, die er aufruft. Mocken Sie sie frühzeitig, überprüfen Sie ihre Antworten und halten Sie Ihre Schlüssel organisiert. Apidog bietet Ihnen eine zentrale Stelle zum Testen und Mocken jedes Tool-Endpunkts, von dem Ihr Agent abhängt, sodass die Integrationen standhalten, wenn ein Agent sie unter Last setzt.