Comment tester ce que fait votre agent IA quand ses outils échouent

Votre agent IA appelle des outils : API HTTP, serveurs MCP et autres services. Ces outils expirent au bout d’un certain délai, atteignent des limites de requêtes, retournent des erreurs et envoient des données sous des formats que vous n’attendez pas. Le modèle décide de ce qu’il faut faire en fonction de ce que votre code lui transmet. Si votre code transmet une exception, une chaîne vide ou rien du tout après une longue attente, l’agent se comporte différemment que s’il obtient une erreur claire.

Comment les défaillances des outils se produisent

  • L’agent se fige. Un appel d’outil sans délai d’attente fait attendre l’utilisateur.
  • L’agent boucle. Le modèle appelle encore et encore l’outil défaillant, épuisant des jetons et la limite de débit de l’outil.
  • L’agent le cache. Votre code masque l’erreur et le modèle répond comme si l’outil avait réussi.
  • L’agent plante. Une exception non gérée met fin à toute la conversation.

Comment gérer les échecs des outils

  1. Définissez un délai d’expiration pour chaque appel d’outil et un budget pour l’ensemble du tour. La spécification MCP indique que les clients doivent implémenter des délais d’attente pour les appels d’outils.
  2. Réessayez en cas d’erreurs temporaires dans le code. Gérez les réponses 429 et 503 dans le code de votre outil, respectez Retry-After, et limitez le nombre de tentatives, afin que le modèle n’ait pas à décider quand effectuer une nouvelle tentative.
  3. Renvoyer les erreurs au modèle sous forme de résultats clairs. MCP sépare les erreurs de protocole, comme un outil inconnu ou des arguments non valides, des erreurs d’exécution d’outil, comme une défaillance d’API. Il signale les erreurs d’exécution dans le résultat de l’outil avec isError: true, afin que le modèle puisse voir ce qui s’est passé. Dites ce qui a échoué et si réessayer est logique.
  4. Limitez le nombre d’appels d’outils par tour. Après un nombre défini d’échecs, arrêtez-vous et informez l’utilisateur.
  5. Validez les résultats de l’outil avant de les transmettre au modèle. La spécification MCP indique que les clients doivent le faire et doivent valider les résultats structurés par rapport au schéma de sortie de l’outil lorsqu’il en a un.
  6. Indiquez à l’utilisateur ce qui n’a pas fonctionné. Une réponse fondée sur un appel à un outil ayant échoué doit l’indiquer.

Comment tester la gestion des échecs des outils dans votre agent

Approach Ce que vous trouvez Ce que vous avez manqué
Test unitaire de votre wrapper d’outils avec un client simulé Comment votre code mappe l’erreur que vous avez écrite Ce que le modèle fait de cela, et comment l’outil réel échoue
Casser l’outil réel, par exemple arrêter le serveur ou révoquer une clé Un véritable échec de ce genre Limitations de débit, réponses lentes et données mal formées, que vous ne pouvez pas déclencher à la demande
Écrire une API factice ou un serveur MCP Toute réponse que vous écrivez dans un script Vous devez configurer votre agent pour qu’il cible le faux, et il s’écarte de l’outil réel
intercepter le trafic réel de l’agent et injecter des échecs Que font l’agent en cours d’exécution et le modèle avec les erreurs, la latence et les données incorrectes de l’outil réel Votre code isolé. Conservez vos tests unitaires pour cela.

La sortie du modèle peut varier entre les exécutions. Par conséquent, exécutez chaque scénario d’échec plusieurs fois.

Essayez-le dans votre application

Dev Proxy se trouve entre votre agent et ses outils et injecte des échecs, sans aucune modification du code de votre agent.

Pour les outils qui appellent des API HTTP, combinez des erreurs aléatoires, de la latence et une vérification que votre agent attend aussi longtemps que l’API le demande :

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

Définissez les erreurs dans errors-contoso-api.json, comme décrit dans Tester mon application avec des erreurs aléatoires. Définissez Retry-After sur 429 sur la valeur @dynamic. Le RetryAfterPlugin vérifie uniquement ceux-ci.

Pour les serveurs MCP qui utilisent STDIO, démarrez le serveur via devproxy stdio avec une configuration qui active MockStdioResponsePlugin, comme illustré dans l’exemplestdio de configuration. Enregistrez-le sous devproxyrc-stdio.json. Ensuite, placez ceci dans stdio-mocks.json afin de retourner une erreur d’exécution d’outil pour chaque requête tools/call :

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

Pour que votre agent l’utilise, modifiez la commande dans la configuration du serveur MCP de votre agent afin qu’il démarre le serveur via devproxy stdio. Utilisez la propriété nth sur un mock pour faire échouer uniquement un appel précis, et ajoutez le LatencyPlugin pour ralentir les réponses du serveur.

Pour tester ce que fait votre agent lorsque le modèle lui-même échoue, LanguageModelFailurePlugin fait halluciner le modèle, lui fait ignorer les instructions ou lui fait répondre dans un format incorrect. Consultez Test de mon application avec des défaillances des modèles de langage.

Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Réponses STDIO factices pour les serveurs MCP

Voir aussi

  • Dernière mise à jour :