Passer au contenu principal
Pour le démarrage rapide, les runners QA, les suites unitaires/d’intégration et les flux Docker, voir Tests. Cette page couvre les suites de tests en direct (avec accès réseau) : matrice de modèles, backends CLI, ACP et tests en direct des providers média, ainsi que la gestion des identifiants.

​
En direct : balayage des capacités de 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 du contrat de commande.
  • Portée :
    • Préconditions/configuration manuelle (la suite n’installe, n’exécute ni n’associe l’app).
    • Validation node.invoke du gateway, commande par commande, pour le Node Android sélectionné.
  • Préconfiguration requise :
    • Application Android déjà connectée + associée au gateway.
    • Application maintenue au premier plan.
    • Autorisations/consentements de capture accordés pour les capacités que vous attendez comme réussies.
  • Surcharges de cible facultatives :
    • 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 configuration Android : App Android

​
En direct : smoke de modèle (clés de profil)

Les tests en direct sont séparés en deux couches afin d’isoler les échecs :
  • « Modèle direct » nous indique si le provider/modèle peut répondre tout court avec la clé donnée.
  • « Gateway smoke » nous indique si tout le pipeline gateway+agent fonctionne pour ce modèle (sessions, historique, outils, politique de sandbox, etc.).

​
Couche 1 : completion directe du modèle (sans gateway)

  • Test : src/agents/models.profiles.live.test.ts
  • Objectif :
    • Énumérer les modèles découverts
    • Utiliser getApiKeyForModel pour sélectionner les modèles pour lesquels vous avez des identifiants
    • Exécuter une petite completion par modèle (et des régressions ciblées si nécessaire)
  • Comment l’activer :
    • pnpm test:live (ou OPENCLAW_LIVE_TEST=1 si vous invoquez Vitest directement)
  • Définissez OPENCLAW_LIVE_MODELS=modern (ou all, alias de modern) pour réellement exécuter cette suite ; sinon elle est ignorée afin de garder pnpm test:live centré sur le smoke gateway
  • Comment sélectionner les modèles :
    • OPENCLAW_LIVE_MODELS=modern pour exécuter la liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
    • OPENCLAW_LIVE_MODELS=all est un alias de la liste d’autorisation moderne
    • ou OPENCLAW_LIVE_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,..." (liste d’autorisation séparée par des virgules)
    • Les balayages modern/all utilisent par défaut un plafond organisé à fort signal ; définissez OPENCLAW_LIVE_MAX_MODELS=0 pour un balayage moderne exhaustif ou un nombre positif pour un plafond plus petit.
    • Les balayages exhaustifs utilisent OPENCLAW_LIVE_TEST_TIMEOUT_MS pour le délai maximal du test direct de modèle complet. Par défaut : 60 minutes.
    • Les sondes directes de modèle s’exécutent avec un parallélisme de 20 par défaut ; définissez OPENCLAW_LIVE_MODEL_CONCURRENCY pour le remplacer.
  • Comment sélectionner les providers :
    • OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli" (liste d’autorisation séparée par des virgules)
  • D’où viennent les clés :
    • Par défaut : magasin de profils et solutions de repli env
    • Définissez OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour imposer uniquement le magasin de profils
  • Pourquoi cela existe :
    • Sépare « l’API provider est cassée / la clé est invalide » de « le pipeline d’agent du gateway est cassé »
    • Contient de petites régressions isolées (exemple : replay de raisonnement OpenAI Responses/Codex Responses + flux d’appel d’outils)

​
Couche 2 : smoke Gateway + agent dev (ce que fait réellement “@openclaw”)

  • Test : src/gateway/gateway-models.profiles.live.test.ts
  • Objectif :
    • Démarrer un gateway en processus interne
    • Créer/patcher une session agent:dev:* (surcharge de modèle par exécution)
    • Itérer sur les modèles avec clés et vérifier :
      • réponse « significative » (sans outils)
      • qu’une invocation réelle d’outil fonctionne (sonde read)
      • sondes d’outils supplémentaires facultatives (sonde exec+read)
      • que les chemins de régression OpenAI (tool-call-only → suivi) continuent de fonctionner
  • Détails des sondes (pour pouvoir expliquer rapidement les échecs) :
    • sonde read : le test écrit un fichier nonce dans l’espace de travail et demande à l’agent de le read puis de renvoyer le nonce.
    • sonde exec+read : le test demande à l’agent d’écrire un nonce dans un fichier temporaire via exec, puis de le read.
    • sonde d’image : le test joint un PNG généré (chat + code aléatoire) et attend que le modèle renvoie cat <CODE>.
    • Référence d’implémentation : src/gateway/gateway-models.profiles.live.test.ts et src/gateway/live-image-probe.ts.
  • Comment l’activer :
    • pnpm test:live (ou OPENCLAW_LIVE_TEST=1 si vous invoquez Vitest directement)
  • Comment sélectionner les modèles :
    • Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
    • OPENCLAW_LIVE_GATEWAY_MODELS=all est un alias de la liste d’autorisation moderne
    • Ou définissez OPENCLAW_LIVE_GATEWAY_MODELS="provider/model" (ou une liste séparée par des virgules) pour restreindre
    • Les balayages gateway modern/all utilisent par défaut un plafond organisé à fort signal ; définissez OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 pour un balayage moderne exhaustif ou un nombre positif pour un plafond plus petit.
  • Comment sélectionner les providers (éviter « OpenRouter partout ») :
    • 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 + d’image sont toujours actives dans ce test en direct :
    • sonde read + sonde exec+read (stress des outils)
    • la sonde d’image s’exécute lorsque le modèle annonce la prise en charge d’entrées image
    • Flux (haut niveau) :
      • Le test génère un petit PNG avec « CAT » + code aléatoire (src/gateway/live-image-probe.ts)
      • L’envoie via agent avec attachments: [{ mimeType: "image/png", content: "<base64>" }]
      • Le Gateway analyse les pièces jointes dans images[] (src/gateway/server-methods/agent.ts + src/gateway/chat-attachments.ts)
      • L’agent intégré transmet un message utilisateur multimodal au modèle
      • Vérification : la réponse contient cat + le code (tolérance OCR : petites erreurs autorisées)
Conseil : pour voir ce que vous pouvez tester sur votre machine (et les identifiants exacts provider/model), exécutez : 
openclaw models list
openclaw models list --json

​
En direct : smoke de backend CLI (Claude, Codex, Gemini, ou autres CLI locaux)

  • Test : src/gateway/gateway-cli-backend.live.test.ts
  • Objectif : valider le pipeline Gateway + agent à l’aide d’un backend CLI local, sans toucher à votre configuration par défaut.
  • Les valeurs par défaut de smoke spécifiques aux backends vivent avec la définition cli-backend.ts de l’extension 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 :
    • Provider/modèle par défaut : claude-cli/claude-sonnet-4-6
    • Le comportement commande/args/image provient des métadonnées du Plugin de backend CLI propriétaire.
  • Surcharges (facultatives) :
    • OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.2"
    • OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"
    • OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1 pour envoyer une vraie pièce jointe image (les chemins sont injectés dans le prompt).
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image" pour transmettre les chemins de fichier image comme arguments CLI au lieu de l’injection dans le prompt.
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat" (ou "list") pour contrôler la façon dont les arguments d’image sont passés 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=0 pour désactiver la sonde de continuité de session par défaut Claude Sonnet -> Opus sur la même session (définissez à 1 pour la forcer lorsque le modèle sélectionné prend en charge une cible de bascule).
Exemple : 
OPENCLAW_LIVE_CLI_BACKEND=1 \
  OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.2" \
  pnpm test:live src/gateway/gateway-cli-backend.live.test.ts
Recette Docker : 
pnpm test:docker:live-cli-backend
Recettes Docker mono-provider : 
pnpm test:docker:live-cli-backend:claude
pnpm test:docker:live-cli-backend:claude-subscription
pnpm test:docker:live-cli-backend:codex
pnpm test:docker:live-cli-backend:gemini
Remarques :
  • Le runner Docker se trouve dans scripts/test-live-cli-backend-docker.sh.
  • Il exécute le smoke de backend CLI en direct dans l’image Docker du dépôt en tant qu’utilisateur non root node.
  • Il résout les métadonnées du smoke CLI depuis l’extension propriétaire, puis installe le package CLI Linux correspondant (@anthropic-ai/claude-code, @openai/codex, ou @google/gemini-cli) dans un préfixe inscriptible mis en cache à OPENCLAW_DOCKER_CLI_TOOLS_DIR (par défaut : ~/.cache/openclaw/docker-cli-tools).
  • pnpm test:docker:live-cli-backend:claude-subscription nécessite un OAuth d’abonnement Claude Code portable via soit ~/.claude/.credentials.json avec claudeAiOauth.subscriptionType, soit CLAUDE_CODE_OAUTH_TOKEN depuis claude setup-token. Il prouve d’abord claude -p direct dans Docker, puis exécute deux tours de backend CLI Gateway sans conserver les variables d’environnement de clé API Anthropic. Cette voie d’abonnement désactive par défaut les sondes Claude MCP/tool et image, car Claude route actuellement l’usage des applications tierces via une facturation d’usage supplémentaire au lieu des limites normales du plan d’abonnement.
  • Le smoke de backend CLI en direct exerce maintenant le même flux de bout en bout pour Claude, Codex et Gemini : tour texte, tour de classification d’image, puis appel à l’outil MCP cron vérifié via le CLI du gateway.
  • Le smoke par défaut de Claude patche aussi la session de Sonnet vers Opus et vérifie que la session reprise se souvient encore d’une note antérieure.

​
En direct : smoke de liaison ACP (/acp spawn ... --bind here)

  • Test : src/gateway/gateway-acp-bind.live.test.ts
  • Objectif : valider le vrai flux conversation-bind ACP avec un agent ACP en direct :
    • envoyer /acp spawn <agent> --bind here
    • lier en place une conversation synthétique de canal de message
    • envoyer un suivi normal sur cette même conversation
    • vérifier que le suivi arrive dans la transcription de 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 pnpm test:live ... direct : claude
    • Canal synthétique : contexte de conversation de type DM Slack
    • Backend ACP : acpx
  • Surcharges :
    • OPENCLAW_LIVE_ACP_BIND_AGENT=claude
    • OPENCLAW_LIVE_ACP_BIND_AGENT=codex
    • OPENCLAW_LIVE_ACP_BIND_AGENT=gemini
    • OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini
    • OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'
    • OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.2
    • OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.2
  • Remarques :
    • Cette voie utilise la surface chat.send du gateway avec des champs admin-only de route d’origine synthétique afin que les tests puissent attacher le contexte de canal de message sans prétendre livrer à l’extérieur.
    • 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 harnais ACP sélectionné.
Exemple : 
OPENCLAW_LIVE_ACP_BIND=1 \
  OPENCLAW_LIVE_ACP_BIND_AGENT=claude \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
Recette Docker : 
pnpm test:docker:live-acp-bind
Recettes Docker mono-agent : 
pnpm test:docker:live-acp-bind:claude
pnpm test:docker:live-acp-bind:codex
pnpm test:docker:live-acp-bind:gemini
Remarques Docker :
  • Le runner Docker se trouve dans scripts/test-live-acp-bind-docker.sh.
  • Par défaut, il exécute le smoke de liaison ACP sur tous les agents CLI en direct pris en charge, dans l’ordre : claude, codex, puis gemini.
  • Utilisez OPENCLAW_LIVE_ACP_BIND_AGENTS=claude, OPENCLAW_LIVE_ACP_BIND_AGENTS=codex, ou OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini pour restreindre la matrice.
  • Il source ~/.profile, prépare dans le conteneur le matériel d’authentification CLI correspondant, installe acpx dans un préfixe npm inscriptible, puis installe le CLI en direct demandé (@anthropic-ai/claude-code, @openai/codex, ou @google/gemini-cli) s’il manque.
  • Dans Docker, le runner définit OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx afin qu’acpx conserve disponibles pour le CLI du harnais enfant les variables d’environnement provider issues du profil sourcé.

​
En direct : smoke de harnais Codex app-server

  • Objectif : valider le harnais Codex détenu par le Plugin via la méthode normale agent du gateway :
    • charger le Plugin intégré codex
    • sélectionner OPENCLAW_AGENT_RUNTIME=codex
    • envoyer un premier tour d’agent gateway vers openai/gpt-5.2 avec le harnais Codex forcé
    • envoyer un second tour à la même session OpenClaw et vérifier que le thread app-server peut reprendre
    • exécuter /codex status et /codex models via le même chemin de commande gateway
    • exécuter éventuellement deux sondes shell escaladées examinées par Guardian : une commande bénigne qui devrait être approuvée et un faux upload de secret qui devrait être refusé afin que l’agent redemande
  • Test : src/gateway/gateway-codex-harness.live.test.ts
  • Activation : OPENCLAW_LIVE_CODEX_HARNESS=1
  • Modèle par défaut : openai/gpt-5.2
  • Sonde d’image facultative : OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1
  • Sonde MCP/tool facultative : OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1
  • Sonde Guardian facultative : OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1
  • Le smoke définit OPENCLAW_AGENT_HARNESS_FALLBACK=none afin qu’un harnais Codex cassé ne puisse pas réussir en revenant silencieusement à PI.
  • Authentification : auth Codex app-server depuis la connexion locale d’abonnement Codex. Les smokes Docker peuvent aussi fournir OPENAI_API_KEY pour les sondes non Codex lorsque cela s’applique, ainsi qu’une copie facultative de ~/.codex/auth.json et ~/.codex/config.toml.
Recette locale : 
source ~/.profile
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.2 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts
Recette Docker : 
source ~/.profile
pnpm test:docker:live-codex-harness
Remarques Docker :
  • Le runner Docker se trouve dans scripts/test-live-codex-harness-docker.sh.
  • Il source le ~/.profile monté, transmet OPENAI_API_KEY, copie les fichiers d’authentification du CLI Codex lorsqu’ils sont présents, installe @openai/codex dans un préfixe npm inscriptible monté, prépare l’arbre source, puis n’exécute que le test en direct du harnais Codex.
  • Docker active par défaut les sondes image, MCP/tool 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 lorsque vous avez besoin d’une exécution de débogage plus restreinte.
  • Docker exporte aussi OPENCLAW_AGENT_HARNESS_FALLBACK=none, en cohérence avec la configuration du test en direct afin que les alias hérités ou le repli PI ne puissent pas masquer une régression du harnais Codex.

​
Recettes en direct recommandées

Les listes d’autorisation étroites et explicites sont les plus rapides et les moins sujettes aux faux problèmes :
  • Modèle unique, direct (sans gateway) :
    • OPENCLAW_LIVE_MODELS="openai/gpt-5.2" pnpm test:live src/agents/models.profiles.live.test.ts
  • Modèle unique, gateway smoke :
    • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
  • Appel d’outils sur plusieurs providers :
    • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
  • Focus Google (clé API Gemini + Antigravity) :
    • Gemini (clé API) : OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" 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
Remarques :
  • google/... utilise l’API Gemini (clé API).
  • google-antigravity/... utilise le pont OAuth Antigravity (point de terminaison agent de style Cloud Code Assist).
  • google-gemini-cli/... utilise le CLI Gemini local sur votre machine (authentification séparée + particularités d’outillage).
  • API Gemini vs CLI Gemini :
    • API : OpenClaw appelle l’API Gemini hébergée de Google via HTTP (authentification par clé API / profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ».
    • CLI : OpenClaw exécute un binaire local gemini ; il a sa propre authentification et peut se comporter différemment (streaming/prise en charge des outils/décalage de version).

​
En direct : matrice de modèles (ce que nous couvrons)

Il n’existe pas de « liste fixe de modèles CI » (le direct est opt-in), mais voici les modèles recommandés à couvrir régulièrement sur une machine de développement avec des clés.

​
Jeu de smoke moderne (appel d’outils + image)

C’est l’exécution « modèles courants » que nous attendons de continuer à voir fonctionner :
  • OpenAI (non-Codex) : openai/gpt-5.2
  • OpenAI Codex OAuth : openai-codex/gpt-5.2
  • Anthropic : anthropic/claude-opus-4-6 (ou anthropic/claude-sonnet-4-6)
  • Google (API Gemini) : google/gemini-3.1-pro-preview et google/gemini-3-flash-preview (évitez les anciens modèles Gemini 2.x)
  • Google (Antigravity) : google-antigravity/claude-opus-4-6-thinking et google-antigravity/gemini-3-flash
  • Z.AI (GLM) : zai/glm-4.7
  • MiniMax : minimax/MiniMax-M2.7
Exécuter le gateway smoke avec outils + image : OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts

​
Référence de base : appel d’outils (Read + Exec facultatif)

Choisissez au moins un modèle par famille de providers :
  • OpenAI : openai/gpt-5.2
  • Anthropic : anthropic/claude-opus-4-6 (ou anthropic/claude-sonnet-4-6)
  • Google : google/gemini-3-flash-preview (ou google/gemini-3.1-pro-preview)
  • Z.AI (GLM) : zai/glm-4.7
  • MiniMax : minimax/MiniMax-M2.7
Couverture supplémentaire facultative (agréable à avoir) :
  • xAI : xai/grok-4 (ou la dernière version disponible)
  • Mistral : mistral/… (choisissez un modèle « tools » activé)
  • Cerebras : cerebras/… (si vous y avez accès)
  • LM Studio : lmstudio/… (local ; l’appel d’outils dépend du mode API)

​
Vision : envoi d’image (pièce jointe → message multimodal)

Incluez au moins un modèle compatible image dans OPENCLAW_LIVE_GATEWAY_MODELS (Claude/Gemini/variantes OpenAI compatibles vision, etc.) afin d’exercer la sonde image.

​
Agrégateurs / gateways alternatifs

Si vous avez des clés activées, nous prenons aussi en charge les tests via :
  • OpenRouter : openrouter/... (des centaines de modèles ; utilisez openclaw models scan pour trouver des candidats compatibles outils+image)
  • OpenCode : opencode/... pour Zen et opencode-go/... pour Go (authentification via OPENCODE_API_KEY / OPENCODE_ZEN_API_KEY)
Autres providers que vous pouvez inclure dans la matrice en direct (si vous avez les identifiants/la configuration) :
  • Intégrés : openai, openai-codex, anthropic, google, google-vertex, google-antigravity, google-gemini-cli, zai, openrouter, opencode, opencode-go, xai, groq, cerebras, mistral, github-copilot
  • Via models.providers (points de terminaison personnalisés) : minimax (cloud/API), plus tout proxy compatible OpenAI/Anthropic (LM Studio, vLLM, LiteLLM, etc.)
Conseil : n’essayez pas de coder en dur « tous les modèles » dans la documentation. La liste faisant autorité est ce que discoverModels(...) renvoie sur votre machine + les clés disponibles.

​
Identifiants (ne jamais commit)

Les tests en direct découvrent les identifiants de la même façon que le CLI. Implications pratiques :
  • Si le CLI fonctionne, les tests en direct devraient trouver les mêmes clés.
  • Si un test en direct dit « pas d’identifiants », déboguez-le comme vous débogueriez openclaw models list / la sélection de modèle.
  • Profils d’authentification par agent : ~/.openclaw/agents/<agentId>/agent/auth-profiles.json (c’est ce que signifient les « profile keys » dans les tests en direct)
  • Configuration : ~/.openclaw/openclaw.json (ou OPENCLAW_CONFIG_PATH)
  • Répertoire d’état hérité : ~/.openclaw/credentials/ (copié dans le home de test en direct préparé lorsqu’il est présent, mais pas le magasin principal de clés de profil)
  • Les exécutions locales en direct copient par défaut la configuration active, les fichiers auth-profiles.json par agent, credentials/ hérité, et les répertoires d’authentification CLI externes pris en charge dans un home de test temporaire ; les homes en direct préparés ignorent workspace/ et sandboxes/, et les surcharges de chemin agents.*.workspace / agentDir sont supprimées afin que les sondes restent hors de votre espace de travail réel sur l’hôte.
Si vous voulez vous appuyer sur des clés env (par ex. exportées dans votre ~/.profile), exécutez les tests locaux après source ~/.profile, ou utilisez les runners Docker ci-dessous (ils peuvent monter ~/.profile dans le conteneur).

​
Deepgram en direct (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

​
BytePlus coding plan en direct

  • Test : extensions/byteplus/live.test.ts
  • Activation : BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts
  • Surcharge de modèle facultative : BYTEPLUS_CODING_MODEL=ark-code-latest

​
Média de workflow ComfyUI en direct

  • 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 chemins image, vidéo et music_generate du comfy intégré
    • Ignore chaque capacité sauf si models.providers.comfy.<capability> est configuré
    • Utile après modification de la soumission de workflow comfy, du polling, des téléchargements ou de l’enregistrement du Plugin

​
Génération d’image en direct

  • Test : test/image-generation.runtime.live.test.ts
  • Commande : pnpm test:live test/image-generation.runtime.live.test.ts
  • Harnais : pnpm test:live:media image
  • Portée :
    • Énumère chaque Plugin provider de génération d’image enregistré
    • Charge les variables d’environnement provider manquantes depuis votre shell de connexion (~/.profile) avant de sonder
    • Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test obsolètes dans auth-profiles.json ne masquent pas les vrais identifiants du shell
    • Ignore les providers sans auth/profil/modèle utilisable
    • Exécute les variantes standard de génération d’image via la capacité runtime partagée :
      • google:flash-generate
      • google:pro-generate
      • google:pro-edit
      • openai:default-generate
  • Providers intégrés actuellement couverts :
    • fal
    • google
    • minimax
    • openai
    • openrouter
    • vydra
    • xai
  • Restriction facultative :
    • OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google,openrouter,xai"
    • 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 forcer l’authentification via le magasin de profils et ignorer les surcharges env-only

​
Génération musicale en direct

  • Test : extensions/music-generation-providers.live.test.ts
  • Activation : OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts
  • Harnais : pnpm test:live:media music
  • Portée :
    • Exerce le chemin partagé des providers intégrés de génération musicale
    • Couvre actuellement Google et MiniMax
    • Charge les variables d’environnement provider depuis votre shell de connexion (~/.profile) avant de sonder
    • Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test obsolètes dans auth-profiles.json ne masquent pas les vrais identifiants du shell
    • Ignore les providers sans auth/profil/modèle utilisable
    • Exécute les deux modes runtime déclarés lorsqu’ils sont disponibles :
      • generate avec entrée prompt uniquement
      • edit lorsque le provider déclare capabilities.edit.enabled
    • Couverture actuelle de la voie partagée :
      • google : generate, edit
      • minimax : generate
      • comfy : fichier en direct Comfy séparé, pas ce balayage partagé
  • Restriction facultative :
    • OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"
    • OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"
  • Comportement d’authentification facultatif :
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification via le magasin de profils et ignorer les surcharges env-only

​
Génération vidéo en direct

  • 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 providers intégrés de génération vidéo
    • Utilise par défaut le chemin de smoke sûr pour la publication : providers hors FAL, une requête texte-vers-vidéo par provider, prompt lobster d’une seconde, et plafond d’opération par provider issu de OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS (180000 par défaut)
    • Ignore FAL par défaut car la latence de file d’attente côté provider peut dominer le temps de publication ; passez --video-providers fal ou OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal" pour l’exécuter explicitement
    • Charge les variables d’environnement provider depuis votre shell de connexion (~/.profile) avant de sonder
    • Utilise par défaut les clés API live/env avant les profils d’authentification stockés, afin que des clés de test obsolètes dans auth-profiles.json ne masquent pas les vrais identifiants du shell
    • Ignore les providers sans auth/profil/modèle utilisable
    • N’exécute que generate par défaut
    • Définissez OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1 pour exécuter aussi les modes de transformation déclarés lorsqu’ils sont disponibles :
      • imageToVideo lorsque le provider déclare capabilities.imageToVideo.enabled et que le provider/modèle sélectionné accepte une entrée image locale adossée à un buffer dans le balayage partagé
      • videoToVideo lorsque le provider déclare capabilities.videoToVideo.enabled et que le provider/modèle sélectionné accepte une entrée vidéo locale adossée à un buffer dans le balayage partagé
    • Providers imageToVideo actuellement déclarés mais ignorés dans le balayage partagé :
      • vydra parce que le veo3 intégré est texte uniquement et que le kling intégré nécessite une URL d’image distante
    • Couverture spécifique au provider Vydra :
      • OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts
      • ce fichier exécute veo3 texte-vers-vidéo plus une voie kling qui utilise par défaut un fixture d’URL d’image distante
    • Couverture actuelle videoToVideo en direct :
      • runway uniquement lorsque le modèle sélectionné est runway/gen4_aleph
    • Providers videoToVideo actuellement déclarés mais ignorés dans le balayage partagé :
      • alibaba, qwen, xai parce que ces chemins nécessitent actuellement des URL de référence distantes http(s) / MP4
      • google parce que la voie partagée actuelle Gemini/Veo utilise une entrée locale adossée à un buffer et que ce chemin n’est pas accepté dans le balayage partagé
      • openai parce que la voie partagée actuelle manque de garanties d’accès spécifiques à l’organisation pour l’inpaint/remix vidéo
  • Restriction facultative :
    • OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="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 chaque provider dans le balayage par défaut, y compris FAL
    • OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000 pour réduire le plafond d’opération de chaque provider lors d’un smoke agressif
  • Comportement d’authentification facultatif :
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification via le magasin de profils et ignorer les surcharges env-only

​
Harnais média en direct

  • Commande : pnpm test:live:media
  • Objectif :
    • Exécute les suites en direct partagées image, musique et vidéo via un point d’entrée natif du dépôt
    • Charge automatiquement les variables d’environnement provider manquantes depuis ~/.profile
    • Restreint automatiquement chaque suite aux providers disposant actuellement d’une authentification utilisable par défaut
    • Réutilise scripts/test-live.mjs, de sorte que Heartbeat et le mode silencieux restent cohérents
  • 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

​
Lié

  • Tests — suites unitaires, d’intégration, QA et Docker