Jak otestovat, co agent AI dělá, když jeho nástroje selžou

Agent AI volá nástroje: rozhraní HTTP API, servery MCP a další služby. U těchto nástrojů dochází k vypršení časového limitu, narážejí na limity frekvence, vracejí chyby a odesílají data ve strukturách, které jste nečekali. Model se rozhodne, co dělat dál, na základě toho, co váš kód předá zpět. Pokud váš kód po dlouhém čekání předá výjimku, prázdný řetězec nebo vůbec nic, agent se chová jinak než v případě, že obdrží jasnou chybu.

Jak dochází k selháním nástrojů

  • Agent se zasekne. Volání nástroje bez časového limitu udržuje uživatele čekající.
  • Agent se opakuje. Model znovu a znovu volá nástroj, který selhává, čímž vyčerpává tokeny i limit rychlosti nástroje.
  • Agent to zatajuje. Kód chybu spolkne a model odpoví, jako by nástroj proběhl úspěšně.
  • Agent spadne. Neošetřená výjimka ukončí celou konverzaci.

Jak řešit selhání nástrojů

  1. Nastavte časový limit pro každé volání nástroje a rozpočet na celé kolo. Specifikace MCP říká, že klienti by měli implementovat časové limity pro volání nástrojů.
  2. Opakovat při dočasných chybách v kódu. Ošetřete odpovědi 429 a 503 v kódu nástroje, respektujte Retry-After a omezte počet pokusů, takže se model nemusí rozhodnout, kdy to zkusit znovu.
  3. Vraťte selhání modelu jako jasné výsledky. MCP odděluje chyby protokolu, jako je neznámý nástroj nebo neplatné argumenty, od chyb provádění nástrojů, jako je selhání rozhraní API. Hlásí chyby spuštění ve výsledku nástroje pomocí isError: true, aby model viděl, co se nepovedlo. Řekněte, co se nezdařilo a zda má smysl to zkusit znovu.
  4. Omezte počet volání nástrojů na jeden tah. Po určitém počtu selhání zastavte a informujte uživatele.
  5. Než je předáte modelu, ověřte výsledky nástroje. Specifikace MCP říká, že klienti by to měli udělat a měli by ověřit strukturované výsledky vůči výstupnímu schématu nástroje, pokud ho má.
  6. Řekněte uživateli, co nefungovalo. Odpověď založená na neúspěšném volání nástroje by to měla říct.

Jak testovat zpracování selhání nástroje v agentu

Approach Co najdete Co vám chybí
Otestujte obálku nástroje jednotkovými testy pomocí stubovaného klienta Jak váš kód mapuje chybu, kterou jste popsali Co s ním dělá model a jak selhává skutečný nástroj
Narušte skutečný nástroj, například zastavením serveru nebo odvoláním klíče Skutečné selhání tohoto typu Omezení rychlosti, pomalé odpovědi a nesprávně formátovaná data, které nelze vyvolat na požádání
Napište falešné rozhraní API nebo server MCP Jakákoli odpověď vytvořená pomocí skriptu Musíte nasměrovat svého agenta na falešný cíl a odchýlí se od skutečného nástroje.
Zachyťte skutečný provoz nástroje agenta a vložte selhání Co dělá spuštěný agent a model s chybami, latencí a chybnými daty z reálného nástroje Váš kód v izolaci. Na to si nechte jednotkové testy.

Výstup modelu se může mezi spuštěními lišit, takže spusťte každý scénář selhání více než jednou.

Vyzkoušejte si ji v aplikaci

Dev Proxy se nachází mezi vaším agentem a jeho nástroji a simuluje selhání beze změn kódu vašeho agenta.

U nástrojů, které volají rozhraní HTTP API, zkombinujte náhodné chyby, latenci a zkontrolujte, zda váš agent čeká po dobu, kterou rozhraní API požaduje:

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

Definujte chyby v errors-contoso-api.jsonsouboru , jak je popsáno v Otestujte moji aplikaci náhodnými chybami. Nastavte Retry-After na @dynamic u svých 429 odpovědí. RetryAfterPlugin kontroluje pouze tyto.

Pro servery MCP, které používají STDIO, spusťte server prostřednictvím devproxy stdio s konfigurací, která umožňuje MockStdioResponsePlugin, jak je uvedeno v stdio příkladu konfigurace. Uložte ho jako devproxyrc-stdio.json. Pak ho vložte stdio-mocks.json , aby se vrátila chyba při spuštění nástroje pro každý tools/call požadavek:

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

Pokud chcete, aby ho váš agent používal, změňte příkaz v konfiguraci serveru MCP vašeho agenta, aby server spouštěl přes devproxy stdio. Vlastnost nth u mocku použijte k selhání pouze konkrétního volání a přidejte LatencyPlugin ke zpomalení odpovědí serveru.

Pokud chcete otestovat, co váš agent dělá, když samotný model selže, LanguageModelFailurePlugin způsobí, že model halucinuje, ignoruje pokyny nebo odpovídá v nesprávném formátu. Podívejte se na Testování aplikace s chybami jazykového modelu.

Pokud chcete nainstalovat Dev Proxy, přečtěte si téma Nastavení Dev Proxy.

Další kroky

Simulované odpovědi STDIO pro servery MCP

Viz také

  • Poslední aktualizace v