So testen Sie, was Ihr KI-Agent tut, wenn seine Tools fehlschlagen

Ihr KI-Agent ruft Tools auf: HTTP-APIs, MCP-Server und andere Dienste. Diese Tools laufen in Zeitüberschreitungen, stoßen an Trefferratenbeschränkungen, geben Fehler zurück und senden Daten in Formen, die Sie nicht erwartet haben. Das Modell entscheidet, was als Nächstes zu tun ist, basierend auf dem, was Ihr Code an ihn zurückgibt. Wenn Ihr Code nach einer langen Wartezeit einen Fehler, eine leere Zeichenfolge oder gar nichts zurückgibt, verhält sich der Agent anders, als wenn er eine klare Fehlermeldung erhält.

Wie Tool-Ausfälle schiefgehen

• Der Agent reagiert nicht mehr. Ein Toolaufruf ohne Timeout lässt den Benutzer warten.
• Der Agent führt eine Schleife aus. Das Modell ruft das fehlerhafte Tool immer wieder auf, wodurch Token und das Ratelimit des Tools aufgebraucht werden.
• Der Agent vertuscht es. Ihr Code verschluckt den Fehler, und das Modell antwortet so, als ob das Tool erfolgreich war.
• Der Agent stürzt ab. Eine unbehandelte Ausnahme beendet die gesamte Unterhaltung.

Behandeln von Toolfehlern

1. Legen Sie ein Timeout für jeden Toolaufruf und ein Budget für die gesamte Interaktion fest. Die MCP-Spezifikation besagt, dass Clients Timeouts für Toolaufrufe implementieren sollten.
2. Bei temporären Fehlern im Code erneut versuchen. Behandeln Sie 429- und 503-Antworten in Ihrem Toolcode, beachten Sie Retry-After, und begrenzen Sie die Anzahl der Versuche, sodass das Modell nicht entscheiden muss, wann ein erneuter Versuch erfolgen soll.
3. Geben Sie Fehlerfälle als klare Ergebnisse an das Modell zurück. MCP trennt Protokollfehler, z. B. ein unbekanntes Tool oder ungültige Argumente, von Toolausführungsfehlern wie einem API-Fehler. Es meldet Ausführungsfehler im Toolergebnis mit isError: true, damit das Modell sehen kann, was schief gelaufen ist. Sagen Sie, was fehlgeschlagen ist und ob es sinnvoll ist, es erneut zu versuchen.
4. Begrenzen Sie die Anzahl der Toolaufrufe pro Schritt. Beenden Sie nach einer festgelegten Anzahl von Fehlern den Vorgang und informieren Sie den Benutzer.
5. Überprüfen Sie die Toolergebnisse, bevor Sie sie an das Modell übergeben. Die MCP-Spezifikation besagt, dass Clients dies tun sollten, und sie sollten strukturierte Ergebnisse anhand des Ausgabeschemas des Tools überprüfen, wenn das Tool ein solches hat.
6. Teilen Sie dem Benutzer mit, was nicht funktioniert hat. Eine Antwort, die auf einem fehlgeschlagenen Toolanruf basiert, sollte dies sagen.

So testen Sie die Behandlung von Toolfehlern in Ihrem Agent

Die Modellausgabe kann zwischen den Ausführungsläufen variieren. Führen Sie daher jedes Fehlerszenario mehrmals aus.

Probieren Sie sie mit Ihrer App aus

Dev Proxy befindet sich zwischen Ihrem Agent und seinen Tools und fügt Fehler ein, ohne änderungen am Code Ihres Agents.

Kombinieren Sie bei Tools, die HTTP-APIs aufrufen, zufällige Fehler, Latenz und eine Überprüfung, dass Ihr Agent so lange wartet, wie von der API verlangt:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "RetryAfterPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll"
    },
    {
      "name": "LatencyPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "latencyPlugin"
    },
    {
      "name": "GenericRandomErrorPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "errorsContosoApi"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "latencyPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/latencyplugin.schema.json",
    "minMs": 2000,
    "maxMs": 10000
  },
  "errorsContosoApi": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/genericrandomerrorplugin.schema.json",
    "errorsFile": "errors-contoso-api.json",
    "rate": 50
  }
}

Definieren Sie die Fehler in errors-contoso-api.json, wie unter Meine App mit zufälligen Fehlern testen beschrieben. Setzen Sie Retry-After für Ihre 429-Antworten auf @dynamic fest. Der RetryAfterPlugin überprüft nur diejenigen.

Starten Sie für MCP-Server, die STDIO verwenden, den Server über devproxy stdio mit einer Konfiguration, die den MockStdioResponsePlugin aktiviert, wie im stdio Konfigurationsbeispiel gezeigt. Speichern Sie es als devproxyrc-stdio.json. Fügen Sie dies dann in stdio-mocks.json ein, um einen Toolausführungsfehler für jede tools/call Anforderung zurückzugeben:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockstdioresponseplugin.mocksfile.schema.json",
  "mocks": [
    {
      "request": {
        "bodyFragment": "tools/call"
      },
      "response": {
        "stdout": "{\"jsonrpc\":\"2.0\",\"id\":@stdin.body.id,\"result\":{\"content\":[{\"type\":\"text\",\"text\":\"Failed to fetch weather data: API rate limit exceeded\"}],\"isError\":true}}\n"
      }
    }
  ]
}

devproxy stdio --config-file devproxyrc-stdio.json npx -y @modelcontextprotocol/server-filesystem

Damit Ihr Agent dies verwendet, ändern Sie den Befehl in der MCP-Serverkonfiguration Ihres Agents, damit er den Server über devproxy stdio startet. Verwenden Sie bei einem Mock die nth Eigenschaft, um nur einen bestimmten Aufruf fehlschlagen zu lassen, und fügen Sie das LatencyPlugin hinzu, um die Antworten des Servers zu verlangsamen.

Um zu testen, was Ihr Agent tut, wenn das Modell selbst fehlschlägt, lässt das LanguageModelFailurePlugin das Modell halluzinieren, Anweisungen ignorieren oder im falschen Format antworten. Siehe Meine App mit Sprachmodellfehlern testen.

Zum Installieren von Dev Proxy siehe Einrichten von Dev Proxy.

Nächste Schritte

Siehe auch

• stdio Befehl
• Langsame API-Antworten simulieren
• LLM-Ratenlimits: Token pro Minute, Anfragen pro Minute und was passiert, wenn Sie sie erreicht haben
• So testen Sie, ob Ihr KI-Agent Anweisungen folgt, die in Toolantworten ausgeblendet sind