Tests: Live-Suites

Für Schnellstart, QA-Runner, Unit-/Integrations-Suites und Docker-Abläufe siehe Tests. Diese Seite behandelt die Live-Testsuites (mit Netzwerkzugriff): Modellmatrix, CLI-Backends, ACP und Live-Tests für Medien-Provider sowie den Umgang mit Zugangsdaten.

# Live: lokale Smoke-Befehle für Profile

Laden Sie ~/.profile vor ad-hoc-Live-Checks, damit Provider-Schlüssel und lokale Tool-Pfade zu Ihrer Shell passen:

source ~/.profile

Sicherer Medien-Smoke-Test:

pnpm openclaw infer tts convert --local --json \
  --text "OpenClaw live smoke." \
  --output /tmp/openclaw-live-smoke.mp3

Sicherer Smoke-Test für die Bereitschaft von Sprachanrufen:

pnpm openclaw voicecall setup --json
pnpm openclaw voicecall smoke --to "+15555550123"

voicecall smoke ist ein Probelauf, sofern nicht zusätzlich --yes vorhanden ist. Verwenden Sie --yes nur, wenn Sie bewusst einen echten Benachrichtigungsanruf auslösen möchten. Für Twilio, Telnyx und Plivo erfordert ein erfolgreicher Bereitschaftscheck eine öffentliche Webhook-URL; nur lokale Loopback-/private Fallbacks werden absichtlich abgelehnt.

# Live: Android-Node-Capability-Sweep

• 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 Befehlsvertragsverhalten prüfen.
• Umfang:
  • Vorbereitete/manuelle Einrichtung (die Suite installiert/startet/koppelt die App nicht).
  • Befehlsweise Gateway-node.invoke-Validierung für die ausgewählte Android-Node.
• Erforderliche Voreinrichtung:
  • Android-App ist bereits mit dem Gateway verbunden und gekoppelt.
  • App bleibt im Vordergrund.
  • Berechtigungen/Einwilligung zur Erfassung sind für die Capabilities erteilt, 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 Android-Einrichtungsdetails: Android-App

# Live: Modell-Smoke-Test (Profilschlüssel)

Live-Tests sind in zwei Ebenen aufgeteilt, damit wir Fehler isolieren können:

• „Direktes Modell“ zeigt uns, ob Provider/Modell mit dem angegebenen Schlüssel überhaupt antworten können.
• „Gateway-Smoke-Test“ zeigt uns, ob die vollständige Gateway+Agent-Pipeline für dieses Modell funktioniert (Sitzungen, Verlauf, Tools, Sandbox-Richtlinie usw.).

# Ebene 1: Direkter Modellabschluss (kein Gateway)

• Test: src/agents/models.profiles.live.test.ts
• Ziel:
  • Erkannte Modelle aufzählen
  • getApiKeyForModel verwenden, um Modelle auszuwählen, für die Sie Zugangsdaten haben
  • Einen kleinen Abschluss 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), um diese Suite tatsächlich auszuführen; andernfalls wird sie übersprungen, damit pnpm test:live auf Gateway-Smoke-Tests fokussiert bleibt.
• Modelle auswählen:
  • OPENCLAW_LIVE_MODELS=modern, um die moderne Allowlist auszuführen (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 ist ein Alias für die moderne Allowlist
  • oder OPENCLAW_LIVE_MODELS="openai/gpt-5.5,openai-codex/gpt-5.5,anthropic/claude-opus-4-6,..." (kommagetrennte Allowlist)
  • Modern/all-Sweeps verwenden standardmäßig eine kuratierte, aussagekräftige Obergrenze; setzen Sie OPENCLAW_LIVE_MAX_MODELS=0 für einen vollständigen modernen Sweep oder eine positive Zahl 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.
• Provider auswählen:
  • OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli" (kommagetrennte Allowlist)
• Herkunft der Schlüssel:
  • Standardmäßig: Profilspeicher und Env-Fallbacks
  • Setzen Sie OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um ausschließlich den Profilspeicher zu erzwingen
• Zweck:
  • Trennt „Provider-API ist defekt / Schlüssel ist ungültig“ von „Gateway-Agent-Pipeline ist defekt“
  • Enthält kleine, isolierte Regressionen (Beispiel: Reasoning-Replay und Tool-Call-Flows für OpenAI Responses/Codex Responses)

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

• Test: src/gateway/gateway-models.profiles.live.test.ts
• Ziel:
  • Ein In-Process-Gateway starten
  • Eine agent:dev:*-Sitzung erstellen/patchen (Modellüberschreibung pro Lauf)
  • Modelle mit Schlüsseln durchlaufen und prüfen:
    • „aussagekräftige“ Antwort (keine Tools)
    • ein echter Tool-Aufruf funktioniert (Read-Probe)
    • optionale zusätzliche Tool-Probes (Exec+Read-Probe)
    • OpenAI-Regressionspfade (nur Tool-Call → Follow-up) funktionieren weiterhin
• Probe-Details (damit Sie Fehler schnell erklären können):
  • read-Probe: Der Test schreibt eine Nonce-Datei in den Arbeitsbereich und fordert den Agent auf, sie mit read zu lesen und die Nonce zurückzugeben.
  • exec+read-Probe: Der Test fordert den Agent auf, mit exec eine Nonce in eine temporäre Datei zu schreiben und sie anschließend mit read zurückzulesen.
  • Bild-Probe: Der Test hängt ein generiertes PNG (Katze + zufälliger Code) an 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)
• Modelle auswählen:
  • Standard: moderne Allowlist (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 ist ein Alias für die moderne Allowlist
  • Oder setzen Sie OPENCLAW_LIVE_GATEWAY_MODELS="provider/model" (oder eine kommagetrennte Liste), um einzugrenzen
  • Modern/all-Gateway-Sweeps verwenden standardmäßig eine kuratierte, aussagekräftige Obergrenze; setzen Sie OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0 für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze.
• Provider auswählen (vermeidet „alles von OpenRouter“):
  • OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax" (kommagetrennte Allowlist)
• Tool- und Bild-Probes sind in diesem Live-Test immer aktiviert:
  • read-Probe + exec+read-Probe (Tool-Belastung)
  • Bild-Probe läuft, wenn das Modell Unterstützung für Bildeingaben ankündigt
  • Ablauf (auf hoher Ebene):
    • Test generiert ein kleines PNG mit „CAT“ + Zufallscode (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 Nutzernachricht an das Modell weiter
    • Assertion: Antwort enthält cat + den Code (OCR-Toleranz: kleinere Fehler erlaubt)

# Live: CLI-Backend-Smoke-Test (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 zu verändern.
• Backend-spezifische Smoke-Standards befinden sich in der cli-backend.ts-Definition des zuständigen Plugins.
• Aktivieren:
  • 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/Args/Bildverhalten stammen aus den Metadaten des zuständigen CLI-Backend-Plugins.
• Überschreibungen (optional):
  • 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, um einen echten Bildanhang zu senden (Pfade werden in den Prompt eingefügt). Docker-Rezepte deaktivieren dies standardmäßig, sofern es nicht ausdrücklich angefordert wird.
  • OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image", um Bilddateipfade als CLI-Argumente statt per Prompt-Injektion 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 eine zweite Runde zu senden und den Resume-Flow zu validieren.
  • OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=1, um sich für die Claude-Sonnet-zu-Opus-Kontinuitätsprobe in derselben Sitzung zu entscheiden, wenn das ausgewählte Modell ein Wechselziel unterstützt. Docker-Rezepte deaktivieren dies standardmäßig zugunsten der aggregierten Zuverlässigkeit.
  • OPENCLAW_LIVE_CLI_BACKEND_MCP_PROBE=1, um sich für die MCP-/Tool-loopback-Probe zu entscheiden. Docker-Rezepte deaktivieren dies standardmäßig, sofern es nicht ausdrücklich angefordert wird.

Beispiel:

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

Günstiger Gemini-MCP-Konfigurations-Smoke-Test:

OPENCLAW_LIVE_TEST=1 \
  pnpm test:live src/agents/cli-runner/bundle-mcp.gemini.live.test.ts

Dies fordert Gemini nicht auf, eine Antwort zu generieren. Es schreibt dieselben Systemeinstellungen, die OpenClaw Gemini übergibt, und führt dann gemini --debug mcp list aus, um nachzuweisen, dass ein gespeicherter transport: "streamable-http"-Server in Geminis HTTP-MCP-Form normalisiert wird und eine Verbindung zu einem lokalen streamable-HTTP-MCP-Server herstellen kann.

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-Test im Repo-Docker-Image als Nicht-Root-Benutzer node aus.
• Er löst CLI-Smoke-Metadaten aus dem zuständigen Plugin auf und installiert anschließend 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-Zugangsdaten für ein Claude-Code-Abonnement, entweder über ~/.claude/.credentials.json mit claudeAiOauth.subscriptionType oder CLAUDE_CODE_OAUTH_TOKEN aus claude setup-token. Es weist zuerst direktes claude -p in Docker nach und führt anschließend zwei Gateway-CLI-Backend-Runden aus, ohne Anthropic-API-Key-Env-Vars beizubehalten. Diese Abonnement-Lane deaktiviert die Claude-MCP-/Tool- und Bild-Probes standardmäßig, weil Claude die Nutzung durch Drittanbieter-Apps derzeit über zusätzliche nutzungsbasierte Abrechnung statt über normale Abonnementplanlimits leitet.
• Der Live-CLI-Backend-Smoke-Test übt nun denselben End-to-End-Flow für Claude, Codex und Gemini aus: Textrunde, Bildklassifizierungsrunde und dann MCP-cron-Tool-Aufruf, der über die Gateway-CLI verifiziert wird.
• Claudes Standard-Smoke-Test patcht die Sitzung außerdem von Sonnet auf Opus und verifiziert, dass die fortgesetzte Sitzung sich weiterhin an eine frühere Notiz erinnert.

# Live: Erreichbarkeit des APNs-HTTP/2-Proxys

• Test: src/infra/push-apns-http2.live.test.ts
• Ziel: durch einen lokalen HTTP-CONNECT-Proxy zum Sandbox-APNs-Endpunkt von Apple tunneln, die APNs-HTTP/2-Validierungsanfrage senden und prüfen, dass Apples echte 403 InvalidProviderToken-Antwort über den Proxy-Pfad zurückkommt.
• Aktivieren:
  • OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_APNS_REACHABILITY=1 pnpm test:live src/infra/push-apns-http2.live.test.ts
• Optionales Timeout:
  • OPENCLAW_LIVE_APNS_TIMEOUT_MS=30000

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

• Test: src/gateway/gateway-acp-bind.live.test.ts
• Ziel: den echten ACP-Conversation-Bind-Ablauf mit einem Live-ACP-Agent validieren:
  • /acp spawn <agent> --bind here senden
  • eine synthetische Message-Channel-Konversation direkt binden
  • eine normale Folgeantwort in derselben Konversation senden
  • verifizieren, dass die Folgeantwort im Transcript der gebundenen ACP-Sitzung landet
• Aktivieren:
  • pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
  • OPENCLAW_LIVE_ACP_BIND=1
• Standardwerte:
  • ACP-Agents in Docker: claude,codex,gemini
  • ACP-Agent für direktes pnpm test:live ...: claude
  • Synthetischer Channel: Slack-DM-artiger Konversationskontext
  • ACP-Backend: acpx
• Overrides:
  • 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
• Hinweise:
  • Diese Lane verwendet die Gateway-Oberfläche chat.send mit synthetischen, nur für Admins vorgesehenen Originating-Route-Feldern, damit Tests Message-Channel-Kontext anhängen können, ohne eine externe Zustellung vorzutäuschen.
  • Wenn OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND nicht gesetzt ist, verwendet der Test die integrierte Agent-Registry des eingebetteten acpx-Plugins für den ausgewählten ACP-Harness-Agent.
  • Die Erstellung des Bound-Session-Cron-MCP erfolgt standardmäßig nach bestem Bemühen, weil externe ACP-Harnesses MCP-Aufrufe abbrechen können, nachdem der Bind-/Image-Nachweis bestanden wurde; setzen Sie OPENCLAW_LIVE_ACP_BIND_REQUIRE_CRON=1, um diese Cron-Prüfung nach dem Binden strikt zu machen.

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 Agents:

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

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 die aggregierten Live-CLI-Agents aus: claude, codex, dann gemini.
• Verwenden Sie OPENCLAW_LIVE_ACP_BIND_AGENTS=claude, OPENCLAW_LIVE_ACP_BIND_AGENTS=codex, OPENCLAW_LIVE_ACP_BIND_AGENTS=droid, OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini oder OPENCLAW_LIVE_ACP_BIND_AGENTS=opencode, um die Matrix einzugrenzen.
• Er liest ~/.profile, stellt das passende CLI-Auth-Material im Container bereit und installiert dann die angeforderte Live-CLI (@anthropic-ai/claude-code, @openai/codex, Factory Droid über https://app.factory.ai/cli, @google/gemini-cli oder opencode-ai), falls sie fehlt. Das ACP-Backend selbst ist das eingebettete Paket acpx/runtime aus dem offiziellen acpx-Plugin.
• Die Droid-Docker-Variante stellt ~/.factory für Einstellungen bereit, leitet FACTORY_API_KEY weiter und benötigt diesen API-Schlüssel, weil lokale Factory-OAuth-/Keyring-Authentifizierung nicht portabel in den Container ist. Sie verwendet den integrierten Registry-Eintrag droid exec --output-format acp von ACPX.
• Die OpenCode-Docker-Variante ist eine strikte Single-Agent-Regressions-Lane. Sie schreibt nach dem Einlesen von ~/.profile ein temporäres Standardmodell OPENCODE_CONFIG_CONTENT aus OPENCLAW_LIVE_ACP_BIND_OPENCODE_MODEL (Standard opencode/kimi-k2.6), und pnpm test:docker:live-acp-bind:opencode erfordert ein gebundenes Assistant-Transcript, statt den generischen Skip nach dem Binden zu akzeptieren.
• Direkte acpx-CLI-Aufrufe sind nur ein manueller/Workaround-Pfad, um Verhalten außerhalb des Gateway zu vergleichen. Der Docker-ACP-Bind-Smoke testet das eingebettete acpx-Runtime-Backend von OpenClaw.

# Live: Codex-App-Server-Harness-Smoke

• Ziel: den Plugin-eigenen Codex-Harness über die normale Gateway-agent-Methode validieren:
  • das gebündelte codex-Plugin laden
  • OPENCLAW_AGENT_RUNTIME=codex auswählen
  • einen ersten Gateway-Agent-Turn an openai/gpt-5.5 senden, wobei der Codex-Harness erzwungen wird
  • einen zweiten Turn an dieselbe OpenClaw-Sitzung senden und verifizieren, dass der App-Server-Thread fortgesetzt 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 Fake-Secret-Upload, der abgelehnt werden sollte, sodass der Agent zurückfragt
• Test: src/gateway/gateway-codex-harness.live.test.ts
• Aktivieren: OPENCLAW_LIVE_CODEX_HARNESS=1
• Standardmodell: openai/gpt-5.5
• Optionale Image-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 verwendet agentRuntime.id: "codex", damit ein defekter Codex-Harness nicht durch stilles Zurückfallen auf PI bestehen kann.
• Auth: Codex-App-Server-Auth aus der lokalen Codex-Abonnement-Anmeldung. Docker-Smokes können außerdem OPENAI_API_KEY für Nicht-Codex-Probes bereitstellen, falls zutreffend, plus 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.5 \
  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 liest das gemountete ~/.profile, übergibt OPENAI_API_KEY, kopiert vorhandene Auth-Dateien der Codex-CLI, installiert @openai/codex in ein beschreibbares, gemountetes npm-Präfix, stellt den Quellbaum bereit und führt dann nur den Codex-Harness-Live-Test aus.
• Docker aktiviert die Image-, MCP-/Tool- und Guardian-Probes standardmäßig. 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 verwendet dieselbe explizite Codex-Runtime-Konfiguration, sodass Legacy-Aliase oder PI-Fallback eine Codex-Harness-Regression nicht verbergen können.

# Empfohlene Live-Rezepte

Enge, explizite Allowlists sind am schnellsten und am wenigsten anfällig für Flakiness:

• Einzelnes Modell, direkt (kein Gateway):

  • OPENCLAW_LIVE_MODELS="openai/gpt-5.5" pnpm test:live src/agents/models.profiles.live.test.ts

• Einzelnes Modell, Gateway-Smoke:

  • OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.5" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts

• Tool Calling über mehrere Provider hinweg:

  • 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

• 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

• Google-Adaptive-Thinking-Smoke:

  • Wenn lokale Schlüssel im Shell-Profil liegen: source ~/.profile
  • Gemini 3, dynamischer Standard: 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
  • Gemini 2.5, dynamisches Budget: 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

Hinweise:

• google/... verwendet die Gemini-API (API-Schlüssel).
• google-antigravity/... verwendet die Antigravity-OAuth-Bridge (Cloud-Code-Assist-artiger Agent-Endpunkt).
• google-gemini-cli/... verwendet die lokale Gemini-CLI auf Ihrem Rechner (separate Authentifizierung + Tooling-Eigenheiten).
• Gemini-API vs. Gemini-CLI:
  • API: OpenClaw ruft Googles gehostete Gemini-API über HTTP auf (API-Schlüssel / Profil-Auth); das ist, was die meisten Nutzer mit „Gemini“ meinen.
  • CLI: OpenClaw ruft ein lokales gemini-Binary per Shell auf; es hat seine eigene Authentifizierung und kann sich anders verhalten (Streaming-/Tool-Unterstützung/Versionsabweichungen).

# Live: Modellmatrix (was wir abdecken)

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

# Moderner Smoke-Satz (Tool Calling + Image)

Dies ist der Lauf für „gängige Modelle“, von dem wir erwarten, dass er funktionsfähig bleibt:

• OpenAI (nicht Codex): openai/gpt-5.5
• OpenAI Codex OAuth: openai-codex/gpt-5.5
• 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
• DeepSeek: deepseek/deepseek-v4-flash und deepseek/deepseek-v4-pro
• Z.AI (GLM): zai/glm-5.1
• MiniMax: minimax/MiniMax-M2.7

Gateway-Smoke mit Tools + Image ausführen: 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

# Baseline: Tool Calling (Read + optional Exec)

Wählen Sie mindestens eines pro Provider-Familie aus:

• OpenAI: openai/gpt-5.5
• 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)
• DeepSeek: deepseek/deepseek-v4-flash
• Z.AI (GLM): zai/glm-5.1
• MiniMax: minimax/MiniMax-M2.7

Optionale zusätzliche Abdeckung (nützlich, wenn vorhanden):

• xAI: xai/grok-4.3 (oder neuestes verfügbares Modell)
• Mistral: mistral/… (wählen Sie ein „tools“-fähiges Modell, das bei Ihnen aktiviert ist)
• Cerebras: cerebras/… (falls Sie Zugriff haben)
• LM Studio: lmstudio/… (lokal; Tool Calling hängt vom API-Modus ab)

# Vision: Image senden (Anhang → multimodale Nachricht)

Nehmen Sie mindestens ein image-fähiges Modell in OPENCLAW_LIVE_GATEWAY_MODELS auf (Claude-/Gemini-/OpenAI-vision-fähige Varianten usw.), um die Image-Probe auszuführen.

# Aggregatoren / alternative Gateways

Wenn Sie Schlüssel aktiviert haben, unterstützen wir auch Tests über:

• OpenRouter: openrouter/... (Hunderte Modelle; verwenden Sie openclaw models scan, um Kandidaten zu finden, die Tools und Images unterstützen)
• OpenCode: opencode/... für Zen und opencode-go/... für Go (Auth über OPENCODE_API_KEY / OPENCODE_ZEN_API_KEY)

Weitere Provider, die Sie in die Live-Matrix aufnehmen können (falls Sie Zugangsdaten/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.)

# Zugangsdaten (niemals committen)

Live-Tests entdecken Zugangsdaten auf dieselbe Weise wie die CLI. Praktische Auswirkungen:

• Wenn die CLI funktioniert, sollten Live-Tests dieselben Schlüssel finden.

• Wenn ein Live-Test „no creds“ meldet, debuggen Sie auf dieselbe Weise, wie Sie openclaw models list / Modellauswahl debuggen würden.

• Auth-Profile pro Agent: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json (das ist mit „Profilschlüssel“ in den Live-Tests gemeint)

• Konfiguration: ~/.openclaw/openclaw.json (oder OPENCLAW_CONFIG_PATH)

• Legacy-State-Verzeichnis: ~/.openclaw/credentials/ (wird in das gestagte Live-Home kopiert, falls vorhanden, aber nicht in den hauptsächlichen Profilschlüssel-Speicher)

• Lokale Live-Läufe kopieren standardmäßig die aktive Konfiguration, auth-profiles.json-Dateien pro Agent, Legacy-credentials/ und unterstützte externe CLI-Auth-Verzeichnisse in ein temporäres Test-Home; gestagte Live-Homes überspringen workspace/ und sandboxes/, und Pfadüberschreibungen für agents.*.workspace / agentDir werden entfernt, damit Probes nicht auf Ihrem echten Host-Workspace laufen.

Wenn Sie sich auf Env-Schlüssel verlassen möchten (z. B. aus Ihrer ~/.profile exportiert), führen Sie lokale Tests nach source ~/.profile aus, oder verwenden Sie die Docker-Runner unten (sie können ~/.profile in den Container einhängen).

# Deepgram live (Audiotranskription)

• Test: extensions/deepgram/audio.live.test.ts
• Aktivieren: 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
• Aktivieren: 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
• Aktivieren: OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts
• Umfang:
  • Übt die gebündelten comfy-Pfade für Bild, Video und music_generate aus
  • Überspringt jede Funktion, sofern plugins.entries.comfy.config.<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:
  • Listet jedes registrierte Bildgenerierungs-Provider-Plugin auf
  • Lädt fehlende Provider-Env-Variablen aus Ihrer Login-Shell (~/.profile) vor dem Probing
  • Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Zugangsdaten nicht verdecken
  • Überspringt Provider ohne nutzbare Auth/Profile/Modell
  • Führt jeden konfigurierten Provider durch die gemeinsame Bildgenerierungs-Runtime:
    • <provider>:generate
    • <provider>:edit, wenn der Provider Edit-Unterstützung deklariert
• Aktuell abgedeckte gebündelte Provider:
  • deepinfra
  • fal
  • google
  • minimax
  • openai
  • openrouter
  • vydra
  • xai
• Optionale Eingrenzung:
  • 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"
• Optionales Auth-Verhalten:
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um Auth aus dem Profilspeicher zu erzwingen und reine Env-Überschreibungen zu ignorieren

Fügen Sie für den ausgelieferten CLI-Pfad einen infer-Smoke hinzu, nachdem der Provider-/Runtime-Live-Test bestanden hat:

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

Dies deckt CLI-Argument-Parsing, Konfigurations-/Default-Agent-Auflösung, Aktivierung gebündelter Plugins, die gemeinsame Bildgenerierungs-Runtime und die Live-Provider-Anfrage ab. Es wird erwartet, dass Plugin-Abhängigkeiten vor dem Laden der Runtime vorhanden sind.

# Musikgenerierung live

• Test: extensions/music-generation-providers.live.test.ts
• Aktivieren: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts
• Harness: pnpm test:live:media music
• Umfang:
  • Übt den gemeinsamen gebündelten Musikgenerierungs-Provider-Pfad aus
  • Deckt aktuell Google und MiniMax ab
  • Lädt Provider-Env-Variablen aus Ihrer Login-Shell (~/.profile) vor dem Probing
  • Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Zugangsdaten nicht verdecken
  • Überspringt Provider ohne nutzbare Auth/Profile/Modell
  • Führt beide deklarierten Runtime-Modi aus, sofern verfügbar:
    • generate mit reiner Prompt-Eingabe
    • edit, wenn der Provider capabilities.edit.enabled deklariert
  • Aktuelle Shared-Lane-Abdeckung:
    • 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.6"
• Optionales Auth-Verhalten:
  • OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1, um Auth aus dem Profilspeicher zu erzwingen und reine Env-Überschreibungen zu ignorieren

# Videogenerierung live

• Test: extensions/video-generation-providers.live.test.ts
• Aktivieren: OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts
• Harness: pnpm test:live:media video
• Umfang:
  • Übt den gemeinsamen gebündelten Videogenerierungs-Provider-Pfad 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 (standardmäßig 180000)
  • Ü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 explizit auszuführen
  • Lädt Provider-Env-Variablen aus Ihrer Login-Shell (~/.profile) vor dem Probing
  • Verwendet standardmäßig Live-/Env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in auth-profiles.json echte Shell-Zugangsdaten nicht verdecken
  • Überspringt Provider ohne nutzbare Auth/Profile/Modell
  • Führt standardmäßig nur generate aus
  • Setzen Sie OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1, um auch deklarierte Transformationsmodi auszuführen, sofern verfügbar:
    • imageToVideo, wenn der Provider capabilities.imageToVideo.enabled deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep pufferbasierte lokale Bildeingabe akzeptiert
    • videoToVideo, wenn der Provider capabilities.videoToVideo.enabled deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep pufferbasierte lokale Videoeingabe akzeptiert
  • Aktuelle deklarierte, aber übersprungene imageToVideo-Provider im gemeinsamen Sweep:
    • vydra, weil das gebündelte veo3 nur Text unterstützt und das gebündelte kling eine Remote-Bild-URL erfordert
  • Provider-spezifische 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 sowie eine kling-Lane aus, die standardmäßig ein Remote-Bild-URL-Fixture verwendet
  • Aktuelle videoToVideo-Live-Abdeckung:
    • runway nur, wenn das ausgewählte Modell runway/gen4_aleph ist
  • Aktuelle deklarierte, aber übersprungene videoToVideo-Provider im gemeinsamen Sweep:
    • alibaba, qwen, xai, weil diese Pfade derzeit Remote-http(s)-/MP4-Referenz-URLs erfordern
    • google, weil die aktuelle gemeinsame Gemini-/Veo-Lane lokale pufferbasierte Eingabe verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird
    • openai, weil der aktuellen gemeinsamen Lane org-spezifische Zugriffsgarantien für Video-Inpainting/-Remixing fehlen
• Optionale Eingrenzung:
  • 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="", um jeden Provider in den Standard-Sweep einzuschließen, einschließlich FAL
  • OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000, um die Obergrenze jeder Provider-Operation 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 Env-Überschreibungen zu ignorieren

# Medien-Live-Harness

• Befehl: pnpm test:live:media
• Zweck:
  • Führt die gemeinsamen Bild-, Musik- und Video-Live-Suites über einen repo-nativen Einstiegspunkt aus
  • Lädt fehlende Provider-Env-Variablen automatisch aus ~/.profile
  • Grenzt standardmäßig jede Suite automatisch auf Provider ein, die aktuell nutzbare Auth haben
  • Verwendet scripts/test-live.mjs erneut, sodass Heartbeat- und Quiet-Mode-Verhalten konsistent bleiben
• 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

• Tests - Unit-, Integrations-, QA- und Docker-Suites