Przejdź do treści

Szukaj w dokumentacji

Wpisz, aby przeszukać każdą stronę dokumentacji.

Menu dokumentacji
PrzewodnikOdbiorcy · Programiści, badacze i współtwórcy

Testy i symulacje

Dwa środowiska testowe: testy integracyjne na prawdziwej infrastrukturze i symulacje agentów z LLM w roli sędziego

Ta strona została przetłumaczona automatycznie z języka angielskiego. W razie rozbieżności pierwszeństwo ma oryginał.Przeczytaj oryginał w języku angielskim

Testowanie agentów jest w tym frameworku pełnoprawną funkcją, a nie dodatkiem dokładanym na końcu. Agent-Lab zawiera dwa uzupełniające się środowiska testowe, których możesz używać zarówno do walidacji samego frameworka, jak i agentów budowanych na jego bazie:

  • Testy integracyjne sprawdzają system na prawdziwej infrastrukturze (Postgres, Redis, Keycloak, embeddingi, headless Chrome) uruchamianej na żądanie za pomocą testcontainers — obejmując usługi zewnętrzne, operacje na bazie danych, wyszukiwanie wektorowe i endpointy API.
  • Symulacje agentów oceniają zachowanie agentów od początku do końca z użyciem rzeczywistych LLM; wyniki wystawia LLM w roli sędziego, a są one śledzone w czasie w Langfuse i LangWatch.

Główna konfiguracja testów integracyjnych znajduje się w tests/conftest.py; dostosuj ją do swojego środowiska.

Uwaga: testy integracyjne i symulacje wykonują rzeczywiste wywołania usług zewnętrznych i mogą generować koszty. Uruchamiaj je w kontrolowanym środowisku i monitoruj zużycie.

Testy integracyjne

Wymagany jest Docker (lub inne środowisko uruchomieniowe kontenerów) — zestaw testów tworzy prawdziwe kontenery za pomocą testcontainers.

make test_unit         # fast lane: boots the app with no infrastructure
make test_integration  # the full real-infrastructure suite
make test              # both, with coverage (gate: 90%)

Pierwsze uruchomienie może potrwać kilka minut — obrazy Docker i modele embeddingów są pobierane jednorazowo. Pokrycie agent_lab/ jest egzekwowane w CI (SonarCloud).

Wygenerowane projekty odzwierciedlają ten układ: tests/ zawiera testy dymne bez kontenerów oraz opcjonalny zestaw testcontainers.

Symulacje agentów

Kompleksowe symulacje agentów znajdują się w tests/simulation/ i wywołują rzeczywistych dostawców LLM. Są oznaczone jako agent_test i domyślnie pomijane; uruchom je poleceniem:

make test_simulations
# or a single track:
make scenario_simulation
make langwatch_simulation
make langfuse_simulation

Trzy uzupełniające się ścieżki współdzielą funkcje pomocnicze do inicjalizacji agentów, sędziego oraz definicje zbiorów danych w tests/simulation/datasets/:

  • tests/simulation/scenario/ — symulacje konwersacyjne z użyciem frameworka langwatch-scenario: symulator użytkownika prowadzi agenta, a agent-sędzia ocenia interakcję.
  • tests/simulation/langfuse/ — eksperymenty oparte na zbiorach danych Langfuse. Każde uruchomienie synchronizuje definicje zbiorów danych, wywołuje agenta dla każdego elementu, ocenia wynik za pomocą LLM w roli sędziego po stronie klienta i zapisuje uruchomienie oraz oceny w Langfuse do porównań w czasie. Pomijane automatycznie, gdy nie ustawiono LANGFUSE_BASE_URL (lub przestarzałego LANGFUSE_HOST), LANGFUSE_PUBLIC_KEY i LANGFUSE_SECRET_KEY.
  • tests/simulation/langwatch/ — te same eksperymenty na zbiorach danych odzwierciedlone w LangWatch przez langwatch.experiment, z zapisem oceny sędziego dla każdego elementu. Definicje są idempotentnie synchronizowane do jednego skonsolidowanego zbioru danych simulations (kolumna dataset identyfikuje definicję źródłową, ponieważ darmowy plan LangWatch pozwala na maksymalnie 3 zbiory danych na projekt). Pomijane automatycznie, gdy nie ustawiono LANGWATCH_ENDPOINT i LANGWATCH_API_KEY.

Referencyjni agenci objęci ścieżkami: coordinator-planner-supervisor, react RAG, agent wizji/dokumentów, automatyzacji przeglądarki, notatek głosowych i adaptive RAG.

Konfiguracja LLM sędziego i agentów

Sędzia (oraz symulator użytkownika w scenariuszach) używa identyfikatorów modeli litellm z dowolnym endpointem zgodnym z API OpenAI:

Zmienna środowiskowa Wartość domyślna Przeznaczenie
SIMULATION_JUDGE_MODEL openai/gpt-5-nano identyfikator modelu litellm używanego przez LLM w roli sędziego
SIMULATION_JUDGE_API_BASE domyślna dostawcy niestandardowy endpoint zgodny z OpenAI dla modelu sędziego
SIMULATION_JUDGE_API_KEY domyślna dostawcy klucz API niestandardowego endpointu

Testowani agenci działają na domyślnym LLM serwowanym przez dowolny endpoint zgodny z OpenAI (np. serwer inferencji w sieci LAN), przygotowywanym dla każdego testu przez tests/simulation/common/llm_factory.py. Wyjątkiem jest agent notatek głosowych, który pozostaje przy OpenAI (potrzebuje wejścia audio w czacie). Embeddingi nadal korzystają z rezerwowego EMBEDDINGS_ENDPOINT (testowy kontener Ollama serwujący bge-m3), zgodnie ze zrzutem pgvector. Endpoint musi obsługiwać wywoływanie narzędzi / ustrukturyzowane wyjście w zestawach opartych na nadzorcy (automatyzacja przeglądarki, nadzorca):

Zmienna środowiskowa Wartość domyślna Przeznaczenie
SIMULATION_LLM_MODEL brak (wymagana) tag modelu wykonującego symulacje (np. qwen3:30b)
SIMULATION_LLM_API_BASE brak (wymagana) endpoint zgodny z OpenAI serwujący model
SIMULATION_LLM_API_KEY dummy-key klucz API, jeśli endpoint go wymaga

Konfigurowanie platform ewaluacyjnych

make test_simulations (oraz cele dla poszczególnych ścieżek) najpierw wykonuje krok sync_simulation_evals, który odzwierciedla definicje zbiorów danych na każdej skonfigurowanej platformie. Aby dodatkowo przygotować konfigurację ewaluacji po stronie serwera Langfuse (połączenie LLM dla modelu sędziego, ewaluator simulation_llm_as_judge i jedną regułę ewaluacji na każdy zbiór danych symulacji — widoczne w sekcji Evaluations w Langfuse), uruchom:

uv run python tests/setup_simulation_evals.py

Skrypt jest idempotentny i można go bezpiecznie uruchamiać ponownie.