--- read_when: - Exécution des tests de fumée en conditions réelles pour la matrice de modèles, le backend CLI, ACP et le fournisseur de médias - Débogage de la résolution des identifiants pour les tests en conditions réelles - Ajout d’un nouveau test en conditions réelles spécifique à un fournisseur sidebarTitle: Live tests summary: 'Tests en conditions réelles (avec accès au réseau) : matrice de modèles, backends CLI, ACP, fournisseurs de médias, identifiants d’authentification' title: 'Tests : suites en conditions réelles' x-i18n: generated_at: "2026-07-12T02:42:29Z" model: gpt-5.6 postprocess_version: locale-links-v1 provider: openai source_hash: 539fc547425f66049fc4df2af29206c281b47ecb75908936977d93020ae19890 source_path: help/testing-live.md workflow: 16 --- Pour le démarrage rapide, les exécuteurs d’assurance qualité, les suites de tests unitaires et d’intégration ainsi que les flux Docker, consultez [Tests](/fr/help/testing). Cette page traite des tests **en conditions réelles** (avec accès réseau) : matrice de modèles, backends CLI, ACP, fournisseurs multimédias et gestion des identifiants. ## En conditions réelles : commandes de vérification rapide locale Exportez la clé du fournisseur requise dans l’environnement du processus avant d’effectuer des vérifications ponctuelles en conditions réelles. Vérification multimédia sûre : ```bash pnpm openclaw infer tts convert --local --json \ --text "OpenClaw live smoke." \ --output /tmp/openclaw-live-smoke.mp3 ``` Vérification sûre de la disponibilité des appels vocaux : ```bash pnpm openclaw voicecall setup --json pnpm openclaw voicecall smoke --to "+15555550123" ``` `voicecall smoke` effectue une simulation, sauf si `--yes` est également présent ; utilisez `--yes` uniquement si vous avez l’intention de passer un véritable appel. Pour Twilio, Telnyx et Plivo, une vérification de disponibilité réussie nécessite une URL de webhook publique ; les URL local loopback ou privées sont rejetées, car ces fournisseurs ne peuvent pas les atteindre. ## En conditions réelles : analyse des capacités d’un Node Android - Test : `src/gateway/android-node.capabilities.live.test.ts` - Script : `pnpm android:test:integration` - Objectif : invoquer **chaque commande actuellement annoncée** par un Node Android connecté et vérifier le comportement contractuel des commandes. - Périmètre : - Configuration manuelle préalable (la suite n’installe, n’exécute ni n’appaire l’application). - Validation, commande par commande, de `node.invoke` du Gateway pour le Node Android sélectionné. - Configuration préalable requise : - Application Android déjà connectée et appairée au Gateway. - Application maintenue au premier plan. - Autorisations et consentement à la capture accordés pour les capacités dont vous attendez la réussite. - Remplacements facultatifs de la cible : - `OPENCLAW_ANDROID_NODE_ID` ou `OPENCLAW_ANDROID_NODE_NAME`. - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`. - Détails complets de la configuration Android : [Application Android](/fr/platforms/android) ## En conditions réelles : vérification rapide des modèles (clés de profil) Les tests de modèles en conditions réelles sont répartis en deux couches afin d’isoler les échecs : - « Modèle direct » indique si le fournisseur ou le modèle peut répondre avec la clé donnée. - « Vérification rapide du Gateway » indique si l’ensemble du pipeline Gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique de bac à sable, etc.). Les listes de modèles sélectionnés ci-dessous se trouvent dans `src/agents/live-model-filter.ts` et évoluent au fil du temps ; considérez les tableaux de ce fichier comme la source de vérité, et non cette page. MiniMax M3 utilise `minimax/MiniMax-M3` comme référence fournisseur/modèle par défaut. ### Couche 1 : exécution directe du modèle (sans Gateway) - Test : `src/agents/models.profiles.live.test.ts` - Objectif : - Énumérer les modèles détectés - Utiliser `getApiKeyForModel` pour sélectionner les modèles pour lesquels vous disposez d’identifiants - Exécuter une courte génération pour chaque modèle (ainsi que des tests de régression ciblés si nécessaire) - Activation : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) - Définissez `OPENCLAW_LIVE_MODELS=modern`, `small` ou `all` (alias de `modern`) pour réellement exécuter cette suite ; sinon elle est ignorée, afin que `pnpm test:live` seul reste centré sur la vérification rapide du Gateway. - Sélection des modèles : - `OPENCLAW_LIVE_MODELS=modern` exécute la liste de priorité sélectionnée à fort pouvoir diagnostique (voir [En conditions réelles : matrice de modèles](#live-model-matrix-what-we-cover)) - `OPENCLAW_LIVE_MODELS=small` exécute la liste de priorité sélectionnée des petits modèles - `OPENCLAW_LIVE_MODELS=all` est un alias de `modern` - ou `OPENCLAW_LIVE_MODELS="openai/gpt-5.6-luna,anthropic/claude-opus-4-6,..."` (liste d’autorisation séparée par des virgules) - Les exécutions locales des petits modèles Ollama utilisent par défaut `http://127.0.0.1:11434` ; définissez `OPENCLAW_LIVE_OLLAMA_BASE_URL` uniquement pour les points de terminaison du réseau local, personnalisés ou Ollama Cloud. - Les analyses modern/all et small utilisent par défaut la longueur de leur liste sélectionnée comme limite ; définissez `OPENCLAW_LIVE_MAX_MODELS=0` pour une analyse exhaustive du profil sélectionné ou un nombre positif pour une limite inférieure. - Les analyses exhaustives utilisent `OPENCLAW_LIVE_TEST_TIMEOUT_MS` comme délai d’expiration pour l’ensemble du test direct des modèles. Valeur par défaut : 60 minutes. - Les sondes directes des modèles s’exécutent avec un parallélisme de 20 par défaut ; définissez `OPENCLAW_LIVE_MODEL_CONCURRENCY` pour le remplacer. - Sélection des fournisseurs : - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (liste d’autorisation séparée par des virgules) - Provenance des clés : - Par défaut : magasin de profils et solutions de repli issues de l’environnement - Définissez `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’utilisation du **magasin de profils** uniquement - Raison d’être : - Distingue « l’API du fournisseur est défaillante / la clé n’est pas valide » de « le pipeline d’agent du Gateway est défaillant » - Contient de petits tests de régression isolés (exemple : relecture du raisonnement OpenAI Responses/Codex Responses et flux d’appels d’outils) ### Couche 2 : vérification rapide du Gateway et de l’agent de développement (ce que fait réellement « @openclaw ») - Test : `src/gateway/gateway-models.profiles.live.test.ts` - Objectif : - Démarrer un Gateway dans le processus - Créer ou modifier une session `agent:dev:*` (remplacement du modèle à chaque exécution) - Parcourir les modèles disposant de clés et vérifier : - une réponse « pertinente » (sans outils) - qu’une véritable invocation d’outil fonctionne (sonde de lecture) - des sondes d’outils supplémentaires facultatives (sonde d’exécution et de lecture) - que les chemins de régression OpenAI (appel d’outil uniquement, puis suivi) continuent de fonctionner - Détails des sondes (pour expliquer rapidement les échecs) : - Sonde `read` : le test écrit un fichier contenant une valeur unique dans l’espace de travail et demande à l’agent de le `read`, puis de renvoyer cette valeur. - Sonde `exec+read` : le test demande à l’agent d’utiliser `exec` pour écrire une valeur unique dans un fichier temporaire, puis de la `read`. - Sonde d’image : le test joint un fichier PNG généré (chat + code aléatoire) et attend que le modèle renvoie `cat `. - Référence de l’implémentation : `src/gateway/gateway-models.profiles.live.test.ts` et `test/helpers/live-image-probe.ts`. - Activation : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) - Sélection des modèles : - Par défaut : la liste de priorité sélectionnée à fort pouvoir diagnostique (`modern`) - `OPENCLAW_LIVE_GATEWAY_MODELS=small` exécute la liste sélectionnée des petits modèles dans l’ensemble du pipeline Gateway+agent - `OPENCLAW_LIVE_GATEWAY_MODELS=all` est un alias de `modern` - Vous pouvez aussi définir `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (ou une liste séparée par des virgules) pour restreindre la sélection - Les analyses modern/all et small du Gateway utilisent par défaut la longueur de leur liste sélectionnée comme limite ; définissez `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` pour une analyse exhaustive de la sélection ou un nombre positif pour une limite inférieure. - Sélection des fournisseurs (pour éviter « tout via OpenRouter ») : - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (liste d’autorisation séparée par des virgules) - Les sondes d’outils et d’images sont toujours activées dans ce test en conditions réelles : - Sonde `read` et sonde `exec+read` (mise à l’épreuve des outils) - La sonde d’image s’exécute lorsque le modèle annonce la prise en charge des images en entrée - Flux (vue d’ensemble) : - Le test génère un petit fichier PNG contenant « CAT » et un code aléatoire (`test/helpers/live-image-probe.ts`) - Il l’envoie via `agent` avec `attachments: [{ mimeType: "image/png", content: "" }]` - Le Gateway analyse les pièces jointes dans `images[]` (`src/gateway/server-methods/agent.ts` et `src/gateway/chat-attachments.ts`) - L’agent intégré transmet au modèle un message utilisateur multimodal - Vérification : la réponse contient `cat` et le code (tolérance de la reconnaissance optique de caractères : les erreurs mineures sont autorisées) Pour voir ce que vous pouvez tester sur votre machine (ainsi que les identifiants `provider/model` exacts), exécutez : ```bash openclaw models list openclaw models list --json ``` ## En conditions réelles : vérification rapide d’un backend CLI (Claude, Gemini ou autres CLI locales) - Test : `src/gateway/gateway-cli-backend.live.test.ts` - Objectif : valider le pipeline Gateway+agent au moyen d’un backend CLI local, sans modifier votre configuration par défaut. - Les valeurs par défaut de vérification propres à chaque backend se trouvent dans la définition `cli-backend.ts` du Plugin propriétaire. - Activation : - `pnpm test:live` (ou `OPENCLAW_LIVE_TEST=1` si vous invoquez Vitest directement) - `OPENCLAW_LIVE_CLI_BACKEND=1` - Valeurs par défaut : - Fournisseur/modèle par défaut : `claude-cli/claude-sonnet-4-6` - Le comportement des commandes, arguments et images provient des métadonnées du Plugin de backend CLI propriétaire. - Remplacements (facultatifs) : - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6"` - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/claude"` - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["-p","--output-format","json"]'` - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` pour envoyer une véritable pièce jointe d’image (les chemins sont injectés dans l’invite). Désactivé par défaut dans les recettes Docker. - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` pour transmettre les chemins des fichiers d’images en tant qu’arguments CLI plutôt que de les injecter dans l’invite. - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (ou `"list"`) pour contrôler la manière dont les arguments d’images sont transmis lorsque `IMAGE_ARG` est défini. - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` pour envoyer un second tour et valider le flux de reprise. - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1` pour activer la sonde de continuité de session Claude Sonnet -> Opus lorsque le modèle sélectionné prend en charge une cible de changement. Désactivé par défaut, y compris dans les recettes Docker. - `OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1` pour activer la sonde de boucle d’outils MCP. Désactivé par défaut dans les recettes Docker. Exemple : ```bash OPENCLAW_LIVE_CLI_BACKEND=1 \ OPENCLAW_LIVE_CLI_BACKEND_MODEL="claude-cli/claude-sonnet-4-6" \ pnpm test:live src/gateway/gateway-cli-backend.live.test.ts ``` Vérification rapide et peu coûteuse de la configuration MCP de Gemini : ```bash OPENCLAW_LIVE_TEST=1 \ pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts ``` Cette opération ne demande pas à Gemini de générer une réponse. Elle écrit les mêmes paramètres système qu’OpenClaw fournit à Gemini, puis exécute `gemini --debug mcp list` pour prouver qu’un serveur enregistré avec `transport: "streamable-http"` est normalisé dans le format MCP HTTP de Gemini et peut se connecter à un serveur MCP HTTP diffusé local. Recette Docker : ```bash pnpm test:docker:live-cli-backend ``` Recettes Docker pour un seul fournisseur : ```bash pnpm test:docker:live-cli-backend:claude pnpm test:docker:live-cli-backend:claude-subscription pnpm test:docker:live-cli-backend:gemini ``` Remarques : - L’exécuteur Docker se trouve dans `scripts/test-live-cli-backend-docker.sh`. - Il exécute la vérification en conditions réelles du backend CLI dans l’image Docker du dépôt en tant qu’utilisateur `node` non privilégié. - Il résout les métadonnées de vérification CLI à partir du Plugin propriétaire, puis installe le paquet CLI Linux correspondant (`@anthropic-ai/claude-code` ou `@google/gemini-cli`) dans un préfixe accessible en écriture et mis en cache à l’emplacement `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (par défaut : `~/.cache/openclaw/docker-cli-tools`). - `codex-cli` n’est plus un backend CLI intégré ; utilisez plutôt `openai/*` avec l’environnement d’exécution du serveur d’application Codex (voir [En conditions réelles : vérification rapide du banc d’essai du serveur d’application Codex](#live-codex-app-server-harness-smoke)). - `pnpm test:docker:live-cli-backend:claude-subscription` nécessite l’OAuth portable de l’abonnement Claude Code, soit via `~/.claude/.credentials.json` avec `claudeAiOauth.subscriptionType`, soit via `CLAUDE_CODE_OAUTH_TOKEN` obtenu avec `claude setup-token`. Il vérifie d’abord directement `claude -p` dans Docker, puis exécute deux tours du backend CLI du Gateway sans conserver les variables d’environnement des clés d’API Anthropic. Ce parcours d’abonnement désactive par défaut les sondes MCP/outils et d’images de Claude, car il consomme les limites d’utilisation de l’abonnement connecté et Anthropic peut modifier le comportement de facturation et de limitation du débit du SDK Claude Agent ou de `claude -p` sans nouvelle version d’OpenClaw. - Claude et Gemini prennent en charge le même ensemble de sondes (tour de texte, classification d’image, appel de l’outil MCP `cron`, continuité lors du changement de modèle) au moyen des indicateurs ci-dessus, mais aucune de ces sondes ne s’exécute par défaut ; activez-les individuellement selon les besoins. ## En conditions réelles : accessibilité du proxy HTTP/2 APNs - Test : `src/infra/push-apns-http2.live.test.ts` - Objectif : établir un tunnel via un proxy HTTP CONNECT local vers le point de terminaison APNs de bac à sable d’Apple, envoyer la requête de validation HTTP/2 APNs et vérifier que la véritable réponse `403 InvalidProviderToken` d’Apple revient par le chemin du proxy. - Activation : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts` - Délai d’expiration facultatif : - `OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000` ## En conditions réelles : vérification rapide de la liaison ACP (`/acp spawn ... --bind here`) - Test : `src/gateway/gateway-acp-bind.live.test.ts` - Objectif : valider le flux réel de liaison de conversation ACP avec un agent ACP actif : - envoyer `/acp spawn --bind here` - lier sur place une conversation synthétique de canal de messagerie - envoyer un suivi normal dans cette même conversation - vérifier que le suivi arrive dans la transcription de la session ACP liée - Activation : - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Valeurs par défaut : - Agents ACP dans Docker : `claude,codex,gemini` - Agent ACP pour l’exécution directe de `pnpm test:live ...` : `claude` - Canal synthétique : contexte de conversation de type message privé Slack - Backend ACP : `acpx` - Surcharges : - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude` - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex` - `OPENCLAW_LIVE_ACP_BIND_AGENT=droid` - `OPENCLAW_LIVE_ACP_BIND_AGENT=gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT=opencode` - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini` - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@'` - `OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.6-luna` - `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL=opencode/kimi-k2.6` - `OPENCLAW_LIVE_ACP_BIND_IMAGE_PROBE=1` (ou `on`/`true`/`yes`) pour forcer l’activation de la sonde d’image ; toute autre valeur force sa désactivation. Elle s’exécute par défaut pour chaque agent sauf `opencode`. - `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` - `OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.6-luna` - Remarques : - Cette voie utilise la surface `chat.send` du Gateway avec des champs synthétiques de route d’origine réservés aux administrateurs, afin que les tests puissent joindre le contexte du canal de messagerie sans simuler une livraison externe. - Lorsque `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` n’est pas défini, le test utilise le registre d’agents intégré du Plugin `acpx` embarqué pour l’agent de banc d’essai ACP sélectionné. - La création Cron MCP de la session liée s’effectue au mieux par défaut, car les bancs d’essai ACP externes peuvent annuler les appels MCP après la réussite de la preuve de liaison/d’image ; définissez `OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1` pour rendre stricte cette sonde Cron postérieure à la liaison. Exemple : ```bash OPENCLAW_LIVE_ACP_BIND=1 \ OPENCLAW_LIVE_ACP_BIND_AGENT=claude \ pnpm test:live src/gateway/gateway-acp-bind.live.test.ts ``` Recette Docker : ```bash pnpm test:docker:live-acp-bind ``` Recettes Docker pour un seul agent : ```bash pnpm test:docker:live-acp-bind:claude pnpm test:docker:live-acp-bind:codex pnpm test:docker:live-acp-bind:droid pnpm test:docker:live-acp-bind:gemini pnpm test:docker:live-acp-bind:opencode ``` Remarques sur Docker : - Le programme d’exécution Docker se trouve dans `scripts/test-live-acp-bind-docker.sh`. - Par défaut, il exécute successivement le test de fumée de liaison ACP avec les agents CLI actifs regroupés : `claude`, `codex`, puis `gemini`. - Utilisez `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=droid`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini` ou `OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode` pour restreindre la matrice. - Il place le matériel d’authentification CLI correspondant dans le conteneur, puis installe la CLI active demandée (`@anthropic-ai/claude-code`, `@openai/codex`, Factory Droid via `https://app.factory.ai/cli`, `@google/gemini-cli` ou `opencode-ai`) si elle est absente. Le backend ACP lui-même est le paquet `acpx/runtime` embarqué du Plugin `acpx` officiel. - La variante Docker de Droid place `~/.factory` pour les paramètres, transmet `FACTORY_API_KEY` et exige cette clé d’API, car l’authentification OAuth/trousseau locale de Factory n’est pas transférable dans le conteneur. Elle utilise l’entrée de registre intégrée `droid exec --output-format acp` d’ACPX. - La variante Docker d’OpenCode est une voie stricte de régression pour un seul agent. Elle écrit dans `OPENCODE_CONFIG_CONTENT` un modèle par défaut temporaire provenant de `OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL` (valeur par défaut : `opencode/kimi-k2.6`). - Les appels directs à la CLI `acpx` constituent uniquement une procédure manuelle/de contournement pour comparer le comportement hors du Gateway. Le test de fumée Docker de liaison ACP exerce le backend d’exécution `acpx` embarqué d’OpenClaw. ## Test de fumée actif : banc d’essai du serveur d’application Codex - Objectif : valider le banc d’essai Codex appartenant au Plugin via la méthode normale `agent` du Gateway : - charger le Plugin `codex` fourni - sélectionner un modèle OpenAI via `/model --runtime codex` - envoyer un premier tour d’agent au Gateway avec le niveau de réflexion demandé - envoyer un second tour à la même session OpenClaw et vérifier que le fil du serveur d’application peut reprendre - exécuter `/codex status` et `/codex models` via le même chemin de commande du Gateway - exécuter éventuellement deux sondes shell avec élévation examinées par Guardian : une commande inoffensive qui doit être approuvée et un faux téléversement de secret qui doit être refusé afin que l’agent redemande une confirmation - Test : `src/gateway/gateway-codex-harness.live.test.ts` - Activation : `OPENCLAW_LIVE_CODEX_HARNESS=1` - Modèle de référence du banc d’essai : `openai/gpt-5.6-luna` - Sélection par défaut avec une nouvelle clé d’API OpenAI : `openai/gpt-5.6` - Réflexion par défaut : `low` - Surcharge du modèle : `OPENCLAW_LIVE_CODEX_HARNESS_MODEL=openai/` - Surcharge de la réflexion : `OPENCLAW_LIVE_CODEX_HARNESS_THINKING=` - Surcharge de la matrice : `OPENCLAW_LIVE_CODEX_HARNESS_TARGETS==,...` - Mode d’authentification : `OPENCLAW_LIVE_CODEX_HARNESS_AUTH=codex-auth` (valeur par défaut) utilise la connexion Codex copiée ; `api-key` utilise `OPENAI_API_KEY` via le serveur d’application Codex. - Sonde d’image facultative : `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` - Sonde MCP/d’outil facultative : `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1` - Sonde Guardian facultative : `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1` - Le test de fumée impose `agentRuntime.id: "codex"` au fournisseur/modèle afin qu’un banc d’essai Codex défectueux ne puisse pas réussir en revenant silencieusement à OpenClaw. - Authentification : authentification du serveur d’application Codex provenant de la connexion locale à l’abonnement Codex, ou `OPENAI_API_KEY` lorsque `OPENCLAW_LIVE_CODEX_HARNESS_AUTH=api-key`. Docker peut copier `~/.codex/auth.json` et `~/.codex/config.toml` pour les exécutions avec abonnement. Recette locale : ```bash OPENCLAW_LIVE_CODEX_HARNESS=1 \ OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1 \ OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1 \ OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1 \ OPENCLAW_LIVE_CODEX_HARNESS_MODEL=openai/gpt-5.6-luna \ pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts ``` Recette Docker : ```bash pnpm test:docker:live-codex-harness ``` Matrice Codex native GPT-5.6 : ```bash OPENCLAW_LIVE_CODEX_HARNESS_AUTH=api-key \ OPENCLAW_LIVE_CODEX_HARNESS_TARGETS='openai/gpt-5.6-sol=ultra,openai/gpt-5.6-terra=ultra,openai/gpt-5.6-luna=max' \ pnpm test:docker:live-codex-harness ``` Valeur par défaut avec une nouvelle clé d’API OpenAI : ```bash OPENCLAW_LIVE_GATEWAY_OPENAI_API_DEFAULT=1 \ OPENCLAW_LIVE_GATEWAY_PROVIDERS=openai \ OPENCLAW_LIVE_GATEWAY_THINKING=off \ pnpm test:live -- src/gateway/gateway-models.profiles.live.test.ts ``` Cette preuve laisse `OPENCLAW_LIVE_GATEWAY_MODELS` non défini, résout le modèle via le point d’intégration de sélection d’inférence du nouvel assistant de configuration, vérifie `openai/gpt-5.6`, puis exécute un véritable tour du Gateway avec ce modèle résolu. Matrice OpenClaw embarquée GPT-5.6 : ```bash OPENCLAW_LIVE_GATEWAY_THINKING=ultra \ OPENCLAW_LIVE_GATEWAY_PROVIDERS=openai \ OPENCLAW_LIVE_GATEWAY_MODELS='openai/gpt-5.6-sol,openai/gpt-5.6-terra,openai/gpt-5.6-luna' \ pnpm test:live -- src/gateway/gateway-models.profiles.live.test.ts ``` Remarques sur Docker : - Le programme d’exécution Docker se trouve dans `scripts/test-live-codex-harness-docker.sh`. - Il transmet `OPENAI_API_KEY`, copie les fichiers d’authentification de la CLI Codex lorsqu’ils sont présents, installe `@openai/codex` dans un préfixe npm monté accessible en écriture, place l’arborescence des sources, puis exécute uniquement le test actif du banc d’essai Codex. - Docker active par défaut les sondes d’image, MCP/d’outil et Guardian. Définissez `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0`, ou `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0`, ou `OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0` lorsqu’une exécution de débogage plus restreinte est nécessaire. - Docker utilise la même configuration explicite d’exécution Codex ; ainsi, les anciens alias ou le repli vers OpenClaw ne peuvent pas masquer une régression du banc d’essai Codex. - Les cibles de la matrice s’exécutent successivement dans un même conteneur. Le script Docker adapte son délai d’expiration par défaut de 35 minutes au nombre de cibles ; tout délai d’expiration externe du shell ou de la CI doit autoriser la même durée totale. La CI canonique conserve chaque cible GPT-5.6 dans une partition distincte. ### Recettes actives recommandées Les listes d’autorisation restreintes et explicites sont les plus rapides et les moins sujettes aux instabilités : - Modèle unique, en direct (sans Gateway) : - `OPENCLAW_LIVE_MODELS="openai/gpt-5.6-luna" pnpm test:live src/agents/models.profiles.live.test.ts` - Profil direct de petits modèles : - `OPENCLAW_LIVE_MODELS=small pnpm test:live src/agents/models.profiles.live.test.ts` - Profil Gateway de petits modèles : - `OPENCLAW_LIVE_GATEWAY_MODELS=small pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Test de fumée de l’API Ollama Cloud : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_OLLAMA=1 OPENCLAW_LIVE_OLLAMA_BASE_URL=https://ollama.com OPENCLAW_LIVE_OLLAMA_MODEL=glm-5.1:cloud OPENCLAW_LIVE_OLLAMA_WEB_SEARCH=0 pnpm test:live -- extensions/ollama/ollama.live.test.ts` - Modèle unique, test de fumée du Gateway : - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.6-luna" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Appels d’outils avec plusieurs fournisseurs : - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.6-luna,anthropic/claude-opus-4-6,google/gemini-3.5-flash,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Test de fumée direct de Z.AI Coding Plan GLM-5.2 : - `ZAI_CODING_LIVE_TEST=1 pnpm test:live src/agents/zai.live.test.ts` - Ciblage de Google (clé d’API Gemini + Antigravity) : - Gemini (clé d’API) : `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3.5-flash" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Antigravity (OAuth) : `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts` - Test de fumée de la réflexion adaptative de Google (`qa manual` depuis la CLI privée d’assurance qualité — nécessite `OPENCLAW_ENABLE_PRIVATE_QA_CLI=1` et une extraction des sources ; consultez la [présentation de l’assurance qualité](/fr/concepts/qa-e2e-automation)) : - Valeur dynamique par défaut de Gemini 3 : `OPENCLAW_ENABLE_PRIVATE_QA_CLI=1 pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-3.1-pro-preview --alt-model google/gemini-3.1-pro-preview --message '/think adaptive Reply exactly: GEMINI_ADAPTIVE_OK' --timeout-ms 180000` - Budget dynamique de Gemini 2.5 : `OPENCLAW_ENABLE_PRIVATE_QA_CLI=1 pnpm openclaw qa manual --provider-mode live-frontier --model google/gemini-2.5-flash --alt-model google/gemini-2.5-flash --message '/think adaptive Reply exactly: GEMINI25_ADAPTIVE_OK' --timeout-ms 180000` Remarques : - `google/...` utilise l’API Gemini (clé d’API). - `google-antigravity/...` utilise la passerelle OAuth Antigravity (point de terminaison d’agent de type Cloud Code Assist). - `google-gemini-cli/...` utilise la CLI Gemini locale sur votre machine (authentification distincte et particularités propres aux outils). - API Gemini et CLI Gemini : - API : OpenClaw appelle l’API Gemini hébergée de Google via HTTP (clé d’API/authentification de profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ». - CLI : OpenClaw lance un binaire `gemini` local via le shell ; il possède sa propre authentification et peut se comporter différemment (diffusion en continu/prise en charge des outils/décalage de version). ## Actif : matrice de modèles (ce que nous couvrons) Les tests actifs sont facultatifs ; il n’existe donc aucune « liste de modèles CI » fixe. `OPENCLAW_LIVE_MODELS=modern` / `OPENCLAW_LIVE_GATEWAY_MODELS=modern` (ainsi que leur alias `all`) exécutent la liste de priorités sélectionnée dans `HIGH_SIGNAL_LIVE_MODEL_PRIORITY` dans `src/agents/live-model-filter.ts`, selon cet ordre de priorité : | Fournisseur/modèle | Remarques | | --------------------------------------------- | ---------- | | `anthropic/claude-opus-4-8` | | | `anthropic/claude-sonnet-5` | | | `anthropic/claude-sonnet-4-6` | | | `anthropic/claude-opus-4-7` | | | `google/gemini-3.1-pro-preview` | API Gemini | | `google/gemini-3.5-flash` | API Gemini | | `cohere/command-a-plus-05-2026` | | | `moonshot/kimi-k2.7-code` | | | `anthropic/claude-opus-4-6` | | | `deepseek/deepseek-v4-flash` | | | `deepseek/deepseek-v4-pro` | | | `minimax/MiniMax-M3` | | | `openai/gpt-5.5` | | | `openrouter/openai/gpt-5.2-chat` | | | `openrouter/minimax/minimax-m2.7` | | | `opencode-go/glm-5` | | | `openrouter/ai21/jamba-large-1.7` | | | `xai/grok-4.5` | | | `xai/grok-4.20-0309-reasoning` | | | `zai/glm-5.1` | | | `fireworks/accounts/fireworks/models/glm-5p1` | | | `minimax-portal/minimax-m3` | | La liste organisée des **petits modèles** (`OPENCLAW_LIVE_MODELS=small` / `OPENCLAW_LIVE_GATEWAY_MODELS=small`), issue de `SMALL_LIVE_MODEL_PRIORITY` : | Fournisseur/modèle | | ---------------------------- | | `lmstudio/qwen/qwen3.5-9b` | | `vllm/qwen/qwen3-8b` | | `sglang/qwen/qwen3-8b` | | `ollama/gemma3:4b` | | `openrouter/qwen/qwen3.5-9b` | | `openrouter/z-ai/glm-5.1` | | `openrouter/z-ai/glm-5` | | `zai/glm-5.1` | Remarques sur la liste moderne : - Les fournisseurs `codex` et `codex-cli` sont exclus de la vérification moderne par défaut (ils couvrent le comportement du backend CLI/ACP, testé séparément ci-dessus). `openai/gpt-5.5` lui-même passe par le banc d'essai du serveur d'application Codex par défaut ; voir [Tests en conditions réelles : vérification rapide du banc d'essai du serveur d'application Codex](#live-codex-app-server-harness-smoke). - `fireworks`, `google`, `openrouter` et `xai` n'exécutent que leurs identifiants de modèle explicitement sélectionnés dans la vérification moderne (sans extension automatique à « tous les modèles de ce fournisseur »). - Incluez au moins un modèle prenant en charge les images (variantes de vision des familles Claude/Gemini/OpenAI, etc.) dans `OPENCLAW_LIVE_GATEWAY_MODELS` afin d'exécuter la sonde d'image. Exécutez la vérification rapide du Gateway avec des outils et une image sur un ensemble de fournisseurs soigneusement sélectionné : ```bash OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.6-luna,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3.5-flash,google-antigravity/claude-opus-4-6-thinking,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts ``` Couverture supplémentaire facultative en dehors des listes organisées (souhaitable ; choisissez un modèle compatible avec les « outils » que vous avez activé) : - Mistral : `mistral/...` - Cerebras : `cerebras/...` (si vous y avez accès) - LM Studio : `lmstudio/...` (local ; l'appel d'outils dépend du mode de l'API) ### Agrégateurs / passerelles alternatives Si vous avez activé des clés, vous pouvez également effectuer des tests via : - OpenRouter : `openrouter/...` (des centaines de modèles ; utilisez `openclaw models scan` pour trouver des candidats prenant en charge les outils et les images) - OpenCode : `opencode/...` pour Zen et `opencode-go/...` pour Go (authentification via `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) Autres fournisseurs que vous pouvez inclure dans la matrice de tests en conditions réelles (si vous disposez des identifiants/configurations nécessaires) : - Intégrés : `anthropic`, `cerebras`, `github-copilot`, `google`, `google-antigravity`, `google-gemini-cli`, `google-vertex`, `groq`, `mistral`, `openai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `zai` - Via `models.providers` (points de terminaison personnalisés) : `minimax` (cloud/API), ainsi que tout proxy compatible avec OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.) Ne codez pas en dur « tous les modèles » dans la documentation. La liste de référence correspond à ce que `discoverModels(...)` renvoie sur votre machine, complété par les clés disponibles. ## Identifiants (ne jamais les valider dans le dépôt) Les tests en conditions réelles découvrent les identifiants de la même manière que la CLI. Conséquences pratiques : - Si la CLI fonctionne, les tests en conditions réelles devraient trouver les mêmes clés. - Si un test en conditions réelles indique « aucun identifiant », déboguez-le comme vous débogueriez `openclaw models list` ou la sélection du modèle. - Profils d'authentification par agent : `~/.openclaw/agents//agent/auth-profiles.json` (c'est ce que « clés de profil » signifie dans les tests en conditions réelles) - Configuration : `~/.openclaw/openclaw.json` (ou `OPENCLAW_CONFIG_PATH`) - Répertoire OAuth hérité : `~/.openclaw/credentials/` (copié dans le répertoire personnel temporaire des tests en conditions réelles lorsqu'il est présent, mais il ne s'agit pas du magasin principal des clés de profil) - Les exécutions locales en conditions réelles copient la configuration active (sans les remplacements `agents.*.workspace` / `agentDir`) et le fichier `auth-profiles.json` de chaque agent — mais pas le reste du répertoire de cet agent, afin que les données de `workspace/` et `sandboxes/` n'atteignent jamais le répertoire personnel temporaire — ainsi que le répertoire hérité `credentials/` et les fichiers/répertoires d'authentification pris en charge des CLI externes (`.claude.json`, `.claude/.credentials.json`, `.claude/settings*.json`, `.claude/backups`, `.codex/auth.json`, `.codex/config.toml`, `.gemini`, `.minimax`) dans un répertoire personnel de test temporaire. Si vous souhaitez utiliser des clés provenant de variables d'environnement, exportez-les avant les tests locaux ou utilisez les exécuteurs Docker ci-dessous avec un `OPENCLAW_PROFILE_FILE` explicite. ## Test en conditions réelles de Deepgram (transcription audio) - Test : `extensions/deepgram/audio.live.test.ts` - Activation : `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts` ## Test en conditions réelles du forfait de programmation BytePlus - Test : `extensions/byteplus/live.test.ts` - Activation : `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts` - Remplacement facultatif du modèle : `BYTEPLUS_CODING_MODEL=ark-code-latest` ## Test en conditions réelles des médias du flux de travail ComfyUI - Test : `extensions/comfy/comfy.live.test.ts` - Activation : `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts` - Portée : - Exerce les parcours intégrés de génération d'images et de vidéos de comfy, ainsi que `music_generate` - Ignore chaque fonctionnalité sauf si `plugins.entries.comfy.config.` est configuré - Utile après une modification de la soumission des flux de travail comfy, de l'interrogation périodique, des téléchargements ou de l'enregistrement du Plugin ## Test en conditions réelles de la génération d'images - Test : `test/image-generation.runtime.live.test.ts` - Commande : `pnpm test:live test/image-generation.runtime.live.test.ts` - Banc d'essai : `pnpm test:live:media image` - Portée : - Énumère tous les Plugins de fournisseur de génération d'images enregistrés - Utilise les variables d'environnement du fournisseur déjà exportées avant d'effectuer les sondes - Utilise par défaut les clés d'API actives/provenant de l'environnement avant les profils d'authentification enregistrés, afin que les clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants de l'environnement shell - Ignore les fournisseurs ne disposant d'aucune authentification, d'aucun profil ou d'aucun modèle utilisable - Exécute chaque fournisseur configuré via le moteur d'exécution partagé de génération d'images : - `:generate` - `:edit` lorsque le fournisseur déclare prendre en charge la modification - Fournisseurs intégrés actuellement couverts : - `deepinfra` - `fal` - `google` - `minimax` - `openai` - `openrouter` - `vydra` - `xai` - Restriction facultative : - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google,openrouter,xai"` - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="deepinfra"` - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-2,google/gemini-3.1-flash-image-preview,openrouter/google/gemini-3.1-flash-image-preview,xai/grok-imagine-image"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit,openrouter:generate,xai:default-generate,xai:default-edit"` - Comportement d'authentification facultatif : - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l'authentification via le magasin de profils et ignorer les remplacements provenant uniquement de l'environnement Pour le parcours de la CLI distribuée, ajoutez une vérification rapide `infer` après la réussite du test en conditions réelles du fournisseur/moteur d'exécution : ```bash OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_INFER_CLI_TEST=1 pnpm test:live -- test/image-generation.infer-cli.live.test.ts openclaw infer image providers --json openclaw infer image generate \ --model google/gemini-3.1-flash-image-preview \ --prompt "Image de test plate et minimaliste : un carré bleu sur un fond blanc, sans texte." \ --output ./openclaw-infer-image-smoke.png \ --json ``` Cela couvre l'analyse des arguments de la CLI, la résolution de la configuration et de l'agent par défaut, l'activation des Plugins intégrés, le moteur d'exécution partagé de génération d'images et la requête réelle au fournisseur. Les dépendances des Plugins doivent être présentes avant le chargement du moteur d'exécution. ## Test en conditions réelles de la génération musicale - Test : `extensions/music-generation-providers.live.test.ts` - Activation : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts` - Banc d'essai : `pnpm test:live:media music` - Portée : - Exerce le parcours partagé des fournisseurs intégrés de génération musicale - Couvre actuellement `fal`, `google`, `minimax` et `openrouter` - Utilise les variables d'environnement du fournisseur déjà exportées avant d'effectuer les sondes - Utilise par défaut les clés d'API actives/provenant de l'environnement avant les profils d'authentification enregistrés, afin que les clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants de l'environnement shell - Ignore les fournisseurs ne disposant d'aucune authentification, d'aucun profil ou d'aucun modèle utilisable - Exécute les deux modes déclarés du moteur d'exécution lorsqu'ils sont disponibles : - `generate` avec une entrée composée uniquement d'une invite - `edit` lorsque le fournisseur déclare `capabilities.edit.enabled` - `comfy` dispose de son propre fichier de test en conditions réelles distinct et ne fait pas partie de cette vérification partagée - Restriction facultative : - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.6"` - Comportement d'authentification facultatif : - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l'authentification via le magasin de profils et ignorer les remplacements provenant uniquement de l'environnement ## Test en conditions réelles de la génération vidéo - Test : `extensions/video-generation-providers.live.test.ts` - Activation : `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts` - Harnais : `pnpm test:live:media video` - Portée : - Exerce le chemin partagé des fournisseurs intégrés de génération vidéo pour `alibaba`, `byteplus`, `deepinfra`, `fal`, `google`, `minimax`, `openai`, `openrouter`, `pixverse`, `qwen`, `runway`, `together`, `vydra`, `xai` - Utilise par défaut le test rapide sûr pour les versions : une requête de génération de texte en vidéo par fournisseur, une invite de homard d’une seconde et une limite d’opération par fournisseur définie par `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (`180000` par défaut) - Ignore FAL par défaut, car la latence de la file d’attente côté fournisseur peut dominer la durée de publication ; transmettez `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"` (ou videz la liste d’exclusion) pour l’exécuter explicitement - Utilise les variables d’environnement de fournisseur déjà exportées avant d’effectuer les sondes - Privilégie par défaut les clés d’API actives issues de l’environnement par rapport aux profils d’authentification enregistrés, afin que des clés de test obsolètes dans `auth-profiles.json` ne masquent pas les véritables identifiants de l’interpréteur de commandes - Ignore les fournisseurs dépourvus d’authentification, de profil ou de modèle utilisable - Exécute uniquement `generate` par défaut - Définissez `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1` pour exécuter également les modes de transformation déclarés lorsqu’ils sont disponibles : - `imageToVideo` lorsque le fournisseur déclare `capabilities.imageToVideo.enabled` et que le fournisseur ou modèle sélectionné accepte une image locale adossée à un tampon dans la campagne partagée - `videoToVideo` lorsque le fournisseur déclare `capabilities.videoToVideo.enabled` et que le fournisseur ou modèle sélectionné accepte une vidéo locale adossée à un tampon dans la campagne partagée - Fournisseur `imageToVideo` actuellement déclaré, mais ignoré dans la campagne partagée : - `vydra` (les images locales adossées à un tampon ne sont pas prises en charge dans cette voie) - Couverture propre au fournisseur Vydra : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts` - Ce fichier exécute une génération de texte en vidéo avec `veo3`, ainsi qu’une voie de génération d’image en vidéo avec `kling` qui utilise par défaut une fixture d’URL d’image distante (`OPENCLAW_LIVE_VYDRA_KLING_IMAGE_URL` pour la remplacer). - Couverture propre au fournisseur xAI : - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_XAI_VIDEO=1 pnpm test:live -- extensions/xai/xai.live.test.ts -t "classic Grok Imagine"` - Le cas classique génère d’abord une première image PNG locale carrée, omet la géométrie, demande un clip d’image en vidéo d’une seconde, interroge l’état jusqu’à son achèvement et vérifie le tampon téléchargé. - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_XAI_VIDEO=1 pnpm test:live -- extensions/xai/xai.live.test.ts -t "Grok Imagine Video 1.5"` - Le cas 1.5 génère une première image PNG locale, demande un clip d’image en vidéo 1080P d’une seconde, interroge l’état jusqu’à son achèvement et vérifie le tampon téléchargé. - Couverture active actuelle de `videoToVideo` : - `runway` uniquement lorsque le modèle sélectionné se résout en `gen4_aleph` - Fournisseurs `videoToVideo` actuellement déclarés, mais ignorés dans la campagne partagée : - `alibaba`, `google`, `openai`, `qwen`, `xai`, car ces chemins nécessitent actuellement des URL de référence `http(s)` distantes plutôt qu’une entrée locale adossée à un tampon - Restriction facultative : - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="deepinfra,google,openai,runway"` - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"` - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""` pour inclure tous les fournisseurs dans la campagne par défaut, y compris FAL - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000` pour réduire la limite de chaque opération de fournisseur lors d’un test rapide intensif - Comportement d’authentification facultatif : - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` pour imposer l’authentification depuis le magasin de profils et ignorer les remplacements provenant uniquement de l’environnement ## Harnais actif pour les médias - Commande : `pnpm test:live:media` - Point d’entrée : `test/e2e/qa-lab/media/hosted-media-provider-live.ts`, qui exécute `pnpm test:live -- ` pour chaque suite sélectionnée, afin que le comportement du Heartbeat et du mode silencieux reste cohérent avec les autres exécutions de `pnpm test:live`. - Objectif : - Exécute les suites actives partagées d’image, de musique et de vidéo via un point d’entrée natif du dépôt - Charge automatiquement depuis `~/.profile` les variables d’environnement de fournisseur manquantes - Restreint automatiquement et par défaut chaque suite aux fournisseurs disposant actuellement d’une authentification utilisable - Options : - `--providers ` filtre global des fournisseurs ; `--image-providers` / `--music-providers` / `--video-providers` limitent un filtre à une seule suite - `--all-providers` désactive le filtrage automatique fondé sur l’authentification - `--allow-empty` quitte avec le code `0` lorsque le filtrage ne laisse aucun fournisseur exécutable - `--quiet` / `--no-quiet` transmis à `test:live` - Exemples : - `pnpm test:live:media` - `pnpm test:live:media image video --providers openai,google,minimax` - `pnpm test:live:media video --video-providers openai,runway --all-providers` - `pnpm test:live:media music --quiet` ## Ressources connexes - [Tests](/fr/help/testing) - suites unitaires, d’intégration, d’assurance qualité et Docker