ReAct Agent spart 90% Retries durch Optimierung
Viele Entwicklerteams von LLM-Agenten, insbesondere solche, die auf ReAct-Systemen basieren, verschwenden bis zu 90 Prozent ihres Retry-Budgets. Eine umfassende Analyse von 200 simulierten Aufgaben zeigt, dass fast alle Wiederholungsversuche an nicht korrigierbaren Fehlern scheitern, hauptsächlich weil das System versucht, von der KI erfundene Werkzeugnamen erneut auszuführen. Das Kernproblem liegt nicht in der Prompt-Qualität, sondern in der Architektur: Die Entscheidung über den Werkzeugnamen erfolgt zur Laufzeit durch die KI, was zu Halluzinationen führt. Wenn die KI einen nicht existierenden Namen ausgibt, gibt das System einfach keine Information zurück und wiederholt den Vorgang, anstatt den Fehler zu klassifizieren. Die Untersuchung enthüllt eine kritische Lücke in der Überwachung. Dashboards zeigen oft nur Erfolgsraten, die bei dieser Konfiguration noch relativ hoch erscheinen könnten, verbergen aber den schleichenden Verbrauch von Ressourcen. In den Tests wurden 90,8 Prozent der Wiederholungen auf Werkzeugeinsatz angewendet, deren Erfolg von vornherein unmöglich war, da das entsprechende Werkzeug gar nicht existierte. Dies führt dazu, dass das Budget für echte, vorübergehende Fehler wie Netzwerkunterbrechungen nicht mehr ausreicht, was oft zum Gesamtausfall der Aufgabe führt, ohne dass die eigentliche Ursache sichtbar ist. Zur Behebung dieser strukturellen Mängel wurden drei wesentliche Änderungen vorgeschlagen. Erstens muss eine Fehlerklassifizierung implementiert werden, die vor jeder Wiederholung prüft, ob der Fehler überhaupt behoben werden kann. Fehler wie nicht gefundene Werkzeuge oder ungültige Eingaben sollten als nicht wiederholbar eingestuft werden und sofort abgebrochen werden, um das Budget zu schonen. Zweitens sollten pro Werkzeug Circuit Breaker statt eines globalen Zählers eingesetzt werden. Dies verhindert, dass der Ausfall eines einzelnen Werkzeugs das gesamte Budget des Agenten aufbraucht. Drittens, und am wichtigstmöglichen strukturellen Ansatz, sollte die Zuordnung von Werkzeugen in den Code verlagert werden. Anstatt der KI zu erlauben, Werkzeugnamen als Strings zu generieren, sollte der Plan in eine vordefinierte Struktur unterteilt werden, bei der die Werkzeugzuordnung deterministisch über ein Python-Wörterbuch erfolgt. Diese architektonische Änderung eliminiert Halluzinationen auf Routing-Ebene vollständig. In der Simulation erreichte der verbesserte Workflow eine Erfolgsquote von 100 Prozent im Vergleich zu 89,5 Prozent beim Standard-Ansatz. Noch wichtiger ist die Effizienz: Der neue Ansatz verschwendete null Prozent der Wiederholungen, während der alte Ansatz fast alle Ressourcen verbrannte. Die Varianz der ausgeführten Schritte reduzierte sich um das Dreifache, was zu besserer Planbarkeit und stabileren Latenzzeiten führt. Besonders bemerkenswert ist, dass die Erfolgsquote bei niedrigen Halluzinationsraten von 5 Prozent im herkömmlichen System zwar 100 Prozent betrug, aber dennoch mehr als die Hälfte der Wiederholungen verschwendet wurden. Ein solches System ist also in der Theorie gesund, hat aber bereits erheblichen Schaden für künftige, echte Ausfälle angerichtet. Die vorgestellten Lösungen lassen sich schrittweise in bestehenden Frameworks wie LangChain oder AutoGen umsetzen, ohne die gesamte Architektur zu ersetzen. Zuerst sollten Ausnahmeklassen definiert werden, um wiederholbare von irreparablen Fehlern zu unterscheiden. Anschließend sollten Wiederholungsschleifen auf diese Klassen beschränkt werden. Für maximale Stabilität ist eine Verschiebung der Werkzeugzuordnung in den Code ratsam, sofern die Aufgabenstruktur dies zulässt. Diese Maßnahmen ermöglichen es Entwicklern, Kosten zu sparen, die Vorhersagbarkeit von Systemen zu erhöhen und sicherzustellen, dass Retry-Ressourcen für tatsächliche technische Probleme genutzt werden können.
