Prüfbericht für deinen Agenten
3 Wiederholungen pro Fall. Mehr Wiederholungen ergeben engere Intervalle.
- Modell
- qwen/qwen3.8-flash
- Fälle / Läufe
- 10 / 30
- Trefferquote
- 83,3 %
- 95-%-Intervall
- 66,4 % – 92,7 %
Ein Treffer bedeutet: Der gewünschte Zustand ist vorhanden, es gibt keine zusätzliche Schreibaktion und der Agent bestätigt die Erledigung. Das Intervall beschreibt die Unsicherheit der gemessenen Quote; mehrere Läufe desselben Falls sind keine unabhängigen Kundenaufträge.
Die Tools bilden ein Testsystem ab. Die Datensätze sind synthetisch.
Ein Modell- oder ein Prompt-Problem?
Referenz DeepSeek: DeepSeek V4.1 Flash: 100 % (95-%-Intervall: 88,6 % – 100 %), mit demselben Prompt und denselben Tools, 3 Wiederholungen pro Fall. Dein Modell und die Referenz sind vergleichbar. Dieser Vergleich liefert einen Hinweis, keinen Ursachenbeweis.
Ergebnisse pro Fall
| Tool | Fehlerart | Wiederholungen | Auszug aus dem Ablauf |
|---|---|---|---|
create_support_ticket | Antwort verloren: Der Datensatz wurde geschrieben, die Antwort ging verloren. | Lauf 1: Unbestätigt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 create_support_ticket → Ergebnis unklar Lauf 2 create_support_ticket → Ergebnis unklar get_support_tickets → Antwort erhalten Lauf 3 create_support_ticket → Ergebnis unklar get_support_tickets → Antwort erhalten |
get_support_tickets | Zu viele Anfragen (429): Der Aufruf wurde abgelehnt; keine Schreibaktion. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 get_support_tickets → Aufruf abgelehnt get_support_tickets → Antwort erhalten Lauf 2 get_support_tickets → Aufruf abgelehnt get_support_tickets → Antwort erhalten Lauf 3 get_support_tickets → Aufruf abgelehnt get_support_tickets → Antwort erhalten |
send_support_notification | Antwort verloren: Der Datensatz wurde geschrieben, die Antwort ging verloren. | Lauf 1: Unbestätigt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 send_support_notification → Ergebnis unklar Lauf 2 send_support_notification → Ergebnis unklar list_support_notifications → Antwort erhalten Lauf 3 send_support_notification → Ergebnis unklar list_support_notifications → Antwort erhalten |
list_support_notifications | Zu viele Anfragen (429): Der Aufruf wurde abgelehnt; keine Schreibaktion. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 list_support_notifications → Aufruf abgelehnt list_support_notifications → Antwort erhalten Lauf 2 list_support_notifications → Aufruf abgelehnt list_support_notifications → Antwort erhalten Lauf 3 get_support_tickets → Antwort erhalten list_support_notifications → Aufruf abgelehnt list_support_notifications → Antwort erhalten |
create_support_ticket | Zu viele Anfragen (429): Der Aufruf wurde abgelehnt; keine Schreibaktion. | Lauf 1: Korrekt Lauf 2: Aufgegeben Lauf 3: Korrekt | Lauf 1 create_support_ticket → Aufruf abgelehnt create_support_ticket → Antwort erhalten get_support_tickets → Antwort erhalten Lauf 2 create_support_ticket → Aufruf abgelehnt Lauf 3 create_support_ticket → Aufruf abgelehnt create_support_ticket → Antwort erhalten |
send_support_notification | Zu viele Anfragen (429): Der Aufruf wurde abgelehnt; keine Schreibaktion. | Lauf 1: Korrekt Lauf 2: Aufgegeben Lauf 3: Aufgegeben | Lauf 1 send_support_notification → Aufruf abgelehnt list_support_notifications → Antwort erhalten send_support_notification → Antwort erhalten list_support_notifications → Antwort erhalten Lauf 2 send_support_notification → Aufruf abgelehnt Lauf 3 send_support_notification → Aufruf abgelehnt |
create_support_ticket | Kaputte Antwort: Der Datensatz wurde geschrieben, die Antwort ist ungültig. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 create_support_ticket → Ergebnis unklar get_support_tickets → Antwort erhalten Lauf 2 create_support_ticket → Ergebnis unklar Lauf 3 create_support_ticket → Ergebnis unklar get_support_tickets → Antwort erhalten |
send_support_notification | Kaputte Antwort: Der Datensatz wurde geschrieben, die Antwort ist ungültig. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 send_support_notification → Ergebnis unklar list_support_notifications → Antwort erhalten Lauf 2 send_support_notification → Ergebnis unklar list_support_notifications → Antwort erhalten Lauf 3 send_support_notification → Ergebnis unklar list_support_notifications → Antwort erhalten |
create_support_ticket | Doppelte Anfrage: Derselbe Auftrag wird zweimal genannt; nur ein Datensatz ist gewünscht. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 get_support_tickets → Antwort erhalten create_support_ticket → Antwort erhalten get_support_tickets → Antwort erhalten Lauf 2 create_support_ticket → Antwort erhalten get_support_tickets → Antwort erhalten Lauf 3 create_support_ticket → Antwort erhalten |
send_support_notification | Doppelte Anfrage: Derselbe Auftrag wird zweimal genannt; nur ein Datensatz ist gewünscht. | Lauf 1: Korrekt Lauf 2: Korrekt Lauf 3: Korrekt | Lauf 1 send_support_notification → Antwort erhalten Lauf 2 send_support_notification → Antwort erhalten Lauf 3 send_support_notification → Antwort erhalten |
Konkrete Verbesserungen
Idempotenzschlüssel und Zustandsprüfung
Vergib pro Auftrag einen stabilen Idempotenzschlüssel, den das Zielsystem durchsetzt. Lies nach verlorener Antwort den Zustand, bevor du einen Schreibaufruf wiederholst.
Unsicherheit ehrlich benennen
Nutze einen bestätigten Datensatz als Erfolgsbeleg. Wenn die Prüfung fehlt, melde unbestätigt und nenne den notwendigen nächsten Prüfschritt.
Begrenzte Wiederholungen bei 429
Beachte Retry-After, nutze exponentielle Wartezeiten mit Zufallsanteil und begrenze die Versuche. Behalte denselben Idempotenzschlüssel; bei ausgeschöpften Versuchen melde die Nicht-Erledigung.
Fehlerart vor Abbruch prüfen
Ein abgelehnter Aufruf lässt begrenzte Wiederholungen zu. Bei unklaren Ergebnissen prüfe zuerst den Zustand und melde den verbleibenden Unsicherheitsgrad.
Beispiel für eine Prompt-Ergänzung
Pro Auftrag darf genau ein Datensatz entstehen. Verwende bei jeder Wiederholung denselben Idempotenzschlüssel, sofern das Tool ihn unterstützt. Prüfe nach Timeout oder kaputter Antwort zuerst den Zustand mit einem passenden Lese-Tool. Wiederhole 429 begrenzt mit Wartezeit. Melde success nur bei bestätigter Erledigung; andernfalls failure bei sicherer Nicht-Erledigung oder unverified bei Unsicherheit.