⚠️ Les simulations sont en bêta privée (pas encore disponibles généralement).

Aucune couverture docs/MCP pour l'instant. Pour la surface de commande lk agent simulate, utilisez lk agent simulate --help et le tableau de bord LiveKit Cloud plutôt que lk docs / MCP jusqu'à ce que les simulations soient documentées.

SDK récent obligatoire. L'exécution de simulations nécessite la branche 1.6 de livekit-agents. Confirmez la version installée plutôt que de l'supposer.

Disponibilité limitée / authentification. La création de runs nécessite que le projet soit activé pour les simulations et une session lk cloud auth valide. (La génération de scénarios — le rôle principal de cette compétence — n'en a besoin d'aucune ; c'est totalement local.)

Génération de scénarios de simulation

La chose la plus précieuse que vous puissiez faire avec les simulations est de générer de bons scénarios de test pour l'agent de l'utilisateur — ancrés dans le code réel de l'agent et dans ce que l'utilisateur veut stress-tester — puis les exécuter. Vous le faites localement : vous lisez le code avec vos outils habituels (rien n'est uploadé), et vous (l'agent de codage) êtes le modèle qui fait la génération, donc aucune clé API ou service supplémentaire n'est nécessaire.

Un scénario = persona + objectifs d'un utilisateur simulé (instructions) et les critères de réussite (agent_expectations). Une simulation joue chaque scénario contre l'agent via texte et un juge LLM le note. Votre travail est de produire un ensemble de scénarios de haute qualité, diversifié et ciblé, et de les écrire dans un fichier de scénarios YAML que la CLI peut exécuter.

Ce qui rend ceci meilleur que l'autopilot

Un naïf « générez juste quelques tests » rate le point. Trois choses rendent cette compétence utile :

Elle lit le code réel de l'agent — donc les scénarios respectent ce que l'agent peut réellement faire et où il bloque (surtout contraintes/éléments indisponibles), au lieu de deviner d'après le nom.
Elle est dirigée par l'utilisateur. L'utilisateur sait ce qui l'inquiète. Capturez toujours cette intention et maintenez-la. C'est le titre — voir references/user-guidance.md.
Elle garantit la couverture de tout risque. Livrée à elle-même, la génération dérive vers des appels plausibles du chemin heureux et ignore silencieusement les cas difficiles — retenir un champ obligatoire, fournir une valeur invalide, une recherche vide, et la surface des garde-fou/abus (hors périmètre, dommageable, conseil professionnel, données sensibles, extraction de prompt). Cette compétence transforme les contraintes de l'agent en une liste de risques explicite et exige au moins un scénario par élément — voir references/analyzing-the-agent.md et references/writing-scenarios.md.

Le flux

Décrivez l'agent + construisez la liste de risques — lisez son code localement et écrivez une description orientée test (Identité / Capacités / Contraintes) vers description.md, et une liste de risques explicite vers risks.yaml (une entrée par contrainte/garde-fou à tester obligatoirement, chacune avec un id et une category). Suivez references/analyzing-the-agent.md. N'uploadez jamais le code.
Obtenez le focus de test de l'utilisateur — s'il n'a pas dit quoi tester, demandez. Appliquez-le selon references/user-guidance.md (ajoutez un # Test Focus à description.md, et orientez la création). Le focus est additif — il approfondit les risques choisis mais ne baisse jamais le plancher de couverture par risque. S'ils n'ont vraiment aucune préférence, générez large et dites-le.
Créez les scénarios — au moins un par risque — écrivez un ensemble diversifié d'environ 10 scénarios ancrés dans description.md et le focus, générant la variété de persona / ambiance / situation à partir de votre propre jugement (cette version ne fournit aucune bibliothèque d'attributs). Garantissez la couverture : chaque élément risks.yaml obtient ≥1 scénario dédié, écrit avec la forme qui l'exerce réellement, et marqué avec covers: [<risk id>, …]. Suivez references/writing-scenarios.md (schéma, les règles « La partie A parle à l'agent », pas d'état antérieur, pas de vrais PII, expectations basées sur les résultats, la taxonomie de forme adversariale, la vérification de couverture, n'écrivez pas de mauvais tests). Écrivez-les dans authored.yaml. Ajoutez ici aussi tous les tests obligatoires épinglés par l'utilisateur.
Assemblez la config (couverture appliquée) — python scripts/build_scenarios.py assemble --in authored.yaml --agent-description-file description.md --risks risks.yaml --strict --out scenarios.yaml (valide le schéma, échoue si un risque n'est pas couvert, et émet le fichier YAML de scénarios que lk agent simulate --scenarios charge). Corrigez les lacunes et réexécutez jusqu'à ce que ça passe.
Exécutez-le — lk agent simulate --scenarios scenarios.yaml (confirmez les flags exactes avec --help ; nécessite le SDK/auth noté dans le bloc bêta). Montrez à l'utilisateur les résultats et proposez de relancer, refocaliser, ou ajouter des scénarios.

Réutilisez les fichiers scenarios.yaml sauvegardés comme suite de régression — réexécutez-les après des changements de prompt/modèle/outil.

Principes

N'uploadez jamais le code de l'utilisateur. Le lire localement est le point ; c'est sa propriété intellectuelle.
L'intention de l'utilisateur est le différenciant — incorporez-la à chaque fois ; ne lancez pas silencieusement l'autopilot.
Ancrez chaque scénario dans la description, surtout Contraintes — un scénario que l'agent ne peut pas positivement satisfaire (ou un garde-fou qu'il devrait refuser) doit avoir des expectations qui le reflètent.
Le script est la colle déterministe ; vous êtes le générateur. Laissez build_scenarios.py gérer l'assemblage + la vérification de couverture ; vous faites la lecture, le jugement, la diversité et la création.

Vérifiez, n'inventez pas (geler à jamais)

Cette compétence est la méthode (aucune bibliothèque groupée — vous fournissez la diversité vous-même). Les flags exactes de lk agent simulate, le flag attente/échec CI, la version minimum du SDK, et le tableau de bord viennent de sources actives car ils changent — utilisez lk agent simulate --help et (post-bêta) lk docs / le serveur MCP LiveKit. Un flag incorrect gaspille une run ; cherchez plutôt que de deviner.

Après l'exécution : agir sur les résultats (secondaire)

Une fois qu'une run est terminée, lisez le succès/échec par scénario, le résumé de la run, et les transcriptions des échecs. Corrigez l'agent où un échec est réel (et réexécutez) ; reconnaissez quand un échec est en fait un mauvais scénario et corrigez le scénario à la place. Gardez ceci léger — les modèles modernes sont déjà bons à l'étape de correction ; la valeur durable de cette compétence est les scénarios que vous générez et conservez.

livekit-simulations