Zum Hauptinhalt springen
Für Schnellstart, QA-Runner, Unit-/Integration-Suites und Docker-Abläufe siehe Testing. Diese Seite behandelt die Live-Tests (mit Netzwerkzugriff): Modellmatrix, CLI-Backends, ACP und Live-Tests für Medien-Provider sowie die Handhabung von Anmeldedaten.

​
Live: Sweep der Android-Node-Fähigkeiten

  • Test: src/gateway/android-node.capabilities.live.test.ts
  • Skript: pnpm android:test:integration
  • Ziel: jeden aktuell angekündigten Befehl einer verbundenen Android-Node aufrufen und das Vertragsverhalten der Befehle verifizieren.
  • Umfang:
    • Manuelle Einrichtung/Vorbedingungen (die Suite installiert/führt/koppelt die App nicht).
    • Validierung von Gateway-node.invoke Befehl für Befehl für die ausgewählte Android-Node.
  • Erforderliche Vorab-Einrichtung:
    • Android-App bereits mit dem Gateway verbunden und gekoppelt.
    • App im Vordergrund halten.
    • Berechtigungen/Aufnahmebestätigungen für die Fähigkeiten gewähren, die erfolgreich sein sollen.
  • Optionale Zielüberschreibungen:
    • OPENCLAW_ANDROID_NODE_ID oder OPENCLAW_ANDROID_NODE_NAME.
    • OPENCLAW_ANDROID_GATEWAY_URL / OPENCLAW_ANDROID_GATEWAY_TOKEN / OPENCLAW_ANDROID_GATEWAY_PASSWORD.
  • Vollständige Details zur Android-Einrichtung: Android App

​
Live: Modell-Smoke (Profilschlüssel)

Live-Tests sind in zwei Ebenen aufgeteilt, damit Fehler isoliert werden können:
  • „Direktes Modell“ zeigt uns, ob Provider/Modell mit dem angegebenen Schlüssel überhaupt antworten kann.
  • „Gateway-Smoke“ zeigt uns, ob die vollständige Gateway-+Agent-Pipeline für dieses Modell funktioniert (Sitzungen, Verlauf, Tools, Sandbox-Richtlinie usw.).

​
Ebene 1: Direkte Modellvervollständigung (ohne Gateway)

  • Test: src/agents/models.profiles.live.test.ts
  • Ziel:
    • Erkannte Modelle auflisten
    • getApiKeyForModel verwenden, um Modelle auszuwählen, für die Sie Anmeldedaten haben
    • Kleine Vervollständigung pro Modell ausführen (und gezielte Regressionen, wo nötig)
  • Aktivierung:
    • pnpm test:live (oder OPENCLAW_LIVE_TEST=1, wenn Vitest direkt aufgerufen wird)
  • Setzen Sie OPENCLAW_LIVE_MODELS=modern (oder all, Alias für modern), damit diese Suite tatsächlich ausgeführt wird; andernfalls wird sie übersprungen, damit pnpm test:live auf Gateway-Smoke fokussiert bleibt
  • Modellauswahl:
    • OPENCLAW_LIVE_MODELS=modern, um die moderne Allowlist auszuführen (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
    • OPENCLAW_LIVE_MODELS=all ist ein Alias für die moderne Allowlist
    • oder OPENCLAW_LIVE_MODELS="openai/gpt-5.2,openai-codex/gpt-5.2,anthropic/claude-opus-4-6,..." (durch Kommas getrennte Allowlist)
    • Moderne/alle Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setzen Sie OPENCLAW_LIVE_MAX_MODELS=0 für einen vollständigen modernen Sweep oder einen positiven Wert für eine kleinere Obergrenze.
    • Vollständige Sweeps verwenden OPENCLAW_LIVE_TEST_TIMEOUT_MS für das gesamte Timeout des direkten Modelltests. Standard: 60 Minuten.
    • Direkte Modell-Probes laufen standardmäßig mit 20-facher Parallelität; setzen Sie OPENCLAW_LIVE_MODEL_CONCURRENCY, um dies zu überschreiben.
  • Providerauswahl:
    • OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli" (durch Kommas getrennte Allowlist)
  • Woher die Schlüssel kommen:
    • Standardmäßig: Profilspeicher und Fallbacks aus der Umgebung
    • Setzen Sie OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um nur den Profilspeicher zu erzwingen
  • Warum es das gibt:
    • Trennt „Provider-API ist kaputt / Schlüssel ist ungültig“ von „Gateway-Agent-Pipeline ist kaputt“
    • Enthält kleine, isolierte Regressionen (Beispiel: OpenAI-Responses-/Codex-Responses-Reasoning-Replay + Tool-Call-Abläufe)

​
Ebene 2: Gateway- + Dev-Agent-Smoke (das, was „@openclaw“ tatsächlich tut)

  • Test: src/gateway/gateway-models.profiles.live.test.ts
  • Ziel:
    • Ein In-Process-Gateway starten
    • Eine Sitzung agent:dev:* erstellen/patchen (Modellüberschreibung pro Lauf)
    • Modelle mit Schlüsseln durchlaufen und verifizieren:
      • „sinnvolle“ Antwort (ohne Tools)
      • ein echter Tool-Aufruf funktioniert (Read-Probe)
      • optionale zusätzliche Tool-Probes funktionieren (Exec+Read-Probe)
      • OpenAI-Regressionspfade (nur Tool-Call → Follow-up) weiter funktionieren
  • Probe-Details (damit Sie Fehler schnell erklären können):
    • read-Probe: Der Test schreibt eine Nonce-Datei in den Workspace und fordert den Agenten auf, sie zu read und die Nonce zurückzugeben.
    • exec+read-Probe: Der Test fordert den Agenten auf, per exec eine Nonce in eine temporäre Datei zu schreiben und sie dann per read zurückzulesen.
    • Bild-Probe: Der Test hängt ein generiertes PNG an (Katze + zufälliger Code) und erwartet, dass das Modell cat <CODE> zurückgibt.
    • Implementierungsreferenz: src/gateway/gateway-models.profiles.live.test.ts und src/gateway/live-image-probe.ts.
  • Aktivierung:
    • pnpm test:live (oder OPENCLAW_LIVE_TEST=1, wenn Vitest direkt aufgerufen wird)
  • Modellauswahl:
    • Standard: moderne Allowlist (Opus/Sonnet 4.6+, GPT-5.2 + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
    • OPENCLAW_LIVE_GATEWAY_MODELS=all ist ein Alias für die moderne Allowlist
    • Oder setzen Sie OPENCLAW_LIVE_GATEWAY_MODELS="provider/model" (oder eine durch Kommas getrennte Liste), um einzugrenzen
    • Moderne/alle Gateway-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setzen Sie OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 für einen vollständigen modernen Sweep oder einen positiven Wert für eine kleinere Obergrenze.
  • Providerauswahl (vermeiden Sie „OpenRouter alles“):
    • OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax" (durch Kommas getrennte Allowlist)
  • Tool- + Bild-Probes sind in diesem Live-Test immer aktiviert:
    • read-Probe + exec+read-Probe (Tool-Stress)
    • Bild-Probe läuft, wenn das Modell Unterstützung für Bildeingaben ankündigt
    • Ablauf (grob):
      • Der Test erzeugt ein kleines PNG mit „CAT“ + zufälligem Code (src/gateway/live-image-probe.ts)
      • Sendet es über agent attachments: [{ mimeType: "image/png", content: "<base64>" }]
      • Gateway parst Anhänge in images[] (src/gateway/server-methods/agent.ts + src/gateway/chat-attachments.ts)
      • Eingebetteter Agent leitet eine multimodale Benutzernachricht an das Modell weiter
      • Assertion: Antwort enthält cat + den Code (OCR-Toleranz: kleinere Fehler sind erlaubt)
Tipp: Um zu sehen, was Sie auf Ihrem Rechner testen können (und die genauen provider/model-IDs), führen Sie aus: 
openclaw models list
openclaw models list --json

​
Live: CLI-Backend-Smoke (Claude, Codex, Gemini oder andere lokale CLIs)

  • Test: src/gateway/gateway-cli-backend.live.test.ts
  • Ziel: die Gateway-+Agent-Pipeline mit einem lokalen CLI-Backend validieren, ohne Ihre Standardkonfiguration anzutasten.
  • Standards für backend-spezifische Smokes liegen in der Definition cli-backend.ts der jeweiligen zuständigen Extension.
  • Aktivierung:
    • pnpm test:live (oder OPENCLAW_LIVE_TEST=1, wenn Vitest direkt aufgerufen wird)
    • OPENCLAW_LIVE_CLI_BACKEND=1
  • Standards:
    • Standard-Provider/-Modell: claude-cli/claude-sonnet-4-6
    • Befehl/Argumente/Bildverhalten kommen aus den Metadaten des jeweiligen CLI-Backend-Plugins.
  • Überschreibungen (optional):
    • 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, um einen echten Bildanhang zu senden (Pfade werden in den Prompt eingebunden).
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image", um Bilddateipfade als CLI-Argumente statt per Prompt-Einbindung zu übergeben.
    • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat" (oder "list"), um zu steuern, wie Bildargumente übergeben werden, wenn IMAGE_ARG gesetzt ist.
    • OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1, um einen zweiten Turnus zu senden und den Resume-Ablauf zu validieren.
    • OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0, um die standardmäßige Probe für die Kontinuität derselben Sitzung bei Claude Sonnet -> Opus zu deaktivieren (setzen Sie auf 1, um sie zu erzwingen, wenn das ausgewählte Modell ein Wechselziel unterstützt).
Beispiel: 
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
Docker-Rezept: 
pnpm test:docker:live-cli-backend
Docker-Rezepte für einzelne 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
Hinweise:
  • Der Docker-Runner befindet sich unter scripts/test-live-cli-backend-docker.sh.
  • Er führt den Live-CLI-Backend-Smoke innerhalb des Repo-Docker-Images als Benutzer node ohne Root-Rechte aus.
  • Er löst CLI-Smoke-Metadaten aus der zuständigen Extension auf und installiert dann das passende Linux-CLI-Paket (@anthropic-ai/claude-code, @openai/codex oder @google/gemini-cli) in ein zwischengespeichertes beschreibbares Präfix unter OPENCLAW_DOCKER_CLI_TOOLS_DIR (Standard: ~/.cache/openclaw/docker-cli-tools).
  • pnpm test:docker:live-cli-backend:claude-subscription erfordert portable OAuth-Subscription von Claude Code entweder über ~/.claude/.credentials.json mit claudeAiOauth.subscriptionType oder CLAUDE_CODE_OAUTH_TOKEN aus claude setup-token. Es beweist zunächst direkt claude -p in Docker und führt dann zwei Gateway-CLI-Backend-Turnusse aus, ohne Anthropic-API-Key-Umgebungsvariablen beizubehalten. Diese Subscription-Lane deaktiviert standardmäßig Claude-MCP-/Tool- und Bild-Probes, weil Claude die Nutzung von Drittanbieter-Apps derzeit über zusätzliche Nutzungsabrechnung statt über normale Subscription-Plan-Limits routet.
  • Der Live-CLI-Backend-Smoke testet jetzt denselben End-to-End-Ablauf für Claude, Codex und Gemini: Text-Turnus, Bildklassifizierungs-Turnus und dann MCP-cron-Tool-Call, verifiziert über die Gateway-CLI.
  • Der Standard-Smoke von Claude patcht außerdem die Sitzung von Sonnet auf Opus und verifiziert, dass sich die fortgesetzte Sitzung weiterhin an eine frühere Notiz erinnert.

​
Live: ACP-Bind-Smoke (/acp spawn ... --bind here)

  • Test: src/gateway/gateway-acp-bind.live.test.ts
  • Ziel: den echten ACP-Converstion-Bind-Ablauf mit einem Live-ACP-Agenten validieren:
    • /acp spawn <agent> --bind here senden
    • eine synthetische Nachricht-Kanal-Konversation an Ort und Stelle binden
    • auf derselben Konversation ein normales Follow-up senden
    • verifizieren, dass das Follow-up im gebundenen ACP-Sitzungstranskript landet
  • Aktivierung:
    • pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
    • OPENCLAW_LIVE_ACP_BIND=1
  • Standards:
    • ACP-Agenten in Docker: claude,codex,gemini
    • ACP-Agent für direktes pnpm test:live ...: claude
    • Synthetischer Kanal: Konversationskontext im Stil einer Slack-DM
    • ACP-Backend: acpx
  • Überschreibungen:
    • 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
  • Hinweise:
    • Diese Lane verwendet die Gateway-Oberfläche chat.send mit nur für Admins verfügbaren synthetischen Feldern für die Herkunftsroute, damit Tests Nachricht-Kanal-Kontext anhängen können, ohne vorzugeben, extern zuzustellen.
    • Wenn OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND nicht gesetzt ist, verwendet der Test die integrierte Agent-Registry des eingebetteten Plugins acpx für den ausgewählten ACP-Harness-Agenten.
Beispiel: 
OPENCLAW_LIVE_ACP_BIND=1 \
  OPENCLAW_LIVE_ACP_BIND_AGENT=claude \
  pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
Docker-Rezept: 
pnpm test:docker:live-acp-bind
Docker-Rezepte für einzelne Agenten: 
pnpm test:docker:live-acp-bind:claude
pnpm test:docker:live-acp-bind:codex
pnpm test:docker:live-acp-bind:gemini
Docker-Hinweise:
  • Der Docker-Runner befindet sich unter scripts/test-live-acp-bind-docker.sh.
  • Standardmäßig führt er den ACP-Bind-Smoke nacheinander gegen alle unterstützten Live-CLI-Agenten aus: claude, codex, dann gemini.
  • Verwenden Sie OPENCLAW_LIVE_ACP_BIND_AGENTS=claude, OPENCLAW_LIVE_ACP_BIND_AGENTS=codex oder OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini, um die Matrix einzugrenzen.
  • Er lädt ~/.profile, stellt das passende CLI-Authentifizierungsmaterial in den Container bereit, installiert acpx in ein beschreibbares npm-Präfix und installiert dann die angeforderte Live-CLI (@anthropic-ai/claude-code, @openai/codex oder @google/gemini-cli), falls sie fehlt.
  • Innerhalb von Docker setzt der Runner OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx, sodass acpx die Provider-Umgebungsvariablen aus dem geladenen Profil für die untergeordnete Harness-CLI verfügbar hält.

​
Live: Smoke des Codex-App-Server-Harness

  • Ziel: das Plugin-eigene Codex-Harness über die normale Gateway- agent-Methode validieren:
    • das gebündelte Plugin codex laden
    • OPENCLAW_AGENT_RUNTIME=codex auswählen
    • einen ersten Gateway-Agenten-Turnus an openai/gpt-5.2 senden, wobei das Codex-Harness erzwungen wird
    • einen zweiten Turnus an dieselbe OpenClaw-Sitzung senden und verifizieren, dass der App-Server- Thread wiederaufgenommen werden kann
    • /codex status und /codex models über denselben Gateway-Befehlspfad ausführen
    • optional zwei von Guardian geprüfte eskalierte Shell-Probes ausführen: einen harmlosen Befehl, der genehmigt werden sollte, und einen Upload eines gefälschten Secrets, der abgelehnt werden sollte, damit der Agent nachfragt
  • Test: src/gateway/gateway-codex-harness.live.test.ts
  • Aktivierung: OPENCLAW_LIVE_CODEX_HARNESS=1
  • Standardmodell: openai/gpt-5.2
  • Optionale Bild-Probe: OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1
  • Optionale MCP-/Tool-Probe: OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=1
  • Optionale Guardian-Probe: OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=1
  • Der Smoke setzt OPENCLAW_AGENT_HARNESS_FALLBACK=none, damit ein defektes Codex- Harness nicht bestehen kann, indem es stillschweigend auf PI zurückfällt.
  • Auth: Authentifizierung des Codex-App-Servers über den lokalen Codex-Subscription-Login. Docker- Smokes können zusätzlich OPENAI_API_KEY für nicht-Codex-Probes bereitstellen, wo anwendbar, sowie optional kopierte ~/.codex/auth.json und ~/.codex/config.toml.
Lokales Rezept: 
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
Docker-Rezept: 
source ~/.profile
pnpm test:docker:live-codex-harness
Docker-Hinweise:
  • Der Docker-Runner befindet sich unter scripts/test-live-codex-harness-docker.sh.
  • Er lädt das eingebundene ~/.profile, übergibt OPENAI_API_KEY, kopiert Auth-Dateien der Codex-CLI, wenn vorhanden, installiert @openai/codex in ein beschreibbares eingebundenes npm- Präfix, stellt den Quellbaum bereit und führt dann nur den Live-Test des Codex-Harness aus.
  • Docker aktiviert standardmäßig die Bild-, MCP-/Tool- und Guardian-Probes. Setzen Sie OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 oder OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 oder OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0, wenn Sie einen engeren Debug- Lauf benötigen.
  • Docker exportiert außerdem OPENCLAW_AGENT_HARNESS_FALLBACK=none, passend zur Live- Testkonfiguration, sodass veraltete Aliase oder ein PI-Fallback keine Regression im Codex-Harness verbergen können.

​
Empfohlene Live-Rezepte

Enge, explizite Allowlists sind am schnellsten und am wenigsten fehleranfällig:
  • Einzelnes Modell, direkt (ohne Gateway):
    • OPENCLAW_LIVE_MODELS="openai/gpt-5.2" pnpm test:live src/agents/models.profiles.live.test.ts
  • Einzelnes Modell, Gateway-Smoke:
    • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.2" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts
  • Tool Calling über mehrere Provider:
    • 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
  • Google-Fokus (Gemini-API-Schlüssel + Antigravity):
    • Gemini (API-Schlüssel): 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
Hinweise:
  • google/... verwendet die Gemini-API (API-Schlüssel).
  • google-antigravity/... verwendet die Antigravity-OAuth-Bridge (Agenten-Endpunkt im Stil von Cloud Code Assist).
  • google-gemini-cli/... verwendet die lokale Gemini-CLI auf Ihrem Rechner (separate Authentifizierung + Besonderheiten bei Tools).
  • Gemini-API vs. Gemini-CLI:
    • API: OpenClaw ruft die gehostete Gemini-API von Google über HTTP auf (API-Schlüssel / Profil-Authentifizierung); das ist es, was die meisten Nutzer mit „Gemini“ meinen.
    • CLI: OpenClaw shellt zu einer lokalen gemini-Binärdatei aus; sie hat ihre eigene Authentifizierung und kann sich anders verhalten (Streaming/Tool-Unterstützung/Versionsdrift).

​
Live: Modellmatrix (was wir abdecken)

Es gibt keine feste „CI-Modellliste“ (Live ist Opt-in), aber dies sind die empfohlenen Modelle, die regelmäßig auf einem Entwicklerrechner mit Schlüsseln abgedeckt werden sollten.

​
Modernes Smoke-Set (Tool Calling + Bild)

Dies ist der Lauf mit den „gängigen Modellen“, von dem wir erwarten, dass er weiter funktioniert:
  • OpenAI (nicht Codex): openai/gpt-5.2
  • OpenAI Codex OAuth: openai-codex/gpt-5.2
  • Anthropic: anthropic/claude-opus-4-6 (oder anthropic/claude-sonnet-4-6)
  • Google (Gemini API): google/gemini-3.1-pro-preview und google/gemini-3-flash-preview (ältere Gemini-2.x-Modelle vermeiden)
  • Google (Antigravity): google-antigravity/claude-opus-4-6-thinking und google-antigravity/gemini-3-flash
  • Z.AI (GLM): zai/glm-4.7
  • MiniMax: minimax/MiniMax-M2.7
Gateway-Smoke mit Tools + Bild ausführen: 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

​
Baseline: Tool Calling (Read + optional Exec)

Wählen Sie mindestens eines pro Provider-Familie:
  • OpenAI: openai/gpt-5.2
  • Anthropic: anthropic/claude-opus-4-6 (oder anthropic/claude-sonnet-4-6)
  • Google: google/gemini-3-flash-preview (oder google/gemini-3.1-pro-preview)
  • Z.AI (GLM): zai/glm-4.7
  • MiniMax: minimax/MiniMax-M2.7
Optionale zusätzliche Abdeckung (nice to have):
  • xAI: xai/grok-4 (oder die neueste verfügbare Version)
  • Mistral: mistral/… (wählen Sie ein „tools“-fähiges Modell, das Sie aktiviert haben)
  • Cerebras: cerebras/… (wenn Sie Zugriff haben)
  • LM Studio: lmstudio/… (lokal; Tool Calling hängt vom API-Modus ab)

​
Vision: Bild senden (Anhang → multimodale Nachricht)

Nehmen Sie mindestens ein bildfähiges Modell in OPENCLAW_LIVE_GATEWAY_MODELS auf (Claude-/Gemini-/OpenAI-Varianten mit Vision-Unterstützung usw.), um die Bild-Probe auszuführen.

​
Aggregatoren / alternative Gateways

Wenn Sie entsprechende Schlüssel aktiviert haben, unterstützen wir auch Tests über:
  • OpenRouter: openrouter/... (Hunderte von Modellen; verwenden Sie openclaw models scan, um Kandidaten mit Tool-+Bild-Unterstützung zu finden)
  • OpenCode: opencode/... für Zen und opencode-go/... für Go (Authentifizierung über OPENCODE_API_KEY / OPENCODE_ZEN_API_KEY)
Weitere Provider, die Sie in die Live-Matrix aufnehmen können (wenn Sie Anmeldedaten/Konfiguration haben):
  • Integriert: openai, openai-codex, anthropic, google, google-vertex, google-antigravity, google-gemini-cli, zai, openrouter, opencode, opencode-go, xai, groq, cerebras, mistral, github-copilot
  • Über models.providers (benutzerdefinierte Endpunkte): minimax (Cloud/API) sowie jeder OpenAI-/Anthropic-kompatible Proxy (LM Studio, vLLM, LiteLLM usw.)
Tipp: Versuchen Sie nicht, „alle Modelle“ in den Dokumenten fest zu codieren. Die maßgebliche Liste ist das, was discoverModels(...) auf Ihrem Rechner zurückgibt + die verfügbaren Schlüssel.

​
Anmeldedaten (niemals committen)

Live-Tests erkennen Anmeldedaten genauso wie die CLI. Praktische Auswirkungen:
  • Wenn die CLI funktioniert, sollten Live-Tests dieselben Schlüssel finden.
  • Wenn ein Live-Test „keine Anmeldedaten“ meldet, debuggen Sie genauso, wie Sie openclaw models list / Modellauswahl debuggen würden.
  • Auth-Profile pro Agent: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json (das ist es, was „Profilschlüssel“ in den Live-Tests bedeutet)
  • Konfiguration: ~/.openclaw/openclaw.json (oder OPENCLAW_CONFIG_PATH)
  • Veraltetes Zustandsverzeichnis: ~/.openclaw/credentials/ (wird in das vorbereitete Live-Home kopiert, wenn vorhanden, aber nicht in den Hauptspeicher für Profilschlüssel)
  • Lokale Live-Läufe kopieren standardmäßig die aktive Konfiguration, auth-profiles.json-Dateien pro Agent, veraltete credentials/ und unterstützte externe CLI-Auth-Verzeichnisse in ein temporäres Test-Home; vorbereitete Live-Homes überspringen workspace/ und sandboxes/, und Pfadüberschreibungen für agents.*.workspace / agentDir werden entfernt, damit Probes nicht Ihren echten Host-Workspace verwenden.
Wenn Sie auf Umgebungs-Schlüssel vertrauen möchten (z. B. exportiert in Ihrem ~/.profile), führen Sie lokale Tests nach source ~/.profile aus oder verwenden Sie die Docker-Runner unten (sie können ~/.profile in den Container einbinden).

​
Deepgram live (Audio-Transkription)

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

​
BytePlus Coding Plan live

  • Test: extensions/byteplus/live.test.ts
  • Aktivierung: BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live extensions/byteplus/live.test.ts
  • Optionale Modellüberschreibung: BYTEPLUS_CODING_MODEL=ark-code-latest

​
ComfyUI-Workflow-Medien live

  • Test: extensions/comfy/comfy.live.test.ts
  • Aktivierung: OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts
  • Umfang:
    • Führt die gebündelten Bild-, Video- und music_generate-Pfade von comfy aus
    • Überspringt jede Fähigkeit, sofern models.providers.comfy.<capability> nicht konfiguriert ist
    • Nützlich nach Änderungen an comfy-Workflow-Übermittlung, Polling, Downloads oder Plugin-Registrierung

​
Bildgenerierung live

  • Test: test/image-generation.runtime.live.test.ts
  • Befehl: pnpm test:live test/image-generation.runtime.live.test.ts
  • Harness: pnpm test:live:media image
  • Umfang:
    • Ermittelt jedes registrierte Plugin für Bildgenerierungs-Provider
    • Lädt fehlende Provider-Umgebungsvariablen vor der Probe aus Ihrer Login-Shell (~/.profile)
    • Verwendet standardmäßig Live-/Umgebungs-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Anmeldedaten nicht verdecken
    • Überspringt Provider ohne verwendbare Auth/Profile/Modelle
    • Führt die Standardvarianten der Bildgenerierung über die gemeinsame Runtime-Fähigkeit aus:
      • google:flash-generate
      • google:pro-generate
      • google:pro-edit
      • openai:default-generate
  • Derzeit abgedeckte gebündelte Provider:
    • fal
    • google
    • minimax
    • openai
    • openrouter
    • vydra
    • xai
  • Optionale Eingrenzung:
    • 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"
  • Optionales Auth-Verhalten:
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um Auth aus dem Profilspeicher zu erzwingen und reine Überschreibungen aus der Umgebung zu ignorieren

​
Musikgenerierung live

  • Test: extensions/music-generation-providers.live.test.ts
  • Aktivierung: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts
  • Harness: pnpm test:live:media music
  • Umfang:
    • Führt den gemeinsamen gebündelten Pfad für Musikgenerierungs-Provider aus
    • Deckt derzeit Google und MiniMax ab
    • Lädt vor der Probe Provider-Umgebungsvariablen aus Ihrer Login-Shell (~/.profile)
    • Verwendet standardmäßig Live-/Umgebungs-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Anmeldedaten nicht verdecken
    • Überspringt Provider ohne verwendbare Auth/Profile/Modelle
    • Führt beide deklarierten Runtime-Modi aus, wenn verfügbar:
      • generate mit nur Prompt als Eingabe
      • edit, wenn der Provider capabilities.edit.enabled deklariert
    • Aktuelle Abdeckung der gemeinsamen Lane:
      • google: generate, edit
      • minimax: generate
      • comfy: separate Comfy-Live-Datei, nicht dieser gemeinsame Sweep
  • Optionale Eingrenzung:
    • OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"
    • OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"
  • Optionales Auth-Verhalten:
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um Auth aus dem Profilspeicher zu erzwingen und reine Überschreibungen aus der Umgebung zu ignorieren

​
Videogenerierung live

  • Test: extensions/video-generation-providers.live.test.ts
  • Aktivierung: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts
  • Harness: pnpm test:live:media video
  • Umfang:
    • Führt den gemeinsamen gebündelten Pfad für Videogenerierungs-Provider aus
    • Verwendet standardmäßig den release-sicheren Smoke-Pfad: Nicht-FAL-Provider, eine Text-zu-Video-Anfrage pro Provider, ein einsekündiger Hummer-Prompt und eine operationsbezogene Obergrenze pro Provider aus OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS (180000 standardmäßig)
    • Überspringt FAL standardmäßig, weil providerseitige Queue-Latenz die Release-Zeit dominieren kann; übergeben Sie --video-providers fal oder OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal", um es ausdrücklich auszuführen
    • Lädt vor der Probe Provider-Umgebungsvariablen aus Ihrer Login-Shell (~/.profile)
    • Verwendet standardmäßig Live-/Umgebungs-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Anmeldedaten nicht verdecken
    • Überspringt Provider ohne verwendbare Auth/Profile/Modelle
    • Führt standardmäßig nur generate aus
    • Setzen Sie OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1, um bei Verfügbarkeit auch deklarierte Transformationsmodi auszuführen:
      • imageToVideo, wenn der Provider capabilities.imageToVideo.enabled deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep lokal eingebettete Bildeingaben auf Buffer-Basis akzeptiert
      • videoToVideo, wenn der Provider capabilities.videoToVideo.enabled deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep lokal eingebettete Videoeingaben auf Buffer-Basis akzeptiert
    • Derzeit deklarierte, aber im gemeinsamen Sweep übersprungene imageToVideo-Provider:
      • vydra, weil das gebündelte veo3 nur Text unterstützt und das gebündelte kling eine Remote-Bild-URL erfordert
    • Providerspezifische Vydra-Abdeckung:
      • OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts
      • diese Datei führt veo3 Text-zu-Video plus eine kling-Lane aus, die standardmäßig ein Remote-Bild-URL-Fixture verwendet
    • Aktuelle videoToVideo-Live-Abdeckung:
      • nur runway, wenn das ausgewählte Modell runway/gen4_aleph ist
    • Derzeit deklarierte, aber im gemeinsamen Sweep übersprungene videoToVideo-Provider:
      • alibaba, qwen, xai, weil diese Pfade derzeit Remote-Referenz-URLs vom Typ http(s) / MP4 erfordern
      • google, weil die aktuelle gemeinsame Gemini-/Veo-Lane lokal eingebettete Eingaben auf Buffer-Basis verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird
      • openai, weil der aktuellen gemeinsamen Lane Garantien für organisationsspezifischen Zugriff auf Video-Inpaint/Remix fehlen
  • Optionale Eingrenzung:
    • 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="", um jeden Provider in den Standard-Sweep einzuschließen, einschließlich FAL
    • OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000, um die Obergrenze pro Provider-Vorgang für einen aggressiven Smoke-Lauf zu reduzieren
  • Optionales Auth-Verhalten:
    • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um Auth aus dem Profilspeicher zu erzwingen und reine Überschreibungen aus der Umgebung zu ignorieren

​
Medien-Live-Harness

  • Befehl: pnpm test:live:media
  • Zweck:
    • Führt die gemeinsamen Live-Suites für Bild, Musik und Video über einen repo-eigenen Einstiegspunkt aus
    • Lädt fehlende Provider-Umgebungsvariablen automatisch aus ~/.profile
    • Grenzt standardmäßig jede Suite automatisch auf Provider ein, die derzeit verwendbare Authentifizierung haben
    • Verwendet scripts/test-live.mjs erneut, sodass Verhalten von Heartbeat und Quiet Mode konsistent bleibt
  • Beispiele:
    • 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

​
Verwandt

  • Testing — Unit-, Integrations-, QA- und Docker-Suites