Jak przetestować, co robi agent sztucznej inteligencji, gdy jego narzędzia zawodzą

Agent sztucznej inteligencji wywołuje narzędzia: interfejsy API HTTP, serwery MCP i inne usługi. Te narzędzia przekraczają limit czasu, napotykają limity szybkości, zwracają błędy i wysyłają dane w formatach, których się nie spodziewasz. Model decyduje, co zrobić dalej, na podstawie tego, co Twój kod przekazuje mu z powrotem. Jeśli kod zwraca wyjątek, pusty ciąg lub nic w ogóle po długim oczekiwaniu, agent zachowuje się inaczej, niż jeśli otrzyma jednoznaczny błąd.

Jak dochodzi do awarii narzędzi

  • Agent się zawiesza. Wywołanie narzędzia bez limitu czasu powoduje, że użytkownik czeka.
  • Agent wykonuje pętlę. Model ponownie wywołuje narzędzie, które kończy się niepowodzeniem, używając tokenów i limitu szybkości narzędzia.
  • Agent to zakrywa. Kod połyka błąd, a model odpowiada tak, jakby narzędzie zakończyło się pomyślnie.
  • Agent ulega awarii. Nieobsługiwany wyjątek kończy całą rozmowę.

Jak postępować w przypadku awarii narzędzi

  1. Ustaw limit czasu dla każdego wywołania narzędzia i budżet dla całej tury. Specyfikacja MCP mówi, że klienci powinni implementować limity czasu dla wywołań narzędzi.
  2. Ponów próbę w przypadku błędów tymczasowych w kodzie. Obsłuż odpowiedzi 429 i 503 w kodzie narzędzia, uwzględnij Retry-After i ogranicz liczbę prób, aby model nie musiał decydować, kiedy ponowić próbę.
  3. Zwracaj niepowodzenia modelowi jako jasne wyniki. Protokół MCP oddziela błędy protokołu, takie jak nieznane narzędzie lub nieprawidłowe argumenty, od błędów wykonywania narzędzi, takich jak błąd interfejsu API. Zgłasza błędy wykonywania w wyniku narzędzia za pomocą znacznika isError: true, dzięki czemu model może zobaczyć, co poszło nie tak. Powiedz, co się nie powiodło i czy próba ponownie ma sens.
  4. Ogranicz liczbę wywołań narzędzi na turę. Po określonej liczbie niepowodzeń zatrzymaj działanie i poinformuj użytkownika.
  5. Przed przekazaniem ich do modelu zweryfikuj wyniki narzędzia. Specyfikacja MCP mówi, że klienci powinni to zrobić i powinni zweryfikować wyniki strukturalne względem schematu danych wyjściowych narzędzia, jeśli taki istnieje.
  6. Poinformuj użytkownika, co nie działa. Odpowiedź oparta na nieudanym wywołaniu narzędzia powinna to jasno zaznaczyć.

Jak przetestować obsługę awarii narzędzia w agencie

Approach Co znajdziesz To, co przegapisz
Przetestuj jednostkowo otokę narzędzia za pomocą zaślepionego klienta Jak Twój kod mapuje opisaną przez Ciebie awarię Co z nim robi model i jak rzeczywiste narzędzie zawodzi
Zepsuj rzeczywiste narzędzie, na przykład zatrzymaj serwer lub unieważnij klucz Prawdziwa awaria tego rodzaju Ograniczenia liczby żądań, wolne odpowiedzi i nieprawidłowo sformatowane dane, których nie można spowodować na żądanie
Napisz fałszywy interfejs API lub serwer MCP Dowolna odpowiedź, którą napiszesz Musisz skierować swojego agenta na fałszywe narzędzie i oddala się on od prawdziwego narzędzia
Przechwytywanie rzeczywistego ruchu narzędzia agenta i wstrzykiwanie awarii Co agent uruchomieniowy i model robią z błędami, opóźnieniami i nieprawidłowymi danymi z rzeczywistego narzędzia Twój kod w izolacji. Zachowaj testy jednostkowe do tego.

Dane wyjściowe modelu mogą się różnić w zależności od przebiegów, dlatego uruchom każdy scenariusz awarii więcej niż raz.

Wypróbuj ją w swojej aplikacji

Dev Proxy znajduje się między agentem a jego narzędziami i symuluje awarie, bez zmian w kodzie agenta.

W przypadku narzędzi wywołujących interfejsy API HTTP połącz losowe błędy, opóźnienia i sprawdź, czy agent czeka tak długo, jak wymaga interfejs API:

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

Zdefiniuj błędy w errors-contoso-api.json, zgodnie z opisem w Testowanie mojej aplikacji z błędami losowymi. Ustaw wartość Retry-After na @dynamic dla odpowiedzi 429. RetryAfterPlugin sprawdza tylko te.

W przypadku serwerów MCP, które używają STDIO, uruchom serwer za pośrednictwem devproxy stdio z konfiguracją, która włącza MockStdioResponsePlugin, jak pokazano w stdio przykładzie konfiguracji. Zapisz go jako devproxyrc-stdio.json. Następnie umieść ten element, stdio-mocks.json aby zwrócić błąd wykonywania narzędzia dla każdego tools/call żądania:

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

Aby agent z niego korzystał, zmień polecenie w konfiguracji serwera MCP agenta, aby uruchamiał serwer przez devproxy stdio. Użyj właściwości nth obiektu mock, aby zakończyć niepowodzeniem tylko określone wywołanie, a następnie dodaj wtyczkę LatencyPlugin, aby spowolnić odpowiedzi serwera.

Aby przetestować działanie agenta, gdy sam model ulegnie awarii, model LanguageModelFailurePlugin sprawia, że model halucynuje, ignoruje instrukcje lub odpowiada w niewłaściwym formacie. Zobacz Testowanie mojej aplikacji pod kątem awarii modelu językowego.

Aby zainstalować Dev Proxy, zobacz Konfigurowanie Dev Proxy.

Następne kroki

Mockowanie odpowiedzi STDIO dla serwerów MCP

Informacje dodatkowe

  • Ostatnia aktualizacja o