Skip to main content
Nutze dieses Rezept, wenn ein Support-Workflow Folgendes leisten soll:
  • Routing- und Prompt-Standards aus einem Dashboard-Preset übernehmen
  • eine strikt strukturierte Ausgabe zurückgeben
  • riskante Fälle zur Prüfung durch Menschen anhalten
  • Gateway-Fehler in den Logs sichtbar halten, statt sie im Agent-Code zu verbergen

1. Mit einem Preset beginnen

Erstelle ein Preset wie support-triage, das Folgendes festlegt:
  • das standardmäßig geroutete Modell oder Router-Ziel
  • Anbieterpräferenzen
  • den Support-System-Prompt
  • stabile Decoding-Parameter
So bleibt der Agent-Code auf die Workflow-Steuerung fokussiert, statt Anfragerichtlinien zu duplizieren.

2. Einen klar abgegrenzten Triage-Vertrag definieren

Halte die erste Ausgabe so kompakt, dass das Betriebsteam sie schnell prüfen kann.

3. Den Preset-gesteuerten Agenten erstellen

Das SDK löst preset: "support-triage" in die Gateway-Aliasform @support-triage auf.

4. Den Gateway-gestützten Adapter konfigurieren

Verwende Adapter-Standards für Einstellungen, die bei jedem Triage-Lauf gleich bleiben sollen:

5. Den Workflow mit begrenzten Wiederholungsversuchen ausführen

Wenn der Run zur Prüfung pausiert, setze ihn ausdrücklich fort:

6. Gateway-Fehler als Betriebsereignisse behandeln

Verbirg Fehler nicht, indem du sie in der Agent-Callback-Kette abfängst und unterdrückst. Fange stattdessen AgentGatewayError ausdrücklich ab:
Anschließend:
  1. Lass die Runtime den failed-Status von Lauf und Schritten speichern.
  2. Prüfe bei späteren Wiederherstellungsabläufen loaded.run.errorDetails oder loaded.steps[n].errorDetails, wenn die ursprüngliche Exception nicht mehr im Speicher liegt.
  3. Prüfe in den Anfragedetails:
    • die Durchsetzung der Guardrails
    • Routing-Details
    • Plugin-Ausführung
    • Request-IDs und Anbieterdaten
Das ist besonders wichtig, wenn:
  • eine Guardrail die Anfrage blockiert
  • die Zulassungsliste des Presets das angeforderte Modell ablehnt
  • Anbieterzugangsdaten oder Aktivierungsfilter die gerouteten Kandidaten entfernen
  • Response-Healing kein schema-konformes JSON wiederherstellen kann

7. Was zu prüfen ist

Prüfe nach einem erfolgreichen und einem gezielt riskanten Lauf Folgendes:
  • die Anfragedetails das durch das Preset festgelegte Ziel anzeigen
  • Hochrisikofälle mit waiting_for_human angehalten werden
  • Wiederholungen von Modellschritten modelAttempts speichern
  • Guardrail- oder Preset-Fehler in den Anfragedetails sichtbar bleiben und nicht in Agent-Ausnahmen verborgen werden

Verwandte Leitfäden

Zuletzt geändert am 2. Oktober 2026