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_simulationTrzy 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 ustawionoLANGFUSE_BASE_URL(lub przestarzałegoLANGFUSE_HOST),LANGFUSE_PUBLIC_KEYiLANGFUSE_SECRET_KEY.tests/simulation/langwatch/— te same eksperymenty na zbiorach danych odzwierciedlone w LangWatch przezlangwatch.experiment, z zapisem oceny sędziego dla każdego elementu. Definicje są idempotentnie synchronizowane do jednego skonsolidowanego zbioru danychsimulations(kolumnadatasetidentyfikuje definicję źródłową, ponieważ darmowy plan LangWatch pozwala na maksymalnie 3 zbiory danych na projekt). Pomijane automatycznie, gdy nie ustawionoLANGWATCH_ENDPOINTiLANGWATCH_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.pySkrypt jest idempotentny i można go bezpiecznie uruchamiać ponownie.