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 tests live (qui touchent au réseau) :
matrice de modèles, backends CLI, ACP et tests live de fournisseurs de médias, ainsi que
la gestion des identifiants.
Live : commandes smoke locales
Exportez la clé fournisseur requise dans l’environnement du processus avant les
vérifications live ponctuelles.
Smoke mé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 un essai à blanc 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 de Webhook publique ; les solutions de repli
locales uniquement en loopback/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, n’exécute ni n’appaire l’application).
- Validation
node.invoke Gateway 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 divisés en deux couches afin d’isoler les défaillances :
- « Modèle direct » nous indique que le fournisseur/modèle peut tout simplement répondre avec la clé donnée.
- « Gateway smoke » nous indique que le pipeline complet gateway+agent fonctionne pour ce modèle (sessions, historique, outils, stratégie de sandbox, etc.).
Couche 1 : complétion directe de 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, small ou all (alias de modern) pour réellement exécuter cette suite ; sinon elle est ignorée afin de garder pnpm test:live concentré 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 5.1, MiniMax M3, Grok 4.3)
OPENCLAW_LIVE_MODELS=small pour exécuter la liste d’autorisation contrainte de petits modèles (routes Qwen 8B/9B compatibles locales, Ollama Gemma, OpenRouter Qwen/GLM et Z.AI GLM)
OPENCLAW_LIVE_MODELS=all est un alias de la liste d’autorisation moderne
- ou
OPENCLAW_LIVE_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,..." (liste d’autorisation séparée par des virgules)
- Les exécutions locales de 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 LAN, personnalisés ou Ollama Cloud.
- Les balayages modern/all et small utilisent par défaut leurs plafonds organisés ; définissez
OPENCLAW_LIVE_MAX_MODELS=0 pour un balayage exhaustif des profils sélectionnés ou un nombre positif pour un plafond plus petit.
- Les balayages exhaustifs utilisent
OPENCLAW_LIVE_TEST_TIMEOUT_MS comme délai d’expiration pour l’ensemble 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)
- Origine des clés :
- Par défaut : magasin de profils et solutions de repli env
- Définissez
OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour imposer le magasin de profils uniquement
- Raison d’être :
- 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 : rejeu de raisonnement OpenAI Responses/Codex Responses + flux d’appels d’outils)
Couche 2 : Gateway + smoke de l’agent dev (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/corriger une session
agent:dev:* (remplacement du modèle par exécution)
- Parcourir les modèles disposant de clés et vérifier :
- réponse « significative » (sans outils)
- une invocation réelle d’outil fonctionne (sonde de lecture)
- sondes d’outils supplémentaires facultatives (sonde exec+lecture)
- 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 avec exec un nonce dans un fichier temporaire, puis de le relire avec read.
- sonde image : le test joint un PNG généré (chat + 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 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 : liste d’autorisation moderne (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, DeepSeek V4, GLM 4.7, MiniMax M3, Grok 4.3)
OPENCLAW_LIVE_GATEWAY_MODELS=small pour exécuter la même liste d’autorisation contrainte de petits modèles via le pipeline complet gateway+agent
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 et small utilisent par défaut leurs plafonds organisés ; définissez
OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 pour un balayage sélectionné exhaustif ou un nombre positif pour un plafond plus petit.
- 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’outil + image sont toujours activées dans ce test live :
- sonde
read + sonde exec+read (stress des outils)
- la sonde 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 (
test/helpers/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 embarqué transmet un message utilisateur multimodal au modèle
- 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 de backend CLI (Claude, Gemini ou autres CLI locales)
- 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 propres au backend résident 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 :
- Fournisseur/modèle par défaut :
claude-cli/claude-sonnet-4-6
- Le comportement commande/arguments/image 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 vraie 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 opter pour la sonde de continuité même session Claude Sonnet -> Opus lorsque le modèle sélectionné prend en charge une cible de bascule. Les recettes Docker la désactivent par défaut pour la fiabilité agrégée.
OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1 pour opter pour la sonde MCP/outil loopback. Les recettes Docker la désactivent par défaut sauf demande explicite.
Exemple :
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
Smoke bon marché de configuration MCP Gemini :
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 HTTP diffusable local.
Recette Docker :
pnpm test:docker:live-cli-backend
Recettes Docker à fournisseur unique :
pnpm test:docker:live-cli-backend:claude
pnpm test:docker:live-cli-backend:claude-subscription
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
node non root.
- Il résout les métadonnées de smoke CLI depuis l’extension 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 à OPENCLAW_DOCKER_CLI_TOOLS_DIR (par défaut : ~/.cache/openclaw/docker-cli-tools).
pnpm test:docker:live-cli-backend:claude-subscription nécessite OAuth portable d’abonnement Claude Code 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 MCP/outil et image Claude, car elle consomme les limites d’utilisation de l’abonnement connecté et Anthropic peut modifier le comportement de facturation et de limitation de débit de Claude Agent SDK / claude -p sans publication OpenClaw.
- Le smoke live de backend CLI exerce désormais le même flux de bout en bout pour Claude 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 vers le 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.
- 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
Live : smoke de 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 en direct :
- envoyer
/acp spawn <agent> --bind here
- lier sur 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 la 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 DM 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@<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 Gateway
chat.send avec des champs d’itinéraire d’origine synthétique réservés à l’administrateur, afin que les tests puissent attacher un contexte de canal de messages sans prétendre effectuer 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 harnais ACP sélectionné.
- La création MCP Cron de session liée est effectuée au mieux 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 à agent unique :
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 restreindre la matrice.
- Il prépare le matériel d’authentification CLI correspondant dans le conteneur, puis installe le CLI en direct demandé (
@anthropic-ai/claude-code, @openai/codex, Factory Droid via https://app.factory.ai/cli, @google/gemini-cli ou opencode-ai) s’il est absent. Le backend ACP lui-même est le package acpx/runtime embarqué provenant du Plugin officiel acpx.
- La variante Docker Droid prépare
~/.factory pour les paramètres, transmet FACTORY_API_KEY et exige cette clé d’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 stricte à agent unique. Elle écrit un modèle par défaut temporaire
OPENCODE_CONFIG_CONTENT depuis OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL (par défaut opencode/kimi-k2.6), 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 en dehors du Gateway. Le smoke Docker de liaison ACP exerce le backend d’exécution acpx embarqué d’OpenClaw.
En direct : smoke du harnais app-server Codex
- Objectif : valider le harnais Codex détenu par le Plugin via la méthode Gateway
agent normale :
- charger le Plugin
codex groupé
- sélectionner
openai/gpt-5.5, qui achemine par défaut les tours d’agent OpenAI via Codex
- envoyer un premier tour d’agent Gateway vers
openai/gpt-5.5 avec le harnais Codex sélectionné
- 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 avec élévation examinées par Guardian : une commande
bénigne qui doit être approuvée et un faux téléversement de secret qui doit être
refusé afin que l’agent redemande
- 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 facultative :
OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1
- Sonde MCP/outil facultative :
OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1
- Sonde Guardian facultative :
OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1
- Le smoke force le fournisseur/modèle
agentRuntime.id: "codex" afin qu’un harnais Codex
cassé ne puisse pas réussir en retombant silencieusement sur OpenClaw.
- Authentification : authentification app-server Codex depuis la connexion à l’abonnement Codex local. Les smokes Docker
peuvent aussi fournir
OPENAI_API_KEY pour les sondes non-Codex le cas échéant,
ainsi que les fichiers copiés facultatifs ~/.codex/auth.json et ~/.codex/config.toml.
Recette locale :
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 :
pnpm test:docker:live-codex-harness
Notes Docker :
- Le lanceur Docker se trouve dans
scripts/test-live-codex-harness-docker.sh.
- Il transmet
OPENAI_API_KEY, copie les fichiers d’authentification 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 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 restreinte.
- Docker utilise la même configuration d’exécution Codex explicite ; les alias hérités ou le
repli OpenClaw ne peuvent donc 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 instables :
-
Modèle unique, direct (sans Gateway) :
OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts
-
Profil direct petit modèle :
OPENCLAW_LIVE_MODELS=small pnpm test:live src/agents/models.profiles.live.test.ts
-
Profil Gateway petit modèle :
OPENCLAW_LIVE_GATEWAY_MODELS=small pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
-
Smoke 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, 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 fournisseurs :
OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,deepseek/deepseek-v4-flash,zai/glm-5.1,minimax/MiniMax-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
-
Smoke direct Z.AI Coding Plan GLM-5.2 :
ZAI_CODING_LIVE_TEST=1 pnpm test:live src/agents/zai.live.test.ts
-
Ciblage 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 raisonnement adaptatif Google :
- 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 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 par Google via HTTP (clé API / authentification de profil) ; c’est ce que la plupart des utilisateurs entendent par « Gemini ».
- CLI : OpenClaw appelle un binaire local
gemini via le shell ; il possède sa propre authentification et peut se comporter différemment (prise en charge du streaming/des outils/décalage de version).
En direct : matrice de modèles (ce que nous couvrons)
Il n’existe pas de « liste de modèles CI » fixe (le direct est à activation explicite), mais voici les modèles recommandés à couvrir régulièrement sur une machine de développement avec des clés.
Ensemble de smoke moderne (appel d’outils + image)
Voici l’exécution des « modèles courants » que nous nous attendons à maintenir fonctionnelle :
- OpenAI (non-Codex) :
openai/gpt-5.5
- OpenAI ChatGPT/Codex OAuth :
openai/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 (éviter 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 (API générale) ou zai/glm-5.2 (Coding Plan)
- MiniMax :
minimax/MiniMax-M3
Exécuter le smoke Gateway avec outils + image :
OPENCLAW_LIVE_GATEWAY_MODELS="openai/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-M3" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
Référence : appel d’outils (Read + Exec facultatif)
Choisissez au moins un modèle par famille de fournisseurs :
- 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 (API générale) ou zai/glm-5.2 (Coding Plan)
- MiniMax :
minimax/MiniMax-M3
Couverture supplémentaire facultative (utile à avoir) :
- xAI :
xai/grok-4.3 (ou le dernier disponible)
- Mistral :
mistral/… (choisissez un modèle compatible « outils » que vous avez 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 (variantes Claude/Gemini/OpenAI compatibles vision, etc.) pour exercer la sonde d’image.
Agrégateurs / passerelles alternatives
Si vous avez des clés activées, nous prenons également 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 fournisseurs que vous pouvez inclure dans la matrice en direct (si vous avez les identifiants/la configuration) :
- Intégré :
openai, 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 la documentation. La liste faisant autorité est celle que discoverModels(...) renvoie sur votre machine, plus les clés disponibles.
Identifiants (ne jamais valider)
Les tests en direct découvrent les identifiants de la même façon que la CLI. Conséquences pratiques :
-
Si la CLI fonctionne, les tests en direct devraient trouver les mêmes clés.
-
Si un test en direct indique « aucun identifiant », déboguez 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 « clés de profil » signifie 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 ce n’est pas 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, le répertoire credentials/ hérité et les répertoires d’authentification de 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 remplacements de chemins agents.*.workspace / agentDir sont supprimés 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, exportez-les avant les tests locaux ou utilisez les
exécuteurs Docker ci-dessous avec un OPENCLAW_PROFILE_FILE explicite.
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
Plan de codage BytePlus en direct
- 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
Médias 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 groupés comfy pour l’image, la vidéo et
music_generate
- Ignore chaque capacité sauf si
plugins.entries.comfy.config.<capability> est configuré
- Utile après des changements touchant la soumission de workflows 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é
- Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
- Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des 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é via 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 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 forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement
Pour le chemin CLI livré, ajoutez un smoke infer une fois que le test en direct du fournisseur/runtime
réussit :
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 de CLI, la résolution de la configuration/de l’agent par défaut, l’activation des
Plugins groupés, le runtime partagé de génération d’images et la requête du 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
- 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é du fournisseur groupé de génération de musique
- Couvre actuellement Google et MiniMax
- Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
- Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des 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 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 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.6"
- Comportement d’authentification facultatif :
OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement
Génération de vidéos 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é du fournisseur groupé de génération de vidéos
- Utilise par défaut le chemin smoke sûr pour la version : fournisseurs non FAL, une requête texte-vers-vidéo par fournisseur, invite d’une seconde avec un homard et plafond d’opération par fournisseur provenant de
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 le temps de publication ; passez
--video-providers fal ou OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal" pour l’exécuter explicitement
- Utilise les variables d’environnement de fournisseur déjà exportées avant les sondes
- Utilise par défaut les clés API en direct/d’environnement avant les profils d’authentification stockés, afin que des 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 aussi 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 basée sur 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 basée sur un tampon dans le balayage partagé
- Fournisseurs
imageToVideo actuellement déclarés mais ignorés dans le balayage partagé :
vydra, car veo3 groupé est uniquement texte et kling groupé nécessite une URL d’image distante
- Couverture Vydra spécifique au fournisseur :
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 dispositif de test avec 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 basée sur 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 à l’édition vidéo 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 lors d’une exécution smoke agressive
- Comportement d’authentification facultatif :
OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1 pour forcer l’authentification par magasin de profils et ignorer les remplacements uniquement par environnement
Harnais média 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 au dépôt
- Utilise les variables d’environnement de fournisseur déjà exportées
- 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