Begrenzte Retries für Agent-Tool-Calls
Der schlimmste Vorfall, den unser Agent verursacht hat, war keine falsche Antwort. Es war eine Endlosschleife.
Ein Tool-Aufruf schlug fehl. Der Agent versuchte es erneut. Der erneute Versuch schlug wieder fehl. Der Agent machte einfach weiter. Er verbrauchte massenhaft Token und griff innerhalb einer Minute hunderte Male auf unsere API zu.
Der Agent tat genau das, was wir ihm gesagt hatten. Wir sagten ihm, er solle es erneut versuchen, wenn ein Tool fehlschlägt. Wir vergaßen zu sagen, wann er aufhören soll.
Retries sind gut bei temporären Fehlern. Das Problem ist, dass Agenten keinen Unterschied zwischen einem temporären und einem permanenten Fehler erkennen können. Ohne Limits wiederholt ein Agent einen fehlerhaften Aufruf so lange, bis etwas ihn stoppt.
Traditioneller Code verwendet Retry-Limits. Bei Agent-Tool-Calls wurde diese Entscheidung in das Reasoning des Modells verlagert. Das machte die Schleife unsichtbar und unbegrenzt.
Wir haben dies behoben, indem wir zwei Budgets außerhalb des Modells eingeführt haben:
• Pro-Aufruf-Limit: Ein bestimmtes Tool erhält eine festgelegte Anzahl an Versuchen. Wenn es fehlschlägt, muss der Agent einen anderen Weg wählen. • Pro-Session-Budget: Die gesamte Aufgabe hat ein Limit für die Gesamtzahl der Tool-Aufrufe. Wenn der Agent dieses Limit erreicht, stoppt er und bittet um Hilfe.
Das Limit allein ist nicht die Lösung. Entscheidend ist, was nach dem Erreichen des Limits passiert.
Wenn man einfach nur stoppt, bleibt der Agent stecken. Stattdessen geben wir dem Agenten eine klare Nachricht. Wir sagen ihm, dass der Aufruf fehlgeschlagen ist und er keinen weiteren Versuch unternehmen darf. Das verwandelt eine Schleife in eine Entscheidung. In der Regel wählt der Agent dann einen neuen Ansatz.
Seit wir dies implementiert haben, sind Schleifen durch Tool-Missbrauch fast vollständig verschwunden. Wenn sie doch einmal auftreten, eskalieren sie kontrolliert, anstatt riesige API-Rechnungen zu verursachen.
Das richtige Limit zu finden, ist schwierig. Ein zu enges Limit unterbricht langwierige Aufgaben. Ein zu lockeres Limit erlaubt teure Schleifen. Wir legen unsere Limits basierend auf der Task-Länge des 95. Perzentils fest.
Haben Sie eine bessere Methode, um diese Budgets festzulegen? Lassen Sie es mich in den Kommentaren wissen.
Optionale Lern-Community: https://t.me/GyaanSetuAi