OpenAIs praxisnaher Leitfaden zum Aufbau von Agenten

• Mit den Fortschritten bei Schlussfolgern, Multimodalität und Tool-Nutzung von LLMs ist eine neue Systemkategorie entstanden: Agenten, die Workflows selbstständig ausführen und dabei im Auftrag der Nutzer handeln
• Agenten bestehen aus drei zentralen Bausteinen: Modell (LLM), Tools (APIs/externe Funktionen) und Anweisungen (Guidelines) und lassen sich als Einzelagent oder Multi-Agenten-System orchestrieren
• Der Einsatz von Agenten eignet sich für Workflows mit komplexen Entscheidungen, schwer wartbaren Regelsystemen und Anforderungen an die Verarbeitung unstrukturierter Daten
• Guardrails sind mehrschichtige Abwehrmechanismen zum Schutz von Datenschutz, Content-Sicherheit und Markenkonsistenz und ein unverzichtbarer Bestandteil beim Einsatz von Agenten
• Entscheidend für eine erfolgreiche Einführung ist ein iterativer Ansatz: mit einem einzelnen Agenten starten, mit realen Nutzern validieren und schrittweise ausbauen

---

Definition von Agenten

• Agenten sind Systeme, die selbstständig Aufgaben im Auftrag der Nutzer ausführen und dabei Workflows wie die Lösung von Kundenservicefällen, Restaurantreservierungen, das Committen von Code-Änderungen oder das Erstellen von Berichten übernehmen
• Anwendungen, die zwar ein LLM integrieren, aber die Ausführung des Workflows nicht steuern, sind keine Agenten, etwa einfache Chatbots, Single-Turn-LLMs oder Stimmungs-Klassifikatoren
• Kerneigenschaften von Agenten:
  • Sie nutzen ein LLM, um die Ausführung von Workflows zu steuern, Entscheidungen zu treffen, den Abschluss eines Workflows zu erkennen und ihr Verhalten bei Bedarf proaktiv anzupassen
  • Bei einem Fehlschlag brechen sie die Ausführung ab und geben die Kontrolle an den Nutzer zurück
  • Sie haben Zugriff auf verschiedene Tools, interagieren damit mit externen Systemen und wählen je nach aktuellem Status des Workflows dynamisch das passende Tool aus, arbeiten dabei aber innerhalb klarer Guardrails

Wann man Agenten bauen sollte

• Im Unterschied zu klassischer Automatisierung eignen sich Agenten für Workflows, in denen traditionelle deterministische und regelbasierte Ansätze an ihre Grenzen stoßen
• Beispiel Zahlungsbetrugserkennung: Eine klassische Rule Engine markiert Transaktionen nach vordefinierten Kriterien im Stil einer Checkliste, während ein LLM-Agent wie ein erfahrener Ermittler agiert, den Kontext bewertet, feine Muster berücksichtigt und verdächtige Aktivitäten auch ohne klaren Regelverstoß erkennt
• Drei Arten von Situationen, in denen Agenten Mehrwert bringen:
  • Komplexe Entscheidungen: Workflows, die differenzierte Urteile, Ausnahmen und kontextabhängige Entscheidungen erfordern, etwa die Genehmigung von Rückerstattungen im Kundenservice
  • Schwer wartbare Regeln: Systeme mit umfangreichen und komplexen Regelwerken, deren Aktualisierung teuer oder fehleranfällig ist, etwa bei Security-Reviews von Anbietern
  • Szenarien mit hoher Abhängigkeit von unstrukturierten Daten: Interpretation natürlicher Sprache, Extraktion von Bedeutung aus Dokumenten und konversationelle Nutzerinteraktion, etwa bei der Bearbeitung von Wohngebäudeversicherungs-Schäden
• Wenn diese Kriterien nicht klar erfüllt sind, kann eine deterministische Lösung ausreichend sein

Grundlagen des Agenten-Designs

• Drei zentrale Komponenten

  • Modell (Model): das LLM, das Schlussfolgern und Entscheidungsfindung des Agenten antreibt
  • Tools: externe Funktionen oder APIs, die der Agent nutzt, um Aktionen auszuführen
  • Anweisungen (Instructions): explizite Leitlinien und Guardrails, die das Verhalten des Agenten definieren

• Modellauswahl

  • Nicht für jede Aufgabe ist das leistungsstärkste Modell nötig — einfache Suche oder Intent-Klassifikation lassen sich mit kleinen, schnellen Modellen erledigen, während schwierigere Aufgaben wie Rückerstattungsentscheidungen von stärkeren Modellen profitieren
  • Ein wirksamer Ansatz ist, in der Prototyping-Phase mit dem stärksten Modell eine Leistungs-Baseline festzulegen und anschließend kleinere Modelle auszuprobieren, um zu prüfen, ob die Ergebnisse noch akzeptabel sind
  • Prinzipien für die Modellauswahl:
    • Eine Evaluierung (Eval) einrichten, um eine Leistungs-Baseline zu etablieren
    • Mit dem besten Modell zuerst das Genauigkeitsziel erreichen
    • Wo möglich durch kleinere Modelle ersetzen, um Kosten und Latenz zu optimieren

• Definition von Tools

  • Tools erweitern die Fähigkeiten des Agenten, indem sie die APIs der zugrunde liegenden Anwendung oder des Systems nutzen
  • Wenn in Legacy-Systemen keine API vorhanden ist, kann mit einem Computer-Use-Modell direkt über Web- und Anwendungsoberflächen interagiert werden
  • Jedes Tool sollte eine standardisierte Definition haben und eine flexible Viele-zu-Viele-Beziehung zwischen Tools und Agenten unterstützen
  • Gut dokumentierte, gründlich getestete und wiederverwendbare Tools verbessern die Auffindbarkeit, vereinfachen die Versionsverwaltung und vermeiden doppelte Definitionen
  • Drei Tool-Typen, die Agenten benötigen:
    • Daten (Data): Abruf von Kontext und Informationen für die Ausführung des Workflows, z. B. Transaktions-DB-Abfragen, CRM-Systeme, PDF-Lesen oder Websuche
    • Aktion (Action): Interaktion mit Systemen, um Informationen in eine DB zu schreiben, Datensätze zu aktualisieren oder Nachrichten zu versenden, z. B. E-Mails/SMS senden, CRM-Records aktualisieren oder Kundenservice-Tickets an Menschen übergeben
    • Orchestrierung (Orchestration): Der Agent selbst fungiert als Tool eines anderen Agenten, z. B. Rückerstattungs-Agent, Research-Agent oder Schreib-Agent

• Gestaltung von Anweisungen

  • Hochwertige Anweisungen sind für jede LLM-basierte App essenziell, bei Agenten aber besonders wichtig
  • Klare Anweisungen reduzieren Unklarheiten und verbessern die Entscheidungsfindung des Agenten, was zu reibungsloseren Workflows und weniger Fehlern führt
  • Best Practices für Agenten-Anweisungen:
    • Bestehende Dokumente nutzen: Vorhandene Betriebsabläufe, Support-Skripte und Richtliniendokumente verwenden, um LLM-freundliche Routinen zu erstellen (im Kundenservice entsprechen Routinen in etwa einzelnen Dokumenten der Wissensdatenbank)
    • Prompts zur Aufgabenzerlegung: In dichten Ressourcen kleinere, klarere Schritte vorgeben, um Mehrdeutigkeiten zu minimieren
    • Aktionen klar definieren: Festlegen, dass jeder Schritt einer Routine einer bestimmten Aktion oder Ausgabe entspricht, etwa das Anfordern einer Bestellnummer oder das Abrufen von Kontodetails per API-Aufruf
    • Edge Cases erfassen: Häufige Abweichungen antizipieren, etwa wenn Nutzer unvollständige Informationen liefern oder unerwartete Fragen stellen, und mit bedingten Schritten oder Verzweigungen festlegen, wie damit umzugehen ist
  • Mit fortgeschrittenen Modellen wie o1 oder o3‑mini lassen sich aus bestehenden Dokumenten auch automatisch Anweisungen erzeugen

Orchestrierung

• Einzelagenten-Systeme

  • Ein einzelner Agent kann mit schrittweise ergänzten Tools viele Aufgaben abdecken, was das Management von Komplexität sowie Evaluierung und Wartung vereinfacht
  • Jeder Orchestrierungsansatz braucht das Konzept eines „run“, üblicherweise umgesetzt als Schleife, in der der Agent arbeitet, bis eine Abbruchbedingung erreicht ist
  • Typische Abbruchbedingungen sind Tool-Aufrufe, eine bestimmte strukturierte Ausgabe, Fehler oder das Erreichen einer maximalen Turn-Zahl
  • Im Agents SDK wird der Agent mit der Methode Agents.run() gestartet; die Schleife endet bei einem Tool-Aufruf für die finale Ausgabe oder bei einer Modellantwort ohne Tool-Aufruf
  • Strategie mit Prompt-Templates: Statt vieler einzelner Prompts wird ein einziges flexibles Basis-Prompt mit Policy-Variablen verwendet, das sich an unterschiedliche Kontexte anpasst und Wartung sowie Evaluierung deutlich vereinfacht

• Wann man zu Multi-Agenten-Systemen wechselt

  • Die allgemeine Empfehlung lautet, zuerst die Fähigkeiten eines Einzelagenten maximal auszureizen
  • Mehr Agenten sorgen zwar für eine intuitive konzeptionelle Trennung, bringen aber zusätzliche Komplexität und Overhead mit sich, daher reicht oft ein einzelner Agent mit Tools aus
  • Praxisleitlinien für die Aufteilung von Agenten:
    • Komplexe Logik: Wenn Prompts viele bedingte Anweisungen (if-then-else-Verzweigungen) enthalten und Prompt-Templates schwer skalierbar werden, sollte jedes Logiksegment in einen separaten Agenten ausgelagert werden
    • Tool-Überlastung: Das Problem ist nicht die reine Zahl der Tools, sondern Ähnlichkeit oder Überschneidung — es gibt Implementierungen, die mehr als 15 klar unterscheidbare Tools erfolgreich verwalten, während andere schon mit weniger als 10 überlappenden Tools Schwierigkeiten haben

• Manager-Pattern (Agenten als Tools)

  • Ein zentrales LLM, der „Manager“, orchestriert über Tool-Aufrufe ein Netzwerk spezialisierter Agenten
  • Der Manager delegiert Aufgaben zum richtigen Zeitpunkt an passende Agenten, ohne Kontext oder Kontrolle zu verlieren, und fügt die Ergebnisse zu einer integrierten Interaktion zusammen
  • Geeignet für Workflows, in denen nur ein Agent die Ausführung steuern und Zugriff auf den Nutzer haben soll
  • Beispiel: Ein Übersetzungs-Agent ruft spanische, französische und italienische Agenten als Tools auf

• Dezentralisiertes Pattern (Handoffs zwischen Agenten)

  • Ein Agent übergibt die Ausführung des Workflows als „Handoff“ einseitig an einen anderen Agenten
  • Im Agents SDK sind Handoffs eine Art Tool oder Funktion; beim Aufruf der Handoff-Funktion wird der aktuelle Gesprächsstatus übergeben und der neue Agent beginnt sofort mit der Ausführung
  • Optimal für Abläufe, in denen kein einzelner Agent zentrale Kontrolle oder Zusammenführung behalten muss und jeder Agent die Ausführung übernehmen und direkt mit dem Nutzer interagieren kann
  • Beispiel: Ein Triage-Agent bewertet die Nutzeranfrage und leitet sie an einen technischen Support-, Sales- oder Bestellmanagement-Agenten weiter

• Deklarative vs. nicht-deklarative Graphen

  • Einige Frameworks verlangen in deklarativer Form, alle Verzweigungen, Schleifen und Bedingungen im Voraus als Graph aus Knoten (Agenten) und Kanten (Handoffs) zu definieren — das schafft visuelle Klarheit, wird aber bei dynamischen und komplexen Workflows umständlich und erfordert das Erlernen einer domänenspezifischen Sprache
  • Das Agents SDK verfolgt einen Code-first-Ansatz, bei dem Workflow-Logik direkt mit vertrauten Programmierstrukturen ausgedrückt wird, ohne den gesamten Graphen vorab definieren zu müssen, was dynamischere und anpassungsfähigere Agenten-Orchestrierung ermöglicht

Guardrails

• Rolle von Guardrails

  • Sie helfen beim Management von Datenschutzrisiken (z. B. Verhinderung von Leaks des System-Prompts) und Reputationsrisiken (z. B. Erzwingen markenkonformen Modellverhaltens)
  • Ein einzelnes Guardrail bietet meist keinen ausreichenden Schutz; für robustere Agenten sollten mehrere spezialisierte Guardrails kombiniert werden
  • Guardrails sind wichtige Bausteine, müssen aber mit starker Authentifizierung und Autorisierung, strengen Zugriffskontrollen und standardmäßigen Software-Sicherheitsmaßnahmen kombiniert werden

• Arten von Guardrails

  • Relevanz-Klassifikator (Relevance classifier): Prüft, ob Antworten des Agenten innerhalb des vorgesehenen Anwendungsbereichs liegen, und markiert Off-Topic-Anfragen (z. B. „Wie hoch ist das Empire State Building?“)
  • Sicherheits-Klassifikator (Safety classifier): Erkennt unsichere Eingaben wie Jailbreaks oder Prompt Injection, die Systemschwachstellen ausnutzen sollen
  • PII-Filter: Verhindert unnötige Offenlegung personenbezogener Daten (PII) in Modellausgaben
  • Moderation: Markiert schädliche oder unangemessene Eingaben wie Hassrede, Belästigung oder Gewalt
  • Tool-Safeguards: Weisen jedem Tool anhand von Kriterien wie Nur-Lesen vs. Schreibzugriff, Reversibilität, erforderlichen Account-Berechtigungen und finanziellen Auswirkungen eine niedrige/mittlere/hohe Risikostufe zu und lösen automatisierte Maßnahmen aus, etwa eine Pause für Guardrail-Prüfungen oder Eskalation an einen Menschen vor der Ausführung risikoreicher Funktionen
  • Regelbasierte Schutzmechanismen (Rules-based protections): Einfache deterministische Maßnahmen wie Blocklisten, Eingabelängenbegrenzungen oder Regex-Filter zum Schutz vor verbotenen Begriffen oder bekannten Bedrohungen wie SQL Injection
  • Output-Validierung: Stellt durch Prompt Engineering und Content-Prüfung sicher, dass Antworten den Markenwerten entsprechen

• Ansatz zum Aufbau von Guardrails

  • Zuerst Guardrails für bereits identifizierte Risiken einführen und bei neu entdeckten Schwachstellen weitere Schichten ergänzen
  • Effektive Heuristiken:
    • Auf Datenschutz und Content-Sicherheit fokussieren
    • Neue Guardrails auf Basis realer Edge Cases und Fehlersituationen ergänzen
    • Sicherheit und Nutzererlebnis gemeinsam optimieren und Guardrails mit der Weiterentwicklung des Agenten anpassen
  • Im Agents SDK werden Guardrails als First-Class-Concept behandelt; standardmäßig wird optimistic execution verwendet — der Basis-Agent erzeugt proaktiv Ausgaben, während Guardrails parallel laufen und bei Regelverstößen Ausnahmen auslösen

• Planung menschlicher Eingriffe

  • Menschliche Eingriffe sind ein zentraler Sicherheitsmechanismus, der die reale Leistung von Agenten verbessern kann, ohne das Nutzererlebnis unnötig zu verschlechtern
  • Besonders in der frühen Einführungsphase sind sie wichtig, um Fehler zu identifizieren, Edge Cases zu entdecken und robuste Evaluierungszyklen aufzubauen
  • Zwei zentrale Trigger für menschliches Eingreifen:
    • Überschreiten von Fehlerschwellen: Begrenzungen für Wiederholungen oder Aktionen des Agenten setzen und bei Überschreitung — etwa wenn die Kundenabsicht auch nach mehreren Versuchen nicht erkannt wird — an einen Menschen eskalieren
    • Hochriskante Aktionen: Bei sensiblen, irreversiblen oder besonders folgenreichen Aktionen wie dem Stornieren einer Nutzerbestellung, der Genehmigung großer Rückerstattungen oder der Zahlungsabwicklung ist menschliche Aufsicht nötig, bis das Vertrauen in den Agenten ausreichend hoch ist

Fazit

• Agenten markieren eine neue Ära der Workflow-Automatisierung: Sie können Mehrdeutigkeit beurteilen, über Tools handeln und mehrstufige Aufgaben mit hoher Autonomie ausführen
• Im Unterschied zu einfachen LLM-Anwendungen führen Agenten End-to-End-Workflows aus und eignen sich daher für komplexe Entscheidungen, unstrukturierte Daten und fragile regelbasierte Systeme
• Für den Aufbau verlässlicher Agenten gilt: leistungsfähige Modelle mit klar definierten Tools und klaren, strukturierten Anweisungen kombinieren, ein zur Komplexität passendes Orchestrierungsmuster wählen und mit einem Einzelagenten beginnen, bevor nur bei Bedarf auf Multi-Agenten erweitert wird
• Guardrails sind auf jeder Stufe wichtig — von der Eingabefilterung über Tool-Nutzung bis zum menschlichen Eingriff — und stellen sicher, dass Agenten in der Produktion sicher und vorhersehbar arbeiten
• Erfolgreiche Einführung ist kein Alles-oder-Nichts-Projekt, sondern ein iterativer Ansatz, der klein beginnt, mit realen Nutzern validiert und die Fähigkeiten über die Zeit ausbaut

• Auch als PDF verfügbar