Umgang mit Tool-Fehlern und Teilergebnissen in einer Agentenschleife

Worum es geht

Drei Ausgänge brauchen drei unterschiedliche Ergebnisse. Ein Protokollfehler (unbekanntes Tool, ungültige Argumente, Server nicht erreichbar) ist ein Fehlschlag des Aufrufs selbst; das Model Context Protocol meldet diese als JSON-RPC-Fehler. Ein Ausführungsfehler des Tools (die vorgelagerte API lieferte 500, die Datei existiert nicht, die Abfrage lief in einen Timeout) ist ein gültiges Ergebnis, das besagt, dass die Operation fehlgeschlagen ist; MCP gibt dies im Ergebnis mit isError: true zurück, und die Tool-Use-Dokumentation des Anbieters beschreibt das gleichwertige Flag is_error: true an einem tool_result-Block, wonach das Modell den Fehler in seinen nächsten Schritt einbezieht. Ein Teilergebnis (7 von 10 Dateien verarbeitet, die erste Seite einer Suche, ein Batch mit zwei abgelehnten Zeilen) ist ein Erfolg, dessen Inhalt sagen muss, was fehlt.

Warum es wichtig ist

Ein Agent handelt danach, was das Tool-Ergebnis sagt. Eine Exception, die das Modell nie erreicht, erzeugt eine selbstsichere Antwort, die auf nichts beruht. Ein Fehler ohne Details erzeugt blinde Wiederholungen desselben Aufrufs. Ein als vollständig gemeldetes Teilergebnis erzeugt eine als erledigt markierte Aufgabe, bei der Zeilen stillschweigend verloren gehen.

So wird es angewendet

• Nie eine Exception aus dem Tool entkommen lassen; sie fangen und ein Fehlerergebnis mit stabilem Fehlertyp, der Meldung und, wo bekannt, ob ein erneuter Versuch helfen kann, zurückgeben (nicht bei einem 404, ja bei einem Timeout).
• Bei Teilergebnissen den erfolgreichen Teil plus eine ausdrückliche Liste dessen, was fehlgeschlagen ist und weshalb, sowie einen Cursor oder Identifikator zum Fortsetzen zurückgeben.
• Fehlertext kurz und sachlich halten; keine Stack-Traces oder vorgelagerte Ausgaben, die eingeschleuste Anweisungen tragen könnten.
• Wiederholungsgrenzen in der Schleife durchsetzen, nicht per Anweisung: Dasselbe Tool mit denselben Argumenten ist nach einem Fehler eine feste Anzahl Male erlaubt, danach gibt die Schleife die Kontrolle mit einer Zusammenfassung zurück.
• Schreibende Tools idempotent machen oder ihnen einen Idempotenzschlüssel geben, damit ein erneuter Versuch nach einem mehrdeutigen Fehlschlag die Wirkung nicht verdoppelt.
• „Keine Ergebnisse" von „Fehler" unterscheiden: eine leere Suche ist ein gültiges, vollständiges Ergebnis.
• Jedes Fehlerergebnis mit der Lauf-ID protokollieren; das Muster der Fehler ist der Nutzbarkeitsbericht des Tools.

Stolpersteine

Bei einem Fehlschlag null oder eine leere Zeichenkette zurückzugeben. Jeden Fehlschlag auf eine generische Meldung abzubilden. Das Modell entscheiden zu lassen, wie oft es erneut versucht. Für eine fachliche Bedingung einen Protokollfehler auszulösen („Bestellung nicht gefunden" ist ein Ergebnis, kein fehlerhafter Aufruf). Teilergebnisse nur in einem Log offenzulegen, das das Modell nie sieht.