From 3be1fcaf9b1c33eef301a1b7263a1693d3848822 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Wed, 15 Apr 2026 14:50:17 +0000 Subject: [PATCH] chore(i18n): refresh de translations --- docs/de/concepts/dreaming.md | 153 ++- docs/de/concepts/experimental-features.md | 56 + docs/de/concepts/memory-search.md | 120 +- docs/de/concepts/memory.md | 162 +-- docs/de/gateway/configuration-reference.md | 1309 ++++++++++---------- docs/de/gateway/local-models.md | 99 +- docs/de/help/testing.md | 771 ++++++------ docs/de/providers/github-copilot.md | 120 +- docs/de/providers/ollama.md | 214 ++-- docs/de/reference/memory-config.md | 400 +++--- docs/de/reference/wizard.md | 169 ++- docs/de/start/wizard-cli-reference.md | 247 ++-- 12 files changed, 1942 insertions(+), 1878 deletions(-) create mode 100644 docs/de/concepts/experimental-features.md diff --git a/docs/de/concepts/dreaming.md b/docs/de/concepts/dreaming.md index 8cf546e39..bdd788f65 100644 --- a/docs/de/concepts/dreaming.md +++ b/docs/de/concepts/dreaming.md @@ -1,47 +1,47 @@ --- read_when: - - Sie möchten, dass die Speicherhochstufung automatisch ausgeführt wird. - - Sie möchten verstehen, was jede Dreaming-Phase bewirkt. - - Sie möchten die Konsolidierung abstimmen, ohne `MEMORY.md` zu überladen. -summary: Hintergrund-Konsolidierung des Gedächtnisses mit leichten, tiefen und REM-Phasen sowie einem Traumtagebuch -title: Dreaming (experimentell) + - Sie möchten, dass die Gedächtnisförderung automatisch ausgeführt wird + - Sie möchten verstehen, was jede Dreaming-Phase bewirkt + - Sie möchten die Konsolidierung abstimmen, ohne `MEMORY.md` zu verunreinigen +summary: Hintergrundkonsolidierung des Gedächtnisses mit leichten, tiefen und REM-Phasen sowie einem Traumtagebuch +title: Dreaming x-i18n: - generated_at: "2026-04-15T06:21:28Z" + generated_at: "2026-04-15T14:40:29Z" model: gpt-5.4 provider: openai - source_hash: 5882a5068f2eabe54ca9893184e5385330a432b921870c38626399ce11c31e25 + source_hash: a5bcaec80f62e7611ed533094ef1917bd72c885f57252824db910e1f0496adc6 source_path: concepts/dreaming.md workflow: 15 --- -# Dreaming (experimentell) +# Dreaming Dreaming ist das Hintergrundsystem zur Gedächtniskonsolidierung in `memory-core`. -Es hilft OpenClaw dabei, starke kurzfristige Signale in dauerhaftes Gedächtnis zu überführen und -den Prozess dabei nachvollziehbar und überprüfbar zu halten. +Es hilft OpenClaw dabei, starke kurzfristige Signale in dauerhaftes Gedächtnis zu überführen, während +der Prozess nachvollziehbar und überprüfbar bleibt. Dreaming ist **optional** und standardmäßig deaktiviert. ## Was Dreaming schreibt -Dreaming verwaltet zwei Arten von Ausgaben: +Dreaming speichert zwei Arten von Ausgaben: -- **Maschinenzustand** in `memory/.dreams/` (Recall-Speicher, Phasensignale, Ingestion-Prüfpunkte, Sperren). -- **Menschenlesbare Ausgabe** in `DREAMS.md` (oder vorhandener `dreams.md`) und optionale Phasenberichtdateien unter `memory/dreaming//YYYY-MM-DD.md`. +- **Maschinenstatus** in `memory/.dreams/` (Recall-Speicher, Phasensignale, Ingestion-Prüfpunkte, Sperren). +- **Menschenlesbare Ausgabe** in `DREAMS.md` (oder vorhandener `dreams.md`) und optionalen Phasenberichtdateien unter `memory/dreaming//YYYY-MM-DD.md`. -Die langfristige Hochstufung schreibt weiterhin nur nach `MEMORY.md`. +Die langfristige Überführung schreibt weiterhin nur in `MEMORY.md`. ## Phasenmodell -Dreaming verwendet drei zusammenarbeitende Phasen: +Dreaming verwendet drei kooperative Phasen: -| Phase | Zweck | Dauerhafter Schreibvorgang | -| ----- | ------------------------------------------ | -------------------------- | -| Light | Kürzliches kurzfristiges Material sortieren und vorbereiten | Nein | -| Deep | Dauerhafte Kandidaten bewerten und hochstufen | Ja (`MEMORY.md`) | +| Phase | Zweck | Dauerhafter Schreibvorgang | +| ----- | ----------------------------------------- | -------------------------- | +| Light | Aktuelles kurzfristiges Material sortieren und vorbereiten | Nein | +| Deep | Dauerhafte Kandidaten bewerten und überführen | Ja (`MEMORY.md`) | | REM | Über Themen und wiederkehrende Ideen reflektieren | Nein | -Diese Phasen sind interne Implementierungsdetails, keine separaten vom Benutzer konfigurierten +Diese Phasen sind interne Implementierungsdetails, keine separaten benutzerkonfigurierbaren „Modi“. ### Light-Phase @@ -49,19 +49,19 @@ Diese Phasen sind interne Implementierungsdetails, keine separaten vom Benutzer Die Light-Phase nimmt aktuelle tägliche Gedächtnissignale und Recall-Spuren auf, dedupliziert sie und bereitet Kandidatenzeilen vor. -- Liest aus dem kurzfristigen Recall-Zustand, aktuellen täglichen Gedächtnisdateien und redigierten Sitzungs-Transkripten, sofern verfügbar. +- Liest aus dem kurzfristigen Recall-Status, aktuellen täglichen Gedächtnisdateien und redigierten Sitzungsprotokollen, wenn verfügbar. - Schreibt einen verwalteten Block `## Light Sleep`, wenn der Speicher Inline-Ausgabe enthält. -- Zeichnet Verstärkungssignale für das spätere Deep-Ranking auf. -- Schreibt niemals nach `MEMORY.md`. +- Zeichnet Verstärkungssignale für spätere Deep-Bewertung auf. +- Schreibt niemals in `MEMORY.md`. ### Deep-Phase -Die Deep-Phase entscheidet, was Teil des Langzeitgedächtnisses wird. +Die Deep-Phase entscheidet, was zum Langzeitgedächtnis wird. -- Ordnet Kandidaten mithilfe gewichteter Bewertung und Schwellenwert-Gates. -- Erfordert, dass `minScore`, `minRecallCount` und `minUniqueQueries` erfüllt werden. -- Hydriert Snippets vor dem Schreiben aus Live-Tagesdateien erneut, sodass veraltete oder gelöschte Snippets übersprungen werden. -- Hängt hochgestufte Einträge an `MEMORY.md` an. +- Bewertet Kandidaten mithilfe gewichteter Scores und Schwellenwerte. +- Erfordert, dass `minScore`, `minRecallCount` und `minUniqueQueries` erfüllt sind. +- Stellt Snippets vor dem Schreiben aus aktiven Tagesdateien wieder her, sodass veraltete/gelöschte Snippets übersprungen werden. +- Hängt überführte Einträge an `MEMORY.md` an. - Schreibt eine Zusammenfassung `## Deep Sleep` in `DREAMS.md` und schreibt optional `memory/dreaming/deep/YYYY-MM-DD.md`. ### REM-Phase @@ -70,55 +70,55 @@ Die REM-Phase extrahiert Muster und reflektierende Signale. - Erstellt Themen- und Reflexionszusammenfassungen aus aktuellen kurzfristigen Spuren. - Schreibt einen verwalteten Block `## REM Sleep`, wenn der Speicher Inline-Ausgabe enthält. -- Zeichnet REM-Verstärkungssignale auf, die vom Deep-Ranking verwendet werden. -- Schreibt niemals nach `MEMORY.md`. +- Zeichnet REM-Verstärkungssignale auf, die bei der Deep-Bewertung verwendet werden. +- Schreibt niemals in `MEMORY.md`. -## Ingestion von Sitzungs-Transkripten +## Aufnahme von Sitzungsprotokollen -Dreaming kann redigierte Sitzungs-Transkripte in den Dreaming-Korpus aufnehmen. Wenn -Transkripte verfügbar sind, werden sie zusammen mit täglichen -Gedächtnissignalen und Recall-Spuren in die Light-Phase eingespeist. Persönliche und sensible Inhalte werden -vor der Ingestion redigiert. +Dreaming kann redigierte Sitzungsprotokolle in den Dreaming-Korpus aufnehmen. Wenn +Protokolle verfügbar sind, werden sie zusammen mit täglichen +Gedächtnissignalen und Recall-Spuren in die Light-Phase eingespeist. Persönliche und sensible Inhalte werden vor +der Aufnahme redigiert. ## Traumtagebuch Dreaming führt außerdem ein erzählerisches **Traumtagebuch** in `DREAMS.md`. -Sobald nach jeder Phase genügend Material vorhanden ist, führt `memory-core` im Hintergrund nach bestem Bemühen -einen Subagent-Durchlauf aus (unter Verwendung des Standard-Runtime-Modells) und fügt einen kurzen Tagebucheintrag an. +Sobald nach jeder Phase genügend Material vorhanden ist, führt `memory-core` im Hintergrund +einen Best-Effort-Subagent-Durchlauf aus (unter Verwendung des Standard-Laufzeitmodells) und hängt einen kurzen Tagebucheintrag an. -Dieses Tagebuch ist für Menschen in der Dreams-UI gedacht, nicht als Quelle für Hochstufungen. +Dieses Tagebuch ist für Menschen zum Lesen in der Dreams-UI gedacht, nicht als Quelle für Überführungen. Von Dreaming erzeugte Tagebuch-/Berichtsartefakte sind von der kurzfristigen -Hochstufung ausgeschlossen. Nur fundierte Gedächtnis-Snippets kommen für die Hochstufung nach +Überführung ausgeschlossen. Nur fundierte Gedächtnis-Snippets kommen für eine Überführung in `MEMORY.md` infrage. -Es gibt außerdem einen fundierten historischen Backfill-Pfad für Überprüfungs- und Wiederherstellungsarbeiten: +Es gibt außerdem einen fundierten historischen Backfill-Pfad für Prüf- und Wiederherstellungsarbeiten: -- `memory rem-harness --path ... --grounded` zeigt eine Vorschau fundierter Tagebuchausgabe aus historischen `YYYY-MM-DD.md`-Notizen. +- `memory rem-harness --path ... --grounded` zeigt fundierte Tagebuchausgaben aus historischen Notizen `YYYY-MM-DD.md` als Vorschau an. - `memory rem-backfill --path ...` schreibt reversible fundierte Tagebucheinträge in `DREAMS.md`. - `memory rem-backfill --path ... --stage-short-term` stellt fundierte dauerhafte Kandidaten in denselben kurzfristigen Evidenzspeicher bereit, den die normale Deep-Phase bereits verwendet. -- `memory rem-backfill --rollback` und `--rollback-short-term` entfernen diese bereitgestellten Backfill-Artefakte, ohne gewöhnliche Tagebucheinträge oder den aktiven kurzfristigen Recall zu berühren. +- `memory rem-backfill --rollback` und `--rollback-short-term` entfernen diese bereitgestellten Backfill-Artefakte, ohne gewöhnliche Tagebucheinträge oder aktiven kurzfristigen Recall zu berühren. -Die Control UI stellt denselben Tagebuch-Backfill-/Reset-Ablauf bereit, sodass Sie die +Die Control UI stellt denselben Backfill-/Zurücksetzen-Ablauf für das Tagebuch bereit, sodass Sie die Ergebnisse in der Dreams-Szene prüfen können, bevor Sie entscheiden, ob die fundierten Kandidaten -eine Hochstufung verdienen. Die Szene zeigt außerdem einen eigenen fundierten Pfad, damit Sie sehen können, -welche bereitgestellten kurzfristigen Einträge aus historischem Replay stammen, welche hochgestuften -Elemente fundiert gesteuert waren, und nur fundiert bereitgestellte Einträge löschen können, ohne -den gewöhnlichen aktiven kurzfristigen Zustand zu berühren. +eine Überführung verdienen. Die Szene zeigt außerdem einen separaten fundierten Pfad, damit Sie sehen können, +welche bereitgestellten kurzfristigen Einträge aus historischer Wiederholung stammen, welche überführten +Elemente fundiert geführt waren, und nur fundierte bereitgestellte Einträge löschen können, ohne +den gewöhnlichen aktiven kurzfristigen Status zu berühren. -## Deep-Ranking-Signale +## Deep-Bewertungssignale -Das Deep-Ranking verwendet sechs gewichtete Basissignale plus Phasenverstärkung: +Die Deep-Bewertung verwendet sechs gewichtete Basissignale plus Phasenverstärkung: -| Signal | Gewicht | Beschreibung | -| ------------------- | ------ | ------------------------------------------------ | -| Frequency | 0.24 | Wie viele kurzfristige Signale der Eintrag angesammelt hat | -| Relevance | 0.30 | Durchschnittliche Abrufqualität für den Eintrag | -| Query diversity | 0.15 | Unterschiedliche Abfrage-/Tageskontexte, in denen er aufgetaucht ist | -| Recency | 0.15 | Zeitlich abklingender Aktualitätswert | -| Consolidation | 0.10 | Stärke des mehrtägigen Wiederauftretens | -| Conceptual richness | 0.06 | Dichte der Konzept-Tags aus Snippet/Pfad | +| Signal | Gewicht | Beschreibung | +| ------------------- | ------ | ---------------------------------------------- | +| Häufigkeit | 0.24 | Wie viele kurzfristige Signale der Eintrag gesammelt hat | +| Relevanz | 0.30 | Durchschnittliche Abrufqualität für den Eintrag | +| Abfragevielfalt | 0.15 | Unterschiedliche Abfrage-/Tageskontexte, in denen er aufgetaucht ist | +| Aktualität | 0.15 | Zeitlich abklingender Frische-Score | +| Konsolidierung | 0.10 | Stärke des mehrtägigen Wiederauftretens | +| Konzeptioneller Reichtum | 0.06 | Dichte der Konzept-Tags aus Snippet/Pfad | -Treffer aus der Light- und REM-Phase fügen einen kleinen, zeitlich abklingenden Boost aus +Treffer in der Light- und REM-Phase fügen einen kleinen, nach Aktualität abklingenden Boost aus `memory/.dreams/phase-signals.json` hinzu. ## Zeitplanung @@ -126,7 +126,7 @@ Treffer aus der Light- und REM-Phase fügen einen kleinen, zeitlich abklingenden Wenn aktiviert, verwaltet `memory-core` automatisch einen Cron-Job für einen vollständigen Dreaming-Durchlauf. Jeder Durchlauf führt die Phasen der Reihe nach aus: light -> REM -> deep. -Standardverhalten für die Ausführungsfrequenz: +Standardverhalten für die Taktung: | Einstellung | Standard | | ------------------- | ----------- | @@ -152,7 +152,7 @@ Dreaming aktivieren: } ``` -Dreaming mit benutzerdefinierter Durchlauf-Frequenz aktivieren: +Dreaming mit einer benutzerdefinierten Durchlauf-Taktung aktivieren: ```json { @@ -181,9 +181,9 @@ Dreaming mit benutzerdefinierter Durchlauf-Frequenz aktivieren: /dreaming help ``` -## CLI-Ablauf +## CLI-Workflow -Verwenden Sie die CLI-Hochstufung für Vorschau oder manuelles Anwenden: +Verwenden Sie die CLI-Überführung für Vorschau oder manuelle Anwendung: ```bash openclaw memory promote @@ -192,18 +192,18 @@ openclaw memory promote --limit 5 openclaw memory status --deep ``` -Das manuelle `memory promote` verwendet standardmäßig die Schwellenwerte der Deep-Phase, sofern sie -nicht mit CLI-Flags überschrieben werden. +Das manuelle `memory promote` verwendet standardmäßig die Schwellenwerte der Deep-Phase, sofern sie nicht +mit CLI-Flags überschrieben werden. -Erklären, warum ein bestimmter Kandidat hochgestuft würde oder nicht: +Erklären, warum ein bestimmter Kandidat überführt würde oder nicht: ```bash openclaw memory promote-explain "router vlan" openclaw memory promote-explain "router vlan" --json ``` -REM-Reflexionen, Kandidatenwahrheiten und Deep-Hochstufungsausgabe in der Vorschau anzeigen, ohne -etwas zu schreiben: +REM-Reflexionen, Kandidatenwahrheiten und Deep-Überführungsausgabe in der Vorschau anzeigen, ohne +irgendetwas zu schreiben: ```bash openclaw memory rem-harness @@ -222,23 +222,22 @@ Alle Einstellungen befinden sich unter `plugins.entries.memory-core.config.dream Phasenrichtlinie, Schwellenwerte und Speicherverhalten sind interne Implementierungsdetails (keine benutzerseitige Konfiguration). -Siehe [Referenz zur Memory-Konfiguration](/de/reference/memory-config#dreaming-experimental) -für die vollständige Schlüsselliste. +Die vollständige Liste der Schlüssel finden Sie unter [Referenz zur Gedächtniskonfiguration](/de/reference/memory-config#dreaming). ## Dreams-UI Wenn aktiviert, zeigt der Gateway-Tab **Dreams** Folgendes an: -- aktuellen Aktivierungsstatus von Dreaming -- Status auf Phasenebene und Vorhandensein verwalteter Durchläufe -- Zählwerte für kurzfristige, fundierte, Signal- und heute hochgestufte Einträge +- aktuellen Dreaming-Aktivierungsstatus +- Status auf Phasenebene und Vorhandensein eines verwalteten Durchlaufs +- Zähler für kurzfristig, fundiert, Signal und heute überführt - Zeitpunkt des nächsten geplanten Durchlaufs -- einen eigenen fundierten Szenenpfad für bereitgestellte historische Replay-Einträge -- einen ausklappbaren Leser für das Traumtagebuch, gestützt durch `doctor.memory.dreamDiary` +- einen separaten fundierten Szenenpfad für bereitgestellte historische Wiederholungseinträge +- einen ausklappbaren Leser für das Traumtagebuch, der von `doctor.memory.dreamDiary` gestützt wird ## Verwandt -- [Memory](/de/concepts/memory) -- [Memory Search](/de/concepts/memory-search) +- [Gedächtnis](/de/concepts/memory) +- [Gedächtnissuche](/de/concepts/memory-search) - [memory CLI](/cli/memory) -- [Referenz zur Memory-Konfiguration](/de/reference/memory-config) +- [Referenz zur Gedächtniskonfiguration](/de/reference/memory-config) diff --git a/docs/de/concepts/experimental-features.md b/docs/de/concepts/experimental-features.md new file mode 100644 index 000000000..b68e1e040 --- /dev/null +++ b/docs/de/concepts/experimental-features.md @@ -0,0 +1,56 @@ +--- +read_when: + - Sie sehen einen Konfigurationsschlüssel `.experimental` und möchten wissen, ob er stabil ist + - Sie möchten Vorschau-Laufzeitfunktionen ausprobieren, ohne sie mit normalen Standardeinstellungen zu verwechseln + - Sie möchten eine zentrale Stelle finden, an der die derzeit dokumentierten experimentellen Flags aufgeführt sind +summary: Was experimentelle Flags in OpenClaw bedeuten und welche derzeit dokumentiert sind +title: Experimentelle Funktionen +x-i18n: + generated_at: "2026-04-15T14:40:30Z" + model: gpt-5.4 + provider: openai + source_hash: 2d1c7b3d4cd56ef8a0bdab1deb9918e9b2c9a33f956d63193246087f8633dcf3 + source_path: concepts/experimental-features.md + workflow: 15 +--- + +# Experimentelle Funktionen + +Experimentelle Funktionen in OpenClaw sind **optionale Vorschau-Oberflächen**. Sie +stehen hinter expliziten Flags, weil sie noch Praxiserfahrung unter realen +Bedingungen brauchen, bevor sie eine stabile Standardeinstellung oder einen +langlebigen öffentlichen Vertrag verdienen. + +Behandeln Sie sie anders als normale Konfiguration: + +- Lassen Sie sie **standardmäßig deaktiviert**, sofern die zugehörige Dokumentation Sie nicht auffordert, eine auszuprobieren. +- Rechnen Sie damit, dass sich **Form und Verhalten** schneller ändern als bei stabiler Konfiguration. +- Bevorzugen Sie zuerst den stabilen Pfad, wenn bereits einer existiert. +- Wenn Sie OpenClaw breit ausrollen, testen Sie experimentelle Flags zunächst in einer kleineren Umgebung, bevor Sie sie in eine gemeinsame Baseline übernehmen. + +## Derzeit dokumentierte Flags + +| Oberfläche | Schlüssel | Verwenden Sie ihn, wenn | Mehr | +| ----------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | +| Laufzeit für lokale Modelle | `agents.defaults.experimental.localModelLean` | ein kleineres oder strengeres lokales Backend an der vollständigen Standard-Tool-Oberfläche von OpenClaw scheitert | [Lokale Modelle](/de/gateway/local-models) | +| Speichersuche | `agents.defaults.memorySearch.experimental.sessionMemory` | Sie möchten, dass `memory_search` frühere Sitzungsprotokolle indexiert und nehmen die zusätzlichen Speicher- und Indexierungskosten in Kauf | [Referenz zur Speicherkonfiguration](/de/reference/memory-config#session-memory-search-experimental) | +| Strukturiertes Planungstool | `tools.experimental.planTool` | Sie möchten das strukturierte Tool `update_plan` für die Nachverfolgung mehrstufiger Arbeiten in kompatiblen Laufzeiten und UIs verfügbar machen | [Referenz zur Gateway-Konfiguration](/de/gateway/configuration-reference#toolsexperimental) | + +## Lean-Modus für lokale Modelle + +`agents.defaults.experimental.localModelLean: true` ist ein Entlastungsventil +für schwächere Setups mit lokalen Modellen. Es entfernt umfangreiche +Standard-Tools wie `browser`, `cron` und `message`, damit die Prompt-Struktur +kleiner und für Backends mit kleinem Kontext oder strengere +OpenAI-kompatible Backends weniger fragil ist. + +Das ist absichtlich **nicht** der normale Pfad. Wenn Ihr Backend die vollständige +Laufzeit sauber verarbeiten kann, lassen Sie dies deaktiviert. + +## Experimentell bedeutet nicht verborgen + +Wenn eine Funktion experimentell ist, sollte OpenClaw das in der Dokumentation +und im Konfigurationspfad selbst klar sagen. Was es **nicht** tun sollte, ist, +Vorschauverhalten in einen stabil wirkenden Standard-Schalter hineinzuschmuggeln +und so zu tun, als wäre das normal. So werden Konfigurationsoberflächen +unübersichtlich. diff --git a/docs/de/concepts/memory-search.md b/docs/de/concepts/memory-search.md index 900b955dd..81b0a8099 100644 --- a/docs/de/concepts/memory-search.md +++ b/docs/de/concepts/memory-search.md @@ -3,13 +3,13 @@ read_when: - Sie möchten verstehen, wie `memory_search` funktioniert - Sie möchten einen Embedding-Anbieter auswählen - Sie möchten die Suchqualität optimieren -summary: Wie die Speichersuche mit Embeddings und hybrider Retrieval relevante Notizen findet +summary: Wie die Speichersuche mithilfe von Embeddings und hybrider Suche relevante Notizen findet title: Speichersuche x-i18n: - generated_at: "2026-04-12T23:28:14Z" + generated_at: "2026-04-15T14:40:34Z" model: gpt-5.4 provider: openai - source_hash: 71fde251b7d2dc455574aa458e7e09136f30613609ad8dafeafd53b2729a0310 + source_hash: f5757aa8fe8f7fec30ef5c826f72230f591ce4cad591d81a091189d50d4262ed source_path: concepts/memory-search.md workflow: 15 --- @@ -17,21 +17,22 @@ x-i18n: # Speichersuche `memory_search` findet relevante Notizen aus Ihren Speicherdateien, auch wenn -die Formulierung vom ursprünglichen Text abweicht. Dazu wird der Speicher in -kleine Abschnitte indexiert und diese mithilfe von Embeddings, Schlüsselwörtern oder -beidem durchsucht. +die Formulierung vom Originaltext abweicht. Dazu wird der Speicher in kleine +Abschnitte indexiert und diese mit Embeddings, Schlüsselwörtern oder beidem +durchsucht. ## Schnellstart -Wenn Sie einen OpenAI-, Gemini-, Voyage- oder Mistral-API-Schlüssel konfiguriert haben, funktioniert die -Speichersuche automatisch. Um einen Anbieter explizit festzulegen: +Wenn Sie ein GitHub Copilot-Abonnement oder einen konfigurierten API-Schlüssel +für OpenAI, Gemini, Voyage oder Mistral haben, funktioniert die Speichersuche +automatisch. Um einen Anbieter explizit festzulegen: ```json5 { agents: { defaults: { memorySearch: { - provider: "openai", // or "gemini", "local", "ollama", etc. + provider: "openai", // oder "gemini", "local", "ollama" usw. }, }, }, @@ -43,66 +44,76 @@ node-llama-cpp). ## Unterstützte Anbieter -| Anbieter | ID | API-Schlüssel erforderlich | Hinweise | -| -------- | --------- | ------------------------- | ---------------------------------------------------- | -| OpenAI | `openai` | Ja | Automatisch erkannt, schnell | -| Gemini | `gemini` | Ja | Unterstützt Bild-/Audio-Indexierung | -| Voyage | `voyage` | Ja | Automatisch erkannt | -| Mistral | `mistral` | Ja | Automatisch erkannt | -| Bedrock | `bedrock` | Nein | Automatisch erkannt, wenn die AWS-Anmeldeinformationskette aufgelöst wird | -| Ollama | `ollama` | Nein | Lokal, muss explizit festgelegt werden | -| Local | `local` | Nein | GGUF-Modell, Download von ca. 0,6 GB | +| Anbieter | ID | API-Schlüssel erforderlich | Hinweise | +| ---------------- | ---------------- | ------------------------- | ----------------------------------------------------- | +| Bedrock | `bedrock` | Nein | Automatisch erkannt, wenn die AWS-Anmeldedatenkette aufgelöst wird | +| Gemini | `gemini` | Ja | Unterstützt Bild-/Audio-Indexierung | +| GitHub Copilot | `github-copilot` | Nein | Automatisch erkannt, verwendet das Copilot-Abonnement | +| Local | `local` | Nein | GGUF-Modell, Download von ca. 0,6 GB | +| Mistral | `mistral` | Ja | Automatisch erkannt | +| Ollama | `ollama` | Nein | Lokal, muss explizit festgelegt werden | +| OpenAI | `openai` | Ja | Automatisch erkannt, schnell | +| Voyage | `voyage` | Ja | Automatisch erkannt | ## So funktioniert die Suche -OpenClaw führt zwei Retrieval-Pfade parallel aus und führt die Ergebnisse zusammen: +OpenClaw führt zwei Abrufpfade parallel aus und führt die Ergebnisse zusammen: ```mermaid flowchart LR - Q["Query"] --> E["Embedding"] - Q --> T["Tokenize"] - E --> VS["Vector Search"] - T --> BM["BM25 Search"] - VS --> M["Weighted Merge"] + Q["Abfrage"] --> E["Embedding"] + Q --> T["Tokenisieren"] + E --> VS["Vektorsuche"] + T --> BM["BM25-Suche"] + VS --> M["Gewichtete Zusammenführung"] BM --> M - M --> R["Top Results"] + M --> R["Beste Ergebnisse"] ``` -- **Vektorsuche** findet Notizen mit ähnlicher Bedeutung („gateway host“ passt zu - „the machine running OpenClaw“). -- **BM25-Schlüsselwortsuche** findet exakte Übereinstimmungen (IDs, Fehlerzeichenfolgen, Konfigurations- +- **Vektorsuche** findet Notizen mit ähnlicher Bedeutung („Gateway-Host“ passt + zu „der Rechner, auf dem OpenClaw läuft“). +- **BM25-Schlüsselwortsuche** findet exakte Treffer (IDs, Fehlerzeichenfolgen, Konfigurations- schlüssel). -Wenn nur ein Pfad verfügbar ist (keine Embeddings oder kein FTS), wird der andere allein ausgeführt. +Wenn nur ein Pfad verfügbar ist (keine Embeddings oder kein FTS), läuft der +andere allein. -Wenn Embeddings nicht verfügbar sind, verwendet OpenClaw weiterhin lexikalisches Ranking über FTS-Ergebnisse, statt nur auf eine rohe Reihenfolge nach exakter Übereinstimmung zurückzufallen. Dieser degradierte Modus hebt Abschnitte mit stärkerer Abdeckung der Suchbegriffe und relevanten Dateipfaden hervor, wodurch der Recall auch ohne `sqlite-vec` oder einen Embedding-Anbieter nützlich bleibt. +Wenn keine Embeddings verfügbar sind, verwendet OpenClaw weiterhin ein +lexikalisches Ranking über FTS-Ergebnisse, anstatt nur auf die rohe Reihenfolge +exakter Treffer zurückzufallen. Dieser eingeschränkte Modus hebt Abschnitte mit +stärkerer Abdeckung der Abfragebegriffe und relevanten Dateipfaden hervor, +wodurch der Recall auch ohne `sqlite-vec` oder einen Embedding-Anbieter +nützlich bleibt. ## Suchqualität verbessern -Zwei optionale Funktionen helfen, wenn Sie einen großen Notizverlauf haben: +Zwei optionale Funktionen helfen, wenn Sie eine lange Notizenhistorie haben: -### Zeitlicher Zerfall +### Zeitlicher Verfall -Alte Notizen verlieren schrittweise an Ranking-Gewicht, sodass aktuelle Informationen zuerst angezeigt werden. -Mit der Standard-Halbwertszeit von 30 Tagen erreicht eine Notiz vom letzten Monat 50 % -ihres ursprünglichen Gewichts. Dauerhaft relevante Dateien wie `MEMORY.md` unterliegen nie einem Zerfall. +Alte Notizen verlieren schrittweise an Ranking-Gewicht, sodass neuere +Informationen zuerst angezeigt werden. Mit der Standard-Halbwertszeit von 30 +Tagen erreicht eine Notiz vom letzten Monat 50 % ihres ursprünglichen Gewichts. +Evergreen-Dateien wie `MEMORY.md` unterliegen nie dem Verfall. -Aktivieren Sie den zeitlichen Zerfall, wenn Ihr Agent tägliche Notizen über mehrere Monate hat und veraltete -Informationen wiederholt aktuellerem Kontext vorgezogen werden. +Aktivieren Sie den zeitlichen Verfall, wenn Ihr Agent monatelange tägliche +Notizen hat und veraltete Informationen immer wieder höher eingestuft werden als +aktueller Kontext. ### MMR (Diversität) -Verringert redundante Ergebnisse. Wenn fünf Notizen alle dieselbe Router-Konfiguration erwähnen, sorgt MMR -dafür, dass die obersten Ergebnisse unterschiedliche Themen abdecken, statt sich zu wiederholen. +Verringert redundante Ergebnisse. Wenn fünf Notizen dieselbe Router-Konfiguration +erwähnen, sorgt MMR dafür, dass die besten Ergebnisse unterschiedliche Themen +abdecken, anstatt sich zu wiederholen. -Aktivieren Sie MMR, wenn `memory_search` immer wieder nahezu doppelte Ausschnitte aus -verschiedenen täglichen Notizen zurückgibt. +Aktivieren Sie MMR, wenn `memory_search` immer wieder nahezu identische Snippets +aus verschiedenen täglichen Notizen zurückgibt. -### Beides aktivieren +### Beide aktivieren ```json5 { @@ -124,29 +135,30 @@ verschiedenen täglichen Notizen zurückgibt. ## Multimodaler Speicher Mit Gemini Embedding 2 können Sie Bilder und Audiodateien zusammen mit -Markdown indexieren. Suchanfragen bleiben Text, aber sie werden mit visuellen und Audio-Inhalten abgeglichen. Siehe die [Referenz zur Speicherkonfiguration](/de/reference/memory-config) für -die Einrichtung. +Markdown indexieren. Suchanfragen bleiben Text, gleichen aber mit visuellen und +Audioinhalten ab. Informationen zur Einrichtung finden Sie in der +[Referenz zur Speicherkonfiguration](/de/reference/memory-config). -## Sitzungsspeichersuche +## Suche im Sitzungsspeicher -Sie können optional Sitzungsprotokolle indexieren, damit `memory_search` -frühere Gespräche abrufen kann. Dies ist ein Opt-in über -`memorySearch.experimental.sessionMemory`. Weitere Details finden Sie in der +Sie können Sitzungsprotokolle optional indexieren, damit `memory_search` +frühere Gespräche abrufen kann. Dies ist per Opt-in über +`memorySearch.experimental.sessionMemory` verfügbar. Details finden Sie in der [Konfigurationsreferenz](/de/reference/memory-config). ## Fehlerbehebung -**Keine Ergebnisse?** Führen Sie `openclaw memory status` aus, um den Index zu prüfen. Wenn er leer ist, führen Sie -`openclaw memory index --force` aus. +**Keine Ergebnisse?** Führen Sie `openclaw memory status` aus, um den Index zu +prüfen. Falls er leer ist, führen Sie `openclaw memory index --force` aus. -**Nur Schlüsselworttreffer?** Ihr Embedding-Anbieter ist möglicherweise nicht konfiguriert. Prüfen Sie -`openclaw memory status --deep`. +**Nur Schlüsselworttreffer?** Ihr Embedding-Anbieter ist möglicherweise nicht +konfiguriert. Prüfen Sie `openclaw memory status --deep`. **CJK-Text wird nicht gefunden?** Erstellen Sie den FTS-Index mit `openclaw memory index --force` neu. ## Weiterführende Informationen -- [Active Memory](/de/concepts/active-memory) -- Sub-Agent-Speicher für interaktive Chat-Sitzungen -- [Speicher](/de/concepts/memory) -- Dateilayout, Backends, Tools +- [Active Memory](/de/concepts/active-memory) -- Unteragenten-Speicher für interaktive Chat-Sitzungen +- [Memory](/de/concepts/memory) -- Dateilayout, Backends, Tools - [Referenz zur Speicherkonfiguration](/de/reference/memory-config) -- alle Konfigurationsoptionen diff --git a/docs/de/concepts/memory.md b/docs/de/concepts/memory.md index 61406fbbb..0ae5a526a 100644 --- a/docs/de/concepts/memory.md +++ b/docs/de/concepts/memory.md @@ -1,109 +1,83 @@ --- read_when: - Sie möchten verstehen, wie der Speicher funktioniert - - Sie möchten wissen, welche Speicherdateien geschrieben werden -summary: Wie OpenClaw Dinge sitzungsübergreifend behält -title: Überblick über den Speicher + - Sie möchten wissen, welche Speicherdateien geschrieben werden sollen +summary: Wie OpenClaw sich Dinge sitzungsübergreifend merkt +title: Speicherübersicht x-i18n: - generated_at: "2026-04-09T01:27:46Z" + generated_at: "2026-04-15T14:40:27Z" model: gpt-5.4 provider: openai - source_hash: 2fe47910f5bf1c44be379e971c605f1cb3a29befcf2a7ee11fb3833cbe3b9059 + source_hash: ad1adafe1d81f1703d24f48a9c9da2b25a0ebbd4aad4f65d8bde5df78195d55b source_path: concepts/memory.md workflow: 15 --- -# Überblick über den Speicher +# Speicherübersicht -OpenClaw merkt sich Dinge, indem es **einfache Markdown-Dateien** im Workspace -Ihres Agenten schreibt. Das Modell „erinnert“ sich nur an das, was auf der -Festplatte gespeichert wird – es gibt keinen verborgenen Zustand. +OpenClaw merkt sich Dinge, indem es **einfache Markdown-Dateien** im Workspace Ihres Agenten schreibt. Das Modell „erinnert“ sich nur an das, was auf der Festplatte gespeichert wird -- es gibt keinen versteckten Zustand. ## So funktioniert es -Ihr Agent verfügt über drei speicherbezogene Dateien: +Ihr Agent hat drei speicherbezogene Dateien: -- **`MEMORY.md`** – Langzeitspeicher. Dauerhafte Fakten, Präferenzen und - Entscheidungen. Wird zu Beginn jeder DM-Sitzung geladen. -- **`memory/YYYY-MM-DD.md`** – tägliche Notizen. Laufender Kontext und - Beobachtungen. Die Notizen von heute und gestern werden automatisch geladen. -- **`DREAMS.md`** (experimentell, optional) – Traumtagebuch und - Zusammenfassungen der Dreaming-Durchläufe zur menschlichen Überprüfung, - einschließlich fundierter historischer Backfill-Einträge. +- **`MEMORY.md`** -- Langzeitspeicher. Dauerhafte Fakten, Präferenzen und Entscheidungen. Wird zu Beginn jeder DM-Sitzung geladen. +- **`memory/YYYY-MM-DD.md`** -- tägliche Notizen. Laufender Kontext und Beobachtungen. Die Notizen von heute und gestern werden automatisch geladen. +- **`DREAMS.md`** (optional) -- Dream Diary und Zusammenfassungen von Dreaming-Durchläufen zur menschlichen Überprüfung, einschließlich fundierter historischer Backfill-Einträge. -Diese Dateien befinden sich im Agent-Workspace (standardmäßig `~/.openclaw/workspace`). +Diese Dateien befinden sich im Agent-Workspace (Standard: `~/.openclaw/workspace`). -Wenn Sie möchten, dass sich Ihr Agent etwas merkt, sagen Sie es ihm einfach: -„Merke dir, dass ich TypeScript bevorzuge.“ Er schreibt es in die passende -Datei. +Wenn Sie möchten, dass Ihr Agent sich etwas merkt, sagen Sie es ihm einfach: „Merke dir, dass ich TypeScript bevorzuge.“ Er schreibt es in die passende Datei. ## Speicher-Tools -Der Agent hat zwei Tools für die Arbeit mit Speicher: +Der Agent verfügt über zwei Tools für die Arbeit mit Speicher: -- **`memory_search`** – findet relevante Notizen mithilfe semantischer Suche, - auch wenn die Formulierung vom Original abweicht. -- **`memory_get`** – liest eine bestimmte Speicherdatei oder einen - Zeilenbereich. +- **`memory_search`** -- findet relevante Notizen mithilfe semantischer Suche, auch wenn die Formulierung vom Original abweicht. +- **`memory_get`** -- liest eine bestimmte Speicherdatei oder einen bestimmten Zeilenbereich. -Beide Tools werden vom aktiven Speicher-Plugin bereitgestellt -(Standard: `memory-core`). +Beide Tools werden vom aktiven Memory-Plugin bereitgestellt (Standard: `memory-core`). -## Begleit-Plugin „Memory Wiki“ +## Begleit-Plugin Memory Wiki -Wenn sich dauerhafter Speicher eher wie eine gepflegte Wissensdatenbank als -nur wie rohe Notizen verhalten soll, verwenden Sie das gebündelte Plugin -`memory-wiki`. +Wenn sich dauerhafter Speicher eher wie eine gepflegte Wissensdatenbank als nur wie rohe Notizen verhalten soll, verwenden Sie das gebündelte Plugin `memory-wiki`. -`memory-wiki` kompiliert dauerhaftes Wissen in einen Wiki-Vault mit: +`memory-wiki` kompiliert dauerhaftes Wissen in einen Wiki-Tresor mit: - deterministischer Seitenstruktur - strukturierten Aussagen und Belegen -- Verfolgung von Widersprüchen und Aktualität +- Widerspruchs- und Aktualitätsverfolgung - generierten Dashboards -- kompilierten Digests für Agent-/Runtime-Konsumenten +- kompilierten Übersichten für Agent-/Laufzeit-Consumer - wiki-nativen Tools wie `wiki_search`, `wiki_get`, `wiki_apply` und `wiki_lint` -Es ersetzt nicht das aktive Speicher-Plugin. Das aktive Speicher-Plugin ist -weiterhin für Abruf, Promotion und Dreaming zuständig. `memory-wiki` fügt -daneben eine wissensreiche Ebene mit Herkunftsnachweisen hinzu. +Es ersetzt nicht das aktive Memory-Plugin. Das aktive Memory-Plugin bleibt weiterhin für Abruf, Überführung und Dreaming zuständig. `memory-wiki` ergänzt daneben eine wissensschicht mit reicher Herkunftsnachverfolgbarkeit. Siehe [Memory Wiki](/de/plugins/memory-wiki). ## Speichersuche -Wenn ein Embedding-Provider konfiguriert ist, verwendet `memory_search` eine -**hybride Suche** – eine Kombination aus Vektorähnlichkeit (semantische -Bedeutung) und Schlüsselwortabgleich (exakte Begriffe wie IDs und Codesymbole). -Das funktioniert sofort, sobald Sie einen API-Schlüssel für einen -unterstützten Provider haben. +Wenn ein Embedding-Provider konfiguriert ist, verwendet `memory_search` **hybride Suche** -- eine Kombination aus Vektorähnlichkeit (semantische Bedeutung) und Schlüsselwortabgleich (exakte Begriffe wie IDs und Code-Symbole). Das funktioniert sofort, sobald Sie einen API-Schlüssel für einen unterstützten Provider haben. -OpenClaw erkennt Ihren Embedding-Provider automatisch anhand verfügbarer -API-Schlüssel. Wenn Sie einen konfigurierten Schlüssel für OpenAI, Gemini, -Voyage oder Mistral haben, wird die Speichersuche automatisch aktiviert. +OpenClaw erkennt Ihren Embedding-Provider automatisch anhand verfügbarer API-Schlüssel. Wenn Sie einen OpenAI-, Gemini-, Voyage- oder Mistral-Schlüssel konfiguriert haben, ist die Speichersuche automatisch aktiviert. -Einzelheiten dazu, wie die Suche funktioniert, zu Abstimmungsoptionen und zur -Provider-Einrichtung finden Sie unter -[Memory Search](/de/concepts/memory-search). +Einzelheiten dazu, wie die Suche funktioniert, zu Abstimmungsoptionen und zur Provider-Einrichtung finden Sie unter [Memory Search](/de/concepts/memory-search). ## Speicher-Backends -SQLite-basiert. Funktioniert sofort mit Schlüsselwortsuche, Vektorähnlichkeit -und hybrider Suche. Keine zusätzlichen Abhängigkeiten. +SQLite-basiert. Funktioniert sofort mit Schlüsselwortsuche, Vektorähnlichkeit und hybrider Suche. Keine zusätzlichen Abhängigkeiten. -Lokaler Sidecar mit Reranking, Query-Erweiterung und der Möglichkeit, -Verzeichnisse außerhalb des Workspace zu indizieren. +Local-first-Sidecar mit Reranking, Query-Erweiterung und der Möglichkeit, Verzeichnisse außerhalb des Workspace zu indexieren. -KI-nativer sitzungsübergreifender Speicher mit Benutzermodellierung, -semantischer Suche und Multi-Agent-Unterstützung. Plugin-Installation. +KI-native sitzungsübergreifende Erinnerung mit Benutzermodellierung, semantischer Suche und Multi-Agent-Bewusstsein. Plugin-Installation. @@ -111,58 +85,39 @@ semantischer Suche und Multi-Agent-Unterstützung. Plugin-Installation. -Kompiliert dauerhaften Speicher in einen herkunftsreichen Wiki-Vault mit -Aussagen, Dashboards, Bridge-Modus und Obsidian-freundlichen Workflows. +Kompiliert dauerhaften Speicher in einen Wiki-Tresor mit reichhaltiger Herkunftsnachverfolgbarkeit, mit Aussagen, Dashboards, Bridge-Modus und Obsidian-freundlichen Workflows. ## Automatische Speicherleerung -Bevor [Kompaktierung](/de/concepts/compaction) Ihre Unterhaltung zusammenfasst, -führt OpenClaw einen stillen Turn aus, der den Agenten daran erinnert, -wichtigen Kontext in Speicherdateien zu speichern. Dies ist standardmäßig -aktiviert – Sie müssen nichts konfigurieren. +Bevor [Compaction](/de/concepts/compaction) Ihre Unterhaltung zusammenfasst, führt OpenClaw einen stillen Turn aus, der den Agenten daran erinnert, wichtigen Kontext in Speicherdateien zu speichern. Dies ist standardmäßig aktiviert -- Sie müssen nichts konfigurieren. -Die Speicherleerung verhindert Kontextverlust während der Kompaktierung. Wenn -Ihr Agent wichtige Fakten in der Unterhaltung hat, die noch nicht in eine Datei -geschrieben wurden, werden sie automatisch gespeichert, bevor die -Zusammenfassung erfolgt. +Die Speicherleerung verhindert Kontextverlust während der Compaction. Wenn Ihr Agent wichtige Fakten in der Unterhaltung hat, die noch nicht in eine Datei geschrieben wurden, werden sie automatisch gespeichert, bevor die Zusammenfassung erfolgt. -## Dreaming (experimentell) +## Dreaming -Dreaming ist ein optionaler Hintergrunddurchlauf zur Konsolidierung von -Speicher. Es sammelt kurzfristige Signale, bewertet Kandidaten und überführt nur -qualifizierte Elemente in den Langzeitspeicher (`MEMORY.md`). +Dreaming ist ein optionaler Hintergrunddurchlauf zur Konsolidierung von Speicher. Dabei werden kurzfristige Signale gesammelt, Kandidaten bewertet und nur qualifizierte Elemente in den Langzeitspeicher (`MEMORY.md`) übernommen. -Es wurde entwickelt, um den Langzeitspeicher signalstark zu halten: +Es ist darauf ausgelegt, den Langzeitspeicher signalstark zu halten: - **Opt-in**: standardmäßig deaktiviert. -- **Geplant**: wenn aktiviert, verwaltet `memory-core` automatisch einen - wiederkehrenden Cron-Job für einen vollständigen Dreaming-Durchlauf. -- **Schwellenwertbasiert**: Promotions müssen Gates für Punktzahl, - Abruffrequenz und Abfragevielfalt bestehen. -- **Überprüfbar**: Phasenzusammenfassungen und Tagebucheinträge werden zur - menschlichen Überprüfung in `DREAMS.md` geschrieben. +- **Geplant**: wenn aktiviert, verwaltet `memory-core` automatisch einen wiederkehrenden Cron-Job für einen vollständigen Dreaming-Durchlauf. +- **Schwellenwertbasiert**: Übernahmen müssen Grenzwerte für Punktzahl, Abruffrequenz und Query-Diversität erfüllen. +- **Überprüfbar**: Phasenzusammenfassungen und Tagebucheinträge werden zur menschlichen Überprüfung in `DREAMS.md` geschrieben. -Details zum Phasenverhalten, zu Bewertungssignalen und zum Traumtagebuch finden -Sie unter [Dreaming (experimental)](/de/concepts/dreaming). +Weitere Informationen zum Phasenverhalten, zu Bewertungssignalen und zu Dream-Diary-Details finden Sie unter [Dreaming](/de/concepts/dreaming). -## Fundiertes Backfill und Live-Promotion +## Fundierter Backfill und Live-Überführung -Das Dreaming-System hat jetzt zwei eng verwandte Überprüfungspfade: +Das Dreaming-System verfügt jetzt über zwei eng verwandte Prüfpfade: -- **Live Dreaming** arbeitet mit dem kurzfristigen Dreaming-Speicher unter - `memory/.dreams/` und wird von der normalen tiefen Phase verwendet, wenn - entschieden wird, was in `MEMORY.md` übernommen werden kann. -- **Fundiertes Backfill** liest historische Notizen aus - `memory/YYYY-MM-DD.md` als eigenständige Tagesdateien und schreibt - strukturierten Überprüfungsausgabe in `DREAMS.md`. +- **Live Dreaming** arbeitet mit dem kurzfristigen Dreaming-Speicher unter `memory/.dreams/` und wird von der normalen Deep-Phase verwendet, wenn entschieden wird, was in `MEMORY.md` übernommen werden kann. +- **Fundierter Backfill** liest historische Notizen aus `memory/YYYY-MM-DD.md` als eigenständige Tagesdateien und schreibt strukturierte Prüfausgaben in `DREAMS.md`. -Fundiertes Backfill ist nützlich, wenn Sie ältere Notizen erneut durchlaufen und -prüfen möchten, was das System für dauerhaft hält, ohne `MEMORY.md` manuell zu -bearbeiten. +Fundierter Backfill ist nützlich, wenn Sie ältere Notizen erneut abspielen und prüfen möchten, was das System für dauerhaft hält, ohne `MEMORY.md` manuell zu bearbeiten. Wenn Sie Folgendes verwenden: @@ -170,17 +125,13 @@ Wenn Sie Folgendes verwenden: openclaw memory rem-backfill --path ./memory --stage-short-term ``` -werden die fundierten dauerhaften Kandidaten nicht direkt übernommen. Sie werden -in denselben kurzfristigen Dreaming-Speicher eingestuft, den die normale tiefe -Phase bereits verwendet. Das bedeutet: +werden die fundierten dauerhaften Kandidaten nicht direkt übernommen. Sie werden in denselben kurzfristigen Dreaming-Speicher eingestuft, den die normale Deep-Phase bereits verwendet. Das bedeutet: - `DREAMS.md` bleibt die Oberfläche für die menschliche Überprüfung. - der kurzfristige Speicher bleibt die maschinenseitige Oberfläche für das Ranking. -- `MEMORY.md` wird weiterhin nur durch tiefe Promotion geschrieben. +- `MEMORY.md` wird weiterhin nur durch Deep-Überführung geschrieben. -Wenn Sie entscheiden, dass die Wiederholung nicht nützlich war, können Sie die -bereitgestellten Artefakte entfernen, ohne gewöhnliche Tagebucheinträge oder den -normalen Abrufstatus zu berühren: +Wenn Sie entscheiden, dass das erneute Abspielen nicht nützlich war, können Sie die eingestuften Artefakte entfernen, ohne gewöhnliche Tagebucheinträge oder den normalen Abrufzustand zu verändern: ```bash openclaw memory rem-backfill --rollback @@ -192,18 +143,17 @@ openclaw memory rem-backfill --rollback-short-term ```bash openclaw memory status # Indexstatus und Provider prüfen openclaw memory search "query" # Über die Befehlszeile suchen -openclaw memory index --force # Den Index neu erstellen +openclaw memory index --force # Den Index neu aufbauen ``` ## Weiterführende Informationen -- [Builtin Memory Engine](/de/concepts/memory-builtin) – Standard-Backend mit SQLite -- [QMD Memory Engine](/de/concepts/memory-qmd) – erweiterter lokaler Sidecar -- [Honcho Memory](/de/concepts/memory-honcho) – KI-nativer sitzungsübergreifender Speicher -- [Memory Wiki](/de/plugins/memory-wiki) – kompilierter Wissens-Vault und wiki-native Tools -- [Memory Search](/de/concepts/memory-search) – Suchpipeline, Provider und - Abstimmung -- [Dreaming (experimental)](/de/concepts/dreaming) – Hintergrund-Promotion +- [Builtin Memory Engine](/de/concepts/memory-builtin) -- standardmäßiges SQLite-Backend +- [QMD Memory Engine](/de/concepts/memory-qmd) -- fortgeschrittener Local-first-Sidecar +- [Honcho Memory](/de/concepts/memory-honcho) -- KI-native sitzungsübergreifende Erinnerung +- [Memory Wiki](/de/plugins/memory-wiki) -- kompilierter Wissenstresor und wiki-native Tools +- [Memory Search](/de/concepts/memory-search) -- Suchpipeline, Provider und Abstimmung +- [Dreaming](/de/concepts/dreaming) -- Hintergrundüberführung vom kurzfristigen Abruf in den Langzeitspeicher -- [Referenz zur Speicherkonfiguration](/de/reference/memory-config) – alle Konfigurationsoptionen -- [Kompaktierung](/de/concepts/compaction) – wie Kompaktierung mit Speicher interagiert +- [Referenz zur Speicherkonfiguration](/de/reference/memory-config) -- alle Konfigurationsoptionen +- [Compaction](/de/concepts/compaction) -- wie Compaction mit Speicher interagiert diff --git a/docs/de/gateway/configuration-reference.md b/docs/de/gateway/configuration-reference.md index 947e5da49..4e93d8918 100644 --- a/docs/de/gateway/configuration-reference.md +++ b/docs/de/gateway/configuration-reference.md @@ -1,37 +1,37 @@ --- read_when: - - Sie benötigen genaue feldbezogene Konfigurationssemantik oder Standardwerte + - Sie benötigen die genaue feldbezogene Konfigurationssemantik oder Standardwerte - Sie validieren Kanal-, Modell-, Gateway- oder Tool-Konfigurationsblöcke summary: Gateway-Konfigurationsreferenz für zentrale OpenClaw-Schlüssel, Standardwerte und Links zu dedizierten Subsystemreferenzen title: Konfigurationsreferenz x-i18n: - generated_at: "2026-04-11T15:15:58Z" + generated_at: "2026-04-15T14:40:32Z" model: gpt-5.4 provider: openai - source_hash: 351a245bed59d852ea8582e4e9fec5017a5c623cd6f0034766cdea1b5330be3c + source_hash: 7a4da3b41d0304389bd6359aac1185c231e529781b607656ab352f8a8104bdba source_path: gateway/configuration-reference.md workflow: 15 --- # Konfigurationsreferenz -Zentrale Konfigurationsreferenz für `~/.openclaw/openclaw.json`. Eine aufgabenorientierte Übersicht finden Sie unter [Konfiguration](/de/gateway/configuration). +Zentrale Konfigurationsreferenz für `~/.openclaw/openclaw.json`. Eine aufgabenorientierte Übersicht finden Sie unter [Configuration](/de/gateway/configuration). -Diese Seite behandelt die wichtigsten OpenClaw-Konfigurationsbereiche und verweist weiter, wenn ein Subsystem eine eigene, ausführlichere Referenz hat. Sie versucht **nicht**, jeden kanal-/plugin-eigenen Befehlskatalog oder jede tiefe Speicher-/QMD-Einstellung auf einer einzigen Seite inline aufzuführen. +Diese Seite behandelt die wichtigsten OpenClaw-Konfigurationsoberflächen und verlinkt weiterführend, wenn ein Subsystem eine eigene ausführlichere Referenz hat. Sie versucht **nicht**, jeden kanal-/Plugin-eigenen Befehlskatalog oder jede tiefgehende Speicher-/QMD-Einstellung auf einer einzigen Seite einzubetten. -Code-Quelle der Wahrheit: +Code-Quelle: -- `openclaw config schema` gibt das Live-JSON-Schema aus, das für die Validierung und die Control UI verwendet wird, wobei gebündelte Plugin-/Kanal-Metadaten zusammengeführt werden, wenn verfügbar -- `config.schema.lookup` gibt einen einzelnen pfadbezogenen Schemaknoten für Drilldown-Tools zurück -- `pnpm config:docs:check` / `pnpm config:docs:gen` validieren den Baseline-Hash der Konfigurationsdokumentation gegen die aktuelle Schemaoberfläche +- `openclaw config schema` gibt das aktive JSON Schema aus, das für Validierung und Control UI verwendet wird, wobei verfügbare Metadaten aus gebündelten Plugins/Kanälen zusammengeführt werden +- `config.schema.lookup` gibt einen einzelnen pfadbezogenen Schemaknoten für Drill-down-Werkzeuge zurück +- `pnpm config:docs:check` / `pnpm config:docs:gen` validieren den Hash der Konfigurationsdokumentations-Baseline gegen die aktuelle Schemaoberfläche -Dedizierte Detailreferenzen: +Dedizierte ausführliche Referenzen: -- [Speicherkonfigurationsreferenz](/de/reference/memory-config) für `agents.defaults.memorySearch.*`, `memory.qmd.*`, `memory.citations` und Dreaming-Konfiguration unter `plugins.entries.memory-core.config.dreaming` -- [Slash-Befehle](/de/tools/slash-commands) für den aktuellen integrierten + gebündelten Befehlskatalog -- Seiten des jeweiligen Kanal-/Plugin-Eigentümers für kanalspezifische Befehlsoberflächen +- [Memory-Konfigurationsreferenz](/de/reference/memory-config) für `agents.defaults.memorySearch.*`, `memory.qmd.*`, `memory.citations` und Dreaming-Konfiguration unter `plugins.entries.memory-core.config.dreaming` +- [Slash Commands](/de/tools/slash-commands) für den aktuellen integrierten + gebündelten Befehlskatalog +- zugehörige Kanal-/Plugin-Seiten für kanalspezifische Befehlsoberflächen -Das Konfigurationsformat ist **JSON5** (Kommentare + nachgestellte Kommas erlaubt). Alle Felder sind optional — OpenClaw verwendet sichere Standardwerte, wenn sie weggelassen werden. +Das Konfigurationsformat ist **JSON5** (Kommentare + nachgestellte Kommas sind erlaubt). Alle Felder sind optional — OpenClaw verwendet sichere Standardwerte, wenn sie weggelassen werden. --- @@ -46,25 +46,25 @@ Alle Kanäle unterstützen DM-Richtlinien und Gruppenrichtlinien: | DM-Richtlinie | Verhalten | | ------------------- | -------------------------------------------------------------- | | `pairing` (Standard) | Unbekannte Absender erhalten einen einmaligen Pairing-Code; der Eigentümer muss zustimmen | -| `allowlist` | Nur Absender in `allowFrom` (oder gepaarter Allow-Store) | +| `allowlist` | Nur Absender in `allowFrom` (oder gepaartem Allow-Store) | | `open` | Alle eingehenden DMs zulassen (erfordert `allowFrom: ["*"]`) | | `disabled` | Alle eingehenden DMs ignorieren | -| Gruppenrichtlinie | Verhalten | -| --------------------- | ------------------------------------------------------ | +| Gruppenrichtlinie | Verhalten | +| --------------------- | ----------------------------------------------------- | | `allowlist` (Standard) | Nur Gruppen, die der konfigurierten Allowlist entsprechen | | `open` | Gruppen-Allowlists umgehen (Mention-Gating gilt weiterhin) | -| `disabled` | Alle Gruppen-/Raumnachrichten blockieren | +| `disabled` | Alle Gruppen-/Raumnachrichten blockieren | -`channels.defaults.groupPolicy` legt den Standard fest, wenn `groupPolicy` eines Providers nicht gesetzt ist. +`channels.defaults.groupPolicy` legt den Standard fest, wenn die `groupPolicy` eines Anbieters nicht gesetzt ist. Pairing-Codes laufen nach 1 Stunde ab. Ausstehende DM-Pairing-Anfragen sind auf **3 pro Kanal** begrenzt. -Fehlt ein Provider-Block vollständig (`channels.` nicht vorhanden), fällt die Laufzeit-Gruppenrichtlinie auf `allowlist` zurück (fail-closed) und es wird eine Startwarnung ausgegeben. +Wenn ein Anbieterblock vollständig fehlt (`channels.` nicht vorhanden), fällt die Laufzeit-Gruppenrichtlinie auf `allowlist` zurück (fail-closed) und es wird beim Start eine Warnung ausgegeben. ### Kanal-Modellüberschreibungen -Verwenden Sie `channels.modelByChannel`, um bestimmte Kanal-IDs an ein Modell zu binden. Werte akzeptieren `provider/model` oder konfigurierte Modell-Aliasse. Die Kanalzuordnung wird angewendet, wenn eine Sitzung noch keine Modellüberschreibung hat (zum Beispiel durch `/model` gesetzt). +Verwenden Sie `channels.modelByChannel`, um bestimmte Kanal-IDs an ein Modell zu binden. Werte akzeptieren `provider/model` oder konfigurierte Modellaliase. Das Kanal-Mapping wird angewendet, wenn eine Sitzung noch keine Modellüberschreibung hat (zum Beispiel über `/model` gesetzt). ```json5 { @@ -85,9 +85,9 @@ Verwenden Sie `channels.modelByChannel`, um bestimmte Kanal-IDs an ein Modell zu } ``` -### Kanal-Standards und Heartbeat +### Kanalstandards und Heartbeat -Verwenden Sie `channels.defaults` für gemeinsames Gruppenrichtlinien- und Heartbeat-Verhalten über alle Provider hinweg: +Verwenden Sie `channels.defaults` für gemeinsames Gruppenrichtlinien- und Heartbeat-Verhalten über Anbieter hinweg: ```json5 { @@ -105,15 +105,15 @@ Verwenden Sie `channels.defaults` für gemeinsames Gruppenrichtlinien- und Heart } ``` -- `channels.defaults.groupPolicy`: Fallback-Gruppenrichtlinie, wenn eine Provider-spezifische `groupPolicy` nicht gesetzt ist. -- `channels.defaults.contextVisibility`: Standardmodus für die Sichtbarkeit ergänzenden Kontexts für alle Kanäle. Werte: `all` (Standard, allen zitierten/Thread-/Verlaufs-Kontext einschließen), `allowlist` (nur Kontext von zugelassenen Absendern einschließen), `allowlist_quote` (wie allowlist, aber expliziten Zitat-/Antwortkontext beibehalten). Kanalbezogene Überschreibung: `channels..contextVisibility`. -- `channels.defaults.heartbeat.showOk`: Gesunde Kanalstatus in die Heartbeat-Ausgabe aufnehmen. -- `channels.defaults.heartbeat.showAlerts`: Degradierte/Fehlerstatus in die Heartbeat-Ausgabe aufnehmen. +- `channels.defaults.groupPolicy`: Fallback-Gruppenrichtlinie, wenn auf Anbieterebene keine `groupPolicy` gesetzt ist. +- `channels.defaults.contextVisibility`: Standardmodus für die Sichtbarkeit ergänzender Kontexte für alle Kanäle. Werte: `all` (Standard, schließt allen zitierten/Thread-/Verlaufs-Kontext ein), `allowlist` (schließt nur Kontext von Absendern auf der Allowlist ein), `allowlist_quote` (wie allowlist, behält aber expliziten Zitat-/Antwort-Kontext bei). Überschreibung pro Kanal: `channels..contextVisibility`. +- `channels.defaults.heartbeat.showOk`: Gesunde Kanalstatus in der Heartbeat-Ausgabe einschließen. +- `channels.defaults.heartbeat.showAlerts`: Beeinträchtigte/fehlerhafte Status in der Heartbeat-Ausgabe einschließen. - `channels.defaults.heartbeat.useIndicator`: Kompakte Heartbeat-Ausgabe im Indikatorstil rendern. ### WhatsApp -WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet automatisch, wenn eine verknüpfte Sitzung vorhanden ist. +WhatsApp läuft über den Web-Kanal des Gateway (Baileys Web). Er startet automatisch, wenn eine verknüpfte Sitzung vorhanden ist. ```json5 { @@ -124,7 +124,7 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom textChunkLimit: 4000, chunkMode: "length", // length | newline mediaMaxMb: 50, - sendReadReceipts: true, // blaue Häkchen (false im Selbstchat-Modus) + sendReadReceipts: true, // blue ticks (false in self-chat mode) groups: { "*": { requireMention: true }, }, @@ -146,7 +146,7 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom } ``` - + ```json5 { @@ -165,9 +165,9 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom ``` - Ausgehende Befehle verwenden standardmäßig das Konto `default`, falls vorhanden; andernfalls die erste konfigurierte Konto-ID (sortiert). -- Optional überschreibt `channels.whatsapp.defaultAccount` diese Fallback-Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. -- Das Legacy-Baileys-Authentifizierungsverzeichnis für ein einzelnes Konto wird von `openclaw doctor` nach `whatsapp/default` migriert. -- Pro-Konto-Überschreibungen: `channels.whatsapp.accounts..sendReadReceipts`, `channels.whatsapp.accounts..dmPolicy`, `channels.whatsapp.accounts..allowFrom`. +- Das optionale `channels.whatsapp.defaultAccount` überschreibt diese Fallback-Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- Das Legacy-Authentifizierungsverzeichnis für ein einzelnes Baileys-Konto wird von `openclaw doctor` nach `whatsapp/default` migriert. +- Überschreibungen pro Konto: `channels.whatsapp.accounts..sendReadReceipts`, `channels.whatsapp.accounts..dmPolicy`, `channels.whatsapp.accounts..allowFrom`. @@ -226,12 +226,12 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom ``` - Bot-Token: `channels.telegram.botToken` oder `channels.telegram.tokenFile` (nur reguläre Datei; Symlinks werden abgelehnt), mit `TELEGRAM_BOT_TOKEN` als Fallback für das Standardkonto. -- Optional überschreibt `channels.telegram.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. -- In Multi-Konto-Setups (2+ Konto-IDs) sollten Sie einen expliziten Standard setzen (`channels.telegram.defaultAccount` oder `channels.telegram.accounts.default`), um Fallback-Routing zu vermeiden; `openclaw doctor` warnt, wenn dies fehlt oder ungültig ist. +- Das optionale `channels.telegram.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- In Multi-Account-Setups (2+ Konto-IDs) setzen Sie einen expliziten Standard (`channels.telegram.defaultAccount` oder `channels.telegram.accounts.default`), um Fallback-Routing zu vermeiden; `openclaw doctor` warnt, wenn dies fehlt oder ungültig ist. - `configWrites: false` blockiert von Telegram initiierte Konfigurationsschreibvorgänge (Supergroup-ID-Migrationen, `/config set|unset`). -- Top-Level-`bindings[]`-Einträge mit `type: "acp"` konfigurieren persistente ACP-Bindungen für Forenthemen (verwenden Sie das kanonische `chatId:topic:topicId` in `match.peer.id`). Die Feldsemantik wird gemeinsam unter [ACP Agents](/de/tools/acp-agents#channel-specific-settings) beschrieben. +- Top-Level-Einträge in `bindings[]` mit `type: "acp"` konfigurieren persistente ACP-Bindungen für Foren-Themen (verwenden Sie das kanonische `chatId:topic:topicId` in `match.peer.id`). Die Feldsemantik ist gemeinsam in [ACP Agents](/de/tools/acp-agents#channel-specific-settings) definiert. - Telegram-Stream-Vorschauen verwenden `sendMessage` + `editMessageText` (funktioniert in Direkt- und Gruppenchats). -- Retry-Richtlinie: siehe [Retry-Richtlinie](/de/concepts/retry). +- Retry-Richtlinie: siehe [Retry policy](/de/concepts/retry). ### Discord @@ -297,7 +297,7 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom enabled: true, idleHours: 24, maxAgeHours: 0, - spawnSubagentSessions: false, // Opt-in für sessions_spawn({ thread: true }) + spawnSubagentSessions: false, // opt-in for sessions_spawn({ thread: true }) }, voice: { enabled: true, @@ -334,33 +334,33 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom ``` - Token: `channels.discord.token`, mit `DISCORD_BOT_TOKEN` als Fallback für das Standardkonto. -- Direkte ausgehende Aufrufe, die ein explizites Discord-`token` bereitstellen, verwenden dieses Token für den Aufruf; Konto-Retry-/Richtlinieneinstellungen kommen weiterhin vom ausgewählten Konto im aktiven Laufzeit-Snapshot. -- Optional überschreibt `channels.discord.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. -- Verwenden Sie `user:` (DM) oder `channel:` (Guild-Kanal) für Zustellziele; reine numerische IDs werden abgelehnt. +- Direkte ausgehende Aufrufe, die ein explizites Discord-`token` angeben, verwenden dieses Token für den Aufruf; Einstellungen für Konto-Retry/Richtlinien stammen weiterhin aus dem ausgewählten Konto im aktiven Laufzeit-Snapshot. +- Das optionale `channels.discord.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- Verwenden Sie `user:` (DM) oder `channel:` (Guild-Kanal) als Zustellziele; reine numerische IDs werden abgelehnt. - Guild-Slugs sind kleingeschrieben, wobei Leerzeichen durch `-` ersetzt werden; Kanalschlüssel verwenden den Slug-Namen (ohne `#`). Bevorzugen Sie Guild-IDs. - Von Bots verfasste Nachrichten werden standardmäßig ignoriert. `allowBots: true` aktiviert sie; verwenden Sie `allowBots: "mentions"`, um nur Bot-Nachrichten zu akzeptieren, die den Bot erwähnen (eigene Nachrichten werden weiterhin gefiltert). -- `channels.discord.guilds..ignoreOtherMentions` (und Kanal-Überschreibungen) verwirft Nachrichten, die einen anderen Nutzer oder eine andere Rolle erwähnen, aber nicht den Bot (ausgenommen @everyone/@here). -- `maxLinesPerMessage` (Standard 17) teilt hohe Nachrichten auf, selbst wenn sie unter 2000 Zeichen liegen. +- `channels.discord.guilds..ignoreOtherMentions` (und Kanal-Überschreibungen) verwirft Nachrichten, die einen anderen Benutzer oder eine andere Rolle erwähnen, aber nicht den Bot (ausgenommen @everyone/@here). +- `maxLinesPerMessage` (Standard 17) teilt lange Nachrichten auch dann auf, wenn sie unter 2000 Zeichen bleiben. - `channels.discord.threadBindings` steuert an Discord-Threads gebundenes Routing: - - `enabled`: Discord-Überschreibung für an Threads gebundene Sitzungsfunktionen (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` sowie gebundene Zustellung/gebundenes Routing) + - `enabled`: Discord-Überschreibung für an Threads gebundene Sitzungsfunktionen (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` und gebundene Zustellung/Routing) - `idleHours`: Discord-Überschreibung für automatisches Entfokussieren bei Inaktivität in Stunden (`0` deaktiviert) - - `maxAgeHours`: Discord-Überschreibung für das harte maximale Alter in Stunden (`0` deaktiviert) - - `spawnSubagentSessions`: Opt-in-Schalter für die automatische Thread-Erstellung/-Bindung durch `sessions_spawn({ thread: true })` -- Top-Level-`bindings[]`-Einträge mit `type: "acp"` konfigurieren persistente ACP-Bindungen für Kanäle und Threads (verwenden Sie die Kanal-/Thread-ID in `match.peer.id`). Die Feldsemantik wird gemeinsam unter [ACP Agents](/de/tools/acp-agents#channel-specific-settings) beschrieben. -- `channels.discord.ui.components.accentColor` legt die Akzentfarbe für Discord-Components-v2-Container fest. -- `channels.discord.voice` aktiviert Gespräche in Discord-Sprachkanälen sowie optionale automatische Beitritte und TTS-Überschreibungen. -- `channels.discord.voice.daveEncryption` und `channels.discord.voice.decryptionFailureTolerance` werden an die DAVE-Optionen von `@discordjs/voice` durchgereicht (standardmäßig `true` bzw. `24`). -- OpenClaw versucht zusätzlich, den Sprach-Empfang wiederherzustellen, indem es nach wiederholten Entschlüsselungsfehlern eine Sprachsitzung verlässt und erneut beitritt. -- `channels.discord.streaming` ist der kanonische Schlüssel für den Stream-Modus. Veraltete Werte für `streamMode` und boolesches `streaming` werden automatisch migriert. -- `channels.discord.autoPresence` ordnet die Laufzeitverfügbarkeit dem Bot-Status zu (healthy => online, degraded => idle, exhausted => dnd) und erlaubt optionale Überschreibungen des Statustexts. -- `channels.discord.dangerouslyAllowNameMatching` aktiviert veränderliches Namens-/Tag-Matching erneut (Break-Glass-Kompatibilitätsmodus). -- `channels.discord.execApprovals`: Discord-native Übermittlung von Exec-Genehmigungen und Autorisierung von Genehmigenden. - - `enabled`: `true`, `false` oder `"auto"` (Standard). Im Auto-Modus werden Exec-Genehmigungen aktiviert, wenn Genehmigende aus `approvers` oder `commands.ownerAllowFrom` aufgelöst werden können. - - `approvers`: Discord-Nutzer-IDs, die Exec-Anfragen genehmigen dürfen. Fällt auf `commands.ownerAllowFrom` zurück, wenn nicht angegeben. - - `agentFilter`: optionale Allowlist für Agent-IDs. Weglassen, um Genehmigungen für alle Agents weiterzuleiten. - - `sessionFilter`: optionale Sitzungs-Schlüsselmuster (Teilzeichenfolge oder Regex). - - `target`: wohin Genehmigungsabfragen gesendet werden. `"dm"` (Standard) sendet an die DMs der Genehmigenden, `"channel"` sendet in den Ursprungskanal, `"both"` sendet an beide. Wenn `target` `"channel"` enthält, sind Buttons nur für aufgelöste Genehmigende nutzbar. - - `cleanupAfterResolve`: wenn `true`, werden Genehmigungs-DMs nach Genehmigung, Ablehnung oder Timeout gelöscht. + - `maxAgeHours`: Discord-Überschreibung für das harte Maximalalter in Stunden (`0` deaktiviert) + - `spawnSubagentSessions`: Opt-in-Schalter für automatische Thread-Erstellung/-Bindung durch `sessions_spawn({ thread: true })` +- Top-Level-Einträge in `bindings[]` mit `type: "acp"` konfigurieren persistente ACP-Bindungen für Kanäle und Threads (verwenden Sie die Kanal-/Thread-ID in `match.peer.id`). Die Feldsemantik ist gemeinsam in [ACP Agents](/de/tools/acp-agents#channel-specific-settings) definiert. +- `channels.discord.ui.components.accentColor` setzt die Akzentfarbe für Discord-Komponenten-v2-Container. +- `channels.discord.voice` aktiviert Gespräche in Discord-Sprachkanälen sowie optionale automatische Beitritte + TTS-Überschreibungen. +- `channels.discord.voice.daveEncryption` und `channels.discord.voice.decryptionFailureTolerance` werden an die DAVE-Optionen von `@discordjs/voice` durchgereicht (`true` bzw. `24` standardmäßig). +- OpenClaw versucht zusätzlich, die Sprachübertragung wiederherzustellen, indem es nach wiederholten Entschlüsselungsfehlern eine Sprachsitzung verlässt und ihr erneut beitritt. +- `channels.discord.streaming` ist der kanonische Schlüssel für den Stream-Modus. Das Legacy-`streamMode` und boolesche `streaming`-Werte werden automatisch migriert. +- `channels.discord.autoPresence` bildet die Laufzeitverfügbarkeit auf die Bot-Präsenz ab (healthy => online, degraded => idle, exhausted => dnd) und erlaubt optionale Überschreibungen des Statustexts. +- `channels.discord.dangerouslyAllowNameMatching` aktiviert die Abgleichung über veränderliche Namen/Tags erneut (Break-Glass-Kompatibilitätsmodus). +- `channels.discord.execApprovals`: Discord-native Zustellung von Exec-Freigaben und Autorisierung von Freigebenden. + - `enabled`: `true`, `false` oder `"auto"` (Standard). Im Auto-Modus werden Exec-Freigaben aktiviert, wenn Freigebende aus `approvers` oder `commands.ownerAllowFrom` aufgelöst werden können. + - `approvers`: Discord-Benutzer-IDs, die Exec-Anfragen freigeben dürfen. Fällt auf `commands.ownerAllowFrom` zurück, wenn weggelassen. + - `agentFilter`: optionale Allowlist für Agent-IDs. Weglassen, um Freigaben für alle Agenten weiterzuleiten. + - `sessionFilter`: optionale Muster für Sitzungsschlüssel (Teilstring oder Regex). + - `target`: wohin Freigabeaufforderungen gesendet werden. `"dm"` (Standard) sendet an DMs der Freigebenden, `"channel"` sendet an den Ursprungskanal, `"both"` sendet an beide. Wenn das Ziel `"channel"` einschließt, sind Buttons nur für aufgelöste Freigebende nutzbar. + - `cleanupAfterResolve`: wenn `true`, werden Freigabe-DMs nach Freigabe, Ablehnung oder Zeitüberschreitung gelöscht. **Modi für Reaktionsbenachrichtigungen:** `off` (keine), `own` (Nachrichten des Bots, Standard), `all` (alle Nachrichten), `allowlist` (aus `guilds..users` für alle Nachrichten). @@ -394,10 +394,10 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom ``` - Service-Account-JSON: inline (`serviceAccount`) oder dateibasiert (`serviceAccountFile`). -- Service-Account-SecretRef wird ebenfalls unterstützt (`serviceAccountRef`). -- Umgebungs-Fallbacks: `GOOGLE_CHAT_SERVICE_ACCOUNT` oder `GOOGLE_CHAT_SERVICE_ACCOUNT_FILE`. -- Verwenden Sie `spaces/` oder `users/` für Zustellziele. -- `channels.googlechat.dangerouslyAllowNameMatching` aktiviert veränderliches Matching von E-Mail-Principals erneut (Break-Glass-Kompatibilitätsmodus). +- SecretRef für den Service Account wird ebenfalls unterstützt (`serviceAccountRef`). +- Umgebungsvariablen-Fallbacks: `GOOGLE_CHAT_SERVICE_ACCOUNT` oder `GOOGLE_CHAT_SERVICE_ACCOUNT_FILE`. +- Verwenden Sie `spaces/` oder `users/` als Zustellziele. +- `channels.googlechat.dangerouslyAllowNameMatching` aktiviert die Abgleichung über veränderliche E-Mail-Principals erneut (Break-Glass-Kompatibilitätsmodus). ### Slack @@ -464,34 +464,34 @@ WhatsApp läuft über den Web-Kanal des Gateways (Baileys Web). Er startet autom } ``` -- **Socket-Modus** erfordert sowohl `botToken` als auch `appToken` (`SLACK_BOT_TOKEN` + `SLACK_APP_TOKEN` als Umgebungs-Fallback für das Standardkonto). +- **Socket-Modus** erfordert sowohl `botToken` als auch `appToken` (`SLACK_BOT_TOKEN` + `SLACK_APP_TOKEN` als Umgebungsvariablen-Fallback für das Standardkonto). - **HTTP-Modus** erfordert `botToken` plus `signingSecret` (auf Root-Ebene oder pro Konto). -- `botToken`, `appToken`, `signingSecret` und `userToken` akzeptieren Klartextzeichenfolgen oder SecretRef-Objekte. -- Slack-Konto-Snapshots stellen quellen-/statusbezogene Felder pro Zugangsdaten bereit, wie `botTokenSource`, `botTokenStatus`, `appTokenStatus` und im HTTP-Modus `signingSecretStatus`. `configured_unavailable` bedeutet, dass das Konto über SecretRef konfiguriert ist, der aktuelle Befehls-/Laufzeitpfad den Secret-Wert aber nicht auflösen konnte. +- `botToken`, `appToken`, `signingSecret` und `userToken` akzeptieren Klartext-Strings oder SecretRef-Objekte. +- Slack-Konto-Snapshots stellen pro Anmeldedaten Quelle-/Statusfelder bereit, etwa `botTokenSource`, `botTokenStatus`, `appTokenStatus` und im HTTP-Modus `signingSecretStatus`. `configured_unavailable` bedeutet, dass das Konto über SecretRef konfiguriert ist, der aktuelle Befehls-/Laufzeitpfad den Secret-Wert jedoch nicht auflösen konnte. - `configWrites: false` blockiert von Slack initiierte Konfigurationsschreibvorgänge. -- Optional überschreibt `channels.slack.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. -- `channels.slack.streaming.mode` ist der kanonische Schlüssel für den Slack-Stream-Modus. `channels.slack.streaming.nativeTransport` steuert Slacks nativen Streaming-Transport. Veraltete Werte für `streamMode`, boolesches `streaming` und `nativeStreaming` werden automatisch migriert. -- Verwenden Sie `user:` (DM) oder `channel:` für Zustellziele. +- Das optionale `channels.slack.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- `channels.slack.streaming.mode` ist der kanonische Schlüssel für den Slack-Stream-Modus. `channels.slack.streaming.nativeTransport` steuert den nativen Streaming-Transport von Slack. Legacy-`streamMode`, boolesche `streaming`- und `nativeStreaming`-Werte werden automatisch migriert. +- Verwenden Sie `user:` (DM) oder `channel:` als Zustellziele. **Modi für Reaktionsbenachrichtigungen:** `off`, `own` (Standard), `all`, `allowlist` (aus `reactionAllowlist`). -**Thread-Sitzungsisolierung:** `thread.historyScope` ist pro Thread (Standard) oder kanalübergreifend gemeinsam. `thread.inheritParent` kopiert das übergeordnete Kanal-Transkript in neue Threads. +**Thread-Sitzungsisolierung:** `thread.historyScope` ist pro Thread (Standard) oder über den Kanal geteilt. `thread.inheritParent` kopiert das übergeordnete Kanal-Transkript in neue Threads. -- Slack-Native-Streaming plus der Slack-assistentenartige Thread-Status „is typing...“ erfordern ein Antwort-Thread-Ziel. Top-Level-DMs bleiben standardmäßig außerhalb von Threads, daher verwenden sie stattdessen `typingReaction` oder normale Zustellung statt der Thread-Vorschau. -- `typingReaction` fügt der eingehenden Slack-Nachricht temporär eine Reaktion hinzu, während eine Antwort läuft, und entfernt sie nach Abschluss wieder. Verwenden Sie einen Slack-Emoji-Shortcode wie `"hourglass_flowing_sand"`. -- `channels.slack.execApprovals`: Slack-native Übermittlung von Exec-Genehmigungen und Autorisierung von Genehmigenden. Gleiches Schema wie bei Discord: `enabled` (`true`/`false`/`"auto"`), `approvers` (Slack-Nutzer-IDs), `agentFilter`, `sessionFilter` und `target` (`"dm"`, `"channel"` oder `"both"`). +- Native Slack-Streams sowie der Slack-Assistentenstil-Status „is typing...“ für Threads erfordern ein Antwort-Thread-Ziel. DMs auf oberster Ebene bleiben standardmäßig außerhalb von Threads, daher verwenden sie stattdessen `typingReaction` oder normale Zustellung statt einer Thread-Vorschau. +- `typingReaction` fügt der eingehenden Slack-Nachricht während der Ausführung einer Antwort vorübergehend eine Reaktion hinzu und entfernt sie nach Abschluss wieder. Verwenden Sie einen Slack-Emoji-Shortcode wie `"hourglass_flowing_sand"`. +- `channels.slack.execApprovals`: Slack-native Zustellung von Exec-Freigaben und Autorisierung von Freigebenden. Gleiches Schema wie bei Discord: `enabled` (`true`/`false`/`"auto"`), `approvers` (Slack-Benutzer-IDs), `agentFilter`, `sessionFilter` und `target` (`"dm"`, `"channel"` oder `"both"`). -| Aktionsgruppe | Standard | Hinweise | -| ------------- | -------- | ------------------------- | +| Aktionsgruppe | Standard | Hinweise | +| ------------- | -------- | ------------------------ | | reactions | aktiviert | Reagieren + Reaktionen auflisten | -| messages | aktiviert | Lesen/Senden/Bearbeiten/Löschen | -| pins | aktiviert | Anheften/Lösen/Auflisten | -| memberInfo | aktiviert | Mitgliedsinformationen | -| emojiList | aktiviert | Liste benutzerdefinierter Emojis | +| messages | aktiviert | Lesen/senden/bearbeiten/löschen | +| pins | aktiviert | Anheften/lösen/auflisten | +| memberInfo | aktiviert | Mitgliedsinformationen | +| emojiList | aktiviert | Benutzerdefinierte Emoji-Liste | ### Mattermost -Mattermost wird als Plugin bereitgestellt: `openclaw plugins install @openclaw/mattermost`. +Mattermost wird als Plugin ausgeliefert: `openclaw plugins install @openclaw/mattermost`. ```json5 { @@ -511,7 +511,7 @@ Mattermost wird als Plugin bereitgestellt: `openclaw plugins install @openclaw/m native: true, // opt-in nativeSkills: true, callbackPath: "/api/channels/mattermost/command", - // Optional explizite URL für Reverse-Proxy-/öffentliche Bereitstellungen + // Optional explicit URL for reverse-proxy/public deployments callbackUrl: "https://gateway.example.com/api/channels/mattermost/command", }, textChunkLimit: 4000, @@ -521,18 +521,18 @@ Mattermost wird als Plugin bereitgestellt: `openclaw plugins install @openclaw/m } ``` -Chat-Modi: `oncall` (bei @-Erwähnung antworten, Standard), `onmessage` (jede Nachricht), `onchar` (Nachrichten, die mit dem Auslöserpräfix beginnen). +Chat-Modi: `oncall` (antwortet auf @-Erwähnung, Standard), `onmessage` (jede Nachricht), `onchar` (Nachrichten, die mit einem Trigger-Präfix beginnen). Wenn native Mattermost-Befehle aktiviert sind: - `commands.callbackPath` muss ein Pfad sein (zum Beispiel `/api/channels/mattermost/command`), keine vollständige URL. -- `commands.callbackUrl` muss auf den OpenClaw-Gateway-Endpunkt zeigen und vom Mattermost-Server erreichbar sein. -- Native Slash-Callbacks werden mit den pro Befehl gültigen Tokens authentifiziert, die Mattermost bei der Registrierung von Slash-Befehlen zurückgibt. Wenn die Registrierung fehlschlägt oder keine Befehle aktiviert werden, lehnt OpenClaw Callbacks mit `Unauthorized: invalid command token.` ab. -- Für private/Tailnet/interne Callback-Hosts kann Mattermost verlangen, dass `ServiceSettings.AllowedUntrustedInternalConnections` den Callback-Host bzw. die Callback-Domain enthält. Verwenden Sie Host-/Domain-Werte, keine vollständigen URLs. -- `channels.mattermost.configWrites`: Mattermost-initiierte Konfigurationsschreibvorgänge erlauben oder verweigern. -- `channels.mattermost.requireMention`: `@mention` vor der Antwort in Kanälen verlangen. -- `channels.mattermost.groups..requireMention`: kanalbezogene Überschreibung für Mention-Gating (`"*"` für Standard). -- Optional überschreibt `channels.mattermost.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- `commands.callbackUrl` muss auf den Gateway-Endpunkt von OpenClaw aufgelöst werden und vom Mattermost-Server aus erreichbar sein. +- Native Slash-Callbacks werden mit den pro Befehl vergebenen Tokens authentifiziert, die Mattermost bei der Registrierung des Slash-Befehls zurückgibt. Wenn die Registrierung fehlschlägt oder keine Befehle aktiviert sind, lehnt OpenClaw Callbacks mit `Unauthorized: invalid command token.` ab. +- Für private/Tailnet-/interne Callback-Hosts muss Mattermost unter Umständen `ServiceSettings.AllowedUntrustedInternalConnections` so konfigurieren, dass der Callback-Host/-Domain enthalten ist. Verwenden Sie Host-/Domain-Werte, keine vollständigen URLs. +- `channels.mattermost.configWrites`: von Mattermost initiierte Konfigurationsschreibvorgänge erlauben oder verweigern. +- `channels.mattermost.requireMention`: `@mention` vor Antworten in Kanälen verlangen. +- `channels.mattermost.groups..requireMention`: kanalbezogene Überschreibung für Mention-Gating (`"*"` als Standard). +- Das optionale `channels.mattermost.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. ### Signal @@ -541,7 +541,7 @@ Wenn native Mattermost-Befehle aktiviert sind: channels: { signal: { enabled: true, - account: "+15555550123", // optionale Kontobindung + account: "+15555550123", // optional account binding dmPolicy: "pairing", allowFrom: ["+15551234567", "uuid:123e4567-e89b-12d3-a456-426614174000"], configWrites: true, @@ -556,12 +556,12 @@ Wenn native Mattermost-Befehle aktiviert sind: **Modi für Reaktionsbenachrichtigungen:** `off`, `own` (Standard), `all`, `allowlist` (aus `reactionAllowlist`). - `channels.signal.account`: bindet den Kanalstart an eine bestimmte Signal-Kontoidentität. -- `channels.signal.configWrites`: von Signal initiierte Konfigurationsschreibvorgänge erlauben oder verweigern. -- Optional überschreibt `channels.signal.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- `channels.signal.configWrites`: erlaubt oder verweigert von Signal initiierte Konfigurationsschreibvorgänge. +- Das optionale `channels.signal.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. ### BlueBubbles -BlueBubbles ist der empfohlene iMessage-Pfad (plugin-gestützt, konfiguriert unter `channels.bluebubbles`). +BlueBubbles ist der empfohlene iMessage-Pfad (Plugin-gestützt, konfiguriert unter `channels.bluebubbles`). ```json5 { @@ -569,16 +569,16 @@ BlueBubbles ist der empfohlene iMessage-Pfad (plugin-gestützt, konfiguriert unt bluebubbles: { enabled: true, dmPolicy: "pairing", - // serverUrl, password, webhookPath, group controls, and advanced actions: - // see /channels/bluebubbles + // serverUrl, password, webhookPath, Gruppensteuerung und erweiterte Aktionen: + // siehe /channels/bluebubbles }, }, } ``` -- Hier behandelte zentrale Schlüsselpfade: `channels.bluebubbles`, `channels.bluebubbles.dmPolicy`. -- Optional überschreibt `channels.bluebubbles.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. -- Top-Level-`bindings[]`-Einträge mit `type: "acp"` können BlueBubbles-Konversationen an persistente ACP-Sitzungen binden. Verwenden Sie einen BlueBubbles-Handle oder Ziel-String (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) in `match.peer.id`. Gemeinsame Feldsemantik: [ACP Agents](/de/tools/acp-agents#channel-specific-settings). +- Hier abgedeckte zentrale Schlüsselpfade: `channels.bluebubbles`, `channels.bluebubbles.dmPolicy`. +- Das optionale `channels.bluebubbles.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- Top-Level-Einträge in `bindings[]` mit `type: "acp"` können BlueBubbles-Konversationen an persistente ACP-Sitzungen binden. Verwenden Sie einen BlueBubbles-Handle oder Ziel-String (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) in `match.peer.id`. Gemeinsame Feldsemantik: [ACP Agents](/de/tools/acp-agents#channel-specific-settings). - Die vollständige BlueBubbles-Kanalkonfiguration ist unter [BlueBubbles](/de/channels/bluebubbles) dokumentiert. ### iMessage @@ -607,15 +607,15 @@ OpenClaw startet `imsg rpc` (JSON-RPC über stdio). Kein Daemon oder Port erford } ``` -- Optional überschreibt `channels.imessage.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- Das optionale `channels.imessage.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. - Erfordert Vollzugriff auf die Messages-Datenbank. -- Bevorzugen Sie Ziele im Format `chat_id:`. Verwenden Sie `imsg chats --limit 20`, um Chats aufzulisten. +- Bevorzugen Sie Ziele vom Typ `chat_id:`. Verwenden Sie `imsg chats --limit 20`, um Chats aufzulisten. - `cliPath` kann auf einen SSH-Wrapper zeigen; setzen Sie `remoteHost` (`host` oder `user@host`) für das Abrufen von Anhängen per SCP. - `attachmentRoots` und `remoteAttachmentRoots` beschränken Pfade eingehender Anhänge (Standard: `/Users/*/Library/Messages/Attachments`). -- SCP verwendet strikte Host-Key-Prüfung, stellen Sie also sicher, dass der Schlüssel des Relay-Hosts bereits in `~/.ssh/known_hosts` vorhanden ist. -- `channels.imessage.configWrites`: von iMessage initiierte Konfigurationsschreibvorgänge erlauben oder verweigern. -- Top-Level-`bindings[]`-Einträge mit `type: "acp"` können iMessage-Konversationen an persistente ACP-Sitzungen binden. Verwenden Sie einen normalisierten Handle oder ein explizites Chat-Ziel (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) in `match.peer.id`. Gemeinsame Feldsemantik: [ACP Agents](/de/tools/acp-agents#channel-specific-settings). +- SCP verwendet strikte Host-Key-Prüfung, stellen Sie daher sicher, dass der Host-Key des Relay-Hosts bereits in `~/.ssh/known_hosts` vorhanden ist. +- `channels.imessage.configWrites`: erlaubt oder verweigert von iMessage initiierte Konfigurationsschreibvorgänge. +- Top-Level-Einträge in `bindings[]` mit `type: "acp"` können iMessage-Konversationen an persistente ACP-Sitzungen binden. Verwenden Sie einen normalisierten Handle oder ein explizites Chat-Ziel (`chat_id:*`, `chat_guid:*`, `chat_identifier:*`) in `match.peer.id`. Gemeinsame Feldsemantik: [ACP Agents](/de/tools/acp-agents#channel-specific-settings). @@ -628,7 +628,7 @@ exec ssh -T gateway-host imsg "$@" ### Matrix -Matrix wird durch eine Erweiterung bereitgestellt und unter `channels.matrix` konfiguriert. +Matrix ist erweiterungsgestützt und wird unter `channels.matrix` konfiguriert. ```json5 { @@ -660,23 +660,23 @@ Matrix wird durch eine Erweiterung bereitgestellt und unter `channels.matrix` ko - Token-Authentifizierung verwendet `accessToken`; Passwort-Authentifizierung verwendet `userId` + `password`. - `channels.matrix.proxy` leitet Matrix-HTTP-Datenverkehr über einen expliziten HTTP(S)-Proxy. Benannte Konten können dies mit `channels.matrix.accounts..proxy` überschreiben. -- `channels.matrix.network.dangerouslyAllowPrivateNetwork` erlaubt private/interne Homeserver. `proxy` und diese Netzwerk-Opt-in-Einstellung sind unabhängige Steuerungen. -- `channels.matrix.defaultAccount` wählt in Multi-Konto-Setups das bevorzugte Konto aus. -- `channels.matrix.autoJoin` ist standardmäßig `off`, daher werden Einladungen in Räume und neue DM-artige Einladungen ignoriert, bis Sie `autoJoin: "allowlist"` mit `autoJoinAllowlist` oder `autoJoin: "always"` setzen. -- `channels.matrix.execApprovals`: Matrix-native Übermittlung von Exec-Genehmigungen und Autorisierung von Genehmigenden. - - `enabled`: `true`, `false` oder `"auto"` (Standard). Im Auto-Modus werden Exec-Genehmigungen aktiviert, wenn Genehmigende aus `approvers` oder `commands.ownerAllowFrom` aufgelöst werden können. - - `approvers`: Matrix-Nutzer-IDs (z. B. `@owner:example.org`), die Exec-Anfragen genehmigen dürfen. - - `agentFilter`: optionale Allowlist für Agent-IDs. Weglassen, um Genehmigungen für alle Agents weiterzuleiten. - - `sessionFilter`: optionale Sitzungs-Schlüsselmuster (Teilzeichenfolge oder Regex). - - `target`: wohin Genehmigungsabfragen gesendet werden. `"dm"` (Standard), `"channel"` (Ursprungsraum) oder `"both"`. - - Pro-Konto-Überschreibungen: `channels.matrix.accounts..execApprovals`. -- `channels.matrix.dm.sessionScope` steuert, wie Matrix-DMs in Sitzungen gruppiert werden: `per-user` (Standard) wird nach geroutetem Peer geteilt, während `per-room` jeden DM-Raum isoliert. -- Matrix-Status-Probes und Live-Verzeichnisabfragen verwenden dieselbe Proxy-Richtlinie wie der Laufzeitdatenverkehr. -- Die vollständige Matrix-Konfiguration, Zielregeln und Einrichtungsbeispiele sind unter [Matrix](/de/channels/matrix) dokumentiert. +- `channels.matrix.network.dangerouslyAllowPrivateNetwork` erlaubt private/interne Homeserver. `proxy` und dieses Netzwerk-Opt-in sind unabhängige Steuerungen. +- `channels.matrix.defaultAccount` wählt das bevorzugte Konto in Multi-Account-Setups aus. +- `channels.matrix.autoJoin` ist standardmäßig `off`, daher werden eingeladene Räume und neue DM-artige Einladungen ignoriert, bis Sie `autoJoin: "allowlist"` mit `autoJoinAllowlist` oder `autoJoin: "always"` setzen. +- `channels.matrix.execApprovals`: Matrix-native Zustellung von Exec-Freigaben und Autorisierung von Freigebenden. + - `enabled`: `true`, `false` oder `"auto"` (Standard). Im Auto-Modus werden Exec-Freigaben aktiviert, wenn Freigebende aus `approvers` oder `commands.ownerAllowFrom` aufgelöst werden können. + - `approvers`: Matrix-Benutzer-IDs (z. B. `@owner:example.org`), die Exec-Anfragen freigeben dürfen. + - `agentFilter`: optionale Allowlist für Agent-IDs. Weglassen, um Freigaben für alle Agenten weiterzuleiten. + - `sessionFilter`: optionale Muster für Sitzungsschlüssel (Teilstring oder Regex). + - `target`: wohin Freigabeaufforderungen gesendet werden. `"dm"` (Standard), `"channel"` (Ursprungsraum) oder `"both"`. + - Überschreibungen pro Konto: `channels.matrix.accounts..execApprovals`. +- `channels.matrix.dm.sessionScope` steuert, wie Matrix-DMs zu Sitzungen gruppiert werden: `per-user` (Standard) teilt nach geroutetem Peer, während `per-room` jeden DM-Raum isoliert. +- Matrix-Statusprüfungen und Live-Verzeichnissuchen verwenden dieselbe Proxy-Richtlinie wie der Laufzeitverkehr. +- Die vollständige Matrix-Konfiguration, Targeting-Regeln und Setup-Beispiele sind unter [Matrix](/de/channels/matrix) dokumentiert. ### Microsoft Teams -Microsoft Teams wird durch eine Erweiterung bereitgestellt und unter `channels.msteams` konfiguriert. +Microsoft Teams ist erweiterungsgestützt und wird unter `channels.msteams` konfiguriert. ```json5 { @@ -684,19 +684,19 @@ Microsoft Teams wird durch eine Erweiterung bereitgestellt und unter `channels.m msteams: { enabled: true, configWrites: true, - // appId, appPassword, tenantId, webhook, team/channel policies: - // see /channels/msteams + // appId, appPassword, tenantId, Webhook, Team-/Kanalrichtlinien: + // siehe /channels/msteams }, }, } ``` -- Hier behandelte zentrale Schlüsselpfade: `channels.msteams`, `channels.msteams.configWrites`. -- Die vollständige Teams-Konfiguration (Anmeldedaten, Webhook, DM-/Gruppenrichtlinie, team-/kanalbezogene Überschreibungen) ist unter [Microsoft Teams](/de/channels/msteams) dokumentiert. +- Hier abgedeckte zentrale Schlüsselpfade: `channels.msteams`, `channels.msteams.configWrites`. +- Die vollständige Teams-Konfiguration (Anmeldedaten, Webhook, DM-/Gruppenrichtlinie, Überschreibungen pro Team/pro Kanal) ist unter [Microsoft Teams](/de/channels/msteams) dokumentiert. ### IRC -IRC wird durch eine Erweiterung bereitgestellt und unter `channels.irc` konfiguriert. +IRC ist erweiterungsgestützt und wird unter `channels.irc` konfiguriert. ```json5 { @@ -717,11 +717,11 @@ IRC wird durch eine Erweiterung bereitgestellt und unter `channels.irc` konfigur } ``` -- Hier behandelte zentrale Schlüsselpfade: `channels.irc`, `channels.irc.dmPolicy`, `channels.irc.configWrites`, `channels.irc.nickserv.*`. -- Optional überschreibt `channels.irc.defaultAccount` die Auswahl des Standardkontos, wenn es mit einer konfigurierten Konto-ID übereinstimmt. +- Hier abgedeckte zentrale Schlüsselpfade: `channels.irc`, `channels.irc.dmPolicy`, `channels.irc.configWrites`, `channels.irc.nickserv.*`. +- Das optionale `channels.irc.defaultAccount` überschreibt die Standardkontenauswahl, wenn es mit einer konfigurierten Konto-ID übereinstimmt. - Die vollständige IRC-Kanalkonfiguration (Host/Port/TLS/Kanäle/Allowlists/Mention-Gating) ist unter [IRC](/de/channels/irc) dokumentiert. -### Mehrere Konten (alle Kanäle) +### Multi-Account (alle Kanäle) Führen Sie mehrere Konten pro Kanal aus (jedes mit eigener `accountId`): @@ -745,25 +745,25 @@ Führen Sie mehrere Konten pro Kanal aus (jedes mit eigener `accountId`): ``` - `default` wird verwendet, wenn `accountId` weggelassen wird (CLI + Routing). -- Umgebungs-Token gelten nur für das **default**-Konto. +- Umgebungsvariablen-Tokens gelten nur für das **Standard**konto. - Basis-Kanaleinstellungen gelten für alle Konten, sofern sie nicht pro Konto überschrieben werden. -- Verwenden Sie `bindings[].match.accountId`, um jedes Konto an einen anderen Agent zu routen. -- Wenn Sie über `openclaw channels add` (oder Kanal-Onboarding) ein Nicht-Standardkonto hinzufügen, während Sie sich noch in einer Top-Level-Kanalkonfiguration für ein einzelnes Konto befinden, verschiebt OpenClaw zunächst kontoabhängige Top-Level-Einzelkonto-Werte in die Kontozuordnung des Kanals, damit das ursprüngliche Konto weiter funktioniert. Die meisten Kanäle verschieben sie nach `channels..accounts.default`; Matrix kann stattdessen ein vorhandenes passendes benanntes/Standardziel beibehalten. -- Bestehende kanalbezogene Bindungen (ohne `accountId`) passen weiterhin auf das Standardkonto; kontobezogene Bindungen bleiben optional. -- `openclaw doctor --fix` repariert auch gemischte Formen, indem kontoabhängige Top-Level-Einzelkonto-Werte in das für diesen Kanal gewählte hochgestufte Konto verschoben werden. Die meisten Kanäle verwenden `accounts.default`; Matrix kann stattdessen ein vorhandenes passendes benanntes/Standardziel beibehalten. +- Verwenden Sie `bindings[].match.accountId`, um jedes Konto an einen anderen Agenten zu routen. +- Wenn Sie ein Nicht-Standardkonto über `openclaw channels add` (oder Kanal-Onboarding) hinzufügen, während Sie noch eine Top-Level-Kanalkonfiguration für ein Einzelkonto verwenden, hebt OpenClaw zunächst die kontobezogenen Top-Level-Werte des Einzelkontos in die Konto-Map des Kanals hoch, damit das ursprüngliche Konto weiterhin funktioniert. Die meisten Kanäle verschieben sie nach `channels..accounts.default`; Matrix kann stattdessen ein vorhandenes passendes benanntes/Standardziel beibehalten. +- Vorhandene reine Kanal-Bindungen (ohne `accountId`) passen weiterhin zum Standardkonto; kontobezogene Bindungen bleiben optional. +- `openclaw doctor --fix` repariert auch gemischte Formen, indem es kontobezogene Top-Level-Werte des Einzelkontos in das für diesen Kanal ausgewählte hochgestufte Konto verschiebt. Die meisten Kanäle verwenden `accounts.default`; Matrix kann stattdessen ein vorhandenes passendes benanntes/Standardziel beibehalten. ### Andere Erweiterungskanäle -Viele Erweiterungskanäle werden als `channels.` konfiguriert und auf ihren dedizierten Kanalseiten dokumentiert (zum Beispiel Feishu, Matrix, LINE, Nostr, Zalo, Nextcloud Talk, Synology Chat und Twitch). -Den vollständigen Kanalindex finden Sie unter: [Kanäle](/de/channels). +Viele Erweiterungskanäle werden als `channels.` konfiguriert und auf ihren jeweiligen dedizierten Kanalseiten dokumentiert (zum Beispiel Feishu, Matrix, LINE, Nostr, Zalo, Nextcloud Talk, Synology Chat und Twitch). +Siehe den vollständigen Kanalindex: [Channels](/de/channels). ### Mention-Gating in Gruppenchats -Gruppennachrichten erfordern standardmäßig **eine Erwähnung** (Metadaten-Erwähnung oder sichere Regex-Muster). Gilt für WhatsApp, Telegram, Discord, Google Chat und iMessage-Gruppenchats. +Gruppennachrichten erfordern standardmäßig eine **Erwähnung erforderlich** (Metadaten-Erwähnung oder sichere Regex-Muster). Gilt für WhatsApp-, Telegram-, Discord-, Google Chat- und iMessage-Gruppenchats. -**Mention-Typen:** +**Erwähnungstypen:** -- **Metadaten-Erwähnungen**: Native @-Erwähnungen der Plattform. Im WhatsApp-Selbstchat-Modus ignoriert. +- **Metadaten-Erwähnungen**: Native @-Erwähnungen der Plattform. Im WhatsApp-Selbstchatmodus ignoriert. - **Textmuster**: Sichere Regex-Muster in `agents.list[].groupChat.mentionPatterns`. Ungültige Muster und unsichere verschachtelte Wiederholungen werden ignoriert. - Mention-Gating wird nur erzwungen, wenn eine Erkennung möglich ist (native Erwähnungen oder mindestens ein Muster). @@ -778,9 +778,9 @@ Gruppennachrichten erfordern standardmäßig **eine Erwähnung** (Metadaten-Erw } ``` -`messages.groupChat.historyLimit` legt den globalen Standard fest. Kanäle können dies mit `channels..historyLimit` (oder pro Konto) überschreiben. Setzen Sie `0`, um es zu deaktivieren. +`messages.groupChat.historyLimit` setzt den globalen Standard. Kanäle können mit `channels..historyLimit` (oder pro Konto) überschreiben. Setzen Sie `0`, um dies zu deaktivieren. -#### DM-Verlaufsgrenzen +#### DM-Verlaufslimits ```json5 { @@ -795,13 +795,13 @@ Gruppennachrichten erfordern standardmäßig **eine Erwähnung** (Metadaten-Erw } ``` -Auflösung: DM-spezifische Überschreibung → Provider-Standard → keine Begrenzung (alles bleibt erhalten). +Auflösung: Überschreibung pro DM → Anbieterstandard → kein Limit (alles wird beibehalten). Unterstützt: `telegram`, `whatsapp`, `discord`, `slack`, `signal`, `imessage`, `msteams`. -#### Selbstchat-Modus +#### Selbstchatmodus -Fügen Sie Ihre eigene Nummer zu `allowFrom` hinzu, um den Selbstchat-Modus zu aktivieren (ignoriert native @-Erwähnungen, reagiert nur auf Textmuster): +Nehmen Sie Ihre eigene Nummer in `allowFrom` auf, um den Selbstchatmodus zu aktivieren (ignoriert native @-Erwähnungen, reagiert nur auf Textmuster): ```json5 { @@ -827,16 +827,16 @@ Fügen Sie Ihre eigene Nummer zu `allowFrom` hinzu, um den Selbstchat-Modus zu a ```json5 { commands: { - native: "auto", // native commands when supported register - nativeSkills: "auto", // native skill commands when supported register - text: true, // /commands in chat messages parsen + native: "auto", // native Befehle registrieren, wenn unterstützt + nativeSkills: "auto", // native Skill-Befehle registrieren, wenn unterstützt + text: true, // /commands in Chat-Nachrichten parsen bash: false, // ! erlauben (Alias: /bash) bashForegroundMs: 2000, config: false, // /config erlauben mcp: false, // /mcp erlauben plugins: false, // /plugins erlauben debug: false, // /debug erlauben - restart: true, // /restart + Gateway-Neustart-Tool erlauben + restart: true, // /restart + Gateway-Neustart-Werkzeug erlauben ownerAllowFrom: ["discord:123456789012345678"], ownerDisplay: "raw", // raw | hash ownerDisplaySecret: "${OWNER_ID_HASH_SECRET}", @@ -851,31 +851,31 @@ Fügen Sie Ihre eigene Nummer zu `allowFrom` hinzu, um den Selbstchat-Modus zu a -- Dieser Block konfiguriert Befehlsoberflächen. Den aktuellen integrierten + gebündelten Befehlskatalog finden Sie unter [Slash-Befehle](/de/tools/slash-commands). -- Diese Seite ist eine **Referenz für Konfigurationsschlüssel**, nicht der vollständige Befehlskatalog. Kanal-/plugin-eigene Befehle wie QQ Bot `/bot-ping` `/bot-help` `/bot-logs`, LINE `/card`, device-pair `/pair`, memory `/dreaming`, phone-control `/phone` und Talk `/voice` sind auf ihren Kanal-/Plugin-Seiten sowie unter [Slash-Befehle](/de/tools/slash-commands) dokumentiert. -- Textbefehle müssen **eigenständige** Nachrichten sein, die mit `/` beginnen. +- Dieser Block konfiguriert Befehlsoberflächen. Den aktuellen integrierten + gebündelten Befehlskatalog finden Sie unter [Slash Commands](/de/tools/slash-commands). +- Diese Seite ist eine **Referenz für Konfigurationsschlüssel**, nicht der vollständige Befehlskatalog. Kanal-/Plugin-eigene Befehle wie QQ Bot `/bot-ping` `/bot-help` `/bot-logs`, LINE `/card`, device-pair `/pair`, memory `/dreaming`, phone-control `/phone` und Talk `/voice` sind auf ihren Kanal-/Plugin-Seiten sowie unter [Slash Commands](/de/tools/slash-commands) dokumentiert. +- Textbefehle müssen **eigenständige** Nachrichten mit vorangestelltem `/` sein. - `native: "auto"` aktiviert native Befehle für Discord/Telegram und lässt Slack deaktiviert. - `nativeSkills: "auto"` aktiviert native Skills-Befehle für Discord/Telegram und lässt Slack deaktiviert. -- Pro Kanal überschreiben mit: `channels.discord.commands.native` (bool oder `"auto"`). `false` entfernt zuvor registrierte Befehle. +- Überschreibung pro Kanal: `channels.discord.commands.native` (bool oder `"auto"`). `false` löscht zuvor registrierte Befehle. - Überschreiben Sie die Registrierung nativer Skills pro Kanal mit `channels..commands.nativeSkills`. - `channels.telegram.customCommands` fügt zusätzliche Telegram-Bot-Menüeinträge hinzu. -- `bash: true` aktiviert `! ` für die Host-Shell. Erfordert `tools.elevated.enabled` und dass sich der Absender in `tools.elevated.allowFrom.` befindet. -- `config: true` aktiviert `/config` (liest/schreibt `openclaw.json`). Für Gateway-`chat.send`-Clients erfordern persistente Schreibvorgänge mit `/config set|unset` außerdem `operator.admin`; das schreibgeschützte `/config show` bleibt für normale Operator-Clients mit Schreibbereich verfügbar. +- `bash: true` aktiviert `! ` für die Host-Shell. Erfordert `tools.elevated.enabled` und einen Absender in `tools.elevated.allowFrom.`. +- `config: true` aktiviert `/config` (liest/schreibt `openclaw.json`). Für Gateway-`chat.send`-Clients erfordern persistente Schreibvorgänge über `/config set|unset` zusätzlich `operator.admin`; schreibgeschütztes `/config show` bleibt für normale Operator-Clients mit Schreibbereich verfügbar. - `mcp: true` aktiviert `/mcp` für von OpenClaw verwaltete MCP-Serverkonfiguration unter `mcp.servers`. -- `plugins: true` aktiviert `/plugins` für Plugin-Erkennung, Installation sowie Steuerelemente zum Aktivieren/Deaktivieren. +- `plugins: true` aktiviert `/plugins` für Plugin-Erkennung, -Installation sowie Steuerung von Aktivierung/Deaktivierung. - `channels..configWrites` steuert Konfigurationsänderungen pro Kanal (Standard: true). -- Für Multi-Konto-Kanäle steuert `channels..accounts..configWrites` auch Schreibvorgänge, die auf dieses Konto zielen (zum Beispiel `/allowlist --config --account ` oder `/config set channels..accounts....`). -- `restart: false` deaktiviert `/restart` und Gateway-Neustart-Tool-Aktionen. Standard: `true`. -- `ownerAllowFrom` ist die explizite Eigentümer-Allowlist für nur für Eigentümer bestimmte Befehle/Tools. Sie ist von `allowFrom` getrennt. +- Für Multi-Account-Kanäle steuert `channels..accounts..configWrites` ebenfalls Schreibvorgänge, die dieses Konto betreffen (zum Beispiel `/allowlist --config --account ` oder `/config set channels..accounts....`). +- `restart: false` deaktiviert `/restart` und Aktionen des Gateway-Neustart-Werkzeugs. Standard: `true`. +- `ownerAllowFrom` ist die explizite Eigentümer-Allowlist für nur für Eigentümer bestimmte Befehle/Werkzeuge. Sie ist von `allowFrom` getrennt. - `ownerDisplay: "hash"` hasht Eigentümer-IDs im System-Prompt. Setzen Sie `ownerDisplaySecret`, um das Hashing zu steuern. -- `allowFrom` ist pro Provider. Wenn gesetzt, ist es die **einzige** Autorisierungsquelle (Kanal-Allowlists/Pairing und `useAccessGroups` werden ignoriert). -- `useAccessGroups: false` erlaubt Befehlen, Zugriffsgruppenrichtlinien zu umgehen, wenn `allowFrom` nicht gesetzt ist. +- `allowFrom` ist anbieterbezogen. Wenn gesetzt, ist es die **einzige** Autorisierungsquelle (Kanal-Allowlists/Pairing und `useAccessGroups` werden ignoriert). +- `useAccessGroups: false` erlaubt es Befehlen, Richtlinien von Zugriffsgruppen zu umgehen, wenn `allowFrom` nicht gesetzt ist. - Zuordnung der Befehlsdokumentation: - - integrierter + gebündelter Katalog: [Slash-Befehle](/de/tools/slash-commands) - - kanalspezifische Befehlsoberflächen: [Kanäle](/de/channels) + - integrierter + gebündelter Katalog: [Slash Commands](/de/tools/slash-commands) + - kanalspezifische Befehlsoberflächen: [Channels](/de/channels) - QQ-Bot-Befehle: [QQ Bot](/de/channels/qqbot) - Pairing-Befehle: [Pairing](/de/channels/pairing) - - LINE-Card-Befehl: [LINE](/de/channels/line) + - LINE-Kartenbefehl: [LINE](/de/channels/line) - Memory-Dreaming: [Dreaming](/de/concepts/dreaming) @@ -896,7 +896,7 @@ Standard: `~/.openclaw/workspace`. ### `agents.defaults.repoRoot` -Optionales Repository-Root, das in der Runtime-Zeile des System-Prompts angezeigt wird. Wenn nicht gesetzt, erkennt OpenClaw es automatisch, indem es vom Workspace aus nach oben läuft. +Optionales Repository-Root, das in der Runtime-Zeile des System-Prompts angezeigt wird. Wenn nicht gesetzt, erkennt OpenClaw es automatisch, indem es vom Workspace aus nach oben traversiert. ```json5 { @@ -906,7 +906,8 @@ Optionales Repository-Root, das in der Runtime-Zeile des System-Prompts angezeig ### `agents.defaults.skills` -Optionale Standard-Allowlist für Skills für Agents, die `agents.list[].skills` nicht setzen. +Optionale Standard-Allowlist für Skills bei Agenten, die +`agents.list[].skills` nicht setzen. ```json5 { @@ -924,7 +925,7 @@ Optionale Standard-Allowlist für Skills für Agents, die `agents.list[].skills` - Lassen Sie `agents.defaults.skills` weg, um standardmäßig uneingeschränkte Skills zuzulassen. - Lassen Sie `agents.list[].skills` weg, um die Standards zu erben. - Setzen Sie `agents.list[].skills: []` für keine Skills. -- Eine nicht leere Liste in `agents.list[].skills` ist die endgültige Menge für diesen Agent; sie wird nicht mit den Standards zusammengeführt. +- Eine nicht leere Liste in `agents.list[].skills` ist die endgültige Menge für diesen Agenten; sie wird nicht mit Standards zusammengeführt. ### `agents.defaults.skipBootstrap` @@ -938,9 +939,9 @@ Deaktiviert die automatische Erstellung von Workspace-Bootstrap-Dateien (`AGENTS ### `agents.defaults.contextInjection` -Steuert, wann Workspace-Bootstrap-Dateien in den System-Prompt eingefügt werden. Standard: `"always"`. +Steuert, wann Workspace-Bootstrap-Dateien in den System-Prompt injiziert werden. Standard: `"always"`. -- `"continuation-skip"`: Sichere Fortsetzungs-Turns (nach einer abgeschlossenen Assistant-Antwort) überspringen das erneute Einfügen des Workspace-Bootstraps und reduzieren so die Prompt-Größe. Heartbeat-Läufe und Wiederholungen nach Kompaktierung bauen den Kontext weiterhin neu auf. +- `"continuation-skip"`: Sichere Fortsetzungsturns (nach einer abgeschlossenen Assistant-Antwort) überspringen die erneute Injektion des Workspace-Bootstraps, wodurch die Prompt-Größe reduziert wird. Heartbeat-Läufe und Wiederholungen nach Compaction bauen den Kontext weiterhin neu auf. ```json5 { @@ -950,7 +951,7 @@ Steuert, wann Workspace-Bootstrap-Dateien in den System-Prompt eingefügt werden ### `agents.defaults.bootstrapMaxChars` -Maximale Zeichenanzahl pro Workspace-Bootstrap-Datei vor dem Abschneiden. Standard: `20000`. +Maximale Zeichenanzahl pro Workspace-Bootstrap-Datei vor der Kürzung. Standard: `20000`. ```json5 { @@ -960,7 +961,7 @@ Maximale Zeichenanzahl pro Workspace-Bootstrap-Datei vor dem Abschneiden. Standa ### `agents.defaults.bootstrapTotalMaxChars` -Maximale Gesamtzahl an eingefügten Zeichen über alle Workspace-Bootstrap-Dateien hinweg. Standard: `150000`. +Maximale Gesamtzahl injizierter Zeichen über alle Workspace-Bootstrap-Dateien hinweg. Standard: `150000`. ```json5 { @@ -970,12 +971,12 @@ Maximale Gesamtzahl an eingefügten Zeichen über alle Workspace-Bootstrap-Datei ### `agents.defaults.bootstrapPromptTruncationWarning` -Steuert den für Agents sichtbaren Warntext, wenn Bootstrap-Kontext abgeschnitten wird. +Steuert den für Agenten sichtbaren Warntext, wenn Bootstrap-Kontext gekürzt wird. Standard: `"once"`. -- `"off"`: Warntext niemals in den System-Prompt einfügen. -- `"once"`: Warnung einmal pro eindeutiger Abschneidesignatur einfügen (empfohlen). -- `"always"`: Warnung bei jedem Lauf einfügen, wenn Abschneidung vorhanden ist. +- `"off"`: Niemals Warntext in den System-Prompt injizieren. +- `"once"`: Warnung einmal pro eindeutiger Kürzungssignatur injizieren (empfohlen). +- `"always"`: Warnung bei jedem Lauf injizieren, wenn eine Kürzung vorliegt. ```json5 { @@ -985,11 +986,11 @@ Standard: `"once"`. ### `agents.defaults.imageMaxDimensionPx` -Maximale Pixelgröße der längsten Bildseite in Transcript-/Tool-Bildblöcken vor Provider-Aufrufen. +Maximale Pixelgröße der längsten Bildseite in Bildblöcken von Transcript/Werkzeugen vor Anbieteraufrufen. Standard: `1200`. -Niedrigere Werte reduzieren in der Regel den Vision-Token-Verbrauch und die Größe der Anfrage-Payload bei screenshotlastigen Läufen. -Höhere Werte erhalten mehr visuelle Details. +Niedrigere Werte reduzieren in der Regel die Nutzung von Vision-Tokens und die Größe des Request-Payloads bei screenshotlastigen Läufen. +Höhere Werte bewahren mehr visuelle Details. ```json5 { @@ -999,7 +1000,7 @@ Höhere Werte erhalten mehr visuelle Details. ### `agents.defaults.userTimezone` -Zeitzone für den Kontext im System-Prompt (nicht für Nachrichten-Zeitstempel). Fällt auf die Zeitzone des Hosts zurück. +Zeitzone für den Kontext des System-Prompts (nicht für Nachrichten-Zeitstempel). Fällt auf die Host-Zeitzone zurück. ```json5 { @@ -1009,7 +1010,7 @@ Zeitzone für den Kontext im System-Prompt (nicht für Nachrichten-Zeitstempel). ### `agents.defaults.timeFormat` -Zeitformat im System-Prompt. Standard: `auto` (OS-Einstellung). +Zeitformat im System-Prompt. Standard: `auto` (OS-Präferenz). ```json5 { @@ -1047,7 +1048,7 @@ Zeitformat im System-Prompt. Standard: `auto` (OS-Einstellung). primary: "anthropic/claude-opus-4-6", fallbacks: ["openai/gpt-5.4-mini"], }, - params: { cacheRetention: "long" }, // globale Standard-Provider-Parameter + params: { cacheRetention: "long" }, // globaler Standard für Anbieterparameter embeddedHarness: { runtime: "auto", // auto | pi | registrierte Harness-ID, z. B. codex fallback: "pi", // pi | none @@ -1070,44 +1071,44 @@ Zeitformat im System-Prompt. Standard: `auto` (OS-Einstellung). - Die String-Form setzt nur das primäre Modell. - Die Objekt-Form setzt das primäre Modell plus geordnete Failover-Modelle. - `imageModel`: akzeptiert entweder einen String (`"provider/model"`) oder ein Objekt (`{ primary, fallbacks }`). - - Wird vom Tool-Pfad `image` als dessen Vision-Modellkonfiguration verwendet. - - Wird außerdem als Fallback-Routing verwendet, wenn das ausgewählte/standardmäßige Modell keine Bildeingaben akzeptieren kann. + - Wird vom `image`-Werkzeugpfad als Vision-Modellkonfiguration verwendet. + - Wird außerdem als Fallback-Routing verwendet, wenn das ausgewählte/Standardmodell keine Bildeingaben akzeptieren kann. - `imageGenerationModel`: akzeptiert entweder einen String (`"provider/model"`) oder ein Objekt (`{ primary, fallbacks }`). - - Wird von der gemeinsamen Bildgenerierungsfunktion und jeder zukünftigen Tool-/Plugin-Oberfläche verwendet, die Bilder erzeugt. + - Wird von der gemeinsamen Fähigkeit zur Bildgenerierung und jeder zukünftigen Werkzeug-/Plugin-Oberfläche verwendet, die Bilder generiert. - Typische Werte: `google/gemini-3.1-flash-image-preview` für native Gemini-Bildgenerierung, `fal/fal-ai/flux/dev` für fal oder `openai/gpt-image-1` für OpenAI Images. - - Wenn Sie direkt einen Provider/ein Modell auswählen, konfigurieren Sie auch die passende Provider-Authentifizierung bzw. den API-Schlüssel dazu (zum Beispiel `GEMINI_API_KEY` oder `GOOGLE_API_KEY` für `google/*`, `OPENAI_API_KEY` für `openai/*`, `FAL_KEY` für `fal/*`). - - Wenn nicht gesetzt, kann `image_generate` dennoch einen authentifizierungsbasierten Provider-Standard ableiten. Es versucht zuerst den aktuellen Standard-Provider und danach die übrigen registrierten Bildgenerierungs-Provider in Provider-ID-Reihenfolge. + - Wenn Sie direkt einen Anbieter/ein Modell auswählen, konfigurieren Sie auch die passende Anbieter-Authentifizierung bzw. den API-Schlüssel dazu (zum Beispiel `GEMINI_API_KEY` oder `GOOGLE_API_KEY` für `google/*`, `OPENAI_API_KEY` für `openai/*`, `FAL_KEY` für `fal/*`). + - Wenn nicht gesetzt, kann `image_generate` trotzdem einen authentifizierungsbasierten Anbieterstandard ableiten. Es versucht zuerst den aktuellen Standardanbieter und dann die übrigen registrierten Anbieter für Bildgenerierung in der Reihenfolge der Anbieter-IDs. - `musicGenerationModel`: akzeptiert entweder einen String (`"provider/model"`) oder ein Objekt (`{ primary, fallbacks }`). - - Wird von der gemeinsamen Musikgenerierungsfunktion und dem integrierten Tool `music_generate` verwendet. + - Wird von der gemeinsamen Fähigkeit zur Musikgenerierung und dem integrierten Werkzeug `music_generate` verwendet. - Typische Werte: `google/lyria-3-clip-preview`, `google/lyria-3-pro-preview` oder `minimax/music-2.5+`. - - Wenn nicht gesetzt, kann `music_generate` dennoch einen authentifizierungsbasierten Provider-Standard ableiten. Es versucht zuerst den aktuellen Standard-Provider und danach die übrigen registrierten Musikgenerierungs-Provider in Provider-ID-Reihenfolge. - - Wenn Sie direkt einen Provider/ein Modell auswählen, konfigurieren Sie auch die passende Provider-Authentifizierung bzw. den API-Schlüssel dazu. + - Wenn nicht gesetzt, kann `music_generate` trotzdem einen authentifizierungsbasierten Anbieterstandard ableiten. Es versucht zuerst den aktuellen Standardanbieter und dann die übrigen registrierten Anbieter für Musikgenerierung in der Reihenfolge der Anbieter-IDs. + - Wenn Sie direkt einen Anbieter/ein Modell auswählen, konfigurieren Sie auch die passende Anbieter-Authentifizierung bzw. den API-Schlüssel dazu. - `videoGenerationModel`: akzeptiert entweder einen String (`"provider/model"`) oder ein Objekt (`{ primary, fallbacks }`). - - Wird von der gemeinsamen Videogenerierungsfunktion und dem integrierten Tool `video_generate` verwendet. + - Wird von der gemeinsamen Fähigkeit zur Videogenerierung und dem integrierten Werkzeug `video_generate` verwendet. - Typische Werte: `qwen/wan2.6-t2v`, `qwen/wan2.6-i2v`, `qwen/wan2.6-r2v`, `qwen/wan2.6-r2v-flash` oder `qwen/wan2.7-r2v`. - - Wenn nicht gesetzt, kann `video_generate` dennoch einen authentifizierungsbasierten Provider-Standard ableiten. Es versucht zuerst den aktuellen Standard-Provider und danach die übrigen registrierten Videogenerierungs-Provider in Provider-ID-Reihenfolge. - - Wenn Sie direkt einen Provider/ein Modell auswählen, konfigurieren Sie auch die passende Provider-Authentifizierung bzw. den API-Schlüssel dazu. - - Der gebündelte Qwen-Videogenerierungs-Provider unterstützt bis zu 1 Ausgabevideo, 1 Eingabebild, 4 Eingangsvideos, 10 Sekunden Dauer sowie Provider-spezifische Optionen für `size`, `aspectRatio`, `resolution`, `audio` und `watermark`. + - Wenn nicht gesetzt, kann `video_generate` trotzdem einen authentifizierungsbasierten Anbieterstandard ableiten. Es versucht zuerst den aktuellen Standardanbieter und dann die übrigen registrierten Anbieter für Videogenerierung in der Reihenfolge der Anbieter-IDs. + - Wenn Sie direkt einen Anbieter/ein Modell auswählen, konfigurieren Sie auch die passende Anbieter-Authentifizierung bzw. den API-Schlüssel dazu. + - Der gebündelte Qwen-Anbieter für Videogenerierung unterstützt bis zu 1 Ausgabevideo, 1 Eingabebild, 4 Eingabevideos, 10 Sekunden Dauer sowie anbieterbezogene Optionen für `size`, `aspectRatio`, `resolution`, `audio` und `watermark`. - `pdfModel`: akzeptiert entweder einen String (`"provider/model"`) oder ein Objekt (`{ primary, fallbacks }`). - - Wird vom Tool `pdf` für das Modell-Routing verwendet. - - Wenn nicht gesetzt, fällt das PDF-Tool auf `imageModel` und danach auf das aufgelöste Sitzungs-/Standardmodell zurück. -- `pdfMaxBytesMb`: Standardgrößenlimit für PDFs im Tool `pdf`, wenn `maxBytesMb` beim Aufruf nicht übergeben wird. -- `pdfMaxPages`: Standardmaximalzahl von Seiten, die im Extraktions-Fallback-Modus des Tools `pdf` berücksichtigt werden. -- `verboseDefault`: Standard-Verbose-Level für Agents. Werte: `"off"`, `"on"`, `"full"`. Standard: `"off"`. -- `elevatedDefault`: Standard-Level für erhöhte Ausgabe für Agents. Werte: `"off"`, `"on"`, `"ask"`, `"full"`. Standard: `"on"`. -- `model.primary`: Format `provider/model` (z. B. `openai/gpt-5.4`). Wenn Sie den Provider weglassen, versucht OpenClaw zuerst einen Alias, dann einen eindeutigen configured-provider-Treffer für genau diese Modell-ID und fällt erst danach auf den konfigurierten Standard-Provider zurück (veraltetes Kompatibilitätsverhalten, daher bevorzugen Sie explizit `provider/model`). Wenn dieser Provider das konfigurierte Standardmodell nicht mehr bereitstellt, fällt OpenClaw auf das erste konfigurierte Provider-/Modellpaar zurück, statt einen veralteten Standard eines entfernten Providers anzuzeigen. -- `models`: der konfigurierte Modellkatalog und die Allowlist für `/model`. Jeder Eintrag kann `alias` (Kurzform) und `params` (providerspezifisch, zum Beispiel `temperature`, `maxTokens`, `cacheRetention`, `context1m`) enthalten. -- `params`: globale Standard-Provider-Parameter, die auf alle Modelle angewendet werden. Setzen Sie sie unter `agents.defaults.params` (z. B. `{ cacheRetention: "long" }`). -- Merge-Priorität von `params` (Konfiguration): `agents.defaults.params` (globale Basis) wird durch `agents.defaults.models["provider/model"].params` (pro Modell) überschrieben, danach überschreibt `agents.list[].params` (passende Agent-ID) schlüsselweise. Details finden Sie unter [Prompt Caching](/de/reference/prompt-caching). -- `embeddedHarness`: standardmäßige Low-Level-Laufzeitrichtlinie für eingebettete Agents. Verwenden Sie `runtime: "auto"`, damit registrierte Plugin-Harnesses unterstützte Modelle beanspruchen können, `runtime: "pi"` zum Erzwingen des integrierten PI-Harnesses oder eine registrierte Harness-ID wie `runtime: "codex"`. Setzen Sie `fallback: "none"`, um den automatischen PI-Fallback zu deaktivieren. + - Wird vom `pdf`-Werkzeug für das Modell-Routing verwendet. + - Wenn nicht gesetzt, greift das PDF-Werkzeug auf `imageModel` zurück und dann auf das aufgelöste Sitzungs-/Standardmodell. +- `pdfMaxBytesMb`: Standard-PDF-Größenlimit für das `pdf`-Werkzeug, wenn `maxBytesMb` zur Aufrufzeit nicht übergeben wird. +- `pdfMaxPages`: Standardmaximum an Seiten, das im Extraktions-Fallback-Modus des `pdf`-Werkzeugs berücksichtigt wird. +- `verboseDefault`: Standard-Verbose-Stufe für Agenten. Werte: `"off"`, `"on"`, `"full"`. Standard: `"off"`. +- `elevatedDefault`: Standardstufe für erweiterte Ausgabe bei Agenten. Werte: `"off"`, `"on"`, `"ask"`, `"full"`. Standard: `"on"`. +- `model.primary`: Format `provider/model` (z. B. `openai/gpt-5.4`). Wenn Sie den Anbieter weglassen, versucht OpenClaw zuerst einen Alias, dann eine eindeutige Übereinstimmung eines konfigurierten Anbieters für genau diese Modell-ID und greift erst dann auf den konfigurierten Standardanbieter zurück (veraltetes Kompatibilitätsverhalten, daher bevorzugen Sie explizit `provider/model`). Wenn dieser Anbieter das konfigurierte Standardmodell nicht mehr bereitstellt, greift OpenClaw auf das erste konfigurierte Anbieter-/Modellpaar zurück, statt einen veralteten entfernten Anbieterstandard anzuzeigen. +- `models`: der konfigurierte Modellkatalog und die Allowlist für `/model`. Jeder Eintrag kann `alias` (Kurzform) und `params` (anbieterspezifisch, zum Beispiel `temperature`, `maxTokens`, `cacheRetention`, `context1m`) enthalten. +- `params`: globale Standardanbieterparameter, die auf alle Modelle angewendet werden. Setzen Sie sie unter `agents.defaults.params` (z. B. `{ cacheRetention: "long" }`). +- Merge-Priorität von `params` (Konfiguration): `agents.defaults.params` (globale Basis) wird durch `agents.defaults.models["provider/model"].params` (pro Modell) überschrieben, anschließend überschreibt `agents.list[].params` (passende Agent-ID) schlüsselweise. Details finden Sie unter [Prompt Caching](/de/reference/prompt-caching). +- `embeddedHarness`: Standardrichtlinie für die Low-Level-Laufzeit eingebetteter Agenten. Verwenden Sie `runtime: "auto"`, damit registrierte Plugin-Harnesses unterstützte Modelle übernehmen können, `runtime: "pi"` zum Erzwingen des integrierten Pi-Harnesses oder eine registrierte Harness-ID wie `runtime: "codex"`. Setzen Sie `fallback: "none"`, um den automatischen Pi-Fallback zu deaktivieren. - Konfigurationsschreiber, die diese Felder ändern (zum Beispiel `/models set`, `/models set-image` und Befehle zum Hinzufügen/Entfernen von Fallbacks), speichern die kanonische Objektform und erhalten vorhandene Fallback-Listen, wenn möglich. - `maxConcurrent`: maximale Anzahl paralleler Agent-Läufe über Sitzungen hinweg (jede Sitzung bleibt weiterhin serialisiert). Standard: 4. ### `agents.defaults.embeddedHarness` `embeddedHarness` steuert, welcher Low-Level-Executor eingebettete Agent-Turns ausführt. -Die meisten Bereitstellungen sollten den Standard `{ runtime: "auto", fallback: "pi" }` beibehalten. -Verwenden Sie dies, wenn ein vertrauenswürdiges Plugin ein natives Harness bereitstellt, etwa das gebündelte Codex-App-Server-Harness. +Die meisten Deployments sollten den Standard `{ runtime: "auto", fallback: "pi" }` beibehalten. +Verwenden Sie dies, wenn ein vertrauenswürdiges Plugin ein natives Harness bereitstellt, wie etwa das gebündelte Codex-App-Server-Harness. ```json5 { @@ -1124,33 +1125,33 @@ Verwenden Sie dies, wenn ein vertrauenswürdiges Plugin ein natives Harness bere ``` - `runtime`: `"auto"`, `"pi"` oder eine registrierte Plugin-Harness-ID. Das gebündelte Codex-Plugin registriert `codex`. -- `fallback`: `"pi"` oder `"none"`. `"pi"` behält den integrierten PI-Harness als Kompatibilitäts-Fallback bei. `"none"` führt dazu, dass eine fehlende oder nicht unterstützte Plugin-Harness-Auswahl fehlschlägt, statt stillschweigend PI zu verwenden. -- Umgebungsüberschreibungen: `OPENCLAW_AGENT_RUNTIME=` überschreibt `runtime`; `OPENCLAW_AGENT_HARNESS_FALLBACK=none` deaktiviert den PI-Fallback für diesen Prozess. -- Für reine Codex-Bereitstellungen setzen Sie `model: "codex/gpt-5.4"`, `embeddedHarness.runtime: "codex"` und `embeddedHarness.fallback: "none"`. -- Dies steuert nur das eingebettete Chat-Harness. Mediengenerierung, Vision, PDF, Musik, Video und TTS verwenden weiterhin ihre Provider-/Modell-Einstellungen. +- `fallback`: `"pi"` oder `"none"`. `"pi"` behält das integrierte Pi-Harness als Kompatibilitäts-Fallback bei. `"none"` sorgt dafür, dass eine fehlende oder nicht unterstützte Plugin-Harness-Auswahl fehlschlägt, statt stillschweigend Pi zu verwenden. +- Umgebungsvariablen-Überschreibungen: `OPENCLAW_AGENT_RUNTIME=` überschreibt `runtime`; `OPENCLAW_AGENT_HARNESS_FALLBACK=none` deaktiviert den Pi-Fallback für diesen Prozess. +- Für reine Codex-Deployments setzen Sie `model: "codex/gpt-5.4"`, `embeddedHarness.runtime: "codex"` und `embeddedHarness.fallback: "none"`. +- Dies steuert nur das eingebettete Chat-Harness. Mediengenerierung, Vision, PDF, Musik, Video und TTS verwenden weiterhin ihre Anbieter-/Modelleinstellungen. **Integrierte Alias-Kurzformen** (gelten nur, wenn das Modell in `agents.defaults.models` enthalten ist): -| Alias | Modell | -| ------------------- | -------------------------------------- | -| `opus` | `anthropic/claude-opus-4-6` | -| `sonnet` | `anthropic/claude-sonnet-4-6` | -| `gpt` | `openai/gpt-5.4` | -| `gpt-mini` | `openai/gpt-5.4-mini` | -| `gpt-nano` | `openai/gpt-5.4-nano` | -| `gemini` | `google/gemini-3.1-pro-preview` | -| `gemini-flash` | `google/gemini-3-flash-preview` | +| Alias | Modell | +| ------------------- | ------------------------------------- | +| `opus` | `anthropic/claude-opus-4-6` | +| `sonnet` | `anthropic/claude-sonnet-4-6` | +| `gpt` | `openai/gpt-5.4` | +| `gpt-mini` | `openai/gpt-5.4-mini` | +| `gpt-nano` | `openai/gpt-5.4-nano` | +| `gemini` | `google/gemini-3.1-pro-preview` | +| `gemini-flash` | `google/gemini-3-flash-preview` | | `gemini-flash-lite` | `google/gemini-3.1-flash-lite-preview` | -Ihre konfigurierten Aliasse haben immer Vorrang vor den Standardwerten. +Ihre konfigurierten Aliase haben immer Vorrang vor den Standardwerten. -Z.AI-GLM-4.x-Modelle aktivieren den Thinking-Modus automatisch, sofern Sie nicht `--thinking off` setzen oder `agents.defaults.models["zai/"].params.thinking` selbst definieren. +Z.AI-GLM-4.x-Modelle aktivieren automatisch den Denkmodus, sofern Sie nicht `--thinking off` setzen oder `agents.defaults.models["zai/"].params.thinking` selbst definieren. Z.AI-Modelle aktivieren standardmäßig `tool_stream` für Tool-Call-Streaming. Setzen Sie `agents.defaults.models["zai/"].params.tool_stream` auf `false`, um dies zu deaktivieren. -Anthropic Claude 4.6-Modelle verwenden standardmäßig `adaptive` thinking, wenn kein explizites Thinking-Level gesetzt ist. +Anthropic-Claude-4.6-Modelle verwenden standardmäßig `adaptive` Thinking, wenn keine explizite Thinking-Stufe gesetzt ist. ### `agents.defaults.cliBackends` -Optionale CLI-Backends für reine Text-Fallback-Läufe (ohne Tool-Aufrufe). Nützlich als Backup, wenn API-Provider ausfallen. +Optionale CLI-Backends für reine Text-Fallback-Läufe (ohne Tool-Calls). Nützlich als Backup, wenn API-Anbieter ausfallen. ```json5 { @@ -1178,13 +1179,13 @@ Optionale CLI-Backends für reine Text-Fallback-Läufe (ohne Tool-Aufrufe). Nüt } ``` -- CLI-Backends sind textorientiert; Tools sind immer deaktiviert. +- CLI-Backends sind textorientiert; Werkzeuge sind immer deaktiviert. - Sitzungen werden unterstützt, wenn `sessionArg` gesetzt ist. -- Bild-Durchleitung wird unterstützt, wenn `imageArg` Dateipfade akzeptiert. +- Bild-Durchreichung wird unterstützt, wenn `imageArg` Dateipfade akzeptiert. ### `agents.defaults.systemPromptOverride` -Ersetzt den gesamten von OpenClaw zusammengesetzten System-Prompt durch eine feste Zeichenfolge. Auf der Standardebene (`agents.defaults.systemPromptOverride`) oder pro Agent (`agents.list[].systemPromptOverride`) setzen. Werte pro Agent haben Vorrang; ein leerer oder nur aus Leerraum bestehender Wert wird ignoriert. Nützlich für kontrollierte Prompt-Experimente. +Ersetzt den gesamten von OpenClaw zusammengesetzten System-Prompt durch einen festen String. Setzen Sie ihn auf Standardebene (`agents.defaults.systemPromptOverride`) oder pro Agent (`agents.list[].systemPromptOverride`). Werte pro Agent haben Vorrang; ein leerer oder nur aus Leerraum bestehender Wert wird ignoriert. Nützlich für kontrollierte Prompt-Experimente. ```json5 { @@ -1208,9 +1209,9 @@ Periodische Heartbeat-Läufe. every: "30m", // 0m deaktiviert model: "openai/gpt-5.4-mini", includeReasoning: false, - includeSystemPromptSection: true, // Standard: true; false lässt den Heartbeat-Abschnitt im System-Prompt weg + includeSystemPromptSection: true, // Standard: true; false lässt den Heartbeat-Abschnitt aus dem System-Prompt weg lightContext: false, // Standard: false; true behält nur HEARTBEAT.md aus den Workspace-Bootstrap-Dateien - isolatedSession: false, // Standard: false; true führt jeden Heartbeat in einer neuen Sitzung aus (kein Gesprächsverlauf) + isolatedSession: false, // Standard: false; true führt jeden Heartbeat in einer neuen Sitzung aus (ohne Gesprächsverlauf) session: "main", to: "+15555550123", directPolicy: "allow", // allow (Standard) | block @@ -1225,15 +1226,15 @@ Periodische Heartbeat-Läufe. } ``` -- `every`: Dauerzeichenfolge (ms/s/m/h). Standard: `30m` (API-Key-Authentifizierung) oder `1h` (OAuth-Authentifizierung). Auf `0m` setzen, um zu deaktivieren. -- `includeSystemPromptSection`: wenn false, lässt den Heartbeat-Abschnitt im System-Prompt weg und überspringt die Einfügung von `HEARTBEAT.md` in den Bootstrap-Kontext. Standard: `true`. -- `suppressToolErrorWarnings`: wenn true, werden Tool-Fehlerwarn-Payloads während Heartbeat-Läufen unterdrückt. -- `timeoutSeconds`: maximal zulässige Zeit in Sekunden für einen Heartbeat-Agent-Turn, bevor er abgebrochen wird. Nicht setzen, um `agents.defaults.timeoutSeconds` zu verwenden. -- `directPolicy`: Richtlinie für direkte/DM-Zustellung. `allow` (Standard) erlaubt die direkte Zielzustellung. `block` unterdrückt die direkte Zielzustellung und erzeugt `reason=dm-blocked`. +- `every`: Dauer-String (ms/s/m/h). Standard: `30m` (API-Key-Authentifizierung) oder `1h` (OAuth-Authentifizierung). Setzen Sie `0m`, um dies zu deaktivieren. +- `includeSystemPromptSection`: wenn false, wird der Heartbeat-Abschnitt aus dem System-Prompt weggelassen und die Injektion von `HEARTBEAT.md` in den Bootstrap-Kontext übersprungen. Standard: `true`. +- `suppressToolErrorWarnings`: wenn true, werden Warn-Payloads für Tool-Fehler während Heartbeat-Läufen unterdrückt. +- `timeoutSeconds`: maximal zulässige Zeit in Sekunden für einen Heartbeat-Agent-Turn, bevor er abgebrochen wird. Wenn nicht gesetzt, wird `agents.defaults.timeoutSeconds` verwendet. +- `directPolicy`: Richtlinie für direkte/DM-Zustellung. `allow` (Standard) erlaubt direkte Zielzustellung. `block` unterdrückt direkte Zielzustellung und gibt `reason=dm-blocked` aus. - `lightContext`: wenn true, verwenden Heartbeat-Läufe einen leichtgewichtigen Bootstrap-Kontext und behalten nur `HEARTBEAT.md` aus den Workspace-Bootstrap-Dateien. -- `isolatedSession`: wenn true, wird jeder Heartbeat in einer neuen Sitzung ohne vorherigen Gesprächsverlauf ausgeführt. Gleiches Isolationsmuster wie bei Cron `sessionTarget: "isolated"`. Reduziert die Token-Kosten pro Heartbeat von etwa 100K auf etwa 2-5K Token. -- Pro Agent: setzen Sie `agents.list[].heartbeat`. Wenn irgendein Agent `heartbeat` definiert, führen **nur diese Agents** Heartbeats aus. -- Heartbeats führen vollständige Agent-Turns aus — kürzere Intervalle verbrauchen mehr Token. +- `isolatedSession`: wenn true, wird jeder Heartbeat in einer neuen Sitzung ohne vorherigen Gesprächsverlauf ausgeführt. Gleiches Isolationsmuster wie bei Cron `sessionTarget: "isolated"`. Reduziert die Token-Kosten pro Heartbeat von ca. 100K auf ca. 2–5K Tokens. +- Pro Agent: setzen Sie `agents.list[].heartbeat`. Wenn irgendein Agent `heartbeat` definiert, führen **nur diese Agenten** Heartbeats aus. +- Heartbeats führen vollständige Agent-Turns aus — kürzere Intervalle verbrauchen mehr Tokens. ### `agents.defaults.compaction` @@ -1247,15 +1248,15 @@ Periodische Heartbeat-Läufe. timeoutSeconds: 900, reserveTokensFloor: 24000, identifierPolicy: "strict", // strict | off | custom - identifierInstructions: "Deployment-IDs, Ticket-IDs und Host:Port-Paare exakt beibehalten.", // wird verwendet, wenn identifierPolicy=custom - postCompactionSections: ["Session Startup", "Red Lines"], // [] deaktiviert erneute Einfügung + identifierInstructions: "Preserve deployment IDs, ticket IDs, and host:port pairs exactly.", // verwendet, wenn identifierPolicy=custom + postCompactionSections: ["Session Startup", "Red Lines"], // [] deaktiviert die erneute Injektion model: "openrouter/anthropic/claude-sonnet-4-6", // optionale nur für Compaction geltende Modellüberschreibung - notifyUser: true, // sendet einen kurzen Hinweis, wenn die Compaction beginnt (Standard: false) + notifyUser: true, // sendet eine kurze Mitteilung, wenn Compaction beginnt (Standard: false) memoryFlush: { enabled: true, softThresholdTokens: 6000, - systemPrompt: "Sitzung nähert sich der Compaction. Dauerhafte Erinnerungen jetzt speichern.", - prompt: "Schreiben Sie alle bleibenden Notizen in memory/YYYY-MM-DD.md; antworten Sie mit dem exakten stillen Token NO_REPLY, wenn nichts gespeichert werden soll.", + systemPrompt: "Session nearing compaction. Store durable memories now.", + prompt: "Write any lasting notes to memory/YYYY-MM-DD.md; reply with the exact silent token NO_REPLY if nothing to store.", }, }, }, @@ -1263,19 +1264,19 @@ Periodische Heartbeat-Läufe. } ``` -- `mode`: `default` oder `safeguard` (chunkweise Zusammenfassung für lange Verläufe). Siehe [Compaction](/de/concepts/compaction). -- `provider`: ID eines registrierten Compaction-Provider-Plugins. Wenn gesetzt, wird `summarize()` des Providers anstelle der integrierten LLM-Zusammenfassung aufgerufen. Fällt bei Fehlern auf die integrierte Lösung zurück. Das Setzen eines Providers erzwingt `mode: "safeguard"`. Siehe [Compaction](/de/concepts/compaction). -- `timeoutSeconds`: maximal zulässige Sekunden für einen einzelnen Compaction-Vorgang, bevor OpenClaw ihn abbricht. Standard: `900`. -- `identifierPolicy`: `strict` (Standard), `off` oder `custom`. `strict` stellt der Compaction-Zusammenfassung integrierte Anweisungen zum Beibehalten undurchsichtiger Bezeichner voran. -- `identifierInstructions`: optionaler benutzerdefinierter Text zur Beibehaltung von Bezeichnern, verwendet bei `identifierPolicy=custom`. -- `postCompactionSections`: optionale AGENTS.md-H2-/H3-Abschnittsnamen, die nach der Compaction erneut eingefügt werden. Standard ist `["Session Startup", "Red Lines"]`; setzen Sie `[]`, um die erneute Einfügung zu deaktivieren. Wenn nicht gesetzt oder explizit auf dieses Standardpaar gesetzt, werden ältere Überschriften `Every Session`/`Safety` auch als Legacy-Fallback akzeptiert. -- `model`: optionale Überschreibung `provider/model-id` nur für die Compaction-Zusammenfassung. Verwenden Sie dies, wenn die Hauptsitzung ein Modell behalten soll, Compaction-Zusammenfassungen aber mit einem anderen Modell laufen sollen; wenn nicht gesetzt, verwendet die Compaction das primäre Modell der Sitzung. -- `notifyUser`: wenn `true`, sendet einen kurzen Hinweis an den Benutzer, wenn die Compaction beginnt (zum Beispiel „Kontext wird kompaktiert...“). Standardmäßig deaktiviert, damit die Compaction still bleibt. -- `memoryFlush`: stiller agentischer Turn vor der automatischen Compaction, um dauerhafte Erinnerungen zu speichern. Wird übersprungen, wenn der Workspace schreibgeschützt ist. +- `mode`: `default` oder `safeguard` (stückweise Zusammenfassung für lange Verläufe). Siehe [Compaction](/de/concepts/compaction). +- `provider`: ID eines registrierten Compaction-Provider-Plugins. Wenn gesetzt, wird `summarize()` des Providers anstelle der integrierten LLM-Zusammenfassung aufgerufen. Fällt bei Fehlern auf die integrierte Variante zurück. Das Setzen eines Providers erzwingt `mode: "safeguard"`. Siehe [Compaction](/de/concepts/compaction). +- `timeoutSeconds`: maximale Anzahl von Sekunden, die für einen einzelnen Compaction-Vorgang erlaubt ist, bevor OpenClaw ihn abbricht. Standard: `900`. +- `identifierPolicy`: `strict` (Standard), `off` oder `custom`. `strict` stellt der Compaction-Zusammenfassung integrierte Hinweise zum Beibehalten opaker Bezeichner voran. +- `identifierInstructions`: optionaler benutzerdefinierter Text zur Beibehaltung von Bezeichnern, der verwendet wird, wenn `identifierPolicy=custom`. +- `postCompactionSections`: optionale Abschnittsnamen (H2/H3) aus `AGENTS.md`, die nach der Compaction erneut injiziert werden. Standard ist `["Session Startup", "Red Lines"]`; setzen Sie `[]`, um die erneute Injektion zu deaktivieren. Wenn nicht gesetzt oder explizit auf dieses Standardpaar gesetzt, werden ältere Überschriften `Every Session`/`Safety` zusätzlich als Legacy-Fallback akzeptiert. +- `model`: optionale Überschreibung `provider/model-id` nur für die Compaction-Zusammenfassung. Verwenden Sie dies, wenn die Hauptsitzung ein Modell beibehalten soll, Compaction-Zusammenfassungen aber auf einem anderen Modell laufen sollen; wenn nicht gesetzt, verwendet Compaction das primäre Modell der Sitzung. +- `notifyUser`: wenn `true`, sendet beim Start der Compaction eine kurze Mitteilung an den Benutzer (zum Beispiel „Compacting context...“). Standardmäßig deaktiviert, damit Compaction still bleibt. +- `memoryFlush`: stiller agentischer Turn vor automatischer Compaction, um dauerhafte Erinnerungen zu speichern. Wird übersprungen, wenn der Workspace schreibgeschützt ist. ### `agents.defaults.contextPruning` -Entfernt **alte Tool-Ergebnisse** aus dem In-Memory-Kontext, bevor dieser an das LLM gesendet wird. Ändert **nicht** den Sitzungsverlauf auf der Festplatte. +Entfernt **alte Tool-Ergebnisse** aus dem In-Memory-Kontext, bevor er an das LLM gesendet wird. Ändert **nicht** den Sitzungsverlauf auf der Festplatte. ```json5 { @@ -1289,7 +1290,7 @@ Entfernt **alte Tool-Ergebnisse** aus dem In-Memory-Kontext, bevor dieser an das hardClearRatio: 0.5, minPrunableToolChars: 50000, softTrim: { maxChars: 4000, headChars: 1500, tailChars: 1500 }, - hardClear: { enabled: true, placeholder: "[Inhalt alter Tool-Ergebnisse entfernt]" }, + hardClear: { enabled: true, placeholder: "[Old tool result content cleared]" }, tools: { deny: ["browser", "canvas"] }, }, }, @@ -1297,25 +1298,25 @@ Entfernt **alte Tool-Ergebnisse** aus dem In-Memory-Kontext, bevor dieser an das } ``` - + - `mode: "cache-ttl"` aktiviert Pruning-Durchläufe. -- `ttl` steuert, wie oft das Pruning erneut ausgeführt werden kann (nach der letzten Cache-Berührung). -- Beim Pruning werden zuerst übergroße Tool-Ergebnisse weich gekürzt und danach bei Bedarf ältere Tool-Ergebnisse hart geleert. +- `ttl` steuert, wie oft Pruning erneut ausgeführt werden kann (nach dem letzten Cache-Touch). +- Pruning kürzt zuerst übergroße Tool-Ergebnisse weich und löscht bei Bedarf danach ältere Tool-Ergebnisse hart. -**Soft-Trim** behält Anfang + Ende und fügt `...` in der Mitte ein. +**Soft-Trim** behält Anfang + Ende bei und fügt in der Mitte `...` ein. **Hard-Clear** ersetzt das gesamte Tool-Ergebnis durch den Platzhalter. Hinweise: -- Bildblöcke werden niemals gekürzt/geleert. +- Bildblöcke werden niemals gekürzt/gelöscht. - Verhältnisse basieren auf Zeichen (ungefähr), nicht auf exakten Token-Anzahlen. -- Wenn weniger als `keepLastAssistants` Assistant-Nachrichten vorhanden sind, wird das Pruning übersprungen. +- Wenn weniger als `keepLastAssistants` Assistant-Nachrichten vorhanden sind, wird Pruning übersprungen. -Details zum Verhalten finden Sie unter [Session Pruning](/de/concepts/session-pruning). +Siehe [Session Pruning](/de/concepts/session-pruning) für Details zum Verhalten. ### Block-Streaming @@ -1337,7 +1338,7 @@ Details zum Verhalten finden Sie unter [Session Pruning](/de/concepts/session-pr - Kanalüberschreibungen: `channels..blockStreamingCoalesce` (und Varianten pro Konto). Signal/Slack/Discord/Google Chat verwenden standardmäßig `minChars: 1500`. - `humanDelay`: zufällige Pause zwischen Block-Antworten. `natural` = 800–2500 ms. Überschreibung pro Agent: `agents.list[].humanDelay`. -Verhaltens- und Chunking-Details finden Sie unter [Streaming](/de/concepts/streaming). +Siehe [Streaming](/de/concepts/streaming) für Verhalten und Details zur Aufteilung. ### Tippindikatoren @@ -1352,7 +1353,7 @@ Verhaltens- und Chunking-Details finden Sie unter [Streaming](/de/concepts/strea } ``` -- Standardwerte: `instant` für Direktchats/Erwähnungen, `message` für Gruppenchats ohne Erwähnung. +- Standardwerte: `instant` für direkte Chats/Erwähnungen, `message` für Gruppenchats ohne Erwähnung. - Überschreibungen pro Sitzung: `session.typingMode`, `session.typingIntervalSeconds`. Siehe [Typing Indicators](/de/concepts/typing-indicators). @@ -1361,7 +1362,7 @@ Siehe [Typing Indicators](/de/concepts/typing-indicators). ### `agents.defaults.sandbox` -Optionale Sandboxing-Funktion für den eingebetteten Agent. Die vollständige Anleitung finden Sie unter [Sandboxing](/de/gateway/sandboxing). +Optionale Sandbox-Ausführung für den eingebetteten Agenten. Den vollständigen Leitfaden finden Sie unter [Sandboxing](/de/gateway/sandboxing). ```json5 { @@ -1471,10 +1472,10 @@ Wenn `backend: "openshell"` ausgewählt ist, werden laufzeitspezifische Einstell - `target`: SSH-Ziel im Format `user@host[:port]` - `command`: SSH-Client-Befehl (Standard: `ssh`) -- `workspaceRoot`: absolutes Remote-Root, das für Workspaces pro Geltungsbereich verwendet wird +- `workspaceRoot`: absolutes Remote-Root, das für Workspaces pro Scope verwendet wird - `identityFile` / `certificateFile` / `knownHostsFile`: vorhandene lokale Dateien, die an OpenSSH übergeben werden - `identityData` / `certificateData` / `knownHostsData`: Inline-Inhalte oder SecretRefs, die OpenClaw zur Laufzeit in temporäre Dateien materialisiert -- `strictHostKeyChecking` / `updateHostKeys`: OpenSSH-Einstellungen für die Host-Key-Richtlinie +- `strictHostKeyChecking` / `updateHostKeys`: OpenSSH-Schalter für die Host-Key-Richtlinie **SSH-Authentifizierungspriorität:** @@ -1485,19 +1486,19 @@ Wenn `backend: "openshell"` ausgewählt ist, werden laufzeitspezifische Einstell **Verhalten des SSH-Backends:** -- initialisiert den Remote-Workspace einmal nach Erstellen oder Neuerstellen +- initialisiert den Remote-Workspace einmal nach Erstellung oder Neuerstellung - behält danach den Remote-SSH-Workspace als kanonisch bei -- leitet `exec`, Datei-Tools und Medienpfade über SSH +- leitet `exec`, Dateitools und Medienpfade über SSH - synchronisiert Remote-Änderungen nicht automatisch zurück zum Host - unterstützt keine Sandbox-Browser-Container **Workspace-Zugriff:** -- `none`: Sandbox-Workspace pro Geltungsbereich unter `~/.openclaw/sandboxes` +- `none`: Workspace pro Scope unter `~/.openclaw/sandboxes` - `ro`: Sandbox-Workspace unter `/workspace`, Agent-Workspace schreibgeschützt unter `/agent` eingehängt -- `rw`: Agent-Workspace schreibend/lesend unter `/workspace` eingehängt +- `rw`: Agent-Workspace unter `/workspace` mit Lese-/Schreibzugriff eingehängt -**Geltungsbereich:** +**Scope:** - `session`: Container + Workspace pro Sitzung - `agent`: ein Container + Workspace pro Agent (Standard) @@ -1531,27 +1532,27 @@ Wenn `backend: "openshell"` ausgewählt ist, werden laufzeitspezifische Einstell **OpenShell-Modus:** -- `mirror`: Remote vor `exec` aus lokalem Stand initialisieren, nach `exec` zurücksynchronisieren; der lokale Workspace bleibt kanonisch -- `remote`: Remote einmal beim Erstellen der Sandbox initialisieren, danach bleibt der Remote-Workspace kanonisch +- `mirror`: initialisiert Remote vor `exec` aus lokal, synchronisiert nach `exec` zurück; der lokale Workspace bleibt kanonisch +- `remote`: initialisiert Remote einmal bei der Erstellung der Sandbox, danach bleibt der Remote-Workspace kanonisch -Im Modus `remote` werden hostlokale Bearbeitungen außerhalb von OpenClaw nach dem Initialisierungsschritt nicht automatisch in die Sandbox synchronisiert. +Im Modus `remote` werden Host-lokale Bearbeitungen, die außerhalb von OpenClaw vorgenommen werden, nach dem Initialisierungsschritt nicht automatisch in die Sandbox synchronisiert. Der Transport erfolgt per SSH in die OpenShell-Sandbox, aber das Plugin verwaltet den Sandbox-Lebenszyklus und die optionale Mirror-Synchronisierung. -**`setupCommand`** wird einmal nach der Erstellung des Containers ausgeführt (über `sh -lc`). Benötigt ausgehenden Netzwerkzugriff, ein beschreibbares Root-Dateisystem und Root-Benutzer. +**`setupCommand`** wird einmal nach der Erstellung des Containers ausgeführt (über `sh -lc`). Benötigt ausgehenden Netzwerkzugriff, beschreibbares Root-Dateisystem und Root-Benutzer. -**Container verwenden standardmäßig `network: "none"`** — setzen Sie auf `"bridge"` (oder ein benutzerdefiniertes Bridge-Netzwerk), wenn der Agent ausgehenden Zugriff benötigt. -`"host"` ist blockiert. `"container:"` ist standardmäßig blockiert, sofern Sie nicht explizit -`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` setzen (Break-Glass). +**Container verwenden standardmäßig `network: "none"`** — setzen Sie es auf `"bridge"` (oder ein benutzerdefiniertes Bridge-Netzwerk), wenn der Agent ausgehenden Zugriff benötigt. +`"host"` ist blockiert. `"container:"` ist standardmäßig blockiert, außer Sie setzen explizit +`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (Break-Glass). **Eingehende Anhänge** werden in `media/inbound/*` im aktiven Workspace bereitgestellt. **`docker.binds`** bindet zusätzliche Host-Verzeichnisse ein; globale und agentbezogene Bindings werden zusammengeführt. -**Sandbox-Browser** (`sandbox.browser.enabled`): Chromium + CDP in einem Container. Die noVNC-URL wird in den System-Prompt eingefügt. Erfordert kein `browser.enabled` in `openclaw.json`. -Der noVNC-Beobachterzugriff verwendet standardmäßig VNC-Authentifizierung, und OpenClaw gibt eine URL mit kurzlebigem Token aus (anstatt das Passwort in der gemeinsam genutzten URL offenzulegen). +**Sandbox-Browser** (`sandbox.browser.enabled`): Chromium + CDP in einem Container. Die noVNC-URL wird in den System-Prompt injiziert. Erfordert kein `browser.enabled` in `openclaw.json`. +noVNC-Beobachterzugriff verwendet standardmäßig VNC-Authentifizierung, und OpenClaw gibt eine URL mit kurzlebigem Token aus (anstatt das Passwort in der geteilten URL offenzulegen). -- `allowHostControl: false` (Standard) blockiert, dass Sandbox-Sitzungen auf den Host-Browser zielen. -- `network` verwendet standardmäßig `openclaw-sandbox-browser` (dediziertes Bridge-Netzwerk). Setzen Sie es nur dann auf `bridge`, wenn Sie ausdrücklich globale Bridge-Konnektivität möchten. +- `allowHostControl: false` (Standard) blockiert, dass Sandbox-Sitzungen auf den Browser des Hosts zielen. +- `network` ist standardmäßig `openclaw-sandbox-browser` (dediziertes Bridge-Netzwerk). Setzen Sie es nur dann auf `bridge`, wenn Sie ausdrücklich globale Bridge-Konnektivität wünschen. - `cdpSourceRange` beschränkt optional eingehenden CDP-Zugriff am Container-Rand auf einen CIDR-Bereich (zum Beispiel `172.21.0.1/32`). - `sandbox.browser.binds` bindet zusätzliche Host-Verzeichnisse nur in den Sandbox-Browser-Container ein. Wenn gesetzt (einschließlich `[]`), ersetzt es `docker.binds` für den Browser-Container. - Start-Standards sind in `scripts/sandbox-browser-entrypoint.sh` definiert und auf Container-Hosts abgestimmt: @@ -1573,10 +1574,10 @@ Der noVNC-Beobachterzugriff verwendet standardmäßig VNC-Authentifizierung, und - `--metrics-recording-only` - `--disable-extensions` (standardmäßig aktiviert) - `--disable-3d-apis`, `--disable-software-rasterizer` und `--disable-gpu` sind standardmäßig aktiviert und können mit `OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0` deaktiviert werden, wenn WebGL-/3D-Nutzung dies erfordert. - - `OPENCLAW_BROWSER_DISABLE_EXTENSIONS=0` aktiviert Erweiterungen wieder, wenn Ihr Workflow davon abhängt. - - `--renderer-process-limit=2` kann mit `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=` geändert werden; setzen Sie `0`, um die Standard-Prozessgrenze von Chromium zu verwenden. - - plus `--no-sandbox` und `--disable-setuid-sandbox`, wenn `noSandbox` aktiviert ist. - - Die Standards bilden die Basis des Container-Images; verwenden Sie ein benutzerdefiniertes Browser-Image mit einem benutzerdefinierten Entry-Point, um die Container-Standards zu ändern. + - `OPENCLAW_BROWSER_DISABLE_EXTENSIONS=0` aktiviert Erweiterungen erneut, wenn Ihr Workflow davon abhängt. + - `--renderer-process-limit=2` kann mit `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=` geändert werden; setzen Sie `0`, um das Standard-Prozesslimit von Chromium zu verwenden. + - zusätzlich `--no-sandbox` und `--disable-setuid-sandbox`, wenn `noSandbox` aktiviert ist. + - Diese Standardwerte sind die Basis des Container-Images; verwenden Sie ein benutzerdefiniertes Browser-Image mit eigenem Entrypoint, um die Container-Standards zu ändern. @@ -1602,9 +1603,9 @@ scripts/sandbox-browser-setup.sh # optionales Browser-Image workspace: "~/.openclaw/workspace", agentDir: "~/.openclaw/agents/main/agent", model: "anthropic/claude-opus-4-6", // oder { primary, fallbacks } - thinkingDefault: "high", // Überschreibung des Standard-Thinking-Levels pro Agent + thinkingDefault: "high", // Überschreibung der Standard-Thinking-Stufe pro Agent reasoningDefault: "on", // Überschreibung der Standard-Sichtbarkeit von Reasoning pro Agent - fastModeDefault: false, // Überschreibung des Standard-Schnellmodus pro Agent + fastModeDefault: false, // Überschreibung des Standard-Fast-Mode pro Agent embeddedHarness: { runtime: "auto", fallback: "pi" }, params: { cacheRetention: "none" }, // überschreibt passende defaults.models-Parameter schlüsselweise skills: ["docs-search"], // ersetzt agents.defaults.skills, wenn gesetzt @@ -1639,26 +1640,26 @@ scripts/sandbox-browser-setup.sh # optionales Browser-Image ``` - `id`: stabile Agent-ID (erforderlich). -- `default`: wenn mehrere gesetzt sind, gewinnt der erste (Warnung wird protokolliert). Wenn keine gesetzt ist, ist der erste Listeneintrag der Standard. -- `model`: Die String-Form überschreibt nur `primary`; die Objektform `{ primary, fallbacks }` überschreibt beides (`[]` deaktiviert globale Fallbacks). Cron-Jobs, die nur `primary` überschreiben, erben weiterhin die Standard-Fallbacks, sofern Sie nicht `fallbacks: []` setzen. -- `params`: Stream-Parameter pro Agent, die über den ausgewählten Modelleintrag in `agents.defaults.models` gemergt werden. Verwenden Sie dies für agentenspezifische Überschreibungen wie `cacheRetention`, `temperature` oder `maxTokens`, ohne den gesamten Modellkatalog zu duplizieren. -- `skills`: optionale Skill-Allowlist pro Agent. Wenn weggelassen, erbt der Agent `agents.defaults.skills`, sofern gesetzt; eine explizite Liste ersetzt die Standards statt mit ihnen gemergt zu werden, und `[]` bedeutet keine Skills. -- `thinkingDefault`: optionales Standard-Thinking-Level pro Agent (`off | minimal | low | medium | high | xhigh | adaptive`). Überschreibt `agents.defaults.thinkingDefault` für diesen Agent, wenn keine Überschreibung pro Nachricht oder Sitzung gesetzt ist. -- `reasoningDefault`: optionale Standard-Sichtbarkeit von Reasoning pro Agent (`on | off | stream`). Gilt, wenn keine Überschreibung pro Nachricht oder Sitzung gesetzt ist. -- `fastModeDefault`: optionaler Standardwert pro Agent für den Schnellmodus (`true | false`). Gilt, wenn keine Überschreibung pro Nachricht oder Sitzung gesetzt ist. -- `embeddedHarness`: optionale Überschreibung der Low-Level-Harness-Richtlinie pro Agent. Verwenden Sie `{ runtime: "codex", fallback: "none" }`, um einen Agent nur auf Codex zu setzen, während andere Agents den Standard-PI-Fallback beibehalten. -- `runtime`: optionaler Laufzeit-Deskriptor pro Agent. Verwenden Sie `type: "acp"` mit `runtime.acp`-Standards (`agent`, `backend`, `mode`, `cwd`), wenn der Agent standardmäßig ACP-Harness-Sitzungen verwenden soll. -- `identity.avatar`: pfad relativ zum Workspace, `http(s)`-URL oder `data:`-URI. +- `default`: wenn mehrere gesetzt sind, gewinnt der erste (es wird eine Warnung protokolliert). Wenn keiner gesetzt ist, ist der erste Listeneintrag der Standard. +- `model`: Die String-Form überschreibt nur `primary`; die Objektform `{ primary, fallbacks }` überschreibt beide (`[]` deaktiviert globale Fallbacks). Cron-Jobs, die nur `primary` überschreiben, erben weiterhin Standard-Fallbacks, sofern Sie nicht `fallbacks: []` setzen. +- `params`: Stream-Parameter pro Agent, zusammengeführt über dem ausgewählten Modelleintrag in `agents.defaults.models`. Verwenden Sie dies für agentenspezifische Überschreibungen wie `cacheRetention`, `temperature` oder `maxTokens`, ohne den gesamten Modellkatalog zu duplizieren. +- `skills`: optionale Skill-Allowlist pro Agent. Wenn weggelassen, erbt der Agent `agents.defaults.skills`, falls gesetzt; eine explizite Liste ersetzt Standards statt sie zusammenzuführen, und `[]` bedeutet keine Skills. +- `thinkingDefault`: optionale Standard-Thinking-Stufe pro Agent (`off | minimal | low | medium | high | xhigh | adaptive`). Überschreibt `agents.defaults.thinkingDefault` für diesen Agenten, wenn keine Überschreibung pro Nachricht oder Sitzung gesetzt ist. +- `reasoningDefault`: optionale Standardsichtbarkeit von Reasoning pro Agent (`on | off | stream`). Gilt, wenn keine Reasoning-Überschreibung pro Nachricht oder Sitzung gesetzt ist. +- `fastModeDefault`: optionale Standardeinstellung pro Agent für den Fast Mode (`true | false`). Gilt, wenn keine Fast-Mode-Überschreibung pro Nachricht oder Sitzung gesetzt ist. +- `embeddedHarness`: optionale Überschreibung der Low-Level-Harness-Richtlinie pro Agent. Verwenden Sie `{ runtime: "codex", fallback: "none" }`, um einen Agenten auf Codex-only festzulegen, während andere Agenten den Standard-Pi-Fallback beibehalten. +- `runtime`: optionaler Runtime-Deskriptor pro Agent. Verwenden Sie `type: "acp"` mit `runtime.acp`-Standards (`agent`, `backend`, `mode`, `cwd`), wenn der Agent standardmäßig ACP-Harness-Sitzungen verwenden soll. +- `identity.avatar`: workspace-relativer Pfad, `http(s)`-URL oder `data:`-URI. - `identity` leitet Standardwerte ab: `ackReaction` aus `emoji`, `mentionPatterns` aus `name`/`emoji`. - `subagents.allowAgents`: Allowlist von Agent-IDs für `sessions_spawn` (`["*"]` = beliebig; Standard: nur derselbe Agent). -- Schutz bei Sandbox-Vererbung: Wenn die anfragende Sitzung in einer Sandbox läuft, lehnt `sessions_spawn` Ziele ab, die unsandboxed laufen würden. -- `subagents.requireAgentId`: wenn true, blockiert `sessions_spawn` Aufrufe ohne `agentId` (erzwingt explizite Profilauswahl; Standard: false). +- Sandbox-Vererbungsschutz: Wenn die anfragende Sitzung in einer Sandbox läuft, lehnt `sessions_spawn` Ziele ab, die unsandboxed ausgeführt würden. +- `subagents.requireAgentId`: wenn true, blockiert `sessions_spawn`-Aufrufe ohne `agentId` (erzwingt explizite Profilauswahl; Standard: false). --- ## Multi-Agent-Routing -Führen Sie mehrere isolierte Agents innerhalb eines Gateways aus. Siehe [Multi-Agent](/de/concepts/multi-agent). +Führen Sie mehrere isolierte Agenten innerhalb eines Gateway aus. Siehe [Multi-Agent](/de/concepts/multi-agent). ```json5 { @@ -1675,9 +1676,9 @@ Führen Sie mehrere isolierte Agents innerhalb eines Gateways aus. Siehe [Multi- } ``` -### Übereinstimmungsfelder für Bindings +### Felder für Binding-Matches -- `type` (optional): `route` für normales Routing (fehlender Typ bedeutet standardmäßig route), `acp` für persistente ACP-Konversationsbindungen. +- `type` (optional): `route` für normales Routing (fehlender Typ bedeutet standardmäßig `route`), `acp` für persistente ACP-Konversationsbindungen. - `match.channel` (erforderlich) - `match.accountId` (optional; `*` = beliebiges Konto; weggelassen = Standardkonto) - `match.peer` (optional; `{ kind: direct|group|channel, id }`) @@ -1689,17 +1690,17 @@ Führen Sie mehrere isolierte Agents innerhalb eines Gateways aus. Siehe [Multi- 1. `match.peer` 2. `match.guildId` 3. `match.teamId` -4. `match.accountId` (exakt, ohne Peer/Guild/Team) +4. `match.accountId` (exakt, ohne peer/guild/team) 5. `match.accountId: "*"` (kanalweit) 6. Standard-Agent -Innerhalb jeder Ebene gewinnt der erste passende `bindings`-Eintrag. +Innerhalb jeder Ebene gewinnt der erste passende Eintrag in `bindings`. -Für Einträge vom Typ `type: "acp"` löst OpenClaw nach exakter Konversationsidentität (`match.channel` + Konto + `match.peer.id`) auf und verwendet nicht die obige Reihenfolge der Route-Bindungsebenen. +Bei Einträgen vom Typ `type: "acp"` löst OpenClaw anhand der exakten Konversationsidentität auf (`match.channel` + Konto + `match.peer.id`) und verwendet nicht die obige Reihenfolge der Route-Binding-Ebenen. ### Zugriffsprofile pro Agent - + ```json5 { @@ -1717,7 +1718,7 @@ Für Einträge vom Typ `type: "acp"` löst OpenClaw nach exakter Konversationsid - + ```json5 { @@ -1826,14 +1827,14 @@ Details zur Priorität finden Sie unter [Multi-Agent Sandbox & Tools](/de/tools/ rotateBytes: "10mb", resetArchiveRetention: "30d", // Dauer oder false maxDiskBytes: "500mb", // optionales hartes Budget - highWaterBytes: "400mb", // optionales Bereinigungsziel + highWaterBytes: "400mb", // optionales Ziel für Bereinigung }, threadBindings: { enabled: true, idleHours: 24, // Standard für automatisches Entfokussieren bei Inaktivität in Stunden (`0` deaktiviert) maxAgeHours: 0, // Standard für hartes Maximalalter in Stunden (`0` deaktiviert) }, - mainKey: "main", // veraltet (Laufzeit verwendet immer "main") + mainKey: "main", // Legacy (die Runtime verwendet immer "main") agentToAgent: { maxPingPongTurns: 5 }, sendPolicy: { rules: [{ action: "deny", match: { channel: "discord", chatType: "group" } }], @@ -1845,35 +1846,35 @@ Details zur Priorität finden Sie unter [Multi-Agent Sandbox & Tools](/de/tools/ -- **`scope`**: grundlegende Gruppierungsstrategie für Sitzungen in Gruppenchats. - - `per-sender` (Standard): Jeder Absender erhält eine isolierte Sitzung innerhalb eines Kanalkontexts. - - `global`: Alle Teilnehmer in einem Kanalkontext teilen sich eine einzige Sitzung (nur verwenden, wenn gemeinsamer Kontext beabsichtigt ist). +- **`scope`**: grundlegende Strategie zur Sitzungsgruppierung für Gruppenchats. + - `per-sender` (Standard): Jeder Absender erhält eine isolierte Sitzung innerhalb eines Kanal-Kontexts. + - `global`: Alle Teilnehmer in einem Kanal-Kontext teilen sich eine einzige Sitzung (nur verwenden, wenn gemeinsamer Kontext beabsichtigt ist). - **`dmScope`**: wie DMs gruppiert werden. - `main`: Alle DMs teilen sich die Hauptsitzung. - - `per-peer`: Isolierung nach Absender-ID kanalübergreifend. - - `per-channel-peer`: Isolierung pro Kanal + Absender (empfohlen für Mehrbenutzer-Posteingänge). - - `per-account-channel-peer`: Isolierung pro Konto + Kanal + Absender (empfohlen für mehrere Konten). -- **`identityLinks`**: ordnet kanonische IDs providerpräfixierten Peers für kanalübergreifende gemeinsame Sitzungen zu. -- **`reset`**: primäre Zurücksetzungsrichtlinie. `daily` setzt um `atHour` lokaler Zeit zurück; `idle` setzt nach `idleMinutes` zurück. Wenn beide konfiguriert sind, gewinnt die zuerst ablaufende Regel. + - `per-peer`: Isolation nach Absender-ID kanalübergreifend. + - `per-channel-peer`: Isolation pro Kanal + Absender (empfohlen für Multi-User-Inboxes). + - `per-account-channel-peer`: Isolation pro Konto + Kanal + Absender (empfohlen für Multi-Account). +- **`identityLinks`**: ordnet kanonische IDs an anbieterpräfixierte Peers zu, um sitzungsübergreifendes Teilen zwischen Kanälen zu ermöglichen. +- **`reset`**: primäre Reset-Richtlinie. `daily` setzt bei `atHour` in lokaler Zeit zurück; `idle` setzt nach `idleMinutes` zurück. Wenn beides konfiguriert ist, gilt jeweils das zuerst ablaufende. - **`resetByType`**: Überschreibungen pro Typ (`direct`, `group`, `thread`). Legacy-`dm` wird als Alias für `direct` akzeptiert. -- **`parentForkMaxTokens`**: maximal zulässige `totalTokens` der übergeordneten Sitzung beim Erstellen einer geforkten Thread-Sitzung (Standard `100000`). - - Wenn `totalTokens` der übergeordneten Sitzung über diesem Wert liegt, startet OpenClaw eine neue Thread-Sitzung, statt den Verlauf der übergeordneten Sitzung zu übernehmen. - - Setzen Sie `0`, um diesen Schutz zu deaktivieren und das Forken aus der übergeordneten Sitzung immer zu erlauben. -- **`mainKey`**: Legacy-Feld. Die Laufzeit verwendet immer `"main"` für den Haupt-Bucket für Direktchats. -- **`agentToAgent.maxPingPongTurns`**: maximale Anzahl von Antwort-Rückantwort-Turns zwischen Agents während Agent-zu-Agent-Austauschvorgängen (Ganzzahl, Bereich: `0`–`5`). `0` deaktiviert Ping-Pong-Verkettung. -- **`sendPolicy`**: Abgleich nach `channel`, `chatType` (`direct|group|channel`, mit Legacy-Alias `dm`), `keyPrefix` oder `rawKeyPrefix`. Die erste Ablehnung gewinnt. -- **`maintenance`**: Bereinigungs- und Aufbewahrungssteuerung für den Sitzungsspeicher. +- **`parentForkMaxTokens`**: maximal erlaubte `totalTokens` der übergeordneten Sitzung beim Erstellen einer geforkten Thread-Sitzung (Standard `100000`). + - Wenn die `totalTokens` der übergeordneten Sitzung über diesem Wert liegen, startet OpenClaw eine neue Thread-Sitzung, statt den Verlauf des übergeordneten Transkripts zu erben. + - Setzen Sie `0`, um diesen Schutz zu deaktivieren und Parent-Forking immer zu erlauben. +- **`mainKey`**: Legacy-Feld. Die Runtime verwendet für den Hauptbucket direkter Chats immer `"main"`. +- **`agentToAgent.maxPingPongTurns`**: maximale Anzahl von Antwort-Turns zwischen Agenten bei Agent-zu-Agent-Austausch (Integer, Bereich: `0`–`5`). `0` deaktiviert Ping-Pong-Verkettung. +- **`sendPolicy`**: Match anhand von `channel`, `chatType` (`direct|group|channel`, mit Legacy-Alias `dm`), `keyPrefix` oder `rawKeyPrefix`. Das erste Deny gewinnt. +- **`maintenance`**: Steuerung für Bereinigung + Aufbewahrung des Sitzungsspeichers. - `mode`: `warn` gibt nur Warnungen aus; `enforce` wendet die Bereinigung an. - `pruneAfter`: Altersgrenze für veraltete Einträge (Standard `30d`). - - `maxEntries`: maximale Anzahl an Einträgen in `sessions.json` (Standard `500`). + - `maxEntries`: maximale Anzahl von Einträgen in `sessions.json` (Standard `500`). - `rotateBytes`: rotiert `sessions.json`, wenn diese Größe überschritten wird (Standard `10mb`). - - `resetArchiveRetention`: Aufbewahrung für Transcript-Archive vom Typ `*.reset.`. Standardmäßig `pruneAfter`; setzen Sie `false`, um dies zu deaktivieren. - - `maxDiskBytes`: optionales Festplattenbudget für das Sitzungsverzeichnis. Im Modus `warn` werden Warnungen protokolliert; im Modus `enforce` werden zuerst die ältesten Artefakte/Sitzungen entfernt. - - `highWaterBytes`: optionales Ziel nach Budget-Bereinigung. Standardmäßig `80%` von `maxDiskBytes`. + - `resetArchiveRetention`: Aufbewahrung für Transkriptarchive `*.reset.`. Standardmäßig `pruneAfter`; setzen Sie `false`, um dies zu deaktivieren. + - `maxDiskBytes`: optionales Speicherbudget für das Sitzungsverzeichnis. Im Modus `warn` werden Warnungen protokolliert; im Modus `enforce` werden zuerst die ältesten Artefakte/Sitzungen entfernt. + - `highWaterBytes`: optionales Ziel nach der Budgetbereinigung. Standardmäßig `80%` von `maxDiskBytes`. - **`threadBindings`**: globale Standardwerte für an Threads gebundene Sitzungsfunktionen. - - `enabled`: globaler Standard-Hauptschalter (Provider können ihn überschreiben; Discord verwendet `channels.discord.threadBindings.enabled`) - - `idleHours`: Standard für automatisches Entfokussieren bei Inaktivität in Stunden (`0` deaktiviert; Provider können überschreiben) - - `maxAgeHours`: Standard für das harte Maximalalter in Stunden (`0` deaktiviert; Provider können überschreiben) + - `enabled`: globaler Standardschalter (Anbieter können überschreiben; Discord verwendet `channels.discord.threadBindings.enabled`) + - `idleHours`: Standard für automatisches Entfokussieren bei Inaktivität in Stunden (`0` deaktiviert; Anbieter können überschreiben) + - `maxAgeHours`: Standard für hartes Maximalalter in Stunden (`0` deaktiviert; Anbieter können überschreiben) @@ -1913,34 +1914,34 @@ Details zur Priorität finden Sie unter [Multi-Agent Sandbox & Tools](/de/tools/ Überschreibungen pro Kanal/Konto: `channels..responsePrefix`, `channels..accounts..responsePrefix`. -Auflösung (spezifischstes gewinnt): Konto → Kanal → global. `""` deaktiviert und stoppt die Kaskade. `"auto"` leitet `[{identity.name}]` ab. +Auflösung (höchste Spezifität gewinnt): Konto → Kanal → global. `""` deaktiviert und stoppt die Kaskade. `"auto"` leitet `[{identity.name}]` ab. -**Vorlagenvariablen:** +**Template-Variablen:** | Variable | Beschreibung | Beispiel | | ----------------- | --------------------- | --------------------------- | | `{model}` | Kurzer Modellname | `claude-opus-4-6` | -| `{modelFull}` | Vollständige Modellkennung | `anthropic/claude-opus-4-6` | -| `{provider}` | Providername | `anthropic` | -| `{thinkingLevel}` | Aktuelles Thinking-Level | `high`, `low`, `off` | -| `{identity.name}` | Name der Agent-Identität | (entspricht `"auto"`) | +| `{modelFull}` | Vollständiger Modellbezeichner | `anthropic/claude-opus-4-6` | +| `{provider}` | Anbietername | `anthropic` | +| `{thinkingLevel}` | Aktuelle Thinking-Stufe | `high`, `low`, `off` | +| `{identity.name}` | Name der Agentenidentität | (wie bei `"auto"`) | -Variablen sind nicht groß-/kleinschreibungssensitiv. `{think}` ist ein Alias für `{thinkingLevel}`. +Variablen sind nicht case-sensitiv. `{think}` ist ein Alias für `{thinkingLevel}`. -### Ack-Reaktion +### Bestätigungsreaktion -- Verwendet standardmäßig `identity.emoji` des aktiven Agent, andernfalls `"👀"`. Setzen Sie `""`, um sie zu deaktivieren. +- Standardmäßig das `identity.emoji` des aktiven Agenten, andernfalls `"👀"`. Setzen Sie `""`, um dies zu deaktivieren. - Überschreibungen pro Kanal: `channels..ackReaction`, `channels..accounts..ackReaction`. - Auflösungsreihenfolge: Konto → Kanal → `messages.ackReaction` → Identity-Fallback. - Geltungsbereich: `group-mentions` (Standard), `group-all`, `direct`, `all`. -- `removeAckAfterReply`: entfernt die Ack-Reaktion nach der Antwort auf Slack, Discord und Telegram. -- `messages.statusReactions.enabled`: aktiviert Lebenszyklus-Statusreaktionen auf Slack, Discord und Telegram. - Auf Slack und Discord bleiben Statusreaktionen aktiviert, wenn Ack-Reaktionen aktiv sind und der Wert nicht gesetzt ist. - Auf Telegram setzen Sie ihn explizit auf `true`, um Lebenszyklus-Statusreaktionen zu aktivieren. +- `removeAckAfterReply`: entfernt die Bestätigungsreaktion nach der Antwort auf Slack, Discord und Telegram. +- `messages.statusReactions.enabled`: aktiviert Lifecycle-Statusreaktionen auf Slack, Discord und Telegram. + Bei Slack und Discord bleiben Statusreaktionen aktiviert, wenn Bestätigungsreaktionen aktiv sind und der Wert nicht gesetzt ist. + Bei Telegram setzen Sie ihn explizit auf `true`, um Lifecycle-Statusreaktionen zu aktivieren. -### Eingehendes Debounce +### Inbound-Debounce -Fasst schnelle reine Textnachrichten vom selben Absender zu einem einzigen Agent-Turn zusammen. Medien/Anhänge werden sofort geleert. Steuerbefehle umgehen das Debouncing. +Bündelt schnelle reine Textnachrichten vom selben Absender zu einem einzelnen Agent-Turn. Medien/Anhänge werden sofort geleert. Steuerbefehle umgehen Debouncing. ### TTS (Text-to-Speech) @@ -1983,12 +1984,12 @@ Fasst schnelle reine Textnachrichten vom selben Absender zu einem einzigen Agent } ``` -- `auto` steuert den Standardmodus für automatisches TTS: `off`, `always`, `inbound` oder `tagged`. `/tts on|off` kann lokale Einstellungen überschreiben, und `/tts status` zeigt den effektiven Zustand an. +- `auto` steuert den Standardmodus für Auto-TTS: `off`, `always`, `inbound` oder `tagged`. `/tts on|off` kann lokale Einstellungen überschreiben, und `/tts status` zeigt den effektiven Zustand an. - `summaryModel` überschreibt `agents.defaults.model.primary` für die automatische Zusammenfassung. - `modelOverrides` ist standardmäßig aktiviert; `modelOverrides.allowProvider` ist standardmäßig `false` (Opt-in). -- API-Schlüssel fallen auf `ELEVENLABS_API_KEY`/`XI_API_KEY` und `OPENAI_API_KEY` zurück. -- `openai.baseUrl` überschreibt den OpenAI-TTS-Endpunkt. Auflösungsreihenfolge: Konfiguration, dann `OPENAI_TTS_BASE_URL`, dann `https://api.openai.com/v1`. -- Wenn `openai.baseUrl` auf einen Nicht-OpenAI-Endpunkt zeigt, behandelt OpenClaw ihn als OpenAI-kompatiblen TTS-Server und lockert die Validierung von Modell und Stimme. +- API-Schlüssel greifen auf `ELEVENLABS_API_KEY`/`XI_API_KEY` und `OPENAI_API_KEY` zurück. +- `openai.baseUrl` überschreibt den OpenAI-TTS-Endpunkt. Die Auflösungsreihenfolge ist Konfiguration, dann `OPENAI_TTS_BASE_URL`, dann `https://api.openai.com/v1`. +- Wenn `openai.baseUrl` auf einen Nicht-OpenAI-Endpunkt zeigt, behandelt OpenClaw ihn als OpenAI-kompatiblen TTS-Server und lockert die Validierung von Modell/Stimme. --- @@ -2018,13 +2019,13 @@ Standardwerte für den Talk-Modus (macOS/iOS/Android). } ``` -- `talk.provider` muss einem Schlüssel in `talk.providers` entsprechen, wenn mehrere Talk-Provider konfiguriert sind. -- Veraltete flache Talk-Schlüssel (`talk.voiceId`, `talk.voiceAliases`, `talk.modelId`, `talk.outputFormat`, `talk.apiKey`) dienen nur der Kompatibilität und werden automatisch nach `talk.providers.` migriert. +- `talk.provider` muss einem Schlüssel in `talk.providers` entsprechen, wenn mehrere Talk-Anbieter konfiguriert sind. +- Legacy-flache Talk-Schlüssel (`talk.voiceId`, `talk.voiceAliases`, `talk.modelId`, `talk.outputFormat`, `talk.apiKey`) dienen nur der Kompatibilität und werden automatisch nach `talk.providers.` migriert. - Für Voice-IDs wird auf `ELEVENLABS_VOICE_ID` oder `SAG_VOICE_ID` zurückgegriffen. -- `providers.*.apiKey` akzeptiert Klartextzeichenfolgen oder SecretRef-Objekte. +- `providers.*.apiKey` akzeptiert Klartext-Strings oder SecretRef-Objekte. - Der Fallback `ELEVENLABS_API_KEY` gilt nur, wenn kein Talk-API-Schlüssel konfiguriert ist. -- `providers.*.voiceAliases` erlaubt Talk-Direktiven die Verwendung freundlicher Namen. -- `silenceTimeoutMs` steuert, wie lange der Talk-Modus nach dem Schweigen des Benutzers wartet, bevor das Transkript gesendet wird. Wenn nicht gesetzt, bleibt das plattformspezifische Standard-Pausenfenster erhalten (`700 ms auf macOS und Android, 900 ms auf iOS`). +- `providers.*.voiceAliases` erlaubt es Talk-Direktiven, benutzerfreundliche Namen zu verwenden. +- `silenceTimeoutMs` steuert, wie lange der Talk-Modus nach Stille des Benutzers wartet, bevor das Transkript gesendet wird. Wenn nicht gesetzt, bleibt das plattformspezifische Standard-Pausenfenster erhalten (`700 ms unter macOS und Android, 900 ms unter iOS`). --- @@ -2032,37 +2033,37 @@ Standardwerte für den Talk-Modus (macOS/iOS/Android). ### Tool-Profile -`tools.profile` setzt eine Basis-Allowlist vor `tools.allow`/`tools.deny`: +`tools.profile` legt eine Basis-Allowlist vor `tools.allow`/`tools.deny` fest: -Lokales Onboarding setzt für neue lokale Konfigurationen standardmäßig `tools.profile: "coding"`, wenn nichts gesetzt ist (bestehende explizite Profile bleiben erhalten). +Lokales Onboarding setzt neue lokale Konfigurationen standardmäßig auf `tools.profile: "coding"`, wenn kein Wert gesetzt ist (bestehende explizite Profile bleiben erhalten). | Profil | Enthält | | ----------- | ------------------------------------------------------------------------------------------------------------------------------- | | `minimal` | nur `session_status` | | `coding` | `group:fs`, `group:runtime`, `group:web`, `group:sessions`, `group:memory`, `cron`, `image`, `image_generate`, `video_generate` | -| `messaging` | `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` | +| `messaging` | `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` | | `full` | Keine Einschränkung (wie nicht gesetzt) | ### Tool-Gruppen -| Gruppe | Tools | -| ------------------ | ---------------------------------------------------------------------------------------------------------------------- | -| `group:runtime` | `exec`, `process`, `code_execution` (`bash` wird als Alias für `exec` akzeptiert) | -| `group:fs` | `read`, `write`, `edit`, `apply_patch` | +| Gruppe | Tools | +| ------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| `group:runtime` | `exec`, `process`, `code_execution` (`bash` wird als Alias für `exec` akzeptiert) | +| `group:fs` | `read`, `write`, `edit`, `apply_patch` | | `group:sessions` | `sessions_list`, `sessions_history`, `sessions_send`, `sessions_spawn`, `sessions_yield`, `subagents`, `session_status` | -| `group:memory` | `memory_search`, `memory_get` | -| `group:web` | `web_search`, `x_search`, `web_fetch` | -| `group:ui` | `browser`, `canvas` | -| `group:automation` | `cron`, `gateway` | -| `group:messaging` | `message` | -| `group:nodes` | `nodes` | -| `group:agents` | `agents_list` | -| `group:media` | `image`, `image_generate`, `video_generate`, `tts` | -| `group:openclaw` | Alle integrierten Tools (ohne Provider-Plugins) | +| `group:memory` | `memory_search`, `memory_get` | +| `group:web` | `web_search`, `x_search`, `web_fetch` | +| `group:ui` | `browser`, `canvas` | +| `group:automation` | `cron`, `gateway` | +| `group:messaging` | `message` | +| `group:nodes` | `nodes` | +| `group:agents` | `agents_list` | +| `group:media` | `image`, `image_generate`, `video_generate`, `tts` | +| `group:openclaw` | Alle integrierten Tools (Provider-Plugins ausgeschlossen) | ### `tools.allow` / `tools.deny` -Globale Tool-Allow-/Deny-Richtlinie (Deny gewinnt). Ohne Berücksichtigung der Groß-/Kleinschreibung, unterstützt `*`-Wildcards. Wird auch angewendet, wenn die Docker-Sandbox deaktiviert ist. +Globale Richtlinie zum Erlauben/Verweigern von Tools (Deny gewinnt). Groß-/Kleinschreibung wird ignoriert, `*`-Wildcards werden unterstützt. Wird auch angewendet, wenn die Docker-Sandbox deaktiviert ist. ```json5 { @@ -2072,7 +2073,7 @@ Globale Tool-Allow-/Deny-Richtlinie (Deny gewinnt). Ohne Berücksichtigung der G ### `tools.byProvider` -Schränkt Tools für bestimmte Provider oder Modelle weiter ein. Reihenfolge: Basisprofil → Provider-Profil → Allow/Deny. +Schränkt Tools für bestimmte Anbieter oder Modelle weiter ein. Reihenfolge: Basisprofil → Anbieterprofil → allow/deny. ```json5 { @@ -2088,7 +2089,7 @@ Schränkt Tools für bestimmte Provider oder Modelle weiter ein. Reihenfolge: Ba ### `tools.elevated` -Steuert erhöhten `exec`-Zugriff außerhalb der Sandbox: +Steuert erweiterten `exec`-Zugriff außerhalb der Sandbox: ```json5 { @@ -2105,8 +2106,8 @@ Steuert erhöhten `exec`-Zugriff außerhalb der Sandbox: ``` - Die Überschreibung pro Agent (`agents.list[].tools.elevated`) kann nur weiter einschränken. -- `/elevated on|off|ask|full` speichert den Status pro Sitzung; Inline-Direktiven gelten nur für eine einzelne Nachricht. -- Erhöhtes `exec` umgeht die Sandbox und verwendet den konfigurierten Escape-Pfad (`gateway` standardmäßig oder `node`, wenn das `exec`-Ziel `node` ist). +- `/elevated on|off|ask|full` speichert den Zustand pro Sitzung; Inline-Direktiven gelten nur für eine einzelne Nachricht. +- Erweitertes `exec` umgeht die Sandbox und verwendet den konfigurierten Escape-Pfad (`gateway` standardmäßig oder `node`, wenn das `exec`-Ziel `node` ist). ### `tools.exec` @@ -2152,10 +2153,10 @@ Einstellungen können global unter `tools.loopDetection` definiert und pro Agent } ``` -- `historySize`: maximaler Verlauf von Tool-Aufrufen, der für die Schleifenanalyse aufbewahrt wird. +- `historySize`: maximale Tool-Call-Historie, die für die Schleifenanalyse behalten wird. - `warningThreshold`: Schwellenwert für Warnungen bei sich wiederholenden Mustern ohne Fortschritt. - `criticalThreshold`: höherer Wiederholungsschwellenwert zum Blockieren kritischer Schleifen. -- `globalCircuitBreakerThreshold`: harter Stoppschwellenwert für jeden Lauf ohne Fortschritt. +- `globalCircuitBreakerThreshold`: harte Stoppschwelle für jeden Lauf ohne Fortschritt. - `detectors.genericRepeat`: warnt bei wiederholten Aufrufen desselben Tools mit denselben Argumenten. - `detectors.knownPollNoProgress`: warnt/blockiert bei bekannten Poll-Tools (`process.poll`, `command_status` usw.). - `detectors.pingPong`: warnt/blockiert bei alternierenden Paarmustern ohne Fortschritt. @@ -2176,7 +2177,7 @@ Einstellungen können global unter `tools.loopDetection` definiert und pro Agent }, fetch: { enabled: true, - provider: "firecrawl", // optional; weglassen für automatische Erkennung + provider: "firecrawl", // optional; für automatische Erkennung weglassen maxChars: 50000, maxCharsCap: 50000, maxResponseBytes: 2000000, @@ -2193,7 +2194,7 @@ Einstellungen können global unter `tools.loopDetection` definiert und pro Agent ### `tools.media` -Konfiguriert das Verstehen eingehender Medien (Bild/Audio/Video): +Konfiguriert das Verständnis eingehender Medien (Bild/Audio/Video): ```json5 { @@ -2201,7 +2202,7 @@ Konfiguriert das Verstehen eingehender Medien (Bild/Audio/Video): media: { concurrency: 2, asyncCompletion: { - directSend: false, // Opt-in: abgeschlossene asynchrone Musik/Videos direkt an den Kanal senden + directSend: false, // Opt-in: fertige asynchrone Musik/Videos direkt an den Kanal senden }, audio: { enabled: true, @@ -2225,18 +2226,18 @@ Konfiguriert das Verstehen eingehender Medien (Bild/Audio/Video): } ``` - + -**Provider-Eintrag** (`type: "provider"` oder weggelassen): +**Anbietereintrag** (`type: "provider"` oder weggelassen): -- `provider`: API-Provider-ID (`openai`, `anthropic`, `google`/`gemini`, `groq` usw.) +- `provider`: ID des API-Anbieters (`openai`, `anthropic`, `google`/`gemini`, `groq` usw.) - `model`: Überschreibung der Modell-ID -- `profile` / `preferredProfile`: Profilauswahl aus `auth-profiles.json` +- `profile` / `preferredProfile`: Auswahl des Profils aus `auth-profiles.json` **CLI-Eintrag** (`type: "cli"`): - `command`: auszuführende Datei -- `args`: vorlagenbasierte Argumente (unterstützt `{{MediaPath}}`, `{{Prompt}}`, `{{MaxChars}}` usw.) +- `args`: templatebasierte Argumente (unterstützt `{{MediaPath}}`, `{{Prompt}}`, `{{MaxChars}}` usw.) **Gemeinsame Felder:** @@ -2244,11 +2245,11 @@ Konfiguriert das Verstehen eingehender Medien (Bild/Audio/Video): - `prompt`, `maxChars`, `maxBytes`, `timeoutSeconds`, `language`: Überschreibungen pro Eintrag. - Bei Fehlern wird auf den nächsten Eintrag zurückgegriffen. -Die Provider-Authentifizierung folgt der Standardreihenfolge: `auth-profiles.json` → Umgebungsvariablen → `models.providers.*.apiKey`. +Die Anbieter-Authentifizierung folgt der Standardreihenfolge: `auth-profiles.json` → Umgebungsvariablen → `models.providers.*.apiKey`. -**Felder für asynchrone Abschlüsse:** +**Felder für asynchrone Fertigstellung:** -- `asyncCompletion.directSend`: wenn `true`, versuchen abgeschlossene asynchrone Aufgaben von `music_generate` und `video_generate` zuerst die direkte Zustellung an den Kanal. Standard: `false` (Legacy-Pfad über anfordernde Sitzung/Aufwecken/Modellzustellung). +- `asyncCompletion.directSend`: wenn `true`, versuchen abgeschlossene asynchrone Aufgaben von `music_generate` und `video_generate` zuerst die direkte Kanalzustellung. Standard: `false` (Legacy-Pfad über Requester-Sitzungs-Weckung/Modellzustellung). @@ -2267,9 +2268,9 @@ Die Provider-Authentifizierung folgt der Standardreihenfolge: `auth-profiles.jso ### `tools.sessions` -Steuert, welche Sitzungen von den Sitzungs-Tools (`sessions_list`, `sessions_history`, `sessions_send`) angesprochen werden können. +Steuert, welche Sitzungen mit den Sitzungstools (`sessions_list`, `sessions_history`, `sessions_send`) adressiert werden können. -Standard: `tree` (aktuelle Sitzung + von ihr gestartete Sitzungen, wie Subagents). +Standard: `tree` (aktuelle Sitzung + von ihr erzeugte Sitzungen, etwa Subagenten). ```json5 { @@ -2285,14 +2286,14 @@ Standard: `tree` (aktuelle Sitzung + von ihr gestartete Sitzungen, wie Subagents Hinweise: - `self`: nur der aktuelle Sitzungsschlüssel. -- `tree`: aktuelle Sitzung + von der aktuellen Sitzung gestartete Sitzungen (Subagents). -- `agent`: jede Sitzung, die zur aktuellen Agent-ID gehört (kann auch andere Benutzer einschließen, wenn Sie Pro-Absender-Sitzungen unter derselben Agent-ID ausführen). +- `tree`: aktuelle Sitzung + von der aktuellen Sitzung erzeugte Sitzungen (Subagenten). +- `agent`: jede Sitzung, die zur aktuellen Agent-ID gehört (kann auch andere Benutzer einschließen, wenn Sie Sitzungen pro Absender unter derselben Agent-ID ausführen). - `all`: jede Sitzung. Kanalübergreifendes Targeting erfordert weiterhin `tools.agentToAgent`. -- Sandbox-Begrenzung: Wenn die aktuelle Sitzung in einer Sandbox läuft und `agents.defaults.sandbox.sessionToolsVisibility="spawned"` gesetzt ist, wird die Sichtbarkeit auf `tree` erzwungen, selbst wenn `tools.sessions.visibility="all"` gesetzt ist. +- Sandbox-Klammerung: Wenn die aktuelle Sitzung in einer Sandbox läuft und `agents.defaults.sandbox.sessionToolsVisibility="spawned"` gesetzt ist, wird die Sichtbarkeit auf `tree` erzwungen, selbst wenn `tools.sessions.visibility="all"` ist. ### `tools.sessions_spawn` -Steuert die Unterstützung für Inline-Anhänge bei `sessions_spawn`. +Steuert die Unterstützung von Inline-Anhängen für `sessions_spawn`. ```json5 { @@ -2303,7 +2304,7 @@ Steuert die Unterstützung für Inline-Anhänge bei `sessions_spawn`. maxTotalBytes: 5242880, // insgesamt 5 MB über alle Dateien maxFiles: 50, maxFileBytes: 1048576, // 1 MB pro Datei - retainOnSessionKeep: false, // Anhänge beibehalten, wenn cleanup="keep" + retainOnSessionKeep: false, // Anhänge behalten, wenn cleanup="keep" }, }, }, @@ -2312,16 +2313,16 @@ Steuert die Unterstützung für Inline-Anhänge bei `sessions_spawn`. Hinweise: -- Anhänge werden nur für `runtime: "subagent"` unterstützt. Die ACP-Laufzeit lehnt sie ab. +- Anhänge werden nur für `runtime: "subagent"` unterstützt. Die ACP-Runtime lehnt sie ab. - Dateien werden im Child-Workspace unter `.openclaw/attachments//` mit einer `.manifest.json` materialisiert. -- Anhangsinhalte werden automatisch aus der Transcript-Persistenz redigiert. -- Base64-Eingaben werden mit strikten Alphabet-/Padding-Prüfungen und einer Größenprüfung vor dem Decodieren validiert. +- Der Inhalt von Anhängen wird automatisch aus der persistenten Transkriptspeicherung entfernt. +- Base64-Eingaben werden mit strikter Alphabet-/Padding-Prüfung und einer Größenprüfung vor dem Dekodieren validiert. - Dateiberechtigungen sind `0700` für Verzeichnisse und `0600` für Dateien. -- Die Bereinigung folgt der `cleanup`-Richtlinie: `delete` entfernt Anhänge immer; `keep` behält sie nur, wenn `retainOnSessionKeep: true`. +- Die Bereinigung folgt der Richtlinie `cleanup`: `delete` entfernt Anhänge immer; `keep` behält sie nur, wenn `retainOnSessionKeep: true` gesetzt ist. ### `tools.experimental` -Experimentelle integrierte Tool-Flags. Standardmäßig deaktiviert, außer wenn eine Regel zur automatischen Aktivierung für streng-agentisches GPT-5 greift. +Experimentelle integrierte Tool-Flags. Standardmäßig deaktiviert, sofern keine Regel zur automatischen Aktivierung für strikt agentisches GPT-5 greift. ```json5 { @@ -2335,9 +2336,9 @@ Experimentelle integrierte Tool-Flags. Standardmäßig deaktiviert, außer wenn Hinweise: -- `planTool`: aktiviert das strukturierte Tool `update_plan` zur Nachverfolgung nicht-trivialer mehrstufiger Arbeit. -- Standard: `false`, außer wenn `agents.defaults.embeddedPi.executionContract` (oder eine Überschreibung pro Agent) für einen Lauf mit OpenAI- oder OpenAI-Codex-GPT-5-Familie auf `"strict-agentic"` gesetzt ist. Setzen Sie `true`, um das Tool außerhalb dieses Bereichs zu erzwingen, oder `false`, um es selbst bei streng-agentischen GPT-5-Läufen deaktiviert zu lassen. -- Wenn aktiviert, fügt der System-Prompt auch Nutzungshinweise hinzu, damit das Modell es nur für umfangreiche Arbeit verwendet und höchstens einen Schritt als `in_progress` markiert. +- `planTool`: aktiviert das strukturierte Tool `update_plan` zur Nachverfolgung nichttrivialer mehrstufiger Arbeit. +- Standard: `false`, sofern nicht `agents.defaults.embeddedPi.executionContract` (oder eine Überschreibung pro Agent) für einen Lauf mit OpenAI oder OpenAI Codex der GPT-5-Familie auf `"strict-agentic"` gesetzt ist. Setzen Sie `true`, um das Tool auch außerhalb dieses Bereichs zu erzwingen, oder `false`, um es selbst für strikt agentische GPT-5-Läufe deaktiviert zu lassen. +- Wenn aktiviert, fügt der System-Prompt auch Nutzungshinweise hinzu, sodass das Modell es nur für umfangreichere Arbeit verwendet und höchstens einen Schritt als `in_progress` hält. ### `agents.defaults.subagents` @@ -2357,16 +2358,16 @@ Hinweise: } ``` -- `model`: Standardmodell für gestartete Sub-Agents. Wenn nicht gesetzt, erben Sub-Agents das Modell des Aufrufers. -- `allowAgents`: Standard-Allowlist der Ziel-Agent-IDs für `sessions_spawn`, wenn der anfordernde Agent keine eigene `subagents.allowAgents` setzt (`["*"]` = beliebig; Standard: nur derselbe Agent). -- `runTimeoutSeconds`: Standard-Timeout (Sekunden) für `sessions_spawn`, wenn der Tool-Aufruf `runTimeoutSeconds` nicht angibt. `0` bedeutet kein Timeout. +- `model`: Standardmodell für erzeugte Subagenten. Wenn nicht gesetzt, erben Subagenten das Modell des Aufrufers. +- `allowAgents`: Standard-Allowlist der Ziel-Agent-IDs für `sessions_spawn`, wenn der anfragende Agent nicht selbst `subagents.allowAgents` setzt (`["*"]` = beliebig; Standard: nur derselbe Agent). +- `runTimeoutSeconds`: Standard-Timeout (Sekunden) für `sessions_spawn`, wenn der Tool-Aufruf `runTimeoutSeconds` weglässt. `0` bedeutet kein Timeout. - Tool-Richtlinie pro Subagent: `tools.subagents.tools.allow` / `tools.subagents.tools.deny`. --- -## Benutzerdefinierte Provider und Base-URLs +## Benutzerdefinierte Anbieter und Base-URLs -OpenClaw verwendet den integrierten Modellkatalog. Fügen Sie benutzerdefinierte Provider über `models.providers` in der Konfiguration oder `~/.openclaw/agents//agent/models.json` hinzu. +OpenClaw verwendet den integrierten Modellkatalog. Fügen Sie benutzerdefinierte Anbieter über `models.providers` in der Konfiguration oder `~/.openclaw/agents//agent/models.json` hinzu. ```json5 { @@ -2397,48 +2398,48 @@ OpenClaw verwendet den integrierten Modellkatalog. Fügen Sie benutzerdefinierte - Verwenden Sie `authHeader: true` + `headers` für benutzerdefinierte Authentifizierungsanforderungen. - Überschreiben Sie das Root der Agent-Konfiguration mit `OPENCLAW_AGENT_DIR` (oder `PI_CODING_AGENT_DIR`, einem Legacy-Alias für Umgebungsvariablen). -- Merge-Priorität für übereinstimmende Provider-IDs: - - Nicht leere `baseUrl`-Werte aus `models.json` des Agent haben Vorrang. - - Nicht leere `apiKey`-Werte des Agent haben nur dann Vorrang, wenn dieser Provider im aktuellen Kontext von config/auth-profile nicht über SecretRef verwaltet wird. - - Über SecretRef verwaltete Provider-`apiKey`-Werte werden aus Quellmarkierungen aktualisiert (`ENV_VAR_NAME` für Env-Refs, `secretref-managed` für Datei-/Exec-Refs), statt aufgelöste Secrets zu persistieren. - - Über SecretRef verwaltete Provider-Headerwerte werden aus Quellmarkierungen aktualisiert (`secretref-env:ENV_VAR_NAME` für Env-Refs, `secretref-managed` für Datei-/Exec-Refs). - - Leere oder fehlende `apiKey`-/`baseUrl`-Werte des Agent fallen auf `models.providers` in der Konfiguration zurück. - - Für übereinstimmende Modelle verwenden `contextWindow`/`maxTokens` den höheren Wert zwischen expliziter Konfiguration und impliziten Katalogwerten. - - Übereinstimmende `contextTokens` bewahren einen expliziten Laufzeitgrenzwert, wenn vorhanden; verwenden Sie ihn, um den effektiven Kontext zu begrenzen, ohne native Modellmetadaten zu ändern. +- Merge-Priorität für übereinstimmende Anbieter-IDs: + - Nicht leere `baseUrl`-Werte aus `models.json` des Agenten haben Vorrang. + - Nicht leere `apiKey`-Werte des Agenten haben nur dann Vorrang, wenn dieser Anbieter im aktuellen Kontext von Konfiguration/Auth-Profil nicht über SecretRef verwaltet wird. + - SecretRef-verwaltete `apiKey`-Werte des Anbieters werden aus Quellenmarkierungen aktualisiert (`ENV_VAR_NAME` für env-Referenzen, `secretref-managed` für file-/exec-Referenzen), statt aufgelöste Secrets zu persistieren. + - SecretRef-verwaltete Header-Werte des Anbieters werden aus Quellenmarkierungen aktualisiert (`secretref-env:ENV_VAR_NAME` für env-Referenzen, `secretref-managed` für file-/exec-Referenzen). + - Leere oder fehlende `apiKey`-/`baseUrl`-Werte des Agenten greifen auf `models.providers` in der Konfiguration zurück. + - Übereinstimmende `contextWindow`-/`maxTokens`-Werte des Modells verwenden den höheren Wert zwischen expliziter Konfiguration und impliziten Katalogwerten. + - Übereinstimmende `contextTokens` behalten ein explizites Laufzeitlimit bei, wenn vorhanden; verwenden Sie dies, um den effektiven Kontext zu begrenzen, ohne native Modellmetadaten zu ändern. - Verwenden Sie `models.mode: "replace"`, wenn die Konfiguration `models.json` vollständig neu schreiben soll. - - Die Persistenz von Markierungen ist quellenautoritativ: Markierungen werden aus dem aktiven Konfigurations-Snapshot der Quelle (vor der Auflösung) geschrieben, nicht aus aufgelösten Laufzeit-Secret-Werten. + - Die Persistenz von Markierungen ist quellenautoritativ: Markierungen werden aus dem aktiven Quellkonfigurations-Snapshot (vor der Auflösung) geschrieben, nicht aus aufgelösten Secret-Werten der Laufzeit. -### Details zu Provider-Feldern +### Details zu Anbieterfeldern -- `models.mode`: Verhalten des Provider-Katalogs (`merge` oder `replace`). -- `models.providers`: benutzerdefinierte Provider-Zuordnung, indiziert nach Provider-ID. +- `models.mode`: Verhalten des Anbieter-Katalogs (`merge` oder `replace`). +- `models.providers`: benutzerdefinierte Anbieterzuordnung, indiziert nach Anbieter-ID. - `models.providers.*.api`: Request-Adapter (`openai-completions`, `openai-responses`, `anthropic-messages`, `google-generative-ai` usw.). -- `models.providers.*.apiKey`: Provider-Zugangsdaten (bevorzugt über SecretRef/Umgebungsvariablen-Substitution). +- `models.providers.*.apiKey`: Anbieter-Anmeldedaten (bevorzugt SecretRef/env-Substitution verwenden). - `models.providers.*.auth`: Authentifizierungsstrategie (`api-key`, `token`, `oauth`, `aws-sdk`). -- `models.providers.*.injectNumCtxForOpenAICompat`: für Ollama + `openai-completions`, `options.num_ctx` in Anfragen einfügen (Standard: `true`). -- `models.providers.*.authHeader`: Transport der Zugangsdaten im `Authorization`-Header erzwingen, wenn erforderlich. +- `models.providers.*.injectNumCtxForOpenAICompat`: für Ollama + `openai-completions` `options.num_ctx` in Requests injizieren (Standard: `true`). +- `models.providers.*.authHeader`: erzwingt bei Bedarf die Übertragung von Anmeldedaten im Header `Authorization`. - `models.providers.*.baseUrl`: Base-URL der Upstream-API. - `models.providers.*.headers`: zusätzliche statische Header für Proxy-/Mandanten-Routing. -- `models.providers.*.request`: Transport-Überschreibungen für HTTP-Anfragen an Modell-Provider. - - `request.headers`: zusätzliche Header (mit Provider-Standards zusammengeführt). Werte akzeptieren SecretRef. - - `request.auth`: Überschreibung der Authentifizierungsstrategie. Modi: `"provider-default"` (integrierte Authentifizierung des Providers verwenden), `"authorization-bearer"` (mit `token`), `"header"` (mit `headerName`, `value`, optional `prefix`). - - `request.proxy`: Überschreibung des HTTP-Proxys. Modi: `"env-proxy"` (Umgebungsvariablen `HTTP_PROXY`/`HTTPS_PROXY` verwenden), `"explicit-proxy"` (mit `url`). Beide Modi akzeptieren optional ein `tls`-Unterobjekt. +- `models.providers.*.request`: Transport-Überschreibungen für HTTP-Requests von Modellanbietern. + - `request.headers`: zusätzliche Header (werden mit den Standardwerten des Anbieters zusammengeführt). Werte akzeptieren SecretRef. + - `request.auth`: Überschreibung der Authentifizierungsstrategie. Modi: `"provider-default"` (integrierte Auth des Anbieters verwenden), `"authorization-bearer"` (mit `token`), `"header"` (mit `headerName`, `value`, optional `prefix`). + - `request.proxy`: Überschreibung des HTTP-Proxys. Modi: `"env-proxy"` (Umgebungsvariablen `HTTP_PROXY`/`HTTPS_PROXY` verwenden), `"explicit-proxy"` (mit `url`). Beide Modi akzeptieren ein optionales Unterobjekt `tls`. - `request.tls`: TLS-Überschreibung für direkte Verbindungen. Felder: `ca`, `cert`, `key`, `passphrase` (alle akzeptieren SecretRef), `serverName`, `insecureSkipVerify`. - - `request.allowPrivateNetwork`: wenn `true`, HTTPS zu `baseUrl` erlauben, wenn DNS auf private, CGNAT- oder ähnliche Bereiche auflöst, über den HTTP-Fetch-Schutz des Providers (Opt-in für Operatoren bei vertrauenswürdigen selbstgehosteten OpenAI-kompatiblen Endpunkten). WebSocket verwendet dieselbe `request` für Header/TLS, aber nicht diesen Fetch-SSRF-Schutz. Standard `false`. -- `models.providers.*.models`: explizite Modellkatalogeinträge des Providers. + - `request.allowPrivateNetwork`: wenn `true`, erlaubt HTTPS zu `baseUrl`, wenn DNS auf private, CGNAT- oder ähnliche Bereiche auflöst, über die HTTP-Fetch-Schutzlogik des Anbieters (Opt-in für Operatoren bei vertrauenswürdigen selbstgehosteten OpenAI-kompatiblen Endpunkten). WebSocket verwendet dieselbe `request` für Header/TLS, aber nicht diese SSRF-Schutzlogik für Fetch. Standard `false`. +- `models.providers.*.models`: explizite Modellsatzeinträge des Anbieters. - `models.providers.*.models.*.contextWindow`: Metadaten des nativen Modell-Kontextfensters. -- `models.providers.*.models.*.contextTokens`: optionale Laufzeitgrenze für den Kontext. Verwenden Sie dies, wenn Sie ein kleineres effektives Kontextbudget als das native `contextWindow` des Modells wünschen. -- `models.providers.*.models.*.compat.supportsDeveloperRole`: optionaler Kompatibilitätshinweis. Für `api: "openai-completions"` mit einer nicht leeren, nicht nativen `baseUrl` (Host nicht `api.openai.com`) erzwingt OpenClaw zur Laufzeit `false`. Bei leerer/weggelassener `baseUrl` bleibt das Standardverhalten von OpenAI erhalten. -- `models.providers.*.models.*.compat.requiresStringContent`: optionaler Kompatibilitätshinweis für reine String-OpenAI-kompatible Chat-Endpunkte. Wenn `true`, flacht OpenClaw reine Text-Arrays in `messages[].content` vor dem Senden der Anfrage zu einfachen Strings ab. -- `plugins.entries.amazon-bedrock.config.discovery`: Root der Bedrock-Einstellungen für automatische Erkennung. +- `models.providers.*.models.*.contextTokens`: optionales Laufzeitlimit für den Kontext. Verwenden Sie dies, wenn Sie ein kleineres effektives Kontextbudget als das native `contextWindow` des Modells möchten. +- `models.providers.*.models.*.compat.supportsDeveloperRole`: optionaler Kompatibilitätshinweis. Für `api: "openai-completions"` mit einer nicht leeren, nicht nativen `baseUrl` (Host nicht `api.openai.com`) erzwingt OpenClaw dies zur Laufzeit auf `false`. Leere/weggelassene `baseUrl` behält das Standardverhalten von OpenAI bei. +- `models.providers.*.models.*.compat.requiresStringContent`: optionaler Kompatibilitätshinweis für OpenAI-kompatible Chat-Endpunkte, die nur Strings unterstützen. Wenn `true`, flacht OpenClaw reine Text-Arrays in `messages[].content` vor dem Senden des Requests zu einfachen Strings ab. +- `plugins.entries.amazon-bedrock.config.discovery`: Root für Bedrock-Einstellungen zur automatischen Erkennung. - `plugins.entries.amazon-bedrock.config.discovery.enabled`: implizite Erkennung ein-/ausschalten. - `plugins.entries.amazon-bedrock.config.discovery.region`: AWS-Region für die Erkennung. -- `plugins.entries.amazon-bedrock.config.discovery.providerFilter`: optionaler Provider-ID-Filter für gezielte Erkennung. -- `plugins.entries.amazon-bedrock.config.discovery.refreshInterval`: Polling-Intervall für das Aktualisieren der Erkennung. +- `plugins.entries.amazon-bedrock.config.discovery.providerFilter`: optionaler Filter nach Anbieter-ID für gezielte Erkennung. +- `plugins.entries.amazon-bedrock.config.discovery.refreshInterval`: Polling-Intervall für die Aktualisierung der Erkennung. - `plugins.entries.amazon-bedrock.config.discovery.defaultContextWindow`: Fallback-Kontextfenster für erkannte Modelle. -- `plugins.entries.amazon-bedrock.config.discovery.defaultMaxTokens`: Fallback für maximale Ausgabetoken bei erkannten Modellen. +- `plugins.entries.amazon-bedrock.config.discovery.defaultMaxTokens`: Fallback für maximale Ausgabetokens erkannter Modelle. -### Provider-Beispiele +### Anbieterbeispiele @@ -2474,7 +2475,7 @@ OpenClaw verwendet den integrierten Modellkatalog. Fügen Sie benutzerdefinierte } ``` -Verwenden Sie `cerebras/zai-glm-4.7` für Cerebras; `zai/glm-4.7` für Z.AI direkt. +Verwenden Sie `cerebras/zai-glm-4.7` für Cerebras; `zai/glm-4.7` für direktes Z.AI. @@ -2508,11 +2509,11 @@ Setzen Sie `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`). Verwenden Sie `open } ``` -Setzen Sie `ZAI_API_KEY`. `z.ai/*` und `z-ai/*` sind akzeptierte Aliasse. Kurzform: `openclaw onboard --auth-choice zai-api-key`. +Setzen Sie `ZAI_API_KEY`. `z.ai/*` und `z-ai/*` werden als Aliase akzeptiert. Kurzform: `openclaw onboard --auth-choice zai-api-key`. - Allgemeiner Endpunkt: `https://api.z.ai/api/paas/v4` - Coding-Endpunkt (Standard): `https://api.z.ai/api/coding/paas/v4` -- Für den allgemeinen Endpunkt definieren Sie einen benutzerdefinierten Provider mit einer Überschreibung der Base-URL. +- Für den allgemeinen Endpunkt definieren Sie einen benutzerdefinierten Anbieter mit Überschreibung der Base-URL. @@ -2553,7 +2554,7 @@ Setzen Sie `ZAI_API_KEY`. `z.ai/*` und `z-ai/*` sind akzeptierte Aliasse. Kurzfo Für den China-Endpunkt: `baseUrl: "https://api.moonshot.cn/v1"` oder `openclaw onboard --auth-choice moonshot-api-key-cn`. -Native Moonshot-Endpunkte deklarieren Streaming-Nutzungskompatibilität auf dem gemeinsamen Transport `openai-completions`, und OpenClaw richtet sich dabei nach den Endpunktfähigkeiten statt nur nach der integrierten Provider-ID. +Native Moonshot-Endpunkte melden Streaming-Nutzungskompatibilität auf dem gemeinsamen Transport `openai-completions`, und OpenClaw richtet sich dabei nach den Fähigkeiten des Endpunkts statt allein nach der integrierten Anbieter-ID. @@ -2571,7 +2572,7 @@ Native Moonshot-Endpunkte deklarieren Streaming-Nutzungskompatibilität auf dem } ``` -Anthropic-kompatibel, integrierter Provider. Kurzform: `openclaw onboard --auth-choice kimi-code-api-key`. +Anthropic-kompatibel, integrierter Anbieter. Kurzform: `openclaw onboard --auth-choice kimi-code-api-key`. @@ -2610,7 +2611,7 @@ Anthropic-kompatibel, integrierter Provider. Kurzform: `openclaw onboard --auth- } ``` -Die Base-URL sollte `/v1` weglassen (der Anthropic-Client hängt es an). Kurzform: `openclaw onboard --auth-choice synthetic-api-key`. +Die Base-URL sollte `/v1` weglassen (der Anthropic-Client hängt sie an). Kurzform: `openclaw onboard --auth-choice synthetic-api-key`. @@ -2653,14 +2654,14 @@ Die Base-URL sollte `/v1` weglassen (der Anthropic-Client hängt es an). Kurzfor Setzen Sie `MINIMAX_API_KEY`. Kurzformen: `openclaw onboard --auth-choice minimax-global-api` oder `openclaw onboard --auth-choice minimax-cn-api`. -Der Modellkatalog verwendet standardmäßig nur M2.7. -Auf dem Anthropic-kompatiblen Streaming-Pfad deaktiviert OpenClaw standardmäßig MiniMax thinking, sofern Sie `thinking` nicht explizit selbst setzen. `/fast on` oder `params.fastMode: true` schreibt `MiniMax-M2.7` in `MiniMax-M2.7-highspeed` um. +Der Modellkatalog ist standardmäßig auf nur M2.7 gesetzt. +Auf dem Anthropic-kompatiblen Streaming-Pfad deaktiviert OpenClaw MiniMax-Thinking standardmäßig, sofern Sie `thinking` nicht explizit selbst setzen. `/fast on` oder `params.fastMode: true` schreibt `MiniMax-M2.7` zu `MiniMax-M2.7-highspeed` um. -Siehe [Lokale Modelle](/de/gateway/local-models). Kurz gesagt: Führen Sie ein großes lokales Modell über die LM Studio Responses API auf leistungsstarker Hardware aus; behalten Sie gehostete Modelle als Fallback im Merge bei. +Siehe [Local Models](/de/gateway/local-models). Kurz gesagt: Führen Sie ein großes lokales Modell über die LM Studio Responses API auf leistungsfähiger Hardware aus; behalten Sie gehostete Modelle zusammengeführt als Fallback. @@ -2681,7 +2682,7 @@ Siehe [Lokale Modelle](/de/gateway/local-models). Kurz gesagt: Führen Sie ein g }, entries: { "image-lab": { - apiKey: { source: "env", provider: "default", id: "GEMINI_API_KEY" }, // oder Klartextzeichenfolge + apiKey: { source: "env", provider: "default", id: "GEMINI_API_KEY" }, // oder Klartext-String env: { GEMINI_API_KEY: "GEMINI_KEY_HERE" }, }, peekaboo: { enabled: true }, @@ -2693,10 +2694,10 @@ Siehe [Lokale Modelle](/de/gateway/local-models). Kurz gesagt: Führen Sie ein g - `allowBundled`: optionale Allowlist nur für gebündelte Skills (verwaltete/Workspace-Skills bleiben unberührt). - `load.extraDirs`: zusätzliche gemeinsame Skill-Roots (niedrigste Priorität). -- `install.preferBrew`: wenn true, Homebrew-Installer bevorzugen, wenn `brew` verfügbar ist, bevor auf andere Installer-Arten zurückgegriffen wird. -- `install.nodeManager`: Präferenz für Node-Installer bei Spezifikationen in `metadata.openclaw.install` (`npm` | `pnpm` | `yarn` | `bun`). +- `install.preferBrew`: wenn true, werden Homebrew-Installer bevorzugt, wenn `brew` verfügbar ist, bevor auf andere Installer-Arten zurückgegriffen wird. +- `install.nodeManager`: Präferenz für Node-Installer bei Spezifikationen aus `metadata.openclaw.install` (`npm` | `pnpm` | `yarn` | `bun`). - `entries..enabled: false` deaktiviert einen Skill, selbst wenn er gebündelt/installiert ist. -- `entries..apiKey`: Komfortfeld für Skills, die eine primäre Umgebungsvariable deklarieren (Klartextzeichenfolge oder SecretRef-Objekt). +- `entries..apiKey`: Komfortfeld für Skills, die eine primäre Umgebungsvariable deklarieren (Klartext-String oder SecretRef-Objekt). --- @@ -2725,39 +2726,39 @@ Siehe [Lokale Modelle](/de/gateway/local-models). Kurz gesagt: Führen Sie ein g ``` - Geladen aus `~/.openclaw/extensions`, `/.openclaw/extensions` sowie `plugins.load.paths`. -- Die Erkennung akzeptiert native OpenClaw-Plugins sowie kompatible Codex-Bundles und Claude-Bundles, einschließlich Claude-Bundles im Standardlayout ohne Manifest. +- Die Erkennung akzeptiert native OpenClaw-Plugins sowie kompatible Codex-Bundles und Claude-Bundles, einschließlich manifestloser Claude-Bundles im Standardlayout. - **Konfigurationsänderungen erfordern einen Gateway-Neustart.** -- `allow`: optionale Allowlist (nur aufgeführte Plugins werden geladen). `deny` hat Vorrang. +- `allow`: optionale Allowlist (nur aufgeführte Plugins werden geladen). `deny` gewinnt. - `plugins.entries..apiKey`: Komfortfeld für API-Schlüssel auf Plugin-Ebene (wenn vom Plugin unterstützt). - `plugins.entries..env`: Plugin-spezifische Zuordnung von Umgebungsvariablen. -- `plugins.entries..hooks.allowPromptInjection`: wenn `false`, blockiert der Core `before_prompt_build` und ignoriert promptmutierende Felder aus Legacy-`before_agent_start`, während Legacy-`modelOverride` und `providerOverride` erhalten bleiben. Gilt für native Plugin-Hooks und unterstützte von Bundles bereitgestellte Hook-Verzeichnisse. -- `plugins.entries..subagent.allowModelOverride`: diesem Plugin explizit vertrauen, pro Lauf `provider`- und `model`-Überschreibungen für Hintergrund-Subagent-Läufe anzufordern. -- `plugins.entries..subagent.allowedModels`: optionale Allowlist kanonischer Ziele im Format `provider/model` für vertrauenswürdige Subagent-Überschreibungen. Verwenden Sie `"*"`, nur wenn Sie absichtlich jedes Modell zulassen möchten. -- `plugins.entries..config`: plugindefiniertes Konfigurationsobjekt (validiert durch das native OpenClaw-Plugin-Schema, wenn verfügbar). -- `plugins.entries.firecrawl.config.webFetch`: Firecrawl-Einstellungen für den Web-Fetch-Provider. - - `apiKey`: Firecrawl-API-Schlüssel (akzeptiert SecretRef). Fällt auf `plugins.entries.firecrawl.config.webSearch.apiKey`, Legacy-`tools.web.fetch.firecrawl.apiKey` oder die Umgebungsvariable `FIRECRAWL_API_KEY` zurück. +- `plugins.entries..hooks.allowPromptInjection`: wenn `false`, blockiert der Core `before_prompt_build` und ignoriert promptverändernde Felder aus Legacy-`before_agent_start`, während Legacy-`modelOverride` und `providerOverride` erhalten bleiben. Gilt für native Plugin-Hooks und unterstützte Hook-Verzeichnisse aus Bundles. +- `plugins.entries..subagent.allowModelOverride`: vertraut diesem Plugin explizit, pro Lauf Überschreibungen von `provider` und `model` für Hintergrund-Subagent-Läufe anzufordern. +- `plugins.entries..subagent.allowedModels`: optionale Allowlist kanonischer Ziele vom Typ `provider/model` für vertrauenswürdige Subagent-Überschreibungen. Verwenden Sie `"*"`, nur wenn Sie bewusst jedes Modell erlauben möchten. +- `plugins.entries..config`: plugindefiniertes Konfigurationsobjekt (validiert durch das native OpenClaw-Plugin-Schema, sofern verfügbar). +- `plugins.entries.firecrawl.config.webFetch`: Firecrawl-Einstellungen für den Web-Fetch-Anbieter. + - `apiKey`: Firecrawl-API-Schlüssel (akzeptiert SecretRef). Fällt zurück auf `plugins.entries.firecrawl.config.webSearch.apiKey`, Legacy-`tools.web.fetch.firecrawl.apiKey` oder die Umgebungsvariable `FIRECRAWL_API_KEY`. - `baseUrl`: Firecrawl-API-Base-URL (Standard: `https://api.firecrawl.dev`). - `onlyMainContent`: nur den Hauptinhalt von Seiten extrahieren (Standard: `true`). - `maxAgeMs`: maximales Cache-Alter in Millisekunden (Standard: `172800000` / 2 Tage). - - `timeoutSeconds`: Timeout für Scrape-Anfragen in Sekunden (Standard: `60`). + - `timeoutSeconds`: Timeout für Scrape-Requests in Sekunden (Standard: `60`). - `plugins.entries.xai.config.xSearch`: Einstellungen für xAI X Search (Grok-Websuche). - - `enabled`: den X-Search-Provider aktivieren. - - `model`: Grok-Modell, das für die Suche verwendet werden soll (z. B. `"grok-4-1-fast"`). -- `plugins.entries.memory-core.config.dreaming`: Einstellungen für Memory-Dreaming (experimentell). Phasen und Schwellenwerte finden Sie unter [Dreaming](/de/concepts/dreaming). + - `enabled`: den Anbieter X Search aktivieren. + - `model`: für die Suche zu verwendendes Grok-Modell (z. B. `"grok-4-1-fast"`). +- `plugins.entries.memory-core.config.dreaming`: Einstellungen für Memory-Dreaming. Phasen und Schwellenwerte finden Sie unter [Dreaming](/de/concepts/dreaming). - `enabled`: globaler Dreaming-Schalter (Standard `false`). - - `frequency`: Cron-Taktung für jeden vollständigen Dreaming-Durchlauf (standardmäßig `"0 3 * * *"`). + - `frequency`: Cron-Takt für jeden vollständigen Dreaming-Durchlauf (standardmäßig `"0 3 * * *"`). - Phasenrichtlinie und Schwellenwerte sind Implementierungsdetails (keine benutzerseitigen Konfigurationsschlüssel). -- Die vollständige Memory-Konfiguration befindet sich in der [Speicherkonfigurationsreferenz](/de/reference/memory-config): +- Die vollständige Memory-Konfiguration befindet sich in [Memory configuration reference](/de/reference/memory-config): - `agents.defaults.memorySearch.*` - `memory.backend` - `memory.citations` - `memory.qmd.*` - `plugins.entries.memory-core.config.dreaming` - Aktivierte Claude-Bundle-Plugins können auch eingebettete Pi-Standards aus `settings.json` beisteuern; OpenClaw wendet diese als bereinigte Agent-Einstellungen an, nicht als rohe OpenClaw-Konfigurations-Patches. -- `plugins.slots.memory`: aktive Memory-Plugin-ID auswählen oder `"none"`, um Memory-Plugins zu deaktivieren. -- `plugins.slots.contextEngine`: aktive Context-Engine-Plugin-ID auswählen; Standard ist `"legacy"`, sofern Sie keine andere Engine installieren und auswählen. -- `plugins.installs`: von der CLI verwaltete Installationsmetadaten, die von `openclaw plugins update` verwendet werden. - - Enthält `source`, `spec`, `sourcePath`, `installPath`, `version`, `resolvedName`, `resolvedVersion`, `resolvedSpec`, `integrity`, `shasum`, `resolvedAt`, `installedAt`. +- `plugins.slots.memory`: aktive ID des Memory-Plugins auswählen oder `"none"`, um Memory-Plugins zu deaktivieren. +- `plugins.slots.contextEngine`: aktive ID des Context-Engine-Plugins auswählen; standardmäßig `"legacy"`, sofern Sie keine andere Engine installieren und auswählen. +- `plugins.installs`: CLI-verwaltete Installationsmetadaten, die von `openclaw plugins update` verwendet werden. + - Umfasst `source`, `spec`, `sourcePath`, `installPath`, `version`, `resolvedName`, `resolvedVersion`, `resolvedSpec`, `integrity`, `shasum`, `resolvedAt`, `installedAt`. - Behandeln Sie `plugins.installs.*` als verwalteten Zustand; bevorzugen Sie CLI-Befehle gegenüber manuellen Änderungen. Siehe [Plugins](/de/tools/plugin). @@ -2801,21 +2802,21 @@ Siehe [Plugins](/de/tools/plugin). ``` - `evaluateEnabled: false` deaktiviert `act:evaluate` und `wait --fn`. -- `ssrfPolicy.dangerouslyAllowPrivateNetwork` ist deaktiviert, wenn es nicht gesetzt ist, sodass Browser-Navigation standardmäßig strikt bleibt. -- Setzen Sie `ssrfPolicy.dangerouslyAllowPrivateNetwork: true` nur, wenn Sie Browser-Navigation in privaten Netzwerken bewusst vertrauen. -- Im strikten Modus unterliegen entfernte CDP-Profil-Endpunkte (`profiles.*.cdpUrl`) bei Erreichbarkeits-/Erkennungsprüfungen derselben Sperre für private Netzwerke. +- `ssrfPolicy.dangerouslyAllowPrivateNetwork` ist deaktiviert, wenn nicht gesetzt, daher bleibt Browser-Navigation standardmäßig strikt. +- Setzen Sie `ssrfPolicy.dangerouslyAllowPrivateNetwork: true` nur dann, wenn Sie Browser-Navigation in privaten Netzwerken bewusst vertrauen. +- Im strikten Modus unterliegen entfernte CDP-Profilendpunkte (`profiles.*.cdpUrl`) bei Erreichbarkeits-/Erkennungsprüfungen derselben Blockierung für private Netzwerke. - `ssrfPolicy.allowPrivateNetwork` wird weiterhin als Legacy-Alias unterstützt. -- Verwenden Sie im strikten Modus `ssrfPolicy.hostnameAllowlist` und `ssrfPolicy.allowedHostnames` für explizite Ausnahmen. -- Remote-Profile sind nur zum Anhängen gedacht (Start/Stopp/Reset deaktiviert). +- Im strikten Modus verwenden Sie `ssrfPolicy.hostnameAllowlist` und `ssrfPolicy.allowedHostnames` für explizite Ausnahmen. +- Remote-Profile sind nur zum Anhängen geeignet (Start/Stopp/Reset deaktiviert). - `profiles.*.cdpUrl` akzeptiert `http://`, `https://`, `ws://` und `wss://`. - Verwenden Sie HTTP(S), wenn OpenClaw `/json/version` erkennen soll; verwenden Sie WS(S), wenn Ihr Provider Ihnen eine direkte DevTools-WebSocket-URL bereitstellt. -- Profile vom Typ `existing-session` sind nur auf dem Host verfügbar und verwenden Chrome MCP statt CDP. -- Profile vom Typ `existing-session` können `userDataDir` setzen, um auf ein bestimmtes Chromium-basiertes Browser-Profil wie Brave oder Edge zu zielen. -- Profile vom Typ `existing-session` behalten die aktuellen Routenbeschränkungen von Chrome MCP bei: snapshot-/ref-basierte Aktionen statt CSS-Selektor-Targeting, Hooks für das Hochladen einzelner Dateien, keine Überschreibungen von Dialog-Timeouts, kein `wait --load networkidle` sowie kein `responsebody`, kein PDF-Export, keine Download-Interception und keine Batch-Aktionen. + Verwenden Sie HTTP(S), wenn OpenClaw `/json/version` erkennen soll; verwenden Sie WS(S), wenn Ihr Anbieter Ihnen eine direkte DevTools-WebSocket-URL liefert. +- `existing-session`-Profile sind nur hostseitig verfügbar und verwenden Chrome MCP anstelle von CDP. +- `existing-session`-Profile können `userDataDir` setzen, um ein bestimmtes Profil eines Chromium-basierten Browsers wie Brave oder Edge anzusprechen. +- `existing-session`-Profile behalten die aktuellen Routenbeschränkungen von Chrome MCP bei: snapshot-/ref-basierte Aktionen statt CSS-Selektor-Targeting, Hooks zum Hochladen einzelner Dateien, keine Überschreibungen für Dialog-Timeouts, kein `wait --load networkidle` sowie kein `responsebody`, kein PDF-Export, keine Download-Abfangung und keine Batch-Aktionen. - Lokal verwaltete `openclaw`-Profile weisen `cdpPort` und `cdpUrl` automatisch zu; setzen Sie `cdpUrl` nur explizit für Remote-CDP. - Reihenfolge der automatischen Erkennung: Standardbrowser, wenn Chromium-basiert → Chrome → Brave → Edge → Chromium → Chrome Canary. -- Control-Service: nur loopback (Port von `gateway.port` abgeleitet, Standard `18791`). -- `extraArgs` hängt zusätzliche Start-Flags an den lokalen Chromium-Start an (zum Beispiel `--disable-gpu`, Fenstergröße oder Debug-Flags). +- Control-Service: nur loopback (Port aus `gateway.port` abgeleitet, Standard `18791`). +- `extraArgs` hängt zusätzliche Start-Flags an den lokalen Chromium-Start an (zum Beispiel `--disable-gpu`, Fenstergrößen oder Debug-Flags). --- @@ -2827,14 +2828,14 @@ Siehe [Plugins](/de/tools/plugin). seamColor: "#FF4500", assistant: { name: "OpenClaw", - avatar: "CB", // Emoji, kurzer Text, Bild-URL oder Data-URI + avatar: "CB", // Emoji, kurzer Text, Bild-URL oder data-URI }, }, } ``` -- `seamColor`: Akzentfarbe für native App-UI-Elemente (Talk-Mode-Bubble-Tönung usw.). -- `assistant`: Überschreibung der Identität in der Control UI. Fällt auf die aktive Agent-Identität zurück. +- `seamColor`: Akzentfarbe für die UI-Chrome der nativen App (Talk-Mode-Blasentönung usw.). +- `assistant`: Überschreibung der Identität in der Control UI. Fällt auf die aktive Agentenidentität zurück. --- @@ -2870,7 +2871,7 @@ Siehe [Plugins](/de/tools/plugin). // embedSandbox: "scripts", // strict | scripts | trusted // allowExternalEmbedUrls: false, // gefährlich: absolute externe http(s)-Embed-URLs erlauben // allowedOrigins: ["https://control.example.com"], // erforderlich für nicht-loopback Control UI - // dangerouslyAllowHostHeaderOriginFallback: false, // gefährlicher Host-Header-Origin-Fallback-Modus + // dangerouslyAllowHostHeaderOriginFallback: false, // gefährlicher Fallback-Modus für Host-Header-Origin // allowInsecureAuth: false, // dangerouslyDisableDeviceAuth: false, }, @@ -2903,41 +2904,41 @@ Siehe [Plugins](/de/tools/plugin). -- `mode`: `local` (Gateway ausführen) oder `remote` (mit Remote-Gateway verbinden). Das Gateway verweigert den Start, sofern nicht `local` gesetzt ist. -- `port`: einzelner multiplexierter Port für WS + HTTP. Priorität: `--port` > `OPENCLAW_GATEWAY_PORT` > `gateway.port` > `18789`. +- `mode`: `local` (Gateway ausführen) oder `remote` (mit Remote-Gateway verbinden). Das Gateway verweigert den Start, wenn es nicht auf `local` gesetzt ist. +- `port`: einzelner multiplexter Port für WS + HTTP. Priorität: `--port` > `OPENCLAW_GATEWAY_PORT` > `gateway.port` > `18789`. - `bind`: `auto`, `loopback` (Standard), `lan` (`0.0.0.0`), `tailnet` (nur Tailscale-IP) oder `custom`. -- **Legacy-Bind-Aliasse**: Verwenden Sie Bind-Modus-Werte in `gateway.bind` (`auto`, `loopback`, `lan`, `tailnet`, `custom`), nicht Host-Aliasse (`0.0.0.0`, `127.0.0.1`, `localhost`, `::`, `::1`). -- **Docker-Hinweis**: Der Standard-Bind `loopback` lauscht im Container auf `127.0.0.1`. Bei Docker-Bridge-Netzwerk (`-p 18789:18789`) kommt der Datenverkehr über `eth0` an, daher ist das Gateway nicht erreichbar. Verwenden Sie `--network host`, oder setzen Sie `bind: "lan"` (oder `bind: "custom"` mit `customBindHost: "0.0.0.0"`), um auf allen Interfaces zu lauschen. -- **Auth**: standardmäßig erforderlich. Nicht-Loopback-Binds erfordern Gateway-Authentifizierung. In der Praxis bedeutet das ein gemeinsames Token/Passwort oder einen identitätsbewussten Reverse-Proxy mit `gateway.auth.mode: "trusted-proxy"`. Der Onboarding-Assistent erzeugt standardmäßig ein Token. +- **Legacy-Bind-Aliase**: Verwenden Sie Bind-Modus-Werte in `gateway.bind` (`auto`, `loopback`, `lan`, `tailnet`, `custom`), nicht Host-Aliase (`0.0.0.0`, `127.0.0.1`, `localhost`, `::`, `::1`). +- **Docker-Hinweis**: Der standardmäßige `loopback`-Bind lauscht innerhalb des Containers auf `127.0.0.1`. Bei Docker-Bridge-Networking (`-p 18789:18789`) kommt der Datenverkehr auf `eth0` an, sodass das Gateway nicht erreichbar ist. Verwenden Sie `--network host` oder setzen Sie `bind: "lan"` (oder `bind: "custom"` mit `customBindHost: "0.0.0.0"`), damit auf allen Interfaces gelauscht wird. +- **Auth**: Standardmäßig erforderlich. Nicht-Loopback-Binds erfordern Gateway-Authentifizierung. Praktisch bedeutet das ein gemeinsames Token/Passwort oder einen identitätsbewussten Reverse-Proxy mit `gateway.auth.mode: "trusted-proxy"`. Der Onboarding-Assistent erzeugt standardmäßig ein Token. - Wenn sowohl `gateway.auth.token` als auch `gateway.auth.password` konfiguriert sind (einschließlich SecretRefs), setzen Sie `gateway.auth.mode` explizit auf `token` oder `password`. Start- sowie Service-Installations-/Reparaturabläufe schlagen fehl, wenn beide konfiguriert sind und `mode` nicht gesetzt ist. - `gateway.auth.mode: "none"`: expliziter Modus ohne Authentifizierung. Nur für vertrauenswürdige lokale loopback-Setups verwenden; dies wird absichtlich nicht in Onboarding-Prompts angeboten. -- `gateway.auth.mode: "trusted-proxy"`: Authentifizierung an einen identitätsbewussten Reverse-Proxy delegieren und Identitäts-Header von `gateway.trustedProxies` vertrauen (siehe [Trusted Proxy Auth](/de/gateway/trusted-proxy-auth)). Dieser Modus erwartet eine **nicht-loopback** Proxy-Quelle; gleichartige loopback-Reverse-Proxys erfüllen die trusted-proxy-Authentifizierung nicht. -- `gateway.auth.allowTailscale`: wenn `true`, können Tailscale-Serve-Identitäts-Header die Authentifizierung für Control UI/WebSocket erfüllen (über `tailscale whois` verifiziert). HTTP-API-Endpunkte verwenden diese Tailscale-Header-Authentifizierung **nicht**; sie folgen stattdessen dem normalen HTTP-Auth-Modus des Gateways. Dieser tokenlose Ablauf setzt voraus, dass dem Gateway-Host vertraut wird. Standard ist `true`, wenn `tailscale.mode = "serve"` gesetzt ist. -- `gateway.auth.rateLimit`: optionaler Limiter für fehlgeschlagene Authentifizierungen. Gilt pro Client-IP und pro Auth-Bereich (Shared-Secret und Device-Token werden unabhängig voneinander verfolgt). Blockierte Versuche geben `429` + `Retry-After` zurück. - - Auf dem asynchronen Tailscale-Serve-Control-UI-Pfad werden fehlgeschlagene Versuche für dasselbe `{scope, clientIp}` vor dem Schreiben des Fehlers serialisiert. Gleichzeitig auftretende fehlerhafte Versuche desselben Clients können daher bereits beim zweiten Request den Limiter auslösen, statt dass beide parallel als normale Fehlanpassungen durchlaufen. - - `gateway.auth.rateLimit.exemptLoopback` ist standardmäßig `true`; setzen Sie `false`, wenn Sie absichtlich auch localhost-Datenverkehr ratenbegrenzen möchten (für Test-Setups oder strikte Proxy-Bereitstellungen). -- Browser-originierte WS-Authentifizierungsversuche werden immer mit deaktivierter loopback-Ausnahme gedrosselt (Defense-in-Depth gegen browserbasierte Brute-Force-Angriffe auf localhost). -- Auf loopback werden diese browser-originären Sperren nach normalisiertem `Origin`-Wert isoliert, sodass wiederholte Fehler von einem localhost-Origin nicht automatisch einen anderen Origin sperren. -- `tailscale.mode`: `serve` (nur tailnet, loopback-Bind) oder `funnel` (öffentlich, erfordert Auth). -- `controlUi.allowedOrigins`: explizite Allowlist von Browser-Origin-Werten für Gateway-WebSocket-Verbindungen. Erforderlich, wenn Browser-Clients von Nicht-Loopback-Origins erwartet werden. -- `controlUi.dangerouslyAllowHostHeaderOriginFallback`: gefährlicher Modus, der Host-Header-Origin-Fallback für Bereitstellungen aktiviert, die absichtlich auf einer Host-Header-Origin-Richtlinie beruhen. -- `remote.transport`: `ssh` (Standard) oder `direct` (ws/wss). Für `direct` muss `remote.url` `ws://` oder `wss://` sein. -- `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`: clientseitige Break-Glass-Überschreibung, die Klartext-`ws://` zu vertrauenswürdigen IPs in privaten Netzwerken erlaubt; Standard bleibt loopback-only für Klartext. -- `gateway.remote.token` / `.password` sind Zugangsdatenfelder für den Remote-Client. Sie konfigurieren die Gateway-Authentifizierung nicht selbst. -- `gateway.push.apns.relay.baseUrl`: HTTPS-Basis-URL für das externe APNs-Relay, das von offiziellen/TestFlight-iOS-Builds verwendet wird, nachdem sie relaygestützte Registrierungen an das Gateway veröffentlicht haben. Diese URL muss mit der in den iOS-Build einkompilierten Relay-URL übereinstimmen. -- `gateway.push.apns.relay.timeoutMs`: Timeout in Millisekunden für das Senden vom Gateway an das Relay. Standard ist `10000`. -- Relay-gestützte Registrierungen werden an eine bestimmte Gateway-Identität delegiert. Die gekoppelte iOS-App ruft `gateway.identity.get` ab, schließt diese Identität in die Relay-Registrierung ein und leitet eine registrierungsbezogene Sendeberechtigung an das Gateway weiter. Ein anderes Gateway kann diese gespeicherte Registrierung nicht wiederverwenden. -- `OPENCLAW_APNS_RELAY_BASE_URL` / `OPENCLAW_APNS_RELAY_TIMEOUT_MS`: temporäre Env-Überschreibungen für die oben genannte Relay-Konfiguration. -- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true`: nur für Entwicklung vorgesehener Escape Hatch für loopback-HTTP-Relay-URLs. Produktions-Relay-URLs sollten HTTPS verwenden. -- `gateway.channelHealthCheckMinutes`: Intervall des Kanal-Health-Monitors in Minuten. Setzen Sie `0`, um Neustarts durch den Health-Monitor global zu deaktivieren. Standard: `5`. +- `gateway.auth.mode: "trusted-proxy"`: delegiert die Authentifizierung an einen identitätsbewussten Reverse-Proxy und vertraut Identitäts-Headern aus `gateway.trustedProxies` (siehe [Trusted Proxy Auth](/de/gateway/trusted-proxy-auth)). Dieser Modus erwartet eine **nicht-loopback** Proxy-Quelle; Loopback-Reverse-Proxys auf demselben Host erfüllen die Anforderungen für trusted-proxy auth nicht. +- `gateway.auth.allowTailscale`: wenn `true`, können Identitäts-Header von Tailscale Serve die Authentifizierung für Control UI/WebSocket erfüllen (verifiziert über `tailscale whois`). HTTP-API-Endpunkte verwenden **nicht** diese Tailscale-Header-Authentifizierung; sie folgen stattdessen dem normalen HTTP-Auth-Modus des Gateway. Dieser tokenlose Ablauf setzt voraus, dass dem Gateway-Host vertraut wird. Standardmäßig `true`, wenn `tailscale.mode = "serve"` gesetzt ist. +- `gateway.auth.rateLimit`: optionaler Limiter für fehlgeschlagene Authentifizierungen. Gilt pro Client-IP und pro Auth-Bereich (Shared Secret und Device-Token werden unabhängig verfolgt). Geblockte Versuche geben `429` + `Retry-After` zurück. + - Auf dem asynchronen Tailscale-Serve-Control-UI-Pfad werden fehlgeschlagene Versuche für dasselbe `{scope, clientIp}` vor dem Schreiben des Fehlers serialisiert. Gleichzeitige ungültige Versuche vom selben Client können den Limiter daher schon beim zweiten Request auslösen, statt dass beide als einfache Mismatches durchrutschen. + - `gateway.auth.rateLimit.exemptLoopback` ist standardmäßig `true`; setzen Sie `false`, wenn auch Localhost-Datenverkehr bewusst dem Rate-Limit unterliegen soll (für Test-Setups oder strikte Proxy-Deployments). +- WebSocket-Authentifizierungsversuche mit Browser-Origin werden immer gedrosselt, wobei die Loopback-Ausnahme deaktiviert ist (Defense-in-Depth gegen browserbasiertes Brute-Force auf Localhost). +- Auf loopback werden diese browserbasierten Sperren pro normalisiertem `Origin`-Wert isoliert, sodass wiederholte Fehlschläge von einem Localhost-Origin nicht automatisch einen anderen Origin aussperren. +- `tailscale.mode`: `serve` (nur tailnet, loopback-Bind) oder `funnel` (öffentlich, Auth erforderlich). +- `controlUi.allowedOrigins`: explizite Browser-Origin-Allowlist für Gateway-WebSocket-Verbindungen. Erforderlich, wenn Browser-Clients von nicht-loopback Origins erwartet werden. +- `controlUi.dangerouslyAllowHostHeaderOriginFallback`: gefährlicher Modus, der Host-Header-Origin-Fallback für Deployments aktiviert, die sich bewusst auf Host-Header-Origin-Richtlinien verlassen. +- `remote.transport`: `ssh` (Standard) oder `direct` (ws/wss). Bei `direct` muss `remote.url` `ws://` oder `wss://` sein. +- `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`: clientseitige Break-Glass-Überschreibung, die Klartext-`ws://` zu vertrauenswürdigen IPs in privaten Netzwerken erlaubt; standardmäßig bleibt Klartext auf loopback beschränkt. +- `gateway.remote.token` / `.password` sind Anmeldedatenfelder für Remote-Clients. Sie konfigurieren die Gateway-Authentifizierung nicht von selbst. +- `gateway.push.apns.relay.baseUrl`: Basis-HTTPS-URL für das externe APNs-Relay, das offizielle/TestFlight-iOS-Builds verwenden, nachdem sie Relay-gestützte Registrierungen an das Gateway veröffentlicht haben. Diese URL muss mit der in den iOS-Build kompilierten Relay-URL übereinstimmen. +- `gateway.push.apns.relay.timeoutMs`: Sendetimeout vom Gateway zum Relay in Millisekunden. Standardmäßig `10000`. +- Relay-gestützte Registrierungen werden an eine bestimmte Gateway-Identität delegiert. Die gekoppelte iOS-App ruft `gateway.identity.get` ab, schließt diese Identität in die Relay-Registrierung ein und leitet dem Gateway eine registrierungsbezogene Sendeberechtigung weiter. Ein anderes Gateway kann diese gespeicherte Registrierung nicht wiederverwenden. +- `OPENCLAW_APNS_RELAY_BASE_URL` / `OPENCLAW_APNS_RELAY_TIMEOUT_MS`: temporäre env-Überschreibungen für die obige Relay-Konfiguration. +- `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true`: nur für Entwicklung gedachter Escape Hatch für loopback-HTTP-Relay-URLs. Produktions-Relay-URLs sollten bei HTTPS bleiben. +- `gateway.channelHealthCheckMinutes`: Intervall des Kanal-Gesundheitsmonitors in Minuten. Setzen Sie `0`, um Neustarts durch den Gesundheitsmonitor global zu deaktivieren. Standard: `5`. - `gateway.channelStaleEventThresholdMinutes`: Schwellenwert für veraltete Sockets in Minuten. Halten Sie diesen Wert größer oder gleich `gateway.channelHealthCheckMinutes`. Standard: `30`. -- `gateway.channelMaxRestartsPerHour`: maximale Anzahl von Health-Monitor-Neustarts pro Kanal/Konto in einer rollierenden Stunde. Standard: `10`. -- `channels..healthMonitor.enabled`: kanalbezogenes Opt-out für Neustarts durch den Health-Monitor, während der globale Monitor aktiv bleibt. -- `channels..accounts..healthMonitor.enabled`: kontobezogene Überschreibung für Multi-Konto-Kanäle. Wenn gesetzt, hat sie Vorrang vor der kanalbezogenen Überschreibung. +- `gateway.channelMaxRestartsPerHour`: maximale Anzahl von Neustarts durch den Gesundheitsmonitor pro Kanal/Konto innerhalb einer gleitenden Stunde. Standard: `10`. +- `channels..healthMonitor.enabled`: kanalbezogenes Opt-out für Neustarts durch den Gesundheitsmonitor, während der globale Monitor aktiviert bleibt. +- `channels..accounts..healthMonitor.enabled`: Überschreibung pro Konto für Multi-Account-Kanäle. Wenn gesetzt, hat sie Vorrang vor der Überschreibung auf Kanalebene. - Lokale Gateway-Aufrufpfade können `gateway.remote.*` nur dann als Fallback verwenden, wenn `gateway.auth.*` nicht gesetzt ist. -- Wenn `gateway.auth.token` / `gateway.auth.password` explizit über SecretRef konfiguriert und nicht aufgelöst ist, schlägt die Auflösung fail-closed fehl (kein maskierender Remote-Fallback). -- `trustedProxies`: IPs von Reverse-Proxys, die TLS terminieren oder Header mit weitergeleiteten Client-Informationen einfügen. Listen Sie nur Proxys auf, die Sie kontrollieren. Loopback-Einträge sind weiterhin für Setups mit gleichartigem Proxy/lokaler Erkennung gültig (zum Beispiel Tailscale Serve oder ein lokaler Reverse-Proxy), machen loopback-Anfragen jedoch **nicht** für `gateway.auth.mode: "trusted-proxy"` zulässig. -- `allowRealIpFallback`: wenn `true`, akzeptiert das Gateway `X-Real-IP`, falls `X-Forwarded-For` fehlt. Standard `false` für fail-closed-Verhalten. +- Wenn `gateway.auth.token` / `gateway.auth.password` explizit über SecretRef konfiguriert und nicht auflösbar sind, schlägt die Auflösung fail-closed fehl (kein Maskieren durch Remote-Fallback). +- `trustedProxies`: IPs von Reverse-Proxys, die TLS terminieren oder Header mit weitergeleiteter Client-Identität injizieren. Listen Sie nur Proxys auf, die Sie kontrollieren. Loopback-Einträge bleiben für Setups mit Proxy auf demselben Host/lokaler Erkennung gültig (zum Beispiel Tailscale Serve oder ein lokaler Reverse-Proxy), machen Loopback-Requests aber **nicht** für `gateway.auth.mode: "trusted-proxy"` geeignet. +- `allowRealIpFallback`: wenn `true`, akzeptiert das Gateway `X-Real-IP`, wenn `X-Forwarded-For` fehlt. Standard `false` für fail-closed-Verhalten. - `gateway.tools.deny`: zusätzliche Tool-Namen, die für HTTP `POST /tools/invoke` blockiert werden (erweitert die Standard-Deny-Liste). - `gateway.tools.allow`: entfernt Tool-Namen aus der Standard-HTTP-Deny-Liste. @@ -2952,13 +2953,13 @@ Siehe [Plugins](/de/tools/plugin). - `gateway.http.endpoints.responses.files.urlAllowlist` - `gateway.http.endpoints.responses.images.urlAllowlist` Leere Allowlists werden als nicht gesetzt behandelt; verwenden Sie `gateway.http.endpoints.responses.files.allowUrl=false` - und/oder `gateway.http.endpoints.responses.images.allowUrl=false`, um URL-Fetching zu deaktivieren. -- Optionaler Header zur Härtung von Antworten: + und/oder `gateway.http.endpoints.responses.images.allowUrl=false`, um das Abrufen per URL zu deaktivieren. +- Optionaler Härtungs-Header für Responses: - `gateway.http.securityHeaders.strictTransportSecurity` (nur für HTTPS-Origins setzen, die Sie kontrollieren; siehe [Trusted Proxy Auth](/de/gateway/trusted-proxy-auth#tls-termination-and-hsts)) -### Multi-Instance-Isolation +### Isolation mehrerer Instanzen -Führen Sie mehrere Gateways auf einem Host mit eindeutigen Ports und Zustandsverzeichnissen aus: +Führen Sie mehrere Gateways auf einem Host mit eindeutigen Ports und State-Verzeichnissen aus: ```bash OPENCLAW_CONFIG_PATH=~/.openclaw/a.json \ @@ -2966,9 +2967,9 @@ OPENCLAW_STATE_DIR=~/.openclaw-a \ openclaw gateway --port 19001 ``` -Komfort-Flags: `--dev` (verwendet `~/.openclaw-dev` + Port `19001`), `--profile ` (verwendet `~/.openclaw-`). +Praktische Flags: `--dev` (verwendet `~/.openclaw-dev` + Port `19001`), `--profile ` (verwendet `~/.openclaw-`). -Siehe [Mehrere Gateways](/de/gateway/multiple-gateways). +Siehe [Multiple Gateways](/de/gateway/multiple-gateways). ### `gateway.tls` @@ -2987,10 +2988,10 @@ Siehe [Mehrere Gateways](/de/gateway/multiple-gateways). ``` - `enabled`: aktiviert TLS-Terminierung am Gateway-Listener (HTTPS/WSS) (Standard: `false`). -- `autoGenerate`: erzeugt automatisch ein lokales selbstsigniertes Zertifikat-/Schlüsselpaar, wenn keine expliziten Dateien konfiguriert sind; nur für lokale/dev-Nutzung. +- `autoGenerate`: generiert automatisch ein lokales selbstsigniertes Zertifikat-/Schlüsselpaar, wenn keine expliziten Dateien konfiguriert sind; nur für lokale/dev-Nutzung. - `certPath`: Dateisystempfad zur TLS-Zertifikatsdatei. - `keyPath`: Dateisystempfad zur privaten TLS-Schlüsseldatei; mit eingeschränkten Berechtigungen schützen. -- `caPath`: optionaler Pfad zu einem CA-Bundle für Client-Verifikation oder benutzerdefinierte Vertrauenskette. +- `caPath`: optionaler Pfad zu einem CA-Bundle für Client-Verifikation oder benutzerdefinierte Vertrauensketteten. ### `gateway.reload` @@ -3008,10 +3009,10 @@ Siehe [Mehrere Gateways](/de/gateway/multiple-gateways). - `mode`: steuert, wie Konfigurationsänderungen zur Laufzeit angewendet werden. - `"off"`: Live-Änderungen ignorieren; Änderungen erfordern einen expliziten Neustart. - - `"restart"`: Gateway-Prozess bei Konfigurationsänderung immer neu starten. + - `"restart"`: bei Konfigurationsänderungen immer den Gateway-Prozess neu starten. - `"hot"`: Änderungen im Prozess anwenden, ohne neu zu starten. - - `"hybrid"` (Standard): zuerst Hot-Reload versuchen; falls erforderlich auf Neustart zurückfallen. -- `debounceMs`: Debounce-Fenster in ms, bevor Konfigurationsänderungen angewendet werden (nicht negative Ganzzahl). + - `"hybrid"` (Standard): zuerst Hot Reload versuchen; bei Bedarf auf Neustart zurückfallen. +- `debounceMs`: Debounce-Fenster in ms, bevor Konfigurationsänderungen angewendet werden (nicht negativer Integer). - `deferralTimeoutMs`: maximale Wartezeit in ms auf laufende Operationen, bevor ein Neustart erzwungen wird (Standard: `300000` = 5 Minuten). --- @@ -3050,36 +3051,36 @@ Siehe [Mehrere Gateways](/de/gateway/multiple-gateways). ``` Auth: `Authorization: Bearer ` oder `x-openclaw-token: `. -Hook-Token in Query-Strings werden abgelehnt. +Hook-Tokens in Query-Strings werden abgelehnt. -Validierungs- und Sicherheitshinweise: +Hinweise zu Validierung und Sicherheit: - `hooks.enabled=true` erfordert ein nicht leeres `hooks.token`. -- `hooks.token` muss sich von `gateway.auth.token` **unterscheiden**; die Wiederverwendung des Gateway-Tokens wird abgelehnt. +- `hooks.token` muss sich **von** `gateway.auth.token` unterscheiden; die Wiederverwendung des Gateway-Tokens wird abgelehnt. - `hooks.path` darf nicht `/` sein; verwenden Sie einen dedizierten Unterpfad wie `/hooks`. -- Wenn `hooks.allowRequestSessionKey=true`, schränken Sie `hooks.allowedSessionKeyPrefixes` ein (zum Beispiel `["hook:"]`). +- Wenn `hooks.allowRequestSessionKey=true`, beschränken Sie `hooks.allowedSessionKeyPrefixes` (zum Beispiel `["hook:"]`). **Endpunkte:** - `POST /hooks/wake` → `{ text, mode?: "now"|"next-heartbeat" }` - `POST /hooks/agent` → `{ message, name?, agentId?, sessionKey?, wakeMode?, deliver?, channel?, to?, model?, thinking?, timeoutSeconds? }` - - `sessionKey` aus dem Request-Payload wird nur akzeptiert, wenn `hooks.allowRequestSessionKey=true` (Standard: `false`). + - `sessionKey` aus dem Request-Payload wird nur akzeptiert, wenn `hooks.allowRequestSessionKey=true` gesetzt ist (Standard: `false`). - `POST /hooks/` → aufgelöst über `hooks.mappings` -- `match.path` stimmt mit dem Unterpfad nach `/hooks` überein (z. B. `/hooks/gmail` → `gmail`). -- `match.source` stimmt mit einem Payload-Feld für generische Pfade überein. -- Vorlagen wie `{{messages[0].subject}}` lesen aus dem Payload. -- `transform` kann auf ein JS-/TS-Modul verweisen, das eine Hook-Aktion zurückgibt. +- `match.path` gleicht den Unterpfad nach `/hooks` ab (z. B. `/hooks/gmail` → `gmail`). +- `match.source` gleicht ein Payload-Feld für generische Pfade ab. +- Templates wie `{{messages[0].subject}}` lesen aus dem Payload. +- `transform` kann auf ein JS-/TS-Modul zeigen, das eine Hook-Aktion zurückgibt. - `transform.module` muss ein relativer Pfad sein und innerhalb von `hooks.transformsDir` bleiben (absolute Pfade und Traversal werden abgelehnt). -- `agentId` routet an einen bestimmten Agent; unbekannte IDs fallen auf den Standard zurück. -- `allowedAgentIds`: beschränkt explizites Routing (`*` oder weggelassen = alle zulassen, `[]` = alle verweigern). +- `agentId` routet an einen bestimmten Agenten; unbekannte IDs fallen auf den Standard zurück. +- `allowedAgentIds`: schränkt explizites Routing ein (`*` oder weggelassen = alle erlauben, `[]` = alle verweigern). - `defaultSessionKey`: optionaler fester Sitzungsschlüssel für Hook-Agent-Läufe ohne explizites `sessionKey`. - `allowRequestSessionKey`: erlaubt Aufrufern von `/hooks/agent`, `sessionKey` zu setzen (Standard: `false`). - `allowedSessionKeyPrefixes`: optionale Präfix-Allowlist für explizite `sessionKey`-Werte (Request + Mapping), z. B. `["hook:"]`. - `deliver: true` sendet die endgültige Antwort an einen Kanal; `channel` ist standardmäßig `last`. -- `model` überschreibt das LLM für diesen Hook-Lauf (muss zulässig sein, wenn ein Modellkatalog gesetzt ist). +- `model` überschreibt das LLM für diesen Hook-Lauf (muss erlaubt sein, wenn der Modellkatalog gesetzt ist). @@ -3123,22 +3124,22 @@ Validierungs- und Sicherheitshinweise: } ``` -- Stellt durch Agents bearbeitbares HTML/CSS/JS und A2UI über HTTP unter dem Gateway-Port bereit: +- Stellt vom Agenten bearbeitbares HTML/CSS/JS und A2UI über HTTP unter dem Gateway-Port bereit: - `http://:/__openclaw__/canvas/` - `http://:/__openclaw__/a2ui/` -- Nur lokal: Behalten Sie `gateway.bind: "loopback"` (Standard) bei. -- Bei Nicht-Loopback-Binds erfordern Canvas-Routen Gateway-Authentifizierung (Token/Passwort/trusted-proxy), genauso wie andere HTTP-Oberflächen des Gateways. -- Node-WebViews senden typischerweise keine Auth-Header; nachdem ein Node gepaart und verbunden ist, kündigt das Gateway nodebezogene Capability-URLs für den Zugriff auf Canvas/A2UI an. -- Capability-URLs sind an die aktive Node-WS-Sitzung gebunden und laufen schnell ab. Ein IP-basierter Fallback wird nicht verwendet. -- Fügt dem ausgelieferten HTML einen Live-Reload-Client ein. -- Erstellt automatisch eine Starter-`index.html`, wenn leer. -- Stellt A2UI auch unter `/__openclaw__/a2ui/` bereit. +- Nur lokal: behalten Sie `gateway.bind: "loopback"` (Standard) bei. +- Nicht-Loopback-Binds: Canvas-Routen erfordern Gateway-Authentifizierung (Token/Passwort/trusted-proxy), genau wie andere HTTP-Oberflächen des Gateway. +- Node-WebViews senden typischerweise keine Auth-Header; nachdem ein Node gekoppelt und verbunden ist, veröffentlicht das Gateway nodebezogene Capability-URLs für den Zugriff auf Canvas/A2UI. +- Capability-URLs sind an die aktive Node-WS-Sitzung gebunden und laufen schnell ab. Es wird kein IP-basierter Fallback verwendet. +- Injiziert den Live-Reload-Client in ausgeliefertes HTML. +- Erstellt automatisch eine Starter-`index.html`, wenn das Verzeichnis leer ist. +- Stellt A2UI außerdem unter `/__openclaw__/a2ui/` bereit. - Änderungen erfordern einen Gateway-Neustart. - Deaktivieren Sie Live Reload bei großen Verzeichnissen oder `EMFILE`-Fehlern. --- -## Erkennung +## Discovery ### mDNS (Bonjour) @@ -3156,7 +3157,7 @@ Validierungs- und Sicherheitshinweise: - `full`: `cliPath` + `sshPort` einschließen. - Der Hostname ist standardmäßig `openclaw`. Überschreiben Sie ihn mit `OPENCLAW_MDNS_HOSTNAME`. -### Wide-Area (DNS-SD) +### Wide-area (DNS-SD) ```json5 { @@ -3168,7 +3169,7 @@ Validierungs- und Sicherheitshinweise: Schreibt eine Unicast-DNS-SD-Zone unter `~/.openclaw/dns/`. Für netzwerkübergreifende Erkennung kombinieren Sie dies mit einem DNS-Server (CoreDNS empfohlen) + Tailscale Split DNS. -Einrichtung: `openclaw dns setup --apply`. +Setup: `openclaw dns setup --apply`. --- @@ -3192,9 +3193,9 @@ Einrichtung: `openclaw dns setup --apply`. ``` - Inline-Umgebungsvariablen werden nur angewendet, wenn die Prozessumgebung den Schlüssel nicht enthält. -- `.env`-Dateien: `.env` im aktuellen Arbeitsverzeichnis + `~/.openclaw/.env` (keine der beiden überschreibt bestehende Variablen). +- `.env`-Dateien: CWD `.env` + `~/.openclaw/.env` (keine von beiden überschreibt vorhandene Variablen). - `shellEnv`: importiert fehlende erwartete Schlüssel aus Ihrem Login-Shell-Profil. -- Vollständige Priorität finden Sie unter [Umgebung](/de/help/environment). +- Die vollständige Prioritätsreihenfolge finden Sie unter [Environment](/de/help/environment). ### Substitution von Umgebungsvariablen @@ -3208,8 +3209,8 @@ Referenzieren Sie Umgebungsvariablen in jeder Konfigurationszeichenfolge mit `${ } ``` -- Es werden nur großgeschriebene Namen abgeglichen: `[A-Z_][A-Z0-9_]*`. -- Fehlende/leere Variablen werfen beim Laden der Konfiguration einen Fehler. +- Es werden nur Großbuchstabennamen im Muster `[A-Z_][A-Z0-9_]*` abgeglichen. +- Fehlende/leere Variablen verursachen beim Laden der Konfiguration einen Fehler. - Mit `$${VAR}` escapen Sie ein wörtliches `${VAR}`. - Funktioniert mit `$include`. @@ -3221,7 +3222,7 @@ SecretRefs sind additiv: Klartextwerte funktionieren weiterhin. ### `SecretRef` -Verwenden Sie eine Objektform: +Verwenden Sie genau eine Objektform: ```json5 { source: "env" | "file" | "exec", provider: "default", id: "..." } @@ -3229,19 +3230,19 @@ Verwenden Sie eine Objektform: Validierung: -- `provider`-Muster: `^[a-z][a-z0-9_-]{0,63}$` -- `source: "env"`-`id`-Muster: `^[A-Z][A-Z0-9_]{0,127}$` -- `source: "file"`-`id`: absoluter JSON-Pointer (zum Beispiel `"/providers/openai/apiKey"`) -- `source: "exec"`-`id`-Muster: `^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$` +- Muster für `provider`: `^[a-z][a-z0-9_-]{0,63}$` +- Muster für `source: "env"` bei `id`: `^[A-Z][A-Z0-9_]{0,127}$` +- `source: "file"` `id`: absoluter JSON-Zeiger (zum Beispiel `"/providers/openai/apiKey"`) +- Muster für `source: "exec"` bei `id`: `^[A-Za-z0-9][A-Za-z0-9._:/-]{0,255}$` - `source: "exec"`-IDs dürfen keine slashgetrennten Pfadsegmente `.` oder `..` enthalten (zum Beispiel wird `a/../b` abgelehnt) -### Unterstützte Zugangsdatenoberfläche +### Unterstützte Oberfläche für Anmeldedaten - Kanonische Matrix: [SecretRef Credential Surface](/de/reference/secretref-credential-surface) -- `secrets apply` zielt auf unterstützte Zugangsdatenpfade in `openclaw.json`. -- `auth-profiles.json`-Refs sind in der Laufzeitauflösung und Audit-Abdeckung enthalten. +- `secrets apply` zielt auf unterstützte Pfade für Anmeldedaten in `openclaw.json`. +- Refs in `auth-profiles.json` sind in Laufzeitauflösung und Audit-Abdeckung enthalten. -### Konfiguration von Secret-Providern +### Konfiguration der Secret-Provider ```json5 { @@ -3272,16 +3273,16 @@ Validierung: Hinweise: - Der `file`-Provider unterstützt `mode: "json"` und `mode: "singleValue"` (`id` muss im Modus `singleValue` `"value"` sein). -- Der `exec`-Provider erfordert einen absoluten `command`-Pfad und verwendet Protokoll-Payloads über stdin/stdout. -- Standardmäßig werden Befehls-Pfade, die Symlinks sind, abgelehnt. Setzen Sie `allowSymlinkCommand: true`, um Symlink-Pfade zu erlauben, während der aufgelöste Zielpfad validiert wird. -- Wenn `trustedDirs` konfiguriert ist, gilt die trusted-dir-Prüfung für den aufgelösten Zielpfad. -- Die Child-Umgebung von `exec` ist standardmäßig minimal; übergeben Sie erforderliche Variablen explizit mit `passEnv`. -- SecretRefs werden bei der Aktivierung in einen In-Memory-Snapshot aufgelöst; Request-Pfade lesen danach nur noch aus dem Snapshot. -- Filtering nach aktiver Oberfläche gilt während der Aktivierung: Nicht aufgelöste Refs auf aktiven Oberflächen führen zu einem fail-closed bei Start/Reload, während inaktive Oberflächen mit Diagnosen übersprungen werden. +- Der `exec`-Provider erfordert einen absoluten `command`-Pfad und verwendet Protokoll-Payloads auf stdin/stdout. +- Standardmäßig werden Symlink-Befehlspfade abgelehnt. Setzen Sie `allowSymlinkCommand: true`, um Symlink-Pfade zu erlauben, während der aufgelöste Zielpfad weiterhin validiert wird. +- Wenn `trustedDirs` konfiguriert ist, gilt die Prüfung auf vertrauenswürdige Verzeichnisse für den aufgelösten Zielpfad. +- Die Child-Umgebung von `exec` ist standardmäßig minimal; geben Sie benötigte Variablen explizit mit `passEnv` weiter. +- SecretRefs werden zur Aktivierungszeit in einen In-Memory-Snapshot aufgelöst; Request-Pfade lesen danach nur noch aus diesem Snapshot. +- Beim Aktivieren wird Active-Surface-Filtering angewendet: nicht aufgelöste Refs auf aktiven Oberflächen führen zu fehlschlagendem Startup/Reload, während inaktive Oberflächen mit Diagnosen übersprungen werden. --- -## Auth-Speicher +## Speicherung der Authentifizierung ```json5 { @@ -3300,12 +3301,12 @@ Hinweise: ``` - Profile pro Agent werden unter `/auth-profiles.json` gespeichert. -- `auth-profiles.json` unterstützt Refs auf Wertebene (`keyRef` für `api_key`, `tokenRef` für `token`) für statische Zugangsdatenmodi. -- Profile im OAuth-Modus (`auth.profiles..mode = "oauth"`) unterstützen keine SecretRef-gestützten Auth-Profile-Zugangsdaten. -- Statische Laufzeit-Zugangsdaten stammen aus aufgelösten In-Memory-Snapshots; veraltete statische Einträge in `auth.json` werden beim Erkennen bereinigt. -- Legacy-OAuth-Importe aus `~/.openclaw/credentials/oauth.json`. +- `auth-profiles.json` unterstützt Refs auf Wertebene (`keyRef` für `api_key`, `tokenRef` für `token`) für statische Anmeldedatenmodi. +- OAuth-Modus-Profile (`auth.profiles..mode = "oauth"`) unterstützen keine SecretRef-gestützten Anmeldedaten in Auth-Profilen. +- Statische Laufzeit-Anmeldedaten stammen aus aufgelösten In-Memory-Snapshots; Legacy-statische Einträge in `auth.json` werden beim Auffinden bereinigt. +- Legacy-OAuth-Importe kommen aus `~/.openclaw/credentials/oauth.json`. - Siehe [OAuth](/de/concepts/oauth). -- Verhalten der Secrets-Laufzeit und Tools für `audit/configure/apply`: [Secrets Management](/de/gateway/secrets). +- Secrets-Laufzeitverhalten sowie Werkzeuge `audit/configure/apply`: [Secrets Management](/de/gateway/secrets). ### `auth.cooldowns` @@ -3327,15 +3328,15 @@ Hinweise: } ``` -- `billingBackoffHours`: Basis-Backoff in Stunden, wenn ein Profil aufgrund echter Abrechnungs-/unzureichender-Guthaben-Fehler fehlschlägt (Standard: `5`). Expliziter Abrechnungstext kann selbst bei `401`-/`403`-Antworten hier landen, aber providerspezifische Text-Matcher bleiben auf den jeweiligen Provider beschränkt, dem sie gehören (zum Beispiel OpenRouter `Key limit exceeded`). Wiederholbare `402`-Nutzungsfenster- oder Organisations-/Workspace-Ausgabenlimit-Meldungen bleiben stattdessen im Pfad `rate_limit`. -- `billingBackoffHoursByProvider`: optionale Überschreibungen der Billing-Backoff-Stunden pro Provider. -- `billingMaxHours`: Obergrenze in Stunden für das exponentielle Anwachsen des Billing-Backoff (Standard: `24`). -- `authPermanentBackoffMinutes`: Basis-Backoff in Minuten für High-Confidence-Fehler vom Typ `auth_permanent` (Standard: `10`). -- `authPermanentMaxMinutes`: Obergrenze in Minuten für das Anwachsen des `auth_permanent`-Backoff (Standard: `60`). -- `failureWindowHours`: rollierendes Fenster in Stunden, das für Backoff-Zähler verwendet wird (Standard: `24`). -- `overloadedProfileRotations`: maximale Anzahl von Auth-Profile-Rotationen beim selben Provider für Überlastungsfehler, bevor auf Modell-Fallback umgeschaltet wird (Standard: `1`). Provider-busy-Formen wie `ModelNotReadyException` landen hier. -- `overloadedBackoffMs`: feste Verzögerung vor erneutem Versuch einer Rotation eines überlasteten Provider-/Profils (Standard: `0`). -- `rateLimitedProfileRotations`: maximale Anzahl von Auth-Profile-Rotationen beim selben Provider für Rate-Limit-Fehler, bevor auf Modell-Fallback umgeschaltet wird (Standard: `1`). Dieser Rate-Limit-Bucket umfasst providerförmigen Text wie `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, `workers_ai ... quota limit exceeded` und `resource exhausted`. +- `billingBackoffHours`: Basis-Backoff in Stunden, wenn ein Profil wegen echter Abrechnungs-/unzureichender-Credits-Fehler fehlschlägt (Standard: `5`). Expliziter Abrechnungstext kann trotzdem hier landen, selbst bei `401`-/`403`-Antworten, anbieterbezogene Textmatcher bleiben aber auf den Anbieter beschränkt, zu dem sie gehören (zum Beispiel OpenRouter `Key limit exceeded`). Retry-fähige `402`-Nachrichten zu Nutzungsfenstern oder Ausgabenlimits für Organisationen/Workspaces bleiben stattdessen im Pfad `rate_limit`. +- `billingBackoffHoursByProvider`: optionale anbieterspezifische Überschreibungen für Billing-Backoff in Stunden. +- `billingMaxHours`: Obergrenze in Stunden für das exponentielle Wachstum des Billing-Backoff (Standard: `24`). +- `authPermanentBackoffMinutes`: Basis-Backoff in Minuten für Fehler vom Typ `auth_permanent` mit hoher Sicherheit (Standard: `10`). +- `authPermanentMaxMinutes`: Obergrenze in Minuten für das Wachstum des `auth_permanent`-Backoff (Standard: `60`). +- `failureWindowHours`: gleitendes Fenster in Stunden, das für Backoff-Zähler verwendet wird (Standard: `24`). +- `overloadedProfileRotations`: maximale Anzahl von Rotationen von Auth-Profilen desselben Anbieters bei Überlastungsfehlern, bevor auf Modell-Fallback umgeschaltet wird (Standard: `1`). Formen von Anbieterüberlastung wie `ModelNotReadyException` landen hier. +- `overloadedBackoffMs`: feste Verzögerung vor einem erneuten Versuch einer Profilrotation bei überlastetem Anbieter/Profil (Standard: `0`). +- `rateLimitedProfileRotations`: maximale Anzahl von Rotationen von Auth-Profilen desselben Anbieters bei Rate-Limit-Fehlern, bevor auf Modell-Fallback umgeschaltet wird (Standard: `1`). Dieser Rate-Limit-Bucket umfasst auch anbieterspezifische Texte wie `Too many concurrent requests`, `ThrottlingException`, `concurrency limit reached`, `workers_ai ... quota limit exceeded` und `resource exhausted`. --- @@ -3356,8 +3357,8 @@ Hinweise: - Standard-Logdatei: `/tmp/openclaw/openclaw-YYYY-MM-DD.log`. - Setzen Sie `logging.file` für einen stabilen Pfad. -- `consoleLevel` wird mit `--verbose` auf `debug` erhöht. -- `maxFileBytes`: maximale Größe der Logdatei in Bytes, bevor Schreibvorgänge unterdrückt werden (positive Ganzzahl; Standard: `524288000` = 500 MB). Verwenden Sie für Produktionsbereitstellungen externe Logrotation. +- `consoleLevel` wird bei `--verbose` auf `debug` erhöht. +- `maxFileBytes`: maximale Größe der Logdatei in Bytes, bevor Schreibvorgänge unterdrückt werden (positiver Integer; Standard: `524288000` = 500 MB). Verwenden Sie für Produktions-Deployments externe Logrotation. --- @@ -3394,17 +3395,17 @@ Hinweise: } ``` -- `enabled`: globaler Hauptschalter für Instrumentierungsausgaben (Standard: `true`). -- `flags`: Array von Flag-Strings zum Aktivieren gezielter Log-Ausgaben (unterstützt Wildcards wie `"telegram.*"` oder `"*"`). -- `stuckSessionWarnMs`: Altersschwellenwert in ms für die Ausgabe von Warnungen zu festhängenden Sitzungen, solange eine Sitzung im Verarbeitungsstatus bleibt. -- `otel.enabled`: aktiviert die OpenTelemetry-Export-Pipeline (Standard: `false`). +- `enabled`: globaler Schalter für die Ausgabe von Instrumentierung (Standard: `true`). +- `flags`: Array aus Flag-Strings zum Aktivieren gezielter Logausgaben (unterstützt Wildcards wie `"telegram.*"` oder `"*"`). +- `stuckSessionWarnMs`: Altersschwelle in ms für die Ausgabe von Warnungen zu festhängenden Sitzungen, solange eine Sitzung im Verarbeitungszustand bleibt. +- `otel.enabled`: aktiviert die OpenTelemetry-Exportpipeline (Standard: `false`). - `otel.endpoint`: Collector-URL für den OTel-Export. - `otel.protocol`: `"http/protobuf"` (Standard) oder `"grpc"`. -- `otel.headers`: zusätzliche HTTP-/gRPC-Metadaten-Header, die mit OTel-Exportanfragen gesendet werden. -- `otel.serviceName`: Servicename für Ressourcenattribute. -- `otel.traces` / `otel.metrics` / `otel.logs`: aktiviert Trace-, Metrik- oder Log-Export. -- `otel.sampleRate`: Trace-Sampling-Rate `0`–`1`. -- `otel.flushIntervalMs`: Intervall in ms für periodisches Flushen von Telemetrie. +- `otel.headers`: zusätzliche HTTP-/gRPC-Metadaten-Header, die mit OTel-Export-Requests gesendet werden. +- `otel.serviceName`: Dienstname für Ressourcenattribute. +- `otel.traces` / `otel.metrics` / `otel.logs`: aktiviert den Export von Traces, Metriken oder Logs. +- `otel.sampleRate`: Sampling-Rate für Traces `0`–`1`. +- `otel.flushIntervalMs`: periodisches Flush-Intervall für Telemetrie in ms. - `cacheTrace.enabled`: protokolliert Cache-Trace-Snapshots für eingebettete Läufe (Standard: `false`). - `cacheTrace.filePath`: Ausgabepfad für Cache-Trace-JSONL (Standard: `$OPENCLAW_STATE_DIR/logs/cache-trace.jsonl`). - `cacheTrace.includeMessages` / `includePrompt` / `includeSystem`: steuern, was in der Cache-Trace-Ausgabe enthalten ist (alle standardmäßig: `true`). @@ -3430,11 +3431,11 @@ Hinweise: ``` - `channel`: Release-Kanal für npm-/Git-Installationen — `"stable"`, `"beta"` oder `"dev"`. -- `checkOnStart`: beim Start des Gateways auf npm-Updates prüfen (Standard: `true`). +- `checkOnStart`: beim Start des Gateway nach npm-Updates suchen (Standard: `true`). - `auto.enabled`: Hintergrund-Auto-Update für Paketinstallationen aktivieren (Standard: `false`). -- `auto.stableDelayHours`: minimale Verzögerung in Stunden vor automatischer Anwendung im Stable-Kanal (Standard: `6`; Maximalwert: `168`). -- `auto.stableJitterHours`: zusätzliches Verteilungsfenster in Stunden für den Stable-Kanal-Rollout (Standard: `12`; Maximalwert: `168`). -- `auto.betaCheckIntervalHours`: wie oft Prüfungen im Beta-Kanal in Stunden ausgeführt werden (Standard: `1`; Maximalwert: `24`). +- `auto.stableDelayHours`: minimale Verzögerung in Stunden vor automatischer Anwendung im Stable-Kanal (Standard: `6`; max: `168`). +- `auto.stableJitterHours`: zusätzliches Rollout-Streuungsfenster in Stunden für den Stable-Kanal (Standard: `12`; max: `168`). +- `auto.betaCheckIntervalHours`: wie oft Prüfungen für den Beta-Kanal in Stunden laufen (Standard: `1`; max: `24`). --- @@ -3468,21 +3469,21 @@ Hinweise: ``` - `enabled`: globales ACP-Feature-Gate (Standard: `false`). -- `dispatch.enabled`: unabhängiges Gate für die Verteilung von ACP-Sitzungs-Turns (Standard: `true`). Setzen Sie `false`, um ACP-Befehle verfügbar zu halten, aber die Ausführung zu blockieren. -- `backend`: Standard-ID des ACP-Laufzeit-Backends (muss einem registrierten ACP-Laufzeit-Plugin entsprechen). -- `defaultAgent`: Fallback-Ziel-Agent-ID für ACP, wenn Starts kein explizites Ziel angeben. -- `allowedAgents`: Allowlist von Agent-IDs, die für ACP-Laufzeitsitzungen zulässig sind; leer bedeutet keine zusätzliche Einschränkung. +- `dispatch.enabled`: unabhängiges Gate für die Turn-Dispatch von ACP-Sitzungen (Standard: `true`). Setzen Sie `false`, um ACP-Befehle verfügbar zu halten, aber die Ausführung zu blockieren. +- `backend`: Standard-ID des ACP-Runtime-Backends (muss einem registrierten ACP-Runtime-Plugin entsprechen). +- `defaultAgent`: Fallback-Ziel-Agent-ID für ACP, wenn Spawns kein explizites Ziel angeben. +- `allowedAgents`: Allowlist von Agent-IDs, die für ACP-Runtime-Sitzungen erlaubt sind; leer bedeutet keine zusätzliche Einschränkung. - `maxConcurrentSessions`: maximale Anzahl gleichzeitig aktiver ACP-Sitzungen. - `stream.coalesceIdleMs`: Idle-Flush-Fenster in ms für gestreamten Text. -- `stream.maxChunkChars`: maximale Chunk-Größe, bevor die Projektion gestreamter Blöcke aufgeteilt wird. +- `stream.maxChunkChars`: maximale Chunk-Größe vor dem Aufteilen der gestreamten Blockprojektion. - `stream.repeatSuppression`: unterdrückt wiederholte Status-/Tool-Zeilen pro Turn (Standard: `true`). -- `stream.deliveryMode`: `"live"` streamt inkrementell; `"final_only"` puffert bis zu den terminalen Turn-Ereignissen. -- `stream.hiddenBoundarySeparator`: Trennzeichen vor sichtbarem Text nach versteckten Tool-Ereignissen (Standard: `"paragraph"`). +- `stream.deliveryMode`: `"live"` streamt inkrementell; `"final_only"` puffert bis zu terminalen Turn-Ereignissen. +- `stream.hiddenBoundarySeparator`: Trennzeichen vor sichtbarem Text nach verborgenen Tool-Ereignissen (Standard: `"paragraph"`). - `stream.maxOutputChars`: maximale Anzahl projizierter Assistant-Ausgabezeichen pro ACP-Turn. -- `stream.maxSessionUpdateChars`: maximale Zeichenzahl für projizierte ACP-Status-/Update-Zeilen. +- `stream.maxSessionUpdateChars`: maximale Anzahl Zeichen für projizierte ACP-Status-/Update-Zeilen. - `stream.tagVisibility`: Zuordnung von Tag-Namen zu booleschen Sichtbarkeitsüberschreibungen für gestreamte Ereignisse. - `runtime.ttlMinutes`: Idle-TTL in Minuten für ACP-Sitzungs-Worker, bevor sie für die Bereinigung infrage kommen. -- `runtime.installCommand`: optionaler Installationsbefehl, der beim Bootstrap einer ACP-Laufzeitumgebung ausgeführt wird. +- `runtime.installCommand`: optionaler Installationsbefehl, der beim Bootstrap einer ACP-Runtime-Umgebung ausgeführt wird. --- @@ -3508,7 +3509,7 @@ Hinweise: ## Wizard -Metadaten, die von geführten CLI-Setup-Abläufen (`onboard`, `configure`, `doctor`) geschrieben werden: +Von CLI-geführten Setup-Abläufen (`onboard`, `configure`, `doctor`) geschriebene Metadaten: ```json5 { @@ -3524,15 +3525,15 @@ Metadaten, die von geführten CLI-Setup-Abläufen (`onboard`, `configure`, `doct --- -## Identity +## Identität -Siehe die Identity-Felder in `agents.list` unter [Agent-Standards](#agent-defaults). +Siehe `agents.list`-Identitätsfelder unter [Agent-Standards](#agent-defaults). --- ## Bridge (Legacy, entfernt) -Aktuelle Builds enthalten die TCP-Bridge nicht mehr. Nodes verbinden sich über das Gateway-WebSocket. Schlüssel unter `bridge.*` sind nicht mehr Teil des Konfigurationsschemas (die Validierung schlägt fehl, bis sie entfernt werden; `openclaw doctor --fix` kann unbekannte Schlüssel entfernen). +Aktuelle Builds enthalten die TCP-Bridge nicht mehr. Nodes verbinden sich über das Gateway WebSocket. `bridge.*`-Schlüssel sind nicht mehr Teil des Konfigurationsschemas (die Validierung schlägt fehl, bis sie entfernt werden; `openclaw doctor --fix` kann unbekannte Schlüssel entfernen). @@ -3563,19 +3564,19 @@ Aktuelle Builds enthalten die TCP-Bridge nicht mehr. Nodes verbinden sich über maxConcurrentRuns: 2, webhook: "https://example.invalid/legacy", // veralteter Fallback für gespeicherte Jobs mit notify:true webhookToken: "replace-with-dedicated-token", // optionales Bearer-Token für ausgehende Webhook-Authentifizierung - sessionRetention: "24h", // Dauerzeichenfolge oder false + sessionRetention: "24h", // Dauer-String oder false runLog: { - maxBytes: "2mb", // standardmäßig 2_000_000 Bytes - keepLines: 2000, // standardmäßig 2000 + maxBytes: "2mb", // Standard 2_000_000 Bytes + keepLines: 2000, // Standard 2000 }, }, } ``` -- `sessionRetention`: wie lange abgeschlossene isolierte Cron-Run-Sitzungen in `sessions.json` aufbewahrt werden, bevor sie entfernt werden. Steuert auch die Bereinigung archivierter gelöschter Cron-Transkripte. Standard: `24h`; setzen Sie `false`, um dies zu deaktivieren. -- `runLog.maxBytes`: maximale Größe pro Run-Log-Datei (`cron/runs/.jsonl`), bevor sie gekürzt wird. Standard: `2_000_000` Bytes. -- `runLog.keepLines`: neueste Zeilen, die beibehalten werden, wenn die Kürzung des Run-Logs ausgelöst wird. Standard: `2000`. -- `webhookToken`: Bearer-Token, das für die POST-Zustellung an Cron-Webhooks (`delivery.mode = "webhook"`) verwendet wird; wenn nicht gesetzt, wird kein Auth-Header gesendet. +- `sessionRetention`: wie lange abgeschlossene isolierte Cron-Run-Sitzungen aufbewahrt werden, bevor sie aus `sessions.json` entfernt werden. Steuert auch die Bereinigung archivierter gelöschter Cron-Transkripte. Standard: `24h`; setzen Sie `false`, um dies zu deaktivieren. +- `runLog.maxBytes`: maximale Größe pro Run-Log-Datei (`cron/runs/.jsonl`) vor der Bereinigung. Standard: `2_000_000` Bytes. +- `runLog.keepLines`: neueste Zeilen, die beibehalten werden, wenn die Bereinigung des Run-Logs ausgelöst wird. Standard: `2000`. +- `webhookToken`: Bearer-Token, das für die POST-Zustellung an Cron-Webhooks verwendet wird (`delivery.mode = "webhook"`); wenn nicht gesetzt, wird kein Auth-Header gesendet. - `webhook`: veraltete Legacy-Fallback-Webhook-URL (http/https), die nur für gespeicherte Jobs verwendet wird, die noch `notify: true` haben. ### `cron.retry` @@ -3592,11 +3593,11 @@ Aktuelle Builds enthalten die TCP-Bridge nicht mehr. Nodes verbinden sich über } ``` -- `maxAttempts`: maximale Anzahl von Wiederholungen für einmalige Jobs bei transienten Fehlern (Standard: `3`; Bereich: `0`–`10`). +- `maxAttempts`: maximale Anzahl von Wiederholungsversuchen für One-Shot-Jobs bei transienten Fehlern (Standard: `3`; Bereich: `0`–`10`). - `backoffMs`: Array von Backoff-Verzögerungen in ms für jeden Wiederholungsversuch (Standard: `[30000, 60000, 300000]`; 1–10 Einträge). - `retryOn`: Fehlertypen, die Wiederholungen auslösen — `"rate_limit"`, `"overloaded"`, `"network"`, `"timeout"`, `"server_error"`. Weglassen, um alle transienten Typen zu wiederholen. -Gilt nur für einmalige Cron-Jobs. Wiederkehrende Jobs verwenden eine separate Fehlerbehandlung. +Gilt nur für One-Shot-Cron-Jobs. Wiederkehrende Jobs verwenden eine separate Fehlerbehandlung. ### `cron.failureAlert` @@ -3614,11 +3615,11 @@ Gilt nur für einmalige Cron-Jobs. Wiederkehrende Jobs verwenden eine separate F } ``` -- `enabled`: Fehlerwarnungen für Cron-Jobs aktivieren (Standard: `false`). -- `after`: aufeinanderfolgende Fehler, bevor eine Warnung ausgelöst wird (positive Ganzzahl, Minimum: `1`). -- `cooldownMs`: minimale Millisekunden zwischen wiederholten Warnungen für denselben Job (nicht negative Ganzzahl). -- `mode`: Zustellmodus — `"announce"` sendet über eine Kanalnachricht; `"webhook"` sendet einen POST an den konfigurierten Webhook. -- `accountId`: optionale Konto- oder Kanal-ID zur Eingrenzung der Warnzustellung. +- `enabled`: Fehlermeldungen für Cron-Jobs aktivieren (Standard: `false`). +- `after`: aufeinanderfolgende Fehler, bevor eine Meldung ausgelöst wird (positiver Integer, min: `1`). +- `cooldownMs`: minimale Millisekunden zwischen wiederholten Meldungen für denselben Job (nicht negativer Integer). +- `mode`: Zustellmodus — `"announce"` sendet per Kanalnachricht; `"webhook"` postet an den konfigurierten Webhook. +- `accountId`: optionale Konto- oder Kanal-ID, um die Zustellung der Meldung zu begrenzen. ### `cron.failureDestination` @@ -3635,45 +3636,45 @@ Gilt nur für einmalige Cron-Jobs. Wiederkehrende Jobs verwenden eine separate F } ``` -- Standardziel für Cron-Fehlerbenachrichtigungen über alle Jobs hinweg. +- Standardziel für Fehlermeldungen von Cron-Jobs über alle Jobs hinweg. - `mode`: `"announce"` oder `"webhook"`; standardmäßig `"announce"`, wenn genügend Zieldaten vorhanden sind. -- `channel`: Kanalüberschreibung für die Zustellung per `announce`. `"last"` verwendet den zuletzt bekannten Zustellkanal erneut. -- `to`: explizites `announce`-Ziel oder Webhook-URL. Für den Webhook-Modus erforderlich. +- `channel`: Kanalüberschreibung für announce-Zustellung. `"last"` verwendet den zuletzt bekannten Zustellkanal wieder. +- `to`: explizites announce-Ziel oder Webhook-URL. Für den Webhook-Modus erforderlich. - `accountId`: optionale Kontoüberschreibung für die Zustellung. -- Pro Job überschreibt `delivery.failureDestination` diesen globalen Standard. -- Wenn weder global noch pro Job ein Fehlerziel gesetzt ist, greifen Jobs, die bereits per `announce` zustellen, im Fehlerfall auf dieses primäre `announce`-Ziel zurück. +- `delivery.failureDestination` pro Job überschreibt diesen globalen Standard. +- Wenn weder global noch pro Job ein Fehlerziel gesetzt ist, greifen Jobs, die bereits per `announce` zustellen, bei Fehlern auf dieses primäre announce-Ziel zurück. - `delivery.failureDestination` wird nur für Jobs mit `sessionTarget="isolated"` unterstützt, es sei denn, der primäre `delivery.mode` des Jobs ist `"webhook"`. -Siehe [Cron Jobs](/de/automation/cron-jobs). Isolierte Cron-Ausführungen werden als [Hintergrundaufgaben](/de/automation/tasks) verfolgt. +Siehe [Cron Jobs](/de/automation/cron-jobs). Isolierte Cron-Ausführungen werden als [background tasks](/de/automation/tasks) verfolgt. --- -## Variablenvorlagen für Medienmodelle +## Template-Variablen für Medienmodelle -Vorlagen-Platzhalter, die in `tools.media.models[].args` erweitert werden: +Template-Platzhalter, die in `tools.media.models[].args` erweitert werden: -| Variable | Beschreibung | -| ------------------ | ------------------------------------------------ | -| `{{Body}}` | Vollständiger eingehender Nachrichtentext | -| `{{RawBody}}` | Roher Nachrichtentext (ohne Verlauf-/Absender-Wrapper) | +| Variable | Beschreibung | +| ------------------ | ----------------------------------------------- | +| `{{Body}}` | Vollständiger eingehender Nachrichtentext | +| `{{RawBody}}` | Roher Nachrichtentext (ohne Verlaufs-/Absender-Wrapper) | | `{{BodyStripped}}` | Nachrichtentext mit entfernten Gruppenerwähnungen | -| `{{From}}` | Absenderkennung | -| `{{To}}` | Zielkennung | -| `{{MessageSid}}` | Kanal-Nachrichten-ID | -| `{{SessionId}}` | UUID der aktuellen Sitzung | -| `{{IsNewSession}}` | `"true"`, wenn eine neue Sitzung erstellt wurde | -| `{{MediaUrl}}` | Pseudo-URL eingehender Medien | -| `{{MediaPath}}` | Lokaler Medienpfad | -| `{{MediaType}}` | Medientyp (image/audio/document/…) | -| `{{Transcript}}` | Audio-Transkript | -| `{{Prompt}}` | Aufgelöster Medien-Prompt für CLI-Einträge | -| `{{MaxChars}}` | Aufgelöste maximale Ausgabezeichen für CLI-Einträge | -| `{{ChatType}}` | `"direct"` oder `"group"` | -| `{{GroupSubject}}` | Gruppenbetreff (best effort) | -| `{{GroupMembers}}` | Vorschau der Gruppenmitglieder (best effort) | -| `{{SenderName}}` | Anzeigename des Absenders (best effort) | -| `{{SenderE164}}` | Telefonnummer des Absenders (best effort) | -| `{{Provider}}` | Provider-Hinweis (whatsapp, telegram, discord usw.) | +| `{{From}}` | Absenderkennung | +| `{{To}}` | Zielkennung | +| `{{MessageSid}}` | Kanal-Nachrichten-ID | +| `{{SessionId}}` | Aktuelle Sitzungs-UUID | +| `{{IsNewSession}}` | `"true"`, wenn eine neue Sitzung erstellt wurde | +| `{{MediaUrl}}` | Pseudo-URL eingehender Medien | +| `{{MediaPath}}` | Lokaler Medienpfad | +| `{{MediaType}}` | Medientyp (image/audio/document/…) | +| `{{Transcript}}` | Audio-Transkript | +| `{{Prompt}}` | Aufgelöster Medien-Prompt für CLI-Einträge | +| `{{MaxChars}}` | Aufgelöste maximale Ausgabelänge in Zeichen für CLI-Einträge | +| `{{ChatType}}` | `"direct"` oder `"group"` | +| `{{GroupSubject}}` | Gruppenbetreff (best effort) | +| `{{GroupMembers}}` | Vorschau auf Gruppenmitglieder (best effort) | +| `{{SenderName}}` | Anzeigename des Absenders (best effort) | +| `{{SenderE164}}` | Telefonnummer des Absenders (best effort) | +| `{{Provider}}` | Anbieterhinweis (whatsapp, telegram, discord usw.) | --- @@ -3695,12 +3696,12 @@ Teilen Sie die Konfiguration in mehrere Dateien auf: **Merge-Verhalten:** - Einzelne Datei: ersetzt das enthaltende Objekt. -- Array von Dateien: wird in Reihenfolge per Deep Merge zusammengeführt (spätere überschreiben frühere). -- Geschwisterschlüssel: werden nach den Includes zusammengeführt (überschreiben eingeschlossene Werte). +- Array von Dateien: wird in Reihenfolge tief zusammengeführt (spätere überschreiben frühere). +- Benachbarte Schlüssel: werden nach den Includes zusammengeführt (überschreiben inkludierte Werte). - Verschachtelte Includes: bis zu 10 Ebenen tief. -- Pfade: werden relativ zur einschließenden Datei aufgelöst, müssen aber innerhalb des Top-Level-Konfigurationsverzeichnisses (`dirname` von `openclaw.json`) bleiben. Absolute/`../`-Formen sind nur erlaubt, wenn sie sich trotzdem innerhalb dieser Grenze auflösen. +- Pfade: werden relativ zur inkludierenden Datei aufgelöst, müssen aber innerhalb des Konfigurationsverzeichnisses der obersten Ebene bleiben (`dirname` von `openclaw.json`). Absolute Formen/`../` sind nur erlaubt, wenn sie sich dennoch innerhalb dieser Grenze auflösen. - Fehler: klare Meldungen für fehlende Dateien, Parse-Fehler und zirkuläre Includes. --- -_Verwandt: [Konfiguration](/de/gateway/configuration) · [Konfigurationsbeispiele](/de/gateway/configuration-examples) · [Doctor](/de/gateway/doctor)_ +_Verwandt: [Configuration](/de/gateway/configuration) · [Configuration Examples](/de/gateway/configuration-examples) · [Doctor](/de/gateway/doctor)_ diff --git a/docs/de/gateway/local-models.md b/docs/de/gateway/local-models.md index 8e6b030d7..d5471335a 100644 --- a/docs/de/gateway/local-models.md +++ b/docs/de/gateway/local-models.md @@ -1,28 +1,28 @@ --- read_when: - - Sie möchten Modelle von Ihrer eigenen GPU-Maschine bereitstellen. - - Sie richten LM Studio oder einen OpenAI-kompatiblen Proxy ein. - - Sie benötigen die sicherste Anleitung für lokale Modelle. + - Du möchtest Modelle von deiner eigenen GPU-Maschine bereitstellen. + - Du richtest LM Studio oder einen OpenAI-kompatiblen Proxy ein. + - Du benötigst die sicherste Anleitung für lokale Modelle. summary: OpenClaw auf lokalen LLMs ausführen (LM Studio, vLLM, LiteLLM, benutzerdefinierte OpenAI-Endpunkte) title: Lokale Modelle x-i18n: - generated_at: "2026-04-15T06:21:28Z" + generated_at: "2026-04-15T14:40:32Z" model: gpt-5.4 provider: openai - source_hash: 8778cc1c623a356ff3cf306c494c046887f9417a70ec71e659e4a8aae912a780 + source_hash: 7a506ff83e4c2870d3878339f646c906584454a156ecd618c360f592cf3b0011 source_path: gateway/local-models.md workflow: 15 --- # Lokale Modelle -Lokal ist machbar, aber OpenClaw erwartet ein großes Kontextfenster + starke Abwehr gegen Prompt-Injection. Kleine Karten kürzen den Kontext und schwächen die Sicherheit. Setzen Sie hoch an: **≥2 voll ausgestattete Mac Studios oder ein vergleichbares GPU-Setup (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts mit höherer Latenz. Verwenden Sie die **größte / vollwertige Modellvariante, die Sie ausführen können**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Prompt-Injection-Risiko (siehe [Sicherheit](/de/gateway/security)). +Lokal ist machbar, aber OpenClaw erwartet großen Kontext und starke Abwehrmechanismen gegen Prompt-Injection. Kleine Grafikkarten beschneiden den Kontext und schwächen die Sicherheit. Setze hoch an: **≥2 voll ausgestattete Mac Studios oder ein vergleichbares GPU-System (~30.000 $+)**. Eine einzelne **24-GB**-GPU funktioniert nur für leichtere Prompts bei höherer Latenz. Verwende die **größte / vollwertige Modellvariante, die du ausführen kannst**; stark quantisierte oder „kleine“ Checkpoints erhöhen das Prompt-Injection-Risiko (siehe [Sicherheit](/de/gateway/security)). -Wenn Sie die lokale Einrichtung mit der geringsten Reibung möchten, beginnen Sie mit [LM Studio](/de/providers/lmstudio) oder [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für leistungsstärkere lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server. +Wenn du die lokale Einrichtung mit der geringsten Reibung möchtest, beginne mit [LM Studio](/de/providers/lmstudio) oder [Ollama](/de/providers/ollama) und `openclaw onboard`. Diese Seite ist der meinungsstarke Leitfaden für leistungsstärkere lokale Stacks und benutzerdefinierte OpenAI-kompatible lokale Server. ## Empfohlen: LM Studio + großes lokales Modell (Responses API) -Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktivieren Sie den lokalen Server (Standard: `http://127.0.0.1:1234`) und verwenden Sie die Responses API, um das Reasoning vom endgültigen Text getrennt zu halten. +Der derzeit beste lokale Stack. Lade ein großes Modell in LM Studio (zum Beispiel einen vollwertigen Qwen-, DeepSeek- oder Llama-Build), aktiviere den lokalen Server (Standard: `http://127.0.0.1:1234`) und verwende die Responses API, damit das Reasoning vom finalen Text getrennt bleibt. ```json5 { @@ -61,16 +61,16 @@ Der derzeit beste lokale Stack. Laden Sie ein großes Modell in LM Studio (zum B **Checkliste für die Einrichtung** -- Installieren Sie LM Studio: [https://lmstudio.ai](https://lmstudio.ai) -- Laden Sie in LM Studio den **größten verfügbaren Modell-Build** herunter (vermeiden Sie „small“-/stark quantisierte Varianten), starten Sie den Server und bestätigen Sie, dass `http://127.0.0.1:1234/v1/models` das Modell auflistet. -- Ersetzen Sie `my-local-model` durch die tatsächliche Modell-ID, die in LM Studio angezeigt wird. -- Halten Sie das Modell geladen; ein Kaltstart erhöht die Startlatenz. -- Passen Sie `contextWindow`/`maxTokens` an, falls Ihr LM-Studio-Build davon abweicht. -- Für WhatsApp sollten Sie bei der Responses API bleiben, damit nur der endgültige Text gesendet wird. +- Installiere LM Studio: [https://lmstudio.ai](https://lmstudio.ai) +- Lade in LM Studio den **größten verfügbaren Modell-Build** herunter (vermeide „small“-/stark quantisierte Varianten), starte den Server und bestätige, dass `http://127.0.0.1:1234/v1/models` ihn auflistet. +- Ersetze `my-local-model` durch die tatsächliche Modell-ID, die in LM Studio angezeigt wird. +- Halte das Modell geladen; Kaltstarts erhöhen die Startlatenz. +- Passe `contextWindow`/`maxTokens` an, wenn sich dein LM-Studio-Build unterscheidet. +- Für WhatsApp solltest du bei der Responses API bleiben, damit nur der finale Text gesendet wird. -Behalten Sie gehostete Modelle auch dann konfiguriert, wenn Sie lokal ausführen; verwenden Sie `models.mode: "merge"`, damit Fallbacks verfügbar bleiben. +Lass gehostete Modelle auch dann konfiguriert, wenn du lokal ausführst; verwende `models.mode: "merge"`, damit Fallbacks verfügbar bleiben. -### Hybride Konfiguration: gehostet primär, lokal als Fallback +### Hybride Konfiguration: gehostet als primär, lokal als Fallback ```json5 { @@ -113,16 +113,16 @@ Behalten Sie gehostete Modelle auch dann konfiguriert, wenn Sie lokal ausführen ### Lokal zuerst mit gehostetem Sicherheitsnetz -Tauschen Sie die Reihenfolge von Primärmodell und Fallbacks; behalten Sie denselben Providers-Block und `models.mode: "merge"` bei, damit Sie auf Sonnet oder Opus zurückgreifen können, wenn die lokale Maschine ausfällt. +Tausche die Reihenfolge von primärem Modell und Fallback aus; behalte denselben Provider-Block und `models.mode: "merge"` bei, damit du auf Sonnet oder Opus zurückfallen kannst, wenn die lokale Maschine ausfällt. ### Regionales Hosting / Datenrouting -- Gehostete MiniMax-/Kimi-/GLM-Varianten gibt es auch auf OpenRouter mit regional gebundenen Endpunkten (z. B. in den USA gehostet). Wählen Sie dort die regionale Variante, um den Datenverkehr in Ihrer gewünschten Rechtsordnung zu halten und gleichzeitig `models.mode: "merge"` für Anthropic-/OpenAI-Fallbacks zu verwenden. -- Nur lokal bleibt der stärkste Weg für Datenschutz; regionales gehostetes Routing ist der Mittelweg, wenn Sie Provider-Funktionen benötigen, aber die Kontrolle über den Datenfluss behalten möchten. +- Gehostete MiniMax-/Kimi-/GLM-Varianten gibt es auch auf OpenRouter mit regional festgelegten Endpunkten (z. B. in den USA gehostet). Wähle dort die regionale Variante, damit der Datenverkehr in deiner gewählten Jurisdiktion bleibt, und nutze weiterhin `models.mode: "merge"` für Anthropic-/OpenAI-Fallbacks. +- Nur lokal bleibt der stärkste Weg für Datenschutz; gehostetes regionales Routing ist der Mittelweg, wenn du Provider-Funktionen brauchst, aber den Datenfluss kontrollieren möchtest. ## Andere OpenAI-kompatible lokale Proxys -vLLM, LiteLLM, OAI-proxy oder benutzerdefinierte Gateways funktionieren, wenn sie einen OpenAI-ähnlichen `/v1`-Endpunkt bereitstellen. Ersetzen Sie den obigen Providers-Block durch Ihren Endpunkt und Ihre Modell-ID: +vLLM, LiteLLM, OAI-proxy oder benutzerdefinierte Gateways funktionieren, wenn sie einen OpenAI-artigen `/v1`-Endpunkt bereitstellen. Ersetze den obigen Provider-Block durch deinen Endpunkt und deine Modell-ID: ```json5 { @@ -150,45 +150,46 @@ vLLM, LiteLLM, OAI-proxy oder benutzerdefinierte Gateways funktionieren, wenn si } ``` -Behalten Sie `models.mode: "merge"` bei, damit gehostete Modelle als Fallbacks verfügbar bleiben. +Behalte `models.mode: "merge"` bei, damit gehostete Modelle als Fallbacks verfügbar bleiben. -Hinweis zum Verhalten für lokale/proxied `/v1`-Backends: +Verhaltenshinweis für lokale/proxied `/v1`-Backends: -- OpenClaw behandelt diese als proxyartige OpenAI-kompatible Routen, nicht als native - OpenAI-Endpunkte -- natives nur-für-OpenAI Request-Shaping gilt hier nicht: kein - `service_tier`, kein Responses-`store`, kein OpenAI-Reasoning-Kompatibilitäts-Payload- - Shaping und keine Prompt-Cache-Hinweise -- versteckte OpenClaw-Zuordnungs-Header (`originator`, `version`, `User-Agent`) - werden bei diesen benutzerdefinierten Proxy-URLs nicht eingefügt +- OpenClaw behandelt diese als proxyartige OpenAI-kompatible Routen, nicht als native OpenAI-Endpunkte +- natives, nur für OpenAI geltendes Request-Shaping greift hier nicht: kein + `service_tier`, kein Responses-`store`, kein OpenAI-Reasoning-kompatibles Payload-Shaping + und keine Prompt-Cache-Hinweise +- versteckte OpenClaw-Attributions-Header (`originator`, `version`, `User-Agent`) + werden auf diesen benutzerdefinierten Proxy-URLs nicht injiziert Kompatibilitätshinweise für strengere OpenAI-kompatible Backends: -- Einige Server akzeptieren bei Chat Completions nur String-`messages[].content`, nicht - strukturierte Content-Part-Arrays. Setzen Sie +- Einige Server akzeptieren bei Chat Completions nur `messages[].content` als String, nicht + strukturierte Content-Part-Arrays. Setze `models.providers..models[].compat.requiresStringContent: true` für diese Endpunkte. - Einige kleinere oder strengere lokale Backends sind mit der vollständigen - Prompt-Struktur der OpenClaw-Agent-Laufzeit instabil, insbesondere wenn Tool-Schemata enthalten sind. Wenn das - Backend für winzige direkte `/v1/chat/completions`-Aufrufe funktioniert, aber bei normalen - OpenClaw-Agent-Turns fehlschlägt, versuchen Sie zuerst - `agents.defaults.localModelMode: "lean"`, um schwergewichtige Standard-Tools - wie `browser`, `cron` und `message` wegzulassen; wenn das weiterhin fehlschlägt, versuchen Sie + Prompt-Form des OpenClaw-Agent-Runtimes instabil, insbesondere wenn Tool-Schemas enthalten sind. Wenn das + Backend für kleine direkte `/v1/chat/completions`-Aufrufe funktioniert, aber bei normalen + OpenClaw-Agent-Turns fehlschlägt, probiere zuerst + `agents.defaults.experimental.localModelLean: true`, um schwergewichtige + Standard-Tools wie `browser`, `cron` und `message` zu entfernen; dies ist ein experimentelles + Flag, keine stabile Einstellung für den Standardmodus. Siehe + [Experimentelle Funktionen](/de/concepts/experimental-features). Wenn das weiterhin fehlschlägt, versuche `models.providers..models[].compat.supportsTools: false`. -- Wenn das Backend weiterhin nur bei größeren OpenClaw-Läufen fehlschlägt, - liegt das verbleibende Problem in der Regel an der Kapazität des Upstream-Modells/Servers - oder an einem Backend-Fehler, nicht an der Transportschicht von OpenClaw. +- Wenn das Backend weiterhin nur bei größeren OpenClaw-Läufen fehlschlägt, liegt das verbleibende Problem + in der Regel an der Upstream-Modell-/Server-Kapazität oder an einem Backend-Fehler, nicht an der + Transportebene von OpenClaw. ## Fehlerbehebung -- Kann das Gateway den Proxy erreichen? `curl http://127.0.0.1:1234/v1/models`. -- LM-Studio-Modell entladen? Laden Sie es erneut; Kaltstart ist eine häufige Ursache für „Hängenbleiben“. -- OpenClaw warnt, wenn das erkannte Kontextfenster unter **32k** liegt, und blockiert unter **16k**. Wenn Sie auf diese Vorabprüfung stoßen, erhöhen Sie das Kontextlimit des Servers/Modells oder wählen Sie ein größeres Modell. -- Kontextfehler? Verringern Sie `contextWindow` oder erhöhen Sie Ihr Serverlimit. +- Kann Gateway den Proxy erreichen? `curl http://127.0.0.1:1234/v1/models`. +- Modell in LM Studio entladen? Lade es erneut; Kaltstart ist eine häufige Ursache für „Hängenbleiben“. +- OpenClaw warnt, wenn das erkannte Kontextfenster unter **32k** liegt, und blockiert unter **16k**. Wenn du auf diese Vorabprüfung triffst, erhöhe das Kontextlimit des Servers/Modells oder wähle ein größeres Modell. +- Kontextfehler? Verringere `contextWindow` oder erhöhe dein Serverlimit. - OpenAI-kompatibler Server gibt `messages[].content ... expected a string` zurück? - Fügen Sie `compat.requiresStringContent: true` zu diesem Modelleintrag hinzu. -- Direkte kleine `/v1/chat/completions`-Aufrufe funktionieren, aber `openclaw infer model run` - schlägt bei Gemma oder einem anderen lokalen Modell fehl? Deaktivieren Sie zuerst Tool-Schemata mit - `compat.supportsTools: false`, und testen Sie dann erneut. Wenn der Server weiterhin nur - bei größeren OpenClaw-Prompts abstürzt, behandeln Sie das als Einschränkung des Upstream-Servers/Modells. -- Sicherheit: Lokale Modelle überspringen providerseitige Filter; halten Sie Agents eng gefasst und lassen Sie Compaction aktiviert, um den Wirkungsbereich von Prompt-Injection zu begrenzen. + Füge `compat.requiresStringContent: true` bei diesem Modelleintrag hinzu. +- Kleine direkte `/v1/chat/completions`-Aufrufe funktionieren, aber `openclaw infer model run` + schlägt bei Gemma oder einem anderen lokalen Modell fehl? Deaktiviere zuerst Tool-Schemas mit + `compat.supportsTools: false` und teste dann erneut. Wenn der Server weiterhin nur + bei größeren OpenClaw-Prompts abstürzt, behandle das als Einschränkung des Upstream-Servers/Modells. +- Sicherheit: Lokale Modelle überspringen providerseitige Filter; halte Agenten eng gefasst und Compaction aktiviert, um den Schadensradius von Prompt-Injection zu begrenzen. diff --git a/docs/de/help/testing.md b/docs/de/help/testing.md index 690dad535..1d97682c5 100644 --- a/docs/de/help/testing.md +++ b/docs/de/help/testing.md @@ -4,38 +4,38 @@ read_when: - Regressionstests für Modell-/Provider-Fehler hinzufügen - Gateway- und Agent-Verhalten debuggen summary: 'Test-Kit: Unit-/E2E-/Live-Suites, Docker-Runner und was jeder Test abdeckt' -title: Testen +title: Tests x-i18n: - generated_at: "2026-04-15T06:21:26Z" + generated_at: "2026-04-15T14:40:31Z" model: gpt-5.4 provider: openai - source_hash: fbf647a5cf13b5861a3ba0cb367dc816c57f0e9c60d3cd6320da193bfadf5609 + source_hash: ec3632cafa1f38b27510372391b84af744266df96c58f7fac98aa03763465db8 source_path: help/testing.md workflow: 15 --- -# Testen +# Tests -OpenClaw hat drei Vitest-Suites (Unit/Integration, E2E, Live) und eine kleine Anzahl von Docker-Runnern. +OpenClaw hat drei Vitest-Suites (Unit/Integration, E2E, Live) und eine kleine Anzahl an Docker-Runnern. -Dieses Dokument ist ein Leitfaden dazu, „wie wir testen“: +Dieses Dokument ist ein Leitfaden dazu, **wie wir testen**: - Was jede Suite abdeckt (und was sie bewusst _nicht_ abdeckt) - Welche Befehle für gängige Workflows auszuführen sind (lokal, vor dem Push, Debugging) - Wie Live-Tests Anmeldedaten erkennen und Modelle/Provider auswählen -- Wie Regressionstests für reale Modell-/Provider-Probleme hinzugefügt werden +- Wie man Regressionen für reale Modell-/Provider-Probleme hinzufügt ## Schnellstart An den meisten Tagen: - Vollständiges Gate (vor dem Push erwartet): `pnpm build && pnpm check && pnpm test` -- Schnellere lokale Ausführung der vollständigen Suite auf einer leistungsstarken Maschine: `pnpm test:max` +- Schnellere lokale Ausführung der vollständigen Suite auf einer leistungsfähigen Maschine: `pnpm test:max` - Direkte Vitest-Watch-Schleife: `pnpm test:watch` -- Direktes Datei-Targeting leitet jetzt auch Erweiterungs-/Kanalpfade weiter: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Bevorzuge zuerst gezielte Ausführungen, wenn du an einem einzelnen Fehler arbeitest. +- Direktes Dateitargeting leitet jetzt auch Pfade für Erweiterungen/Channels weiter: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Bevorzuge zuerst gezielte Ausführungen, wenn du an einem einzelnen Fehler iterierst. - Docker-gestützte QA-Site: `pnpm qa:lab:up` -- Linux-VM-gestützte QA-Lane: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Linux-VM-gestützte QA-Strecke: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` Wenn du Tests anfasst oder zusätzliche Sicherheit möchtest: @@ -44,74 +44,73 @@ Wenn du Tests anfasst oder zusätzliche Sicherheit möchtest: Beim Debuggen realer Provider/Modelle (erfordert echte Anmeldedaten): -- Live-Suite (Modelle + Gateway-Tool-/Bild-Probes): `pnpm test:live` -- Eine Live-Datei gezielt und ohne viel Ausgabe ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Live-Suite (Modelle + Gateway-Tool-/Image-Prüfungen): `pnpm test:live` +- Eine einzelne Live-Datei leise ausführen: `pnpm test:live -- src/agents/models.profiles.live.test.ts` Tipp: Wenn du nur einen einzelnen fehlschlagenden Fall brauchst, grenze Live-Tests bevorzugt über die unten beschriebenen Allowlist-Umgebungsvariablen ein. ## QA-spezifische Runner -Diese Befehle stehen neben den Haupt-Test-Suites zur Verfügung, wenn du die Realitätsnähe von qa-lab brauchst: +Diese Befehle stehen neben den Haupttest-Suites zur Verfügung, wenn du mehr QA-lab-Realismus brauchst: - `pnpm openclaw qa suite` - Führt repo-gestützte QA-Szenarien direkt auf dem Host aus. - - Führt standardmäßig mehrere ausgewählte Szenarien parallel mit isolierten Gateway-Workern aus, bis zu 64 Worker oder die Anzahl der ausgewählten Szenarien. Verwende `--concurrency `, um die Anzahl der Worker anzupassen, oder `--concurrency 1` für die ältere serielle Lane. + - Führt standardmäßig mehrere ausgewählte Szenarien parallel mit isolierten Gateway-Workern aus, bis zu 64 Workern oder der Anzahl der ausgewählten Szenarien. Verwende `--concurrency `, um die Anzahl der Worker anzupassen, oder `--concurrency 1` für die ältere serielle Strecke. - `pnpm openclaw qa suite --runner multipass` - - Führt dieselbe QA-Suite innerhalb einer flüchtigen Multipass-Linux-VM aus. - - Behält dasselbe Verhalten zur Szenarioauswahl wie `qa suite` auf dem Host bei. + - Führt dieselbe QA-Suite in einer kurzlebigen Multipass-Linux-VM aus. + - Behält dasselbe Verhalten bei der Szenarioauswahl wie `qa suite` auf dem Host bei. - Verwendet dieselben Flags zur Provider-/Modellauswahl wie `qa suite`. - - Live-Ausführungen leiten die unterstützten QA-Authentifizierungseingaben weiter, die für den Gast praktikabel sind: - env-basierte Provider-Schlüssel, den Pfad zur QA-Live-Provider-Konfiguration und `CODEX_HOME`, wenn vorhanden. - - Ausgabeverzeichnisse müssen unter dem Repo-Root bleiben, damit der Gast über den eingehängten Workspace zurückschreiben kann. - - Schreibt den normalen QA-Bericht + die Zusammenfassung sowie Multipass-Logs unter - `.artifacts/qa-e2e/...`. + - Live-Ausführungen reichen die unterstützten QA-Auth-Eingaben weiter, die für den Gast praktikabel sind: + env-basierte Provider-Schlüssel, den QA-Live-Provider-Konfigurationspfad und `CODEX_HOME`, falls vorhanden. + - Ausgabeordner müssen unterhalb der Repo-Wurzel bleiben, damit der Gast über den eingebundenen Workspace zurückschreiben kann. + - Schreibt den normalen QA-Bericht + die Zusammenfassung sowie Multipass-Logs unter `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Startet die Docker-gestützte QA-Site für operatorähnliche QA-Arbeit. + - Startet die Docker-gestützte QA-Site für operatorartige QA-Arbeit. - `pnpm openclaw qa matrix` - - Führt die Matrix-Live-QA-Lane gegen einen flüchtigen, Docker-gestützten Tuwunel-Homeserver aus. - - Dieser QA-Host ist derzeit nur für Repo/Entwicklung gedacht. Gepackte OpenClaw-Installationen enthalten kein `qa-lab`, daher stellen sie `openclaw qa` nicht bereit. - - Repo-Checkouts laden den gebündelten Runner direkt; ein separater Installationsschritt für Plugins ist nicht erforderlich. - - Stellt drei temporäre Matrix-Benutzer (`driver`, `sut`, `observer`) sowie einen privaten Raum bereit und startet dann ein QA-Gateway-Child mit dem echten Matrix-Plugin als SUT-Transport. - - Verwendet standardmäßig das angeheftete stabile Tuwunel-Image `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Überschreibe es mit `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, wenn du ein anderes Image testen musst. - - Matrix stellt keine gemeinsamen Flags für Anmeldedatenquellen bereit, weil die Lane lokal flüchtige Benutzer bereitstellt. - - Schreibt einen Matrix-QA-Bericht, eine Zusammenfassung und ein Artefakt mit beobachteten Ereignissen unter `.artifacts/qa-e2e/...`. + - Führt die Matrix-Live-QA-Strecke gegen einen kurzlebigen Docker-gestützten Tuwunel-Homeserver aus. + - Dieser QA-Host ist aktuell nur für Repo/Entwicklung gedacht. Gepackte OpenClaw-Installationen liefern `qa-lab` nicht mit aus und stellen daher `openclaw qa` nicht bereit. + - Repo-Checkouts laden den gebündelten Runner direkt; kein separater Schritt zur Plugin-Installation ist erforderlich. + - Richtet drei temporäre Matrix-Benutzer (`driver`, `sut`, `observer`) sowie einen privaten Raum ein und startet dann ein QA-Gateway-Unterprozess mit dem echten Matrix-Plugin als SUT-Transport. + - Verwendet standardmäßig das festgepinnte stabile Tuwunel-Image `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Mit `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE` kannst du ein anderes Image zum Testen überschreiben. + - Matrix stellt keine gemeinsamen Flags für Anmeldedatenquellen bereit, da die Strecke lokal kurzlebige Benutzer bereitstellt. + - Schreibt einen Matrix-QA-Bericht, eine Zusammenfassung und ein Artifact mit beobachteten Ereignissen unter `.artifacts/qa-e2e/...`. - `pnpm openclaw qa telegram` - - Führt die Telegram-Live-QA-Lane gegen eine reale private Gruppe aus, wobei die Bot-Tokens von Driver und SUT aus der Umgebung verwendet werden. + - Führt die Telegram-Live-QA-Strecke gegen eine echte private Gruppe aus und verwendet dabei die Bot-Token für Driver und SUT aus der Umgebung. - Erfordert `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` und `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Die Gruppen-ID muss die numerische Telegram-Chat-ID sein. - - Unterstützt `--credential-source convex` für gemeinsam genutzte gepoolte Anmeldedaten. Verwende standardmäßig den env-Modus oder setze `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, um gepoolte Leases zu verwenden. + - Unterstützt `--credential-source convex` für gemeinsam genutzte gepoolte Anmeldedaten. Verwende standardmäßig den env-Modus oder setze `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, um gepoolte Leases zu nutzen. - Erfordert zwei unterschiedliche Bots in derselben privaten Gruppe, wobei der SUT-Bot einen Telegram-Benutzernamen bereitstellen muss. - - Für stabile Bot-zu-Bot-Beobachtung aktiviere in `@BotFather` den Bot-to-Bot Communication Mode für beide Bots und stelle sicher, dass der Driver-Bot Bot-Datenverkehr in der Gruppe beobachten kann. - - Schreibt einen Telegram-QA-Bericht, eine Zusammenfassung und ein Artefakt mit beobachteten Nachrichten unter `.artifacts/qa-e2e/...`. + - Für eine stabile Bot-zu-Bot-Beobachtung aktiviere in `@BotFather` für beide Bots den Bot-to-Bot Communication Mode und stelle sicher, dass der Driver-Bot Bot-Verkehr in der Gruppe beobachten kann. + - Schreibt einen Telegram-QA-Bericht, eine Zusammenfassung und ein Artifact mit beobachteten Nachrichten unter `.artifacts/qa-e2e/...`. -Live-Transport-Lanes teilen sich einen standardisierten Vertrag, damit neue Transporte nicht voneinander abweichen: +Live-Transport-Strecken teilen sich einen gemeinsamen Standardvertrag, damit neue Transporte nicht auseinanderdriften: -`qa-channel` bleibt die breite synthetische QA-Suite und ist nicht Teil der Live-Transport-Abdeckungsmatrix. +`qa-channel` bleibt die breit angelegte synthetische QA-Suite und ist nicht Teil der Live-Transport-Abdeckungsmatrix. -| Lane | Canary | Mention-Gating | Allowlist-Block | Antwort auf oberster Ebene | Fortsetzen nach Neustart | Thread-Follow-up | Thread-Isolierung | Beobachtung von Reaktionen | Hilfe-Befehl | -| -------- | ------ | -------------- | --------------- | -------------------------- | ------------------------ | ---------------- | ----------------- | -------------------------- | ------------ | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Strecke | Canary | Mention-Gating | Allowlist-Block | Antwort auf oberster Ebene | Fortsetzung nach Neustart | Thread-Follow-up | Thread-Isolation | Reaktionsbeobachtung | Help-Befehl | +| -------- | ------ | -------------- | --------------- | -------------------------- | ------------------------- | ---------------- | ---------------- | -------------------- | ----------- | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Gemeinsame Telegram-Anmeldedaten über Convex (v1) Wenn `--credential-source convex` (oder `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) für -`openclaw qa telegram` aktiviert ist, bezieht QA lab ein exklusives Lease aus einem Convex-gestützten Pool, sendet Heartbeat-Signale für dieses Lease, während die Lane läuft, und gibt das Lease beim Beenden frei. +`openclaw qa telegram` aktiviert ist, bezieht QA lab ein exklusives Lease aus einem Convex-gestützten Pool, sendet Heartbeat-Signale für dieses Lease, solange die Strecke läuft, und gibt das Lease beim Beenden wieder frei. Referenzgerüst für ein Convex-Projekt: - `qa/convex-credential-broker/` -Erforderliche Umgebungsvariablen: +Erforderliche env vars: - `OPENCLAW_QA_CONVEX_SITE_URL` (zum Beispiel `https://your-deployment.convex.site`) - Ein Secret für die ausgewählte Rolle: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` für `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` für `ci` -- Auswahl der Anmeldedatenrolle: +- Auswahl der Rolle für Anmeldedaten: - CLI: `--credential-role maintainer|ci` - - Standard in der Umgebung: `OPENCLAW_QA_CREDENTIAL_ROLE` (Standard ist `maintainer`) + - Env-Standard: `OPENCLAW_QA_CREDENTIAL_ROLE` (Standard ist `maintainer`) -Optionale Umgebungsvariablen: +Optionale env vars: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (Standard `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (Standard `30000`) @@ -119,11 +118,11 @@ Optionale Umgebungsvariablen: - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (Standard `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (Standard `/qa-credentials/v1`) - `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (optionale Trace-ID) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` erlaubt loopback-`http://`-Convex-URLs für rein lokale Entwicklung. +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` erlaubt Loopback-`http://`-Convex-URLs nur für lokale Entwicklung. -`OPENCLAW_QA_CONVEX_SITE_URL` sollte im normalen Betrieb `https://` verwenden. +`OPENCLAW_QA_CONVEX_SITE_URL` sollte im Normalbetrieb `https://` verwenden. -Maintainer-Admin-Befehle (Pool hinzufügen/entfernen/auflisten) erfordern +Admin-Befehle für Maintainer (Pool hinzufügen/entfernen/auflisten) erfordern explizit `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. CLI-Hilfsbefehle für Maintainer: @@ -136,7 +135,7 @@ pnpm openclaw qa credentials remove --credential-id Verwende `--json` für maschinenlesbare Ausgabe in Skripten und CI-Hilfsprogrammen. -Standard-Endpoint-Vertrag (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Standard-Endpunktvertrag (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Anfrage: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -159,62 +158,63 @@ Standard-Endpoint-Vertrag (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`) - Anfrage: `{ kind?, status?, includePayload?, limit? }` - Erfolg: `{ status: "ok", credentials, count }` -Payload-Form für die Art Telegram: +Payload-Form für Telegram-Typ: - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` muss eine numerische Telegram-Chat-ID als String sein. - `admin/add` validiert diese Form für `kind: "telegram"` und weist fehlerhafte Payloads zurück. -### Einen Kanal zu QA hinzufügen +### Einen Channel zu QA hinzufügen -Das Hinzufügen eines Kanals zum Markdown-QA-System erfordert genau zwei Dinge: +Das Hinzufügen eines Channels zum Markdown-QA-System erfordert genau zwei Dinge: -1. Einen Transport-Adapter für den Kanal. -2. Ein Szenario-Paket, das den Kanalvertrag testet. +1. Einen Transport-Adapter für den Channel. +2. Ein Szenariopaket, das den Channel-Vertrag testet. -Füge keinen neuen Root-Befehl der obersten Ebene für QA hinzu, wenn der gemeinsame `qa-lab`-Host den Ablauf übernehmen kann. +Füge keinen neuen QA-Befehlsstamm auf oberster Ebene hinzu, wenn der gemeinsame `qa-lab`-Host +den Ablauf besitzen kann. -`qa-lab` ist für die gemeinsamen Host-Mechaniken zuständig: +`qa-lab` besitzt die gemeinsamen Host-Mechaniken: -- den Root-Befehl `openclaw qa` +- den `openclaw qa`-Befehlsstamm - Start und Beenden der Suite - Worker-Konkurrenz -- Schreiben von Artefakten +- Schreiben von Artifacts - Berichtserstellung - Szenarioausführung -- Kompatibilitäts-Aliasse für ältere `qa-channel`-Szenarien +- Kompatibilitätsaliasse für ältere `qa-channel`-Szenarien -Runner-Plugins sind für den Transportvertrag zuständig: +Runner-Plugins besitzen den Transportvertrag: -- wie `openclaw qa ` unter dem gemeinsamen Root `qa` eingehängt wird +- wie `openclaw qa ` unter dem gemeinsamen `qa`-Stamm eingehängt wird - wie das Gateway für diesen Transport konfiguriert wird -- wie die Bereitschaft geprüft wird +- wie Bereitschaft geprüft wird - wie eingehende Ereignisse injiziert werden - wie ausgehende Nachrichten beobachtet werden - wie Transkripte und normalisierter Transportzustand bereitgestellt werden - wie transportgestützte Aktionen ausgeführt werden - wie transport-spezifisches Zurücksetzen oder Aufräumen behandelt wird -Die Mindestanforderung für die Übernahme eines neuen Kanals ist: +Die minimale Voraussetzung für die Einführung eines neuen Channels ist: -1. Behalte `qa-lab` als Besitzer des gemeinsamen Roots `qa`. -2. Implementiere den Transport-Runner auf der gemeinsamen Host-Seam von `qa-lab`. -3. Behalte transport-spezifische Mechaniken im Runner-Plugin oder Kanal-Harness. -4. Hänge den Runner als `openclaw qa ` ein, statt einen konkurrierenden Root-Befehl zu registrieren. - Runner-Plugins sollten `qaRunners` in `openclaw.plugin.json` deklarieren und ein passendes Array `qaRunnerCliRegistrations` aus `runtime-api.ts` exportieren. - Halte `runtime-api.ts` schlank; Lazy-CLI- und Runner-Ausführung sollten hinter separaten Entry-Points bleiben. -5. Erstelle oder passe Markdown-Szenarien unter `qa/scenarios/` an. -6. Verwende die generischen Szenario-Hilfsfunktionen für neue Szenarien. -7. Sorge dafür, dass bestehende Kompatibilitäts-Aliasse weiter funktionieren, außer das Repo führt bewusst eine Migration durch. +1. `qa-lab` als Besitzer des gemeinsamen `qa`-Stamms beibehalten. +2. Den Transport-Runner auf der gemeinsamen `qa-lab`-Host-Seam implementieren. +3. Transport-spezifische Mechaniken im Runner-Plugin oder Channel-Harness belassen. +4. Den Runner als `openclaw qa ` einhängen, statt einen konkurrierenden Root-Befehl zu registrieren. + Runner-Plugins sollten `qaRunners` in `openclaw.plugin.json` deklarieren und ein passendes `qaRunnerCliRegistrations`-Array aus `runtime-api.ts` exportieren. + Halte `runtime-api.ts` schlank; lazy CLI- und Runner-Ausführung sollten hinter separaten Entrypoints bleiben. +5. Markdown-Szenarien unter `qa/scenarios/` verfassen oder anpassen. +6. Die generischen Szenario-Helfer für neue Szenarien verwenden. +7. Bestehende Kompatibilitätsaliasse funktionsfähig halten, außer das Repo führt bewusst eine Migration durch. Die Entscheidungsregel ist strikt: -- Wenn Verhalten einmalig in `qa-lab` ausgedrückt werden kann, platziere es in `qa-lab`. -- Wenn Verhalten von einem Kanaltransport abhängt, behalte es in diesem Runner-Plugin oder Plugin-Harness. -- Wenn ein Szenario eine neue Fähigkeit benötigt, die mehr als ein Kanal verwenden kann, füge eine generische Hilfsfunktion hinzu, statt einen kanal-spezifischen Branch in `suite.ts`. +- Wenn Verhalten einmalig in `qa-lab` ausgedrückt werden kann, gehört es in `qa-lab`. +- Wenn Verhalten von einem Channel-Transport abhängt, bleibt es in diesem Runner-Plugin oder Plugin-Harness. +- Wenn ein Szenario eine neue Fähigkeit benötigt, die mehr als ein Channel nutzen kann, füge einen generischen Helfer hinzu statt eines Channel-spezifischen Zweigs in `suite.ts`. - Wenn ein Verhalten nur für einen Transport sinnvoll ist, halte das Szenario transport-spezifisch und mache das im Szenariovertrag explizit. -Bevorzugte Namen generischer Hilfsfunktionen für neue Szenarien sind: +Bevorzugte generische Helfernamen für neue Szenarien sind: - `waitForTransportReady` - `waitForChannelReady` @@ -229,7 +229,7 @@ Bevorzugte Namen generischer Hilfsfunktionen für neue Szenarien sind: - `formatTransportTranscript` - `resetTransport` -Kompatibilitäts-Aliasse bleiben für bestehende Szenarien verfügbar, darunter: +Kompatibilitätsaliasse bleiben für bestehende Szenarien verfügbar, darunter: - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -237,80 +237,81 @@ Kompatibilitäts-Aliasse bleiben für bestehende Szenarien verfügbar, darunter: - `formatConversationTranscript` - `resetBus` -Neue Kanal-Arbeit sollte die generischen Namen der Hilfsfunktionen verwenden. -Kompatibilitäts-Aliasse existieren, um eine Migration mit Stichtag zu vermeiden, nicht als Modell für das Verfassen neuer Szenarien. +Neue Channel-Arbeit sollte die generischen Helfernamen verwenden. +Kompatibilitätsaliasse existieren, um eine Migration an einem Stichtag zu vermeiden, nicht als Modell für +neue Szenarioerstellung. -## Test-Suites (was wo ausgeführt wird) +## Test-Suites (was wo läuft) -Stelle dir die Suites als „zunehmenden Realismus“ vor (und zunehmende Flakiness/Kosten): +Stelle dir die Suites als „zunehmenden Realismus“ vor (und zunehmende Instabilität/Kosten): ### Unit / Integration (Standard) - Befehl: `pnpm test` -- Konfiguration: zehn sequentielle Shard-Läufe (`vitest.full-*.config.ts`) über die bestehenden bereichsspezifischen Vitest-Projekte -- Dateien: Core-/Unit-Inventare unter `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` und die per Allowlist freigegebenen `ui`-Node-Tests, die von `vitest.unit.config.ts` abgedeckt werden +- Konfiguration: zehn sequenzielle Shard-Läufe (`vitest.full-*.config.ts`) über die bestehenden abgegrenzten Vitest-Projekte +- Dateien: Core-/Unit-Inventare unter `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` sowie die per Whitelist freigegebenen `ui`-Node-Tests, die von `vitest.unit.config.ts` abgedeckt werden - Umfang: - Reine Unit-Tests - - In-Process-Integrationstests (Gateway-Authentifizierung, Routing, Tooling, Parsing, Konfiguration) - - Deterministische Regressionstests für bekannte Fehler + - In-Process-Integrationstests (Gateway-Auth, Routing, Tooling, Parsing, Konfiguration) + - Deterministische Regressionen für bekannte Fehler - Erwartungen: - Läuft in CI - Keine echten Schlüssel erforderlich - Sollte schnell und stabil sein - Hinweis zu Projekten: - - Nicht gezieltes `pnpm test` führt jetzt elf kleinere Shard-Konfigurationen aus (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) statt eines riesigen nativen Root-Projekt-Prozesses. Das reduziert die Spitzen-RSS auf ausgelasteten Maschinen und verhindert, dass `auto-reply`-/Erweiterungs-Arbeit nicht zusammenhängende Suites ausbremst. - - `pnpm test --watch` verwendet weiterhin den nativen Root-`vitest.config.ts`-Projektgraphen, weil eine Watch-Schleife mit mehreren Shards nicht praktikabel ist. - - `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnis-Targets jetzt zuerst durch bereichsspezifische Lanes, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nicht den gesamten Startaufwand des Root-Projekts zahlen muss. - - `pnpm test:changed` erweitert geänderte Git-Pfade zu denselben bereichsspezifischen Lanes, wenn der Diff nur routbare Quell-/Testdateien berührt; Konfigurations-/Setup-Änderungen fallen weiterhin auf den breiten erneuten Lauf des Root-Projekts zurück. - - Import-leichte Unit-Tests aus Agents, Commands, Plugins, `auto-reply`-Hilfsfunktionen, `plugin-sdk` und ähnlichen rein utilitären Bereichen werden über die `unit-fast`-Lane geleitet, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/runtime-schwere Dateien bleiben auf den bestehenden Lanes. - - Ausgewählte `plugin-sdk`- und `commands`-Hilfsquellendateien ordnen Changed-Mode-Läufe ebenfalls expliziten benachbarten Tests in diesen leichten Lanes zu, sodass Hilfsänderungen nicht die vollständige schwere Suite für dieses Verzeichnis erneut ausführen. - - `auto-reply` hat jetzt drei dedizierte Buckets: Core-Hilfsfunktionen auf oberster Ebene, `reply.*`-Integrationstests auf oberster Ebene und den Teilbaum `src/auto-reply/reply/**`. So bleibt die schwerste Reply-Harness-Arbeit von den günstigen Status-/Chunk-/Token-Tests getrennt. + - Nicht gezieltes `pnpm test` führt jetzt elf kleinere Shard-Konfigurationen aus (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) statt eines einzigen großen nativen Root-Projekt-Prozesses. Das senkt den Spitzen-RSS auf ausgelasteten Maschinen und verhindert, dass Auto-Reply-/Erweiterungsarbeit andere Suites ausbremst. + - `pnpm test --watch` verwendet weiterhin den nativen Root-`vitest.config.ts`-Projektgraphen, weil eine Multi-Shard-Watch-Schleife nicht praktikabel ist. + - `pnpm test`, `pnpm test:watch` und `pnpm test:perf:imports` leiten explizite Datei-/Verzeichnisziele jetzt zuerst durch abgegrenzte Strecken, sodass `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` nicht den Startaufwand des vollständigen Root-Projekts zahlen muss. + - `pnpm test:changed` erweitert geänderte Git-Pfade in dieselben abgegrenzten Strecken, wenn der Diff nur routbare Source-/Test-Dateien berührt; Konfigurations-/Setup-Änderungen fallen weiterhin auf den breiten erneuten Root-Projekt-Lauf zurück. + - Import-leichte Unit-Tests aus Agents, Commands, Plugins, Auto-Reply-Helfern, `plugin-sdk` und ähnlichen reinen Utility-Bereichen laufen über die `unit-fast`-Strecke, die `test/setup-openclaw-runtime.ts` überspringt; zustandsbehaftete/laufzeitintensive Dateien bleiben auf den bestehenden Strecken. + - Ausgewählte `plugin-sdk`- und `commands`-Helper-Quelldateien ordnen Läufe im Changed-Modus ebenfalls expliziten benachbarten Tests in diesen leichten Strecken zu, sodass Helper-Änderungen kein erneutes Ausführen der vollständigen schweren Suite für dieses Verzeichnis auslösen. + - `auto-reply` hat jetzt drei dedizierte Buckets: Core-Helper auf oberster Ebene, `reply.*`-Integrationstests auf oberster Ebene und den Teilbaum `src/auto-reply/reply/**`. Dadurch bleibt die schwerste Reply-Harness-Arbeit von den günstigen Status-/Chunk-/Token-Tests getrennt. - Hinweis zum eingebetteten Runner: - - Wenn du Discovery-Eingaben für Message-Tools oder den Laufzeitkontext von Compaction änderst, - behalte beide Ebenen der Abdeckung bei. - - Füge fokussierte Hilfs-Regressionstests für reine Routing-/Normalisierungsgrenzen hinzu. - - Halte außerdem die eingebetteten Runner-Integrations-Suites gesund: + - Wenn du Eingaben für die Discovery von Message-Tools oder den Laufzeitkontext von Compaction änderst, + halte beide Abdeckungsebenen intakt. + - Füge fokussierte Helper-Regressionen für reine Routing-/Normalisierungsgrenzen hinzu. + - Halte außerdem die Integrations-Suites des eingebetteten Runners gesund: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` und `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Diese Suites prüfen, dass bereichsspezifische IDs und Compaction-Verhalten weiterhin - durch die echten Pfade `run.ts` / `compact.ts` fließen; reine Hilfstests sind kein + - Diese Suites verifizieren, dass abgegrenzte IDs und Compaction-Verhalten weiterhin + durch die echten Pfade `run.ts` / `compact.ts` fließen; reine Helper-Tests sind kein ausreichender Ersatz für diese Integrationspfade. - Hinweis zum Pool: - Die Basis-Vitest-Konfiguration verwendet jetzt standardmäßig `threads`. - - Die gemeinsame Vitest-Konfiguration setzt außerdem `isolate: false` fest und verwendet den nicht isolierten Runner für die Root-Projekte, E2E- und Live-Konfigurationen. - - Die Root-UI-Lane behält ihr `jsdom`-Setup und ihren Optimizer, läuft jetzt aber ebenfalls auf dem gemeinsamen nicht isolierten Runner. - - Jeder `pnpm test`-Shard erbt dieselben Standardwerte `threads` + `isolate: false` aus der gemeinsamen Vitest-Konfiguration. - - Der gemeinsame Launcher `scripts/run-vitest.mjs` fügt jetzt standardmäßig auch `--no-maglev` für Vitest-Child-Node-Prozesse hinzu, um V8-Kompilierungs-Churn bei großen lokalen Läufen zu reduzieren. Setze `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, wenn du mit dem Standardverhalten von V8 vergleichen musst. + - Die gemeinsame Vitest-Konfiguration setzt außerdem `isolate: false` fest und verwendet den nicht isolierten Runner über die Root-Projekte, E2E- und Live-Konfigurationen hinweg. + - Die Root-UI-Strecke behält ihr `jsdom`-Setup und ihren Optimizer bei, läuft jetzt aber ebenfalls auf dem gemeinsamen nicht isolierten Runner. + - Jeder `pnpm test`-Shard übernimmt dieselben Standards `threads` + `isolate: false` aus der gemeinsamen Vitest-Konfiguration. + - Der gemeinsame Launcher `scripts/run-vitest.mjs` fügt für Vitest-Child-Node-Prozesse jetzt standardmäßig ebenfalls `--no-maglev` hinzu, um den V8-Kompilierungs-Overhead bei großen lokalen Läufen zu reduzieren. Setze `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, wenn du mit dem Standardverhalten von V8 vergleichen musst. - Hinweis zur schnellen lokalen Iteration: - - `pnpm test:changed` wird über bereichsspezifische Lanes geroutet, wenn die geänderten Pfade sauber einer kleineren Suite zugeordnet werden können. + - `pnpm test:changed` leitet durch abgegrenzte Strecken, wenn die geänderten Pfade eindeutig einer kleineren Suite zugeordnet werden können. - `pnpm test:max` und `pnpm test:changed:max` behalten dasselbe Routing-Verhalten bei, nur mit einer höheren Worker-Obergrenze. - - Die automatische lokale Worker-Skalierung ist jetzt absichtlich konservativ und fährt ebenfalls zurück, wenn die Lastdurchschnittswerte des Hosts bereits hoch sind, sodass mehrere gleichzeitige Vitest-Läufe standardmäßig weniger Schaden anrichten. - - Die Basis-Vitest-Konfiguration markiert die Projekte-/Konfigurationsdateien als `forceRerunTriggers`, damit erneute Läufe im Changed-Modus korrekt bleiben, wenn sich die Test-Verdrahtung ändert. - - Die Konfiguration lässt `OPENCLAW_VITEST_FS_MODULE_CACHE` auf unterstützten Hosts aktiviert; setze `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, wenn du einen expliziten Cache-Speicherort für direktes Profiling möchtest. + - Die automatische lokale Worker-Skalierung ist jetzt absichtlich konservativ und fährt ebenfalls zurück, wenn die Host-Load-Average bereits hoch ist, sodass mehrere gleichzeitige Vitest-Läufe standardmäßig weniger Schaden anrichten. + - Die Basis-Vitest-Konfiguration markiert die Projekte/Konfigurationsdateien als `forceRerunTriggers`, damit erneute Läufe im Changed-Modus korrekt bleiben, wenn sich das Test-Wiring ändert. + - Die Konfiguration lässt `OPENCLAW_VITEST_FS_MODULE_CACHE` auf unterstützten Hosts aktiviert; setze `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, wenn du einen expliziten Cache-Ort für direktes Profiling möchtest. - Hinweis zum Performance-Debugging: - - `pnpm test:perf:imports` aktiviert die Berichterstattung zur Vitest-Importdauer sowie die Ausgabe der Import-Aufschlüsselung. - - `pnpm test:perf:imports:changed` beschränkt dieselbe Profiling-Ansicht auf Dateien, die sich seit `origin/main` geändert haben. -- `pnpm test:perf:changed:bench -- --ref ` vergleicht geroutetes `test:changed` mit dem nativen Root-Projekt-Pfad für diesen festgeschriebenen Diff und gibt Wall Time sowie das macOS-Maximum der RSS aus. -- `pnpm test:perf:changed:bench -- --worktree` benchmarkt den aktuellen Dirty Tree, indem die Liste geänderter Dateien durch `scripts/test-projects.mjs` und die Root-Vitest-Konfiguration geleitet wird. - - `pnpm test:perf:profile:main` schreibt ein CPU-Profil des Main-Threads für den Start von Vitest/Vite und den Transformations-Overhead. - - `pnpm test:perf:profile:runner` schreibt CPU-+Heap-Profile des Runners für die Unit-Suite bei deaktivierter Datei-Parallelität. + - `pnpm test:perf:imports` aktiviert die Vitest-Berichterstattung zur Importdauer sowie die Ausgabe der Importaufschlüsselung. + - `pnpm test:perf:imports:changed` grenzt dieselbe Profiling-Ansicht auf Dateien ein, die sich seit `origin/main` geändert haben. +- `pnpm test:perf:changed:bench -- --ref ` vergleicht das geroutete `test:changed` mit dem nativen Root-Projekt-Pfad für diesen festgeschriebenen Diff und gibt Laufzeit sowie den maximalen RSS unter macOS aus. +- `pnpm test:perf:changed:bench -- --worktree` benchmarkt den aktuellen Dirty-Tree, indem die Liste geänderter Dateien durch `scripts/test-projects.mjs` und die Root-Vitest-Konfiguration geroutet wird. + - `pnpm test:perf:profile:main` schreibt ein CPU-Profil des Main-Threads für den Vitest-/Vite-Start und den Transform-Overhead. + - `pnpm test:perf:profile:runner` schreibt CPU- und Heap-Profile des Runners für die Unit-Suite bei deaktivierter Dateiparallelität. ### E2E (Gateway-Smoke) - Befehl: `pnpm test:e2e` - Konfiguration: `vitest.e2e.config.ts` - Dateien: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` -- Laufzeit-Standards: - - Verwendet Vitest-`threads` mit `isolate: false`, passend zum Rest des Repos. +- Laufzeitstandards: + - Verwendet Vitest-`threads` mit `isolate: false` und entspricht damit dem Rest des Repos. - Verwendet adaptive Worker (CI: bis zu 2, lokal: standardmäßig 1). - - Läuft standardmäßig im stillen Modus, um den Overhead durch Konsolen-I/O zu reduzieren. -- Nützliche Overrides: + - Läuft standardmäßig im Silent-Modus, um den Konsolen-I/O-Overhead zu reduzieren. +- Nützliche Überschreibungen: - `OPENCLAW_E2E_WORKERS=`, um die Anzahl der Worker zu erzwingen (begrenzt auf 16). - - `OPENCLAW_E2E_VERBOSE=1`, um die ausführliche Konsolenausgabe wieder zu aktivieren. + - `OPENCLAW_E2E_VERBOSE=1`, um ausführliche Konsolenausgabe wieder zu aktivieren. - Umfang: - End-to-End-Verhalten von Multi-Instance-Gateways - - WebSocket-/HTTP-Oberflächen, Node-Pairing und umfangreicheres Networking + - WebSocket-/HTTP-Oberflächen, Node-Pairing und schwergewichtigere Netzwerkarbeit - Erwartungen: - Läuft in CI (wenn in der Pipeline aktiviert) - Keine echten Schlüssel erforderlich @@ -322,131 +323,131 @@ Stelle dir die Suites als „zunehmenden Realismus“ vor (und zunehmende Flakin - Datei: `test/openshell-sandbox.e2e.test.ts` - Umfang: - Startet über Docker ein isoliertes OpenShell-Gateway auf dem Host - - Erstellt eine Sandbox aus einer temporären lokalen Dockerfile + - Erstellt aus einem temporären lokalen Dockerfile eine Sandbox - Testet OpenClaws OpenShell-Backend über echtes `sandbox ssh-config` + SSH-Exec - - Verifiziert remote-kanonisches Dateisystemverhalten über die Sandbox-FS-Bridge + - Verifiziert kanonisches Remote-Dateisystemverhalten über die Sandbox-FS-Bridge - Erwartungen: - - Nur Opt-in; nicht Teil des standardmäßigen `pnpm test:e2e`-Laufs - - Erfordert eine lokale `openshell`-CLI sowie einen funktionierenden Docker-Daemon - - Verwendet isoliertes `HOME` / `XDG_CONFIG_HOME` und zerstört anschließend Test-Gateway und Sandbox -- Nützliche Overrides: + - Nur per Opt-in; nicht Teil des standardmäßigen `pnpm test:e2e`-Laufs + - Erfordert eine lokale `openshell`-CLI plus einen funktionierenden Docker-Daemon + - Verwendet isoliertes `HOME` / `XDG_CONFIG_HOME` und zerstört dann Test-Gateway und Sandbox +- Nützliche Überschreibungen: - `OPENCLAW_E2E_OPENSHELL=1`, um den Test zu aktivieren, wenn die breitere E2E-Suite manuell ausgeführt wird - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, um auf ein nicht standardmäßiges CLI-Binary oder Wrapper-Skript zu verweisen -### Live (reale Provider + reale Modelle) +### Live (echte Provider + echte Modelle) - Befehl: `pnpm test:live` - Konfiguration: `vitest.live.config.ts` - Dateien: `src/**/*.live.test.ts` -- Standard: **aktiviert** durch `pnpm test:live` (setzt `OPENCLAW_LIVE_TEST=1`) +- Standard: durch `pnpm test:live` **aktiviert** (setzt `OPENCLAW_LIVE_TEST=1`) - Umfang: - „Funktioniert dieser Provider/dieses Modell _heute_ tatsächlich mit echten Anmeldedaten?“ - - Erkennt Änderungen an Provider-Formaten, Eigenheiten bei Tool-Calling, Authentifizierungsprobleme und Rate-Limit-Verhalten + - Erkennt Änderungen an Provider-Formaten, Tool-Calling-Eigenheiten, Auth-Probleme und Rate-Limit-Verhalten - Erwartungen: - - Von Haus aus nicht CI-stabil (reale Netzwerke, reale Provider-Richtlinien, Quoten, Ausfälle) + - Absichtlich nicht CI-stabil (echte Netzwerke, echte Provider-Richtlinien, Quoten, Ausfälle) - Kostet Geld / verbraucht Rate Limits - - Bevorzuge eingegrenzte Teilmengen statt „alles“ -- Live-Läufe sourcen `~/.profile`, um fehlende API-Schlüssel aufzunehmen. -- Standardmäßig isolieren Live-Läufe weiterhin `HOME` und kopieren Konfigurations-/Auth-Material in ein temporäres Test-Home, damit Unit-Fixtures dein echtes `~/.openclaw` nicht verändern können. -- Setze `OPENCLAW_LIVE_USE_REAL_HOME=1` nur, wenn Live-Tests bewusst dein echtes Home-Verzeichnis verwenden sollen. -- `pnpm test:live` verwendet jetzt standardmäßig einen ruhigeren Modus: `[live] ...`-Fortschrittsausgaben bleiben sichtbar, aber der zusätzliche Hinweis zu `~/.profile` wird unterdrückt und Gateway-Bootstrap-Logs/Bonjour-Chatter werden stummgeschaltet. Setze `OPENCLAW_LIVE_TEST_QUIET=0`, wenn du die vollständigen Start-Logs wiederhaben möchtest. -- Rotation von API-Schlüsseln (providerspezifisch): setze `*_API_KEYS` im Komma-/Semikolon-Format oder `*_API_KEY_1`, `*_API_KEY_2` (zum Beispiel `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) oder pro Live-Override über `OPENCLAW_LIVE_*_KEY`; Tests versuchen bei Rate-Limit-Antworten einen erneuten Lauf. + - Statt „alles“ möglichst eingegrenzte Teilmengen ausführen +- Live-Läufe sourcen `~/.profile`, um fehlende API-Schlüssel zu übernehmen. +- Standardmäßig isolieren Live-Läufe `HOME` weiterhin und kopieren Konfigurations-/Auth-Material in ein temporäres Test-Home, damit Unit-Fixtures dein echtes `~/.openclaw` nicht verändern können. +- Setze `OPENCLAW_LIVE_USE_REAL_HOME=1` nur dann, wenn Live-Tests absichtlich dein echtes Home-Verzeichnis verwenden sollen. +- `pnpm test:live` verwendet jetzt standardmäßig einen ruhigeren Modus: `[live] ...`-Fortschrittsausgabe bleibt erhalten, aber der zusätzliche Hinweis zu `~/.profile` wird unterdrückt und Gateway-Bootstrap-Logs/Bonjour-Chatter werden stummgeschaltet. Setze `OPENCLAW_LIVE_TEST_QUIET=0`, wenn du wieder die vollständigen Start-Logs sehen möchtest. +- API-Schlüsselrotation (provider-spezifisch): setze `*_API_KEYS` im Komma-/Semikolonformat oder `*_API_KEY_1`, `*_API_KEY_2` (zum Beispiel `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) oder pro Live-Überschreibung `OPENCLAW_LIVE_*_KEY`; Tests versuchen bei Rate-Limit-Antworten erneut. - Fortschritts-/Heartbeat-Ausgabe: - - Live-Suites geben jetzt Fortschrittszeilen auf stderr aus, sodass bei langen Provider-Aufrufen sichtbar bleibt, dass Aktivität stattfindet, selbst wenn die Konsolenerfassung von Vitest ruhig ist. - - `vitest.live.config.ts` deaktiviert das Abfangen der Konsole durch Vitest, sodass Fortschrittszeilen von Provider/Gateway während Live-Läufen sofort gestreamt werden. - - Passe direkte Modell-Heartbeats mit `OPENCLAW_LIVE_HEARTBEAT_MS` an. - - Passe Gateway-/Probe-Heartbeats mit `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` an. + - Live-Suites geben jetzt Fortschrittszeilen auf stderr aus, sodass lange Provider-Aufrufe sichtbar aktiv bleiben, auch wenn die Vitest-Konsolenerfassung ruhig ist. + - `vitest.live.config.ts` deaktiviert die Vitest-Konsolenabfangung, sodass Provider-/Gateway-Fortschrittszeilen bei Live-Läufen sofort gestreamt werden. + - Passe Heartbeats für direkte Modelle mit `OPENCLAW_LIVE_HEARTBEAT_MS` an. + - Passe Heartbeats für Gateway/Probes mit `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS` an. ## Welche Suite sollte ich ausführen? Verwende diese Entscheidungstabelle: - Logik/Tests bearbeiten: `pnpm test` ausführen (und `pnpm test:coverage`, wenn du viel geändert hast) -- Gateway-Networking / WS-Protokoll / Pairing berühren: zusätzlich `pnpm test:e2e` ausführen -- „Mein Bot ist down“ / providerspezifische Fehler / Tool-Calling debuggen: eingegrenztes `pnpm test:live` ausführen +- Gateway-Networking / WS-Protokoll / Pairing anfassen: `pnpm test:e2e` ergänzen +- „Mein Bot ist down“ / provider-spezifische Fehler / Tool-Calling debuggen: ein eingegrenztes `pnpm test:live` ausführen -## Live: Android-Node-Fähigkeiten-Sweep +## Live: Android-Node-Capability-Sweep - Test: `src/gateway/android-node.capabilities.live.test.ts` - Skript: `pnpm android:test:integration` -- Ziel: **jeden aktuell beworbenen Befehl** eines verbundenen Android-Node aufrufen und das Vertragsverhalten des Befehls prüfen. +- Ziel: **jeden aktuell beworbenen Befehl** eines verbundenen Android-Nodes aufrufen und das Befehlsvertragsverhalten prüfen. - Umfang: - - Vorgegebene/manuelle Einrichtung (die Suite installiert/startet/paired die App nicht). - - Gateway-`node.invoke`-Validierung Befehl für Befehl für den ausgewählten Android-Node. -- Erforderliche Voreinrichtung: - - Android-App ist bereits verbunden und mit dem Gateway gepairt. - - App bleibt im Vordergrund. - - Berechtigungen/Aufnahmezustimmung wurden für die Fähigkeiten erteilt, bei denen du Erfolg erwartest. -- Optionale Ziel-Overrides: + - Vorgegebene/manuelle Vorbereitung (die Suite installiert/startet/pairt die App nicht). + - Befehlsweise `node.invoke`-Validierung des Gateways für den ausgewählten Android-Node. +- Erforderliche Vorbereitung: + - Android-App bereits verbunden und mit dem Gateway gepairt. + - App im Vordergrund halten. + - Berechtigungen/Capture-Zustimmung für Capabilities erteilt, von denen du erwartest, dass sie bestehen. +- 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-Setup-Details: [Android-App](/de/platforms/android) -## Live: Modell-Smoke (Profilschlüssel) +## Live: Modell-Smoke (Profile-Keys) Live-Tests sind in zwei Ebenen aufgeteilt, damit wir Fehler isolieren können: -- „Direktes Modell“ zeigt uns, dass der Provider/das Modell mit dem angegebenen Schlüssel überhaupt antworten kann. -- „Gateway-Smoke“ zeigt uns, dass die vollständige Gateway-+Agent-Pipeline für dieses Modell funktioniert (Sitzungen, Verlauf, Tools, Sandbox-Richtlinie usw.). +- „Direktes Modell“ sagt uns, ob der Provider/das Modell mit dem angegebenen Schlüssel überhaupt antworten kann. +- „Gateway-Smoke“ sagt uns, ob die vollständige Gateway+Agent-Pipeline für dieses Modell funktioniert (Sitzungen, Verlauf, Tools, Sandbox-Policy usw.). ### Ebene 1: Direkte Modell-Completion (ohne Gateway) - Test: `src/agents/models.profiles.live.test.ts` - Ziel: - - Erkannte Modelle aufzählen + - Erkannte Modelle auflisten - `getApiKeyForModel` verwenden, um Modelle auszuwählen, für die du Anmeldedaten hast - - Pro Modell eine kleine Completion ausführen (und gezielte Regressionstests, wo nötig) + - Pro Modell eine kleine Completion ausführen (und gezielte Regressionen, wo nötig) - Aktivierung: - `pnpm test:live` (oder `OPENCLAW_LIVE_TEST=1`, wenn Vitest direkt aufgerufen wird) -- Setze `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 fokussiert bleibt +- Setze `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.x + 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.4,anthropic/claude-opus-4-6,..."` (Komma-Allowlist) - - Moderne/All-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setze `OPENCLAW_LIVE_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. + - Moderne/alle Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setze `OPENCLAW_LIVE_MAX_MODELS=0` für einen vollständigen modernen Sweep oder einen positiven Wert für eine kleinere Obergrenze. - Providerauswahl: - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (Komma-Allowlist) - Woher die Schlüssel kommen: - - Standardmäßig: Profilspeicher und env-Fallbacks - - Setze `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um **nur** den Profilspeicher zu erzwingen -- Warum das existiert: - - Trennt „Provider-API ist kaputt / Schlüssel ist ungültig“ von „Gateway-Agent-Pipeline ist kaputt“ - - Enthält kleine, isolierte Regressionstests (Beispiel: OpenAI-Responses/Codex-Responses-Reasoning-Replay + Tool-Call-Flows) + - Standardmäßig: Profile-Store und env-Fallbacks + - Setze `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um **nur den Profile-Store** zu erzwingen +- Warum es das gibt: + - Trennt „Provider-API ist defekt / Schlüssel ist ungültig“ von „Gateway-Agent-Pipeline ist defekt“ + - Enthält kleine, isolierte Regressionen (Beispiel: OpenAI-Responses/Codex-Responses-Reasoning-Replay- und Tool-Call-Flows) -### Ebene 2: Gateway + Dev-Agent-Smoke (was „@openclaw“ tatsächlich macht) +### Ebene 2: Gateway + Dev-Agent-Smoke (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-Override pro Lauf) - Modelle mit Schlüsseln durchlaufen und Folgendes prüfen: - - „aussagekräftige“ Antwort (ohne Tools) - - eine echte Tool-Invocation funktioniert (Read-Probe) - - optionale zusätzliche Tool-Probes (Exec+Read-Probe) + - „sinnvolle“ Antwort (ohne 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 du Fehler schnell erklären kannst): - - `read`-Probe: Der Test schreibt eine Nonce-Datei in den Workspace 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 dann mit `read` wieder zu lesen. - - Image-Probe: Der Test hängt ein erzeugtes PNG an (Katze + zufälliger Code) und erwartet, dass das Modell `cat ` zurückgibt. + - `read`-Probe: Der Test schreibt eine Nonce-Datei in den Workspace und fordert den Agenten auf, sie zu `read`en 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` wieder auszulesen. + - Image-Probe: Der Test hängt ein generiertes PNG an (Katze + zufälliger Code) und erwartet, dass das Modell `cat ` 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.x + 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 `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (oder Komma-Liste) setzen, um einzugrenzen - - Moderne/All-Gateway-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setze `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` für einen vollständigen modernen Sweep oder eine positive Zahl für eine kleinere Obergrenze. -- Providerauswahl (vermeide „alles über OpenRouter“): + - Oder `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` setzen (oder Komma-Liste), um einzugrenzen + - Moderne/alle Gateway-Sweeps verwenden standardmäßig eine kuratierte Obergrenze mit hohem Signal; setze `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` für einen vollständigen modernen Sweep oder einen positiven Wert für eine kleinere Obergrenze. +- Providerauswahl (vermeide „alles von OpenRouter“): - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (Komma-Allowlist) - Tool- + Image-Probes sind in diesem Live-Test immer aktiviert: - `read`-Probe + `exec+read`-Probe (Tool-Stresstest) - - Image-Probe läuft, wenn das Modell Unterstützung für Bildeingaben bewirbt - - Ablauf (allgemein): + - Die Image-Probe läuft, wenn das Modell Unterstützung für Bildeingaben bewirbt + - Ablauf (grobe Übersicht): - Der Test erzeugt ein kleines PNG mit „CAT“ + zufälligem Code (`src/gateway/live-image-probe.ts`) - Sendet es über `agent` mit `attachments: [{ mimeType: "image/png", content: "" }]` - - Das Gateway parst Anhänge in `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) + - Das Gateway parst Attachments in `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`) - Der eingebettete Agent leitet eine multimodale Benutzernachricht an das Modell weiter - - Prüfung: Die Antwort enthält `cat` + den Code (OCR-Toleranz: kleinere Fehler sind erlaubt) + - Prüfung: Die Antwort enthält `cat` + den Code (OCR-Toleranz: kleine Fehler sind erlaubt) Tipp: Um zu sehen, was du auf deiner Maschine testen kannst (und die genauen `provider/model`-IDs), führe Folgendes aus: @@ -458,23 +459,23 @@ 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 deine Standardkonfiguration anzufassen. -- Backend-spezifische Smoke-Standards liegen in der Definition `cli-backend.ts` der besitzenden Erweiterung. +- Ziel: die Gateway- + Agent-Pipeline mit einem lokalen CLI-Backend validieren, ohne deine Standardkonfiguration anzufassen. +- Backend-spezifische Smoke-Standards liegen in der Definition `cli-backend.ts` der jeweiligen besitzenden Erweiterung. - 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` - - Verhalten von Command/Args/Image kommt aus den Metadaten des besitzenden CLI-Backend-Plugins. -- Overrides (optional): + - Verhalten für Command/Args/Image kommt aus den Metadaten des jeweiligen CLI-Backend-Plugins. +- Überschreibungen (optional): - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"` - `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 injiziert). - - `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_IMAGE_PROBE=1`, um ein echtes Bild-Attachment zu senden (Pfade werden in den Prompt injiziert). + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, um Bilddateipfade als CLI-Args statt per Prompt-Injektion zu übergeben. + - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (oder `"list"`), um zu steuern, wie Bild-Args übergeben werden, wenn `IMAGE_ARG` gesetzt ist. - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, um einen zweiten Turn zu senden und den Resume-Flow zu validieren. - - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, um die standardmäßige Kontinuitätsprobe Claude Sonnet -> Opus in derselben Sitzung zu deaktivieren (auf `1` setzen, um sie zu erzwingen, wenn das ausgewählte Modell ein Switch-Ziel unterstützt). + - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, um die standardmäßige Kontinuitätsprobe Claude Sonnet -> Opus in derselben Sitzung zu deaktivieren (auf `1` setzen, um sie zu erzwingen, wenn das ausgewählte Modell ein Umschaltziel unterstützt). Beispiel: @@ -502,37 +503,37 @@ pnpm test:docker:live-cli-backend:gemini Hinweise: - Der Docker-Runner liegt unter `scripts/test-live-cli-backend-docker.sh`. -- Er führt den Live-CLI-Backend-Smoke innerhalb des Repo-Docker-Images als Nicht-Root-Benutzer `node` aus. -- Er löst CLI-Smoke-Metadaten aus der besitzenden Erweiterung 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 portables Claude-Code-Subscription-OAuth entweder über `~/.claude/.credentials.json` mit `claudeAiOauth.subscriptionType` oder `CLAUDE_CODE_OAUTH_TOKEN` aus `claude setup-token`. Zuerst wird direktes `claude -p` in Docker nachgewiesen, dann werden zwei Gateway-CLI-Backend-Turns ausgeführt, ohne Anthropic-API-Key-env-Variablen beizubehalten. Diese Subscription-Lane deaktiviert standardmäßig die Claude-MCP-/Tool- und Image-Probes, weil Claude die Nutzung durch Drittanbieter-Apps derzeit über Extra-Usage-Abrechnung statt über normale Grenzen des Subscription-Plans leitet. -- Der Live-CLI-Backend-Smoke testet jetzt denselben End-to-End-Flow für Claude, Codex und Gemini: Text-Turn, Bildklassifizierungs-Turn, dann MCP-`cron`-Tool-Call, verifiziert über die Gateway-CLI. -- Claudes standardmäßiger Smoke patcht außerdem die Sitzung von Sonnet auf Opus und prüft, dass sich die fortgesetzte Sitzung weiterhin eine frühere Notiz merkt. +- Er führt den Live-CLI-Backend-Smoke im Repo-Docker-Image als Nicht-Root-Benutzer `node` aus. +- Er löst CLI-Smoke-Metadaten aus der jeweiligen besitzenden Erweiterung auf und installiert dann das passende Linux-CLI-Paket (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`) in ein gecachtes beschreibbares Präfix unter `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (Standard: `~/.cache/openclaw/docker-cli-tools`). +- `pnpm test:docker:live-cli-backend:claude-subscription` erfordert portables Claude-Code-Subscription-OAuth entweder über `~/.claude/.credentials.json` mit `claudeAiOauth.subscriptionType` oder `CLAUDE_CODE_OAUTH_TOKEN` aus `claude setup-token`. Es prüft zuerst direktes `claude -p` in Docker und führt dann zwei Gateway-CLI-Backend-Turns aus, ohne Anhtropic-API-Key-env vars beizubehalten. Diese Subscription-Strecke deaktiviert standardmäßig die Claude-MCP-/Tool- und Image-Probes, weil Claude die Nutzung von Drittanbieter-Apps derzeit über Zusatznutzungsabrechnung statt über normale Limits des Subscription-Tarifs leitet. +- Der Live-CLI-Backend-Smoke testet jetzt denselben End-to-End-Ablauf für Claude, Codex und Gemini: Text-Turn, Bildklassifizierungs-Turn, dann MCP-Tool-Call `cron`, verifiziert über die Gateway-CLI. +- Der standardmäßige Claude-Smoke patcht die Sitzung außerdem von Sonnet auf Opus und verifiziert, dass die fortgesetzte Sitzung sich 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 Conversation-Bind-Flow von ACP mit einem Live-ACP-Agent validieren: +- Ziel: den echten ACP-Conversation-Bind-Flow mit einem Live-ACP-Agenten validieren: - `/acp spawn --bind here` senden - - eine synthetische Message-Channel-Konversation direkt vor Ort binden - - einen normalen Follow-up auf derselben Konversation senden - - prüfen, dass der Follow-up im Transkript der gebundenen ACP-Sitzung landet + - eine synthetische Message-Channel-Konversation an Ort und Stelle binden + - ein normales Follow-up in derselben Konversation senden + - verifizieren, dass das Follow-up im Transkript der gebundenen ACP-Sitzung landet - Aktivierung: - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts` - `OPENCLAW_LIVE_ACP_BIND=1` - Standards: - - ACP-Agents in Docker: `claude,codex,gemini` + - ACP-Agenten in Docker: `claude,codex,gemini` - ACP-Agent für direktes `pnpm test:live ...`: `claude` - - Synthetischer Kanal: Slack-DM-artiger Konversationskontext + - Synthetischer Channel: Konversationskontext im Stil einer Slack-DM - ACP-Backend: `acpx` -- Overrides: +- Ü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@'` - Hinweise: - - Diese Lane verwendet die Gateway-Oberfläche `chat.send` mit rein administrativen synthetischen Feldern für die Herkunftsroute, damit Tests Message-Channel-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 `acpx`-Plugins für den ausgewählten ACP-Harness-Agent. + - Diese Strecke verwendet die Gateway-Oberfläche `chat.send` mit Admin-only-Feldern für synthetische Ausgangsrouten, damit Tests Message-Channel-Kontext anhängen können, ohne vorzugeben, extern zuzustellen. + - Wenn `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` nicht gesetzt ist, verwendet der Test die eingebaute Agent-Registry des eingebetteten `acpx`-Plugins für den ausgewählten ACP-Harness-Agenten. Beispiel: @@ -548,7 +549,7 @@ Docker-Rezept: pnpm test:docker:live-acp-bind ``` -Docker-Rezepte für einzelne Agents: +Docker-Rezepte für einzelne Agenten: ```bash pnpm test:docker:live-acp-bind:claude @@ -559,20 +560,19 @@ pnpm test:docker:live-acp-bind:gemini Docker-Hinweise: - Der Docker-Runner liegt unter `scripts/test-live-acp-bind-docker.sh`. -- Standardmäßig führt er den ACP-Bind-Smoke nacheinander gegen alle unterstützten Live-CLI-Agents aus: `claude`, `codex`, dann `gemini`. +- Standardmäßig führt er den ACP-Bind-Smoke nacheinander gegen alle unterstützten Live-CLI-Agenten aus: `claude`, `codex`, dann `gemini`. - Verwende `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` oder `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, um die Matrix einzugrenzen. -- Er sourct `~/.profile`, staged das passende CLI-Auth-Material in den Container, installiert `acpx` in ein beschreibbares npm-Präfix und installiert dann bei Bedarf die angeforderte Live-CLI (`@anthropic-ai/claude-code`, `@openai/codex` oder `@google/gemini-cli`). -- Innerhalb von Docker setzt der Runner `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, damit `acpx` Provider-env-Variablen aus dem gesourcten Profil für die Child-Harness-CLI verfügbar hält. +- Er sourct `~/.profile`, stellt passendes CLI-Auth-Material 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`, damit acpx Provider-env vars aus dem gesourcten Profil für die untergeordnete Harness-CLI verfügbar hält. ## Live: Codex-App-Server-Harness-Smoke -- Ziel: das Plugin-eigene Codex-Harness über die normale Gateway- +- Ziel: die Plugin-eigene 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 `codex/gpt-5.4` senden - - einen zweiten Turn an dieselbe OpenClaw-Sitzung senden und prüfen, dass der App-Server- - Thread fortgesetzt werden kann + - einen zweiten Turn an dieselbe OpenClaw-Sitzung senden und verifizieren, dass der App-Server-Thread wiederaufgenommen werden kann - `/codex status` und `/codex models` über denselben Gateway-Command- Pfad ausführen - Test: `src/gateway/gateway-codex-harness.live.test.ts` @@ -580,9 +580,9 @@ Docker-Hinweise: - Standardmodell: `codex/gpt-5.4` - Optionale Image-Probe: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=1` - Optionale MCP-/Tool-Probe: `OPENCLAW_LIVE_CODEX_HARNESS_MCP_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: `OPENAI_API_KEY` aus der Shell/dem Profil sowie optional kopierte +- Der Smoke setzt `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, damit eine defekte Codex- + Harness nicht unbemerkt durch stillen Fallback auf PI bestehen kann. +- Auth: `OPENAI_API_KEY` aus Shell/Profil sowie optional kopierte Dateien `~/.codex/auth.json` und `~/.codex/config.toml` Lokales Rezept: @@ -606,19 +606,19 @@ pnpm test:docker:live-codex-harness Docker-Hinweise: - Der Docker-Runner liegt unter `scripts/test-live-codex-harness-docker.sh`. -- Er sourct das eingehängte `~/.profile`, übergibt `OPENAI_API_KEY`, kopiert Codex-CLI- - Auth-Dateien, wenn vorhanden, installiert `@openai/codex` in ein beschreibbares eingehängtes npm- - Präfix, staged den Quellbaum und führt dann nur den Live-Test des Codex-Harness aus. +- Er sourct das eingebundene `~/.profile`, übergibt `OPENAI_API_KEY`, kopiert Codex-CLI- + Auth-Dateien, sofern vorhanden, installiert `@openai/codex` in ein beschreibbares eingebundenes npm- + Präfix, stellt den Source-Tree bereit und führt dann nur den Live-Test der Codex-Harness aus. - Docker aktiviert standardmäßig die Image- und MCP-/Tool-Probes. Setze `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0` oder `OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0`, wenn du einen engeren Debug-Lauf brauchst. - Docker exportiert außerdem `OPENCLAW_AGENT_HARNESS_FALLBACK=none`, passend zur Live- - Testkonfiguration, sodass `openai-codex/*`- oder PI-Fallback einen Codex-Harness- - Regressionsfehler nicht verbergen kann. + Testkonfiguration, damit `openai-codex/*`- oder PI-Fallback eine Codex-Harness- + Regression nicht verbergen kann. ### Empfohlene Live-Rezepte -Enge, explizite Allowlists sind am schnellsten und am wenigsten flaky: +Enge, explizite Allowlists sind am schnellsten und am wenigsten instabil: - Einzelnes Modell, direkt (ohne Gateway): - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts` @@ -629,26 +629,26 @@ Enge, explizite Allowlists sind am schnellsten und am wenigsten flaky: - Tool-Calling über mehrere Provider hinweg: - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,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` -- Fokus auf Google (Gemini-API-Key + Antigravity): - - Gemini (API-Key): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" 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-Key). -- `google-antigravity/...` verwendet die Antigravity-OAuth-Bridge (Agent-Endpoint im Stil von Cloud Code Assist). -- `google-gemini-cli/...` verwendet die lokale Gemini-CLI auf deiner Maschine (separate Authentifizierung + Eigenheiten beim Tooling). +- `google/...` verwendet die Gemini-API (API-Schlüssel). +- `google-antigravity/...` verwendet die Antigravity-OAuth-Bridge (Agent-Endpunkt im Stil von Cloud Code Assist). +- `google-gemini-cli/...` verwendet die lokale Gemini-CLI auf deiner Maschine (separate Auth + eigene Tooling-Eigenheiten). - Gemini-API vs. Gemini-CLI: - - API: OpenClaw ruft Googles gehostete Gemini-API über HTTP auf (API-Key / Profil-Authentifizierung); das ist, was die meisten Benutzer mit „Gemini“ meinen. - - CLI: OpenClaw ruft ein lokales `gemini`-Binary über die Shell auf; es hat seine eigene Authentifizierung und kann sich anders verhalten (Streaming/Tool-Support/Versionsabweichungen). + - API: OpenClaw ruft Googles gehostete Gemini-API über HTTP auf (API-Schlüssel / Profile-Auth); das ist, was die meisten Benutzer mit „Gemini“ meinen. + - CLI: OpenClaw führt ein lokales `gemini`-Binary per Shell aus; es hat seine eigene Authentifizierung und kann sich anders verhalten (Streaming/Tool-Support/Versionsabweichungen). ## Live: Modellmatrix (was wir abdecken) -Es gibt keine feste „CI-Modellliste“ (Live ist Opt-in), aber dies sind die **empfohlenen** Modelle, die auf einer Entwickler-Maschine mit Schlüsseln regelmäßig abgedeckt werden sollten. +Es gibt keine feste „CI-Modellliste“ (Live ist Opt-in), aber dies sind die **empfohlenen** Modelle, die regelmäßig auf einer Entwickler-Maschine mit Schlüsseln abgedeckt werden sollten. -### Moderner Smoke-Satz (Tool-Calling + Bild) +### Modernes Smoke-Set (Tool-Calling + Image) -Das ist der Lauf mit den „gängigen Modellen“, den wir funktionsfähig halten wollen: +Das ist der Lauf für „gängige Modelle“, den wir funktionsfähig halten wollen: - OpenAI (nicht Codex): `openai/gpt-5.4` (optional: `openai/gpt-5.4-mini`) - OpenAI Codex: `openai-codex/gpt-5.4` @@ -658,12 +658,12 @@ Das ist der Lauf mit den „gängigen Modellen“, den wir funktionsfähig halte - Z.AI (GLM): `zai/glm-4.7` - MiniMax: `minimax/MiniMax-M2.7` -Gateway-Smoke mit Tools + Bild ausführen: +Gateway-Smoke mit Tools + Image ausführen: `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,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` -### Basislinie: Tool-Calling (Read + optional Exec) +### Baseline: Tool-Calling (Read + optional Exec) -Wähle mindestens eines pro Provider-Familie: +Wähle mindestens ein Modell pro Provider-Familie: - OpenAI: `openai/gpt-5.4` (oder `openai/gpt-5.4-mini`) - Anthropic: `anthropic/claude-opus-4-6` (oder `anthropic/claude-sonnet-4-6`) @@ -678,149 +678,149 @@ Optionale zusätzliche Abdeckung (nice to have): - Cerebras: `cerebras/`… (wenn du Zugriff hast) - LM Studio: `lmstudio/`… (lokal; Tool-Calling hängt vom API-Modus ab) -### Vision: Bild senden (Anhang → multimodale Nachricht) +### Vision: Bild senden (Attachment → multimodale Nachricht) -Nimm mindestens ein bildfähiges Modell in `OPENCLAW_LIVE_GATEWAY_MODELS` auf (Claude/Gemini/OpenAI-Bildvarianten usw.), um die Image-Probe zu testen. +Nimm mindestens ein bildfähiges Modell in `OPENCLAW_LIVE_GATEWAY_MODELS` auf (Claude-/Gemini-/OpenAI-Varianten mit Vision-Unterstützung usw.), um die Image-Probe zu testen. ### Aggregatoren / alternative Gateways -Wenn du aktivierte Schlüssel hast, unterstützen wir außerdem Tests über: +Wenn du aktivierte Schlüssel hast, unterstützen wir Tests auch über: -- OpenRouter: `openrouter/...` (Hunderte Modelle; verwende `openclaw models scan`, um Kandidaten mit Tool-+Bild-Fähigkeit zu finden) -- OpenCode: `opencode/...` für Zen und `opencode-go/...` für Go (Authentifizierung über `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) +- OpenRouter: `openrouter/...` (Hunderte von Modellen; verwende `openclaw models scan`, um Kandidaten mit Tool- und Image-Fähigkeiten zu finden) +- OpenCode: `opencode/...` für Zen und `opencode-go/...` für Go (Auth über `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`) -Weitere Provider, die du in die Live-Matrix aufnehmen kannst (wenn du Anmeldedaten/Konfiguration hast): +Weitere Provider, die du in die Live-Matrix aufnehmen kannst (falls du Anmeldedaten/Konfiguration hast): - 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 Endpoints): `minimax` (Cloud/API) sowie jeder OpenAI-/Anthropic-kompatible Proxy (LM Studio, vLLM, LiteLLM usw.) +- Über `models.providers` (benutzerdefinierte Endpunkte): `minimax` (Cloud/API) sowie jeder OpenAI-/Anthropic-kompatible Proxy (LM Studio, vLLM, LiteLLM usw.) -Tipp: Versuche nicht, „alle Modelle“ in den Docs fest zu codieren. Die maßgebliche Liste ist das, was `discoverModels(...)` auf deiner Maschine zurückgibt + welche Schlüssel verfügbar sind. +Tipp: Versuche nicht, in der Dokumentation „alle Modelle“ fest zu codieren. Die maßgebliche Liste ist, was `discoverModels(...)` auf deiner Maschine zurückgibt + welche Schlüssel verfügbar sind. ## Anmeldedaten (niemals committen) Live-Tests erkennen Anmeldedaten auf dieselbe Weise wie die CLI. Praktische Auswirkungen: - Wenn die CLI funktioniert, sollten Live-Tests dieselben Schlüssel finden. -- Wenn ein Live-Test „keine Anmeldedaten“ meldet, debugge auf dieselbe Weise wie bei `openclaw models list` / Modellauswahl. +- Wenn ein Live-Test „no creds“ meldet, debugge auf dieselbe Weise wie bei `openclaw models list` / der Modellauswahl. -- Auth-Profile pro Agent: `~/.openclaw/agents//agent/auth-profiles.json` (das ist mit „Profilschlüssel“ in den Live-Tests gemeint) +- Auth-Profile pro Agent: `~/.openclaw/agents//agent/auth-profiles.json` (das ist, was mit „Profile-Keys“ in den Live-Tests gemeint ist) - Konfiguration: `~/.openclaw/openclaw.json` (oder `OPENCLAW_CONFIG_PATH`) -- Legacy-Statusverzeichnis: `~/.openclaw/credentials/` (wird bei Vorhandensein in das gestagte Live-Home kopiert, ist aber nicht der Hauptspeicher für Profilschlüssel) -- 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-Overrides für `agents.*.workspace` / `agentDir` werden entfernt, damit Probes nicht in deinem echten Host-Workspace landen. +- Legacy-State-Verzeichnis: `~/.openclaw/credentials/` (wird bei Vorhandensein in das vorbereitete Live-Home kopiert, ist aber nicht der Hauptspeicher für Profile-Keys) +- Lokale Live-Läufe kopieren standardmäßig die aktive Konfiguration, die Dateien `auth-profiles.json` pro Agent, das Legacy-Verzeichnis `credentials/` und unterstützte externe CLI-Auth-Verzeichnisse in ein temporäres Test-Home; vorbereitete Live-Homes überspringen `workspace/` und `sandboxes/`, und Pfad-Overrides für `agents.*.workspace` / `agentDir` werden entfernt, damit Probes nicht in deinem echten Host-Workspace landen. -Wenn du dich auf env-Schlüssel verlassen möchtest (z. B. aus deinem `~/.profile` exportiert), führe lokale Tests nach `source ~/.profile` aus oder verwende die Docker-Runner unten (sie können `~/.profile` in den Container einhängen). +Wenn du dich auf env-Schlüssel verlassen willst (z. B. in deinem `~/.profile` exportiert), führe lokale Tests nach `source ~/.profile` aus oder verwende die Docker-Runner unten (sie können `~/.profile` in den Container einbinden). -## Deepgram Live (Audio-Transkription) +## Deepgram live (Audiotranskription) - Test: `src/media-understanding/providers/deepgram/audio.live.test.ts` - Aktivierung: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts` -## BytePlus Coding-Plan Live +## BytePlus Coding-Plan live - Test: `src/agents/byteplus.live.test.ts` - Aktivierung: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts` - Optionales Modell-Override: `BYTEPLUS_CODING_MODEL=ark-code-latest` -## ComfyUI-Workflow-Medien Live +## 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: - - Testet die gebündelten comfy-Pfade für Bild, Video und `music_generate` - - Überspringt jede Fähigkeit, sofern `models.providers.comfy.` nicht konfiguriert ist - - Nützlich nach Änderungen an comfy-Workflow-Submission, Polling, Downloads oder Plugin-Registrierung + - Testet die gebündelten Comfy-Pfade für Bild, Video und `music_generate` + - Überspringt jede Capability, sofern `models.providers.comfy.` nicht konfiguriert ist + - Nützlich nach Änderungen an Comfy-Workflow-Übermittlung, Polling, Downloads oder Plugin-Registrierung -## Bildgenerierung Live +## Bildgenerierung live - Test: `src/image-generation/runtime.live.test.ts` - Befehl: `pnpm test:live src/image-generation/runtime.live.test.ts` - Harness: `pnpm test:live:media image` - Umfang: - - Zählt jedes registrierte Plugin für Bildgenerierungs-Provider auf - - Lädt fehlende Provider-env-Variablen vor dem Testen aus deiner Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht verdecken - - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell - - Führt die Standardvarianten der Bildgenerierung über die gemeinsame Runtime-Fähigkeit aus: + - Listet jedes registrierte Plugin für Bildgenerierungs-Provider auf + - Lädt fehlende Provider-env vars vor dem Testen aus deiner Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht überdecken + - Überspringt Provider ohne nutzbare Auth/Profile/Modelle + - Führt die Standardvarianten der Bildgenerierung über die gemeinsame Runtime-Capability aus: - `google:flash-generate` - `google:pro-generate` - `google:pro-edit` - `openai:default-generate` -- Derzeit abgedeckte gebündelte Provider: +- Aktuell abgedeckte gebündelte Provider: - `openai` - `google` - Optionale Eingrenzung: - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google"` - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"` - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"` -- Optionales Authentifizierungsverhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung über den Profilspeicher zu erzwingen und reine env-Overrides zu ignorieren +- Optionales Auth-Verhalten: + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Auth aus dem Profile-Store zu erzwingen und env-only-Overrides zu ignorieren -## Musikgenerierung Live +## 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: - - Testet den gemeinsamen gebündelten Pfad für Musikgenerierungs-Provider + - Testet den gemeinsamen gebündelten Provider-Pfad für Musikgenerierung - Deckt derzeit Google und MiniMax ab - - Lädt Provider-env-Variablen vor dem Testen aus deiner Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht verdecken - - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell + - Lädt Provider-env vars vor dem Testen aus deiner Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht überdecken + - Überspringt Provider ohne nutzbare Auth/Profile/Modelle - Führt beide deklarierten Runtime-Modi aus, wenn verfügbar: - - `generate` mit reiner Prompt-Eingabe + - `generate` mit rein promptbasierter Eingabe - `edit`, wenn der Provider `capabilities.edit.enabled` deklariert - - Aktuelle Abdeckung in der gemeinsamen Lane: + - Aktuelle Abdeckung der gemeinsamen Strecke: - `google`: `generate`, `edit` - `minimax`: `generate` - - `comfy`: separate Comfy-Live-Datei, nicht dieser gemeinsame Sweep + - `comfy`: separate Comfy-Live-Datei, nicht Teil dieses gemeinsamen Sweeps - Optionale Eingrenzung: - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"` - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"` -- Optionales Authentifizierungsverhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung über den Profilspeicher zu erzwingen und reine env-Overrides zu ignorieren +- Optionales Auth-Verhalten: + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Auth aus dem Profile-Store zu erzwingen und env-only-Overrides zu ignorieren -## Videogenerierung Live +## 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: - - Testet den gemeinsamen gebündelten Pfad für Videogenerierungs-Provider - - Verwendet standardmäßig den release-sicheren Smoke-Pfad: Nicht-FAL-Provider, eine Text-zu-Video-Anfrage pro Provider, ein einsekündiger Lobster-Prompt und eine providerbezogene Obergrenze pro Operation aus `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (standardmäßig `180000`) + - Testet den gemeinsamen gebündelten Provider-Pfad für Videogenerierung + - Verwendet standardmäßig den release-sicheren Smoke-Pfad: keine FAL-Provider, eine Text-zu-Video-Anfrage pro Provider, einen einsekündigen Lobster-Prompt und eine Provider-spezifische Operationsgrenze aus `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS` (standardmäßig `180000`) - Überspringt FAL standardmäßig, weil providerseitige Queue-Latenz die Release-Zeit dominieren kann; übergib `--video-providers fal` oder `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="fal"`, um ihn explizit auszuführen - - Lädt Provider-env-Variablen vor dem Testen aus deiner Login-Shell (`~/.profile`) - - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht verdecken - - Überspringt Provider ohne nutzbare Authentifizierung/Profil/Modell + - Lädt Provider-env vars vor dem Testen aus deiner Login-Shell (`~/.profile`) + - Verwendet standardmäßig Live-/env-API-Schlüssel vor gespeicherten Auth-Profilen, damit veraltete Testschlüssel in `auth-profiles.json` echte Shell-Anmeldedaten nicht überdecken + - Überspringt Provider ohne nutzbare Auth/Profile/Modelle - Führt standardmäßig nur `generate` aus - - Setze `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, um zusätzlich deklarierte Transformationsmodi auszuführen, wenn verfügbar: - - `imageToVideo`, wenn der Provider `capabilities.imageToVideo.enabled` deklariert und das ausgewählte Provider-/Modellpaar im gemeinsamen Sweep buffer-gestützte lokale Bildeingabe akzeptiert - - `videoToVideo`, wenn der Provider `capabilities.videoToVideo.enabled` deklariert und das ausgewählte Provider-/Modellpaar im gemeinsamen Sweep buffer-gestützte lokale Videoeingabe akzeptiert - - Aktuell deklarierte, aber im gemeinsamen Sweep übersprungene `imageToVideo`-Provider: + - Setze `OPENCLAW_LIVE_VIDEO_GENERATION_FULL_MODES=1`, um bei Verfügbarkeit auch deklarierte Transform-Modi auszuführen: + - `imageToVideo`, wenn der Provider `capabilities.imageToVideo.enabled` deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep bufferbasierte lokale Bildeingaben akzeptiert + - `videoToVideo`, wenn der Provider `capabilities.videoToVideo.enabled` deklariert und der ausgewählte Provider/das ausgewählte Modell im gemeinsamen Sweep bufferbasierte lokale Videoeingaben akzeptiert + - Aktuelle in der gemeinsamen Sweep deklarierte, aber übersprungene `imageToVideo`-Provider: - `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 standardmäßig eine `kling`-Lane aus, die ein Fixture mit einer Remote-Bild-URL verwendet + - diese Datei führt standardmäßig `veo3` Text-zu-Video plus eine `kling`-Strecke aus, die eine Fixture mit Remote-Bild-URL verwendet - Aktuelle `videoToVideo`-Live-Abdeckung: - nur `runway`, wenn das ausgewählte Modell `runway/gen4_aleph` ist - - Aktuell deklarierte, aber im gemeinsamen Sweep übersprungene `videoToVideo`-Provider: - - `alibaba`, `qwen`, `xai`, weil diese Pfade derzeit Referenz-URLs als Remote-`http(s)` / MP4 erfordern - - `google`, weil die aktuelle gemeinsame Gemini-/Veo-Lane lokale buffer-gestützte Eingabe verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird - - `openai`, weil der aktuelle gemeinsame Pfad keine Garantien für organisationsspezifischen Zugriff auf Video-Inpainting/Remix bietet + - Aktuelle in der gemeinsamen Sweep deklarierte, aber übersprungene `videoToVideo`-Provider: + - `alibaba`, `qwen`, `xai`, weil diese Pfade derzeit Remote-Referenz-URLs mit `http(s)` / MP4 erfordern + - `google`, weil die aktuelle gemeinsame Gemini-/Veo-Strecke lokale bufferbasierte Eingaben verwendet und dieser Pfad im gemeinsamen Sweep nicht akzeptiert wird + - `openai`, weil die aktuelle gemeinsame Strecke keine Garantien für organisationsspezifischen Zugriff auf Video-Inpaint/Remix bietet - 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 im Standardsweep einzuschließen, einschließlich FAL - - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, um die providerbezogene Obergrenze pro Operation für einen aggressiven Smoke-Lauf zu reduzieren -- Optionales Authentifizierungsverhalten: - - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Authentifizierung über den Profilspeicher zu erzwingen und reine env-Overrides zu ignorieren + - `OPENCLAW_LIVE_VIDEO_GENERATION_SKIP_PROVIDERS=""`, um jeden Provider im Standard-Sweep einzubeziehen, einschließlich FAL + - `OPENCLAW_LIVE_VIDEO_GENERATION_TIMEOUT_MS=60000`, um die Operationsgrenze pro Provider für einen aggressiven Smoke-Lauf zu senken +- Optionales Auth-Verhalten: + - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um Auth aus dem Profile-Store zu erzwingen und env-only-Overrides zu ignorieren ## Media-Live-Harness - Befehl: `pnpm test:live:media` - Zweck: - - Führt die gemeinsamen Live-Suites für Bild, Musik und Video über einen repo-eigenen Entry-Point aus - - Lädt fehlende Provider-env-Variablen automatisch aus `~/.profile` - - Grenzt standardmäßig jede Suite automatisch auf Provider ein, die derzeit nutzbare Authentifizierung haben + - Führt die gemeinsamen Live-Suites für Bild, Musik und Video über einen repo-nativen Entrypoint aus + - Lädt fehlende Provider-env vars automatisch aus `~/.profile` + - Grenzt jede Suite standardmäßig automatisch auf Provider ein, die aktuell nutzbare Auth haben - Verwendet erneut `scripts/test-live.mjs`, sodass Heartbeat- und Quiet-Mode-Verhalten konsistent bleiben - Beispiele: - `pnpm test:live:media` @@ -830,20 +830,20 @@ Wenn du dich auf env-Schlüssel verlassen möchtest (z. B. aus deinem `~/.profil ## Docker-Runner (optionale „funktioniert unter Linux“-Prüfungen) -Diese Docker-Runner teilen sich in zwei Gruppen auf: +Diese Docker-Runner sind in zwei Gruppen aufgeteilt: -- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur ihre jeweils passende Live-Datei für Profilschlüssel innerhalb des Repo-Docker-Images aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei dein lokales Konfigurationsverzeichnis und dein Workspace eingehängt werden (und `~/.profile` gesourct wird, wenn es eingehängt ist). Die passenden lokalen Entry-Points sind `test:live:models-profiles` und `test:live:gateway-profiles`. +- Live-Modell-Runner: `test:docker:live-models` und `test:docker:live-gateway` führen nur ihre jeweils passende Live-Datei für Profile-Keys im Repo-Docker-Image aus (`src/agents/models.profiles.live.test.ts` und `src/gateway/gateway-models.profiles.live.test.ts`), wobei dein lokales Konfigurationsverzeichnis und dein Workspace eingebunden werden (und `~/.profile` gesourct wird, falls eingebunden). Die passenden lokalen Entrypoints sind `test:live:models-profiles` und `test:live:gateway-profiles`. - Docker-Live-Runner verwenden standardmäßig eine kleinere Smoke-Obergrenze, damit ein vollständiger Docker-Sweep praktikabel bleibt: `test:docker:live-models` verwendet standardmäßig `OPENCLAW_LIVE_MAX_MODELS=12`, und `test:docker:live-gateway` verwendet standardmäßig `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` und - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Überschreibe diese env-Variablen, wenn du + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Überschreibe diese env vars, wenn du ausdrücklich den größeren vollständigen Scan möchtest. -- `test:docker:all` baut das Live-Docker-Image einmal über `test:docker:live-build` und verwendet es dann für die beiden Docker-Live-Lanes erneut. +- `test:docker:all` baut das Live-Docker-Image einmal über `test:docker:live-build` und verwendet es dann für die beiden Live-Docker-Strecken erneut. - Container-Smoke-Runner: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` und `test:docker:plugins` starten einen oder mehrere echte Container und verifizieren Integrationspfade auf höherer Ebene. -Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Auth-Homes ein (oder alle unterstützten, wenn der Lauf nicht eingegrenzt ist) und kopieren sie dann vor dem Lauf in das Home-Verzeichnis des Containers, damit OAuth externer CLIs Tokens aktualisieren kann, ohne den Auth-Speicher des Hosts zu verändern: +Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Auth-Homes ein (oder alle unterstützten, wenn der Lauf nicht eingegrenzt ist) und kopieren sie dann vor dem Lauf in das Container-Home, damit externes CLI-OAuth Tokens aktualisieren kann, ohne den Auth-Store des Hosts zu verändern: - Direkte Modelle: `pnpm test:docker:live-models` (Skript: `scripts/test-live-models-docker.sh`) - ACP-Bind-Smoke: `pnpm test:docker:live-acp-bind` (Skript: `scripts/test-live-acp-bind-docker.sh`) @@ -853,139 +853,140 @@ Die Docker-Runner für Live-Modelle binden außerdem nur die benötigten CLI-Aut - Open-WebUI-Live-Smoke: `pnpm test:docker:openwebui` (Skript: `scripts/e2e/openwebui-docker.sh`) - Onboarding-Assistent (TTY, vollständiges Scaffolding): `pnpm test:docker:onboard` (Skript: `scripts/e2e/onboard-docker.sh`) - Gateway-Networking (zwei Container, WS-Auth + Health): `pnpm test:docker:gateway-network` (Skript: `scripts/e2e/gateway-network-docker.sh`) -- MCP-Kanal-Bridge (vorgefülltes Gateway + stdio-Bridge + roher Claude-Benachrichtigungsframe-Smoke): `pnpm test:docker:mcp-channels` (Skript: `scripts/e2e/mcp-channels-docker.sh`) +- MCP-Channel-Bridge (vorbereiteter Gateway + stdio-Bridge + roher Claude-Benachrichtigungsframe-Smoke): `pnpm test:docker:mcp-channels` (Skript: `scripts/e2e/mcp-channels-docker.sh`) - Plugins (Installations-Smoke + `/plugin`-Alias + Neustartsemantik des Claude-Bundles): `pnpm test:docker:plugins` (Skript: `scripts/e2e/plugins-docker.sh`) Die Docker-Runner für Live-Modelle binden außerdem den aktuellen Checkout schreibgeschützt ein und -stagen ihn in ein temporäres Workdir innerhalb des Containers. Dadurch bleibt das Runtime- -Image schlank, während Vitest trotzdem gegen genau deinen lokalen Quellcode/deine lokale Konfiguration ausgeführt wird. -Der Staging-Schritt überspringt große nur lokale Caches und App-Build-Ausgaben wie +stellen ihn in ein temporäres Workdir im Container bereit. So bleibt das Runtime- +Image schlank, während Vitest trotzdem gegen deinen exakten lokalen Source-/Konfigurationsstand läuft. +Der Bereitstellungsschritt überspringt große lokale Caches und App-Build-Ausgaben wie `.pnpm-store`, `.worktrees`, `__openclaw_vitest__` und app-lokale `.build`- oder -Gradle-Ausgabeverzeichnisse, damit Docker-Live-Läufe nicht minutenlang -maschinenspezifische Artefakte kopieren. -Sie setzen außerdem `OPENCLAW_SKIP_CHANNELS=1`, damit Gateway-Live-Probes nicht -echte Kanal-Worker für Telegram/Discord usw. innerhalb des Containers starten. -`test:docker:live-models` führt weiterhin `pnpm test:live` aus, daher gib auch -`OPENCLAW_LIVE_GATEWAY_*` weiter, wenn du die Gateway- -Live-Abdeckung in dieser Docker-Lane eingrenzen oder ausschließen musst. +Gradle-Ausgabeordner, damit Docker-Live-Läufe nicht Minuten mit dem Kopieren +maschinenspezifischer Artifacts verbringen. +Sie setzen außerdem `OPENCLAW_SKIP_CHANNELS=1`, damit Gateway-Live-Probes keine +echten Telegram-/Discord-/usw.-Channel-Worker im Container starten. +`test:docker:live-models` führt weiterhin `pnpm test:live` aus; reiche daher auch +`OPENCLAW_LIVE_GATEWAY_*` durch, wenn du die Gateway-Live-Abdeckung in dieser Docker-Strecke +eingrenzen oder ausschließen musst. `test:docker:openwebui` ist ein höherstufiger Kompatibilitäts-Smoke: Er startet einen -OpenClaw-Gateway-Container mit aktivierten OpenAI-kompatiblen HTTP-Endpoints, -startet einen angehefteten Open-WebUI-Container gegen dieses Gateway, meldet sich über -Open WebUI an, prüft, dass `/api/models` `openclaw/default` bereitstellt, und sendet dann eine -echte Chat-Anfrage über den Proxy `/api/chat/completions` von Open WebUI. -Der erste Lauf kann deutlich langsamer sein, weil Docker möglicherweise das -Open-WebUI-Image ziehen muss und Open WebUI möglicherweise seine eigene Kaltstart-Einrichtung abschließen muss. -Diese Lane erwartet einen nutzbaren Live-Modell-Schlüssel, und `OPENCLAW_PROFILE_FILE` +OpenClaw-Gateway-Container mit aktivierten OpenAI-kompatiblen HTTP-Endpunkten, +startet einen festgepinnte Open-WebUI-Container gegen dieses Gateway, meldet sich über +Open WebUI an, verifiziert, dass `/api/models` `openclaw/default` bereitstellt, und sendet dann +eine echte Chat-Anfrage über den Proxy `/api/chat/completions` von Open WebUI. +Der erste Lauf kann spürbar langsamer sein, weil Docker möglicherweise zuerst das +Open-WebUI-Image ziehen muss und Open WebUI sein eigenes Cold-Start-Setup abschließen muss. +Diese Strecke erwartet einen verwendbaren Live-Modellschlüssel, und `OPENCLAW_PROFILE_FILE` (`~/.profile` standardmäßig) ist der primäre Weg, ihn in Docker-Läufen bereitzustellen. -Erfolgreiche Läufe geben eine kleine JSON-Payload aus wie `{ "ok": true, "model": -"openclaw/default", ... }`. +Erfolgreiche Läufe geben eine kleine JSON-Payload wie `{ "ok": true, "model": +"openclaw/default", ... }` aus. `test:docker:mcp-channels` ist absichtlich deterministisch und benötigt kein -echtes Telegram-, Discord- oder iMessage-Konto. Es startet ein vorgefülltes Gateway- +echtes Telegram-, Discord- oder iMessage-Konto. Es startet einen vorbereiteten Gateway- Container, startet einen zweiten Container, der `openclaw mcp serve` ausführt, und -prüft dann geroutete Konversationserkennung, Transkript-Lesezugriffe, Anhang-Metadaten, -Verhalten der Live-Ereigniswarteschlange, Routing ausgehender Sendungen und Benachrichtigungen -zu Kanal + Berechtigungen im Claude-Stil über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung -untersucht die rohen stdio-MCP-Frames direkt, sodass der Smoke das validiert, was die -Bridge tatsächlich ausgibt, nicht nur das, was ein bestimmtes Client-SDK zufällig bereitstellt. +verifiziert dann geroutete Konversationserkennung, Transkriptlesevorgänge, Attachment-Metadaten, +Verhalten der Live-Event-Queue, Routing ausgehender Sends sowie Claude-artige Channel- + +Berechtigungsbenachrichtigungen über die echte stdio-MCP-Bridge. Die Benachrichtigungsprüfung +untersucht direkt die rohen stdio-MCP-Frames, sodass der Smoke validiert, was die +Bridge tatsächlich ausgibt, und nicht nur, was ein bestimmtes Client-SDK gerade sichtbar macht. -Manueller ACP-Smoke für Threads in natürlicher Sprache (nicht CI): +Manueller ACP-Smoketest für Threads in natürlicher Sprache (nicht CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Behalte dieses Skript für Regressions-/Debug-Workflows. Es könnte für die Validierung des ACP-Thread-Routings erneut benötigt werden, also nicht löschen. +- Behalte dieses Skript für Regressions-/Debug-Workflows bei. Es kann für die Validierung des ACP-Thread-Routings erneut benötigt werden, also nicht löschen. -Nützliche env-Variablen: +Nützliche env vars: -- `OPENCLAW_CONFIG_DIR=...` (Standard: `~/.openclaw`), eingehängt nach `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (Standard: `~/.openclaw/workspace`), eingehängt nach `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (Standard: `~/.profile`), eingehängt nach `/home/node/.profile` und vor dem Ausführen der Tests gesourct -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (Standard: `~/.cache/openclaw/docker-cli-tools`), eingehängt nach `/home/node/.npm-global` für zwischengespeicherte CLI-Installationen innerhalb von Docker -- Externe CLI-Auth-Verzeichnisse/-Dateien unter `$HOME` werden schreibgeschützt unter `/host-auth...` eingehängt und dann vor dem Start der Tests nach `/home/node/...` kopiert +- `OPENCLAW_CONFIG_DIR=...` (Standard: `~/.openclaw`), eingebunden nach `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...` (Standard: `~/.openclaw/workspace`), eingebunden nach `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...` (Standard: `~/.profile`), eingebunden nach `/home/node/.profile` und vor dem Ausführen der Tests gesourct +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, um nur env vars zu prüfen, die aus `OPENCLAW_PROFILE_FILE` gesourct wurden, unter Verwendung temporärer Konfigurations-/Workspace-Verzeichnisse und ohne externe CLI-Auth-Mounts +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (Standard: `~/.cache/openclaw/docker-cli-tools`), eingebunden nach `/home/node/.npm-global` für gecachte CLI-Installationen in Docker +- Externe CLI-Auth-Verzeichnisse/-Dateien unter `$HOME` werden schreibgeschützt unter `/host-auth...` eingebunden und dann nach `/home/node/...` kopiert, bevor die Tests starten - Standardverzeichnisse: `.minimax` - Standarddateien: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Eingegrenzte Provider-Läufe hängen nur die benötigten Verzeichnisse/Dateien ein, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden - - Manuelles Override mit `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` oder einer Komma-Liste wie `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Eingegrenzte Provider-Läufe binden nur die benötigten Verzeichnisse/Dateien ein, die aus `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` abgeleitet werden + - Manuelle Überschreibung mit `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` oder einer Komma-Liste wie `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, um den Lauf einzugrenzen - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, um Provider im Container zu filtern -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, um ein vorhandenes Image `openclaw:local-live` für erneute Läufe wiederzuverwenden, die keinen Neubau benötigen -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Anmeldedaten aus dem Profilspeicher kommen (nicht aus env) -- `OPENCLAW_OPENWEBUI_MODEL=...`, um das vom Gateway für den Open-WebUI-Smoke bereitgestellte Modell auszuwählen -- `OPENCLAW_OPENWEBUI_PROMPT=...`, um den für den Open-WebUI-Smoke verwendeten Nonce-Prüf-Prompt zu überschreiben -- `OPENWEBUI_IMAGE=...`, um das angeheftete Open-WebUI-Image-Tag zu überschreiben +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, um ein vorhandenes Image `openclaw:local-live` für erneute Läufe zu verwenden, die keinen Neubau benötigen +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, um sicherzustellen, dass Anmeldedaten aus dem Profile-Store kommen (nicht aus env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, um das Modell auszuwählen, das das Gateway für den Open-WebUI-Smoke bereitstellt +- `OPENCLAW_OPENWEBUI_PROMPT=...`, um den für den Open-WebUI-Smoke verwendeten Nonce-Prüfprompt zu überschreiben +- `OPENWEBUI_IMAGE=...`, um das festgepinnte Open-WebUI-Image-Tag zu überschreiben -## Docs-Sanity +## Doku-Sanity -Führe nach Änderungen an der Dokumentation die Docs-Prüfungen aus: `pnpm check:docs`. -Führe die vollständige Mintlify-Anchor-Validierung aus, wenn du auch Prüfungen für In-Page-Überschriften benötigst: `pnpm docs:check-links:anchors`. +Führe nach Doku-Bearbeitungen Doku-Prüfungen aus: `pnpm check:docs`. +Führe die vollständige Mintlify-Anchor-Validierung aus, wenn du auch Heading-Prüfungen innerhalb der Seite brauchst: `pnpm docs:check-links:anchors`. ## Offline-Regression (CI-sicher) -Das sind Regressionstests für die „reale Pipeline“ ohne echte Provider: +Das sind Regressionen mit „echter Pipeline“, aber ohne echte Provider: -- Gateway-Tool-Calling (Mock-OpenAI, echtes Gateway + Agent-Schleife): `src/gateway/gateway.test.ts` (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Gateway-Assistent (WS `wizard.start`/`wizard.next`, schreibt Konfiguration + erzwungene Authentifizierung): `src/gateway/gateway.test.ts` (Fall: "runs wizard over ws and writes auth token config") +- Gateway-Tool-Calling (Mock-OpenAI, echtes Gateway + Agent-Loop): `src/gateway/gateway.test.ts` (Fall: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Gateway-Assistent (WS `wizard.start`/`wizard.next`, schreibt Konfiguration + Auth erzwungen): `src/gateway/gateway.test.ts` (Fall: "runs wizard over ws and writes auth token config") -## Agent-Zuverlässigkeits-Evals (Skills) +## Evals zur Agent-Zuverlässigkeit (Skills) -Wir haben bereits einige CI-sichere Tests, die sich wie „Agent-Zuverlässigkeits-Evals“ verhalten: +Wir haben bereits einige CI-sichere Tests, die sich wie „Evals zur Agent-Zuverlässigkeit“ verhalten: -- Mock-Tool-Calling über die echte Gateway- + Agent-Schleife (`src/gateway/gateway.test.ts`). -- End-to-End-Assistenten-Flows, die Sitzungsverdrahtung und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). +- Mock-Tool-Calling über den echten Gateway- + Agent-Loop (`src/gateway/gateway.test.ts`). +- End-to-End-Assistenten-Flows, die Sitzungs-Wiring und Konfigurationseffekte validieren (`src/gateway/gateway.test.ts`). Was für Skills noch fehlt (siehe [Skills](/de/tools/skills)): -- **Decisioning:** Wenn Skills im Prompt aufgeführt sind, wählt der Agent den richtigen Skill aus (oder vermeidet irrelevante)? -- **Compliance:** Liest der Agent vor der Nutzung `SKILL.md` und folgt den erforderlichen Schritten/Argumenten? -- **Workflow-Verträge:** Multi-Turn-Szenarien, die Tool-Reihenfolge, Übernahme des Sitzungsverlaufs und Sandbox-Grenzen prüfen. +- **Entscheidungsfindung:** Wenn Skills im Prompt aufgeführt sind, wählt der Agent dann den richtigen Skill aus (oder vermeidet irrelevante)? +- **Compliance:** Liest der Agent vor der Verwendung `SKILL.md` und befolgt die erforderlichen Schritte/Args? +- **Workflow-Verträge:** Multi-Turn-Szenarien, die Tool-Reihenfolge, Sitzungsverlauf über mehrere Turns und Sandbox-Grenzen prüfen. Zukünftige Evals sollten zuerst deterministisch bleiben: -- Ein Szenario-Runner, der Mock-Provider verwendet, um Tool-Calls + Reihenfolge, Skill-Datei-Lesezugriffe und Sitzungsverdrahtung zu prüfen. -- Eine kleine Suite skill-fokussierter Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection). -- Optionale Live-Evals (Opt-in, env-gesteuert) erst, nachdem die CI-sichere Suite vorhanden ist. +- Ein Szenario-Runner mit Mock-Providern, der Tool-Calls + Reihenfolge, Skill-Dateilesen und Sitzungs-Wiring prüft. +- Eine kleine Suite mit Skill-fokussierten Szenarien (verwenden vs. vermeiden, Gating, Prompt-Injection). +- Optionale Live-Evals (Opt-in, env-gated) erst dann, wenn die CI-sichere Suite vorhanden ist. -## Vertragstests (Plugin- und Kanalform) +## Contract-Tests (Plugin- und Channel-Form) -Vertragstests verifizieren, dass jedes registrierte Plugin und jeder Kanal seinem -Schnittstellenvertrag entspricht. Sie iterieren über alle entdeckten Plugins und führen eine Suite aus -Form- und Verhaltensprüfungen aus. Die standardmäßige Unit-Lane `pnpm test` -überspringt diese gemeinsam genutzten Seam- und Smoke-Dateien absichtlich; führe die Vertragsbefehle explizit aus, -wenn du gemeinsam genutzte Kanal- oder Provider-Oberflächen änderst. +Contract-Tests verifizieren, dass jedes registrierte Plugin und jeder registrierte Channel seinem +Schnittstellenvertrag entspricht. Sie iterieren über alle entdeckten Plugins und führen eine Suite von +Prüfungen für Form und Verhalten aus. Die standardmäßige Unit-Strecke `pnpm test` +überspringt diese gemeinsamen Seam- und Smoke-Dateien absichtlich; führe die Contract-Befehle explizit aus, +wenn du gemeinsame Channel- oder Provider-Oberflächen anfasst. ### Befehle -- Alle Verträge: `pnpm test:contracts` -- Nur Kanalverträge: `pnpm test:contracts:channels` -- Nur Provider-Verträge: `pnpm test:contracts:plugins` +- Alle Contracts: `pnpm test:contracts` +- Nur Channel-Contracts: `pnpm test:contracts:channels` +- Nur Provider-Contracts: `pnpm test:contracts:plugins` -### Kanalverträge +### Channel-Contracts -Zu finden unter `src/channels/plugins/contracts/*.contract.test.ts`: +Liegen unter `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Grundform des Plugins (ID, Name, Fähigkeiten) -- **setup** - Vertragsprüfung des Setup-Assistenten -- **session-binding** - Verhalten beim Sitzungs-Binding -- **outbound-payload** - Struktur der Nachrichten-Payload +- **plugin** - Grundlegende Plugin-Form (ID, Name, Capabilities) +- **setup** - Vertrag für den Setup-Assistenten +- **session-binding** - Verhalten der Sitzungsbindung +- **outbound-payload** - Struktur der Message-Payload - **inbound** - Verarbeitung eingehender Nachrichten -- **actions** - Handler für Kanalaktionen +- **actions** - Channel-Action-Handler - **threading** - Verarbeitung von Thread-IDs - **directory** - API für Verzeichnis/Roster -- **group-policy** - Durchsetzung von Gruppenrichtlinien +- **group-policy** - Durchsetzung der Gruppenrichtlinie -### Provider-Statusverträge +### Provider-Status-Contracts -Zu finden unter `src/plugins/contracts/*.contract.test.ts`. +Liegen unter `src/plugins/contracts/*.contract.test.ts`. -- **status** - Kanal-Status-Probes +- **status** - Channel-Status-Probes - **registry** - Form der Plugin-Registry -### Provider-Verträge +### Provider-Contracts -Zu finden unter `src/plugins/contracts/*.contract.test.ts`: +Liegen unter `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Vertrag des Authentifizierungsablaufs -- **auth-choice** - Authentifizierungswahl/-auswahl +- **auth** - Auth-Flow-Vertrag +- **auth-choice** - Auth-Auswahl - **catalog** - API des Modellkatalogs -- **discovery** - Plugin-Erkennung +- **discovery** - Plugin-Discovery - **loader** - Plugin-Laden - **runtime** - Provider-Runtime - **shape** - Plugin-Form/Schnittstelle @@ -994,20 +995,20 @@ Zu finden unter `src/plugins/contracts/*.contract.test.ts`: ### Wann ausführen - Nach Änderungen an `plugin-sdk`-Exports oder Subpfaden -- Nach dem Hinzufügen oder Ändern eines Kanal- oder Provider-Plugins -- Nach Refactorings der Plugin-Registrierung oder -Erkennung +- Nach dem Hinzufügen oder Ändern eines Channel- oder Provider-Plugins +- Nach Refactorings an Plugin-Registrierung oder -Discovery -Vertragstests laufen in CI und erfordern keine echten API-Schlüssel. +Contract-Tests laufen in CI und benötigen keine echten API-Schlüssel. -## Regressionen hinzufügen (Leitlinien) +## Regressionen hinzufügen (Leitfaden) -Wenn du ein Provider-/Modellproblem behebst, das in Live entdeckt wurde: +Wenn du ein in Live entdecktes Provider-/Modellproblem behebst: -- Füge nach Möglichkeit eine CI-sichere Regression hinzu (Mock-/Stub-Provider oder Erfassung der exakten Transformation der Request-Form) -- Wenn es von Natur aus nur live prüfbar ist (Rate Limits, Authentifizierungsrichtlinien), halte den Live-Test eng und als Opt-in über env-Variablen +- Füge möglichst eine CI-sichere Regression hinzu (Mock-/Stub-Provider oder erfasse die exakte Transformation der Request-Form) +- Wenn das Problem von Natur aus nur live testbar ist (Rate Limits, Auth-Richtlinien), halte den Live-Test eng und aktiviere ihn per Opt-in über env vars - Bevorzuge die kleinste Ebene, die den Fehler erkennt: - - Fehler bei Provider-Request-Konvertierung/-Replay → Test direkter Modelle - - Fehler in Gateway-Sitzung/Verlauf/Tool-Pipeline → Gateway-Live-Smoke oder CI-sicherer Gateway-Mock-Test -- Schutzregel für SecretRef-Traversierung: - - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet aus Registry-Metadaten (`listSecretTargetRegistryEntries()`) ein Stichprobenziel pro SecretRef-Klasse ab und prüft dann, dass Exec-IDs von Traversierungssegmenten zurückgewiesen werden. - - Wenn du in `src/secrets/target-registry-data.ts` eine neue SecretRef-Zielfamilie mit `includeInPlan` hinzufügst, aktualisiere `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend übersprungen werden können. + - Fehler bei Provider-Request-Konvertierung/Replay → Test für direkte Modelle + - Fehler bei Gateway-Sitzung/Verlauf/Tool-Pipeline → Gateway-Live-Smoke oder CI-sicherer Gateway-Mock-Test +- Guardrail für SecretRef-Traversierung: + - `src/secrets/exec-secret-ref-id-parity.test.ts` leitet aus den Registry-Metadaten (`listSecretTargetRegistryEntries()`) ein gesampeltes Ziel pro SecretRef-Klasse ab und prüft dann, dass Exec-IDs von Traversierungssegmenten zurückgewiesen werden. + - Wenn du in `src/secrets/target-registry-data.ts` eine neue `includeInPlan`-SecretRef-Zielfamilie hinzufügst, aktualisiere `classifyTargetClass` in diesem Test. Der Test schlägt absichtlich bei nicht klassifizierten Ziel-IDs fehl, damit neue Klassen nicht stillschweigend ausgelassen werden können. diff --git a/docs/de/providers/github-copilot.md b/docs/de/providers/github-copilot.md index ceb0a1856..09a07cc93 100644 --- a/docs/de/providers/github-copilot.md +++ b/docs/de/providers/github-copilot.md @@ -1,14 +1,14 @@ --- read_when: - - Sie möchten GitHub Copilot als Modell-Provider verwenden - - Sie benötigen den `openclaw models auth login-github-copilot`-Ablauf -summary: Bei GitHub Copilot aus OpenClaw mit dem Device Flow anmelden + - Sie möchten GitHub Copilot als Modellanbieter verwenden + - Sie benötigen den Ablauf `openclaw models auth login-github-copilot` +summary: Melden Sie sich über den Gerätefluss von OpenClaw bei GitHub Copilot an title: GitHub Copilot x-i18n: - generated_at: "2026-04-12T23:30:58Z" + generated_at: "2026-04-15T14:40:26Z" model: gpt-5.4 provider: openai - source_hash: 51fee006e7d4e78e37b0c29356b0090b132de727d99b603441767d3fb642140b + source_hash: b8258fecff22fb73b057de878462941f6eb86d0c5f775c5eac4840e95ba5eccf source_path: providers/github-copilot.md workflow: 15 --- @@ -16,19 +16,19 @@ x-i18n: # GitHub Copilot GitHub Copilot ist GitHubs KI-Coding-Assistent. Er bietet Zugriff auf Copilot- -Modelle für Ihr GitHub-Konto und Ihren Tarif. OpenClaw kann Copilot auf zwei verschiedene Arten als Modell- -Provider verwenden. +Modelle für Ihr GitHub-Konto und Ihren Tarif. OpenClaw kann Copilot auf zwei +verschiedene Arten als Modellanbieter verwenden. ## Zwei Möglichkeiten, Copilot in OpenClaw zu verwenden - - Verwenden Sie den nativen Device-Login-Ablauf, um ein GitHub-Token zu erhalten, und tauschen Sie es dann - beim Ausführen von OpenClaw gegen Copilot-API-Token aus. Dies ist der **Standard** und der einfachste Weg, - weil dafür kein VS Code erforderlich ist. + + Verwenden Sie den nativen Geräteanmeldefluss, um ein GitHub-Token zu erhalten, und tauschen Sie es dann gegen + Copilot-API-Token aus, wenn OpenClaw ausgeführt wird. Dies ist der **Standard** und der einfachste Weg, + da dafür kein VS Code erforderlich ist. - + ```bash openclaw models auth login-github-copilot ``` @@ -36,7 +36,7 @@ Provider verwenden. Sie werden aufgefordert, eine URL aufzurufen und einen einmaligen Code einzugeben. Lassen Sie das Terminal geöffnet, bis der Vorgang abgeschlossen ist. - + ```bash openclaw models set github-copilot/gpt-4o ``` @@ -53,13 +53,13 @@ Provider verwenden. - + Verwenden Sie die VS Code-Erweiterung **Copilot Proxy** als lokale Brücke. OpenClaw kommuniziert mit dem `/v1`-Endpunkt des Proxys und verwendet die Modellliste, die Sie dort konfigurieren. Wählen Sie dies, wenn Sie Copilot Proxy bereits in VS Code ausführen oder den Datenverkehr - darüber leiten müssen. Sie müssen das Plugin aktivieren und die VS Code-Erweiterung weiterhin ausführen. + darüber leiten müssen. Sie müssen das Plugin aktivieren und die VS Code-Erweiterung weiter ausführen. @@ -67,10 +67,10 @@ Provider verwenden. ## Optionale Flags -| Flag | Beschreibung | -| --------------- | --------------------------------------------------- | -| `--yes` | Die Bestätigungsabfrage überspringen | -| `--set-default` | Zusätzlich das empfohlene Standardmodell des Providers anwenden | +| Flag | Beschreibung | +| --------------- | ------------------------------------------------- | +| `--yes` | Überspringt die Bestätigungsaufforderung | +| `--set-default` | Wendet außerdem das empfohlene Standardmodell des Anbieters an | ```bash # Bestätigung überspringen @@ -81,58 +81,98 @@ openclaw models auth login --provider github-copilot --method device --set-defau ``` - - Der Device-Login-Ablauf erfordert ein interaktives TTY. Führen Sie ihn direkt in einem - Terminal aus, nicht in einem nicht interaktiven Skript oder einer CI-Pipeline. + + Der Geräteanmeldefluss erfordert ein interaktives TTY. Führen Sie ihn direkt in einem + Terminal aus, nicht in einem nicht-interaktiven Skript oder einer CI-Pipeline. - + Die Verfügbarkeit von Copilot-Modellen hängt von Ihrem GitHub-Tarif ab. Wenn ein Modell abgelehnt wird, versuchen Sie eine andere ID (zum Beispiel `github-copilot/gpt-4.1`). - + Claude-Modell-IDs verwenden automatisch den Anthropic-Messages-Transport. GPT-, o-series- und Gemini-Modelle verwenden weiterhin den OpenAI-Responses-Transport. OpenClaw - wählt den richtigen Transport anhand der Modell-Referenz aus. + wählt den richtigen Transport basierend auf der Modell-Ref aus. - + OpenClaw löst die Copilot-Authentifizierung aus Umgebungsvariablen in der folgenden Prioritätsreihenfolge auf: - | Priorität | Variable | Hinweise | - | --------- | ---------------------- | -------------------------------- | + | Priorität | Variable | Hinweise | + | --------- | --------------------- | -------------------------------- | | 1 | `COPILOT_GITHUB_TOKEN` | Höchste Priorität, Copilot-spezifisch | - | 2 | `GH_TOKEN` | GitHub-CLI-Token (Fallback) | - | 3 | `GITHUB_TOKEN` | Standard-GitHub-Token (niedrigste Priorität) | + | 2 | `GH_TOKEN` | GitHub-CLI-Token (Fallback) | + | 3 | `GITHUB_TOKEN` | Standard-GitHub-Token (niedrigste Priorität) | - Wenn mehrere Variablen gesetzt sind, verwendet OpenClaw die Variable mit der höchsten Priorität. - Der Device-Login-Ablauf (`openclaw models auth login-github-copilot`) speichert - sein Token im Authentifizierungsprofil-Speicher und hat Vorrang vor allen Umgebungs- + Wenn mehrere Variablen gesetzt sind, verwendet OpenClaw die mit der höchsten Priorität. + Der Geräteanmeldefluss (`openclaw models auth login-github-copilot`) speichert + sein Token im Auth-Profil-Speicher und hat Vorrang vor allen Umgebungs- variablen. - - Die Anmeldung speichert ein GitHub-Token im Authentifizierungsprofil-Speicher und tauscht es - beim Ausführen von OpenClaw gegen ein Copilot-API-Token aus. Sie müssen das + + Die Anmeldung speichert ein GitHub-Token im Auth-Profil-Speicher und tauscht es + aus, wenn OpenClaw ausgeführt wird, gegen ein Copilot-API-Token aus. Sie müssen das Token nicht manuell verwalten. -Erfordert ein interaktives TTY. Führen Sie den Login-Befehl direkt in einem Terminal aus, nicht -innerhalb eines Headless-Skripts oder CI-Jobs. +Erfordert ein interaktives TTY. Führen Sie den Anmeldebefehl direkt in einem Terminal aus, +nicht in einem headless Skript oder CI-Job. +## Einbettungen für die Speicher-Suche + +GitHub Copilot kann auch als Einbettungsanbieter für die +[Speicher-Suche](/de/concepts/memory-search) dienen. Wenn Sie ein Copilot-Abonnement haben und +angemeldet sind, kann OpenClaw es für Einbettungen ohne separaten API-Schlüssel verwenden. + +### Automatische Erkennung + +Wenn `memorySearch.provider` `"auto"` ist (der Standard), wird GitHub Copilot +mit Priorität 15 versucht – nach lokalen Einbettungen, aber vor OpenAI und anderen +kostenpflichtigen Anbietern. Wenn ein GitHub-Token verfügbar ist, erkennt OpenClaw verfügbare +Einbettungsmodelle über die Copilot-API und wählt automatisch das beste aus. + +### Explizite Konfiguration + +```json5 +{ + agents: { + defaults: { + memorySearch: { + provider: "github-copilot", + // Optional: das automatisch erkannte Modell überschreiben + model: "text-embedding-3-small", + }, + }, + }, +} +``` + +### So funktioniert es + +1. OpenClaw löst Ihr GitHub-Token auf (aus Umgebungsvariablen oder dem Auth-Profil). +2. Tauscht es gegen ein kurzlebiges Copilot-API-Token aus. +3. Fragt den Copilot-`/models`-Endpunkt ab, um verfügbare Einbettungsmodelle zu erkennen. +4. Wählt das beste Modell aus (bevorzugt `text-embedding-3-small`). +5. Sendet Einbettungsanfragen an den Copilot-`/embeddings`-Endpunkt. + +Die Modellverfügbarkeit hängt von Ihrem GitHub-Tarif ab. Wenn keine Einbettungsmodelle +verfügbar sind, überspringt OpenClaw Copilot und versucht den nächsten Anbieter. + ## Verwandt - Auswahl von Providern, Modell-Referenzen und Failover-Verhalten. + Auswahl von Anbietern, Modell-Refs und Failover-Verhalten. - Authentifizierungsdetails und Regeln zur Wiederverwendung von Anmeldedaten. + Details zur Authentifizierung und Regeln zur Wiederverwendung von Anmeldedaten. diff --git a/docs/de/providers/ollama.md b/docs/de/providers/ollama.md index e5bd5a110..1b55dee06 100644 --- a/docs/de/providers/ollama.md +++ b/docs/de/providers/ollama.md @@ -1,24 +1,24 @@ --- read_when: - - Sie möchten OpenClaw über Ollama mit Cloud- oder lokalen Modellen ausführen - - Sie benötigen Anleitungen für Einrichtung und Konfiguration von Ollama + - Sie möchten OpenClaw mit Cloud- oder lokalen Modellen über Ollama ausführen + - Sie benötigen Anleitungen zur Einrichtung und Konfiguration von Ollama summary: OpenClaw mit Ollama ausführen (Cloud- und lokale Modelle) title: Ollama x-i18n: - generated_at: "2026-04-12T23:32:07Z" + generated_at: "2026-04-15T14:40:47Z" model: gpt-5.4 provider: openai - source_hash: ec796241b884ca16ec7077df4f3f1910e2850487bb3ea94f8fdb37c77e02b219 + source_hash: 098e083e0fc484bddb5270eb630c55d7832039b462d1710372b6afece5cefcdf source_path: providers/ollama.md workflow: 15 --- # Ollama -Ollama ist eine lokale LLM-Laufzeit, mit der Sie Open-Source-Modelle einfach auf Ihrer Maschine ausführen können. OpenClaw integriert sich mit der nativen API von Ollama (`/api/chat`), unterstützt Streaming und Tool-Calling und kann lokale Ollama-Modelle automatisch erkennen, wenn Sie dies mit `OLLAMA_API_KEY` (oder einem Auth-Profil) aktivieren und keinen expliziten Eintrag `models.providers.ollama` definieren. +OpenClaw integriert sich mit Ollamas nativer API (`/api/chat`) für gehostete Cloud-Modelle und lokale/selbstgehostete Ollama-Server. Sie können Ollama in drei Modi verwenden: `Cloud + Local` über einen erreichbaren Ollama-Host, `Cloud only` gegen `https://ollama.com` oder `Local only` gegen einen erreichbaren Ollama-Host. -**Benutzer von Remote-Ollama**: Verwenden Sie nicht die OpenAI-kompatible URL `/v1` (`http://host:11434/v1`) mit OpenClaw. Dadurch wird Tool-Calling beschädigt, und Modelle können rohes Tool-JSON als Klartext ausgeben. Verwenden Sie stattdessen die native Ollama-API-URL: `baseUrl: "http://host:11434"` (ohne `/v1`). +**Remote-Ollama-Benutzer**: Verwenden Sie die OpenAI-kompatible URL `/v1` (`http://host:11434/v1`) nicht mit OpenClaw. Das beeinträchtigt Tool-Aufrufe, und Modelle können rohe Tool-JSON als Klartext ausgeben. Verwenden Sie stattdessen die native Ollama-API-URL: `baseUrl: "http://host:11434"` (ohne `/v1`). ## Erste Schritte @@ -27,7 +27,7 @@ Wählen Sie Ihre bevorzugte Einrichtungsmethode und Ihren Modus. - **Am besten geeignet für:** den schnellsten Weg zu einer funktionierenden Ollama-Einrichtung mit automatischer Modellerkennung. + **Am besten geeignet für:** den schnellsten Weg zu einer funktionierenden Ollama-Cloud- oder lokalen Einrichtung. @@ -35,25 +35,24 @@ Wählen Sie Ihre bevorzugte Einrichtungsmethode und Ihren Modus. openclaw onboard ``` - Wählen Sie **Ollama** aus der Provider-Liste aus. + Wählen Sie **Ollama** aus der Anbieterliste aus. - - - **Cloud + Lokal** — Cloud-gehostete Modelle und lokale Modelle zusammen - - **Lokal** — nur lokale Modelle - - Wenn Sie **Cloud + Lokal** wählen und nicht bei ollama.com angemeldet sind, öffnet das Onboarding einen Browser-Anmeldefluss. + + - **Cloud + Local** — lokaler Ollama-Host plus Cloud-Modelle, die über diesen Host weitergeleitet werden + - **Cloud only** — gehostete Ollama-Modelle über `https://ollama.com` + - **Local only** — nur lokale Modelle - Das Onboarding erkennt verfügbare Modelle und schlägt Standardwerte vor. Es zieht das ausgewählte Modell automatisch, wenn es lokal nicht verfügbar ist. + `Cloud only` fordert `OLLAMA_API_KEY` an und schlägt gehostete Cloud-Standardwerte vor. `Cloud + Local` und `Local only` fragen nach einer Ollama-Basis-URL, erkennen verfügbare Modelle und laden das ausgewählte lokale Modell automatisch herunter, wenn es noch nicht verfügbar ist. `Cloud + Local` prüft außerdem, ob dieser Ollama-Host für den Cloud-Zugriff angemeldet ist. - + ```bash openclaw models list --provider ollama ``` - ### Nicht interaktiver Modus + ### Nicht-interaktiver Modus ```bash openclaw onboard --non-interactive \ @@ -74,37 +73,35 @@ Wählen Sie Ihre bevorzugte Einrichtungsmethode und Ihren Modus. - **Am besten geeignet für:** vollständige Kontrolle über Installation, Modell-Pulls und Konfiguration. + **Am besten geeignet für:** volle Kontrolle über die Cloud- oder lokale Einrichtung. - - Herunterladen von [ollama.com/download](https://ollama.com/download). + + - **Cloud + Local**: Ollama installieren, mit `ollama signin` anmelden und Cloud-Anfragen über diesen Host weiterleiten + - **Cloud only**: `https://ollama.com` mit einem `OLLAMA_API_KEY` verwenden + - **Local only**: Ollama von [ollama.com/download](https://ollama.com/download) installieren - + ```bash ollama pull gemma4 - # or + # oder ollama pull gpt-oss:20b - # or + # oder ollama pull llama3.3 ``` - - Wenn Sie auch Cloud-Modelle möchten: - - ```bash - ollama signin - ``` - - Setzen Sie einen beliebigen Wert für den API-Schlüssel (Ollama benötigt keinen echten Schlüssel): + Verwenden Sie für `Cloud only` Ihren echten `OLLAMA_API_KEY`. Für hostgestützte Setups funktioniert jeder Platzhalterwert: ```bash - # Set environment variable + # Cloud + export OLLAMA_API_KEY="your-ollama-api-key" + + # Nur lokal export OLLAMA_API_KEY="ollama-local" - # Or configure in your config file - openclaw config set models.providers.ollama.apiKey "ollama-local" + # Oder in Ihrer Konfigurationsdatei konfigurieren + openclaw config set models.providers.ollama.apiKey "OLLAMA_API_KEY" ``` @@ -113,7 +110,7 @@ Wählen Sie Ihre bevorzugte Einrichtungsmethode und Ihren Modus. openclaw models set ollama/gemma4 ``` - Oder den Standardwert in der Konfiguration setzen: + Oder den Standardwert in der Konfiguration festlegen: ```json5 { @@ -133,94 +130,99 @@ Wählen Sie Ihre bevorzugte Einrichtungsmethode und Ihren Modus. ## Cloud-Modelle - - Mit Cloud-Modellen können Sie Cloud-gehostete Modelle zusammen mit Ihren lokalen Modellen ausführen. Beispiele sind `kimi-k2.5:cloud`, `minimax-m2.7:cloud` und `glm-5.1:cloud` -- diese erfordern **kein** lokales `ollama pull`. + + `Cloud + Local` verwendet einen erreichbaren Ollama-Host als Steuerungspunkt sowohl für lokale als auch für Cloud-Modelle. Dies ist Ollamas bevorzugter Hybrid-Workflow. - Wählen Sie während der Einrichtung den Modus **Cloud + Lokal**. Der Assistent prüft, ob Sie angemeldet sind, und öffnet bei Bedarf einen Browser-Anmeldefluss. Wenn die Authentifizierung nicht verifiziert werden kann, fällt der Assistent auf Standardwerte für lokale Modelle zurück. + Verwenden Sie während der Einrichtung **Cloud + Local**. OpenClaw fragt nach der Ollama-Basis-URL, erkennt lokale Modelle von diesem Host und prüft, ob der Host mit `ollama signin` für den Cloud-Zugriff angemeldet ist. Wenn der Host angemeldet ist, schlägt OpenClaw auch gehostete Cloud-Standardwerte wie `kimi-k2.5:cloud`, `minimax-m2.7:cloud` und `glm-5.1:cloud` vor. - Sie können sich auch direkt unter [ollama.com/signin](https://ollama.com/signin) anmelden. - - OpenClaw schlägt derzeit diese Cloud-Standardwerte vor: `kimi-k2.5:cloud`, `minimax-m2.7:cloud`, `glm-5.1:cloud`. + Wenn der Host noch nicht angemeldet ist, behält OpenClaw die Einrichtung als nur lokal bei, bis Sie `ollama signin` ausführen. - - Im Modus „nur lokal“ erkennt OpenClaw Modelle von der lokalen Ollama-Instanz. Keine Cloud-Anmeldung erforderlich. + + `Cloud only` läuft gegen Ollamas gehostete API unter `https://ollama.com`. + + Verwenden Sie während der Einrichtung **Cloud only**. OpenClaw fordert `OLLAMA_API_KEY` an, setzt `baseUrl: "https://ollama.com"` und initialisiert die gehostete Cloud-Modellliste. Dieser Pfad erfordert **keinen** lokalen Ollama-Server und kein `ollama signin`. + + + + + Im Modus nur lokal erkennt OpenClaw Modelle von der konfigurierten Ollama-Instanz. Dieser Pfad ist für lokale oder selbstgehostete Ollama-Server gedacht. OpenClaw schlägt derzeit `gemma4` als lokalen Standardwert vor. -## Modellerkennung (impliziter Provider) +## Modellerkennung (impliziter Anbieter) -Wenn Sie `OLLAMA_API_KEY` (oder ein Auth-Profil) setzen und **nicht** `models.providers.ollama` definieren, erkennt OpenClaw Modelle von der lokalen Ollama-Instanz unter `http://127.0.0.1:11434`. +Wenn Sie `OLLAMA_API_KEY` (oder ein Auth-Profil) festlegen und **nicht** `models.providers.ollama` definieren, erkennt OpenClaw Modelle von der lokalen Ollama-Instanz unter `http://127.0.0.1:11434`. | Verhalten | Detail | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Katalogabfrage | Fragt `/api/tags` ab | -| Capability-Erkennung | Verwendet Best-Effort-Abfragen an `/api/show`, um `contextWindow` auszulesen und Capabilities zu erkennen (einschließlich Vision) | -| Vision-Modelle | Modelle mit einer von `/api/show` gemeldeten `vision`-Capability werden als bildfähig markiert (`input: ["text", "image"]`), sodass OpenClaw Bilder automatisch in den Prompt injiziert | -| Reasoning-Erkennung | Markiert `reasoning` mit einer Modellnamen-Heuristik (`r1`, `reasoning`, `think`) | -| Token-Limits | Setzt `maxTokens` auf die von OpenClaw verwendete Standardobergrenze für Ollama-Max-Token | +| Fähigkeitserkennung | Verwendet Best-Effort-Abfragen von `/api/show`, um `contextWindow` zu lesen und Fähigkeiten zu erkennen (einschließlich Vision) | +| Vision-Modelle | Modelle mit einer von `/api/show` gemeldeten `vision`-Fähigkeit werden als bildfähig markiert (`input: ["text", "image"]`), sodass OpenClaw Bilder automatisch in den Prompt einfügt | +| Reasoning-Erkennung | Markiert `reasoning` mit einer Modellnamens-Heuristik (`r1`, `reasoning`, `think`) | +| Token-Limits | Setzt `maxTokens` auf die von OpenClaw verwendete standardmäßige maximale Ollama-Token-Obergrenze | | Kosten | Setzt alle Kosten auf `0` | -Damit werden manuelle Modelleinträge vermieden, während der Katalog mit der lokalen Ollama-Instanz abgestimmt bleibt. +Dadurch werden manuelle Modeleinträge vermieden, während der Katalog mit der lokalen Ollama-Instanz abgestimmt bleibt. ```bash -# See what models are available +# Anzeigen, welche Modelle verfügbar sind ollama list openclaw models list ``` -Um ein neues Modell hinzuzufügen, ziehen Sie es einfach mit Ollama: +Um ein neues Modell hinzuzufügen, laden Sie es einfach mit Ollama herunter: ```bash ollama pull mistral ``` -Das neue Modell wird automatisch erkannt und steht zur Verwendung bereit. +Das neue Modell wird automatisch erkannt und steht zur Verfügung. -Wenn Sie `models.providers.ollama` explizit setzen, wird die automatische Erkennung übersprungen und Sie müssen Modelle manuell definieren. Siehe den Abschnitt zur expliziten Konfiguration unten. +Wenn Sie `models.providers.ollama` explizit festlegen, wird die automatische Erkennung übersprungen und Sie müssen Modelle manuell definieren. Siehe den Abschnitt zur expliziten Konfiguration unten. ## Konfiguration - Der einfachste Weg, Ollama zu aktivieren, ist über eine Umgebungsvariable: + Der einfachste Aktivierungspfad nur für lokal erfolgt über eine Umgebungsvariable: ```bash export OLLAMA_API_KEY="ollama-local" ``` - Wenn `OLLAMA_API_KEY` gesetzt ist, können Sie `apiKey` im Provider-Eintrag weglassen, und OpenClaw ergänzt ihn für Verfügbarkeitsprüfungen. + Wenn `OLLAMA_API_KEY` gesetzt ist, können Sie `apiKey` im Anbietereintrag weglassen, und OpenClaw ergänzt ihn für Verfügbarkeitsprüfungen. - Verwenden Sie eine explizite Konfiguration, wenn Ollama auf einem anderen Host/Port läuft, Sie bestimmte Kontextfenster oder Modelllisten erzwingen möchten oder vollständig manuelle Modelldefinitionen möchten. + Verwenden Sie eine explizite Konfiguration, wenn Sie ein gehostetes Cloud-Setup möchten, Ollama auf einem anderen Host/Port läuft, Sie bestimmte Kontextfenster oder Modelllisten erzwingen möchten oder vollständig manuelle Modelldefinitionen wünschen. ```json5 { models: { providers: { ollama: { - baseUrl: "http://ollama-host:11434", - apiKey: "ollama-local", + baseUrl: "https://ollama.com", + apiKey: "OLLAMA_API_KEY", api: "ollama", models: [ { - id: "gpt-oss:20b", - name: "GPT-OSS 20B", + id: "kimi-k2.5:cloud", + name: "kimi-k2.5:cloud", reasoning: false, - input: ["text"], + input: ["text", "image"], cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, - contextWindow: 8192, - maxTokens: 8192 * 10 + contextWindow: 128000, + maxTokens: 8192 } ] } @@ -232,7 +234,7 @@ Wenn Sie `models.providers.ollama` explizit setzen, wird die automatische Erkenn - Wenn Ollama auf einem anderen Host oder Port läuft (explizite Konfiguration deaktiviert die automatische Erkennung, daher Modelle manuell definieren): + Wenn Ollama auf einem anderen Host oder Port läuft (explizite Konfiguration deaktiviert die automatische Erkennung, daher müssen Modelle manuell definiert werden): ```json5 { @@ -240,8 +242,8 @@ Wenn Sie `models.providers.ollama` explizit setzen, wird die automatische Erkenn providers: { ollama: { apiKey: "ollama-local", - baseUrl: "http://ollama-host:11434", // No /v1 - use native Ollama API URL - api: "ollama", // Set explicitly to guarantee native tool-calling behavior + baseUrl: "http://ollama-host:11434", // Kein /v1 - native Ollama-API-URL verwenden + api: "ollama", // Explizit setzen, um natives Tool-Calling-Verhalten sicherzustellen }, }, }, @@ -249,7 +251,7 @@ Wenn Sie `models.providers.ollama` explizit setzen, wird die automatische Erkenn ``` - Fügen Sie der URL kein `/v1` hinzu. Der Pfad `/v1` verwendet den OpenAI-kompatiblen Modus, in dem Tool-Calling nicht zuverlässig ist. Verwenden Sie die Basis-Ollama-URL ohne Pfadsuffix. + Fügen Sie der URL kein `/v1` hinzu. Der Pfad `/v1` verwendet den OpenAI-kompatiblen Modus, in dem Tool-Aufrufe nicht zuverlässig sind. Verwenden Sie die Ollama-Basis-URL ohne Pfadsuffix. @@ -257,7 +259,7 @@ Wenn Sie `models.providers.ollama` explizit setzen, wird die automatische Erkenn ### Modellauswahl -Sobald die Konfiguration eingerichtet ist, sind alle Ihre Ollama-Modelle verfügbar: +Nach der Konfiguration sind alle Ihre Ollama-Modelle verfügbar: ```json5 { @@ -274,15 +276,15 @@ Sobald die Konfiguration eingerichtet ist, sind alle Ihre Ollama-Modelle verfüg ## Ollama Web Search -OpenClaw unterstützt **Ollama Web Search** als gebündelten `web_search`-Provider. +OpenClaw unterstützt **Ollama Web Search** als gebündelten `web_search`-Anbieter. -| Eigenschaft | Detail | -| ----------- | -------------------------------------------------------------------------------------------------------------------- | -| Host | Verwendet Ihren konfigurierten Ollama-Host (`models.providers.ollama.baseUrl`, falls gesetzt, andernfalls `http://127.0.0.1:11434`) | -| Auth | Ohne Schlüssel | -| Voraussetzung | Ollama muss laufen und Sie müssen mit `ollama signin` angemeldet sein | +| Eigenschaft | Detail | +| ----------- | ------------------------------------------------------------------------------------------------------------------- | +| Host | Verwendet Ihren konfigurierten Ollama-Host (`models.providers.ollama.baseUrl`, wenn gesetzt, andernfalls `http://127.0.0.1:11434`) | +| Auth | Ohne Schlüssel | +| Voraussetzung | Ollama muss laufen und mit `ollama signin` angemeldet sein | -Wählen Sie **Ollama Web Search** während `openclaw onboard` oder `openclaw configure --section web` oder setzen Sie: +Wählen Sie **Ollama Web Search** während `openclaw onboard` oder `openclaw configure --section web`, oder setzen Sie: ```json5 { @@ -297,15 +299,15 @@ Wählen Sie **Ollama Web Search** während `openclaw onboard` oder `openclaw con ``` -Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools/ollama-search). +Die vollständigen Details zur Einrichtung und zum Verhalten finden Sie unter [Ollama Web Search](/de/tools/ollama-search). ## Erweiterte Konfiguration - + - **Tool-Calling ist im OpenAI-kompatiblen Modus nicht zuverlässig.** Verwenden Sie diesen Modus nur, wenn Sie das OpenAI-Format für einen Proxy benötigen und nicht von nativem Tool-Calling-Verhalten abhängig sind. + **Tool-Aufrufe sind im OpenAI-kompatiblen Modus nicht zuverlässig.** Verwenden Sie diesen Modus nur, wenn Sie das OpenAI-Format für einen Proxy benötigen und nicht auf natives Tool-Calling-Verhalten angewiesen sind. Wenn Sie stattdessen den OpenAI-kompatiblen Endpunkt verwenden müssen (zum Beispiel hinter einem Proxy, der nur das OpenAI-Format unterstützt), setzen Sie `api: "openai-completions"` explizit: @@ -317,7 +319,7 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools ollama: { baseUrl: "http://ollama-host:11434/v1", api: "openai-completions", - injectNumCtxForOpenAICompat: true, // default: true + injectNumCtxForOpenAICompat: true, // Standard: true apiKey: "ollama-local", models: [...] } @@ -326,9 +328,9 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools } ``` - Dieser Modus unterstützt möglicherweise nicht gleichzeitig Streaming und Tool-Calling. Möglicherweise müssen Sie Streaming mit `params: { streaming: false }` in der Modellkonfiguration deaktivieren. + Dieser Modus unterstützt möglicherweise nicht gleichzeitig Streaming und Tool-Aufrufe. Möglicherweise müssen Sie Streaming mit `params: { streaming: false }` in der Modellkonfiguration deaktivieren. - Wenn `api: "openai-completions"` mit Ollama verwendet wird, injiziert OpenClaw standardmäßig `options.num_ctx`, damit Ollama nicht stillschweigend auf ein Kontextfenster von 4096 zurückfällt. Wenn Ihr Proxy/Upstream unbekannte Felder `options` ablehnt, deaktivieren Sie dieses Verhalten: + Wenn `api: "openai-completions"` mit Ollama verwendet wird, fügt OpenClaw standardmäßig `options.num_ctx` ein, damit Ollama nicht stillschweigend auf ein Kontextfenster von 4096 zurückfällt. Wenn Ihr Proxy/Upstream unbekannte `options`-Felder ablehnt, deaktivieren Sie dieses Verhalten: ```json5 { @@ -349,9 +351,9 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools - Für automatisch erkannte Modelle verwendet OpenClaw das von Ollama gemeldete Kontextfenster, wenn verfügbar; andernfalls fällt es auf das von OpenClaw verwendete Standard-Kontextfenster für Ollama zurück. + Bei automatisch erkannten Modellen verwendet OpenClaw das von Ollama gemeldete Kontextfenster, sofern verfügbar, andernfalls greift es auf das von OpenClaw verwendete Standard-Kontextfenster für Ollama zurück. - Sie können `contextWindow` und `maxTokens` in der expliziten Provider-Konfiguration überschreiben: + Sie können `contextWindow` und `maxTokens` in der expliziten Anbieterkonfiguration überschreiben: ```json5 { @@ -380,7 +382,7 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools ollama pull deepseek-r1:32b ``` - Es ist keine zusätzliche Konfiguration erforderlich -- OpenClaw markiert sie automatisch. + Keine zusätzliche Konfiguration erforderlich -- OpenClaw markiert sie automatisch. @@ -388,17 +390,17 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools Ollama ist kostenlos und läuft lokal, daher sind alle Modellkosten auf $0 gesetzt. Das gilt sowohl für automatisch erkannte als auch für manuell definierte Modelle. - - Das gebündelte Ollama-Plugin registriert einen Provider für Speicher-Embeddings für - [Memory Search](/de/concepts/memory). Er verwendet die konfigurierte Ollama-Basis-URL + + Das gebündelte Ollama-Plugin registriert einen Einbettungsanbieter für + [Speichersuche](/de/concepts/memory). Es verwendet die konfigurierte Ollama-Basis-URL und den API-Schlüssel. - | Eigenschaft | Wert | - | ------------- | ------------------- | - | Standardmodell | `nomic-embed-text` | - | Auto-Pull | Ja — das Embedding-Modell wird automatisch gezogen, wenn es lokal nicht vorhanden ist | + | Eigenschaft | Wert | + | -------------- | ------------------- | + | Standardmodell | `nomic-embed-text` | + | Auto-Pull | Ja — das Einbettungsmodell wird automatisch heruntergeladen, wenn es lokal nicht vorhanden ist | - Um Ollama als Embedding-Provider für Memory Search auszuwählen: + So wählen Sie Ollama als Einbettungsanbieter für die Speichersuche aus: ```json5 { @@ -413,10 +415,10 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools - Die Ollama-Integration von OpenClaw verwendet standardmäßig die **native Ollama-API** (`/api/chat`), die Streaming und Tool-Calling gleichzeitig vollständig unterstützt. Es ist keine besondere Konfiguration erforderlich. + Die Ollama-Integration von OpenClaw verwendet standardmäßig die **native Ollama-API** (`/api/chat`), die Streaming und Tool-Aufrufe gleichzeitig vollständig unterstützt. Es ist keine besondere Konfiguration erforderlich. - Wenn Sie den OpenAI-kompatiblen Endpunkt verwenden müssen, siehe oben im Abschnitt „Veralteter OpenAI-kompatibler Modus“. Streaming und Tool-Calling funktionieren in diesem Modus möglicherweise nicht gleichzeitig. + Wenn Sie den OpenAI-kompatiblen Endpunkt verwenden müssen, siehe den Abschnitt „Legacy OpenAI-kompatibler Modus“ oben. In diesem Modus funktionieren Streaming und Tool-Aufrufe möglicherweise nicht gleichzeitig. @@ -425,14 +427,14 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools ## Fehlerbehebung - - Stellen Sie sicher, dass Ollama läuft und dass Sie `OLLAMA_API_KEY` (oder ein Auth-Profil) gesetzt haben und **keinen** expliziten Eintrag `models.providers.ollama` definiert haben: + + Stellen Sie sicher, dass Ollama läuft, dass Sie `OLLAMA_API_KEY` (oder ein Auth-Profil) gesetzt haben und dass Sie **keinen** expliziten Eintrag `models.providers.ollama` definiert haben: ```bash ollama serve ``` - Prüfen Sie, ob die API erreichbar ist: + Überprüfen Sie, ob die API erreichbar ist: ```bash curl http://localhost:11434/api/tags @@ -441,13 +443,13 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools - Wenn Ihr Modell nicht aufgeführt ist, ziehen Sie das Modell entweder lokal oder definieren Sie es explizit in `models.providers.ollama`. + Wenn Ihr Modell nicht aufgeführt ist, laden Sie das Modell entweder lokal herunter oder definieren Sie es explizit in `models.providers.ollama`. ```bash - ollama list # See what's installed + ollama list # Anzeigen, was installiert ist ollama pull gemma4 ollama pull gpt-oss:20b - ollama pull llama3.3 # Or another model + ollama pull llama3.3 # Oder ein anderes Modell ``` @@ -456,10 +458,10 @@ Einrichtung und Verhaltensdetails finden Sie unter [Ollama Web Search](/de/tools Prüfen Sie, ob Ollama auf dem richtigen Port läuft: ```bash - # Check if Ollama is running + # Prüfen, ob Ollama läuft ps aux | grep ollama - # Or restart Ollama + # Oder Ollama neu starten ollama serve ``` @@ -473,14 +475,14 @@ Weitere Hilfe: [Fehlerbehebung](/de/help/troubleshooting) und [FAQ](/de/help/faq ## Verwandt - - Überblick über alle Provider, Modell-Referenzen und Failover-Verhalten. + + Überblick über alle Anbieter, Modellreferenzen und das Failover-Verhalten. - Wie Sie Modelle auswählen und konfigurieren. + So wählen und konfigurieren Sie Modelle. - Vollständige Einrichtungs- und Verhaltensdetails für Ollama-gestützte Websuche. + Vollständige Einrichtungs- und Verhaltensdetails für die von Ollama unterstützte Websuche. Vollständige Konfigurationsreferenz. diff --git a/docs/de/reference/memory-config.md b/docs/de/reference/memory-config.md index e7fcba58d..1b758a470 100644 --- a/docs/de/reference/memory-config.md +++ b/docs/de/reference/memory-config.md @@ -1,97 +1,99 @@ --- read_when: - - Sie möchten Provider für die Speichersuche oder Embedding-Modelle konfigurieren + - Sie möchten Anbieter für die Speicher-Suche oder Einbettungsmodelle konfigurieren - Sie möchten das QMD-Backend einrichten - - Sie möchten Hybridsuche, MMR oder zeitlichen Zerfall optimieren - - Sie möchten multimodale Speicherindizierung aktivieren -summary: Alle Konfigurationsoptionen für Memory-Suche, Embedding-Provider, QMD, Hybridsuche und multimodale Indizierung + - Sie möchten die hybride Suche, MMR oder den zeitlichen Zerfall optimieren + - Sie möchten die multimodale Speicherindizierung aktivieren +summary: Alle Konfigurationsoptionen für Speicher-Suche, Einbettungsanbieter, QMD, hybride Suche und multimodale Indizierung title: Referenz zur Speicherkonfiguration x-i18n: - generated_at: "2026-04-12T23:34:00Z" + generated_at: "2026-04-15T14:41:00Z" model: gpt-5.4 provider: openai - source_hash: 299ca9b69eea292ea557a2841232c637f5c1daf2bc0f73c0a42f7c0d8d566ce2 + source_hash: 334c3c4dac08e864487047d3822c75f96e9e7a97c38be4b4e0cd9e63c4489a53 source_path: reference/memory-config.md workflow: 15 --- # Referenz zur Speicherkonfiguration -Diese Seite listet alle Konfigurationsoptionen für die OpenClaw-Speichersuche auf. Für +Diese Seite listet alle Konfigurationsoptionen für die OpenClaw-Speicher-Suche auf. Für konzeptionelle Übersichten siehe: -- [Speicherüberblick](/de/concepts/memory) -- wie Speicher funktioniert -- [Builtin Engine](/de/concepts/memory-builtin) -- Standard-SQLite-Backend -- [QMD Engine](/de/concepts/memory-qmd) -- lokaler Sidecar mit lokalem Fokus -- [Speichersuche](/de/concepts/memory-search) -- Suchpipeline und Optimierung +- [Speicherübersicht](/de/concepts/memory) -- wie Speicher funktioniert +- [Integrierte Engine](/de/concepts/memory-builtin) -- Standard-SQLite-Backend +- [QMD-Engine](/de/concepts/memory-qmd) -- lokaler Sidecar mit Local-First-Ansatz +- [Speicher-Suche](/de/concepts/memory-search) -- Suchpipeline und Optimierung - [Active Memory](/de/concepts/active-memory) -- Aktivieren des Speicher-Sub-Agenten für interaktive Sitzungen -Alle Einstellungen für die Speichersuche befinden sich unter `agents.defaults.memorySearch` in +Alle Einstellungen für die Speicher-Suche befinden sich unter `agents.defaults.memorySearch` in `openclaw.json`, sofern nicht anders angegeben. -Wenn Sie nach dem Feature-Schalter für **Active Memory** und der Konfiguration des Sub-Agenten suchen, -finden Sie diese unter `plugins.entries.active-memory` statt unter `memorySearch`. +Wenn Sie nach dem **Active Memory**-Funktionsschalter und der Sub-Agent-Konfiguration suchen, +befinden sich diese unter `plugins.entries.active-memory` statt unter `memorySearch`. -Active Memory verwendet ein Modell mit zwei Gates: +Active Memory verwendet ein Modell mit zwei Voraussetzungen: -1. Das Plugin muss aktiviert sein und auf die aktuelle Agent-ID zielen -2. Die Anfrage muss eine geeignete interaktive persistente Chat-Sitzung sein +1. das Plugin muss aktiviert sein und auf die aktuelle Agent-ID zielen +2. die Anfrage muss eine geeignete interaktive persistente Chat-Sitzung sein Siehe [Active Memory](/de/concepts/active-memory) für das Aktivierungsmodell, -die Plugin-eigene Konfiguration, die Persistenz von Transkripten und ein sicheres Rollout-Muster. +die Plugin-eigene Konfiguration, die Transkriptpersistenz und ein sicheres Einführungsmodell. --- -## Providerauswahl +## Anbieterauswahl -| Schlüssel | Typ | Standard | Beschreibung | -| ---------- | --------- | ---------------- | -------------------------------------------------------------------------------------------- | -| `provider` | `string` | automatisch erkannt | Embedding-Adapter-ID: `openai`, `gemini`, `voyage`, `mistral`, `bedrock`, `ollama`, `local` | -| `model` | `string` | Provider-Standard | Name des Embedding-Modells | -| `fallback` | `string` | `"none"` | Fallback-Adapter-ID, wenn der primäre fehlschlägt | -| `enabled` | `boolean` | `true` | Speichersuche aktivieren oder deaktivieren | +| Schlüssel | Typ | Standard | Beschreibung | +| ---------- | --------- | ---------------- | ------------------------------------------------------------------------------------------------------------- | +| `provider` | `string` | automatisch erkannt | Einbettungsadapter-ID: `bedrock`, `gemini`, `github-copilot`, `local`, `mistral`, `ollama`, `openai`, `voyage` | +| `model` | `string` | Anbieterstandard | Name des Einbettungsmodells | +| `fallback` | `string` | `"none"` | Fallback-Adapter-ID, wenn der primäre Adapter fehlschlägt | +| `enabled` | `boolean` | `true` | Aktiviert oder deaktiviert die Speicher-Suche | ### Reihenfolge der automatischen Erkennung -Wenn `provider` nicht gesetzt ist, wählt OpenClaw den ersten verfügbaren: +Wenn `provider` nicht gesetzt ist, wählt OpenClaw den ersten verfügbaren Anbieter: 1. `local` -- wenn `memorySearch.local.modelPath` konfiguriert ist und die Datei existiert. -2. `openai` -- wenn ein OpenAI-Schlüssel aufgelöst werden kann. -3. `gemini` -- wenn ein Gemini-Schlüssel aufgelöst werden kann. -4. `voyage` -- wenn ein Voyage-Schlüssel aufgelöst werden kann. -5. `mistral` -- wenn ein Mistral-Schlüssel aufgelöst werden kann. -6. `bedrock` -- wenn die AWS-SDK-Credential-Chain aufgelöst wird (Instance Role, Access Keys, Profile, SSO, Web Identity oder Shared Config). +2. `github-copilot` -- wenn ein GitHub-Copilot-Token aufgelöst werden kann (Umgebungsvariable oder Auth-Profil). +3. `openai` -- wenn ein OpenAI-Schlüssel aufgelöst werden kann. +4. `gemini` -- wenn ein Gemini-Schlüssel aufgelöst werden kann. +5. `voyage` -- wenn ein Voyage-Schlüssel aufgelöst werden kann. +6. `mistral` -- wenn ein Mistral-Schlüssel aufgelöst werden kann. +7. `bedrock` -- wenn die AWS-SDK-Anmeldedatenkette aufgelöst wird (Instanzrolle, Zugriffsschlüssel, Profil, SSO, Web-Identität oder freigegebene Konfiguration). -`ollama` wird unterstützt, aber nicht automatisch erkannt (explizit setzen). +`ollama` wird unterstützt, aber nicht automatisch erkannt (setzen Sie es explizit). ### Auflösung von API-Schlüsseln -Remote-Embeddings erfordern einen API-Schlüssel. Bedrock verwendet stattdessen die -standardmäßige AWS-SDK-Credential-Chain (Instance Roles, SSO, Access Keys). +Remote-Einbettungen erfordern einen API-Schlüssel. Bedrock verwendet stattdessen die +Standard-Anmeldedatenkette des AWS SDK (Instanzrollen, SSO, Zugriffsschlüssel). -| Provider | Env-Variable | Konfigurationsschlüssel | -| -------- | ------------------------------ | -------------------------------- | -| OpenAI | `OPENAI_API_KEY` | `models.providers.openai.apiKey` | -| Gemini | `GEMINI_API_KEY` | `models.providers.google.apiKey` | -| Voyage | `VOYAGE_API_KEY` | `models.providers.voyage.apiKey` | -| Mistral | `MISTRAL_API_KEY` | `models.providers.mistral.apiKey` | -| Bedrock | AWS-Credential-Chain | Kein API-Schlüssel erforderlich | -| Ollama | `OLLAMA_API_KEY` (Platzhalter) | -- | +| Anbieter | Umgebungsvariable | Konfigurationsschlüssel | +| -------------- | ------------------------------------------------- | --------------------------------- | +| Bedrock | AWS-Anmeldedatenkette | Kein API-Schlüssel erforderlich | +| Gemini | `GEMINI_API_KEY` | `models.providers.google.apiKey` | +| GitHub Copilot | `COPILOT_GITHUB_TOKEN`, `GH_TOKEN`, `GITHUB_TOKEN` | Auth-Profil über Geräteanmeldung | +| Mistral | `MISTRAL_API_KEY` | `models.providers.mistral.apiKey` | +| Ollama | `OLLAMA_API_KEY` (Platzhalter) | -- | +| OpenAI | `OPENAI_API_KEY` | `models.providers.openai.apiKey` | +| Voyage | `VOYAGE_API_KEY` | `models.providers.voyage.apiKey` | -Codex OAuth gilt nur für Chat/Completions und erfüllt Embedding- -Anfragen nicht. +Codex OAuth deckt nur Chat/Completions ab und erfüllt keine Einbettungs- +anfragen. --- -## Konfiguration von Remote-Endpunkten +## Remote-Endpunktkonfiguration -Für benutzerdefinierte OpenAI-kompatible Endpunkte oder zum Überschreiben von Provider-Standards: +Für benutzerdefinierte OpenAI-kompatible Endpunkte oder zum Überschreiben von Anbieterstandards: -| Schlüssel | Typ | Beschreibung | -| ----------------- | -------- | --------------------------------------------- | -| `remote.baseUrl` | `string` | Benutzerdefinierte API-Basis-URL | -| `remote.apiKey` | `string` | API-Schlüssel überschreiben | -| `remote.headers` | `object` | Zusätzliche HTTP-Header (mit Provider-Standards zusammengeführt) | +| Schlüssel | Typ | Beschreibung | +| ----------------- | -------- | ------------------------------------------------- | +| `remote.baseUrl` | `string` | Benutzerdefinierte API-Basis-URL | +| `remote.apiKey` | `string` | API-Schlüssel überschreiben | +| `remote.headers` | `object` | Zusätzliche HTTP-Header (mit Anbieterstandards zusammengeführt) | ```json5 { @@ -114,22 +116,22 @@ Für benutzerdefinierte OpenAI-kompatible Endpunkte oder zum Überschreiben von ## Gemini-spezifische Konfiguration -| Schlüssel | Typ | Standard | Beschreibung | -| ----------------------- | -------- | ---------------------- | -------------------------------------------- | +| Schlüssel | Typ | Standard | Beschreibung | +| ----------------------- | -------- | ---------------------- | ------------------------------------------ | | `model` | `string` | `gemini-embedding-001` | Unterstützt auch `gemini-embedding-2-preview` | -| `outputDimensionality` | `number` | `3072` | Für Embedding 2: 768, 1536 oder 3072 | +| `outputDimensionality` | `number` | `3072` | Für Embedding 2: 768, 1536 oder 3072 | -Das Ändern von `model` oder `outputDimensionality` löst eine automatische vollständige Neuindizierung aus. +Das Ändern von Modell oder `outputDimensionality` löst automatisch eine vollständige Neuindizierung aus. --- -## Bedrock-Embedding-Konfiguration +## Bedrock-Einbettungskonfiguration -Bedrock verwendet die standardmäßige AWS-SDK-Credential-Chain -- keine API-Schlüssel erforderlich. -Wenn OpenClaw auf EC2 mit einer Bedrock-fähigen Instance Role läuft, setzen Sie einfach -Provider und Modell: +Bedrock verwendet die Standard-Anmeldedatenkette des AWS SDK -- keine API-Schlüssel erforderlich. +Wenn OpenClaw auf EC2 mit einer Bedrock-aktivierten Instanzrolle ausgeführt wird, setzen Sie einfach +Anbieter und Modell: ```json5 { @@ -144,44 +146,43 @@ Provider und Modell: } ``` -| Schlüssel | Typ | Standard | Beschreibung | -| ----------------------- | -------- | ---------------------------- | ------------------------------- | -| `model` | `string` | `amazon.titan-embed-text-v2:0` | Beliebige Bedrock-Embedding-Modell-ID | -| `outputDimensionality` | `number` | Modellstandard | Für Titan V2: 256, 512 oder 1024 | +| Schlüssel | Typ | Standard | Beschreibung | +| ----------------------- | -------- | ------------------------------ | ------------------------------- | +| `model` | `string` | `amazon.titan-embed-text-v2:0` | Beliebige Bedrock-Einbettungsmodell-ID | +| `outputDimensionality` | `number` | Modellstandard | Für Titan V2: 256, 512 oder 1024 | ### Unterstützte Modelle -Die folgenden Modelle werden unterstützt (mit Familienerkennung und Standardwerten -für Dimensionen): +Die folgenden Modelle werden unterstützt (mit Familienerkennung und Standarddimensionen): -| Modell-ID | Provider | Standard-Dimensionen | Konfigurierbare Dimensionen | -| ------------------------------------------ | ---------- | -------------------- | --------------------------- | -| `amazon.titan-embed-text-v2:0` | Amazon | 1024 | 256, 512, 1024 | -| `amazon.titan-embed-text-v1` | Amazon | 1536 | -- | -| `amazon.titan-embed-g1-text-02` | Amazon | 1536 | -- | -| `amazon.titan-embed-image-v1` | Amazon | 1024 | -- | -| `amazon.nova-2-multimodal-embeddings-v1:0` | Amazon | 1024 | 256, 384, 1024, 3072 | -| `cohere.embed-english-v3` | Cohere | 1024 | -- | -| `cohere.embed-multilingual-v3` | Cohere | 1024 | -- | -| `cohere.embed-v4:0` | Cohere | 1536 | 256-1536 | -| `twelvelabs.marengo-embed-3-0-v1:0` | TwelveLabs | 512 | -- | -| `twelvelabs.marengo-embed-2-7-v1:0` | TwelveLabs | 1024 | -- | +| Modell-ID | Anbieter | Standard-Dims | Konfigurierbare Dims | +| ------------------------------------------ | ---------- | ------------- | -------------------- | +| `amazon.titan-embed-text-v2:0` | Amazon | 1024 | 256, 512, 1024 | +| `amazon.titan-embed-text-v1` | Amazon | 1536 | -- | +| `amazon.titan-embed-g1-text-02` | Amazon | 1536 | -- | +| `amazon.titan-embed-image-v1` | Amazon | 1024 | -- | +| `amazon.nova-2-multimodal-embeddings-v1:0` | Amazon | 1024 | 256, 384, 1024, 3072 | +| `cohere.embed-english-v3` | Cohere | 1024 | -- | +| `cohere.embed-multilingual-v3` | Cohere | 1024 | -- | +| `cohere.embed-v4:0` | Cohere | 1536 | 256-1536 | +| `twelvelabs.marengo-embed-3-0-v1:0` | TwelveLabs | 512 | -- | +| `twelvelabs.marengo-embed-2-7-v1:0` | TwelveLabs | 1024 | -- | Varianten mit Durchsatzsuffix (z. B. `amazon.titan-embed-text-v1:2:8k`) übernehmen die Konfiguration des Basismodells. ### Authentifizierung -Bedrock-Auth verwendet die standardmäßige Reihenfolge der AWS-SDK-Credential-Auflösung: +Die Bedrock-Authentifizierung verwendet die Standardreihenfolge zur Auflösung von AWS-SDK-Anmeldedaten: 1. Umgebungsvariablen (`AWS_ACCESS_KEY_ID` + `AWS_SECRET_ACCESS_KEY`) 2. SSO-Token-Cache -3. Credentials über Web-Identity-Token -4. Gemeinsame Credentials- und Konfigurationsdateien -5. ECS- oder EC2-Metadaten-Credentials +3. Anmeldedaten für Web-Identitätstoken +4. Freigegebene Anmeldedaten- und Konfigurationsdateien +5. ECS- oder EC2-Metadaten-Anmeldedaten -Die Region wird aus `AWS_REGION`, `AWS_DEFAULT_REGION`, der -`amazon-bedrock`-`baseUrl` des Providers ermittelt oder fällt standardmäßig auf `us-east-1` zurück. +Die Region wird aus `AWS_REGION`, `AWS_DEFAULT_REGION`, der `baseUrl` des +Anbieters `amazon-bedrock` aufgelöst oder standardmäßig auf `us-east-1` gesetzt. ### IAM-Berechtigungen @@ -195,7 +196,7 @@ Die IAM-Rolle oder der IAM-Benutzer benötigt: } ``` -Für Least-Privilege beschränken Sie `InvokeModel` auf das konkrete Modell: +Für Least-Privilege beschränken Sie `InvokeModel` auf das jeweilige Modell: ``` arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0 @@ -203,44 +204,44 @@ arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0 --- -## Konfiguration lokaler Embeddings +## Lokale Einbettungskonfiguration | Schlüssel | Typ | Standard | Beschreibung | | ---------------------- | -------- | ---------------------- | ------------------------------- | -| `local.modelPath` | `string` | automatisch heruntergeladen | Pfad zur GGUF-Modelldatei | -| `local.modelCacheDir` | `string` | `node-llama-cpp`-Standard | Cache-Verzeichnis für heruntergeladene Modelle | +| `local.modelPath` | `string` | automatisch heruntergeladen | Pfad zur GGUF-Modelldatei | +| `local.modelCacheDir` | `string` | node-llama-cpp-Standard | Cache-Verzeichnis für heruntergeladene Modelle | Standardmodell: `embeddinggemma-300m-qat-Q8_0.gguf` (~0,6 GB, wird automatisch heruntergeladen). -Erfordert einen nativen Build: `pnpm approve-builds` und dann `pnpm rebuild node-llama-cpp`. +Erfordert nativen Build: `pnpm approve-builds` und dann `pnpm rebuild node-llama-cpp`. --- -## Konfiguration der Hybridsuche +## Konfiguration der hybriden Suche Alles unter `memorySearch.query.hybrid`: -| Schlüssel | Typ | Standard | Beschreibung | -| ---------------------- | --------- | -------- | ------------------------------------ | -| `enabled` | `boolean` | `true` | Hybride BM25- + Vektorsuche aktivieren | -| `vectorWeight` | `number` | `0.7` | Gewicht für Vektor-Scores (0-1) | -| `textWeight` | `number` | `0.3` | Gewicht für BM25-Scores (0-1) | +| Schlüssel | Typ | Standard | Beschreibung | +| ---------------------- | --------- | -------- | ---------------------------------- | +| `enabled` | `boolean` | `true` | Hybride BM25- und Vektorsuche aktivieren | +| `vectorWeight` | `number` | `0.7` | Gewichtung für Vektorscores (0-1) | +| `textWeight` | `number` | `0.3` | Gewichtung für BM25-Scores (0-1) | | `candidateMultiplier` | `number` | `4` | Multiplikator für die Größe des Kandidatenpools | ### MMR (Diversität) -| Schlüssel | Typ | Standard | Beschreibung | -| -------------- | --------- | -------- | ---------------------------------------- | -| `mmr.enabled` | `boolean` | `false` | MMR-Re-Ranking aktivieren | +| Schlüssel | Typ | Standard | Beschreibung | +| -------------- | --------- | -------- | --------------------------------------- | +| `mmr.enabled` | `boolean` | `false` | MMR-Neu-Ranking aktivieren | | `mmr.lambda` | `number` | `0.7` | 0 = maximale Diversität, 1 = maximale Relevanz | ### Zeitlicher Zerfall (Aktualität) -| Schlüssel | Typ | Standard | Beschreibung | -| ----------------------------- | --------- | -------- | -------------------------------- | -| `temporalDecay.enabled` | `boolean` | `false` | Aktualitäts-Boost aktivieren | -| `temporalDecay.halfLifeDays` | `number` | `30` | Score halbiert sich alle N Tage | +| Schlüssel | Typ | Standard | Beschreibung | +| ----------------------------- | --------- | -------- | ------------------------------- | +| `temporalDecay.enabled` | `boolean` | `false` | Aktualitäts-Boost aktivieren | +| `temporalDecay.halfLifeDays` | `number` | `30` | Score halbiert sich alle N Tage | -Immergrüne Dateien (`MEMORY.md`, nicht datierte Dateien in `memory/`) unterliegen nie einem Zerfall. +Evergreen-Dateien (`MEMORY.md`, nicht datierte Dateien in `memory/`) unterliegen nie einem Zerfall. ### Vollständiges Beispiel @@ -267,9 +268,9 @@ Immergrüne Dateien (`MEMORY.md`, nicht datierte Dateien in `memory/`) unterlieg ## Zusätzliche Speicherpfade -| Schlüssel | Typ | Beschreibung | -| ----------- | ---------- | --------------------------------------------- | -| `extraPaths` | `string[]` | Zusätzliche Verzeichnisse oder Dateien zur Indizierung | +| Schlüssel | Typ | Beschreibung | +| ----------- | ---------- | ----------------------------------------- | +| `extraPaths`| `string[]` | Zusätzliche Verzeichnisse oder Dateien zur Indizierung | ```json5 { @@ -284,18 +285,18 @@ Immergrüne Dateien (`MEMORY.md`, nicht datierte Dateien in `memory/`) unterlieg ``` Pfade können absolut oder relativ zum Workspace sein. Verzeichnisse werden -rekursiv nach `.md`-Dateien durchsucht. Die Behandlung von Symlinks hängt vom aktiven Backend ab: -Die Builtin Engine ignoriert Symlinks, während QMD dem Verhalten des zugrunde liegenden QMD- -Scanners folgt. +rekursiv nach `.md`-Dateien durchsucht. Die Behandlung symbolischer Links hängt +vom aktiven Backend ab: Die integrierte Engine ignoriert symbolische Links, während QMD +dem Verhalten des zugrunde liegenden QMD-Scanners folgt. -Für agentenspezifische agentenübergreifende Transkriptsuche verwenden Sie +Für agentenbezogene agentenübergreifende Transkriptsuche verwenden Sie `agents.list[].memorySearch.qmd.extraCollections` statt `memory.qmd.paths`. -Diese zusätzlichen Collections folgen derselben Form `{ path, name, pattern? }`, werden jedoch +Diese zusätzlichen Collections verwenden dieselbe Form `{ path, name, pattern? }`, werden jedoch pro Agent zusammengeführt und können explizite gemeinsame Namen beibehalten, wenn der Pfad außerhalb des aktuellen Workspace liegt. Wenn derselbe aufgelöste Pfad sowohl in `memory.qmd.paths` als auch in -`memorySearch.qmd.extraCollections` erscheint, behält QMD den ersten Eintrag und überspringt das -Duplikat. +`memorySearch.qmd.extraCollections` erscheint, behält QMD den ersten Eintrag bei und überspringt +das Duplikat. --- @@ -303,13 +304,13 @@ Duplikat. Indizieren Sie Bilder und Audio zusammen mit Markdown mit Gemini Embedding 2: -| Schlüssel | Typ | Standard | Beschreibung | -| --------------------------- | ---------- | ---------- | -------------------------------------- | -| `multimodal.enabled` | `boolean` | `false` | Multimodale Indizierung aktivieren | -| `multimodal.modalities` | `string[]` | -- | `["image"]`, `["audio"]` oder `["all"]` | -| `multimodal.maxFileBytes` | `number` | `10000000` | Maximale Dateigröße für die Indizierung | +| Schlüssel | Typ | Standard | Beschreibung | +| -------------------------- | ---------- | ---------- | ------------------------------------- | +| `multimodal.enabled` | `boolean` | `false` | Multimodale Indizierung aktivieren | +| `multimodal.modalities` | `string[]` | -- | `["image"]`, `["audio"]` oder `["all"]` | +| `multimodal.maxFileBytes` | `number` | `10000000` | Maximale Dateigröße für die Indizierung | -Gilt nur für Dateien in `extraPaths`. Standard-Speicher-Roots bleiben nur für Markdown. +Gilt nur für Dateien in `extraPaths`. Standard-Speicherwurzeln bleiben auf Markdown beschränkt. Erfordert `gemini-embedding-2-preview`. `fallback` muss `"none"` sein. Unterstützte Formate: `.jpg`, `.jpeg`, `.png`, `.webp`, `.gif`, `.heic`, `.heif` @@ -317,66 +318,67 @@ Unterstützte Formate: `.jpg`, `.jpeg`, `.png`, `.webp`, `.gif`, `.heic`, `.heif --- -## Embedding-Cache +## Einbettungs-Cache | Schlüssel | Typ | Standard | Beschreibung | | ------------------- | --------- | -------- | ------------------------------------ | -| `cache.enabled` | `boolean` | `false` | Chunk-Embeddings in SQLite cachen | -| `cache.maxEntries` | `number` | `50000` | Maximale Anzahl gecachter Embeddings | +| `cache.enabled` | `boolean` | `false` | Chunk-Einbettungen in SQLite cachen | +| `cache.maxEntries` | `number` | `50000` | Maximale Anzahl zwischengespeicherter Einbettungen | -Verhindert das erneute Erzeugen von Embeddings für unveränderten Text bei Neuindizierung oder Transkript-Updates. +Verhindert die erneute Einbettung unveränderten Texts bei Neuindizierung oder Transkriptaktualisierungen. --- ## Batch-Indizierung -| Schlüssel | Typ | Standard | Beschreibung | -| ---------------------------- | --------- | -------- | ------------------------------ | -| `remote.batch.enabled` | `boolean` | `false` | Batch-Embedding-API aktivieren | -| `remote.batch.concurrency` | `number` | `2` | Parallele Batch-Jobs | -| `remote.batch.wait` | `boolean` | `true` | Auf Abschluss des Batch warten | -| `remote.batch.pollIntervalMs`| `number` | -- | Polling-Intervall | -| `remote.batch.timeoutMinutes`| `number` | -- | Batch-Timeout | +| Schlüssel | Typ | Standard | Beschreibung | +| ------------------------------ | --------- | -------- | --------------------------- | +| `remote.batch.enabled` | `boolean` | `false` | Batch-Einbettungs-API aktivieren | +| `remote.batch.concurrency` | `number` | `2` | Parallele Batch-Jobs | +| `remote.batch.wait` | `boolean` | `true` | Auf Batch-Abschluss warten | +| `remote.batch.pollIntervalMs` | `number` | -- | Abfrageintervall | +| `remote.batch.timeoutMinutes` | `number` | -- | Batch-Timeout | -Verfügbar für `openai`, `gemini` und `voyage`. OpenAI-Batches sind in der Regel -am schnellsten und günstigsten für große Backfills. +Verfügbar für `openai`, `gemini` und `voyage`. OpenAI-Batches sind für große Backfills in der Regel +am schnellsten und kostengünstigsten. --- -## Sitzungs-Speichersuche (experimentell) +## Sitzungs-Speicher-Suche (experimentell) -Indizieren Sie Sitzungs-Transkripte und stellen Sie sie über `memory_search` bereit: +Indiziert Sitzungsprotokolle und stellt sie über `memory_search` bereit: -| Schlüssel | Typ | Standard | Beschreibung | -| ---------------------------- | ---------- | ------------- | ----------------------------------------- | -| `experimental.sessionMemory` | `boolean` | `false` | Sitzungsindizierung aktivieren | -| `sources` | `string[]` | `["memory"]` | `"sessions"` hinzufügen, um Transkripte einzubeziehen | -| `sync.sessions.deltaBytes` | `number` | `100000` | Byte-Schwelle für Neuindizierung | -| `sync.sessions.deltaMessages`| `number` | `50` | Nachrichten-Schwelle für Neuindizierung | +| Schlüssel | Typ | Standard | Beschreibung | +| ---------------------------- | ---------- | ------------ | ----------------------------------------- | +| `experimental.sessionMemory` | `boolean` | `false` | Sitzungsindizierung aktivieren | +| `sources` | `string[]` | `["memory"]` | `"sessions"` hinzufügen, um Transkripte einzuschließen | +| `sync.sessions.deltaBytes` | `number` | `100000` | Byte-Schwellenwert für Neuindizierung | +| `sync.sessions.deltaMessages`| `number` | `50` | Nachrichten-Schwellenwert für Neuindizierung | -Die Sitzungsindizierung ist Opt-in und läuft asynchron. Ergebnisse können leicht -veraltet sein. Sitzungslogs liegen auf dem Datenträger, daher sollte der Dateisystemzugriff als Vertrauensgrenze betrachtet werden. +Die Sitzungsindizierung ist optional und läuft asynchron. Ergebnisse können leicht +veraltet sein. Sitzungsprotokolle werden auf der Festplatte gespeichert, daher sollte der Dateisystemzugriff als Vertrauensgrenze +behandelt werden. --- -## SQLite-Vektorbeschleunigung (`sqlite-vec`) +## SQLite-Vektorbeschleunigung (sqlite-vec) -| Schlüssel | Typ | Standard | Beschreibung | -| ----------------------------- | --------- | -------- | ------------------------------------- | -| `store.vector.enabled` | `boolean` | `true` | `sqlite-vec` für Vektorabfragen verwenden | -| `store.vector.extensionPath` | `string` | gebündelt | Pfad zu `sqlite-vec` überschreiben | +| Schlüssel | Typ | Standard | Beschreibung | +| ----------------------------- | --------- | -------- | ----------------------------------- | +| `store.vector.enabled` | `boolean` | `true` | sqlite-vec für Vektorabfragen verwenden | +| `store.vector.extensionPath` | `string` | gebündelt | sqlite-vec-Pfad überschreiben | -Wenn `sqlite-vec` nicht verfügbar ist, fällt OpenClaw automatisch auf In-Process-Kosinus- -Ähnlichkeit zurück. +Wenn sqlite-vec nicht verfügbar ist, fällt OpenClaw automatisch auf Cosinus- +ähnlichkeit im Prozess zurück. --- -## Indexspeicherung +## Indexspeicher -| Schlüssel | Typ | Standard | Beschreibung | -| ---------------------- | -------- | ------------------------------------- | --------------------------------------------- | -| `store.path` | `string` | `~/.openclaw/memory/{agentId}.sqlite` | Speicherort des Index (unterstützt Token `{agentId}`) | -| `store.fts.tokenizer` | `string` | `unicode61` | FTS5-Tokenizer (`unicode61` oder `trigram`) | +| Schlüssel | Typ | Standard | Beschreibung | +| -------------------- | -------- | ------------------------------------- | --------------------------------------------- | +| `store.path` | `string` | `~/.openclaw/memory/{agentId}.sqlite` | Speicherort des Indexes (unterstützt Token `{agentId}`) | +| `store.fts.tokenizer`| `string` | `unicode61` | FTS5-Tokenizer (`unicode61` oder `trigram`) | --- @@ -385,50 +387,50 @@ Wenn `sqlite-vec` nicht verfügbar ist, fällt OpenClaw automatisch auf In-Proce Setzen Sie `memory.backend = "qmd"`, um es zu aktivieren. Alle QMD-Einstellungen befinden sich unter `memory.qmd`: -| Schlüssel | Typ | Standard | Beschreibung | -| ------------------------- | --------- | -------- | --------------------------------------------- | -| `command` | `string` | `qmd` | Pfad zur QMD-Executable | -| `searchMode` | `string` | `search` | Suchbefehl: `search`, `vsearch`, `query` | -| `includeDefaultMemory` | `boolean` | `true` | `MEMORY.md` + `memory/**/*.md` automatisch indizieren | -| `paths[]` | `array` | -- | Zusätzliche Pfade: `{ name, path, pattern? }` | -| `sessions.enabled` | `boolean` | `false` | Sitzungs-Transkripte indizieren | -| `sessions.retentionDays` | `number` | -- | Aufbewahrung von Transkripten | -| `sessions.exportDir` | `string` | -- | Exportverzeichnis | +| Schlüssel | Typ | Standard | Beschreibung | +| ----------------------- | --------- | -------- | -------------------------------------------- | +| `command` | `string` | `qmd` | Pfad zur QMD-Executable | +| `searchMode` | `string` | `search` | Suchbefehl: `search`, `vsearch`, `query` | +| `includeDefaultMemory` | `boolean` | `true` | `MEMORY.md` + `memory/**/*.md` automatisch indizieren | +| `paths[]` | `array` | -- | Zusätzliche Pfade: `{ name, path, pattern? }` | +| `sessions.enabled` | `boolean` | `false` | Sitzungsprotokolle indizieren | +| `sessions.retentionDays`| `number` | -- | Aufbewahrung von Transkripten | +| `sessions.exportDir` | `string` | -- | Exportverzeichnis | -OpenClaw bevorzugt die aktuellen QMD-Collection- und MCP-Abfrageformen, hält -aber ältere QMD-Releases funktionsfähig, indem bei Bedarf auf veraltete `--mask`-Collection-Flags -und ältere MCP-Tool-Namen zurückgefallen wird. +OpenClaw bevorzugt die aktuellen Formen für QMD-Collections und MCP-Abfragen, hält jedoch +ältere QMD-Versionen funktionsfähig, indem bei Bedarf auf Legacy-Collection-Flags `--mask` +und ältere MCP-Toolnamen zurückgegriffen wird. -QMD-Modell-Overrides bleiben auf der QMD-Seite, nicht in der OpenClaw-Konfiguration. Wenn Sie +QMD-Modellüberschreibungen bleiben auf der QMD-Seite, nicht in der OpenClaw-Konfiguration. Wenn Sie QMD-Modelle global überschreiben müssen, setzen Sie Umgebungsvariablen wie `QMD_EMBED_MODEL`, `QMD_RERANK_MODEL` und `QMD_GENERATE_MODEL` in der Gateway- Laufzeitumgebung. -### Update-Zeitplan +### Aktualisierungsplan -| Schlüssel | Typ | Standard | Beschreibung | -| -------------------------- | --------- | -------- | ----------------------------------------- | -| `update.interval` | `string` | `5m` | Aktualisierungsintervall | -| `update.debounceMs` | `number` | `15000` | Entprellung für Dateiveränderungen | -| `update.onBoot` | `boolean` | `true` | Beim Start aktualisieren | +| Schlüssel | Typ | Standard | Beschreibung | +| -------------------------- | --------- | -------- | ------------------------------------------ | +| `update.interval` | `string` | `5m` | Aktualisierungsintervall | +| `update.debounceMs` | `number` | `15000` | Entprellung für Dateiänderungen | +| `update.onBoot` | `boolean` | `true` | Beim Start aktualisieren | | `update.waitForBootSync` | `boolean` | `false` | Start blockieren, bis Aktualisierung abgeschlossen ist | -| `update.embedInterval` | `string` | -- | Separate Embedding-Taktung | -| `update.commandTimeoutMs` | `number` | -- | Timeout für QMD-Befehle | -| `update.updateTimeoutMs` | `number` | -- | Timeout für QMD-Update-Vorgänge | -| `update.embedTimeoutMs` | `number` | -- | Timeout für QMD-Embedding-Vorgänge | +| `update.embedInterval` | `string` | -- | Separater Einbettungstakt | +| `update.commandTimeoutMs` | `number` | -- | Timeout für QMD-Befehle | +| `update.updateTimeoutMs` | `number` | -- | Timeout für QMD-Aktualisierungsvorgänge | +| `update.embedTimeoutMs` | `number` | -- | Timeout für QMD-Einbettungsvorgänge | -### Limits +### Grenzen -| Schlüssel | Typ | Standard | Beschreibung | -| -------------------------- | -------- | -------- | ------------------------------- | -| `limits.maxResults` | `number` | `6` | Maximale Suchergebnisse | -| `limits.maxSnippetChars` | `number` | -- | Snippet-Länge begrenzen | -| `limits.maxInjectedChars` | `number` | -- | Insgesamt eingefügte Zeichen begrenzen | -| `limits.timeoutMs` | `number` | `4000` | Such-Timeout | +| Schlüssel | Typ | Standard | Beschreibung | +| -------------------------- | -------- | -------- | --------------------------------- | +| `limits.maxResults` | `number` | `6` | Maximale Suchergebnisse | +| `limits.maxSnippetChars` | `number` | -- | Snippet-Länge begrenzen | +| `limits.maxInjectedChars` | `number` | -- | Gesamte eingefügte Zeichen begrenzen | +| `limits.timeoutMs` | `number` | `4000` | Such-Timeout | ### Geltungsbereich -Steuert, welche Sitzungen QMD-Suchergebnisse erhalten können. Gleiches Schema wie +Steuert, welche Sitzungen QMD-Suchergebnisse empfangen können. Gleiches Schema wie [`session.sendPolicy`](/de/gateway/configuration-reference#session): ```json5 @@ -444,19 +446,19 @@ Steuert, welche Sitzungen QMD-Suchergebnisse erhalten können. Gleiches Schema w } ``` -Der mitgelieferte Standard erlaubt direkte Sitzungen und Kanalsitzungen, verweigert aber weiterhin +Der mitgelieferte Standard erlaubt Direkt- und Kanalsitzungen, verweigert aber weiterhin Gruppen. -Standard ist nur DM. `match.keyPrefix` vergleicht mit dem normalisierten Sitzungsschlüssel; -`match.rawKeyPrefix` mit dem rohen Schlüssel einschließlich `agent::`. +Standard ist nur DM. `match.keyPrefix` gleicht den normalisierten Sitzungsschlüssel ab; +`match.rawKeyPrefix` gleicht den rohen Schlüssel einschließlich `agent::` ab. -### Zitate +### Quellenangaben `memory.citations` gilt für alle Backends: | Wert | Verhalten | | ---------------- | --------------------------------------------------- | -| `auto` (Standard) | `Source: `-Fußzeile in Snippets einfügen | +| `auto` (Standard)| Fußzeile `Source: ` in Snippets einfügen | | `on` | Fußzeile immer einfügen | | `off` | Fußzeile weglassen (Pfad wird intern weiterhin an den Agenten übergeben) | @@ -483,22 +485,22 @@ Standard ist nur DM. `match.keyPrefix` vergleicht mit dem normalisierten Sitzung --- -## Dreaming (experimentell) +## Dreaming Dreaming wird unter `plugins.entries.memory-core.config.dreaming` konfiguriert, nicht unter `agents.defaults.memorySearch`. -Dreaming läuft als ein geplanter Sweep und verwendet interne Light-/Deep-/REM-Phasen als +Dreaming läuft als ein geplanter Durchlauf und verwendet interne Light-/Deep-/REM-Phasen als Implementierungsdetail. -Für konzeptionelles Verhalten und Slash-Befehle siehe [Dreaming](/de/concepts/dreaming). +Zum konzeptionellen Verhalten und zu Slash-Befehlen siehe [Dreaming](/de/concepts/dreaming). ### Benutzereinstellungen -| Schlüssel | Typ | Standard | Beschreibung | -| ------------ | --------- | ------------- | ------------------------------------------------- | -| `enabled` | `boolean` | `false` | Dreaming vollständig aktivieren oder deaktivieren | -| `frequency` | `string` | `0 3 * * *` | Optionaler Cron-Takt für den vollständigen Dreaming-Sweep | +| Schlüssel | Typ | Standard | Beschreibung | +| ------------ | --------- | ----------- | ------------------------------------------------- | +| `enabled` | `boolean` | `false` | Dreaming vollständig aktivieren oder deaktivieren | +| `frequency` | `string` | `0 3 * * *` | Optionaler Cron-Takt für den vollständigen Dreaming-Durchlauf | ### Beispiel @@ -521,6 +523,6 @@ Für konzeptionelles Verhalten und Slash-Befehle siehe [Dreaming](/de/concepts/d Hinweise: -- Dreaming schreibt Maschinenstatus nach `memory/.dreams/`. -- Dreaming schreibt menschenlesbare narrative Ausgabe nach `DREAMS.md` (oder in eine vorhandene `dreams.md`). -- Die Richtlinien und Schwellenwerte für Light-/Deep-/REM-Phasen sind internes Verhalten, keine benutzerseitige Konfiguration. +- Dreaming schreibt Maschinenzustand nach `memory/.dreams/`. +- Dreaming schreibt menschenlesbare narrative Ausgabe nach `DREAMS.md` (oder in vorhandene `dreams.md`). +- Die Richtlinie und Schwellenwerte für Light-/Deep-/REM-Phasen sind internes Verhalten, keine benutzerseitige Konfiguration. diff --git a/docs/de/reference/wizard.md b/docs/de/reference/wizard.md index d465bf67a..73bd0218f 100644 --- a/docs/de/reference/wizard.md +++ b/docs/de/reference/wizard.md @@ -1,16 +1,16 @@ --- read_when: - - Einen bestimmten Onboarding-Schritt oder ein bestimmtes Flag nachschlagen - - Onboarding mit dem nicht interaktiven Modus automatisieren + - Nach einem bestimmten Onboarding-Schritt oder Flag suchen + - Onboarding mit dem nicht-interaktiven Modus automatisieren - Onboarding-Verhalten debuggen sidebarTitle: Onboarding Reference -summary: 'Vollständige Referenz für CLI-Onboarding: jeder Schritt, jedes Flag und jedes Konfigurationsfeld' +summary: 'Vollständige Referenz für das CLI-Onboarding: jeder Schritt, jedes Flag und jedes Konfigurationsfeld' title: Onboarding-Referenz x-i18n: - generated_at: "2026-04-07T06:19:53Z" + generated_at: "2026-04-15T14:40:54Z" model: gpt-5.4 provider: openai - source_hash: a142b9ec4323fabb9982d05b64375d2b4a4007dffc910acbee3a38ff871a7236 + source_hash: 1db3ff789422617634e6624f9d12c18b6a6c573721226b9c0fa6f6b7956ef33d source_path: reference/wizard.md workflow: 15 --- @@ -24,77 +24,76 @@ Eine allgemeine Übersicht finden Sie unter [Onboarding (CLI)](/de/start/wizard) - - Wenn `~/.openclaw/openclaw.json` vorhanden ist, wählen Sie **Keep / Modify / Reset**. - - Ein erneutes Ausführen des Onboardings löscht nichts, außer Sie wählen ausdrücklich **Reset** + - Wenn `~/.openclaw/openclaw.json` vorhanden ist, wählen Sie **Behalten / Ändern / Zurücksetzen**. + - Das erneute Ausführen des Onboardings löscht **nichts**, es sei denn, Sie wählen ausdrücklich **Zurücksetzen** (oder übergeben `--reset`). - CLI-`--reset` verwendet standardmäßig `config+creds+sessions`; verwenden Sie `--reset-scope full`, um zusätzlich den Workspace zu entfernen. - Wenn die Konfiguration ungültig ist oder veraltete Schlüssel enthält, stoppt der Assistent und fordert - Sie auf, `openclaw doctor` auszuführen, bevor Sie fortfahren. - - Beim Zurücksetzen wird `trash` verwendet (niemals `rm`) und es werden diese Bereiche angeboten: + Sie auf, vor dem Fortfahren `openclaw doctor` auszuführen. + - Beim Zurücksetzen wird `trash` verwendet (niemals `rm`) und es werden folgende Bereiche angeboten: - Nur Konfiguration - Konfiguration + Anmeldedaten + Sitzungen - Vollständiges Zurücksetzen (entfernt auch den Workspace) - - **Anthropic-API-Schlüssel**: verwendet `ANTHROPIC_API_KEY`, wenn vorhanden, oder fragt nach einem Schlüssel und speichert ihn dann für die Nutzung durch den Daemon. + - **Anthropic-API-Schlüssel**: verwendet `ANTHROPIC_API_KEY`, falls vorhanden, oder fordert zur Eingabe eines Schlüssels auf und speichert ihn dann für die Daemon-Nutzung. - **Anthropic-API-Schlüssel**: bevorzugte Anthropic-Assistentenwahl in Onboarding/Konfiguration. - - **Anthropic-Setup-Token**: weiterhin in Onboarding/Konfiguration verfügbar, obwohl OpenClaw jetzt die Wiederverwendung von Claude CLI bevorzugt, wenn verfügbar. - - **OpenAI Code (Codex)-Abonnement (Codex CLI)**: wenn `~/.codex/auth.json` vorhanden ist, kann das Onboarding es wiederverwenden. Wiederverwendete Codex-CLI-Anmeldedaten werden weiterhin von Codex CLI verwaltet; bei Ablauf liest OpenClaw zuerst erneut aus dieser Quelle und schreibt aktualisierte Anmeldedaten, wenn der Provider sie erneuern kann, zurück in den Codex-Speicher, statt selbst die Kontrolle zu übernehmen. - - **OpenAI Code (Codex)-Abonnement (OAuth)**: Browser-Flow; fügen Sie `code#state` ein. - - Setzt `agents.defaults.model` auf `openai-codex/gpt-5.4`, wenn kein Modell gesetzt ist oder `openai/*` verwendet wird. - - **OpenAI-API-Schlüssel**: verwendet `OPENAI_API_KEY`, wenn vorhanden, oder fragt nach einem Schlüssel und speichert ihn dann in Auth-Profilen. - - Setzt `agents.defaults.model` auf `openai/gpt-5.4`, wenn kein Modell gesetzt ist, `openai/*` oder `openai-codex/*`. - - **xAI (Grok)-API-Schlüssel**: fragt nach `XAI_API_KEY` und konfiguriert xAI als Modell-Provider. - - **OpenCode**: fragt nach `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`, erhältlich unter https://opencode.ai/auth) und lässt Sie den Zen- oder Go-Katalog auswählen. - - **Ollama**: fragt nach der Ollama-Basis-URL, bietet den Modus **Cloud + Local** oder **Local** an, erkennt verfügbare Modelle und zieht das ausgewählte lokale Modell bei Bedarf automatisch. - - Mehr Details: [Ollama](/de/providers/ollama) + - **Anthropic-Setup-Token**: weiterhin in Onboarding/Konfiguration verfügbar, obwohl OpenClaw jetzt, wenn verfügbar, die Wiederverwendung der Claude CLI bevorzugt. + - **OpenAI Code (Codex)-Abonnement (Codex CLI)**: wenn `~/.codex/auth.json` vorhanden ist, kann das Onboarding es wiederverwenden. Wiederverwendete Codex-CLI-Anmeldedaten bleiben von der Codex CLI verwaltet; bei Ablauf liest OpenClaw diese Quelle zuerst erneut und schreibt bei entsprechender Refresh-Unterstützung des Providers die aktualisierten Anmeldedaten zurück in den Codex-Speicher, anstatt selbst die Verwaltung zu übernehmen. + - **OpenAI Code (Codex)-Abonnement (OAuth)**: Browser-Ablauf; fügen Sie `code#state` ein. + - Setzt `agents.defaults.model` auf `openai-codex/gpt-5.4`, wenn das Modell nicht gesetzt ist oder `openai/*` verwendet. + - **OpenAI-API-Schlüssel**: verwendet `OPENAI_API_KEY`, falls vorhanden, oder fordert zur Eingabe eines Schlüssels auf und speichert ihn dann in Auth-Profilen. + - Setzt `agents.defaults.model` auf `openai/gpt-5.4`, wenn das Modell nicht gesetzt ist, `openai/*` oder `openai-codex/*` verwendet. + - **xAI (Grok)-API-Schlüssel**: fordert `XAI_API_KEY` an und konfiguriert xAI als Modell-Provider. + - **OpenCode**: fordert `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`, erhältlich unter https://opencode.ai/auth) an und lässt Sie den Zen- oder Go-Katalog auswählen. + - **Ollama**: bietet zuerst **Cloud + Local**, **Nur Cloud** oder **Nur lokal** an. `Nur Cloud` fordert `OLLAMA_API_KEY` an und verwendet `https://ollama.com`; die hostgestützten Modi fragen nach der Ollama-Basis-URL, erkennen verfügbare Modelle und laden das ausgewählte lokale Modell bei Bedarf automatisch herunter; `Cloud + Local` prüft außerdem, ob dieser Ollama-Host für den Cloud-Zugriff angemeldet ist. + - Weitere Details: [Ollama](/de/providers/ollama) - **API-Schlüssel**: speichert den Schlüssel für Sie. - - **Vercel AI Gateway (Multi-Model-Proxy)**: fragt nach `AI_GATEWAY_API_KEY`. - - Mehr Details: [Vercel AI Gateway](/de/providers/vercel-ai-gateway) - - **Cloudflare AI Gateway**: fragt nach Account ID, Gateway ID und `CLOUDFLARE_AI_GATEWAY_API_KEY`. - - Mehr Details: [Cloudflare AI Gateway](/de/providers/cloudflare-ai-gateway) - - **MiniMax**: Konfiguration wird automatisch geschrieben; gehosteter Standard ist `MiniMax-M2.7`. - Die Einrichtung mit API-Schlüssel verwendet `minimax/...`, die OAuth-Einrichtung - verwendet `minimax-portal/...`. - - Mehr Details: [MiniMax](/de/providers/minimax) - - **StepFun**: Konfiguration wird automatisch für StepFun Standard oder Step Plan auf China- oder globalen Endpunkten geschrieben. - - Standard enthält derzeit `step-3.5-flash`, und Step Plan enthält zusätzlich `step-3.5-flash-2603`. - - Mehr Details: [StepFun](/de/providers/stepfun) - - **Synthetic (Anthropic-kompatibel)**: fragt nach `SYNTHETIC_API_KEY`. - - Mehr Details: [Synthetic](/de/providers/synthetic) - - **Moonshot (Kimi K2)**: Konfiguration wird automatisch geschrieben. - - **Kimi Coding**: Konfiguration wird automatisch geschrieben. - - Mehr Details: [Moonshot AI (Kimi + Kimi Coding)](/de/providers/moonshot) - - **Überspringen**: noch keine Authentifizierung konfiguriert. - - Wählen Sie aus den erkannten Optionen ein Standardmodell aus (oder geben Sie `provider/model` manuell ein). Für beste Qualität und ein geringeres Risiko durch Prompt-Injection wählen Sie das stärkste Modell der neuesten Generation, das in Ihrem Provider-Stack verfügbar ist. - - Onboarding führt eine Modellprüfung aus und warnt, wenn das konfigurierte Modell unbekannt ist oder Auth fehlt. - - Der Speichermodus für API-Schlüssel verwendet standardmäßig Klartextwerte in Auth-Profilen. Verwenden Sie `--secret-input-mode ref`, um stattdessen env-gestützte Refs zu speichern (zum Beispiel `keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" }`). - - Auth-Profile befinden sich unter `~/.openclaw/agents//agent/auth-profiles.json` (API-Schlüssel + OAuth). `~/.openclaw/credentials/oauth.json` dient nur noch dem Import aus Altbeständen. - - Mehr Details: [/concepts/oauth](/de/concepts/oauth) + - **Vercel AI Gateway (Multi-Modell-Proxy)**: fordert `AI_GATEWAY_API_KEY` an. + - Weitere Details: [Vercel AI Gateway](/de/providers/vercel-ai-gateway) + - **Cloudflare AI Gateway**: fordert Account-ID, Gateway-ID und `CLOUDFLARE_AI_GATEWAY_API_KEY` an. + - Weitere Details: [Cloudflare AI Gateway](/de/providers/cloudflare-ai-gateway) + - **MiniMax**: Die Konfiguration wird automatisch geschrieben; gehosteter Standard ist `MiniMax-M2.7`. + Die Einrichtung mit API-Schlüssel verwendet `minimax/...`, und die OAuth-Einrichtung verwendet + `minimax-portal/...`. + - Weitere Details: [MiniMax](/de/providers/minimax) + - **StepFun**: Die Konfiguration wird automatisch für StepFun Standard oder Step Plan auf China- oder globalen Endpunkten geschrieben. + - Standard umfasst derzeit `step-3.5-flash`, und Step Plan umfasst außerdem `step-3.5-flash-2603`. + - Weitere Details: [StepFun](/de/providers/stepfun) + - **Synthetic (Anthropic-kompatibel)**: fordert `SYNTHETIC_API_KEY` an. + - Weitere Details: [Synthetic](/de/providers/synthetic) + - **Moonshot (Kimi K2)**: Die Konfiguration wird automatisch geschrieben. + - **Kimi Coding**: Die Konfiguration wird automatisch geschrieben. + - Weitere Details: [Moonshot AI (Kimi + Kimi Coding)](/de/providers/moonshot) + - **Überspringen**: Noch keine Authentifizierung konfiguriert. + - Wählen Sie ein Standardmodell aus den erkannten Optionen aus (oder geben Sie Provider/Modell manuell ein). Für die beste Qualität und ein geringeres Risiko für Prompt Injection wählen Sie das stärkste aktuelle Modell, das in Ihrem Provider-Stack verfügbar ist. + - Das Onboarding führt eine Modellprüfung aus und warnt, wenn das konfigurierte Modell unbekannt ist oder Auth fehlt. + - Der Speichermodus für API-Schlüssel verwendet standardmäßig Klartextwerte in Auth-Profilen. Verwenden Sie `--secret-input-mode ref`, um stattdessen env-gestützte Referenzen zu speichern (zum Beispiel `keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" }`). + - Auth-Profile befinden sich unter `~/.openclaw/agents//agent/auth-profiles.json` (API-Schlüssel + OAuth). `~/.openclaw/credentials/oauth.json` dient nur noch als veraltete Importquelle. + - Weitere Details: [/concepts/oauth](/de/concepts/oauth) - Tipp für Headless-/Server-Systeme: Schließen Sie OAuth auf einem Rechner mit Browser ab und kopieren Sie dann - die `auth-profiles.json` dieses Agenten (zum Beispiel + Tipp für Headless-/Server-Umgebungen: Schließen Sie OAuth auf einem Rechner mit Browser ab und kopieren Sie dann die `auth-profiles.json` dieses Agenten (zum Beispiel `~/.openclaw/agents//agent/auth-profiles.json` oder den entsprechenden Pfad unter `$OPENCLAW_STATE_DIR/...`) auf den Gateway-Host. `credentials/oauth.json` - ist nur noch eine Altquelle für den Import. + ist nur eine veraltete Importquelle. - Standard `~/.openclaw/workspace` (konfigurierbar). - - Legt die für das Bootstrap-Ritual des Agenten benötigten Workspace-Dateien an. - - Vollständiges Workspace-Layout + Backup-Leitfaden: [Agent-Workspace](/de/concepts/agent-workspace) + - Legt die Workspace-Dateien an, die für das Bootstrap-Ritual des Agenten benötigt werden. + - Vollständiges Workspace-Layout + Backup-Anleitung: [Agent workspace](/de/concepts/agent-workspace) - - Port, Bind, Auth-Modus, Tailscale-Exponierung. + - Port, Bind, Auth-Modus, Tailscale-Exposition. - Auth-Empfehlung: Behalten Sie **Token** auch für Loopback bei, damit sich lokale WS-Clients authentifizieren müssen. - - Im Token-Modus bietet die interaktive Einrichtung: - - **Generate/store plaintext token** (Standard) - - **Use SecretRef** (Opt-in) - - Quickstart verwendet vorhandene `gateway.auth.token`-SecretRefs der Provider `env`, `file` und `exec` für Onboarding-Probe/Dashboard-Bootstrap erneut. - - Wenn dieses SecretRef konfiguriert ist, aber nicht aufgelöst werden kann, schlägt das Onboarding frühzeitig mit einer klaren Meldung zur Behebung fehl, statt die Laufzeit-Authentifizierung stillschweigend zu verschlechtern. - - Im Passwortmodus unterstützt die interaktive Einrichtung ebenfalls Klartext- oder SecretRef-Speicherung. - - Nicht interaktiver Token-SecretRef-Pfad: `--gateway-token-ref-env `. + - Im Token-Modus bietet das interaktive Setup: + - **Klartext-Token generieren/speichern** (Standard) + - **SecretRef verwenden** (Opt-in) + - Quickstart verwendet vorhandene SecretRefs in `gateway.auth.token` für die Provider `env`, `file` und `exec` erneut für Onboarding-Probe/Dashboard-Bootstrap. + - Wenn diese SecretRef konfiguriert ist, aber nicht aufgelöst werden kann, schlägt das Onboarding frühzeitig mit einer klaren Fehlermeldung fehl, statt die Laufzeit-Authentifizierung stillschweigend abzuschwächen. + - Im Passwortmodus unterstützt das interaktive Setup ebenfalls die Speicherung als Klartext oder SecretRef. + - Nicht-interaktiver Token-SecretRef-Pfad: `--gateway-token-ref-env `. - Erfordert eine nicht leere Umgebungsvariable in der Prozessumgebung des Onboardings. - Kann nicht mit `--gateway-token` kombiniert werden. - Deaktivieren Sie Auth nur, wenn Sie jedem lokalen Prozess vollständig vertrauen. @@ -106,35 +105,35 @@ Eine allgemeine Übersicht finden Sie unter [Onboarding (CLI)](/de/start/wizard) - [Discord](/de/channels/discord): Bot-Token. - [Google Chat](/de/channels/googlechat): Service-Account-JSON + Webhook-Audience. - [Mattermost](/de/channels/mattermost) (Plugin): Bot-Token + Basis-URL. - - [Signal](/de/channels/signal): optionale `signal-cli`-Installation + Kontokonfiguration. + - [Signal](/de/channels/signal): optionale Installation von `signal-cli` + Kontokonfiguration. - [BlueBubbles](/de/channels/bluebubbles): **empfohlen für iMessage**; Server-URL + Passwort + Webhook. - [iMessage](/de/channels/imessage): veralteter `imsg`-CLI-Pfad + DB-Zugriff. - - DM-Sicherheit: Standard ist Kopplung. Die erste DM sendet einen Code; genehmigen Sie ihn mit `openclaw pairing approve ` oder verwenden Sie Allowlists. + - DM-Sicherheit: Standard ist Pairing. Die erste DM sendet einen Code; genehmigen Sie ihn mit `openclaw pairing approve ` oder verwenden Sie Allowlists. - - Wählen Sie einen unterstützten Provider wie Brave, DuckDuckGo, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax Search, Ollama Web Search, Perplexity, SearXNG oder Tavily (oder überspringen Sie den Schritt). - - API-gestützte Provider können für die Schnelleinrichtung Umgebungsvariablen oder bestehende Konfiguration verwenden; schlüssellose Provider nutzen stattdessen ihre providerspezifischen Voraussetzungen. + - Wählen Sie einen unterstützten Provider wie Brave, DuckDuckGo, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax Search, Ollama Web Search, Perplexity, SearXNG oder Tavily (oder überspringen Sie diesen Schritt). + - API-gestützte Provider können für eine schnelle Einrichtung Umgebungsvariablen oder vorhandene Konfiguration verwenden; schlüssellose Provider nutzen stattdessen ihre providerspezifischen Voraussetzungen. - Mit `--skip-search` überspringen. - Später konfigurieren: `openclaw configure --section web`. - macOS: LaunchAgent - - Erfordert eine angemeldete Benutzersitzung; für Headless-Systeme verwenden Sie einen benutzerdefinierten LaunchDaemon (nicht mitgeliefert). - - Linux (und Windows über WSL2): systemd-Benutzereinheit + - Erfordert eine angemeldete Benutzersitzung; für Headless-Umgebungen verwenden Sie einen benutzerdefinierten LaunchDaemon (nicht mitgeliefert). + - Linux (und Windows über WSL2): systemd-User-Unit - Das Onboarding versucht, Lingering über `loginctl enable-linger ` zu aktivieren, damit das Gateway nach dem Abmelden weiterläuft. - - Kann nach sudo fragen (schreibt nach `/var/lib/systemd/linger`); zunächst wird es ohne sudo versucht. - - **Laufzeitauswahl:** Node (empfohlen; erforderlich für WhatsApp/Telegram). Bun ist **nicht empfohlen**. - - Wenn Token-Auth ein Token erfordert und `gateway.auth.token` über SecretRef verwaltet wird, validiert die Daemon-Installation es, speichert aber keine aufgelösten Klartext-Tokenwerte in den Umgebungsmetadaten des Supervisor-Dienstes. - - Wenn Token-Auth ein Token erfordert und das konfigurierte Token-SecretRef nicht aufgelöst werden kann, wird die Daemon-Installation mit umsetzbaren Hinweisen blockiert. - - Wenn sowohl `gateway.auth.token` als auch `gateway.auth.password` konfiguriert sind und `gateway.auth.mode` nicht gesetzt ist, wird die Daemon-Installation blockiert, bis der Modus explizit gesetzt wird. + - Kann nach sudo fragen (schreibt nach `/var/lib/systemd/linger`); es wird zunächst ohne sudo versucht. + - **Laufzeitauswahl:** Node (empfohlen; erforderlich für WhatsApp/Telegram). Bun wird **nicht empfohlen**. + - Wenn Token-Auth ein Token erfordert und `gateway.auth.token` per SecretRef verwaltet wird, validiert die Daemon-Installation dieses, speichert jedoch keine aufgelösten Klartext-Tokenwerte in den Umgebungsmetadaten des Supervisor-Dienstes. + - Wenn Token-Auth ein Token erfordert und die konfigurierte Token-SecretRef nicht aufgelöst ist, wird die Daemon-Installation mit umsetzbaren Hinweisen blockiert. + - Wenn sowohl `gateway.auth.token` als auch `gateway.auth.password` konfiguriert sind und `gateway.auth.mode` nicht gesetzt ist, wird die Daemon-Installation blockiert, bis der Modus explizit gesetzt ist. - Startet das Gateway (falls nötig) und führt `openclaw health` aus. - - Tipp: `openclaw status --deep` erweitert die Statusausgabe um die Live-Gateway-Integritätsprüfung, einschließlich Kanal-Probes, sofern unterstützt (erfordert ein erreichbares Gateway). + - Tipp: `openclaw status --deep` fügt der Statusausgabe die Live-Integritätsprüfung des Gateways hinzu, einschließlich Kanalprüfungen, sofern unterstützt (erfordert ein erreichbares Gateway). - Liest die verfügbaren Skills und prüft die Anforderungen. - - Lässt Sie einen Node-Manager auswählen: **npm / pnpm** (Bun nicht empfohlen). + - Lässt Sie einen Node-Manager auswählen: **npm / pnpm** (bun nicht empfohlen). - Installiert optionale Abhängigkeiten (einige verwenden Homebrew unter macOS). @@ -143,11 +142,11 @@ Eine allgemeine Übersicht finden Sie unter [Onboarding (CLI)](/de/start/wizard) -Wenn keine GUI erkannt wird, gibt das Onboarding SSH-Port-Forwarding-Anweisungen für die Control UI aus, anstatt einen Browser zu öffnen. +Wenn keine GUI erkannt wird, gibt das Onboarding SSH-Portweiterleitungsanweisungen für die Control UI aus, anstatt einen Browser zu öffnen. Wenn die Assets der Control UI fehlen, versucht das Onboarding, sie zu bauen; Fallback ist `pnpm ui:build` (installiert UI-Abhängigkeiten automatisch). -## Nicht interaktiver Modus +## Nicht-interaktiver Modus Verwenden Sie `--non-interactive`, um das Onboarding zu automatisieren oder zu skripten: @@ -165,7 +164,7 @@ openclaw onboard --non-interactive \ Fügen Sie `--json` für eine maschinenlesbare Zusammenfassung hinzu. -Gateway-Token-SecretRef im nicht interaktiven Modus: +Gateway-Token-SecretRef im nicht-interaktiven Modus: ```bash export OPENCLAW_GATEWAY_TOKEN="your-token" @@ -179,13 +178,13 @@ openclaw onboard --non-interactive \ `--gateway-token` und `--gateway-token-ref-env` schließen sich gegenseitig aus. -`--json` impliziert **nicht** den nicht interaktiven Modus. Verwenden Sie für Skripte `--non-interactive` (und `--workspace`). +`--json` impliziert **nicht** den nicht-interaktiven Modus. Verwenden Sie für Skripte `--non-interactive` (und `--workspace`). Providerspezifische Befehlsbeispiele finden Sie unter [CLI Automation](/de/start/wizard-cli-automation#provider-specific-examples). Verwenden Sie diese Referenzseite für die Semantik der Flags und die Reihenfolge der Schritte. -### Agent hinzufügen (nicht interaktiv) +### Agent hinzufügen (nicht-interaktiv) ```bash openclaw agents add work \ @@ -196,12 +195,12 @@ openclaw agents add work \ --json ``` -## Gateway-Assistenten-RPC +## Gateway-Wizard-RPC Das Gateway stellt den Onboarding-Ablauf über RPC bereit (`wizard.start`, `wizard.next`, `wizard.cancel`, `wizard.status`). -Clients (macOS-App, Control UI) können Schritte rendern, ohne die Onboarding-Logik erneut implementieren zu müssen. +Clients (macOS-App, Control UI) können Schritte darstellen, ohne die Onboarding-Logik erneut implementieren zu müssen. -## Signal-Einrichtung (signal-cli) +## Signal-Einrichtung (`signal-cli`) Das Onboarding kann `signal-cli` aus GitHub-Releases installieren: @@ -220,15 +219,15 @@ Hinweise: Typische Felder in `~/.openclaw/openclaw.json`: - `agents.defaults.workspace` -- `agents.defaults.model` / `models.providers` (wenn Minimax ausgewählt wurde) -- `tools.profile` (lokales Onboarding setzt standardmäßig `"coding"`, wenn nicht gesetzt; vorhandene explizite Werte bleiben erhalten) +- `agents.defaults.model` / `models.providers` (wenn MiniMax ausgewählt wurde) +- `tools.profile` (lokales Onboarding verwendet standardmäßig `"coding"`, wenn kein Wert gesetzt ist; vorhandene explizite Werte bleiben erhalten) - `gateway.*` (Modus, Bind, Auth, Tailscale) -- `session.dmScope` (Verhaltensdetails: [CLI Setup Reference](/de/start/wizard-cli-reference#outputs-and-internals)) +- `session.dmScope` (Verhaltensdetails: [CLI-Setup-Referenz](/de/start/wizard-cli-reference#outputs-and-internals)) - `channels.telegram.botToken`, `channels.discord.token`, `channels.matrix.*`, `channels.signal.*`, `channels.imessage.*` -- Kanal-Allowlists (Slack/Discord/Matrix/Microsoft Teams), wenn Sie ihnen während der Eingabeaufforderungen zustimmen (Namen werden, wenn möglich, zu IDs aufgelöst). +- Kanal-Allowlists (Slack/Discord/Matrix/Microsoft Teams), wenn Sie sich während der Eingabeaufforderungen dafür entscheiden (Namen werden, wenn möglich, in IDs aufgelöst). - `skills.install.nodeManager` - `setup --node-manager` akzeptiert `npm`, `pnpm` oder `bun`. - - In der manuellen Konfiguration kann weiterhin `yarn` verwendet werden, indem `skills.install.nodeManager` direkt gesetzt wird. + - Die manuelle Konfiguration kann weiterhin `yarn` verwenden, indem `skills.install.nodeManager` direkt gesetzt wird. - `wizard.lastRunAt` - `wizard.lastRunVersion` - `wizard.lastRunCommit` @@ -237,13 +236,13 @@ Typische Felder in `~/.openclaw/openclaw.json`: `openclaw agents add` schreibt `agents.list[]` und optionale `bindings`. -WhatsApp-Anmeldedaten liegen unter `~/.openclaw/credentials/whatsapp//`. +WhatsApp-Anmeldedaten werden unter `~/.openclaw/credentials/whatsapp//` gespeichert. Sitzungen werden unter `~/.openclaw/agents//sessions/` gespeichert. -Einige Kanäle werden als Plugins bereitgestellt. Wenn Sie während der Einrichtung einen solchen auswählen, -fordert das Onboarding Sie auf, ihn zu installieren (npm oder ein lokaler Pfad), bevor er konfiguriert werden kann. +Einige Kanäle werden als Plugins bereitgestellt. Wenn Sie während der Einrichtung einen davon auswählen, fordert das Onboarding +Sie auf, ihn zu installieren (npm oder ein lokaler Pfad), bevor er konfiguriert werden kann. -## Verwandte Dokumente +## Zugehörige Dokumentation - Onboarding-Übersicht: [Onboarding (CLI)](/de/start/wizard) - macOS-App-Onboarding: [Onboarding](/de/start/onboarding) diff --git a/docs/de/start/wizard-cli-reference.md b/docs/de/start/wizard-cli-reference.md index 7b367efc8..e33801a7d 100644 --- a/docs/de/start/wizard-cli-reference.md +++ b/docs/de/start/wizard-cli-reference.md @@ -3,129 +3,129 @@ read_when: - Sie benötigen detailliertes Verhalten für `openclaw onboard` - Sie debuggen Onboarding-Ergebnisse oder integrieren Onboarding-Clients sidebarTitle: CLI reference -summary: Vollständige Referenz für den CLI-Setup-Ablauf, Auth-/Modelleinrichtung, Ausgaben und Interna -title: CLI-Setup-Referenz +summary: Vollständige Referenz für den CLI-Einrichtungsablauf, die Authentifizierungs-/Modell-Einrichtung, Ausgaben und Interna +title: CLI-Einrichtungsreferenz x-i18n: - generated_at: "2026-04-06T03:12:42Z" + generated_at: "2026-04-15T14:41:07Z" model: gpt-5.4 provider: openai - source_hash: 92f379b34a2b48c68335dae4f759117c770f018ec51b275f4f40421c6b3abb23 + source_hash: 61ca679caca3b43fa02388294007f89db22d343e49e10b61d8d118cd8fbb7369 source_path: start/wizard-cli-reference.md workflow: 15 --- -# CLI-Setup-Referenz +# CLI-Einrichtungsreferenz Diese Seite ist die vollständige Referenz für `openclaw onboard`. -Die kurze Anleitung finden Sie unter [Onboarding (CLI)](/de/start/wizard). +Die Kurzfassung finden Sie unter [Onboarding (CLI)](/de/start/wizard). ## Was der Assistent macht -Der lokale Modus (Standard) führt Sie durch: +Der lokale Modus (Standard) führt Sie durch Folgendes: -- Modell- und Auth-Setup (OAuth für OpenAI Code subscription, Anthropic Claude CLI oder API-Schlüssel sowie Optionen für MiniMax, GLM, Ollama, Moonshot, StepFun und AI Gateway) +- Modell- und Authentifizierungs-Einrichtung (OpenAI Code-Abonnement-OAuth, Anthropic Claude CLI oder API-Schlüssel sowie Optionen für MiniMax, GLM, Ollama, Moonshot, StepFun und AI Gateway) - Workspace-Speicherort und Bootstrap-Dateien -- Gateway-Einstellungen (Port, Bind, Auth, Tailscale) -- Kanäle und Provider (Telegram, WhatsApp, Discord, Google Chat, Mattermost, Signal, BlueBubbles und andere gebündelte Kanal-Plugins) -- Daemon-Installation (LaunchAgent, systemd-User-Unit oder native Windows Scheduled Task mit Fallback auf den Startup-Ordner) -- Health-Check -- Skills-Setup +- Gateway-Einstellungen (Port, Bind, Authentifizierung, Tailscale) +- Kanäle und Anbieter (Telegram, WhatsApp, Discord, Google Chat, Mattermost, Signal, BlueBubbles und andere gebündelte Kanal-Plugins) +- Daemon-Installation (LaunchAgent, `systemd`-Benutzereinheit oder native Windows-Aufgabe im Aufgabenplaner mit Fallback auf den Autostart-Ordner) +- Integritätsprüfung +- Skills-Einrichtung -Der Remote-Modus konfiguriert diese Maschine so, dass sie sich mit einem Gateway an einem anderen Ort verbindet. -Er installiert oder verändert nichts auf dem Remote-Host. +Der Remote-Modus konfiguriert diesen Rechner für die Verbindung mit einem Gateway an einem anderen Ort. +Dabei wird auf dem Remote-Host nichts installiert oder geändert. -## Details des lokalen Ablaufs +## Details zum lokalen Ablauf - - Wenn `~/.openclaw/openclaw.json` existiert, wählen Sie Beibehalten, Ändern oder Zurücksetzen. - - Ein erneutes Ausführen des Assistenten löscht nichts, es sei denn, Sie wählen ausdrücklich Zurücksetzen (oder übergeben `--reset`). + - Wenn `~/.openclaw/openclaw.json` vorhanden ist, wählen Sie Beibehalten, Ändern oder Zurücksetzen. + - Das erneute Ausführen des Assistenten löscht nichts, außer Sie wählen ausdrücklich Zurücksetzen (oder übergeben `--reset`). - CLI-`--reset` verwendet standardmäßig `config+creds+sessions`; verwenden Sie `--reset-scope full`, um zusätzlich den Workspace zu entfernen. - - Wenn die Konfiguration ungültig ist oder veraltete Schlüssel enthält, stoppt der Assistent und fordert Sie auf, vor dem Fortfahren `openclaw doctor` auszuführen. - - Zum Zurücksetzen wird `trash` verwendet und folgende Bereiche werden angeboten: + - Wenn die Konfiguration ungültig ist oder Legacy-Schlüssel enthält, stoppt der Assistent und fordert Sie auf, vor dem Fortfahren `openclaw doctor` auszuführen. + - Beim Zurücksetzen wird `trash` verwendet und folgende Bereiche werden angeboten: - Nur Konfiguration - Konfiguration + Zugangsdaten + Sitzungen - Vollständiges Zurücksetzen (entfernt auch den Workspace) - - - Die vollständige Optionsmatrix finden Sie unter [Auth- und Modelloptionen](#auth-and-model-options). + + - Die vollständige Optionsmatrix finden Sie unter [Auth- und Modelloptionen](#auth-und-modelloptionen). - - Standardmäßig `~/.openclaw/workspace` (konfigurierbar). + - Standard `~/.openclaw/workspace` (konfigurierbar). - Legt die für das Bootstrap-Ritual beim ersten Start benötigten Workspace-Dateien an. - - Workspace-Layout: [Agent workspace](/de/concepts/agent-workspace). + - Workspace-Layout: [Agent-Workspace](/de/concepts/agent-workspace). - - Fragt nach Port, Bind, Auth-Modus und Tailscale-Exposition. - - Empfehlung: Lassen Sie Token-Auth auch für loopback aktiviert, damit sich lokale WS-Clients authentifizieren müssen. - - Im Token-Modus bietet das interaktive Setup: - - **Klartext-Token erzeugen/speichern** (Standard) + - Fragt Port, Bind, Authentifizierungsmodus und Tailscale-Freigabe ab. + - Empfohlen: Token-Authentifizierung auch bei local loopback aktiviert lassen, damit lokale WS-Clients sich authentifizieren müssen. + - Im Token-Modus bietet die interaktive Einrichtung: + - **Klartext-Token generieren/speichern** (Standard) - **SecretRef verwenden** (Opt-in) - - Im Passwortmodus unterstützt das interaktive Setup ebenfalls Klartext- oder SecretRef-Speicherung. - - Nicht interaktiver SecretRef-Pfad für Tokens: `--gateway-token-ref-env `. - - Erfordert eine nicht leere Umgebungsvariable in der Umgebung des Onboarding-Prozesses. + - Im Passwortmodus unterstützt die interaktive Einrichtung ebenfalls die Speicherung als Klartext oder SecretRef. + - Nicht interaktiver Token-SecretRef-Pfad: `--gateway-token-ref-env `. + - Erfordert eine nicht leere Umgebungsvariable in der Onboarding-Prozessumgebung. - Kann nicht mit `--gateway-token` kombiniert werden. - - Deaktivieren Sie Auth nur, wenn Sie jedem lokalen Prozess vollständig vertrauen. - - Nicht-loopback-Binds erfordern weiterhin Auth. + - Deaktivieren Sie die Authentifizierung nur, wenn Sie jedem lokalen Prozess vollständig vertrauen. + - Nicht-loopback-Binds erfordern weiterhin Authentifizierung. - - [WhatsApp](/de/channels/whatsapp): optionaler QR-Login + - [WhatsApp](/de/channels/whatsapp): optionale QR-Anmeldung - [Telegram](/de/channels/telegram): Bot-Token - [Discord](/de/channels/discord): Bot-Token - - [Google Chat](/de/channels/googlechat): JSON für Dienstkonto + Webhook-Audience + - [Google Chat](/de/channels/googlechat): JSON des Dienstkontos + Webhook-Audience - [Mattermost](/de/channels/mattermost): Bot-Token + Basis-URL - [Signal](/de/channels/signal): optionale `signal-cli`-Installation + Kontokonfiguration - [BlueBubbles](/de/channels/bluebubbles): empfohlen für iMessage; Server-URL + Passwort + Webhook - - [iMessage](/de/channels/imessage): veralteter `imsg`-CLI-Pfad + DB-Zugriff - - DM-Sicherheit: Standard ist Pairing. Die erste DM sendet einen Code; genehmigen Sie ihn über - `openclaw pairing approve ` oder verwenden Sie Allowlists. + - [iMessage](/de/channels/imessage): Legacy-`imsg`-CLI-Pfad + DB-Zugriff + - Sicherheit bei Direktnachrichten: Standard ist Pairing. Die erste Direktnachricht sendet einen Code; bestätigen Sie ihn mit + `openclaw pairing approve ` oder verwenden Sie Zulassungslisten. - macOS: LaunchAgent - Erfordert eine angemeldete Benutzersitzung; für Headless-Betrieb verwenden Sie einen benutzerdefinierten LaunchDaemon (wird nicht mitgeliefert). - - Linux und Windows über WSL2: systemd-User-Unit + - Linux und Windows über WSL2: `systemd`-Benutzereinheit - Der Assistent versucht `loginctl enable-linger `, damit das Gateway nach dem Abmelden weiterläuft. - - Möglicherweise wird sudo abgefragt (schreibt nach `/var/lib/systemd/linger`); zuerst wird es ohne sudo versucht. - - Natives Windows: zuerst Scheduled Task - - Wenn das Erstellen der Aufgabe verweigert wird, fällt OpenClaw auf ein Anmeldeelement im benutzerspezifischen Startup-Ordner zurück und startet das Gateway sofort. - - Scheduled Tasks bleiben bevorzugt, weil sie einen besseren Supervisor-Status bieten. - - Auswahl der Laufzeit: Node (empfohlen; erforderlich für WhatsApp und Telegram). Bun wird nicht empfohlen. + - Möglicherweise wird nach sudo gefragt (schreibt nach `/var/lib/systemd/linger`); zunächst wird es ohne sudo versucht. + - Natives Windows: zuerst Aufgabe im Aufgabenplaner + - Wenn das Erstellen der Aufgabe verweigert wird, weicht OpenClaw auf ein benutzerspezifisches Anmeldeobjekt im Autostart-Ordner aus und startet das Gateway sofort. + - Aufgaben im Aufgabenplaner bleiben bevorzugt, weil sie einen besseren Supervisor-Status bieten. + - Laufzeitauswahl: Node (empfohlen; erforderlich für WhatsApp und Telegram). Bun wird nicht empfohlen. - + - Startet das Gateway (falls nötig) und führt `openclaw health` aus. - - `openclaw status --deep` fügt der Statusausgabe die Live-Gateway-Health-Probe hinzu, einschließlich Kanal-Probes, wenn unterstützt. + - `openclaw status --deep` ergänzt die Statusausgabe um die Live-Gateway-Integritätsprüfung, einschließlich Kanalprüfungen, wenn unterstützt. - Liest verfügbare Skills und prüft Anforderungen. - - Lässt Sie den Node-Manager wählen: npm, pnpm oder bun. - - Installiert optionale Abhängigkeiten (einige verwenden Homebrew unter macOS). + - Ermöglicht die Auswahl des Node-Managers: npm, pnpm oder bun. + - Installiert optionale Abhängigkeiten (einige verwenden Homebrew auf macOS). - + - Zusammenfassung und nächste Schritte, einschließlich Optionen für iOS-, Android- und macOS-Apps. -Wenn keine GUI erkannt wird, gibt der Assistent Anweisungen für SSH-Port-Forwarding zur Control UI aus, statt einen Browser zu öffnen. -Wenn Assets der Control UI fehlen, versucht der Assistent, sie zu erstellen; Fallback ist `pnpm ui:build` (installiert UI-Abhängigkeiten automatisch). +Wenn keine GUI erkannt wird, gibt der Assistent SSH-Portweiterleitungsanweisungen für die Control UI aus, anstatt einen Browser zu öffnen. +Wenn Assets für die Control UI fehlen, versucht der Assistent, sie zu bauen; als Fallback dient `pnpm ui:build` (installiert UI-Abhängigkeiten automatisch). ## Details zum Remote-Modus -Der Remote-Modus konfiguriert diese Maschine so, dass sie sich mit einem Gateway an einem anderen Ort verbindet. +Der Remote-Modus konfiguriert diesen Rechner für die Verbindung mit einem Gateway an einem anderen Ort. -Der Remote-Modus installiert oder verändert nichts auf dem Remote-Host. +Im Remote-Modus wird auf dem Remote-Host nichts installiert oder geändert. Was Sie festlegen: - URL des Remote-Gateways (`ws://...`) -- Token, falls Auth des Remote-Gateways erforderlich ist (empfohlen) +- Token, falls für die Remote-Gateway-Authentifizierung erforderlich (empfohlen) -- Wenn das Gateway nur über loopback erreichbar ist, verwenden Sie SSH-Tunneling oder ein Tailnet. -- Discovery-Hinweise: +- Wenn das Gateway nur auf loopback lauscht, verwenden Sie SSH-Tunneling oder ein Tailnet. +- Hinweise zur Erkennung: - macOS: Bonjour (`dns-sd`) - Linux: Avahi (`avahi-browse`) @@ -134,132 +134,134 @@ Was Sie festlegen: - Verwendet `ANTHROPIC_API_KEY`, falls vorhanden, oder fragt nach einem Schlüssel und speichert ihn dann für die Verwendung durch den Daemon. + Verwendet `ANTHROPIC_API_KEY`, falls vorhanden, oder fordert zur Eingabe eines Schlüssels auf und speichert ihn anschließend für die Daemon-Nutzung. - - Wenn `~/.codex/auth.json` existiert, kann der Assistent sie wiederverwenden. - Wiederverwendete Zugangsdaten der Codex CLI bleiben durch die Codex CLI verwaltet; nach Ablauf liest OpenClaw - diese Quelle zuerst erneut ein und schreibt die aktualisierten Zugangsdaten, - wenn der Provider sie aktualisieren kann, zurück in den Codex-Speicher, - statt die Verwaltung selbst zu übernehmen. + + Wenn `~/.codex/auth.json` vorhanden ist, kann der Assistent es wiederverwenden. + Wiederverwendete Codex CLI-Zugangsdaten bleiben von Codex CLI verwaltet; bei Ablauf liest OpenClaw + zuerst erneut diese Quelle und schreibt, wenn der Anbieter sie aktualisieren kann, die + aktualisierten Zugangsdaten zurück in den Codex-Speicher, anstatt + selbst die Verwaltung zu übernehmen. - + Browser-Ablauf; fügen Sie `code#state` ein. - Setzt `agents.defaults.model` auf `openai-codex/gpt-5.4`, wenn kein Modell gesetzt ist oder `openai/*`. + Setzt `agents.defaults.model` auf `openai-codex/gpt-5.4`, wenn kein Modell gesetzt ist oder `openai/*` verwendet wird. - Verwendet `OPENAI_API_KEY`, falls vorhanden, oder fragt nach einem Schlüssel und speichert die Zugangsdaten dann in Auth-Profilen. + Verwendet `OPENAI_API_KEY`, falls vorhanden, oder fordert zur Eingabe eines Schlüssels auf und speichert die Zugangsdaten dann in Auth-Profilen. - Setzt `agents.defaults.model` auf `openai/gpt-5.4`, wenn kein Modell gesetzt ist, `openai/*` oder `openai-codex/*`. + Setzt `agents.defaults.model` auf `openai/gpt-5.4`, wenn kein Modell gesetzt ist, `openai/*` oder `openai-codex/*` verwendet wird. - Fragt nach `XAI_API_KEY` und konfiguriert xAI als Modell-Provider. + Fordert `XAI_API_KEY` an und konfiguriert xAI als Modellanbieter. - Fragt nach `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`) und lässt Sie den Zen- oder Go-Katalog auswählen. - Setup-URL: [opencode.ai/auth](https://opencode.ai/auth). + Fordert `OPENCODE_API_KEY` (oder `OPENCODE_ZEN_API_KEY`) an und lässt Sie zwischen dem Zen- oder Go-Katalog wählen. + Einrichtungs-URL: [opencode.ai/auth](https://opencode.ai/auth). Speichert den Schlüssel für Sie. - Fragt nach `AI_GATEWAY_API_KEY`. + Fordert `AI_GATEWAY_API_KEY` an. Weitere Details: [Vercel AI Gateway](/de/providers/vercel-ai-gateway). - Fragt nach Konten-ID, Gateway-ID und `CLOUDFLARE_AI_GATEWAY_API_KEY`. + Fordert Konto-ID, Gateway-ID und `CLOUDFLARE_AI_GATEWAY_API_KEY` an. Weitere Details: [Cloudflare AI Gateway](/de/providers/cloudflare-ai-gateway). - Die Konfiguration wird automatisch geschrieben. Gehosteter Standard ist `MiniMax-M2.7`; das Setup mit API-Schlüssel verwendet - `minimax/...`, und das OAuth-Setup verwendet `minimax-portal/...`. + Die Konfiguration wird automatisch geschrieben. Der gehostete Standardwert ist `MiniMax-M2.7`; bei der Einrichtung mit API-Schlüssel wird + `minimax/...` verwendet, und bei OAuth-Einrichtung `minimax-portal/...`. Weitere Details: [MiniMax](/de/providers/minimax). - Die Konfiguration wird für StepFun Standard oder Step Plan auf China- oder globalen Endpunkten automatisch geschrieben. + Die Konfiguration wird automatisch für StepFun Standard oder Step Plan auf chinesischen oder globalen Endpunkten geschrieben. Standard umfasst derzeit `step-3.5-flash`, und Step Plan umfasst außerdem `step-3.5-flash-2603`. Weitere Details: [StepFun](/de/providers/stepfun). - Fragt nach `SYNTHETIC_API_KEY`. + Fordert `SYNTHETIC_API_KEY` an. Weitere Details: [Synthetic](/de/providers/synthetic). - Fragt nach der Basis-URL (Standard `http://127.0.0.1:11434`) und bietet dann Cloud + Local oder den Modus Local an. - Ermittelt verfügbare Modelle und schlägt Standardwerte vor. + Fordert zuerst `Cloud + Local`, `Cloud only` oder `Local only` an. + `Cloud only` verwendet `OLLAMA_API_KEY` mit `https://ollama.com`. + Die hostgestützten Modi fragen nach der Basis-URL (Standard `http://127.0.0.1:11434`), erkennen verfügbare Modelle und schlagen Standardwerte vor. + `Cloud + Local` prüft außerdem, ob dieser Ollama-Host für den Cloud-Zugriff angemeldet ist. Weitere Details: [Ollama](/de/providers/ollama). Konfigurationen für Moonshot (Kimi K2) und Kimi Coding werden automatisch geschrieben. Weitere Details: [Moonshot AI (Kimi + Kimi Coding)](/de/providers/moonshot). - + Funktioniert mit OpenAI-kompatiblen und Anthropic-kompatiblen Endpunkten. - Interaktives Onboarding unterstützt dieselben Speicheroptionen für API-Schlüssel wie andere API-Schlüssel-Abläufe für Provider: + Das interaktive Onboarding unterstützt dieselben Speicheroptionen für API-Schlüssel wie andere API-Schlüssel-Abläufe von Anbietern: - **API-Schlüssel jetzt einfügen** (Klartext) - - **Geheimnisreferenz verwenden** (Env-Ref oder konfigurierte Provider-Ref, mit Preflight-Validierung) + - **Geheimnisreferenz verwenden** (Umgebungsreferenz oder konfigurierte Anbieterreferenz, mit Vorabvalidierung) Nicht interaktive Flags: - `--auth-choice custom-api-key` - `--custom-base-url` - `--custom-model-id` - - `--custom-api-key` (optional; fällt auf `CUSTOM_API_KEY` zurück) + - `--custom-api-key` (optional; greift auf `CUSTOM_API_KEY` zurück) - `--custom-provider-id` (optional) - `--custom-compatibility ` (optional; Standard `openai`) - Belässt Auth unkonfiguriert. + Lässt die Authentifizierung unkonfiguriert. Modellverhalten: -- Wählen Sie ein Standardmodell aus den erkannten Optionen oder geben Sie Provider und Modell manuell ein. -- Wenn das Onboarding mit einer Provider-Auth-Auswahl beginnt, bevorzugt der Modell-Picker - diesen Provider automatisch. Für Volcengine und BytePlus entspricht diese Präferenz - auch ihren Varianten für Coding Plans (`volcengine-plan/*`, +- Wählen Sie das Standardmodell aus den erkannten Optionen aus oder geben Sie Anbieter und Modell manuell ein. +- Wenn das Onboarding mit einer Anbieter-Authentifizierungsoption beginnt, bevorzugt die Modellauswahl + diesen Anbieter automatisch. Bei Volcengine und BytePlus passt dieselbe Präferenz + außerdem zu ihren Coding-Plan-Varianten (`volcengine-plan/*`, `byteplus-plan/*`). -- Wenn dieser bevorzugte Provider-Filter leer wäre, fällt der Picker auf den vollständigen Katalog zurück, statt keine Modelle anzuzeigen. -- Der Assistent führt eine Modellprüfung aus und warnt, wenn das konfigurierte Modell unbekannt ist oder Auth fehlt. +- Wenn dieser Filter für den bevorzugten Anbieter leer wäre, fällt die Auswahl auf + den vollständigen Katalog zurück, anstatt keine Modelle anzuzeigen. +- Der Assistent führt eine Modellprüfung aus und warnt, wenn das konfigurierte Modell unbekannt ist oder die Authentifizierung fehlt. Pfade für Zugangsdaten und Profile: - Auth-Profile (API-Schlüssel + OAuth): `~/.openclaw/agents//agent/auth-profiles.json` -- Veralteter OAuth-Import: `~/.openclaw/credentials/oauth.json` +- Legacy-OAuth-Import: `~/.openclaw/credentials/oauth.json` Speichermodus für Zugangsdaten: -- Das Standardverhalten des Onboardings speichert API-Schlüssel als Klartextwerte in Auth-Profilen. -- `--secret-input-mode ref` aktiviert den Referenzmodus statt Klartextspeicherung von Schlüsseln. - Im interaktiven Setup können Sie entweder Folgendes wählen: - - Referenz auf eine Umgebungsvariable (zum Beispiel `keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" }`) - - konfigurierte Provider-Ref (`file` oder `exec`) mit Provider-Alias + ID -- Der interaktive Referenzmodus führt vor dem Speichern eine schnelle Preflight-Validierung aus. - - Env-Refs: validiert Variablennamen + nicht leeren Wert in der aktuellen Onboarding-Umgebung. - - Provider-Refs: validiert die Provider-Konfiguration und löst die angeforderte ID auf. - - Wenn der Preflight fehlschlägt, zeigt das Onboarding den Fehler an und lässt Sie es erneut versuchen. -- Im nicht interaktiven Modus ist `--secret-input-mode ref` nur Env-basiert. - - Setzen Sie die Provider-Umgebungsvariable in der Umgebung des Onboarding-Prozesses. +- Das Standardverhalten im Onboarding speichert API-Schlüssel als Klartextwerte in Auth-Profilen. +- `--secret-input-mode ref` aktiviert den Referenzmodus anstelle der Speicherung von Schlüsseln im Klartext. + In der interaktiven Einrichtung können Sie Folgendes wählen: + - Referenz auf Umgebungsvariable (zum Beispiel `keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" }`) + - konfigurierte Anbieterreferenz (`file` oder `exec`) mit Anbieteralias + ID +- Der interaktive Referenzmodus führt vor dem Speichern eine schnelle Vorabvalidierung aus. + - Umgebungsreferenzen: validiert Variablennamen + nicht leeren Wert in der aktuellen Onboarding-Umgebung. + - Anbieterreferenzen: validiert die Anbieterkonfiguration und löst die angeforderte ID auf. + - Wenn die Vorabprüfung fehlschlägt, zeigt das Onboarding den Fehler an und lässt Sie es erneut versuchen. +- Im nicht interaktiven Modus ist `--secret-input-mode ref` nur umgebungsbasiert. + - Setzen Sie die Anbieter-Umgebungsvariable in der Onboarding-Prozessumgebung. - Inline-Schlüssel-Flags (zum Beispiel `--openai-api-key`) erfordern, dass diese Umgebungsvariable gesetzt ist; andernfalls schlägt das Onboarding sofort fehl. - - Für benutzerdefinierte Provider speichert der nicht interaktive `ref`-Modus `models.providers..apiKey` als `{ source: "env", provider: "default", id: "CUSTOM_API_KEY" }`. - - In diesem Fall für benutzerdefinierte Provider erfordert `--custom-api-key`, dass `CUSTOM_API_KEY` gesetzt ist; andernfalls schlägt das Onboarding sofort fehl. -- Gateway-Auth-Zugangsdaten unterstützen im interaktiven Setup Klartext- und SecretRef-Optionen: - - Token-Modus: **Klartext-Token erzeugen/speichern** (Standard) oder **SecretRef verwenden**. + - Für benutzerdefinierte Anbieter speichert der nicht interaktive `ref`-Modus `models.providers..apiKey` als `{ source: "env", provider: "default", id: "CUSTOM_API_KEY" }`. + - In diesem Fall für benutzerdefinierte Anbieter erfordert `--custom-api-key`, dass `CUSTOM_API_KEY` gesetzt ist; andernfalls schlägt das Onboarding sofort fehl. +- Gateway-Authentifizierungsdaten unterstützen in der interaktiven Einrichtung Klartext- und SecretRef-Optionen: + - Token-Modus: **Klartext-Token generieren/speichern** (Standard) oder **SecretRef verwenden**. - Passwortmodus: Klartext oder SecretRef. -- Nicht interaktiver SecretRef-Pfad für Tokens: `--gateway-token-ref-env `. -- Vorhandene Klartext-Setups funktionieren unverändert weiter. +- Nicht interaktiver Token-SecretRef-Pfad: `--gateway-token-ref-env `. +- Bestehende Klartext-Konfigurationen funktionieren unverändert weiter. -Tipp für Headless- und Server-Betrieb: Führen Sie OAuth auf einer Maschine mit Browser aus und kopieren Sie dann -die `auth-profiles.json` dieses Agenten (zum Beispiel +Tipp für Headless- und Server-Umgebungen: Schließen Sie OAuth auf einem Rechner mit Browser ab und kopieren Sie dann die `auth-profiles.json` dieses Agents (zum Beispiel `~/.openclaw/agents//agent/auth-profiles.json` oder den entsprechenden Pfad unter `$OPENCLAW_STATE_DIR/...`) auf den Gateway-Host. `credentials/oauth.json` -ist nur eine veraltete Importquelle. +ist nur eine Legacy-Importquelle. ## Ausgaben und Interna @@ -267,12 +269,12 @@ ist nur eine veraltete Importquelle. Typische Felder in `~/.openclaw/openclaw.json`: - `agents.defaults.workspace` -- `agents.defaults.model` / `models.providers` (falls Minimax gewählt wurde) -- `tools.profile` (lokales Onboarding setzt dies standardmäßig auf `"coding"`, wenn nicht gesetzt; vorhandene explizite Werte bleiben erhalten) -- `gateway.*` (Modus, Bind, Auth, Tailscale) -- `session.dmScope` (lokales Onboarding setzt dies standardmäßig auf `per-channel-peer`, wenn nicht gesetzt; vorhandene explizite Werte bleiben erhalten) +- `agents.defaults.model` / `models.providers` (wenn Minimax ausgewählt wurde) +- `tools.profile` (lokales Onboarding setzt standardmäßig `"coding"`, wenn kein Wert gesetzt ist; vorhandene explizite Werte bleiben erhalten) +- `gateway.*` (Modus, Bind, Authentifizierung, Tailscale) +- `session.dmScope` (lokales Onboarding setzt dies standardmäßig auf `per-channel-peer`, wenn kein Wert gesetzt ist; vorhandene explizite Werte bleiben erhalten) - `channels.telegram.botToken`, `channels.discord.token`, `channels.matrix.*`, `channels.signal.*`, `channels.imessage.*` -- Kanal-Allowlists (Slack, Discord, Matrix, Microsoft Teams), wenn Sie sich bei den Eingabeaufforderungen dafür entscheiden (Namen werden nach Möglichkeit in IDs aufgelöst) +- Kanal-Zulassungslisten (Slack, Discord, Matrix, Microsoft Teams), wenn Sie dies während der Eingabeaufforderungen aktivieren (Namen werden nach Möglichkeit in IDs aufgelöst) - `skills.install.nodeManager` - Das Flag `setup --node-manager` akzeptiert `npm`, `pnpm` oder `bun`. - Die manuelle Konfiguration kann später weiterhin `skills.install.nodeManager: "yarn"` setzen. @@ -284,12 +286,11 @@ Typische Felder in `~/.openclaw/openclaw.json`: `openclaw agents add` schreibt `agents.list[]` und optionale `bindings`. -WhatsApp-Zugangsdaten werden unter `~/.openclaw/credentials/whatsapp//` abgelegt. +WhatsApp-Zugangsdaten werden unter `~/.openclaw/credentials/whatsapp//` gespeichert. Sitzungen werden unter `~/.openclaw/agents//sessions/` gespeichert. -Einige Kanäle werden als Plugins ausgeliefert. Wenn sie während des Setups ausgewählt werden, fordert der Assistent -zur Installation des Plugins auf (npm oder lokaler Pfad), bevor die Kanalkonfiguration erfolgt. +Einige Kanäle werden als Plugins bereitgestellt. Wenn sie während der Einrichtung ausgewählt werden, fordert der Assistent Sie auf, das Plugin (npm oder lokaler Pfad) vor der Kanalkonfiguration zu installieren. Gateway-Assistent-RPC: @@ -299,19 +300,19 @@ Gateway-Assistent-RPC: - `wizard.cancel` - `wizard.status` -Clients (macOS-App und Control UI) können Schritte rendern, ohne die Onboarding-Logik neu implementieren zu müssen. +Clients (macOS-App und Control UI) können Schritte rendern, ohne die Onboarding-Logik erneut implementieren zu müssen. -Verhalten beim Signal-Setup: +Verhalten bei der Signal-Einrichtung: - Lädt das passende Release-Asset herunter - Speichert es unter `~/.openclaw/tools/signal-cli//` - Schreibt `channels.signal.cliPath` in die Konfiguration - JVM-Builds erfordern Java 21 - Native Builds werden verwendet, wenn verfügbar -- Windows verwendet WSL2 und folgt dem Linux-Ablauf für signal-cli innerhalb von WSL +- Windows verwendet WSL2 und folgt dem Linux-`signal-cli`-Ablauf innerhalb von WSL -## Verwandte Docs +## Zugehörige Dokumente - Onboarding-Hub: [Onboarding (CLI)](/de/start/wizard) -- Automatisierung und Skripte: [CLI Automation](/de/start/wizard-cli-automation) +- Automatisierung und Skripte: [CLI-Automatisierung](/de/start/wizard-cli-automation) - Befehlsreferenz: [`openclaw onboard`](/cli/onboard)