+220 XP

Capstone: ein echter End-to-End-ChatGPT-Workflow

# Capstone: ein echter End-to-End-ChatGPT-Workflow

Bauen wir ein realistisches System von Anfang bis Ende: einen Customer-Support-Assistenten für ein kleines SaaS-Unternehmen, der aus einer Knowledge Base antwortet, live Bestell- und Accountdaten abruft, schwierige Tickets an einen Menschen eskaliert und dem Gründer jeden Montag einen wöchentlichen Health-Report per E-Mail schickt. Die einzelnen Bausteine kennen Sie schon. In dieser Lektion geht es darum, sie zu verdrahten und, wichtiger noch, zu entscheiden, *welcher* Baustein wo eingesetzt wird.

Das Szenario und die Constraints

„SupportBot“ muss vier Dinge leisten:

1. Produktfragen aus internen Docs beantworten.

2. Das laufende Abo und die letzten Tickets eines Kunden nachschlagen.

3. An einen Menschen übergeben, wenn die Confidence niedrig ist oder der Kunde verärgert ist.

4. Einen Wochenreport zu Ticketvolumen, Lösungszeit und Top-Themen erzeugen.

Drei Constraints bestimmen jede Entscheidung: das Team besteht aus zwei Personen, die Docs ändern sich wöchentlich, und Kundendaten liegen in einer Postgres-Datenbank und in Zendesk. Behalten Sie das im Kopf, denn es führt uns für unterschiedliche Aufgaben zu unterschiedlichen Surfaces.

Entscheidung 1: Custom GPT oder API?

Das ist die zentrale Architekturverzweigung, also klären wir sie zuerst.

Ein Custom GPT (konfiguriert auf chatgpt.com, verteilt über den GPT Store oder einen privaten Link) ist der richtige Ort für den *intern genutzten* Assistenten. Ihre zwei Support-Agents öffnen ihn in ChatGPT, fügen eine Kunden-E-Mail ein und erhalten eine Antwort, die auf Ihren Docs basiert. Kein Hosting, kein Auth-Code, und Connectors und Actions sind nativ mit dabei.

Die API (die Responses API) ist der richtige Ort für alles *Kundenseitige* oder *Automatisierte*: das Widget auf Ihrer Website, den nächtlichen Report-Job. Sie brauchen programmatische Kontrolle, eigene Auth, Logging und die Möglichkeit, ohne Human in the Loop zu laufen.

Die Antwort ist also beides, getrennt nach Zielgruppe:

  • Drafting-Tool für die Agents → Custom GPT.
  • Website-Widget + geplanter Report → API.

Versuchen Sie nicht, ein Surface zu allem zu zwingen. Der Custom GPT ist Ihr schneller Weg; die API ist Ihr belastbarer Weg.

Entscheidung 2: Wie die Docs in die Antwort kommen

Die Docs ändern sich wöchentlich, deshalb ist die Grounding-Strategie relevant.

Für den Custom GPT nutzen Sie Connectors, um den Google-Drive-Ordner zu verbinden, in dem das Team die Docs pflegt. Der GPT durchsucht diese Quelle zur Abfragezeit, eine Änderung am Montag ist also am Montag sichtbar. Das ist besser, als statische Dateien in die Knowledge des GPT zu laden, die veralten und immer wieder neu hochgeladen werden müssten. Den aktuellen Connectors-Katalog und die Admin-Einstellungen finden Sie auf help.openai.com.

Beim API-basierten Widget gehört Ihnen das Retrieval. Entweder betreiben Sie eine eigene Vektorsuche und übergeben die Ergebnisse in den Prompt, oder Sie nutzen file search als gehostetes Tool der Responses API. Für ein Zwei-Personen-Team ist gehostete file search die pragmatische Wahl: weniger Infrastruktur, um die man sich kümmern muss. Ein wöchentlicher Cron-Job synchronisiert die Docs neu in den File Store.

Entscheidung 3: Live-Daten über Actions vs. function calling

Der Assistent braucht getCustomer(email) und getRecentTickets(customerId). Gleiche Fähigkeit, zwei Implementierungen je nach Surface.

Im Custom GPT stellen Sie diese als GPT Actions bereit: eine OpenAPI-Spezifikation, die auf Ihre interne API zeigt, mit Auth im GPT-Builder konfiguriert. Das Modell entscheidet, wann es sie aufruft.

Im API-Widget werden dieselben Operationen zu function calling mit structured outputs, sodass die Argumente jedes Mal als schemakonformes JSON ankommen. Hier die Tool-Definition für die Responses API:

python
from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "name": "get_customer",
    "description": "Look up a customer's subscription and account status by email.",
    "parameters": {
        "type": "object",
        "properties": {
            "email": {"type": "string", "description": "Customer email address"}
        },
        "required": ["email"],
        "additionalProperties": False
    },
    "strict": True
}]

response = client.responses.create(
    model="gpt-4.1",
    input="What plan is taylor@acme.com on, and is their account in good standing?",
    tools=tools
)

print(response.output)

strict: True ist der Teil, den man verinnerlichen sollte: er garantiert, dass die Argumente des Modells Ihrem Schema entsprechen, Ihr Backend-Code also nie defensiv ein fehlerhaftes E-Mail-Feld parsen muss. Den kompletten Loop, inklusive der Frage, wie Sie das Tool-Ergebnis für die finale Antwort des Modells zurückschicken, finden Sie im function calling guide.

Der entscheidende Punkt: *dieselben OpenAPI-Operationen* liegen sowohl Ihren GPT Actions als auch Ihren function-calling-Tools zugrunde. Die API einmal schreiben, zweimal bereitstellen.

Entscheidung 4: Eskalation und die Grenze zum Human in the Loop

Lassen Sie einen Support-Bot niemals eigenständig eine Rückerstattung zusagen oder ein Ticket schließen. Bauen Sie ein explizites Eskalations-Tool, escalate_to_human(reason, urgency), und weisen Sie das Modell an, es aufzurufen, wenn der Kunde verärgert ist, Geld verlangt oder die Docs die Frage nicht abdecken.

Machen Sie Eskalation zu einem *First-Class-Tool*, nicht zu einem Bauchgefühl. Beim Aufruf legt Ihr Code die Konversation in eine Zendesk-Queue und teilt dem Kunden mit, dass sich ein Mensch darum kümmert. So wird aus „der Bot lag falsch“ ein „der Bot kannte seine Grenzen“, und genau das unterscheidet einen nützlichen Assistenten von einem Risiko.

Entscheidung 5: Wo das Modell orchestriert und wo Ihr Code

Wenn Sie mehrere Tools und mehrstufige Logik haben (Kunden nachschlagen → Tickets prüfen → antworten oder eskalieren), haben Sie die Wahl:

  • Das Modell orchestrieren lassen über den Tool-Loop der Responses API. Einfach, gut für lineare Abläufe.
  • Das [Agents SDK](https://platform.openai.com/docs/guides/agents-sdk) nutzen, wenn Sie typisierte Agents, Handoffs zwischen spezialisierten Agents (ein „Billing-Agent“ vs. ein „Technik-Agent“), Guardrails und Tracing wollen. Für das Eskalations- und Handoff-Muster von SupportBot zahlt sich das Agents SDK aus, weil Handoffs ein eingebautes Primitiv sind.

Wenn Sie interaktiv prototypen, ist der ChatGPT agent (der browsende, klickende, mehrstufige Agent in ChatGPT) hervorragend für punktuelle Recherchen geeignet („finde jedes offene Ticket, das den neuen Billing-Bug erwähnt“), aber dort läuft kein Produktionstraffic. Halten Sie diese Unterscheidung scharf: ChatGPT agent für Exploration, Agents SDK für das ausgerollte System.

Entscheidung 6: Der Wochenreport

Hier glänzt Advanced Data Analysis (Code Interpreter). Der Report braucht echte Berechnung: mediane Lösungszeit, Ticket-Deltas Woche über Woche, ein Chart der häufigsten Issue-Kategorien.

Sie haben zwei saubere Optionen:

Option A: Scheduled Task in ChatGPT. ChatGPT unterstützt scheduled tasks, die einen Prompt wiederkehrend ausführen. Erstellen Sie einen Task in Ihrem Custom GPT: „Jeden Montag um 8 Uhr die Tickets der letzten Woche über den Zendesk-Connector abrufen, Lösungsstatistiken berechnen und eine Zusammenfassung mit Chart erzeugen.“ Geringster Aufwand, kein Code zu hosten.

Option B: API-Job auf Ihrem eigenen Cron. Ein kleines Skript fragt Postgres ab, übergibt die Zeilen mit dem Code-Interpreter-Tool an das Modell, um Zahlen zu berechnen und ein Chart zu rendern, und mailt das Ergebnis. Mehr Kontrolle, versioniert, testbar. Wählen Sie das, wenn der Report etwas Nachgelagertes speist oder der Gründer ihn jedes Mal in einem bestimmten Format braucht.

Für ein Zwei-Personen-Team: mit Option A anfangen. Auf Option B umsteigen, wenn der Report tragend wird.

Building a Customer Support Agent with the OpenAI Agents SDK

Watch on YouTube

Wissenscheck

1. Warum wird im SupportBot-Design für das Drafting-Tool der Agents ein Custom GPT gewählt und nicht die API?

2. Die Lektion kommt zum Schluss, die Antwort auf „Custom GPT oder API?“ sei „beides“. Welches Prinzip steckt hinter dieser Trennung?

3. Da sich die Docs wöchentlich ändern: Warum bevorzugt die Lektion einen per Connectors verbundenen Live-Google-Drive-Ordner gegenüber statischen Dateien in der Knowledge des GPT?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aufgaben im SupportBot-Szenario, die besser über die API als über den Custom GPT abgedeckt werden.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Constraints, die laut Lektion die Architekturentscheidungen von SupportBot bestimmen sollen.

Wählen Sie alle richtigen Antworten aus.

Die Surfaces zusammensetzen

Hier das Gesamtbild, Surface für Surface:

| Aufgabe | Surface | Warum |

|---|---|---|

| Agents entwerfen Antworten | Custom GPT + Connectors + Actions | Schnell, kein Hosting, live Docs |

| Website-Chat-Widget | Responses API + file search + function calling | Programmatisch, eigene Auth und eigenes Logging |

| Multi-Agent-Routing & Eskalation | Agents SDK | Handoffs und Guardrails sind eingebaut |

| Wochenreport | Scheduled Task (Start) → API + Code Interpreter (Skalierung) | Echte Berechnung nach Zeitplan |

Achten Sie auf die rote Linie: eine Backend-API liefert die Lookups, bereitgestellt als Actions für den GPT und als function tools für die API. Eine Doc-Quelle (der Drive-Ordner) versorgt sowohl den Connector als auch den file-search-Sync. Sie bauen keine vier Systeme; Sie bauen zwei Integrationspunkte (Ihre API, Ihre Docs) und richten mehrere Surfaces darauf aus.

Memory, Projects und Instructions

Einige ChatGPT-Funktionen verbessern das Tool für die Agents nebenbei deutlich:

  • Legen Sie SupportBots Tonalitätsregeln, Eskalationspolicy und die Regel „immer das Doc zitieren“ in die Instructions des Custom GPT, nicht in jeden Prompt.
  • Bündeln Sie die Support-Arbeit des Teams in einem Project, damit Konversationen, Dateien und Custom Instructions zusammen abgegrenzt bleiben, getrennt von der übrigen ChatGPT-Nutzung.
  • Lassen Sie memory für den Support-Custom-GPT aus. Sie wollen nicht, dass er Annahmen zwischen unabhängigen Kunden mitnimmt. Memory ist gut für einen persönlichen Assistenten, riskant für ein gemeinsam genutztes Support-Tool.

Eine Anmerkung zu Canvas und Codex

Wenn Sie die Report-Templates oder die E-Mail-Texte *schreiben*, ist Canvas das bessere Editier-Surface als der Chat: Sie iterieren direkt am Dokument. Und die eigentliche Implementierungsarbeit (das Responses-API-Skript, die OpenAPI-Spec, der Cron-Job) ist genau das, wofür Codex da ist. Nutzen Sie es, um den function-calling-Loop und die Postgres-Query zu scaffolden, und prüfen Sie dann jede Zeile, bevor sie Kundendaten anfasst.

Failure Modes, für die Sie designen sollten

Entscheiden Sie vor dem Launch, was passiert, wenn etwas kaputtgeht:

  • Die Lookup-API ist down. Ihre Funktion sollte ein klares Fehlerobjekt zurückgeben, und die Instructions des Modells sollten sagen: „wenn ein Lookup fehlschlägt, eskaliere statt zu raten.“
  • Das Modell erfindet eine Policy. Grenzen Sie es ein: nur aus den abgerufenen Docs antworten, und wenn das Retrieval nichts Relevantes liefert, das sagen und eskalieren.
  • Rate Limits oder Kostenspitzen. Loggen Sie den Token-Verbrauch pro Konversation. Das Website-Widget ist Ihr ungedeckeltes Surface, also begrenzen Sie die Konversationslänge und ergänzen Sie einen Fallback auf die Übergabe an einen Menschen.

Entwerfen Sie das erst auf Papier. Jetzt zu entscheiden ist billiger als später in Produktion zu debuggen.

Key Takeaways

  • Nach Zielgruppe trennen, nicht nach Feature. Custom GPT für Ihr internes Team (schnell, kein Hosting); die Responses API für kundenseitige und automatisierte Flows (Kontrolle, Logging, Auth).
  • Das Backend einmal bauen, zweimal bereitstellen. Dieselben OpenAPI-Operationen treiben Ihre GPT Actions und Ihre function-calling-Tools. Dasselbe Prinzip bei den Docs: eine Quelle versorgt Connectors und file search.
  • Machen Sie Eskalation zu einem First-Class-Tool mit strict structured outputs, und weisen Sie das Modell an, bei Fehlern oder niedriger Confidence zu eskalieren statt zu raten.
  • Auf dem aufwandsarmen Surface starten, umsteigen, wenn es tragend wird. Nutzen Sie für den Wochenreport zuerst einen ChatGPT Scheduled Task; gehen Sie erst auf einen API- und Code-Interpreter-Cron-Job über, wenn er etwas Nachgelagertes speist.
  • Greifen Sie zum Agents SDK, wenn Sie Handoffs, Guardrails und Tracing brauchen; nutzen Sie den ChatGPT agent für Exploration, nicht für Produktionstraffic.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Lassen Sie das Modell nur die Generierung übernehmen; Sammeln, Validieren und Ausliefern erledigt der Code
Vollständiges Action Playbook ansehen