Så här testar du vad AI-agenten gör när dess verktyg misslyckas

AI-agenten anropar verktyg: HTTP-API:er, MCP-servrar och andra tjänster. Dessa verktyg överskrider tidsgränsen, stöter på frekvensbegränsningar, returnerar fel och skickar data i former som du inte förväntade dig. Modellen bestämmer vad den ska göra härnäst baserat på vad koden skickar tillbaka till den. Om koden skickar tillbaka ett undantag, en tom sträng eller inget alls efter en lång väntan beter sig agenten annorlunda än om koden returnerar ett tydligt fel.

Så här uppstår fel i verktyg

  • Agenten låser sig. Ett verktygsanrop utan tidsgräns gör att användaren väntar.
  • Agenten går i loop. Modellen anropar det misslyckade verktyget om och om igen och förbrukar token och verktygets gräns för anropsfrekvens.
  • Agenten döljer det. Koden sväljer felet och modellen svarar som om verktyget lyckades.
  • Agenten kraschar. Ett ohanterat undantag avslutar hela konversationen.

Hantera verktygsfel

  1. Ange en tidsgräns för varje verktygsanrop och en budget för hela turen. MCP-specifikationen säger att klienter bör implementera tidsgränser för verktygsanrop.
  2. Försök igen vid tillfälliga fel i koden. Hantera 429- och 503-svar i verktygskoden, respektera Retry-Afteroch begränsa försöken, så att modellen inte behöver bestämma när den ska försöka igen.
  3. Returnera misslyckanden till modellen som tydliga resultat. MCP separerar protokollfel, till exempel ett okänt verktyg eller ogiltiga argument, från verktygskörningsfel, till exempel ett API-fel. Den rapporterar körningsfel i verktygets resultat med isError: true, så att modellen kan se vad som gick fel. Säg vad som misslyckades och om det är vettigt att försöka igen.
  4. Begränsa antalet verktygsanrop per tur. Efter ett angivet antal fel, stoppa och informera användaren.
  5. Verifiera verktygsresultat innan du skickar dem till modellen. MCP-specifikationen säger att klienter ska göra detta, och bör validera strukturerade resultat mot verktygets schema för utdata när ett sådant finns.
  6. Berätta för användaren vad som inte fungerade. Ett svar som bygger på ett misslyckat verktygsanrop bör säga det.

Så här testar du verktygsfelhantering i din agent

Approach Det här hittar du Vad du saknar
Enhetstesta verktygs-wrappern med en klient med stub Hur koden mappar felet du skrev Vad modellen gör med den och hur det verkliga verktyget misslyckas
Gör något som påverkar det riktiga systemet, till exempel stoppa servern eller återkalla en nyckel Ett verkligt misslyckande av det slaget Begränsningar av begärandefrekvens, långsamma svar och felaktiga data, vilket du inte kan orsaka på begäran
Skriv ett falskt API eller en MCP-server Alla svar som du skapar med skript Du måste rikta agenten mot den falska, och den glider bort från det verkliga verktyget
Fånga upp agentens verkliga verktygstrafik och injicera fel Vad agenten som körs och modellen gör med fel, svarstider och felaktiga data från det verkliga verktyget Din kod i isolering. Spara det till enhetstesterna.

Modellutdata kan variera mellan körningar, så kör varje felscenario mer än en gång.

Prova det i din app

Dev Proxy finns mellan din agent och dess verktyg och injicerar fel, utan ändringar i agentens kod.

För verktyg som anropar HTTP-API:er kombinerar du slumpmässiga fel, svarstider och en kontroll av att agenten väntar så länge som API:et anger:

{
  "$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
  }
}

Definiera felen i errors-contoso-api.json, enligt beskrivningen i Testa min app med slumpmässiga fel. Ställ in Retry-After på @dynamic för dina 429-svar. RetryAfterPlugin kontrollerar endast dessa.

För MCP-servrar som använder STDIO startar du servern via devproxy stdio med en konfiguration som aktiverar MockStdioResponsePlugin, som visas i stdio konfigurationsexemplet. Spara den som devproxyrc-stdio.json. Lägg sedan detta i stdio-mocks.json för att returnera ett körningsfel för varje tools/call begäran:

{
  "$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

Om du vill att agenten ska använda den ändrar du kommandot i agentens MCP-serverkonfiguration så att servern startas via devproxy stdio. Använd egenskapen nth på en mock för att bara misslyckas med ett specifikt anrop och lägg till LatencyPlugin för att göra serverns svar långsammare.

Om du vill testa vad din agent gör när själva modellen misslyckas får LanguageModelFailurePlugin modellen att hallucinera, ignorera instruktioner eller svara i fel format. Se Testa appen med språkmodellfel.

Information om hur du installerar Dev Proxy finns i Installera Dev Proxy.

Nästa steg

Se även