Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures

Stellen Sie sich vor, Sie sind der Kapitän eines Raumschiffs, aber anstatt das Schiff selbst zu steuern, sprechen Sie mit einem sehr intelligenten, gesprächigen Roboter-Co-Piloten. Ihre Aufgabe ist es, dem Roboter Anweisungen zu geben, wie zum Beispiel „Schalte den Antrieb ein“ oder „Sende ein Notfallsignal“. In der Welt der Künstlichen Intelligenz werden diese Roboter LLM-Agenten (Large Language Model Agents) genannt, und die Dinge, die sie berühren, werden als Tools (Werkzeuge, wie zum Beispiel Computerprogramme oder Datenbanken) bezeichnet. Lange Zeit gingen Wissenschaftler davon aus, dass, wenn der Roboter ein Tool bittet, etwas zu tun, das Tool sofort mit „Erledigt!“ oder „Ups, fehlgeschlagen!“ antwortet. Es war wie ein perfektes Pingpong-Spiel, bei dem der Ball immer sofort zurückkommt.

Aber in der realen Welt sind die Dinge chaotischer. Manchmal senden Sie eine Nachricht, und das Netzwerk ist langsam, sodass Sie eine Zeit lang keine Antwort erhalten. Oder vielleicht ist die Nachricht tatsächlich durchgekommen und der Antrieb wurde gestartet, aber der Roboter hat das „Erledigt!“-Signal nie erhalten. Wenn der Robot dann in Panik gerät, weil er nichts gehört hat, ruft er vielleicht: „Mach es nochmal!“, und schaltet versehentlich den Antrieb zweimal ein. In dieser Arbeit geht es darum, diese Roboter-Co-Piloten zu lehren, wie sie mit diesen verwirrenden Momenten umgehen, ohne Chaos anzurichten. Es wird vorgeschlagen, dass der Roboter, anstatt nur zu raten und es erneut zu versuchen, einen kurzen Blick darauf werfen sollte, ob die Aufgabe tatsächlich schon erledigt ist.

Das Problem: Das „Hat es funktioniert?“-Rätsel

Die Forscher stellten eine große Lücke in der Funktionsweise dieser KI-Agenten fest. Die meisten aktuellen Systeme agieren so, als befänden sie sich in einer perfellen, instantanen Welt. Sie gehen davon aus, dass, wenn ein Tool-Aufruf (wie das Versenden einer E-Mail oder das Aktualisieren eines Bankkontos) keine klare „Erfolgs“-Meldung liefert, er definitiv fehlgeschlagen ist.

Doch reale Computersysteme sind wie eine geschäftige Postfiliale. Manchmal wird ein Brief zugestellt, aber der Beleg über die Zustellung geht auf dem Postweg verloren. Manchmal kommt der Brief an, aber die Person, die den Briefkasten kontrolliert, hat ihn noch nicht gesehen (eine Verzögerung). Manchmal wird der Brief nur halb zugestellt. In der Arbeit nennen die Autoren dies nicht-atomare Fehler. „Atomar“ bedeutet, dass etwas auf einmal geschieht, wie das Umlegen eines Lichtschalters. „Nicht-atomar“ bedeutet, dass es unordentlich ist, mit Verzögerungen und Teilschritten.

Wenn ein KI-Agent mit diesem Chaos konfrontiert wird, gerät er oft in Panik. Wenn er einen Befehl sendet und ein Timeout (keine Antwort) erhält, denkt er: „Oh nein, es hat nicht funktioniert!“ und versucht es erneut. Aber wenn der erste Befehl eigentlich funktioniert hat, hat der Agent gerade ein Duplikat erstellt. Stellen Sie sich vor, Sie bestellen eine Pizza, erhalten keine Antwort vom Laden und rufen fünfmal beim Laden an. Jetzt haben Sie statt einer fünf Pizzen. In der digitalen Welt könnte das bedeutsam sein, indem man fünf wütende E-Mails an einen Kunden sendet oder eine Kreditkarte fünfmal belastet.

Die Lösung: Der „Check-First“-Wrapper

Um dies zu beheben, haben die Autoren einen einfachen, leichtgewichtigen „Wrapper“ (eine Sicherheitsebene) um die Tools gebaut, die die Agenten verwenden. Sie nennen es ein Verify-Before-Retry-System (Verifizieren-vor-dem-Wiederholen).

So funktioniert es, unter Verwendung einer einfachen Analogie:
Stellen Sie sich vor, Sie versuchen, ein Bild an eine Wand zu hängen.

1. Der alte Weg (Naives Wiederholen): Sie schlagen den Nagel ein. Sie hören kein „Thud“ (Aufschlaggeräusch), also denken Sie, Sie hätten daneben geschlagen. Sie schlagen erneut zu. Und wieder. Am Ende enden Sie mit einem riesigen, ruinierten Loch in der Wand, weil Sie immer weitergehämmert haben, obwohl das Bild bereits hing.
2. Der neue Weg (Verify-Before-Retry): Sie schlagen den Nagel ein. Sie hören kein „Thud“. Anstatt sofort wieder zu hämmern, schauen Sie an die Wand. Sie prüfen: „Hängt das Bild?“
   • Wenn das Bild da ist, hören Sie auf. Sie hämmern nicht noch einmal.
   • Wenn das Bild nicht da ist, dann hämmern Sie erneut.

Dieser Wrapper fügt dem Verhalten des Agenten drei kluge Regeln hinzu:

1. Trennen Sie das Signal von der Realität: Nur weil Sie keine „Erfolg“-Meldung erhalten haben, bedeutet das nicht, dass die Aktion fehlgeschlagen ist.
2. Prüfen Sie, bevor Sie wiederholen: Bevor der Agent einen Befehl erneut versucht, muss er zuerst den tatsächlichen Zustand der Welt (die Postbedingung) prüfen, um zu sehen, ob die Aufgabe bereits erledigt ist.
3. Nutzen Sie einen magischen Schlüssel (Idempotenz): Wenn der Agent doch wiederholen muss, verwendet er einen speziellen „magischen Schlüssel“ (einen Idempotenz-Schlüssel). Dies sagt dem Computersystem: „Hey, ich versuche das hier nochmal, aber es ist exakt dieselbe Anfrage. Wenn du es bereits erledigt hast, ignoriere diese zweite Anfrage einfach.“

Was sie herausgefunden haben: Weniger Fehler, gleicher Erfolg

Die Forscher testeten diese Idee in einer simulierten Umgebung, in der sie absichtlich Dinge kaputt machten, um zu sehen, wie die Agenten reagieren würden. Sie erstellten zwei Hauptaufgaben:

• Aktivierung eines Kunden: Erstellen eines Benutzerkontos und Versenden von genau einer Willkommensnachricht.
• Erfassung einer Rechnung: Aktualisieren einer Rechnung und Markieren als bezahlt.

Sie injizierten verschiedene Arten von „Pech“ in das System, wie etwa Netzwerk-Timeouts, verzögerte Aktualisierungen und Teilfehler. Sie verglichen die alte Methode („einfach wiederholen“) mit ihrer neuen „Check-First“-Methode.

Die Ergebnisse waren eindeutig und ziemlich dramatisch:

• Duplikate von Aktionen: Die alte Methode war ein Desaster, wenn Dinge schiefgingen. Bei der Aufgabe „Kunden aktivieren“ schickten die alten Agenten, wenn Fehler häufig auftraten, 72 % der Zeit doppelte Willkommensnachrichten. Der neue „Verify-Before-Retry“-Agent reduzierte dies auf nur 20 %. In der Aufgabe „Rechnung erfassen“ erstellte der alte Agent bei hohen Fehlerraten 76 % der Zeit doppelte Datensätze, während der neue Agent diesen Wert auf 20 % senkte (im Vergleich zu 0 % bei geringer Fehlerrate und 16 % bei mittlerer Fehlerrate).
• Aufgabenerfolg: Die neue Methode verhinderte nicht nur Fehler; sie half den Agenten auch dabei, ihre Aufgaben besser abzuschließen. Für die Kundenaufgabe war der neue Agent zu 100 % erfolgreich, selbst als das System defekt war. Die Erfolgsrate des alten Agenten sank auf 64 %, wenn die Dinge problematisch wurden. Für die Rechnungsaufgabe war die Baseline bereits recht stark (sie erreichte 100 % bei geringer Fehlerrate und 96 % bei hoher Fehlerrate), aber der neue Wrapper stellte eine Erfolgsquote von 100 % sicher, selbst bei den höchsten Fehlerraten, und bewahrte die Zuverlässigkeit, wo die Baseline leicht absank.

Die Autoren führten auch einen speziellen Test durch, um zu sehen, welcher Teil ihres neuen Systems die Hauptarbeit leistete. Sie fanden heraus, dass die Verifizierung (das Prüfen, ob die Aufgabe erledigt ist) der wichtigste Teil war. Einfach den Zustand zu prüfen und nicht zu wiederholen, war fast so gut wie das vollständige System. Dies deutet darauf darauf hin, dass das Hauptproblem nicht darin bestand, dass die Agenten härter arbeiten mussten, sondern dass sie zu hart arbeiteten, wenn sie es gar nicht nötig hatten.

Warum das wichtig ist

Das Paper legt nahe, dass wir das KI-Modell nicht unbedingt „schlauer“ machen oder sein Gehirn ändern müssen, um diese Probleme zu lösen. Stattdessen müssen wir nur ändern, wie es mit den Tools interagiert. Indem wir einen einfachen Schritt hinzufügen, um „hinzuschauen, bevor man springt“, können wir KI-Agenten viel zuverlässiger machen.

Dies ist besonders wichtig für Aufgaben, bei denen eine doppelte Ausführung katastrophal wäre, wie etwa beim Versenden von Geld oder beim Löschen von Dateien. Die Studie zeigt, dass wir in einer Welt, in der Computersysteme oft unordentlich und verzögert sind, die beste Art und Weise, einen zuverlässigen Roboter zu bauen, darin besteht, ihm beizubringen, seine Arbeit doppelt zu prüfen, bevor er in Panik gerät und es einfach noch einmal versucht. Es ist eine kleine Änderung in der Software, die viel digitale Unordnung verhindern kann.