Hoe u kunt testen wat uw AI-agent doet wanneer de hulpprogramma's mislukken

Uw AI-agent roept hulpprogramma's aan: HTTP-API's, MCP-servers en andere services. Deze hulpprogramma's krijgen time-outs, lopen tegen frequentielimieten aan, retourneren fouten en verzenden gegevens in structuren die u niet had verwacht. Het model bepaalt wat het vervolgens moet doen op basis van wat uw code eraan doorgeeft. Als uw code een uitzondering, een lege tekenreeks of helemaal niets doorgeeft na een lange wachttijd, gedraagt de agent zich anders dan wanneer deze een duidelijke foutmelding krijgt.

Hoe storingen van hulpprogramma's ontstaan

  • De agent loopt vast. Met een aanroep van een hulpprogramma zonder time-out blijft de gebruiker wachten.
  • De agent herhaalt zich. Het model roept de falende tool opnieuw en opnieuw aan met behulp van tokens en de frequentielimiet van de tool.
  • De agent verbergt het. Uw code slikt de fout in en het model beantwoordt alsof de tool succesvol was.
  • De agent crasht. Een onverwerkte uitzondering beëindigt de volledige conversatie.

Hulpprogrammafouten afhandelen

  1. Stel een time-out in voor elke aanroep van het hulpprogramma en een budget voor de volledige interactie. Volgens de MCP-specificatie moeten clients time-outs implementeren voor hulpprogramma-aanroepen.
  2. Probeer het opnieuw bij tijdelijke fouten in code. Verwerk 429- en 503-antwoorden in je hulpprogrammacode, respecteer Retry-After en capeer de pogingen, zodat het model niet hoeft te beslissen wanneer je het opnieuw moet proberen.
  3. Retourneer fouten aan het model terug als duidelijke resultaten. MCP scheidt protocolfouten, zoals een onbekend hulpprogramma of ongeldige argumenten, van fouten bij het uitvoeren van hulpprogramma's, zoals een API-fout. Het rapporteert uitvoeringsfouten in het resultaat van het hulpprogramma, isError: truezodat het model kan zien wat er mis is gegaan. Zeg wat is mislukt en of het opnieuw proberen zinvol is.
  4. Beperk het aantal toolaanroepen per interactieronde. Stop na een vast aantal fouten en vertel het de gebruiker.
  5. Valideer de resultaten van het hulpprogramma voordat u ze doorgeeft aan het model. De MCP-specificatie geeft aan dat clients dit moeten doen en gestructureerde resultaten moeten valideren op basis van het uitvoerschema van het hulpprogramma wanneer het er een heeft.
  6. Vertel de gebruiker wat niet werkte. Een antwoord dat is gebaseerd op een mislukte toolaanroep, moet dit zeggen.

Hoe u de foutafhandeling van tools in uw agent test

Approach Wat u vindt Wat u mist
Unit test uw tool wrapper met een stubbed client Hoe uw code de storing die u hebt geschreven in kaart brengt Wat het model ermee doet en hoe het echte hulpprogramma mislukt
Schakel het echte hulpprogramma uit, bijvoorbeeld door de server te stoppen of een sleutel in te trekken Een echt falen van dat soort Frequentielimieten, trage reacties en ongeldig gevormde gegevens, die u niet op aanvraag kunt veroorzaken
Een nep-API of MCP-server schrijven Elk antwoord dat u scriptt Je moet je agent op de nep laten richten, en het wijkt af van de echte tool
Het echte toolverkeer van de agent onderscheppen en fouten injecteren Wat de actieve agent en het model doen met fouten, latentie en slechte gegevens uit het echte hulpprogramma Uw code afzonderlijk. Bewaar daar je unit tests voor.

Modeluitvoer kan variëren tussen uitvoeringen, dus voer elk foutscenario meerdere keren uit.

Probeer het in uw app

Dev Proxy bevindt zich tussen uw agent en de bijbehorende hulpprogramma's en injecteert fouten, zonder wijzigingen in de code van uw agent.

Voor hulpprogramma's die HTTP-API's aanroepen, combineer willekeurige fouten, latentie en controleer of uw agent wacht zolang de API vraagt:

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

Geef de fouten op in errors-contoso-api.json, zoals beschreven in Mijn app testen met willekeurige fouten. Stel Retry-After in op @dynamic voor uw 429-antwoorden. De RetryAfterPlugin controleert alleen die verzoeken.

Voor MCP-servers die GEBRUIKMAKEN van STDIO, start u de server met devproxy stdio een configuratie waarmee mockStdioResponsePlugin wordt ingeschakeld, zoals wordt weergegeven in het stdio configuratievoorbeeld. Sla het op als devproxyrc-stdio.json. Plaats dit vervolgens in stdio-mocks.json om een fout bij het uitvoeren van een hulpprogramma te retourneren voor elke tools/call aanvraag:

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

Als u wilt dat uw agent dit gebruikt, wijzigt u de opdracht in de MCP-serverconfiguratie van uw agent, zodat de server wordt gestart via devproxy stdio. Gebruik de nth eigenschap in een mock om alleen een specifieke aanroep te laten mislukken en voeg de LatencyPlugin toe om de reacties van de server te vertragen.

Als u wilt testen wat uw agent doet wanneer het model zelf mislukt, laat LanguageModelFailurePlugin het model hallucineren, instructies negeren of in de verkeerde indeling antwoorden. Zie Test mijn app met fouten in het taalmodel.

Om Dev Proxy te installeren, raadpleegt u Dev Proxy instellen.

Volgende stappen 

Gesimuleerde STDIO-reacties voor MCP-servers

Zie ook

  • Laatst bijgewerkt om