Exécuter des simulations LiveKit

Une simulation joue un scénario contre l'agent réel en utilisant un utilisateur simulé piloté par un LLM, puis un juge note la transcription. Un test unitaire s'exécute sur un tour. Une simulation vous dit si une conversation entière a atteint le bon résultat.

Lisez lk agent simulate --help avant d'exécuter. Les sous-commandes et les drapeaux changent, un mauvais drapeau gaspille une exécution payante, et cette skill ne les réexpose pas. reading-livekit-docs contient le reste.

Quand utiliser une simulation

Utilisez les simulations pour tester la régression du comportement à long horizon avant le déploiement en production : si une conversation multi-tour atteint le bon résultat quand l'appelant revient en arrière, si les détails collectés au début survivent jusqu'à la fin, si l'agent respecte ses instructions sous pression, et s'il s'est terminé dans le bon état. Pour un seul tour, utilisez testing-livekit-agents ; pour explorer le comportement lors de l'édition, utilisez debugging-livekit-agents.

Exécution

Exécutez à partir du répertoire du projet de l'agent. Le mode est un sous-commande :

lk agent simulate text --scenarios scenarios.yaml    # voir --help pour les drapeaux actuels

Sans fichier de scénario, la CLI génère des scénarios à partir de la source de l'agent. Cela charge le code, et la CLI demande une confirmation d'abord. La génération relève de writing-livekit-scenarios.

Par défaut, la CLI démarre l'agent comme un worker local, envoie les scénarios, et l'arrête quand l'exécution se termine. Une option vous permet de noter un agent déjà en cours d'exécution par nom à la place. Cela nécessite un fichier de scénario, puisqu'il n'y a pas de source locale à générer.

La concurrence est limitée par exécution et par projet. La documentation contient les limites actuelles.

Texte ou audio

Le texte est le défaut, et c'est le bon choix. L'utilisateur simulé échange du texte avec l'agent, ainsi l'exécution exerce le LLM, les outils et la logique de conversation tandis que le framework désactive la STT, la TTS et la VAD. C'est plus rapide, moins cher et plus déterministe. Utilisez-le pour l'itération et pour tout ce qui est automatisé.

Les exécutions audio lancent les mêmes scénarios dans le pipeline de parole complète. L'utilisateur simulé parle, écoute et interrompt comme le ferait un appelant, et l'exécution note ce que seule la parole expose :

• Alternance de parole : commencer à parler avant que l'appelant ait terminé, ou laisser un appelant qui a terminé attendre.
• Gestion des interruptions : céder à une irruption et distinguer un bref accusé de réception d'un nouveau tour.
• Précision de la transcription dans les deux sens, notée séparément pour ce qui compte : noms, numéros, adresses, codes de confirmation.
• Latence perçue : ce que l'appelant a entendu, qui diffère de ce que l'agent rapporte sur lui-même. L'écart entre les deux est ce que l'utilisateur vit.

Les exécutions audio s'exécutent en temps réel, appellent les fournisseurs STT et TTS à chaque tour, et sont mesurées à un taux plus élevé. Réservez-les pour un candidat à la version ou une modification qui touche la parole, l'alternance de parole ou l'interruption. Ne les mettez pas dans une tâche récurrente.

La sous-commande audio a des options pour dégrader l'audio de l'appelant simulé (bruit, mauvais micro, perte de paquets). Utilisez-les pour tester ce que l'agent fait avec la parole qu'il ne peut pas entendre clairement. Il devrait demander une répétition au lieu de deviner. Combinez-les pour un appelant dans le pire cas.

Automatiser une exécution de pré-version

Tout ce dont vous avez besoin est un fichier de scénario commité et une tâche planifiée ou une branche de version. La CLI affiche une sortie simple quand elle n'est pas attachée à un terminal et quitte avec un code non nul quand tout scénario échoue, donc la tâche échoue sans câblage supplémentaire ; la documentation a un exemple CI fonctionnel pour commencer. Gardez les exécutions automatisées en mode texte. Chaque scénario du fichier commité doit passer ou la tâche échoue, donc gardez les scénarios aspirationnels que l'agent ne réussit pas encore dans un fichier séparé que vous exécutez à la demande.

Lire les résultats

Une exécution affiche un verdict par scénario et un lien de tableau de bord. Le verdict vous dit ce qui s'est passé ; la transcription vous dit pourquoi, travaillez donc à partir de la transcription. Le lien du tableau de bord est pour le lecteur. Votre chemin est export : il affiche une exécution terminée, avec le contexte de chat complet de chaque scénario, en JSON — lisez une transcription échouée de là, comparez deux exécutions, ou archivez une exécution comme artefact de build. list trouve l'id d'exécution et a aussi une sortie lisible par machine ; --help nomme les drapeaux.

Pour trier un échec, décidez duquel il s'agit :

1. Un bug dans l'agent. Corrigez l'agent et réexécutez. Vérifiez d'abord les instructions et les descriptions des outils. Un échec qui ressemble à un mauvais raisonnement est souvent un outil dont la description ne dit jamais quand l'utiliser.
2. Un mauvais scénario. L'attente exige quelque chose que l'agent ne devrait pas faire, ou c'est trop vague pour qu'un juge décide de manière cohérente. Corrigez le scénario. Un agent_expectations vague est la raison la plus courante d'une inversion de verdict entre les exécutions.
3. Une lacune dans le monde simulé. Le scénario passe mais la production a échoué, ou l'inverse. Généralement l'agent a atteint des données différentes, les instructions dérivées omettent le tour qui a causé le problème, ou l'échec ne se produit qu'en audio et une exécution texte ne peut pas le voir.

Après une correction, exécutez le fichier entier, pas seulement le scénario sur lequel vous travailliez. Une correction pour une conversation change souvent une voisine.

Descendre les échecs répétés dans la pile. Un scénario qui échoue de la même manière à chaque fois décrit un bug au niveau du tour. Un test unitaire l'épingle plus économiquement et l'attrape plus tôt. Voir testing-livekit-agents.

Skills connexes

• Rédaction et organisation des scénarios : writing-livekit-scenarios
• Débogage interactif d'un échec : debugging-livekit-agents
• Couverture moins chère par commit : testing-livekit-agents
• Déploiement de l'agent que l'exécution note : operating-livekit-agents
• Drapeaux, versions, changelogs : reading-livekit-docs