Tests et simulations

Le test des agents est une capacité à part entière du framework, et non une réflexion après coup. Agent-Lab fournit deux bancs d'essai complémentaires que vous pouvez utiliser aussi bien pour valider le framework lui-même que pour valider les agents que vous construisez par-dessus :

• Les tests d'intégration éprouvent le système sur une infrastructure réelle (Postgres, Redis, Keycloak, embeddings, Chrome headless) démarrée à la demande avec testcontainers — en couvrant les services externes, les opérations de base de données, la recherche vectorielle et les points de terminaison de l'API.
• Les simulations d'agents évaluent le comportement des agents de bout en bout face à des LLM réels, notés par un LLM-as-judge et suivis dans le temps dans Langfuse et LangWatch.

La configuration principale des tests d'intégration se trouve dans tests/conftest.py ; adaptez-la à votre environnement.

Remarque : les tests d'intégration et les simulations effectuent de véritables appels à des services externes et peuvent engendrer des coûts. Exécutez-les dans un environnement maîtrisé et surveillez la consommation.

Tests d'intégration

Nécessite Docker (ou un autre runtime de conteneurs) — la suite provisionne de vrais conteneurs via 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%)

La première exécution peut prendre plusieurs minutes — les images Docker et les modèles d'embeddings sont téléchargés une seule fois. La couverture de agent_lab/ est imposée dans la CI (SonarCloud).

Les projets générés reprennent ce fonctionnement : tests/ contient des smoke tests sans conteneur ainsi qu'une suite testcontainers facultative.

Simulations d'agents

Les simulations d'agents de bout en bout se trouvent dans tests/simulation/ et appellent de véritables fournisseurs de LLM. Elles sont marquées agent_test et désélectionnées par défaut ; exécutez-les avec :

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

Trois volets complémentaires partagent les helpers d'initialisation des agents, le juge et les définitions de jeux de données situées sous tests/simulation/datasets/ :

• tests/simulation/scenario/ — simulations conversationnelles reposant sur le framework langwatch-scenario : un simulateur d'utilisateur pilote l'agent tandis qu'un agent juge note l'interaction.
• tests/simulation/langfuse/ — expériences pilotées par des jeux de données reposant sur les datasets Langfuse. Chaque exécution synchronise les définitions de jeux de données, invoque l'agent pour chaque élément, note la sortie avec un LLM-as-judge côté client et enregistre l'exécution et les scores dans Langfuse afin de les comparer dans le temps. Ce volet est ignoré automatiquement lorsque LANGFUSE_BASE_URL (ou la variable obsolète LANGFUSE_HOST), LANGFUSE_PUBLIC_KEY et LANGFUSE_SECRET_KEY ne sont pas définis.
• tests/simulation/langwatch/ — les mêmes expériences sur jeux de données, répliquées vers LangWatch via langwatch.experiment, en consignant le score du juge pour chaque élément. Les définitions sont synchronisées de manière idempotente dans un unique jeu de données consolidé simulations (une colonne dataset identifie la définition d'origine, car l'offre gratuite de LangWatch autorise au plus 3 jeux de données par projet). Ce volet est ignoré automatiquement lorsque LANGWATCH_ENDPOINT et LANGWATCH_API_KEY ne sont pas définis.

Les agents de référence couverts par ces volets : les agents coordinator-planner-supervisor, ReAct RAG, vision/document, automatisation de navigateur, mémos vocaux et RAG adaptatif.

Configuration des LLM du juge et des agents

Le juge (ainsi que le simulateur d'utilisateur des scénarios) utilise des identifiants de modèles litellm sur n'importe quel point de terminaison compatible avec l'API OpenAI :

Les agents testés s'exécutent sur un LLM par défaut servi par n'importe quel point de terminaison compatible OpenAI (par exemple un serveur d'inférence sur le réseau local), provisionné pour chaque test par tests/simulation/common/llm_factory.py. L'exception est l'agent de mémos vocaux, qui reste sur OpenAI (il nécessite une entrée de chat audio). Les embeddings continuent d'utiliser le repli EMBEDDINGS_ENDPOINT (le conteneur Ollama de test qui sert bge-m3), en cohérence avec le dump pgvector. Le point de terminaison doit prendre en charge l'appel d'outils et la sortie structurée pour les suites reposant sur un superviseur (automatisation de navigateur, superviseur) :

Mettre en place les plateformes d'évaluation

make test_simulations (ainsi que les cibles propres à chaque volet) exécute d'abord l'étape sync_simulation_evals, qui réplique les définitions de jeux de données vers chaque plateforme configurée. Pour provisionner également la configuration d'évaluation côté serveur de Langfuse (une connexion LLM pour le modèle du juge, un évaluateur simulation_llm_as_judge et une règle d'évaluation par jeu de données de simulation — visibles dans la section Evaluations de Langfuse), exécutez :

uv run python tests/setup_simulation_evals.py

Le script est idempotent et peut être réexécuté sans risque.