Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Pour le démarrage rapide, les exécuteurs QA, les suites unitaires/d’intégration et les flux Docker, consultez Tests. Cette page couvre les suites de test live (qui touchent au réseau) : matrice de modèles, backends CLI, ACP et tests live des fournisseurs multimédias, ainsi que la gestion des identifiants.

​
Live : commandes de smoke locales avec profil

Sourcez ~/.profile avant les vérifications live ad hoc afin que les clés de fournisseurs et les chemins d’outils locaux correspondent à votre shell : 
source ~/.profile
Smoke multimédia sûr : 
pnpm openclaw infer tts convert --local --json \
  --text "OpenClaw live smoke." \
  --output /tmp/openclaw-live-smoke.mp3
Smoke sûr de préparation aux appels vocaux : 
pnpm openclaw voicecall setup --json
pnpm openclaw voicecall smoke --to "+15555550123"
voicecall smoke est une simulation, sauf si --yes est également présent. Utilisez --yes uniquement lorsque vous voulez intentionnellement passer un véritable appel de notification. Pour Twilio, Telnyx et Plivo, une vérification de préparation réussie nécessite une URL Webhook publique ; les solutions de repli loopback locales uniquement/privées sont rejetées par conception.

​
Live : balayage des capacités du nœud Android

  • Test : src/gateway/android-node.capabilities.live.test.ts
  • Script : pnpm android:test:integration
  • Objectif : invoquer chaque commande actuellement annoncée par un nœud Android connecté et vérifier le comportement du contrat de commande.
  • Portée :
    • Configuration préalable/manuelle (la suite n’installe pas, n’exécute pas et n’appaire pas l’application).
    • Validation Gateway node.invoke, commande par commande, pour le nœud Android sélectionné.
  • Préconfiguration requise :
    • Application Android déjà connectée et appairée au Gateway.
    • Application maintenue au premier plan.
    • Autorisations/consentement de capture accordés pour les capacités que vous vous attendez à voir réussir.
  • Remplacements de cible facultatifs :
    • 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 : Application Android

​
Live : smoke des modèles (clés de profil)

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

​
Couche 1 : complétion 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 complétion par modèle (et des régressions ciblées si nécessaire)
  • Activation :
    • 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 exécuter réellement cette suite ; sinon elle est ignorée afin de garder pnpm test:live centré sur le smoke Gateway
  • Sélection des modèles :
    • OPENCLAW_LIVE_MODELS=modern pour exécuter la liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
    • OPENCLAW_LIVE_MODELS=all est un alias de la liste d’autorisation moderne
    • ou OPENCLAW_LIVE_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,..." (liste d’autorisation séparée par des virgules)
    • Les balayages modern/all utilisent par défaut une limite organisée à signal élevé ; définissez OPENCLAW_LIVE_MAX_MODELS=0 pour un balayage moderne exhaustif ou un nombre positif pour une limite plus petite.
    • Les balayages exhaustifs utilisent OPENCLAW_LIVE_TEST_TIMEOUT_MS pour le délai d’expiration global du test de modèle direct. Valeur par défaut : 60 minutes.
    • Les sondes de modèle direct s’exécutent par défaut avec un parallélisme de 20 ; 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 d’environnement
    • Définissez OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour imposer uniquement le magasin de profils
  • Pourquoi cela existe :
    • Sépare « l’API fournisseur est cassée / la clé est invalide » de « le pipeline d’agent Gateway est cassé »
    • Contient de petites régressions isolées (exemple : relecture de raisonnement OpenAI Responses/Codex Responses + flux d’appels d’outils)

​
Couche 2 : smoke Gateway + agent de développement (ce que fait réellement « @openclaw »)

  • Test : src/gateway/gateway-models.profiles.live.test.ts
  • Objectif :
    • Démarrer un Gateway en processus
    • Créer/corriger une session agent:dev:* (remplacement de modèle à chaque exécution)
    • Parcourir les modèles avec clés et vérifier :
      • réponse « significative » (sans outils)
      • un véritable appel d’outil fonctionne (sonde de lecture)
      • sondes d’outils supplémentaires facultatives (sonde exec+read)
      • les chemins de régression OpenAI (appel d’outil uniquement → suivi) continuent de fonctionner
  • Détails des sondes (pour 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, via exec, un nonce dans un fichier temporaire, puis de le relire avec read.
    • sonde d’image : le test joint un PNG généré (cat + code aléatoire) et s’attend à ce 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.
  • Activation :
    • pnpm test:live (ou OPENCLAW_LIVE_TEST=1 si vous invoquez Vitest directement)
  • Sélection des modèles :
    • Par défaut : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M2.7, Grok 4.3)
    • 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 une limite organisée à signal élevé ; définissez OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 pour un balayage moderne exhaustif ou un nombre positif pour une limite plus petite.
  • Sélection des fournisseurs (éviter « tout 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 live :
    • sonde read + sonde exec+read (stress des outils)
    • la sonde d’image s’exécute lorsque le modèle annonce la prise en charge de l’entrée image
    • Flux (vue d’ensemble) :
      • Le test génère un petit PNG avec « CAT » + code aléatoire (src/gateway/live-image-probe.ts)
      • L’envoie via agent attachments: [{ mimeType: "image/png", content: "<base64>" }]
      • Gateway analyse les pièces jointes en images[] (src/gateway/server-methods/agent.ts + src/gateway/chat-attachments.ts)
      • L’agent intégré transmet au modèle un message utilisateur multimodal
      • Assertion : la réponse contient cat + le code (tolérance OCR : erreurs mineures autorisées)
Pour voir ce que vous pouvez tester sur votre machine (et les identifiants provider/model exacts), exécutez :
openclaw models list
openclaw models list --json

​
Live : smoke du backend CLI (Claude, Codex, Gemini ou autres CLI locales)

  • Test : src/gateway/gateway-cli-backend.live.test.ts
  • Objectif : valider le pipeline Gateway + agent avec un backend CLI local, sans toucher à votre configuration par défaut.
  • Les valeurs par défaut de smoke propres au backend vivent avec la définition cli-backend.ts de l’extension propriétaire.
  • Activer :
    • 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 commande/arguments/image provient des métadonnées du Plugin backend CLI propriétaire.
  • Remplacements (facultatifs) :
    • OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.5"
    • 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 véritable pièce jointe image (les chemins sont injectés dans le prompt). Les recettes Docker désactivent cela par défaut sauf demande explicite.
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image" pour passer les chemins de fichiers image comme arguments CLI au lieu d’une injection dans le prompt.
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat" (ou "list") pour contrôler la manière 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=1 pour activer la sonde de continuité de même session Claude Sonnet -> Opus lorsque le modèle sélectionné prend en charge une cible de bascule. Les recettes Docker désactivent cela par défaut pour la fiabilité agrégée.
    • OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1 pour activer la sonde MCP/outil loopback. Les recettes Docker désactivent cela par défaut sauf demande explicite.
Exemple : 
OPENCLAW_LIVE_CLI_BACKEND=1 \
  OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.5" \
  pnpm test:live src/gateway/gateway-cli-backend.live.test.ts
Smoke de configuration MCP Gemini peu coûteux : 
OPENCLAW_LIVE_TEST=1 \
  pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts
Cela ne demande pas à Gemini de générer une réponse. Il écrit les mêmes paramètres système qu’OpenClaw fournit à Gemini, puis exécute gemini --debug mcp list pour prouver qu’un serveur transport: "streamable-http" enregistré est normalisé vers la forme MCP HTTP de Gemini et peut se connecter à un serveur MCP streamable-HTTP local. Recette Docker : 
pnpm test:docker:live-cli-backend
Recettes Docker pour fournisseur unique : 
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
Notes :
  • L’exécuteur Docker se trouve dans scripts/test-live-cli-backend-docker.sh.
  • Il exécute le smoke live du backend CLI dans l’image Docker du dépôt en tant qu’utilisateur non root node.
  • Il résout les métadonnées de 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 l’OAuth portable d’abonnement Claude Code via ~/.claude/.credentials.json avec claudeAiOauth.subscriptionType ou CLAUDE_CODE_OAUTH_TOKEN depuis claude setup-token. Il prouve d’abord claude -p direct dans Docker, puis exécute deux tours Gateway CLI-backend sans conserver les variables d’environnement de clé API Anthropic. Cette voie d’abonnement désactive par défaut les sondes MCP/outil et image de Claude, car Claude route actuellement l’usage par des applications tierces via une facturation d’utilisation supplémentaire plutôt que via les limites normales du plan d’abonnement.
  • Le smoke live du backend CLI exerce désormais le même flux de bout en bout pour Claude, Codex et Gemini : tour texte, tour de classification d’image, puis appel d’outil MCP cron vérifié via la CLI Gateway.
  • Le smoke par défaut de Claude corrige également la session de Sonnet vers Opus et vérifie que la session reprise se souvient encore d’une note antérieure.

​
Live : accessibilité du proxy HTTP/2 APNs

  • Test : src/infra/push-apns-http2.live.test.ts
  • Objectif : passer par un proxy HTTP CONNECT local jusqu’au point de terminaison APNs sandbox 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.
  • Activer :
    • 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

​
Live : smoke de bind 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 en direct :
    • envoyer /acp spawn <agent> --bind here
    • lier en place une conversation synthétique de canal de messages
    • envoyer un suivi normal dans cette même conversation
    • vérifier que le suivi arrive dans la transcription de session ACP liée
  • Activer :
    • 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 MP Slack
    • Backend ACP : acpx
  • Remplacements :
    • 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@<version>'
    • OPENCLAW_LIVE_ACP_BIND_CODEX_MODEL=gpt-5.5
    • OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL=opencode/kimi-k2.6
    • OPENCLAW_LIVE_ACP_BIND_REQUIRE_TRANSCRIPT=1
    • OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1
    • OPENCLAW_LIVE_ACP_BIND_PARENT_MODEL=openai/gpt-5.5
  • Notes :
    • Cette voie utilise la surface chat.send du gateway avec des champs de route d’origine synthétiques réservés aux administrateurs, afin que les tests puissent attacher un contexte de canal de messages sans prétendre livrer en 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 harnais ACP sélectionné.
    • La création MCP Cron de session liée est en mode meilleur effort par défaut, car les harnais ACP externes peuvent annuler les appels MCP après la réussite de la preuve de liaison/image ; définissez OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1 pour rendre cette sonde Cron post-liaison stricte.
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:droid
pnpm test:docker:live-acp-bind:gemini
pnpm test:docker:live-acp-bind:opencode
Notes Docker :
  • Le lanceur Docker se trouve dans scripts/test-live-acp-bind-docker.sh.
  • Par défaut, il exécute le smoke de liaison ACP contre les agents CLI en direct agrégés dans l’ordre : 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 réduire la matrice.
  • Il source ~/.profile, prépare le matériel d’authentification CLI correspondant dans le conteneur, puis installe la CLI en direct 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 package acpx/runtime embarqué du plugin acpx officiel.
  • La variante Docker Droid prépare ~/.factory pour les paramètres, transmet FACTORY_API_KEY et exige cette clé API, car l’authentification locale Factory OAuth/keyring n’est pas portable dans le conteneur. Elle utilise l’entrée de registre intégrée d’ACPX droid exec --output-format acp.
  • La variante Docker OpenCode est une voie de régression mono-agent stricte. Elle écrit un modèle par défaut temporaire OPENCODE_CONFIG_CONTENT à partir de OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL (opencode/kimi-k2.6 par défaut) après avoir sourcé ~/.profile, et pnpm test:docker:live-acp-bind:opencode exige une transcription d’assistant liée au lieu d’accepter le saut post-liaison générique.
  • Les appels CLI acpx directs ne sont qu’un chemin manuel/de contournement pour comparer le comportement hors du Gateway. Le smoke Docker de liaison ACP exerce le backend d’exécution acpx embarqué d’OpenClaw.

​
En direct : smoke du harnais de serveur d’application Codex

  • Objectif : valider le harnais Codex détenu par le plugin via la méthode normale agent du gateway :
    • charger le plugin codex groupé
    • sélectionner openai/gpt-5.5, qui route par défaut les tours d’agent OpenAI via Codex
    • envoyer un premier tour d’agent gateway à openai/gpt-5.5 avec le harnais Codex sélectionné
    • 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 gateway
    • éventuellement exécuter deux sondes shell avec élévation revues par Guardian : une commande bénigne qui devrait être approuvée et un téléversement de faux secret qui devrait être refusé afin que l’agent réponde en demandant une clarification
  • Test : src/gateway/gateway-codex-harness.live.test.ts
  • Activer : OPENCLAW_LIVE_CODEX_HARNESS=1
  • Modèle par défaut : openai/gpt-5.5
  • Sonde d’image optionnelle : OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1
  • Sonde MCP/outil optionnelle : OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1
  • Sonde Guardian optionnelle : OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1
  • Le smoke force la configuration provider/modèle agentRuntime.id: "codex" afin qu’un harnais Codex cassé ne puisse pas passer en se rabattant silencieusement sur PI.
  • Authentification : auth serveur d’application Codex issue de la connexion locale à l’abonnement Codex. Les smokes Docker peuvent aussi fournir OPENAI_API_KEY pour les sondes non Codex lorsque c’est applicable, ainsi que des copies optionnelles 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.5 \
  pnpm test:live -- src/gateway/gateway-codex-harness.live.test.ts
Recette Docker : 
source ~/.profile
pnpm test:docker:live-codex-harness
Notes Docker :
  • Le lanceur 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 de la CLI Codex lorsqu’ils sont présents, installe @openai/codex dans un préfixe npm monté accessible en écriture, prépare l’arborescence source, puis exécute uniquement le test en direct du harnais Codex.
  • Docker active par défaut les sondes d’image, MCP/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 lorsque vous avez besoin d’une exécution de débogage plus étroite.
  • Docker utilise la même configuration d’exécution Codex explicite, de sorte 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 fragiles :
  • Modèle unique, direct (sans gateway) :
    • OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts
  • Modèle unique, smoke gateway :
    • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
  • Appel d’outils sur plusieurs providers :
    • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,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
  • Smoke de réflexion adaptative Google :
    • Si les clés locales se trouvent dans le profil shell : source ~/.profile
    • Valeur par défaut dynamique Gemini 3 : 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 Gemini 2.5 : 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
Notes :
  • google/... utilise l’API Gemini (clé API).
  • google-antigravity/... utilise le pont OAuth Antigravity (point de terminaison d’agent de type Cloud Code Assist).
  • google-gemini-cli/... utilise la CLI Gemini locale 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 (clé API / auth de profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ».
    • CLI : OpenClaw lance un binaire gemini local via le shell ; il a sa propre authentification et peut se comporter différemment (prise en charge du streaming/des outils/décalage de version).

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

Il n’y a pas de « liste de modèles CI » fixe (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)

Il s’agit de l’exécution « modèles courants » que nous voulons maintenir opérationnelle :
  • OpenAI (non Codex) : openai/gpt-5.5
  • OpenAI Codex OAuth : openai-codex/gpt-5.5
  • 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
  • DeepSeek : deepseek/deepseek-v4-flash et deepseek/deepseek-v4-pro
  • Z.AI (GLM) : zai/glm-5.1
  • MiniMax : minimax/MiniMax-M2.7
Exécuter le smoke gateway avec outils + image : OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,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,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts

​
Référence : appel d’outils (Read + Exec optionnel)

Choisissez au moins un modèle par famille de providers :
  • OpenAI : openai/gpt-5.5
  • 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)
  • DeepSeek : deepseek/deepseek-v4-flash
  • Z.AI (GLM) : zai/glm-5.1
  • MiniMax : minimax/MiniMax-M2.7
Couverture supplémentaire optionnelle (utile à avoir) :
  • xAI : xai/grok-4.3 (ou le plus récent disponible)
  • Mistral : mistral/… (choisissez un modèle compatible avec les « tools » que vous avez activé)
  • Cerebras : cerebras/… (si vous 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 (variantes Claude/Gemini/OpenAI compatibles vision, etc.) afin d’exercer la sonde d’image.

​
Agrégateurs / gateways alternatifs

Si vous avez activé les clés, 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.)
Ne codez pas en dur « tous les modèles » dans les docs. La liste faisant autorité est celle que discoverModels(...) retourne sur votre machine, plus les clés disponibles.

​
Identifiants (ne jamais commit)

Les tests en direct découvrent les identifiants de la même manière que la CLI. Implications pratiques :
  • Si la CLI fonctionne, les tests en direct devraient trouver les mêmes clés.
  • Si un test en direct indique « aucune information d’identification », déboguez de la même manière que 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 signifie « clés de profil » dans les tests en direct)
  • Configuration : ~/.openclaw/openclaw.json (ou OPENCLAW_CONFIG_PATH)
  • Répertoire d’état hérité : ~/.openclaw/credentials/ (copié dans le répertoire personnel de test en direct préparé lorsqu’il est présent, mais pas dans le magasin principal des clés de profil)
  • Les exécutions locales en direct copient par défaut la configuration active, les fichiers auth-profiles.json par agent, les anciens credentials/ et les répertoires d’authentification CLI externes pris en charge dans un répertoire personnel de test temporaire ; les répertoires personnels en direct préparés ignorent workspace/ et sandboxes/, et les substitutions de chemin agents.*.workspace / agentDir sont supprimées afin que les sondes restent hors de votre véritable espace de travail hôte.
Si vous voulez vous appuyer sur des clés d’environnement (par exemple exportées dans votre ~/.profile), exécutez les tests locaux après source ~/.profile, ou utilisez les exécuteurs Docker ci-dessous (ils peuvent monter ~/.profile dans le conteneur).

​
Deepgram en direct (transcription audio)

  • Test : extensions/deepgram/audio.live.test.ts
  • Activer : DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live extensions/deepgram/audio.live.test.ts

​
Plan de codage BytePlus en direct

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

​
Médias de workflow ComfyUI en direct

  • Test : extensions/comfy/comfy.live.test.ts
  • Activer : OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts
  • Portée :
    • Exerce les chemins comfy groupés pour l’image, la vidéo et music_generate
    • Ignore chaque capacité sauf si plugins.entries.comfy.config.<capability> est configuré
    • Utile après avoir modifié la soumission de workflow comfy, l’interrogation, les téléchargements ou l’enregistrement du Plugin

​
Génération d’images 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 fournisseur de génération d’images enregistré
    • Charge les variables d’environnement de fournisseur manquantes depuis votre shell de connexion (~/.profile) avant la sonde
    • Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que les clés de test obsolètes dans auth-profiles.json ne masquent pas les véritables identifiants du shell
    • Ignore les fournisseurs sans authentification/profil/modèle utilisable
    • Exécute chaque fournisseur configuré à travers le runtime partagé de génération d’images :
      • <provider>:generate
      • <provider>:edit lorsque le fournisseur déclare la prise en charge de l’édition
  • Fournisseurs groupés actuels 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 forcer l’authentification via le magasin de profils et ignorer les substitutions uniquement par environnement
Pour le chemin CLI livré, ajoutez un smoke infer après la réussite du test en direct fournisseur/runtime : 
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 "Minimal flat test image: one blue square on a white background, no text." \
  --output ./openclaw-infer-image-smoke.png \
  --json
Cela couvre l’analyse des arguments CLI, la résolution de la configuration/de l’agent par défaut, l’activation du Plugin groupé, le runtime partagé de génération d’images et la requête fournisseur en direct. Les dépendances du Plugin doivent être présentes avant le chargement du runtime.

​
Génération de musique en direct

  • Test : extensions/music-generation-providers.live.test.ts
  • Activer : 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 fournisseurs groupés de génération de musique
    • Couvre actuellement Google et MiniMax
    • Charge les variables d’environnement de fournisseur depuis votre shell de connexion (~/.profile) avant la sonde
    • Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que les clés de test obsolètes dans auth-profiles.json ne masquent pas les véritables identifiants du shell
    • Ignore les fournisseurs sans authentification/profil/modèle utilisable
    • Exécute les deux modes de runtime déclarés lorsqu’ils sont disponibles :
      • generate avec une entrée contenant uniquement une invite
      • edit lorsque le fournisseur déclare capabilities.edit.enabled
    • Couverture actuelle de la voie partagée :
      • google : generate, edit
      • minimax : generate
      • comfy : fichier Comfy en direct 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.6"
  • Comportement d’authentification facultatif :
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification via le magasin de profils et ignorer les substitutions uniquement par environnement

​
Génération de vidéo en direct

  • Test : extensions/video-generation-providers.live.test.ts
  • Activer : 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 groupés de génération de vidéo
    • Utilise par défaut le chemin smoke adapté aux publications : fournisseurs non FAL, une requête texte-vers-vidéo par fournisseur, une invite de homard d’une seconde et un plafond d’opération par fournisseur depuis OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS (180000 par défaut)
    • Ignore FAL par défaut, car la latence de file d’attente côté fournisseur 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 de fournisseur depuis votre shell de connexion (~/.profile) avant la sonde
    • Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que les clés de test obsolètes dans auth-profiles.json ne masquent pas les véritables identifiants du shell
    • Ignore les fournisseurs sans authentification/profil/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/modèle sélectionné accepte une entrée d’image locale adossée à un tampon dans le balayage partagé
      • videoToVideo lorsque le fournisseur déclare capabilities.videoToVideo.enabled et que le fournisseur/modèle sélectionné accepte une entrée vidéo locale adossée à un tampon dans le balayage partagé
    • Fournisseurs imageToVideo actuellement déclarés mais ignorés dans le balayage partagé :
      • vydra, car le veo3 groupé est texte uniquement et le kling groupé nécessite une URL d’image distante
    • Couverture Vydra propre au fournisseur :
      • OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts
      • ce fichier exécute le texte-vers-vidéo veo3 ainsi qu’une voie kling qui utilise par défaut un fixture d’URL d’image distante
    • Couverture en direct actuelle de videoToVideo :
      • runway uniquement lorsque le modèle sélectionné est runway/gen4_aleph
    • Fournisseurs videoToVideo actuellement déclarés mais ignorés dans le balayage partagé :
      • alibaba, qwen, xai, car ces chemins nécessitent actuellement des URL de référence distantes http(s) / MP4
      • google, car la voie Gemini/Veo partagée actuelle utilise une entrée locale adossée à un tampon et ce chemin n’est pas accepté dans le balayage partagé
      • openai, car la voie partagée actuelle ne dispose pas de garanties d’accès aux fonctions vidéo inpaint/remix propres à l’organisation
  • 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 chaque fournisseur 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 fournisseur pour une exécution smoke agressive
  • Comportement d’authentification facultatif :
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification via le magasin de profils et ignorer les substitutions uniquement par environnement

​
Harnais médias en direct

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

​
Connexe

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