diff --git a/docs/de/automation/tasks.md b/docs/de/automation/tasks.md
index 56af91bdd..19f880f5e 100644
--- a/docs/de/automation/tasks.md
+++ b/docs/de/automation/tasks.md
@@ -1,44 +1,44 @@
---
read_when:
- - In Bearbeitung befindliche oder kürzlich abgeschlossene Hintergrundaufgaben prüfen
- - Fehler bei der Zustellung für getrennte Agentenläufe beheben
+ - Inspektion laufender oder kürzlich abgeschlossener Hintergrundaufgaben
+ - Debuggen von Zustellungsfehlern bei entkoppelten Agent-Läufen
- Verstehen, wie Hintergrundläufe mit Sitzungen, Cron und Heartbeat zusammenhängen
-summary: Hintergrundaufgabenverfolgung für ACP-Läufe, Subagenten, isolierte Cron-Jobs und CLI-Operationen
+summary: Hintergrundaufgaben-Verfolgung für ACP-Läufe, Subagents, isolierte Cron-Jobs und CLI-Operationen
title: Hintergrundaufgaben
x-i18n:
- generated_at: "2026-04-21T06:22:58Z"
+ generated_at: "2026-04-21T19:20:42Z"
model: gpt-5.4
provider: openai
- source_hash: ba5511b1c421bdf505fc7d34f09e453ac44e85213fcb0f082078fa957aa91fe7
+ source_hash: a4cd666b3eaffde8df0b5e1533eb337e44a0824824af6f8a240f18a89f71b402
source_path: automation/tasks.md
workflow: 15
---
# Hintergrundaufgaben
-> **Auf der Suche nach Planung?** Siehe [Automatisierung & Aufgaben](/de/automation), um den richtigen Mechanismus auszuwählen. Diese Seite behandelt das **Nachverfolgen** von Hintergrundarbeit, nicht deren Planung.
+> **Suchen Sie nach Planung?** Unter [Automatisierung & Aufgaben](/de/automation) erfahren Sie, wie Sie den richtigen Mechanismus auswählen. Auf dieser Seite geht es um das **Nachverfolgen** von Hintergrundarbeit, nicht um deren Planung.
-Hintergrundaufgaben verfolgen Arbeit, die **außerhalb Ihrer Haupt-Konversationssitzung** ausgeführt wird:
-ACP-Läufe, Subagent-Starts, isolierte Cron-Job-Ausführungen und per CLI initiierte Operationen.
+Hintergrundaufgaben verfolgen Arbeit, die **außerhalb Ihrer Haupt-Konversationssitzung** läuft:
+ACP-Läufe, Subagent-Starts, isolierte Cron-Job-Ausführungen und über die CLI gestartete Operationen.
-Aufgaben ersetzen **nicht** Sitzungen, Cron-Jobs oder Heartbeats — sie sind das **Aktivitätsprotokoll**, das aufzeichnet, welche entkoppelte Arbeit stattgefunden hat, wann sie stattgefunden hat und ob sie erfolgreich war.
+Aufgaben ersetzen **nicht** Sitzungen, Cron-Jobs oder Heartbeats — sie sind das **Aktivitätsprotokoll**, das festhält, welche entkoppelte Arbeit stattgefunden hat, wann sie stattgefunden hat und ob sie erfolgreich war.
-Nicht jeder Agentenlauf erstellt eine Aufgabe. Heartbeat-Durchläufe und normale interaktive Chats tun das nicht. Alle Cron-Ausführungen, ACP-Starts, Subagent-Starts und CLI-Agent-Befehle tun es.
+Nicht jeder Agent-Lauf erstellt eine Aufgabe. Heartbeat-Turns und normaler interaktiver Chat tun das nicht. Alle Cron-Ausführungen, ACP-Starts, Subagent-Starts und CLI-Agent-Befehle tun es.
## Kurzfassung
-- Aufgaben sind **Einträge**, keine Planer — Cron und Heartbeat entscheiden, _wann_ Arbeit ausgeführt wird, Aufgaben verfolgen, _was passiert ist_.
-- ACP, Subagenten, alle Cron-Jobs und CLI-Operationen erstellen Aufgaben. Heartbeat-Durchläufe nicht.
+- Aufgaben sind **Datensätze**, keine Planer — Cron und Heartbeat entscheiden, _wann_ Arbeit ausgeführt wird, Aufgaben verfolgen, _was passiert ist_.
+- ACP, Subagents, alle Cron-Jobs und CLI-Operationen erstellen Aufgaben. Heartbeat-Turns tun das nicht.
- Jede Aufgabe durchläuft `queued → running → terminal` (succeeded, failed, timed_out, cancelled oder lost).
-- Cron-Aufgaben bleiben aktiv, solange die Cron-Laufzeit die Aufgabe noch besitzt; chatgestützte CLI-Aufgaben bleiben nur aktiv, solange ihr zugehöriger Ausführungskontext noch aktiv ist.
-- Der Abschluss ist push-gesteuert: Entkoppelte Arbeit kann direkt benachrichtigen oder die anfordernde Sitzung bzw. den Heartbeat wecken, wenn sie beendet ist, daher sind Status-Polling-Schleifen meist die falsche Form.
-- Isolierte Cron-Läufe und Subagent-Abschlüsse räumen nach bestem Bemühen verfolgte Browser-Tabs/Prozesse für ihre untergeordnete Sitzung vor der abschließenden Cleanup-Buchführung auf.
-- Die Zustellung isolierter Cron-Läufe unterdrückt veraltete vorläufige Antworten der übergeordneten Instanz, während nachgeordnete Subagent-Arbeit noch ausläuft, und bevorzugt die endgültige Ausgabe der Nachkommen, wenn diese vor der Zustellung eintrifft.
+- Cron-Aufgaben bleiben aktiv, solange die Cron-Laufzeitumgebung den Job noch besitzt; chatgestützte CLI-Aufgaben bleiben nur aktiv, solange ihr besitzender Laufkontext noch aktiv ist.
+- Der Abschluss ist Push-gesteuert: Entkoppelte Arbeit kann direkt benachrichtigen oder die anfordernde Sitzung/den Heartbeat wecken, wenn sie abgeschlossen ist; Status-Polling-Schleifen sind daher in der Regel die falsche Form.
+- Isolierte Cron-Läufe und Subagent-Abschlüsse bereinigen nach bestem Bemühen nachverfolgte Browser-Tabs/Prozesse für ihre untergeordnete Sitzung vor der finalen Cleanup-Buchführung.
+- Die Auslieferung isolierter Cron-Läufe unterdrückt veraltete Zwischenantworten des Elternteils, während nachgelagerte Subagent-Arbeit noch ausläuft, und bevorzugt finale nachgelagerte Ausgabe, wenn diese vor der Zustellung eintrifft.
- Abschlussbenachrichtigungen werden direkt an einen Kanal zugestellt oder für den nächsten Heartbeat in die Warteschlange gestellt.
- `openclaw tasks list` zeigt alle Aufgaben; `openclaw tasks audit` macht Probleme sichtbar.
-- Terminal-Einträge werden 7 Tage lang aufbewahrt und dann automatisch entfernt.
+- Terminal-Datensätze werden 7 Tage lang aufbewahrt und danach automatisch bereinigt.
## Schnellstart
@@ -62,7 +62,7 @@ openclaw tasks notify state_changes
# Integritätsprüfung ausführen
openclaw tasks audit
-# Wartung vorschauen oder anwenden
+# Wartung in der Vorschau anzeigen oder anwenden
openclaw tasks maintenance
openclaw tasks maintenance --apply
@@ -74,24 +74,24 @@ openclaw tasks flow cancel
## Was eine Aufgabe erstellt
-| Quelle | Laufzeittyp | Wann ein Aufgabeneintrag erstellt wird | Standard-Benachrichtigungsrichtlinie |
+| Quelle | Laufzeittyp | Wann ein Aufgabendatensatz erstellt wird | Standard-Benachrichtigungsrichtlinie |
| ---------------------- | ----------- | ----------------------------------------------------- | ------------------------------------ |
-| ACP-Hintergrundläufe | `acp` | Starten einer untergeordneten ACP-Sitzung | `done_only` |
-| Subagent-Orchestrierung | `subagent` | Starten eines Subagenten über `sessions_spawn` | `done_only` |
-| Cron-Jobs (alle Typen) | `cron` | Jede Cron-Ausführung (Hauptsitzung und isoliert) | `silent` |
+| ACP-Hintergrundläufe | `acp` | Beim Starten einer untergeordneten ACP-Sitzung | `done_only` |
+| Subagent-Orchestrierung | `subagent` | Beim Starten eines Subagents über `sessions_spawn` | `done_only` |
+| Cron-Jobs (alle Typen) | `cron` | Bei jeder Cron-Ausführung (Hauptsitzung und isoliert) | `silent` |
| CLI-Operationen | `cli` | `openclaw agent`-Befehle, die über das Gateway laufen | `silent` |
-| Agenten-Medienjobs | `cli` | Sitzungsgebundene `video_generate`-Läufe | `silent` |
+| Agent-Medienjobs | `cli` | Sitzungsgebundene `video_generate`-Läufe | `silent` |
-Cron-Aufgaben der Hauptsitzung verwenden standardmäßig die Benachrichtigungsrichtlinie `silent` — sie erstellen Einträge zur Nachverfolgung, erzeugen aber keine Benachrichtigungen. Isolierte Cron-Aufgaben verwenden ebenfalls standardmäßig `silent`, sind aber sichtbarer, weil sie in ihrer eigenen Sitzung laufen.
+Cron-Aufgaben der Hauptsitzung verwenden standardmäßig die Benachrichtigungsrichtlinie `silent` — sie erstellen Datensätze zum Nachverfolgen, erzeugen aber keine Benachrichtigungen. Isolierte Cron-Aufgaben verwenden ebenfalls standardmäßig `silent`, sind aber sichtbarer, weil sie in ihrer eigenen Sitzung laufen.
-Sitzungsgebundene `video_generate`-Läufe verwenden ebenfalls die Benachrichtigungsrichtlinie `silent`. Sie erstellen weiterhin Aufgabeneinträge, aber der Abschluss wird als internes Wecksignal an die ursprüngliche Agentensitzung zurückgegeben, damit der Agent die Folgemeldung schreiben und das fertige Video selbst anhängen kann. Wenn Sie `tools.media.asyncCompletion.directSend` aktivieren, versuchen asynchrone `music_generate`- und `video_generate`-Abschlüsse zuerst die direkte Kanalzustellung, bevor sie auf den Weckpfad der anfordernden Sitzung zurückfallen.
+Sitzungsgebundene `video_generate`-Läufe verwenden ebenfalls die Benachrichtigungsrichtlinie `silent`. Sie erstellen weiterhin Aufgabendatensätze, aber der Abschluss wird als internes Wake an die ursprüngliche Agent-Sitzung zurückgegeben, damit der Agent selbst die Folgemeldung schreiben und das fertige Video anhängen kann. Wenn Sie `tools.media.asyncCompletion.directSend` aktivieren, versuchen asynchrone `music_generate`- und `video_generate`-Abschlüsse zuerst die direkte Kanalzustellung, bevor sie auf den Wake-Pfad der anfordernden Sitzung zurückfallen.
-Solange eine sitzungsgebundene `video_generate`-Aufgabe noch aktiv ist, fungiert das Tool auch als Schutzmechanismus: Wiederholte `video_generate`-Aufrufe in derselben Sitzung geben den Status der aktiven Aufgabe zurück, anstatt eine zweite gleichzeitige Generierung zu starten. Verwenden Sie `action: "status"`, wenn Sie explizit eine Fortschritts-/Statusabfrage von Agentenseite aus möchten.
+Während eine sitzungsgebundene `video_generate`-Aufgabe noch aktiv ist, wirkt das Tool auch als Leitplanke: Wiederholte `video_generate`-Aufrufe in derselben Sitzung geben den Status der aktiven Aufgabe zurück, statt eine zweite gleichzeitige Generierung zu starten. Verwenden Sie `action: "status"`, wenn Sie auf Agent-Seite eine explizite Fortschritts-/Statusabfrage möchten.
**Was keine Aufgaben erstellt:**
-- Heartbeat-Durchläufe — Hauptsitzung; siehe [Heartbeat](/de/gateway/heartbeat)
-- Normale interaktive Chat-Durchläufe
+- Heartbeat-Turns — Hauptsitzung; siehe [Heartbeat](/de/gateway/heartbeat)
+- Normale interaktive Chat-Turns
- Direkte `/command`-Antworten
## Aufgabenlebenszyklus
@@ -99,47 +99,47 @@ Solange eine sitzungsgebundene `video_generate`-Aufgabe noch aktiv ist, fungiert
```mermaid
stateDiagram-v2
[*] --> queued
- queued --> running : Agent startet
- running --> succeeded : erfolgreich abgeschlossen
- running --> failed : Fehler
- running --> timed_out : Zeitüberschreitung
- running --> cancelled : Operator bricht ab
- queued --> lost : Sitzung > 5 Min. verschwunden
- running --> lost : Sitzung > 5 Min. verschwunden
+ queued --> running : agent starts
+ running --> succeeded : completes ok
+ running --> failed : error
+ running --> timed_out : timeout exceeded
+ running --> cancelled : operator cancels
+ queued --> lost : session gone > 5 min
+ running --> lost : session gone > 5 min
```
| Status | Bedeutung |
| ----------- | ------------------------------------------------------------------------- |
| `queued` | Erstellt, wartet auf den Start des Agenten |
-| `running` | Der Agent-Durchlauf wird aktiv ausgeführt |
-| `succeeded` | Erfolgreich abgeschlossen |
+| `running` | Der Agent-Turn wird gerade aktiv ausgeführt |
+| `succeeded` | Erfolgreich abgeschlossen |
| `failed` | Mit einem Fehler abgeschlossen |
-| `timed_out` | Die konfigurierte Zeitüberschreitung wurde erreicht |
+| `timed_out` | Das konfigurierte Timeout wurde überschritten |
| `cancelled` | Vom Operator über `openclaw tasks cancel` gestoppt |
-| `lost` | Die Laufzeit hat nach einer Karenzzeit von 5 Minuten den maßgeblichen Sicherungsstatus verloren |
+| `lost` | Die Laufzeitumgebung hat nach einer Schonfrist von 5 Minuten den autoritativen Trägerstatus verloren |
-Übergänge erfolgen automatisch — wenn der zugehörige Agentenlauf endet, wird der Aufgabenstatus entsprechend aktualisiert.
+Übergänge erfolgen automatisch — wenn der zugehörige Agent-Lauf endet, wird der Aufgabenstatus entsprechend aktualisiert.
`lost` ist laufzeitbewusst:
-- ACP-Aufgaben: Metadaten der zugehörigen ACP-Untergeordnetensitzung sind verschwunden.
-- Subagent-Aufgaben: Zugehörige Untergeordnetensitzung ist aus dem Ziel-Agentenspeicher verschwunden.
-- Cron-Aufgaben: Die Cron-Laufzeit verfolgt den Job nicht mehr als aktiv.
-- CLI-Aufgaben: Isolierte Aufgaben mit Untergeordnetensitzung verwenden die Untergeordnetensitzung; chatgestützte CLI-Aufgaben verwenden stattdessen den aktiven Ausführungskontext, sodass verbleibende Kanal-/Gruppen-/Direktsitzungszeilen sie nicht aktiv halten.
+- ACP-Aufgaben: Metadaten der untergeordneten ACP-Sitzung sind verschwunden.
+- Subagent-Aufgaben: Untergeordnete Sitzung ist aus dem Ziel-Agent-Store verschwunden.
+- Cron-Aufgaben: Die Cron-Laufzeitumgebung verfolgt den Job nicht mehr als aktiv.
+- CLI-Aufgaben: Isolierte untergeordnete Sitzungsaufgaben verwenden die untergeordnete Sitzung; chatgestützte CLI-Aufgaben verwenden stattdessen den Live-Laufkontext, sodass verbleibende Kanal-/Gruppen-/Direktsitzungszeilen sie nicht aktiv halten.
## Zustellung und Benachrichtigungen
-Wenn eine Aufgabe einen terminalen Zustand erreicht, benachrichtigt OpenClaw Sie. Es gibt zwei Zustellpfade:
+Wenn eine Aufgabe einen Terminal-Status erreicht, benachrichtigt OpenClaw Sie. Es gibt zwei Zustellpfade:
-**Direkte Zustellung** — wenn die Aufgabe ein Kanalziel hat (den `requesterOrigin`), geht die Abschlussnachricht direkt an diesen Kanal (Telegram, Discord, Slack usw.). Bei Subagent-Abschlüssen bewahrt OpenClaw außerdem gebundene Thread-/Thema-Weiterleitung, wenn verfügbar, und kann ein fehlendes `to` / Konto aus der gespeicherten Route der anfordernden Sitzung (`lastChannel` / `lastTo` / `lastAccountId`) ergänzen, bevor die direkte Zustellung aufgegeben wird.
+**Direkte Zustellung** — wenn die Aufgabe ein Kanalziel hat (den `requesterOrigin`), geht die Abschlussmeldung direkt an diesen Kanal (Telegram, Discord, Slack usw.). Bei Subagent-Abschlüssen bewahrt OpenClaw außerdem die gebundene Thread-/Topic-Weiterleitung, wenn verfügbar, und kann ein fehlendes `to` / Konto aus der gespeicherten Route der anfordernden Sitzung (`lastChannel` / `lastTo` / `lastAccountId`) ergänzen, bevor die direkte Zustellung aufgegeben wird.
-**In die Sitzungswarteschlange eingereihte Zustellung** — wenn die direkte Zustellung fehlschlägt oder kein Ursprung gesetzt ist, wird das Update als Systemereignis in die Warteschlange der anfordernden Sitzung gestellt und beim nächsten Heartbeat sichtbar.
+**Sitzungswarteschlangen-Zustellung** — wenn die direkte Zustellung fehlschlägt oder kein Ursprung gesetzt ist, wird das Update als Systemereignis in die Warteschlange der anfordernden Sitzung gestellt und beim nächsten Heartbeat angezeigt.
-Der Abschluss einer Aufgabe löst ein sofortiges Heartbeat-Wecksignal aus, damit Sie das Ergebnis schnell sehen — Sie müssen nicht bis zum nächsten geplanten Heartbeat-Takt warten.
+Der Abschluss einer Aufgabe löst ein sofortiges Heartbeat-Wake aus, damit Sie das Ergebnis schnell sehen — Sie müssen nicht auf den nächsten geplanten Heartbeat-Tick warten.
-Das bedeutet, dass der übliche Arbeitsablauf push-basiert ist: Starten Sie entkoppelte Arbeit einmal und lassen Sie sich dann von der Laufzeit bei Abschluss wecken oder benachrichtigen. Fragen Sie den Aufgabenstatus nur ab, wenn Sie Debugging, Eingriffe oder eine explizite Prüfung benötigen.
+Das bedeutet, dass der übliche Ablauf Push-basiert ist: Starten Sie entkoppelte Arbeit einmal und lassen Sie sich dann von der Laufzeitumgebung bei Abschluss wecken oder benachrichtigen. Fragen Sie den Aufgabenstatus nur ab, wenn Sie Debugging, Eingriffe oder eine explizite Prüfung benötigen.
### Benachrichtigungsrichtlinien
@@ -147,9 +147,9 @@ Steuern Sie, wie viel Sie über jede Aufgabe erfahren:
| Richtlinie | Was zugestellt wird |
| --------------------- | ------------------------------------------------------------------------ |
-| `done_only` (Standard) | Nur terminaler Zustand (succeeded, failed usw.) — **dies ist der Standard** |
-| `state_changes` | Jeder Zustandsübergang und jede Fortschrittsaktualisierung |
-| `silent` | Gar nichts |
+| `done_only` (Standard) | Nur der Terminal-Status (succeeded, failed usw.) — **das ist der Standard** |
+| `state_changes` | Jeder Statusübergang und jedes Fortschritts-Update |
+| `silent` | Überhaupt nichts |
Ändern Sie die Richtlinie, während eine Aufgabe läuft:
@@ -165,7 +165,7 @@ openclaw tasks notify state_changes
openclaw tasks list [--runtime ] [--status ] [--json]
```
-Ausgabespalten: Aufgaben-ID, Art, Status, Zustellung, Lauf-ID, Untergeordnetensitzung, Zusammenfassung.
+Ausgabespalten: Aufgaben-ID, Typ, Status, Zustellung, Lauf-ID, untergeordnete Sitzung, Zusammenfassung.
### `tasks show`
@@ -173,7 +173,7 @@ Ausgabespalten: Aufgaben-ID, Art, Status, Zustellung, Lauf-ID, Untergeordnetensi
openclaw tasks show
```
-Das Lookup-Token akzeptiert eine Aufgaben-ID, Lauf-ID oder einen Sitzungsschlüssel. Zeigt den vollständigen Eintrag einschließlich Zeitangaben, Zustellstatus, Fehler und terminaler Zusammenfassung.
+Das Lookup-Token akzeptiert eine Aufgaben-ID, Lauf-ID oder einen Sitzungsschlüssel. Zeigt den vollständigen Datensatz einschließlich Timing, Zustellstatus, Fehler und Terminal-Zusammenfassung.
### `tasks cancel`
@@ -181,7 +181,7 @@ Das Lookup-Token akzeptiert eine Aufgaben-ID, Lauf-ID oder einen Sitzungsschlüs
openclaw tasks cancel
```
-Bei ACP- und Subagent-Aufgaben beendet dies die untergeordnete Sitzung. Bei CLI-verfolgten Aufgaben wird der Abbruch im Aufgabenregister erfasst (es gibt keinen separaten Handle der untergeordneten Laufzeit). Der Status wechselt zu `cancelled`, und falls zutreffend wird eine Zustellbenachrichtigung gesendet.
+Bei ACP- und Subagent-Aufgaben beendet dies die untergeordnete Sitzung. Bei CLI-nachverfolgten Aufgaben wird der Abbruch in der Aufgabenregistrierung vermerkt (es gibt keinen separaten Handle der untergeordneten Laufzeitumgebung). Der Status wechselt zu `cancelled`, und wenn zutreffend wird eine Zustellbenachrichtigung gesendet.
### `tasks notify`
@@ -195,16 +195,16 @@ openclaw tasks notify
openclaw tasks audit [--json]
```
-Macht betriebliche Probleme sichtbar. Erkenntnisse erscheinen auch in `openclaw status`, wenn Probleme erkannt werden.
+Macht betriebliche Probleme sichtbar. Erkenntnisse erscheinen bei erkannten Problemen auch in `openclaw status`.
-| Erkenntnis | Schweregrad | Auslöser |
+| Ergebnis | Schweregrad | Auslöser |
| ------------------------- | ----------- | ----------------------------------------------------- |
-| `stale_queued` | warn | Mehr als 10 Minuten in Warteschlange |
-| `stale_running` | error | Mehr als 30 Minuten ausgeführt |
-| `lost` | error | Laufzeitgestützte Aufgabeninhaberschaft verschwunden |
+| `stale_queued` | warn | Mehr als 10 Minuten in der Warteschlange |
+| `stale_running` | error | Mehr als 30 Minuten laufend |
+| `lost` | error | Laufzeitgestützte Aufgabeninhaberschaft ist verschwunden |
| `delivery_failed` | warn | Zustellung fehlgeschlagen und Benachrichtigungsrichtlinie ist nicht `silent` |
-| `missing_cleanup` | warn | Terminale Aufgabe ohne Cleanup-Zeitstempel |
-| `inconsistent_timestamps` | warn | Verletzung der Zeitachse (zum Beispiel vor Start beendet) |
+| `missing_cleanup` | warn | Terminal-Aufgabe ohne Cleanup-Zeitstempel |
+| `inconsistent_timestamps` | warn | Verletzung der Zeitachse (zum Beispiel Ende vor Start) |
### `tasks maintenance`
@@ -213,21 +213,21 @@ openclaw tasks maintenance [--json]
openclaw tasks maintenance --apply [--json]
```
-Verwenden Sie dies, um Abgleich, Cleanup-Zeitstempelung und Pruning für Aufgaben und den Task Flow-Status in der Vorschau anzuzeigen oder anzuwenden.
+Verwenden Sie dies, um Abgleich, Cleanup-Markierung und Bereinigung für Aufgaben- und Task Flow-Status in der Vorschau anzuzeigen oder anzuwenden.
Der Abgleich ist laufzeitbewusst:
-- ACP-/Subagent-Aufgaben prüfen ihre zugehörige Untergeordnetensitzung.
-- Cron-Aufgaben prüfen, ob die Cron-Laufzeit den Job noch besitzt.
-- Chatgestützte CLI-Aufgaben prüfen den zugehörigen aktiven Ausführungskontext, nicht nur die Chat-Sitzungszeile.
+- ACP-/Subagent-Aufgaben prüfen ihre untergeordnete Sitzung.
+- Cron-Aufgaben prüfen, ob die Cron-Laufzeitumgebung den Job noch besitzt.
+- Chatgestützte CLI-Aufgaben prüfen den besitzenden Live-Laufkontext, nicht nur die Chat-Sitzungszeile.
Das Abschluss-Cleanup ist ebenfalls laufzeitbewusst:
-- Beim Subagent-Abschluss werden nach bestem Bemühen verfolgte Browser-Tabs/Prozesse für die untergeordnete Sitzung geschlossen, bevor das Cleanup der Ankündigung fortgesetzt wird.
-- Beim Abschluss isolierter Cron-Läufe werden nach bestem Bemühen verfolgte Browser-Tabs/Prozesse für die Cron-Sitzung geschlossen, bevor der Lauf vollständig heruntergefahren wird.
-- Die Zustellung isolierter Cron-Läufe wartet bei Bedarf auf nachgeordnetes Subagent-Follow-up und unterdrückt veralteten Bestätigungstext der übergeordneten Instanz, anstatt ihn anzukündigen.
-- Die Zustellung beim Subagent-Abschluss bevorzugt den neuesten sichtbaren Assistant-Text; falls dieser leer ist, wird auf bereinigten neuesten `tool`-/`toolResult`-Text zurückgegriffen, und reine Tool-Aufruf-Läufe mit Zeitüberschreitung können zu einer kurzen Zusammenfassung des Teilfortschritts verdichtet werden.
-- Cleanup-Fehler verdecken nicht das tatsächliche Aufgabenergebnis.
+- Der Subagent-Abschluss schließt nach bestem Bemühen nachverfolgte Browser-Tabs/Prozesse für die untergeordnete Sitzung, bevor das Ankündigungs-Cleanup fortgesetzt wird.
+- Der Abschluss eines isolierten Cron-Laufs schließt nach bestem Bemühen nachverfolgte Browser-Tabs/Prozesse für die Cron-Sitzung, bevor der Lauf vollständig heruntergefahren wird.
+- Die Zustellung isolierter Cron-Läufe wartet bei Bedarf nachgelagerte Subagent-Nacharbeit ab und unterdrückt veralteten Bestätigungstext des Elternteils, statt ihn anzukündigen.
+- Die Zustellung von Subagent-Abschlüssen bevorzugt den neuesten sichtbaren Assistant-Text; ist dieser leer, greift sie auf bereinigten neuesten tool-/toolResult-Text zurück, und reine Timeout-Tool-Call-Läufe können auf eine kurze Teilfortschritts-Zusammenfassung reduziert werden. Terminal fehlgeschlagene Läufe melden den Fehlerstatus, ohne erfassten Antworttext erneut wiederzugeben.
+- Cleanup-Fehler verschleiern nicht das tatsächliche Aufgabenergebnis.
### `tasks flow list|show|cancel`
@@ -237,17 +237,18 @@ openclaw tasks flow show [--json]
openclaw tasks flow cancel
```
-Verwenden Sie diese Befehle, wenn der orchestrierende TaskFlow das ist, was Sie interessiert, und nicht ein einzelner Hintergrundaufgabeneintrag.
+Verwenden Sie diese Befehle, wenn Sie sich eher für den orchestrierenden Task Flow interessieren als für einen einzelnen Datensatz einer Hintergrundaufgabe.
## Chat-Aufgabenboard (`/tasks`)
-Verwenden Sie `/tasks` in jeder Chatsitzung, um mit dieser Sitzung verknüpfte Hintergrundaufgaben anzuzeigen. Das Board zeigt aktive und kürzlich abgeschlossene Aufgaben mit Laufzeit, Status, Zeitangaben sowie Fortschritts- oder Fehlerdetails.
+Verwenden Sie `/tasks` in einer beliebigen Chat-Sitzung, um mit dieser Sitzung verknüpfte Hintergrundaufgaben zu sehen. Das Board zeigt aktive und kürzlich abgeschlossene Aufgaben mit Laufzeit, Status, Timing sowie Fortschritts- oder Fehlerdetails.
-Wenn die aktuelle Sitzung keine sichtbaren verknüpften Aufgaben hat, greift `/tasks` auf agentlokale Aufgabenzählungen zurück, sodass Sie weiterhin einen Überblick erhalten, ohne Details anderer Sitzungen offenzulegen.
+Wenn die aktuelle Sitzung keine sichtbar verknüpften Aufgaben hat, greift `/tasks` auf agentlokale Aufgabenzahlen zurück,
+damit Sie weiterhin einen Überblick erhalten, ohne Details anderer Sitzungen offenzulegen.
Für das vollständige Operator-Protokoll verwenden Sie die CLI: `openclaw tasks list`.
-## Statusintegration (Aufgabenlast)
+## Statusintegration (Aufgabendruck)
`openclaw status` enthält eine Aufgabenübersicht auf einen Blick:
@@ -261,62 +262,64 @@ Die Zusammenfassung meldet:
- **failures** — Anzahl von `failed` + `timed_out` + `lost`
- **byRuntime** — Aufschlüsselung nach `acp`, `subagent`, `cron`, `cli`
-Sowohl `/status` als auch das Tool `session_status` verwenden eine Cleanup-bewusste Aufgabenmomentaufnahme: Aktive Aufgaben werden bevorzugt, veraltete abgeschlossene Einträge werden ausgeblendet, und aktuelle Fehler werden nur angezeigt, wenn keine aktive Arbeit mehr verbleibt. So bleibt die Statuskarte auf das fokussiert, was gerade wichtig ist.
+Sowohl `/status` als auch das Tool `session_status` verwenden einen cleanupbewussten Aufgaben-Snapshot: Aktive Aufgaben werden bevorzugt,
+veraltete abgeschlossene Zeilen werden ausgeblendet, und aktuelle Fehler werden nur angezeigt, wenn keine aktive Arbeit
+mehr verbleibt. Dadurch bleibt die Statuskarte auf das fokussiert, was gerade wichtig ist.
## Speicherung und Wartung
### Wo Aufgaben gespeichert werden
-Aufgabeneinträge werden in SQLite gespeichert unter:
+Aufgabendatensätze werden in SQLite gespeichert unter:
```
$OPENCLAW_STATE_DIR/tasks/runs.sqlite
```
-Das Register wird beim Gateway-Start in den Speicher geladen und synchronisiert Schreibvorgänge nach SQLite, damit die Daten Neustarts überdauern.
+Die Registrierung wird beim Start des Gateway in den Speicher geladen und synchronisiert Schreibvorgänge nach SQLite, damit sie Neustarts überdauern.
### Automatische Wartung
-Ein Sweeper läuft alle **60 Sekunden** und übernimmt drei Dinge:
+Ein Sweeper läuft alle **60 Sekunden** und erledigt drei Dinge:
-1. **Abgleich** — prüft, ob aktive Aufgaben noch einen maßgeblichen Laufzeit-Backing-Status haben. ACP-/Subagent-Aufgaben verwenden den Status der Untergeordnetensitzung, Cron-Aufgaben die Eigentümerschaft aktiver Jobs, und chatgestützte CLI-Aufgaben den zugehörigen Ausführungskontext. Wenn dieser Backing-Status länger als 5 Minuten fehlt, wird die Aufgabe als `lost` markiert.
-2. **Cleanup-Zeitstempelung** — setzt für terminale Aufgaben einen Zeitstempel `cleanupAfter` (endedAt + 7 Tage).
-3. **Pruning** — löscht Einträge nach Erreichen ihres `cleanupAfter`-Datums.
+1. **Abgleich** — prüft, ob aktive Aufgaben noch eine autoritative Laufzeitstützung haben. ACP-/Subagent-Aufgaben verwenden den Status der untergeordneten Sitzung, Cron-Aufgaben die Inhaberschaft aktiver Jobs und chatgestützte CLI-Aufgaben den besitzenden Laufkontext. Wenn dieser Trägerstatus länger als 5 Minuten fehlt, wird die Aufgabe als `lost` markiert.
+2. **Cleanup-Markierung** — setzt bei Terminal-Aufgaben einen Zeitstempel `cleanupAfter` (endedAt + 7 Tage).
+3. **Bereinigung** — löscht Datensätze nach ihrem `cleanupAfter`-Datum.
-**Aufbewahrung**: Terminale Aufgabeneinträge werden **7 Tage** lang aufbewahrt und dann automatisch entfernt. Keine Konfiguration erforderlich.
+**Aufbewahrung**: Terminal-Aufgabendatensätze werden **7 Tage** lang aufbewahrt und danach automatisch bereinigt. Keine Konfiguration erforderlich.
## Wie Aufgaben mit anderen Systemen zusammenhängen
### Aufgaben und Task Flow
-[Task Flow](/de/automation/taskflow) ist die Flow-Orchestrierungsebene oberhalb von Hintergrundaufgaben. Ein einzelner Flow kann über seine Lebensdauer hinweg mehrere Aufgaben koordinieren, indem er verwaltete oder gespiegelte Synchronisationsmodi verwendet. Verwenden Sie `openclaw tasks`, um einzelne Aufgabeneinträge zu prüfen, und `openclaw tasks flow`, um den orchestrierenden Flow zu prüfen.
+[Task Flow](/de/automation/taskflow) ist die Flow-Orchestrierungsebene über Hintergrundaufgaben. Ein einzelner Flow kann über seine Lebensdauer hinweg mehrere Aufgaben koordinieren, indem er verwaltete oder gespiegelte Synchronisierungsmodi verwendet. Verwenden Sie `openclaw tasks`, um einzelne Aufgabendatensätze zu prüfen, und `openclaw tasks flow`, um den orchestrierenden Flow zu prüfen.
-Siehe [Task Flow](/de/automation/taskflow) für Details.
+Einzelheiten finden Sie unter [Task Flow](/de/automation/taskflow).
### Aufgaben und Cron
-Eine Cron-Job-**Definition** liegt in `~/.openclaw/cron/jobs.json`; der Laufzeit-Ausführungsstatus liegt daneben in `~/.openclaw/cron/jobs-state.json`. **Jede** Cron-Ausführung erstellt einen Aufgabeneintrag — sowohl in der Hauptsitzung als auch isoliert. Cron-Aufgaben der Hauptsitzung verwenden standardmäßig die Benachrichtigungsrichtlinie `silent`, sodass sie nachverfolgt werden, ohne Benachrichtigungen zu erzeugen.
+Eine Cron-Job-**Definition** liegt in `~/.openclaw/cron/jobs.json`; der Laufzeit-Ausführungsstatus liegt daneben in `~/.openclaw/cron/jobs-state.json`. **Jede** Cron-Ausführung erstellt einen Aufgabendatensatz — sowohl in der Hauptsitzung als auch isoliert. Cron-Aufgaben der Hauptsitzung verwenden standardmäßig die Benachrichtigungsrichtlinie `silent`, sodass sie nachverfolgt werden, ohne Benachrichtigungen zu erzeugen.
-Siehe [Cron Jobs](/de/automation/cron-jobs).
+Siehe [Cron-Jobs](/de/automation/cron-jobs).
### Aufgaben und Heartbeat
-Heartbeat-Läufe sind Durchläufe der Hauptsitzung — sie erstellen keine Aufgabeneinträge. Wenn eine Aufgabe abgeschlossen wird, kann sie ein Heartbeat-Wecksignal auslösen, damit Sie das Ergebnis umgehend sehen.
+Heartbeat-Läufe sind Turns der Hauptsitzung — sie erstellen keine Aufgabendatensätze. Wenn eine Aufgabe abgeschlossen wird, kann sie ein Heartbeat-Wake auslösen, damit Sie das Ergebnis umgehend sehen.
Siehe [Heartbeat](/de/gateway/heartbeat).
### Aufgaben und Sitzungen
-Eine Aufgabe kann auf einen `childSessionKey` verweisen (wo die Arbeit läuft) und auf einen `requesterSessionKey` (wer sie gestartet hat). Sitzungen sind der Gesprächskontext; Aufgaben sind die darüberliegende Aktivitätsverfolgung.
+Eine Aufgabe kann auf einen `childSessionKey` verweisen (wo die Arbeit ausgeführt wird) und auf einen `requesterSessionKey` (wer sie gestartet hat). Sitzungen sind Konversationskontext; Aufgaben sind die darüberliegende Aktivitätsverfolgung.
-### Aufgaben und Agentenläufe
+### Aufgaben und Agent-Läufe
-Die `runId` einer Aufgabe verknüpft sie mit dem Agentenlauf, der die Arbeit ausführt. Ereignisse im Agentenlebenszyklus (Start, Ende, Fehler) aktualisieren den Aufgabenstatus automatisch — Sie müssen den Lebenszyklus nicht manuell verwalten.
+Die `runId` einer Aufgabe verweist auf den Agent-Lauf, der die Arbeit ausführt. Ereignisse im Lebenszyklus des Agenten (Start, Ende, Fehler) aktualisieren den Aufgabenstatus automatisch — Sie müssen den Lebenszyklus nicht manuell verwalten.
## Verwandt
- [Automatisierung & Aufgaben](/de/automation) — alle Automatisierungsmechanismen auf einen Blick
-- [Task Flow](/de/automation/taskflow) — Flow-Orchestrierung oberhalb von Aufgaben
+- [Task Flow](/de/automation/taskflow) — Flow-Orchestrierung über Aufgaben
- [Geplante Aufgaben](/de/automation/cron-jobs) — Planung von Hintergrundarbeit
-- [Heartbeat](/de/gateway/heartbeat) — periodische Durchläufe der Hauptsitzung
-- [CLI: Tasks](/cli/index#tasks) — CLI-Befehlsreferenz
+- [Heartbeat](/de/gateway/heartbeat) — periodische Turns der Hauptsitzung
+- [CLI: Aufgaben](/cli/index#tasks) — CLI-Befehlsreferenz
diff --git a/docs/de/channels/synology-chat.md b/docs/de/channels/synology-chat.md
index 79f1e40cc..0421e48ab 100644
--- a/docs/de/channels/synology-chat.md
+++ b/docs/de/channels/synology-chat.md
@@ -1,30 +1,30 @@
---
read_when:
- - Beim Einrichten von Synology Chat mit OpenClaw
- - Beim Debuggen des Synology Chat-Webhook-Routings
-summary: Einrichtung von Synology Chat-Webhooks und OpenClaw-Konfiguration
+ - Einrichten von Synology Chat mit OpenClaw
+ - Fehlerbehebung beim Webhook-Routing von Synology Chat
+summary: Einrichtung des Synology-Chat-Webhooks und der OpenClaw-Konfiguration
title: Synology Chat
x-i18n:
- generated_at: "2026-04-05T12:36:18Z"
+ generated_at: "2026-04-21T19:20:44Z"
model: gpt-5.4
provider: openai
- source_hash: ddb25fc6b53f896f15f43b4936d69ea071a29a91838a5b662819377271e89d81
+ source_hash: 7288e2aa873ee1a1f57861d839cfb44ff324e3d40a7f36da07c6ba43cbe1e6e6
source_path: channels/synology-chat.md
workflow: 15
---
# Synology Chat
-Status: gebündelter Plugin-Kanal für Direktnachrichten mit Synology Chat-Webhooks.
-Das Plugin akzeptiert eingehende Nachrichten von ausgehenden Synology Chat-Webhooks und sendet Antworten
-über einen eingehenden Synology Chat-Webhook.
+Status: Gebündelter Plugin-Direktnachrichtenkanal mit Synology-Chat-Webhooks.
+Das Plugin akzeptiert eingehende Nachrichten von ausgehenden Synology-Chat-Webhooks und sendet Antworten
+über einen eingehenden Synology-Chat-Webhook.
## Gebündeltes Plugin
-Synology Chat wird in aktuellen OpenClaw-Versionen als gebündeltes Plugin mitgeliefert, daher benötigen normale
-Paket-Builds keine separate Installation.
+Synology Chat wird in aktuellen OpenClaw-Releases als gebündeltes Plugin ausgeliefert, daher
+benötigen normale paketierte Builds keine separate Installation.
-Wenn Sie eine ältere Version oder eine benutzerdefinierte Installation ohne Synology Chat verwenden,
+Wenn Sie einen älteren Build oder eine benutzerdefinierte Installation verwenden, die Synology Chat ausschließt,
installieren Sie es manuell:
Aus einem lokalen Checkout installieren:
@@ -33,25 +33,25 @@ Aus einem lokalen Checkout installieren:
openclaw plugins install ./path/to/local/synology-chat-plugin
```
-Details: [Plugins](/tools/plugin)
+Details: [Plugins](/de/tools/plugin)
## Schnelleinrichtung
-1. Stellen Sie sicher, dass das Synology Chat-Plugin verfügbar ist.
- - Aktuelle paketierte OpenClaw-Versionen enthalten es bereits.
+1. Stellen Sie sicher, dass das Synology-Chat-Plugin verfügbar ist.
+ - Aktuelle paketierte OpenClaw-Releases enthalten es bereits.
- Ältere/benutzerdefinierte Installationen können es mit dem obigen Befehl manuell aus einem Source-Checkout hinzufügen.
- - `openclaw onboard` zeigt Synology Chat jetzt in derselben Liste zur Kanaleinrichtung wie `openclaw channels add` an.
- - Nicht interaktive Einrichtung: `openclaw channels add --channel synology-chat --token --url `
-2. In den Synology Chat-Integrationen:
+ - `openclaw onboard` zeigt Synology Chat jetzt in derselben Kanaleinrichtungsliste wie `openclaw channels add` an.
+ - Nicht-interaktive Einrichtung: `openclaw channels add --channel synology-chat --token --url `
+2. In den Synology-Chat-Integrationen:
- Erstellen Sie einen eingehenden Webhook und kopieren Sie dessen URL.
- Erstellen Sie einen ausgehenden Webhook mit Ihrem geheimen Token.
-3. Richten Sie die URL des ausgehenden Webhooks auf Ihr OpenClaw-Gateway:
+3. Leiten Sie die URL des ausgehenden Webhooks an Ihr OpenClaw-Gateway weiter:
- Standardmäßig `https://gateway-host/webhook/synology`.
- - Oder Ihren benutzerdefinierten `channels.synology-chat.webhookPath`.
+ - Oder Ihr benutzerdefinierter `channels.synology-chat.webhookPath`.
4. Schließen Sie die Einrichtung in OpenClaw ab.
- Geführt: `openclaw onboard`
- Direkt: `openclaw channels add --channel synology-chat --token --url `
-5. Starten Sie das Gateway neu und senden Sie eine DM an den Synology Chat-Bot.
+5. Starten Sie das Gateway neu und senden Sie eine Direktnachricht an den Synology-Chat-Bot.
Details zur Webhook-Authentifizierung:
@@ -62,7 +62,7 @@ Details zur Webhook-Authentifizierung:
- `x-webhook-token`
- `x-openclaw-token`
- `Authorization: Bearer `
-- Leere oder fehlende Tokens schlagen fail-closed fehl.
+- Leere oder fehlende Token werden Fail-Closed abgewiesen.
Minimale Konfiguration:
@@ -98,19 +98,19 @@ Konfigurationswerte überschreiben Umgebungsvariablen.
## DM-Richtlinie und Zugriffskontrolle
-- `dmPolicy: "allowlist"` ist der empfohlene Standard.
+- `dmPolicy: "allowlist"` ist die empfohlene Standardeinstellung.
- `allowedUserIds` akzeptiert eine Liste (oder eine durch Kommas getrennte Zeichenfolge) von Synology-Benutzer-IDs.
-- Im Modus `allowlist` wird eine leere Liste `allowedUserIds` als Fehlkonfiguration behandelt und die Webhook-Route wird nicht gestartet (verwenden Sie `dmPolicy: "open"` für Zulassen-aller).
+- Im Modus `allowlist` wird eine leere `allowedUserIds`-Liste als Fehlkonfiguration behandelt, und die Webhook-Route wird nicht gestartet (verwenden Sie `dmPolicy: "open"` für Zugriff für alle).
- `dmPolicy: "open"` erlaubt jeden Absender.
-- `dmPolicy: "disabled"` blockiert DMs.
-- Die Bindung des Antwortempfängers bleibt standardmäßig an die stabile numerische `user_id` gebunden. `channels.synology-chat.dangerouslyAllowNameMatching: true` ist ein Break-Glass-Kompatibilitätsmodus, der die veränderliche Suche nach Benutzername/Spitzname für die Antwortzustellung wieder aktiviert.
-- Kopplungsgenehmigungen funktionieren mit:
+- `dmPolicy: "disabled"` blockiert Direktnachrichten.
+- Die Bindung des Antwortempfängers bleibt standardmäßig an die stabile numerische `user_id` gebunden. `channels.synology-chat.dangerouslyAllowNameMatching: true` ist ein Break-Glass-Kompatibilitätsmodus, der die Suche nach veränderbaren Benutzernamen/Spitznamen für die Antwortzustellung wieder aktiviert.
+- Pairing-Freigaben funktionieren mit:
- `openclaw pairing list synology-chat`
- `openclaw pairing approve synology-chat `
## Ausgehende Zustellung
-Verwenden Sie numerische Synology Chat-Benutzer-IDs als Ziele.
+Verwenden Sie numerische Synology-Chat-Benutzer-IDs als Ziele.
Beispiele:
@@ -119,19 +119,20 @@ openclaw message send --channel synology-chat --target 123456 --text "Hello from
openclaw message send --channel synology-chat --target synology-chat:123456 --text "Hello again"
```
-Das Senden von Medien wird durch URL-basierte Dateizustellung unterstützt.
+Das Senden von Medien wird über URL-basierte Dateizustellung unterstützt.
+Ausgehende Datei-URLs müssen `http` oder `https` verwenden, und private oder anderweitig blockierte Netzwerkziele werden abgewiesen, bevor OpenClaw die URL an den NAS-Webhook weiterleitet.
-## Multi-Account
+## Mehrere Konten
-Mehrere Synology Chat-Konten werden unter `channels.synology-chat.accounts` unterstützt.
+Mehrere Synology-Chat-Konten werden unter `channels.synology-chat.accounts` unterstützt.
Jedes Konto kann Token, eingehende URL, Webhook-Pfad, DM-Richtlinie und Limits überschreiben.
-Direktnachrichtensitzungen sind pro Konto und Benutzer isoliert, sodass dieselbe numerische `user_id`
-auf zwei verschiedenen Synology-Konten keinen gemeinsamen Transkriptzustand teilt.
-Geben Sie jedem aktivierten Konto einen eigenen `webhookPath`. OpenClaw lehnt jetzt doppelte exakte Pfade ab
-und verweigert den Start benannter Konten, die in Multi-Account-Setups nur einen gemeinsamen Webhook-Pfad erben.
-Wenn Sie absichtlich eine veraltete Vererbung für ein benanntes Konto benötigen, setzen Sie
+Direktnachrichtensitzungen werden pro Konto und Benutzer isoliert, sodass dieselbe numerische `user_id`
+in zwei verschiedenen Synology-Konten keinen gemeinsamen Transkriptstatus teilt.
+Geben Sie jedem aktivierten Konto einen eigenen `webhookPath`. OpenClaw weist jetzt doppelte exakte Pfade zurück
+und verweigert den Start benannter Konten, die in Mehrkontoeinrichtungen nur einen gemeinsamen Webhook-Pfad erben.
+Wenn Sie absichtlich Legacy-Vererbung für ein benanntes Konto benötigen, setzen Sie
`dangerouslyAllowInheritedWebhookPath: true` für dieses Konto oder unter `channels.synology-chat`,
-aber doppelte exakte Pfade werden weiterhin fail-closed abgelehnt. Bevorzugen Sie explizite Pfade pro Konto.
+aber doppelte exakte Pfade werden weiterhin Fail-Closed abgewiesen. Bevorzugen Sie explizite kontospezifische Pfade.
```json5
{
@@ -159,34 +160,34 @@ aber doppelte exakte Pfade werden weiterhin fail-closed abgelehnt. Bevorzugen Si
## Sicherheitshinweise
- Halten Sie `token` geheim und rotieren Sie es, wenn es offengelegt wurde.
-- Lassen Sie `allowInsecureSsl: false`, es sei denn, Sie vertrauen einem selbstsignierten lokalen NAS-Zertifikat ausdrücklich.
-- Eingehende Webhook-Anfragen werden tokenverifiziert und pro Absender ratenbegrenzt.
-- Prüfungen ungültiger Tokens verwenden einen Vergleich von Geheimnissen in konstanter Zeit und schlagen fail-closed fehl.
-- Bevorzugen Sie `dmPolicy: "allowlist"` für den Produktionseinsatz.
-- Lassen Sie `dangerouslyAllowNameMatching` deaktiviert, es sei denn, Sie benötigen ausdrücklich die veraltete antwortbasierte Zustellung über Benutzernamen.
-- Lassen Sie `dangerouslyAllowInheritedWebhookPath` deaktiviert, es sei denn, Sie akzeptieren ausdrücklich das Risiko gemeinsamen Pfad-Routings in einem Multi-Account-Setup.
+- Behalten Sie `allowInsecureSsl: false` bei, es sei denn, Sie vertrauen einem selbstsignierten lokalen NAS-Zertifikat ausdrücklich.
+- Eingehende Webhook-Anfragen werden per Token verifiziert und pro Absender ratelimitiert.
+- Prüfungen auf ungültige Token verwenden einen Secret-Vergleich in konstanter Zeit und werden Fail-Closed durchgeführt.
+- Bevorzugen Sie `dmPolicy: "allowlist"` für Produktionsumgebungen.
+- Lassen Sie `dangerouslyAllowNameMatching` deaktiviert, es sei denn, Sie benötigen ausdrücklich die Legacy-Antwortzustellung auf Basis von Benutzernamen.
+- Lassen Sie `dangerouslyAllowInheritedWebhookPath` deaktiviert, es sei denn, Sie akzeptieren ausdrücklich das Routing-Risiko eines gemeinsam genutzten Pfads in einer Mehrkontoeinrichtung.
## Fehlerbehebung
- `Missing required fields (token, user_id, text)`:
- - in der Nutzlast des ausgehenden Webhooks fehlt eines der erforderlichen Felder
+ - in der Payload des ausgehenden Webhooks fehlt eines der erforderlichen Felder
- wenn Synology das Token in Headern sendet, stellen Sie sicher, dass das Gateway/der Proxy diese Header beibehält
- `Invalid token`:
- - das Geheimnis des ausgehenden Webhooks stimmt nicht mit `channels.synology-chat.token` überein
- - die Anfrage trifft das falsche Konto/den falschen Webhook-Pfad
+ - das Secret des ausgehenden Webhooks stimmt nicht mit `channels.synology-chat.token` überein
+ - die Anfrage trifft das falsche Konto bzw. den falschen Webhook-Pfad
- ein Reverse-Proxy hat den Token-Header entfernt, bevor die Anfrage OpenClaw erreicht hat
- `Rate limit exceeded`:
- - zu viele ungültige Token-Versuche aus derselben Quelle können diese Quelle vorübergehend aussperren
- - authentifizierte Absender haben außerdem ein separates Ratenlimit pro Benutzer für Nachrichten
+ - zu viele Versuche mit ungültigem Token von derselben Quelle können diese Quelle vorübergehend sperren
+ - authentifizierte Absender haben außerdem ein separates Nachrichten-Ratelimit pro Benutzer
- `Allowlist is empty. Configure allowedUserIds or use dmPolicy=open.`:
- `dmPolicy="allowlist"` ist aktiviert, aber es sind keine Benutzer konfiguriert
- `User not authorized`:
- - die numerische `user_id` des Absenders ist nicht in `allowedUserIds`
+ - die numerische `user_id` des Absenders ist nicht in `allowedUserIds` enthalten
## Verwandt
-- [Channels Overview](/channels) — alle unterstützten Kanäle
-- [Pairing](/channels/pairing) — DM-Authentifizierung und Kopplungsablauf
-- [Groups](/channels/groups) — Verhalten in Gruppenchats und Mention-Gating
-- [Channel Routing](/channels/channel-routing) — Sitzungsrouting für Nachrichten
-- [Security](/gateway/security) — Zugriffsmodell und Härtung
+- [Channels Overview](/de/channels) — alle unterstützten Kanäle
+- [Pairing](/de/channels/pairing) — DM-Authentifizierung und Pairing-Ablauf
+- [Groups](/de/channels/groups) — Verhalten in Gruppenchats und Mention-Gating
+- [Channel Routing](/de/channels/channel-routing) — Sitzungsrouting für Nachrichten
+- [Security](/de/gateway/security) — Zugriffsmodell und Härtung
diff --git a/docs/de/ci.md b/docs/de/ci.md
index 14c21eefd..897b4e11a 100644
--- a/docs/de/ci.md
+++ b/docs/de/ci.md
@@ -1,46 +1,46 @@
---
read_when:
- Sie müssen verstehen, warum ein CI-Job ausgeführt wurde oder nicht.
- - Sie debuggen fehlschlagende GitHub-Actions-Checks.
+ - Sie debuggen fehlgeschlagene GitHub-Actions-Prüfungen.
summary: CI-Job-Graph, Scope-Gates und lokale Befehlsäquivalente
title: CI-Pipeline
x-i18n:
- generated_at: "2026-04-21T06:23:35Z"
+ generated_at: "2026-04-21T19:20:41Z"
model: gpt-5.4
provider: openai
- source_hash: 88a98d777fd61be1603417b71779aaf42a24d602b2437ad549f0075f22494cec
+ source_hash: 4d01a178402976cdf7c3c864695e8a12d3f7d1d069a77ea1b02a8aef2a3497f7
source_path: ci.md
workflow: 15
---
# CI-Pipeline
-Die CI läuft bei jedem Push auf `main` und bei jedem Pull Request. Sie verwendet intelligentes Scoping, um teure Jobs zu überspringen, wenn sich nur nicht zusammenhängende Bereiche geändert haben.
+Die CI läuft bei jedem Push auf `main` und bei jeder Pull Request. Sie verwendet intelligentes Scoping, um teure Jobs zu überspringen, wenn sich nur nicht zusammenhängende Bereiche geändert haben.
-## Job-Übersicht
+## Job-Überblick
-| Job | Zweck | Wann er ausgeführt wird |
-| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight` | Erkennt reine Doku-Änderungen, geänderte Scopes, geänderte Extensions und erstellt das CI-Manifest | Immer bei Nicht-Entwurfs-Pushes und PRs |
-| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Entwurfs-Pushes und PRs |
-| `security-dependency-audit` | Audit der produktiven Lockfile ohne Abhängigkeitsinstallation gegen npm-Advisories | Immer bei Nicht-Entwurfs-Pushes und PRs |
-| `security-fast` | Erforderliche Aggregation für die schnellen Sicherheitsjobs | Immer bei Nicht-Entwurfs-Pushes und PRs |
-| `build-artifacts` | Baut `dist/` und die Control UI einmal und lädt wiederverwendbare Artefakte für nachgelagerte Jobs hoch | Bei Node-relevanten Änderungen |
-| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie Bundled-/Plugin-Contract-/Protocol-Prüfungen | Bei Node-relevanten Änderungen |
-| `checks-fast-contracts-channels` | Gesplittete Channel-Contract-Prüfungen mit stabilem aggregiertem Check-Ergebnis | Bei Node-relevanten Änderungen |
-| `checks-node-extensions` | Vollständige Test-Shards für Bundled-Plugins über die gesamte Extension-Suite | Bei Node-relevanten Änderungen |
-| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, Bundled-, Contract- und Extension-Lanes | Bei Node-relevanten Änderungen |
-| `extension-fast` | Fokussierte Tests nur für die geänderten Bundled-Plugins | Wenn Extension-Änderungen erkannt werden |
-| `check` | Gesplittetes Äquivalent zum wichtigsten lokalen Gate: produktive Typen, Lint, Guards, Test-Typen und strikter Smoke-Test | Bei Node-relevanten Änderungen |
-| `check-additional` | Architecture-, Boundary-, Extension-Surface-Guards, Package-Boundary- und Gateway-Watch-Shards | Bei Node-relevanten Änderungen |
-| `build-smoke` | Smoke-Tests für die gebaute CLI und Startup-Memory-Smoke | Bei Node-relevanten Änderungen |
-| `checks` | Verbleibende Linux-Node-Lanes: Channel-Tests und nur bei Pushes Node-22-Kompatibilität | Bei Node-relevanten Änderungen |
-| `check-docs` | Doku-Formatierung, Lint und Broken-Link-Prüfungen | Wenn sich Doku geändert hat |
-| `skills-python` | Ruff + pytest für Python-basierte Skills | Bei Python-Skill-relevanten Änderungen |
-| `checks-windows` | Windows-spezifische Test-Lanes | Bei Windows-relevanten Änderungen |
-| `macos-node` | macOS-TypeScript-Test-Lane mit den gemeinsam genutzten Build-Artefakten | Bei macOS-relevanten Änderungen |
-| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | Bei macOS-relevanten Änderungen |
-| `android` | Android-Build- und Test-Matrix | Bei Android-relevanten Änderungen |
+| Job | Zweck | Wann er läuft |
+| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
+| `preflight` | Nur-Doku-Änderungen, geänderte Scopes, geänderte Extensions erkennen und das CI-Manifest erstellen | Immer bei Nicht-Entwurf-Pushes und PRs |
+| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Entwurf-Pushes und PRs |
+| `security-dependency-audit` | Audit der produktionsrelevanten Lockfile ohne Abhängigkeiten gegen npm-Sicherheitsmeldungen | Immer bei Nicht-Entwurf-Pushes und PRs |
+| `security-fast` | Erforderliche Aggregation für die schnellen Sicherheitsjobs | Immer bei Nicht-Entwurf-Pushes und PRs |
+| `build-artifacts` | `dist/` und die Control UI einmal bauen, wiederverwendbare Artefakte für nachgelagerte Jobs hochladen | Bei Node-relevanten Änderungen |
+| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie bundled-/plugin-contract-/protocol-Prüfungen | Bei Node-relevanten Änderungen |
+| `checks-fast-contracts-channels` | Gesplittete Kanal-Contract-Prüfungen mit einem stabilen aggregierten Prüfergebnis | Bei Node-relevanten Änderungen |
+| `checks-node-extensions` | Vollständige Test-Shards für bundled-Plugins über die gesamte Extension-Suite | Bei Node-relevanten Änderungen |
+| `checks-node-core-test` | Core-Node-Test-Shards, ausgenommen Kanal-, bundled-, Contract- und Extension-Lanes | Bei Node-relevanten Änderungen |
+| `extension-fast` | Fokussierte Tests nur für die geänderten bundled-Plugins | Wenn Extension-Änderungen erkannt werden |
+| `check` | Gesplittetes Äquivalent zum Haupt-Local-Gate: Prod-Typen, Lint, Guards, Test-Typen und strenger Smoke | Bei Node-relevanten Änderungen |
+| `check-additional` | Shards für Architektur-, Boundary-, Extension-Surface-Guards, Package-Boundary und Gateway-Watch | Bei Node-relevanten Änderungen |
+| `build-smoke` | Smoke-Tests für die gebaute CLI und Startup-Memory-Smoke | Bei Node-relevanten Änderungen |
+| `checks` | Verbleibende Linux-Node-Lanes: Kanaltests und nur bei Pushes Node-22-Kompatibilität | Bei Node-relevanten Änderungen |
+| `check-docs` | Doku-Formatierung, Lint- und Broken-Link-Prüfungen | Wenn sich Doku geändert hat |
+| `skills-python` | Ruff + pytest für Python-gestützte Skills | Bei Python-Skills-relevanten Änderungen |
+| `checks-windows` | Windows-spezifische Test-Lanes | Bei Windows-relevanten Änderungen |
+| `macos-node` | macOS-TypeScript-Test-Lane unter Verwendung der gemeinsam gebauten Artefakte | Bei macOS-relevanten Änderungen |
+| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | Bei macOS-relevanten Änderungen |
+| `android` | Android-Build- und Test-Matrix | Bei Android-relevanten Änderungen |
## Fail-Fast-Reihenfolge
@@ -48,42 +48,42 @@ Die Jobs sind so angeordnet, dass günstige Prüfungen fehlschlagen, bevor teure
1. `preflight` entscheidet, welche Lanes überhaupt existieren. Die Logik `docs-scope` und `changed-scope` sind Schritte innerhalb dieses Jobs, keine eigenständigen Jobs.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` und `skills-python` schlagen schnell fehl, ohne auf die schwereren Artefakt- und Plattform-Matrix-Jobs zu warten.
-3. `build-artifacts` überlappt sich mit den schnellen Linux-Lanes, damit nachgelagerte Verbraucher starten können, sobald der gemeinsame Build bereit ist.
+3. `build-artifacts` überlappt mit den schnellen Linux-Lanes, sodass nachgelagerte Verbraucher starten können, sobald der gemeinsame Build bereit ist.
4. Danach fächern sich die schwereren Plattform- und Runtime-Lanes auf: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` und `android`.
-Die Scope-Logik liegt in `scripts/ci-changed-scope.mjs` und wird durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt.
-Der separate Workflow `install-smoke` verwendet dasselbe Scope-Skript über seinen eigenen `preflight`-Job wieder. Er berechnet `run_install_smoke` aus dem engeren Signal `changed-smoke`, sodass Docker-/Install-Smoke nur bei install-, paketierungs- und containerrelevanten Änderungen ausgeführt wird.
+Die Scope-Logik liegt in `scripts/ci-changed-scope.mjs` und ist durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt.
+Der separate Workflow `install-smoke` verwendet dasselbe Scope-Skript über seinen eigenen Job `preflight` wieder. Er berechnet `run_install_smoke` aus dem engeren Signal `changed-smoke`, sodass Docker-/Install-Smoke nur bei Installations-, Packaging- und Container-relevanten Änderungen läuft.
-Die lokale Changed-Lane-Logik liegt in `scripts/changed-lanes.mjs` und wird von `scripts/check-changed.mjs` ausgeführt. Dieses lokale Gate ist bei Architekturgrenzen strenger als das breite CI-Plattform-Scoping: Änderungen an der Core-Production führen Core-Prod-Typecheck plus Core-Tests aus, reine Core-Test-Änderungen führen nur Core-Test-Typecheck/-Tests aus, Änderungen an der Extension-Production führen Extension-Prod-Typecheck plus Extension-Tests aus, und reine Extension-Test-Änderungen führen nur Extension-Test-Typecheck/-Tests aus. Änderungen am öffentlichen Plugin SDK oder an Plugin-Contracts erweitern auf Extension-Validierung, weil Extensions von diesen Core-Contracts abhängen. Unbekannte Root-/Config-Änderungen fallen aus Sicherheitsgründen auf alle Lanes zurück.
+Die lokale Changed-Lane-Logik liegt in `scripts/changed-lanes.mjs` und wird durch `scripts/check-changed.mjs` ausgeführt. Dieses lokale Gate ist bei Architekturgrenzen strenger als das breite CI-Plattform-Scoping: Änderungen an der Core-Production führen Core-Prod-Typecheck plus Core-Tests aus, Änderungen nur an Core-Tests führen nur Core-Test-Typecheck/-Tests aus, Änderungen an der Extension-Production führen Extension-Prod-Typecheck plus Extension-Tests aus, und Änderungen nur an Extension-Tests führen nur Extension-Test-Typecheck/-Tests aus. Öffentliche Änderungen am Plugin SDK oder plugin-contract erweitern die Extension-Validierung, weil Extensions von diesen Core-Contracts abhängen. Unbekannte Root-/Config-Änderungen fallen sicherheitshalber auf alle Lanes zurück.
-Bei Pushes ergänzt die `checks`-Matrix die nur bei Pushes ausgeführte Lane `compat-node22`. Bei Pull Requests wird diese Lane übersprungen und die Matrix bleibt auf die normalen Test-/Channel-Lanes fokussiert.
+Bei Pushes ergänzt die Matrix `checks` die nur bei Pushes vorhandene Lane `compat-node22`. Bei Pull Requests wird diese Lane übersprungen, und die Matrix bleibt auf die normalen Test-/Kanal-Lanes fokussiert.
-Die langsamsten Node-Testfamilien werden in Include-File-Shards aufgeteilt, damit jeder Job klein bleibt: Channel-Contracts teilen Registry- und Core-Abdeckung in jeweils acht gewichtete Shards auf, Auto-Reply-Reply-Command-Tests werden in vier Include-Pattern-Shards aufgeteilt, und die anderen großen Auto-Reply-Reply-Prefix-Gruppen werden jeweils in zwei Shards aufgeteilt. `check-additional` trennt außerdem Package-Boundary-Compile-/Canary-Arbeit von Runtime-Topology-Gateway-/Architecture-Arbeit.
+Die langsamsten Node-Testfamilien sind in Include-File-Shards aufgeteilt, damit jeder Job klein bleibt: Kanal-Contracts teilen Registry- und Core-Abdeckung in jeweils acht gewichtete Shards auf, Auto-Reply-Reply-Command-Tests sind in vier Include-Pattern-Shards aufgeteilt, und die anderen großen Auto-Reply-Reply-Prefix-Gruppen sind jeweils in zwei Shards aufgeteilt. `check-additional` trennt außerdem Package-Boundary-Compile-/Canary-Arbeit von Runtime-Topology-Gateway-/Architektur-Arbeit.
-GitHub kann überholte Jobs als `cancelled` markieren, wenn ein neuerer Push auf derselben PR oder demselben `main`-Ref landet. Behandeln Sie das als CI-Rauschen, es sei denn, der neueste Lauf für denselben Ref schlägt ebenfalls fehl. Die aggregierten Shard-Checks weisen explizit auf diesen Abbruchfall hin, damit er leichter von einem Testfehler zu unterscheiden ist.
+GitHub kann ersetzte Jobs als `cancelled` markieren, wenn ein neuerer Push auf derselben PR oder derselben Ref `main` landet. Behandeln Sie das als CI-Rauschen, es sei denn, auch der neueste Lauf für dieselbe Ref schlägt fehl. Die aggregierten Shard-Prüfungen weisen explizit auf diesen Abbruchfall hin, damit er leichter von einem Testfehler zu unterscheiden ist.
## Runner
| Runner | Jobs |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux-Checks, Doku-Checks, Python-Skills, `android` |
+| `blacksmith-16vcpu-ubuntu-2404` | `preflight`, `security-scm-fast`, `security-dependency-audit`, `security-fast`, `build-artifacts`, Linux-Prüfungen, Doku-Prüfungen, Python-Skills, `android` |
| `blacksmith-32vcpu-windows-2025` | `checks-windows` |
-| `macos-latest` | `macos-node`, `macos-swift` |
+| `blacksmith-12vcpu-macos-latest` | `macos-node`, `macos-swift` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück |
## Lokale Äquivalente
```bash
-pnpm changed:lanes # lokalen Changed-Lane-Klassifizierer für origin/main...HEAD prüfen
-pnpm check:changed # intelligentes lokales Gate: geänderte Typechecks/Lint/Tests nach Boundary-Lane
-pnpm check # schnelles lokales Gate: produktives tsgo + gesplittetes Lint + parallele schnelle Guards
+pnpm changed:lanes # lokalen Changed-Lane-Klassifikator für origin/main...HEAD prüfen
+pnpm check:changed # intelligentes lokales Gate: geänderte Typecheck-/Lint-/Tests nach Boundary-Lane
+pnpm check # schnelles lokales Gate: Produktions-tsgo + gesplittetes Lint + parallele schnelle Guards
pnpm check:test-types
-pnpm check:timed # dasselbe Gate mit Zeitmessungen pro Stufe
+pnpm check:timed # dasselbe Gate mit Zeiten pro Phase
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
pnpm test # Vitest-Tests
pnpm test:channels
pnpm test:contracts:channels
-pnpm check:docs # Doku-Formatierung + Lint + Broken-Links
-pnpm build # `dist` bauen, wenn CI-Artefakt-/build-smoke-Lanes relevant sind
+pnpm check:docs # Doku-Formatierung + Lint + Broken Links
+pnpm build # dist bauen, wenn CI-Artefakt-/build-smoke-Lanes relevant sind
```
diff --git a/docs/de/gateway/multiple-gateways.md b/docs/de/gateway/multiple-gateways.md
index 77e5c0484..7fe10619a 100644
--- a/docs/de/gateway/multiple-gateways.md
+++ b/docs/de/gateway/multiple-gateways.md
@@ -1,133 +1,158 @@
---
read_when:
- Mehr als ein Gateway auf demselben Rechner ausführen
- - Sie benötigen isolierte Konfiguration, isolierten Status und isolierte Ports pro Gateway
+ - Sie benötigen isolierte Konfigurationen/Zustände/Ports pro Gateway
summary: Mehrere OpenClaw Gateways auf einem Host ausführen (Isolation, Ports und Profile)
title: Mehrere Gateways
x-i18n:
- generated_at: "2026-04-21T17:45:33Z"
+ generated_at: "2026-04-21T19:20:40Z"
model: gpt-5.4
provider: openai
- source_hash: 8c3fcb921bc6596040e9249467964bd9dcd40ea7c16e958bb378247b0f994a7b
+ source_hash: 36796da339d5baea1704a7f42530030ea6ef4fa4bde43452ffec946b917ed4a3
source_path: gateway/multiple-gateways.md
workflow: 15
---
# Mehrere Gateways (derselbe Host)
-Die meisten Setups sollten ein Gateway verwenden, weil ein einzelnes Gateway mehrere Messaging-Verbindungen und Agents verarbeiten kann. Wenn Sie stärkere Isolation oder Redundanz benötigen, z. B. einen Rescue-Bot, führen Sie separate Gateways mit isolierten Profilen und Ports aus.
+Die meisten Setups sollten ein Gateway verwenden, weil ein einzelnes Gateway mehrere Messaging-Verbindungen und Agents verarbeiten kann. Wenn Sie stärkere Isolation oder Redundanz benötigen (z. B. einen Rescue-Bot), führen Sie separate Gateways mit isolierten Profilen/Ports aus.
-## Checkliste für die Isolation (erforderlich)
+## Am besten empfohlenes Setup
-- `OPENCLAW_CONFIG_PATH` — Konfigurationsdatei pro Instanz
-- `OPENCLAW_STATE_DIR` — Sitzungen, Anmeldedaten und Caches pro Instanz
-- `agents.defaults.workspace` — Workspace-Stammverzeichnis pro Instanz
-- `gateway.port` (oder `--port`) — eindeutig pro Instanz
-- Abgeleitete Ports (Browser/Canvas) dürfen sich nicht überschneiden
-
-Wenn diese gemeinsam genutzt werden, kommt es zu Konfigurations-Race-Conditions und Portkonflikten.
-
-## Empfohlen: Verwenden Sie das Standardprofil für das Hauptsystem und ein benanntes Profil für Rescue
-
-Profile grenzen `OPENCLAW_STATE_DIR` und `OPENCLAW_CONFIG_PATH` automatisch ab und hängen Suffixe an Dienstnamen an. Für die meisten Rescue-Bot-Setups sollten Sie den Haupt-Bot im Standardprofil belassen und nur dem Rescue-Bot ein benanntes Profil wie `rescue` geben.
-
-```bash
-# main (default profile)
-openclaw setup
-openclaw gateway --port 18789
-
-# rescue
-openclaw --profile rescue setup
-openclaw --profile rescue gateway --port 19001
-```
-
-Dienste:
-
-```bash
-openclaw gateway install
-openclaw --profile rescue gateway install
-```
-
-Wenn Sie möchten, dass beide Gateways benannte Profile verwenden, funktioniert das ebenfalls, ist aber nicht erforderlich.
-
-## Leitfaden für Rescue-Bots
-
-Empfohlenes Setup:
+Für die meisten Nutzer ist das einfachste Rescue-Bot-Setup:
- den Haupt-Bot im Standardprofil belassen
- den Rescue-Bot mit `--profile rescue` ausführen
- für das Rescue-Konto einen vollständig separaten Telegram-Bot verwenden
-- den Rescue-Bot auf einem anderen Basisport wie `19001` betreiben
+- den Rescue-Bot auf einem anderen Basis-Port wie `19789` belassen
-Dadurch bleibt der Rescue-Bot vom Haupt-Bot isoliert, sodass er Konfigurationsänderungen debuggen oder anwenden kann, wenn der primäre Bot ausgefallen ist. Lassen Sie zwischen den Basisports mindestens 20 Ports Abstand, damit sich die abgeleiteten Browser-/Canvas-/CDP-Ports niemals überschneiden.
+Dadurch bleibt der Rescue-Bot vom Haupt-Bot isoliert, sodass er Debugging durchführen oder
+Konfigurationsänderungen anwenden kann, wenn der primäre Bot ausfällt. Lassen Sie mindestens 20 Ports Abstand zwischen den
+Basis-Ports, damit die abgeleiteten Browser-/Canvas-/CDP-Ports niemals kollidieren.
-### Empfohlener Rescue-Kanal/-Account
+## Rescue-Bot-Schnellstart
-Verwenden Sie für die meisten Setups einen vollständig separaten Telegram-Bot für das Rescue-Profil.
-
-Warum Telegram:
-
-- leicht auf reine Operator-Nutzung beschränkbar
-- separates Bot-Token und separate Identität
-- unabhängig von der Kanal-/App-Installation des Haupt-Bots
-- einfacher DM-basierter Wiederherstellungspfad, wenn der Haupt-Bot defekt ist
-
-Wichtig ist die vollständige Unabhängigkeit: separates Bot-Konto, separate Anmeldedaten, separates OpenClaw-Profil, separater Workspace und separater Port.
-
-### Empfohlener Installationsablauf
-
-Verwenden Sie dies als Standard-Setup, sofern Sie keinen triftigen Grund haben, etwas anderes zu tun:
+Verwenden Sie dies als Standardpfad, sofern Sie keinen triftigen Grund haben, etwas
+anderes zu tun:
```bash
-# Main bot (default profile, port 18789)
-openclaw onboard
-openclaw gateway install
-
-# Rescue bot (separate Telegram bot, separate profile, port 19001)
+# Rescue-Bot (separater Telegram-Bot, separates Profil, Port 19789)
openclaw --profile rescue onboard
-openclaw --profile rescue gateway install
+openclaw --profile rescue gateway install --port 19789
```
+Wenn Ihr Haupt-Bot bereits läuft, ist das normalerweise alles, was Sie brauchen.
+
Während `openclaw --profile rescue onboard`:
-- verwenden Sie das separate Telegram-Bot-Token
-- behalten Sie das Profil `rescue` bei
-- verwenden Sie einen Basisport, der mindestens 20 höher ist als der des Haupt-Bots
-- übernehmen Sie den Standard-Workspace für Rescue, sofern Sie nicht bereits selbst einen verwalten
+- verwenden Sie den separaten Telegram-Bot-Token
+- behalten Sie das Profil `rescue`
+- verwenden Sie einen Basis-Port, der mindestens 20 höher ist als beim Haupt-Bot
+- akzeptieren Sie den Standard-Workspace für den Rescue-Bot, sofern Sie nicht bereits selbst einen verwalten
-Wenn das Onboarding den Rescue-Dienst bereits für Sie installiert hat, ist das abschließende `gateway install` nicht erforderlich.
+Wenn das Onboarding den Rescue-Dienst bereits für Sie installiert hat, ist das abschließende
+`gateway install` nicht erforderlich.
-### Was das Onboarding ändert
+## Warum das funktioniert
-`openclaw --profile rescue onboard` verwendet den normalen Onboarding-Ablauf, schreibt aber alles in ein separates Profil.
+Der Rescue-Bot bleibt unabhängig, weil er seine eigenen folgenden Ressourcen hat:
-In der Praxis bedeutet das, dass der Rescue-Bot Folgendes erhält:
+- Profil/Konfiguration
+- Zustandsverzeichnis
+- Workspace
+- Basis-Port (plus abgeleitete Ports)
+- Telegram-Bot-Token
-- eine eigene Konfigurationsdatei
-- ein eigenes Statusverzeichnis
-- einen eigenen Workspace (standardmäßig `~/.openclaw/workspace-rescue`)
-- einen eigenen Namen für den verwalteten Dienst
+Für die meisten Setups verwenden Sie für das Rescue-Profil einen vollständig separaten Telegram-Bot:
+
+- leicht auf nur Operatoren beschränkbar
+- separater Bot-Token und eigene Identität
+- unabhängig von der Kanal-/App-Installation des Haupt-Bots
+- einfacher DM-basierter Wiederherstellungspfad, wenn der Haupt-Bot defekt ist
+
+## Was `--profile rescue onboard` ändert
+
+`openclaw --profile rescue onboard` verwendet den normalen Onboarding-Ablauf, schreibt aber
+alles in ein separates Profil.
+
+In der Praxis bedeutet das, dass der Rescue-Bot seine eigenen folgenden Ressourcen erhält:
+
+- Konfigurationsdatei
+- Zustandsverzeichnis
+- Workspace (standardmäßig `~/.openclaw/workspace-rescue`)
+- Name des verwalteten Dienstes
Die Eingabeaufforderungen sind ansonsten dieselben wie beim normalen Onboarding.
+## Allgemeines Multi-Gateway-Setup
+
+Das oben gezeigte Rescue-Bot-Layout ist der einfachste Standard, aber dasselbe Isolationsmuster
+funktioniert für jedes Paar oder jede Gruppe von Gateways auf einem Host.
+
+Für ein allgemeineres Setup geben Sie jedem zusätzlichen Gateway sein eigenes benanntes Profil und seinen
+eigenen Basis-Port:
+
+```bash
+# main (Standardprofil)
+openclaw setup
+openclaw gateway --port 18789
+
+# zusätzliches Gateway
+openclaw --profile ops setup
+openclaw --profile ops gateway --port 19789
+```
+
+Wenn Sie möchten, dass beide Gateways benannte Profile verwenden, funktioniert das ebenfalls:
+
+```bash
+openclaw --profile main setup
+openclaw --profile main gateway --port 18789
+
+openclaw --profile ops setup
+openclaw --profile ops gateway --port 19789
+```
+
+Dienste folgen demselben Muster:
+
+```bash
+openclaw gateway install
+openclaw --profile ops gateway install --port 19789
+```
+
+Verwenden Sie den Rescue-Bot-Schnellstart, wenn Sie eine Fallback-Bedienebene möchten. Verwenden Sie das
+allgemeine Profilmuster, wenn Sie mehrere langlebige Gateways für
+verschiedene Kanäle, Mandanten, Workspaces oder betriebliche Rollen möchten.
+
+## Isolations-Checkliste
+
+Halten Sie diese Werte pro Gateway-Instanz eindeutig:
+
+- `OPENCLAW_CONFIG_PATH` — instanzspezifische Konfigurationsdatei
+- `OPENCLAW_STATE_DIR` — instanzspezifische Sitzungen, Zugangsdaten, Caches
+- `agents.defaults.workspace` — instanzspezifisches Workspace-Stammverzeichnis
+- `gateway.port` (oder `--port`) — eindeutig pro Instanz
+- abgeleitete Browser-/Canvas-/CDP-Ports
+
+Wenn diese gemeinsam genutzt werden, treten Konfigurationsrennen und Portkonflikte auf.
+
## Portzuordnung (abgeleitet)
-Basisport = `gateway.port` (oder `OPENCLAW_GATEWAY_PORT` / `--port`).
+Basis-Port = `gateway.port` (oder `OPENCLAW_GATEWAY_PORT` / `--port`).
-- Browser-Steuerungsdienst-Port = Basisport + 2 (nur loopback)
-- Canvas Host wird über den Gateway-HTTP-Server bereitgestellt (derselbe Port wie `gateway.port`)
-- CDP-Ports für Browser-Profile werden automatisch aus `browser.controlPort + 9 .. + 108` zugewiesen
+- Port des Browser-Steuerungsdienstes = Basis-Port + 2 (nur loopback)
+- Canvas-Host wird auf dem Gateway-HTTP-Server bereitgestellt (derselbe Port wie `gateway.port`)
+- CDP-Ports des Browser-Profils werden automatisch aus `browser.controlPort + 9 .. + 108` zugewiesen
-Wenn Sie einen dieser Werte in der Konfiguration oder per Umgebungsvariable überschreiben, müssen sie pro Instanz eindeutig bleiben.
+Wenn Sie einen dieser Werte in der Konfiguration oder in Umgebungsvariablen überschreiben, müssen Sie sie pro Instanz eindeutig halten.
-## Hinweise zu Browser/CDP (häufige Fehlerquelle)
+## Browser-/CDP-Hinweise (häufige Stolperfalle)
-- Legen Sie `browser.cdpUrl` auf mehreren Instanzen **nicht** auf dieselben Werte fest.
-- Jede Instanz benötigt ihren eigenen Browser-Steuerungsport und ihren eigenen CDP-Bereich (abgeleitet von ihrem Gateway-Port).
+- `browser.cdpUrl` **nicht** auf dieselben Werte bei mehreren Instanzen festlegen.
+- Jede Instanz benötigt ihren eigenen Browser-Steuerungsport und ihren eigenen CDP-Bereich (abgeleitet aus ihrem Gateway-Port).
- Wenn Sie explizite CDP-Ports benötigen, setzen Sie `browser.profiles..cdpPort` pro Instanz.
- Remote-Chrome: Verwenden Sie `browser.profiles..cdpUrl` (pro Profil, pro Instanz).
-## Beispiel für manuelle Umgebungsvariablen
+## Manuelles Umgebungsvariablen-Beispiel
```bash
OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \
@@ -136,7 +161,7 @@ openclaw gateway --port 18789
OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \
OPENCLAW_STATE_DIR=~/.openclaw-rescue \
-openclaw gateway --port 19001
+openclaw gateway --port 19789
```
## Schnelle Prüfungen
@@ -153,4 +178,4 @@ openclaw --profile rescue browser status
Interpretation:
- `gateway status --deep` hilft dabei, veraltete launchd-/systemd-/schtasks-Dienste aus älteren Installationen zu erkennen.
-- Warntexte von `gateway probe` wie `multiple reachable gateways detected` sind nur dann erwartbar, wenn Sie absichtlich mehr als ein isoliertes Gateway ausführen.
+- Warntext von `gateway probe` wie `multiple reachable gateways detected` ist nur dann zu erwarten, wenn Sie absichtlich mehr als ein isoliertes Gateway ausführen.
diff --git a/docs/de/plugins/manifest.md b/docs/de/plugins/manifest.md
index 8c0540bb7..44517e5c3 100644
--- a/docs/de/plugins/manifest.md
+++ b/docs/de/plugins/manifest.md
@@ -1,65 +1,77 @@
---
read_when:
- - Du erstellst ein OpenClaw Plugin
- - Du musst ein Plugin-Konfigurationsschema bereitstellen oder Plugin-Validierungsfehler beheben
-summary: Plugin-Manifest- und JSON-Schema-Anforderungen (strikte Konfigurationsvalidierung)
+ - Sie erstellen ein OpenClaw-Plugin
+ - Sie müssen ein Plugin-Konfigurationsschema bereitstellen oder Plugin-Validierungsfehler debuggen
+summary: Plugin-Manifest + JSON-Schema-Anforderungen (strikte Konfigurationsvalidierung)
title: Plugin-Manifest
x-i18n:
- generated_at: "2026-04-19T01:11:10Z"
+ generated_at: "2026-04-21T19:20:41Z"
model: gpt-5.4
provider: openai
- source_hash: 2dfc00759108ddee7bfcda8c42acf7f2d47451676447ba3caf8b5950f8a1c181
+ source_hash: 304c08035724dfb1ce6349972729b621aafc00880d4d259db78c22b86e9056ba
source_path: plugins/manifest.md
workflow: 15
---
# Plugin-Manifest (`openclaw.plugin.json`)
-Diese Seite gilt nur für das **native OpenClaw Plugin-Manifest**.
+Diese Seite gilt nur für das **native OpenClaw-Plugin-Manifest**.
-Kompatible Bundle-Layouts findest du unter [Plugin-Bundles](/de/plugins/bundles).
+Kompatible Bundle-Layouts finden Sie unter [Plugin-Bundles](/de/plugins/bundles).
Kompatible Bundle-Formate verwenden andere Manifestdateien:
- Codex-Bundle: `.codex-plugin/plugin.json`
-- Claude-Bundle: `.claude-plugin/plugin.json` oder das standardmäßige Claude-Komponenten-Layout ohne Manifest
+- Claude-Bundle: `.claude-plugin/plugin.json` oder das standardmäßige Claude-Komponenten-
+ Layout ohne Manifest
- Cursor-Bundle: `.cursor-plugin/plugin.json`
-OpenClaw erkennt diese Bundle-Layouts ebenfalls automatisch, sie werden jedoch nicht anhand des hier beschriebenen `openclaw.plugin.json`-Schemas validiert.
+OpenClaw erkennt diese Bundle-Layouts ebenfalls automatisch, sie werden jedoch
+nicht gegen das hier beschriebene Schema für `openclaw.plugin.json` validiert.
-Für kompatible Bundles liest OpenClaw derzeit Bundle-Metadaten sowie deklarierte Skill-Roots, Claude-Befehls-Roots, Claude-Bundle-`settings.json`-Standards, Claude-Bundle-LSP-Standards und unterstützte Hook-Packs, wenn das Layout den OpenClaw-Laufzeiterwartungen entspricht.
+Für kompatible Bundles liest OpenClaw derzeit Bundle-Metadaten sowie deklarierte
+Skill-Roots, Claude-Befehls-Roots, Standardwerte aus `settings.json` von
+Claude-Bundles, Claude-Bundle-LSP-Standardwerte und unterstützte Hook-Pakete,
+wenn das Layout den Laufzeiterwartungen von OpenClaw entspricht.
-Jedes native OpenClaw Plugin **muss** im **Plugin-Root** eine Datei `openclaw.plugin.json` bereitstellen. OpenClaw verwendet dieses Manifest, um die Konfiguration zu validieren, **ohne Plugin-Code auszuführen**. Fehlende oder ungültige Manifeste werden als Plugin-Fehler behandelt und blockieren die Konfigurationsvalidierung.
+Jedes native OpenClaw-Plugin **muss** eine Datei `openclaw.plugin.json` im
+**Plugin-Root** enthalten. OpenClaw verwendet dieses Manifest, um die
+Konfiguration zu validieren, **ohne Plugin-Code auszuführen**. Fehlende oder
+ungültige Manifeste werden als Plugin-Fehler behandelt und blockieren die
+Konfigurationsvalidierung.
-Siehe den vollständigen Leitfaden zum Plugin-System: [Plugins](/de/tools/plugin).
-Zum nativen Fähigkeitsmodell und den aktuellen Hinweisen zur externen Kompatibilität:
+Den vollständigen Leitfaden zum Plugin-System finden Sie unter: [Plugins](/de/tools/plugin).
+Zum nativen Fähigkeitsmodell und den aktuellen Richtlinien zur externen
+Kompatibilität:
[Fähigkeitsmodell](/de/plugins/architecture#public-capability-model).
-## Was diese Datei macht
+## Was diese Datei tut
-`openclaw.plugin.json` sind die Metadaten, die OpenClaw liest, bevor dein Plugin-Code geladen wird.
+`openclaw.plugin.json` sind die Metadaten, die OpenClaw liest, bevor es Ihren
+Plugin-Code lädt.
-Verwende sie für:
+Verwenden Sie sie für:
- Plugin-Identität
- Konfigurationsvalidierung
-- Authentifizierungs- und Onboarding-Metadaten, die ohne Starten der Plugin-Laufzeit verfügbar sein sollen
+- Authentifizierungs- und Onboarding-Metadaten, die verfügbar sein sollen, ohne die Plugin-
+ Laufzeit zu starten
- kostengünstige Aktivierungshinweise, die Control-Plane-Oberflächen vor dem Laden der Laufzeit prüfen können
-- kostengünstige Setup-Deskriptoren, die Setup-/Onboarding-Oberflächen vor dem Laden der Laufzeit prüfen können
-- Alias- und Auto-Enable-Metadaten, die vor dem Laden der Plugin-Laufzeit aufgelöst werden sollen
-- Kurzschreibweise-Metadaten zur Besitzerschaft von Modellfamilien, die das Plugin vor dem Laden der Laufzeit automatisch aktivieren sollen
-- statische Snapshots zur Besitzerschaft von Fähigkeiten, die für gebündelte Kompatibilitätsverdrahtung und Vertragsabdeckung verwendet werden
-- kostengünstige QA-Runner-Metadaten, die der gemeinsame `openclaw qa`-Host vor dem Laden der Plugin-Laufzeit prüfen kann
-- kanalspezifische Konfigurationsmetadaten, die in Katalog- und Validierungsoberflächen zusammengeführt werden sollen, ohne die Laufzeit zu laden
-- Hinweise für die Konfigurations-UI
+- kostengünstige Einrichtungsdeskriptoren, die Setup-/Onboarding-Oberflächen vor dem Laden der Laufzeit prüfen können
+- Alias- und Metadaten zur automatischen Aktivierung, die aufgelöst werden sollen, bevor die Plugin-Laufzeit lädt
+- Kurzform-Metadaten zur Besitzerschaft von Modellfamilien, die das Plugin vor dem Laden der Laufzeit automatisch aktivieren sollen
+- statische Snapshots der Fähigkeitszuordnung, die für gebündelte Kompatibilitätsverdrahtung und Vertragsabdeckung verwendet werden
+- kostengünstige QA-Runner-Metadaten, die der gemeinsame Host `openclaw qa` vor dem Laden der Plugin-Laufzeit prüfen kann
+- kanalspezifische Konfigurationsmetadaten, die sich in Katalog- und Validierungsoberflächen einfügen sollen, ohne die Laufzeit zu laden
+- Hinweise für die Konfigurations-Benutzeroberfläche
-Verwende sie nicht für:
+Verwenden Sie sie nicht für:
-- das Registrieren von Laufzeitverhalten
-- das Deklarieren von Code-Entrypoints
+- die Registrierung von Laufzeitverhalten
+- die Deklaration von Code-Einstiegspunkten
- npm-Installationsmetadaten
-Diese gehören in deinen Plugin-Code und in `package.json`.
+Diese gehören in Ihren Plugin-Code und in `package.json`.
## Minimales Beispiel
@@ -137,66 +149,69 @@ Diese gehören in deinen Plugin-Code und in `package.json`.
}
```
-## Referenz für Felder der obersten Ebene
+## Referenz der Felder auf oberster Ebene
| Feld | Erforderlich | Typ | Bedeutung |
| ----------------------------------- | ------------ | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `id` | Ja | `string` | Kanonische Plugin-ID. Dies ist die ID, die in `plugins.entries.` verwendet wird. |
| `configSchema` | Ja | `object` | Inline-JSON-Schema für die Konfiguration dieses Plugins. |
-| `enabledByDefault` | Nein | `true` | Kennzeichnet ein gebündeltes Plugin als standardmäßig aktiviert. Lasse das Feld weg oder setze einen beliebigen Wert ungleich `true`, damit das Plugin standardmäßig deaktiviert bleibt. |
-| `legacyPluginIds` | Nein | `string[]` | Veraltete IDs, die auf diese kanonische Plugin-ID normalisiert werden. |
-| `autoEnableWhenConfiguredProviders` | Nein | `string[]` | Provider-IDs, die dieses Plugin automatisch aktivieren sollen, wenn Auth, Konfiguration oder Modell-Referenzen sie erwähnen. |
-| `kind` | Nein | `"memory"` \| `"context-engine"` | Deklariert einen exklusiven Plugin-Typ, der von `plugins.slots.*` verwendet wird. |
-| `channels` | Nein | `string[]` | Kanal-IDs, die diesem Plugin gehören. Werden für Erkennung und Konfigurationsvalidierung verwendet. |
+| `enabledByDefault` | Nein | `true` | Kennzeichnet ein gebündeltes Plugin als standardmäßig aktiviert. Lassen Sie das Feld weg oder setzen Sie einen beliebigen Wert ungleich `true`, damit das Plugin standardmäßig deaktiviert bleibt. |
+| `legacyPluginIds` | Nein | `string[]` | Legacy-IDs, die auf diese kanonische Plugin-ID normalisiert werden. |
+| `autoEnableWhenConfiguredProviders` | Nein | `string[]` | Provider-IDs, die dieses Plugin automatisch aktivieren sollen, wenn Authentifizierung, Konfiguration oder Modellreferenzen sie erwähnen. |
+| `kind` | Nein | `"memory"` \| `"context-engine"` | Deklariert eine exklusive Plugin-Art, die von `plugins.slots.*` verwendet wird. |
+| `channels` | Nein | `string[]` | Kanal-IDs, die diesem Plugin gehören. Wird für Discovery und Konfigurationsvalidierung verwendet. |
| `providers` | Nein | `string[]` | Provider-IDs, die diesem Plugin gehören. |
-| `modelSupport` | Nein | `object` | Manifest-eigene Kurzschreibweise-Metadaten für Modellfamilien, die verwendet werden, um das Plugin vor der Laufzeit automatisch zu laden. |
-| `providerEndpoints` | Nein | `object[]` | Manifest-eigene Metadaten zu Endpoint-Hosts/-`baseUrl` für Provider-Routen, die der Core vor dem Laden der Provider-Laufzeit klassifizieren muss. |
-| `cliBackends` | Nein | `string[]` | IDs von CLI-Inferenz-Backends, die diesem Plugin gehören. Werden für die automatische Aktivierung beim Start anhand expliziter Konfigurationsreferenzen verwendet. |
-| `syntheticAuthRefs` | Nein | `string[]` | Provider- oder CLI-Backend-Referenzen, deren Plugin-eigener Synthetic-Auth-Hook während der kalten Modellerkennung geprüft werden soll, bevor die Laufzeit geladen wird. |
-| `nonSecretAuthMarkers` | Nein | `string[]` | Platzhalterwerte für API-Schlüssel, die einem gebündelten Plugin gehören und einen nicht geheimen lokalen, OAuth- oder ambienten Anmeldezustand repräsentieren. |
-| `commandAliases` | Nein | `object[]` | Befehlsnamen, die diesem Plugin gehören und vor dem Laden der Laufzeit pluginbewusste Konfigurations- und CLI-Diagnosen erzeugen sollen. |
-| `providerAuthEnvVars` | Nein | `Record` | Kostengünstige Metadaten zu Provider-Auth-Umgebungsvariablen, die OpenClaw ohne Laden von Plugin-Code prüfen kann. |
-| `providerAuthAliases` | Nein | `Record` | Provider-IDs, die für die Auth-Suche eine andere Provider-ID wiederverwenden sollen, zum Beispiel ein Coding-Provider, der denselben API-Schlüssel und dieselben Auth-Profile wie der Basis-Provider teilt. |
-| `channelEnvVars` | Nein | `Record` | Kostengünstige Metadaten zu Kanal-Umgebungsvariablen, die OpenClaw ohne Laden von Plugin-Code prüfen kann. Verwende dies für env-gesteuerte Kanal-Einrichtungs- oder Auth-Oberflächen, die generische Start-/Konfigurationshilfen sehen sollen. |
-| `providerAuthChoices` | Nein | `object[]` | Kostengünstige Metadaten zu Auth-Auswahlmöglichkeiten für Onboarding-Auswähler, bevorzugte Provider-Auflösung und einfache CLI-Flag-Verdrahtung. |
-| `activation` | Nein | `object` | Kostengünstige Aktivierungshinweise für provider-, befehls-, kanal-, routen- und fähigkeitsgesteuertes Laden. Nur Metadaten; die tatsächliche Laufzeitlogik bleibt im Plugin. |
-| `setup` | Nein | `object` | Kostengünstige Setup-/Onboarding-Deskriptoren, die Erkennungs- und Setup-Oberflächen ohne Laden der Plugin-Laufzeit prüfen können. |
-| `qaRunners` | Nein | `object[]` | Kostengünstige QA-Runner-Deskriptoren, die vom gemeinsamen `openclaw qa`-Host vor dem Laden der Plugin-Laufzeit verwendet werden. |
-| `contracts` | Nein | `object` | Statischer Snapshot gebündelter Fähigkeiten für Sprach-, Echtzeit-Transkriptions-, Echtzeit-Sprach-, Media-Understanding-, Bildgenerierungs-, Musikgenerierungs-, Videogenerierungs-, Web-Fetch-, Web-Suche- und Tool-Besitzerschaft. |
-| `channelConfigs` | Nein | `Record` | Manifest-eigene Kanal-Konfigurationsmetadaten, die vor dem Laden der Laufzeit in Erkennungs- und Validierungsoberflächen zusammengeführt werden. |
-| `skills` | Nein | `string[]` | Skill-Verzeichnisse, die relativ zum Plugin-Root geladen werden. |
+| `modelSupport` | Nein | `object` | Manifest-eigene Kurzform-Metadaten für Modellfamilien, die verwendet werden, um das Plugin vor der Laufzeit automatisch zu laden. |
+| `providerEndpoints` | Nein | `object[]` | Manifest-eigene Endpunkt-Metadaten zu Host/BaseUrl für Provider-Routen, die der Core vor dem Laden der Provider-Laufzeit klassifizieren muss. |
+| `cliBackends` | Nein | `string[]` | CLI-Inferenz-Backend-IDs, die diesem Plugin gehören. Wird für die automatische Aktivierung beim Start aus expliziten Konfigurationsreferenzen verwendet. |
+| `syntheticAuthRefs` | Nein | `string[]` | Provider- oder CLI-Backend-Referenzen, deren plugin-eigener synthetischer Auth-Hook während der kalten Modell-Discovery vor dem Laden der Laufzeit geprüft werden soll. |
+| `nonSecretAuthMarkers` | Nein | `string[]` | Platzhalterwerte für API-Schlüssel, die einem gebündelten Plugin gehören und einen nicht geheimen lokalen, OAuth- oder ambienten Anmeldedatenzustand darstellen. |
+| `commandAliases` | Nein | `object[]` | Befehlsnamen, die diesem Plugin gehören und vor dem Laden der Laufzeit Plugin-bewusste Konfigurations- und CLI-Diagnosen erzeugen sollen. |
+| `providerAuthEnvVars` | Nein | `Record` | Kostengünstige Umgebungsvariablen-Metadaten für Provider-Authentifizierung, die OpenClaw ohne Laden von Plugin-Code prüfen kann. |
+| `providerAuthAliases` | Nein | `Record` | Provider-IDs, die für die Authentifizierung eine andere Provider-ID wiederverwenden sollen, zum Beispiel ein Coding-Provider, der denselben API-Schlüssel und dieselben Auth-Profile wie der Basis-Provider nutzt. |
+| `channelEnvVars` | Nein | `Record` | Kostengünstige Umgebungsvariablen-Metadaten für Kanäle, die OpenClaw ohne Laden von Plugin-Code prüfen kann. Verwenden Sie dies für umgebungsvariablengesteuerte Kanaleinrichtung oder Auth-Oberflächen, die generische Start-/Konfigurationshelfer sehen sollen. |
+| `providerAuthChoices` | Nein | `object[]` | Kostengünstige Metadaten zu Authentifizierungsoptionen für Onboarding-Auswahlen, Auflösung bevorzugter Provider und einfache CLI-Flag-Verdrahtung. |
+| `activation` | Nein | `object` | Kostengünstige Aktivierungshinweise für durch Provider, Befehl, Kanal, Route und Fähigkeit ausgelöstes Laden. Nur Metadaten; die tatsächliche Logik bleibt weiterhin Eigentum der Plugin-Laufzeit. |
+| `setup` | Nein | `object` | Kostengünstige Setup-/Onboarding-Deskriptoren, die Discovery- und Setup-Oberflächen prüfen können, ohne die Plugin-Laufzeit zu laden. |
+| `qaRunners` | Nein | `object[]` | Kostengünstige QA-Runner-Deskriptoren, die vom gemeinsamen Host `openclaw qa` vor dem Laden der Plugin-Laufzeit verwendet werden. |
+| `contracts` | Nein | `object` | Statischer Snapshot gebündelter Fähigkeiten für Sprachverarbeitung, Echtzeittranskription, Echtzeitstimme, Medienverständnis, Bildgenerierung, Musikgenerierung, Videogenerierung, Web-Fetch, Websuche und Tool-Besitzerschaft. |
+| `channelConfigs` | Nein | `Record` | Manifest-eigene Kanal-Konfigurationsmetadaten, die vor dem Laden der Laufzeit in Discovery- und Validierungsoberflächen zusammengeführt werden. |
+| `skills` | Nein | `string[]` | Zu ladende Skills-Verzeichnisse, relativ zum Plugin-Root. |
| `name` | Nein | `string` | Menschenlesbarer Plugin-Name. |
| `description` | Nein | `string` | Kurze Zusammenfassung, die in Plugin-Oberflächen angezeigt wird. |
| `version` | Nein | `string` | Informative Plugin-Version. |
-| `uiHints` | Nein | `Record` | UI-Beschriftungen, Platzhalter und Sensitivitätshinweise für Konfigurationsfelder. |
+| `uiHints` | Nein | `Record` | UI-Beschriftungen, Platzhalter und Sensitivitätshinweise für Konfigurationsfelder. |
## Referenz für `providerAuthChoices`
-Jeder Eintrag in `providerAuthChoices` beschreibt eine Onboarding- oder Auth-Auswahlmöglichkeit.
+Jeder Eintrag in `providerAuthChoices` beschreibt eine einzelne Onboarding- oder Authentifizierungsoption.
OpenClaw liest dies, bevor die Provider-Laufzeit geladen wird.
-| Feld | Erforderlich | Typ | Bedeutung |
-| --------------------- | ------------ | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
-| `provider` | Ja | `string` | Provider-ID, zu der diese Auswahl gehört. |
-| `method` | Ja | `string` | Auth-Methoden-ID, an die weitergeleitet wird. |
-| `choiceId` | Ja | `string` | Stabile Auth-Auswahl-ID, die von Onboarding- und CLI-Abläufen verwendet wird. |
-| `choiceLabel` | Nein | `string` | Für Benutzer sichtbare Bezeichnung. Wenn ausgelassen, verwendet OpenClaw stattdessen `choiceId`. |
-| `choiceHint` | Nein | `string` | Kurzer Hilfetext für den Auswähler. |
-| `assistantPriority` | Nein | `number` | Niedrigere Werte werden in assistentengesteuerten interaktiven Auswählern früher sortiert. |
-| `assistantVisibility` | Nein | `"visible"` \| `"manual-only"` | Blendet die Auswahl in Assistenten-Auswählern aus, erlaubt aber weiterhin die manuelle Auswahl per CLI. |
-| `deprecatedChoiceIds` | Nein | `string[]` | Veraltete Auswahl-IDs, die Benutzer auf diese Ersatzauswahl umleiten sollen. |
-| `groupId` | Nein | `string` | Optionale Gruppen-ID zum Gruppieren verwandter Auswahlmöglichkeiten. |
-| `groupLabel` | Nein | `string` | Für Benutzer sichtbare Bezeichnung dieser Gruppe. |
-| `groupHint` | Nein | `string` | Kurzer Hilfetext für die Gruppe. |
-| `optionKey` | Nein | `string` | Interner Option-Key für einfache Auth-Abläufe mit nur einem Flag. |
-| `cliFlag` | Nein | `string` | Name des CLI-Flags, zum Beispiel `--openrouter-api-key`. |
-| `cliOption` | Nein | `string` | Vollständige CLI-Optionsform, zum Beispiel `--openrouter-api-key `. |
-| `cliDescription` | Nein | `string` | Beschreibung, die in der CLI-Hilfe verwendet wird. |
-| `onboardingScopes` | Nein | `Array<"text-inference" \| "image-generation">` | In welchen Onboarding-Oberflächen diese Auswahl erscheinen soll. Wenn ausgelassen, ist der Standardwert `["text-inference"]`. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| --------------------- | ------------ | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
+| `provider` | Ja | `string` | Provider-ID, zu der diese Option gehört. |
+| `method` | Ja | `string` | ID der Authentifizierungsmethode, an die weitergeleitet werden soll. |
+| `choiceId` | Ja | `string` | Stabile ID der Authentifizierungsoption, die von Onboarding- und CLI-Abläufen verwendet wird. |
+| `choiceLabel` | Nein | `string` | Benutzerseitige Bezeichnung. Falls weggelassen, verwendet OpenClaw stattdessen `choiceId`. |
+| `choiceHint` | Nein | `string` | Kurzer Hilfstext für die Auswahl. |
+| `assistantPriority` | Nein | `number` | Niedrigere Werte werden in assistentengesteuerten interaktiven Auswahlen früher sortiert. |
+| `assistantVisibility` | Nein | `"visible"` \| `"manual-only"` | Blendet die Option in Assistenten-Auswahlen aus, erlaubt aber weiterhin die manuelle Auswahl über die CLI. |
+| `deprecatedChoiceIds` | Nein | `string[]` | Legacy-IDs von Optionen, die Benutzer auf diese Ersatzoption umleiten sollen. |
+| `groupId` | Nein | `string` | Optionale Gruppen-ID zum Gruppieren verwandter Optionen. |
+| `groupLabel` | Nein | `string` | Benutzerseitige Bezeichnung für diese Gruppe. |
+| `groupHint` | Nein | `string` | Kurzer Hilfstext für die Gruppe. |
+| `optionKey` | Nein | `string` | Interner Optionsschlüssel für einfache Authentifizierungsabläufe mit einem einzelnen Flag. |
+| `cliFlag` | Nein | `string` | Name des CLI-Flags, zum Beispiel `--openrouter-api-key`. |
+| `cliOption` | Nein | `string` | Vollständige Form der CLI-Option, zum Beispiel `--openrouter-api-key `. |
+| `cliDescription` | Nein | `string` | Beschreibung für die CLI-Hilfe. |
+| `onboardingScopes` | Nein | `Array<"text-inference" \| "image-generation">` | In welchen Onboarding-Oberflächen diese Option erscheinen soll. Wenn weggelassen, wird standardmäßig `["text-inference"]` verwendet. |
## Referenz für `commandAliases`
-Verwende `commandAliases`, wenn ein Plugin einen Laufzeit-Befehlsnamen besitzt, den Benutzer versehentlich in `plugins.allow` eintragen oder als Root-CLI-Befehl ausführen könnten. OpenClaw verwendet diese Metadaten für Diagnosen, ohne Plugin-Laufzeitcode zu importieren.
+Verwenden Sie `commandAliases`, wenn ein Plugin einen Laufzeit-Befehlsnamen
+besitzt, den Benutzer fälschlicherweise in `plugins.allow` eintragen oder als
+CLI-Befehl auf Root-Ebene ausführen könnten. OpenClaw verwendet diese
+Metadaten für Diagnosen, ohne den Plugin-Laufzeitcode zu importieren.
```json
{
@@ -210,19 +225,24 @@ Verwende `commandAliases`, wenn ein Plugin einen Laufzeit-Befehlsnamen besitzt,
}
```
-| Feld | Erforderlich | Typ | Bedeutung |
-| ------------ | ------------ | ----------------- | ----------------------------------------------------------------------------- |
-| `name` | Ja | `string` | Befehlsname, der zu diesem Plugin gehört. |
-| `kind` | Nein | `"runtime-slash"` | Kennzeichnet den Alias als Chat-Slash-Befehl statt als Root-CLI-Befehl. |
-| `cliCommand` | Nein | `string` | Zugehöriger Root-CLI-Befehl, der für CLI-Operationen vorgeschlagen werden soll, falls vorhanden. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| ------------ | ------------ | ----------------- | ---------------------------------------------------------------------------- |
+| `name` | Ja | `string` | Befehlsname, der zu diesem Plugin gehört. |
+| `kind` | Nein | `"runtime-slash"` | Kennzeichnet den Alias als Chat-Slash-Befehl statt als CLI-Befehl auf Root-Ebene. |
+| `cliCommand` | Nein | `string` | Zugehöriger CLI-Befehl auf Root-Ebene, der für CLI-Operationen vorgeschlagen werden soll, falls vorhanden. |
## Referenz für `activation`
-Verwende `activation`, wenn das Plugin kostengünstig deklarieren kann, welche Control-Plane-Ereignisse es später aktivieren sollen.
+Verwenden Sie `activation`, wenn das Plugin kostengünstig deklarieren kann,
+welche Control-Plane-Ereignisse es später aktivieren sollen.
## Referenz für `qaRunners`
-Verwende `qaRunners`, wenn ein Plugin einen oder mehrere Transport-Runner unterhalb des gemeinsamen `openclaw qa`-Roots beiträgt. Halte diese Metadaten kostengünstig und statisch; die eigentliche CLI-Registrierung bleibt weiterhin in der Plugin-Laufzeit über eine schlanke `runtime-api.ts`-Oberfläche, die `qaRunnerCliRegistrations` exportiert.
+Verwenden Sie `qaRunners`, wenn ein Plugin einen oder mehrere Transport-Runner
+unterhalb des gemeinsamen Roots `openclaw qa` beiträgt. Halten Sie diese
+Metadaten kostengünstig und statisch; die tatsächliche CLI-Registrierung bleibt
+weiterhin Eigentum der Plugin-Laufzeit über eine leichtgewichtige
+`runtime-api.ts`-Oberfläche, die `qaRunnerCliRegistrations` exportiert.
```json
{
@@ -235,12 +255,17 @@ Verwende `qaRunners`, wenn ein Plugin einen oder mehrere Transport-Runner unterh
}
```
-| Feld | Erforderlich | Typ | Bedeutung |
-| ------------- | ------------ | -------- | --------------------------------------------------------------------- |
-| `commandName` | Ja | `string` | Unterbefehl, der unter `openclaw qa` eingehängt wird, zum Beispiel `matrix`. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| ------------- | ------------ | -------- | ------------------------------------------------------------------- |
+| `commandName` | Ja | `string` | Unterbefehl unter `openclaw qa`, zum Beispiel `matrix`. |
| `description` | Nein | `string` | Fallback-Hilfetext, der verwendet wird, wenn der gemeinsame Host einen Stub-Befehl benötigt. |
-Dieser Block enthält nur Metadaten. Er registriert kein Laufzeitverhalten und ersetzt nicht `register(...)`, `setupEntry` oder andere Laufzeit-/Plugin-Entrypoints. Aktuelle Verbraucher verwenden ihn als Eingrenzungshinweis vor breiterem Plugin-Laden; fehlende Aktivierungsmetadaten kosten daher meist nur Performance und sollten die Korrektheit nicht verändern, solange Fallbacks für veraltete Manifest-Besitzerschaft noch existieren.
+Dieser Block enthält nur Metadaten. Er registriert kein Laufzeitverhalten und
+ersetzt nicht `register(...)`, `setupEntry` oder andere Laufzeit-/Plugin-Einstiegspunkte.
+Aktuelle Verbraucher verwenden ihn als Eingrenzungshinweis vor einem breiteren
+Plugin-Laden, daher kostet fehlende Aktivierungsmetadaten in der Regel nur
+Leistung; die Korrektheit sollte sich nicht ändern, solange weiterhin Legacy-Fallbacks
+für Manifest-Besitzerschaft existieren.
```json
{
@@ -254,23 +279,28 @@ Dieser Block enthält nur Metadaten. Er registriert kein Laufzeitverhalten und e
}
```
-| Feld | Erforderlich | Typ | Bedeutung |
-| ---------------- | ------------ | ---------------------------------------------------- | ---------------------------------------------------------------- |
-| `onProviders` | Nein | `string[]` | Provider-IDs, die dieses Plugin bei Anforderung aktivieren sollen. |
-| `onCommands` | Nein | `string[]` | Befehls-IDs, die dieses Plugin aktivieren sollen. |
-| `onChannels` | Nein | `string[]` | Kanal-IDs, die dieses Plugin aktivieren sollen. |
-| `onRoutes` | Nein | `string[]` | Routen-Arten, die dieses Plugin aktivieren sollen. |
-| `onCapabilities` | Nein | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Breite Fähigkeitshinweise, die von der Control-Plane-Aktivierungsplanung verwendet werden. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| ---------------- | ------------ | ---------------------------------------------------- | -------------------------------------------------------------------- |
+| `onProviders` | Nein | `string[]` | Provider-IDs, die dieses Plugin aktivieren sollen, wenn sie angefordert werden. |
+| `onCommands` | Nein | `string[]` | Befehls-IDs, die dieses Plugin aktivieren sollen. |
+| `onChannels` | Nein | `string[]` | Kanal-IDs, die dieses Plugin aktivieren sollen. |
+| `onRoutes` | Nein | `string[]` | Route-Arten, die dieses Plugin aktivieren sollen. |
+| `onCapabilities` | Nein | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Allgemeine Fähigkeitshinweise, die von der Control Plane für die Aktivierungsplanung verwendet werden. |
Aktuelle Live-Verbraucher:
-- befehlsgesteuerte CLI-Planung greift auf veraltete `commandAliases[].cliCommand` oder `commandAliases[].name` zurück
-- kanalgetriggerte Setup-/Kanal-Planung greift auf veraltete Besitzerschaft über `channels[]` zurück, wenn explizite Kanal-Aktivierungsmetadaten fehlen
-- providergetriggerte Setup-/Laufzeitplanung greift auf veraltete Besitzerschaft über `providers[]` und `cliBackends[]` auf oberster Ebene zurück, wenn explizite Provider-Aktivierungsmetadaten fehlen
+- Befehlsausgelöste CLI-Planung greift auf Legacy-
+ `commandAliases[].cliCommand` oder `commandAliases[].name` zurück
+- kanalgetriggerte Setup-/Kanalplanung greift auf die Legacy-Besitzerschaft
+ `channels[]` zurück, wenn explizite Kanal-Aktivierungsmetadaten fehlen
+- providergetriggerte Setup-/Laufzeitplanung greift auf die Legacy-
+ Besitzerschaft `providers[]` und das Top-Level-Element `cliBackends[]`
+ zurück, wenn explizite Provider-Aktivierungsmetadaten fehlen
## Referenz für `setup`
-Verwende `setup`, wenn Setup- und Onboarding-Oberflächen kostengünstige plugin-eigene Metadaten benötigen, bevor die Laufzeit geladen wird.
+Verwenden Sie `setup`, wenn Setup- und Onboarding-Oberflächen vor dem Laden
+der Laufzeit kostengünstige, plugin-eigene Metadaten benötigen.
```json
{
@@ -289,32 +319,43 @@ Verwende `setup`, wenn Setup- und Onboarding-Oberflächen kostengünstige plugin
}
```
-`cliBackends` auf oberster Ebene bleibt gültig und beschreibt weiterhin CLI-Inferenz-Backends. `setup.cliBackends` ist die Setup-spezifische Deskriptor-Oberfläche für Control-Plane-/Setup-Abläufe, die reine Metadaten bleiben sollen.
+Das Top-Level-Feld `cliBackends` bleibt gültig und beschreibt weiterhin
+CLI-Inferenz-Backends. `setup.cliBackends` ist die setupspezifische
+Deskriptor-Oberfläche für Control-Plane-/Setup-Abläufe, die rein metadatenbasiert
+bleiben sollen.
-Wenn vorhanden, sind `setup.providers` und `setup.cliBackends` die bevorzugte Deskriptor-First-Lookup-Oberfläche für die Setup-Erkennung. Wenn der Deskriptor das Kandidaten-Plugin nur eingrenzt und das Setup weiterhin umfangreichere Laufzeit-Hooks zur Setup-Zeit benötigt, setze `requiresRuntime: true` und lasse `setup-api` als Fallback-Ausführungspfad bestehen.
+Falls vorhanden, sind `setup.providers` und `setup.cliBackends` die bevorzugte,
+deskriptororientierte Lookup-Oberfläche für die Setup-Discovery. Wenn der
+Deskriptor das Kandidaten-Plugin nur eingrenzt und das Setup dennoch
+umfangreichere Laufzeit-Hooks zur Setup-Zeit benötigt, setzen Sie
+`requiresRuntime: true` und belassen Sie `setup-api` als Fallback-Ausführungspfad.
-Da die Setup-Suche plugin-eigenen `setup-api`-Code ausführen kann, müssen normalisierte Werte in `setup.providers[].id` und `setup.cliBackends[]` über alle erkannten Plugins hinweg eindeutig bleiben. Mehrdeutige Besitzerschaft schlägt fail-closed fehl, anstatt anhand der Erkennungsreihenfolge einen Gewinner auszuwählen.
+Da das Setup-Lookup plugin-eigenen `setup-api`-Code ausführen kann, müssen
+normalisierte Werte in `setup.providers[].id` und `setup.cliBackends[]`
+pluginübergreifend eindeutig bleiben. Mehrdeutige Besitzerschaft schlägt
+geschlossen fehl, statt anhand der Discovery-Reihenfolge einen Gewinner zu wählen.
### Referenz für `setup.providers`
-| Feld | Erforderlich | Typ | Bedeutung |
-| ------------- | ------------ | ---------- | ------------------------------------------------------------------------------------------ |
-| `id` | Ja | `string` | Provider-ID, die während Setup oder Onboarding bereitgestellt wird. Halte normalisierte IDs global eindeutig. |
-| `authMethods` | Nein | `string[]` | Setup-/Auth-Methoden-IDs, die dieser Provider unterstützt, ohne die vollständige Laufzeit zu laden. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| ------------- | ------------ | ---------- | ----------------------------------------------------------------------------------------- |
+| `id` | Ja | `string` | Provider-ID, die während Setup oder Onboarding verfügbar gemacht wird. Halten Sie normalisierte IDs global eindeutig. |
+| `authMethods` | Nein | `string[]` | Setup-/Authentifizierungsmethoden-IDs, die dieser Provider unterstützt, ohne die vollständige Laufzeit zu laden. |
| `envVars` | Nein | `string[]` | Umgebungsvariablen, die generische Setup-/Status-Oberflächen prüfen können, bevor die Plugin-Laufzeit geladen wird. |
### `setup`-Felder
-| Feld | Erforderlich | Typ | Bedeutung |
-| ------------------ | ------------ | ---------- | ------------------------------------------------------------------------------------------------- |
-| `providers` | Nein | `object[]` | Provider-Setup-Deskriptoren, die während Setup und Onboarding bereitgestellt werden. |
-| `cliBackends` | Nein | `string[]` | Backend-IDs zur Setup-Zeit, die für Deskriptor-First-Setup-Lookups verwendet werden. Halte normalisierte IDs global eindeutig. |
-| `configMigrations` | Nein | `string[]` | IDs von Konfigurationsmigrationen, die der Setup-Oberfläche dieses Plugins gehören. |
-| `requiresRuntime` | Nein | `boolean` | Ob das Setup nach dem Deskriptor-Lookup weiterhin eine `setup-api`-Ausführung benötigt. |
+| Feld | Erforderlich | Typ | Bedeutung |
+| ------------------ | ------------ | ---------- | -------------------------------------------------------------------------------------------------- |
+| `providers` | Nein | `object[]` | Provider-Setup-Deskriptoren, die während Setup und Onboarding verfügbar gemacht werden. |
+| `cliBackends` | Nein | `string[]` | Backend-IDs zur Setup-Zeit, die für deskriptororientiertes Setup-Lookup verwendet werden. Halten Sie normalisierte IDs global eindeutig. |
+| `configMigrations` | Nein | `string[]` | IDs von Konfigurationsmigrationen, die der Setup-Oberfläche dieses Plugins gehören. |
+| `requiresRuntime` | Nein | `boolean` | Ob das Setup nach dem Deskriptor-Lookup weiterhin die Ausführung von `setup-api` benötigt. |
## Referenz für `uiHints`
-`uiHints` ist eine Zuordnung von Konfigurationsfeldnamen zu kleinen Rendering-Hinweisen.
+`uiHints` ist eine Zuordnung von Konfigurationsfeldnamen zu kleinen
+Rendering-Hinweisen.
```json
{
@@ -331,18 +372,19 @@ Da die Setup-Suche plugin-eigenen `setup-api`-Code ausführen kann, müssen norm
Jeder Feldhinweis kann Folgendes enthalten:
-| Feld | Typ | Bedeutung |
-| ------------- | ---------- | ------------------------------------------ |
-| `label` | `string` | Für Benutzer sichtbare Feldbezeichnung. |
-| `help` | `string` | Kurzer Hilfetext. |
-| `tags` | `string[]` | Optionale UI-Tags. |
-| `advanced` | `boolean` | Kennzeichnet das Feld als erweitert. |
+| Feld | Typ | Bedeutung |
+| ------------- | ---------- | ---------------------------------------- |
+| `label` | `string` | Benutzerseitige Feldbezeichnung. |
+| `help` | `string` | Kurzer Hilfetext. |
+| `tags` | `string[]` | Optionale UI-Tags. |
+| `advanced` | `boolean` | Kennzeichnet das Feld als erweitert. |
| `sensitive` | `boolean` | Kennzeichnet das Feld als geheim oder sensibel. |
-| `placeholder` | `string` | Platzhaltertext für Formulareingaben. |
+| `placeholder` | `string` | Platzhaltertext für Formulareingaben. |
## Referenz für `contracts`
-Verwende `contracts` nur für statische Metadaten zur Besitzerschaft von Fähigkeiten, die OpenClaw lesen kann, ohne die Plugin-Laufzeit zu importieren.
+Verwenden Sie `contracts` nur für statische Metadaten zur Fähigkeitszuordnung,
+die OpenClaw lesen kann, ohne die Plugin-Laufzeit zu importieren.
```json
{
@@ -362,21 +404,22 @@ Verwende `contracts` nur für statische Metadaten zur Besitzerschaft von Fähigk
Jede Liste ist optional:
-| Feld | Typ | Bedeutung |
-| -------------------------------- | ---------- | ------------------------------------------------------------------- |
-| `speechProviders` | `string[]` | IDs von Sprach-Providern, die diesem Plugin gehören. |
-| `realtimeTranscriptionProviders` | `string[]` | IDs von Providern für Echtzeit-Transkription, die diesem Plugin gehören. |
-| `realtimeVoiceProviders` | `string[]` | IDs von Providern für Echtzeit-Sprachfunktionen, die diesem Plugin gehören. |
-| `mediaUnderstandingProviders` | `string[]` | IDs von Providern für Media Understanding, die diesem Plugin gehören. |
-| `imageGenerationProviders` | `string[]` | IDs von Bildgenerierungs-Providern, die diesem Plugin gehören. |
-| `videoGenerationProviders` | `string[]` | IDs von Videogenerierungs-Providern, die diesem Plugin gehören. |
-| `webFetchProviders` | `string[]` | IDs von Web-Fetch-Providern, die diesem Plugin gehören. |
-| `webSearchProviders` | `string[]` | IDs von Web-Such-Providern, die diesem Plugin gehören. |
-| `tools` | `string[]` | Namen von Agent-Tools, die diesem Plugin für gebündelte Vertragsprüfungen gehören. |
+| Feld | Typ | Bedeutung |
+| -------------------------------- | ---------- | ----------------------------------------------------------------- |
+| `speechProviders` | `string[]` | Speech-Provider-IDs, die diesem Plugin gehören. |
+| `realtimeTranscriptionProviders` | `string[]` | Provider-IDs für Echtzeittranskription, die diesem Plugin gehören. |
+| `realtimeVoiceProviders` | `string[]` | Provider-IDs für Echtzeitstimme, die diesem Plugin gehören. |
+| `mediaUnderstandingProviders` | `string[]` | Provider-IDs für Medienverständnis, die diesem Plugin gehören. |
+| `imageGenerationProviders` | `string[]` | Provider-IDs für Bildgenerierung, die diesem Plugin gehören. |
+| `videoGenerationProviders` | `string[]` | Provider-IDs für Videogenerierung, die diesem Plugin gehören. |
+| `webFetchProviders` | `string[]` | Provider-IDs für Web-Fetch, die diesem Plugin gehören. |
+| `webSearchProviders` | `string[]` | Provider-IDs für Websuche, die diesem Plugin gehören. |
+| `tools` | `string[]` | Namen von Agent-Tools, die diesem Plugin für Prüfungen gebündelter Verträge gehören. |
## Referenz für `channelConfigs`
-Verwende `channelConfigs`, wenn ein Kanal-Plugin kostengünstige Konfigurationsmetadaten benötigt, bevor die Laufzeit geladen wird.
+Verwenden Sie `channelConfigs`, wenn ein Kanal-Plugin vor dem Laden der
+Laufzeit kostengünstige Konfigurationsmetadaten benötigt.
```json
{
@@ -405,17 +448,19 @@ Verwende `channelConfigs`, wenn ein Kanal-Plugin kostengünstige Konfigurationsm
Jeder Kanaleintrag kann Folgendes enthalten:
-| Feld | Typ | Bedeutung |
-| ------------- | ------------------------ | ------------------------------------------------------------------------------------------ |
+| Feld | Typ | Bedeutung |
+| ------------- | ------------------------ | ---------------------------------------------------------------------------------------------- |
| `schema` | `object` | JSON-Schema für `channels.`. Für jeden deklarierten Kanal-Konfigurationseintrag erforderlich. |
-| `uiHints` | `Record` | Optionale UI-Beschriftungen/Platzhalter/Sensitivitätshinweise für diesen Kanal-Konfigurationsabschnitt. |
-| `label` | `string` | Kanalbezeichnung, die in Auswähl- und Inspektionsoberflächen zusammengeführt wird, wenn Laufzeitmetadaten noch nicht bereit sind. |
-| `description` | `string` | Kurze Kanalbeschreibung für Inspektions- und Katalogoberflächen. |
-| `preferOver` | `string[]` | Veraltete oder niedriger priorisierte Plugin-IDs, die dieser Kanal in Auswahloberflächen übertreffen soll. |
+| `uiHints` | `Record` | Optionale UI-Beschriftungen/Platzhalter/Sensitivitätshinweise für diesen Abschnitt der Kanal-Konfiguration. |
+| `label` | `string` | Kanalbezeichnung, die in Auswahl- und Inspektionsoberflächen zusammengeführt wird, wenn Laufzeitmetadaten noch nicht bereit sind. |
+| `description` | `string` | Kurze Kanalbeschreibung für Inspektions- und Katalogoberflächen. |
+| `preferOver` | `string[]` | Legacy- oder Plugin-IDs mit niedrigerer Priorität, die dieser Kanal in Auswahloberflächen übertreffen soll. |
## Referenz für `modelSupport`
-Verwende `modelSupport`, wenn OpenClaw dein Provider-Plugin aus Kurzform-Modell-IDs wie `gpt-5.4` oder `claude-sonnet-4.6` ableiten soll, bevor die Plugin-Laufzeit geladen wird.
+Verwenden Sie `modelSupport`, wenn OpenClaw Ihr Provider-Plugin aus
+Kurzform-Modell-IDs wie `gpt-5.4` oder `claude-sonnet-4.6` ableiten soll, bevor
+die Plugin-Laufzeit geladen wird.
```json
{
@@ -426,60 +471,84 @@ Verwende `modelSupport`, wenn OpenClaw dein Provider-Plugin aus Kurzform-Modell-
}
```
-OpenClaw verwendet dabei diese Rangfolge:
+OpenClaw wendet dabei folgende Priorität an:
-- explizite `provider/model`-Referenzen verwenden die Manifest-Metadaten des besitzenden `providers`
+- explizite Referenzen `provider/model` verwenden die manifest-eigenen Metadaten des besitzenden `providers`
- `modelPatterns` haben Vorrang vor `modelPrefixes`
-- wenn sowohl ein nicht gebündeltes Plugin als auch ein gebündeltes Plugin übereinstimmen, gewinnt das nicht gebündelte Plugin
-- verbleibende Mehrdeutigkeiten werden ignoriert, bis der Benutzer oder die Konfiguration einen Provider angibt
+- wenn ein nicht gebündeltes Plugin und ein gebündeltes Plugin beide passen, gewinnt das nicht gebündelte Plugin
+- verbleibende Mehrdeutigkeit wird ignoriert, bis der Benutzer oder die Konfiguration einen Provider angibt
Felder:
-| Feld | Typ | Bedeutung |
-| --------------- | ---------- | ------------------------------------------------------------------------------------- |
-| `modelPrefixes` | `string[]` | Präfixe, die mit `startsWith` mit Kurzform-Modell-IDs abgeglichen werden. |
-| `modelPatterns` | `string[]` | Regex-Quellen, die nach Entfernen des Profil-Suffixes mit Kurzform-Modell-IDs abgeglichen werden. |
+| Feld | Typ | Bedeutung |
+| --------------- | ---------- | ----------------------------------------------------------------------------------- |
+| `modelPrefixes` | `string[]` | Präfixe, die per `startsWith` mit Kurzform-Modell-IDs abgeglichen werden. |
+| `modelPatterns` | `string[]` | Regex-Quellen, die nach dem Entfernen des Profil-Suffixes mit Kurzform-Modell-IDs abgeglichen werden. |
-Veraltete Capability-Schlüssel auf oberster Ebene sind deprecated. Verwende `openclaw doctor --fix`, um `speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders` und `webSearchProviders` unter `contracts` zu verschieben; das normale Laden des Manifests behandelt diese Felder auf oberster Ebene nicht mehr als Besitzerschaft von Fähigkeiten.
+Legacy-Fähigkeitsschlüssel auf oberster Ebene sind veraltet. Verwenden Sie
+`openclaw doctor --fix`, um `speechProviders`,
+`realtimeTranscriptionProviders`, `realtimeVoiceProviders`,
+`mediaUnderstandingProviders`, `imageGenerationProviders`,
+`videoGenerationProviders`, `webFetchProviders` und
+`webSearchProviders` unter `contracts` zu verschieben; das normale
+Laden von Manifesten behandelt diese Felder auf oberster Ebene nicht mehr als
+Fähigkeitszuordnung.
## Manifest im Vergleich zu `package.json`
Die beiden Dateien erfüllen unterschiedliche Aufgaben:
-| Datei | Verwende sie für |
-| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `openclaw.plugin.json` | Erkennung, Konfigurationsvalidierung, Metadaten zu Auth-Auswahlmöglichkeiten und UI-Hinweise, die vorhanden sein müssen, bevor Plugin-Code ausgeführt wird |
-| `package.json` | npm-Metadaten, Abhängigkeitsinstallation und den `openclaw`-Block, der für Entrypoints, Installations-Gating, Setup oder Katalogmetadaten verwendet wird |
+| Datei | Verwenden Sie sie für |
+| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| `openclaw.plugin.json` | Discovery, Konfigurationsvalidierung, Metadaten zu Authentifizierungsoptionen und UI-Hinweise, die vorhanden sein müssen, bevor Plugin-Code ausgeführt wird |
+| `package.json` | npm-Metadaten, Installation von Abhängigkeiten und den Block `openclaw`, der für Einstiegspunkte, Installations-Gating, Setup oder Katalogmetadaten verwendet wird |
-Wenn du dir unsicher bist, wohin ein Metadatum gehört, verwende diese Regel:
+Wenn Sie unsicher sind, wohin ein Metadatenelement gehört, verwenden Sie diese Regel:
- wenn OpenClaw es kennen muss, bevor Plugin-Code geladen wird, gehört es in `openclaw.plugin.json`
-- wenn es um Packaging, Entry-Dateien oder das npm-Installationsverhalten geht, gehört es in `package.json`
+- wenn es um Packaging, Einstiegsdateien oder das npm-Installationsverhalten geht, gehört es in `package.json`
-### `package.json`-Felder, die die Erkennung beeinflussen
+### `package.json`-Felder, die Discovery beeinflussen
-Einige Plugin-Metadaten vor der Laufzeit befinden sich absichtlich in `package.json` unter dem `openclaw`-Block statt in `openclaw.plugin.json`.
+Einige Plugin-Metadaten vor der Laufzeit befinden sich absichtlich in
+`package.json` unter dem Block `openclaw` statt in `openclaw.plugin.json`.
Wichtige Beispiele:
-| Feld | Bedeutung |
-| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `openclaw.extensions` | Deklariert native Plugin-Entrypoints. |
-| `openclaw.setupEntry` | Leichtgewichtiger Setup-only-Entrypoint, der während Onboarding und verzögertem Kanalstart verwendet wird. |
-| `openclaw.channel` | Kostengünstige Kanal-Katalogmetadaten wie Bezeichnungen, Doku-Pfade, Aliasse und Auswahltexte. |
-| `openclaw.channel.configuredState` | Leichtgewichtige Metadaten für einen Checker des konfigurierten Zustands, der „existiert bereits ein nur per env eingerichtetes Setup?“ beantworten kann, ohne die vollständige Kanal-Laufzeit zu laden. |
-| `openclaw.channel.persistedAuthState` | Leichtgewichtige Metadaten für einen Checker persistierter Auth-Zustände, der „ist bereits irgendwo angemeldet?“ beantworten kann, ohne die vollständige Kanal-Laufzeit zu laden. |
-| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Installations-/Update-Hinweise für gebündelte und extern veröffentlichte Plugins. |
-| `openclaw.install.defaultChoice` | Bevorzugter Installationspfad, wenn mehrere Installationsquellen verfügbar sind. |
-| `openclaw.install.minHostVersion` | Minimale unterstützte OpenClaw-Host-Version, unter Verwendung einer Semver-Untergrenze wie `>=2026.3.22`. |
-| `openclaw.install.allowInvalidConfigRecovery` | Erlaubt einen eng begrenzten Wiederherstellungspfad zur Neuinstallation gebündelter Plugins, wenn die Konfiguration ungültig ist. |
-| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Ermöglicht, dass Setup-only-Kanaloberflächen beim Start vor dem vollständigen Kanal-Plugin geladen werden. |
+| Feld | Bedeutung |
+| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| `openclaw.extensions` | Deklariert native Plugin-Einstiegspunkte. |
+| `openclaw.setupEntry` | Leichtgewichtiger, nur für Setup vorgesehener Einstiegspunkt, der beim Onboarding, verzögertem Kanalstart und bei schreibgeschützter Discovery von Kanalstatus/SecretRef verwendet wird. |
+| `openclaw.channel` | Kostengünstige Kanal-Katalogmetadaten wie Bezeichnungen, Dokumentationspfade, Aliasse und Auswahltexte. |
+| `openclaw.channel.configuredState` | Leichtgewichtige Metadaten für den Prüfer des konfigurierten Zustands, die beantworten können: „Existiert bereits ein nur per Umgebungsvariablen eingerichtetes Setup?“ ohne die vollständige Kanal-Laufzeit zu laden. |
+| `openclaw.channel.persistedAuthState` | Leichtgewichtige Metadaten für den Prüfer des persistierten Authentifizierungszustands, die beantworten können: „Ist bereits irgendetwas angemeldet?“ ohne die vollständige Kanal-Laufzeit zu laden. |
+| `openclaw.install.npmSpec` / `openclaw.install.localPath` | Hinweise zur Installation/Aktualisierung für gebündelte und extern veröffentlichte Plugins. |
+| `openclaw.install.defaultChoice` | Bevorzugter Installationspfad, wenn mehrere Installationsquellen verfügbar sind. |
+| `openclaw.install.minHostVersion` | Minimal unterstützte OpenClaw-Host-Version mit einer Semver-Untergrenze wie `>=2026.3.22`. |
+| `openclaw.install.allowInvalidConfigRecovery` | Erlaubt einen engen Wiederherstellungspfad für die Neuinstallation gebündelter Plugins, wenn die Konfiguration ungültig ist. |
+| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Erlaubt, dass Setup-only-Kanaloberflächen beim Start vor dem vollständigen Kanal-Plugin geladen werden. |
-`openclaw.install.minHostVersion` wird während der Installation und beim Laden der Manifest-Registry erzwungen. Ungültige Werte werden abgelehnt; neuere, aber gültige Werte überspringen das Plugin auf älteren Hosts.
+`openclaw.install.minHostVersion` wird während der Installation und beim Laden
+der Manifest-Registry erzwungen. Ungültige Werte werden abgelehnt; neuere, aber
+gültige Werte überspringen das Plugin auf älteren Hosts.
-`openclaw.install.allowInvalidConfigRecovery` ist absichtlich eng begrenzt. Es macht nicht beliebige fehlerhafte Konfigurationen installierbar. Derzeit erlaubt es Installationsabläufen nur, sich von bestimmten veralteten Upgrade-Fehlern gebündelter Plugins zu erholen, etwa einem fehlenden gebündelten Plugin-Pfad oder einem veralteten `channels.`-Eintrag für dasselbe gebündelte Plugin. Nicht zusammenhängende Konfigurationsfehler blockieren weiterhin die Installation und verweisen Betreiber auf `openclaw doctor --fix`.
+Kanal-Plugins sollten `openclaw.setupEntry` bereitstellen, wenn Status,
+Kanalliste oder SecretRef-Scans konfigurierte Konten identifizieren müssen,
+ohne die vollständige Laufzeit zu laden. Der Setup-Einstiegspunkt sollte
+Kanalmetadaten sowie setupsichere Adapter für Konfiguration, Status und
+Geheimnisse bereitstellen; behalten Sie Netzwerkclients, Gateway-Listener und
+Transport-Laufzeiten im Haupteinstiegspunkt der Erweiterung.
-`openclaw.channel.persistedAuthState` ist Paketmetadaten für ein kleines Checker-Modul:
+`openclaw.install.allowInvalidConfigRecovery` ist absichtlich eng gefasst. Es
+macht nicht beliebige defekte Konfigurationen installierbar. Derzeit erlaubt es
+Installationsabläufen nur, sich von bestimmten veralteten Upgrade-Fehlern
+gebündelter Plugins zu erholen, etwa einem fehlenden Pfad zu einem gebündelten
+Plugin oder einem veralteten Eintrag `channels.` für dasselbe gebündelte
+Plugin. Nicht zusammenhängende Konfigurationsfehler blockieren weiterhin die
+Installation und verweisen Operatoren auf `openclaw doctor --fix`.
+
+`openclaw.channel.persistedAuthState` sind Paketmetadaten für ein kleines
+Prüfmodul:
```json
{
@@ -495,9 +564,14 @@ Wichtige Beispiele:
}
```
-Verwende dies, wenn Setup-, Doctor- oder Abläufe für den konfigurierten Zustand eine kostengünstige Ja/Nein-Auth-Prüfung benötigen, bevor das vollständige Kanal-Plugin geladen wird. Das Ziel-Export sollte eine kleine Funktion sein, die nur persistierten Zustand liest; führe sie nicht über das vollständige Kanal-Laufzeit-Barrel.
+Verwenden Sie dies, wenn Setup-, Doctor- oder Abläufe für den konfigurierten
+Zustand vor dem Laden des vollständigen Kanal-Plugins eine kostengünstige
+Ja/Nein-Prüfung der Authentifizierung benötigen. Das Zielexport sollte eine
+kleine Funktion sein, die nur persistierten Zustand liest; leiten Sie dies
+nicht über das vollständige Barrel der Kanal-Laufzeit.
-`openclaw.channel.configuredState` folgt derselben Form für kostengünstige Prüfungen eines nur per env konfigurierten Zustands:
+`openclaw.channel.configuredState` folgt derselben Form für kostengünstige
+Prüfungen des konfigurierten Zustands nur per Umgebungsvariablen:
```json
{
@@ -513,46 +587,78 @@ Verwende dies, wenn Setup-, Doctor- oder Abläufe für den konfigurierten Zustan
}
```
-Verwende dies, wenn ein Kanal den konfigurierten Zustand aus env oder anderen kleinen Nicht-Laufzeit-Eingaben beantworten kann. Wenn die Prüfung vollständige Konfigurationsauflösung oder die echte Kanal-Laufzeit benötigt, belasse diese Logik stattdessen im Plugin-Hook `config.hasConfiguredState`.
+Verwenden Sie dies, wenn ein Kanal den konfigurierten Zustand aus
+Umgebungsvariablen oder anderen kleinen Nicht-Laufzeit-Eingaben beantworten
+kann. Wenn die Prüfung eine vollständige Auflösung der Konfiguration oder die
+echte Kanal-Laufzeit benötigt, belassen Sie diese Logik stattdessen im
+Plugin-Hook `config.hasConfiguredState`.
## JSON-Schema-Anforderungen
- **Jedes Plugin muss ein JSON-Schema bereitstellen**, auch wenn es keine Konfiguration akzeptiert.
-- Ein leeres Schema ist zulässig, zum Beispiel `{ "type": "object", "additionalProperties": false }`.
+- Ein leeres Schema ist zulässig (zum Beispiel `{ "type": "object", "additionalProperties": false }`).
- Schemata werden beim Lesen/Schreiben der Konfiguration validiert, nicht zur Laufzeit.
## Validierungsverhalten
-- Unbekannte `channels.*`-Schlüssel sind **Fehler**, es sei denn, die Kanal-ID ist durch ein Plugin-Manifest deklariert.
-- `plugins.entries.`, `plugins.allow`, `plugins.deny` und `plugins.slots.*` müssen auf **erkennbare** Plugin-IDs verweisen. Unbekannte IDs sind **Fehler**.
-- Wenn ein Plugin installiert ist, aber ein fehlerhaftes oder fehlendes Manifest oder Schema hat, schlägt die Validierung fehl und Doctor meldet den Plugin-Fehler.
-- Wenn eine Plugin-Konfiguration existiert, das Plugin aber **deaktiviert** ist, bleibt die Konfiguration erhalten und in Doctor sowie den Logs wird eine **Warnung** angezeigt.
+- Unbekannte `channels.*`-Schlüssel sind **Fehler**, es sei denn, die Kanal-ID wird durch
+ ein Plugin-Manifest deklariert.
+- `plugins.entries.`, `plugins.allow`, `plugins.deny` und `plugins.slots.*`
+ müssen auf **auffindbare** Plugin-IDs verweisen. Unbekannte IDs sind **Fehler**.
+- Wenn ein Plugin installiert ist, aber ein defektes oder fehlendes Manifest oder Schema hat,
+ schlägt die Validierung fehl und Doctor meldet den Plugin-Fehler.
+- Wenn eine Plugin-Konfiguration existiert, das Plugin aber **deaktiviert** ist, bleibt die
+ Konfiguration erhalten und in Doctor + Logs wird eine **Warnung** ausgegeben.
-Siehe [Konfigurationsreferenz](/de/gateway/configuration) für das vollständige `plugins.*`-Schema.
+Die vollständige `plugins.*`-Schema-Referenz finden Sie unter
+[Konfigurationsreferenz](/de/gateway/configuration).
## Hinweise
-- Das Manifest ist **für native OpenClaw Plugins erforderlich**, einschließlich lokaler Dateisystem-Ladevorgänge.
-- Die Laufzeit lädt das Plugin-Modul weiterhin separat; das Manifest dient nur der Erkennung und Validierung.
-- Native Manifeste werden mit JSON5 geparst, daher sind Kommentare, nachgestellte Kommas und Schlüssel ohne Anführungszeichen zulässig, solange der endgültige Wert weiterhin ein Objekt ist.
-- Nur dokumentierte Manifest-Felder werden vom Manifest-Loader gelesen. Vermeide es, hier benutzerdefinierte Schlüssel auf oberster Ebene hinzuzufügen.
-- `providerAuthEnvVars` ist der kostengünstige Metadatenpfad für Auth-Prüfungen, die Validierung von env-Markern und ähnliche Provider-Auth-Oberflächen, die die Plugin-Laufzeit nicht starten sollten, nur um env-Namen zu prüfen.
-- `providerAuthAliases` ermöglicht es Provider-Varianten, die Auth-Umgebungsvariablen, Auth-Profile, konfigurationsgestützte Authentifizierung und die API-Key-Onboarding-Auswahl eines anderen Providers wiederzuverwenden, ohne diese Beziehung im Core fest zu codieren.
-- `providerEndpoints` ermöglicht es Provider-Plugins, einfache Metadaten zum Abgleich von Endpoint-Host/`baseUrl` zu besitzen. Verwende es nur für Endpoint-Klassen, die der Core bereits unterstützt; das Laufzeitverhalten bleibt weiterhin im Plugin.
-- `syntheticAuthRefs` ist der kostengünstige Metadatenpfad für plugin-eigene Synthetic-Auth-Hooks, die für die kalte Modellerkennung sichtbar sein müssen, bevor die Laufzeit-Registry existiert. Liste nur Referenzen auf, deren Laufzeit-Provider oder CLI-Backend tatsächlich `resolveSyntheticAuth` implementiert.
-- `nonSecretAuthMarkers` ist der kostengünstige Metadatenpfad für Platzhalter-API-Schlüssel, die einem gebündelten Plugin gehören, etwa Marker für lokale, OAuth- oder ambiente Anmeldedaten. Der Core behandelt diese für die Anzeige von Authentifizierung und Secret-Audits als nicht geheim, ohne den besitzenden Provider fest zu codieren.
-- `channelEnvVars` ist der kostengünstige Metadatenpfad für Shell-env-Fallback, Setup-Prompts und ähnliche Kanal-Oberflächen, die die Plugin-Laufzeit nicht starten sollten, nur um env-Namen zu prüfen.
-- `providerAuthChoices` ist der kostengünstige Metadatenpfad für Auth-Auswahl-Auswähler, die Auflösung von `--auth-choice`, bevorzugte Provider-Zuordnung und die einfache CLI-Flag-Registrierung für das Onboarding, bevor die Provider-Laufzeit geladen wird. Für Laufzeit-Wizard-Metadaten, die Provider-Code erfordern, siehe [Provider-Laufzeit-Hooks](/de/plugins/architecture#provider-runtime-hooks).
-- Exklusive Plugin-Typen werden über `plugins.slots.*` ausgewählt.
- - `kind: "memory"` wird über `plugins.slots.memory` ausgewählt.
- - `kind: "context-engine"` wird über `plugins.slots.contextEngine` ausgewählt
- (Standard: eingebautes `legacy`).
-- `channels`, `providers`, `cliBackends` und `skills` können weggelassen werden, wenn ein Plugin sie nicht benötigt.
-- Wenn dein Plugin von nativen Modulen abhängt, dokumentiere die Build-Schritte und alle Anforderungen an Allowlists des Paketmanagers, zum Beispiel pnpm `allow-build-scripts`
- - `pnpm rebuild `.
+- Das Manifest ist **für native OpenClaw-Plugins erforderlich**, einschließlich lokaler Dateisystem-Ladevorgänge.
+- Die Laufzeit lädt das Plugin-Modul weiterhin separat; das Manifest dient nur
+ der Discovery und Validierung.
+- Native Manifeste werden mit JSON5 geparst, daher werden Kommentare, nachgestellte Kommas und
+ nicht in Anführungszeichen gesetzte Schlüssel akzeptiert, solange der endgültige Wert weiterhin ein Objekt ist.
+- Nur dokumentierte Manifestfelder werden vom Manifest-Loader gelesen. Vermeiden Sie es,
+ hier benutzerdefinierte Schlüssel auf oberster Ebene hinzuzufügen.
+- `providerAuthEnvVars` ist der kostengünstige Metadatenpfad für Auth-Prüfungen, Env-Marker-
+ Validierung und ähnliche Oberflächen für Provider-Authentifizierung, die die Plugin-
+ Laufzeit nicht starten sollten, nur um Umgebungsvariablennamen zu prüfen.
+- `providerAuthAliases` ermöglicht es Provider-Varianten, die Auth-
+ Umgebungsvariablen, Auth-Profile, konfigurationsgestützte Authentifizierung und die
+ API-Key-Onboarding-Option eines anderen Providers wiederzuverwenden, ohne diese Beziehung im Core fest zu codieren.
+- `providerEndpoints` ermöglicht es Provider-Plugins, einfache Metadaten für das
+ Abgleichen von Endpoint-Host/BaseUrl zu besitzen. Verwenden Sie dies nur für Endpoint-Klassen,
+ die der Core bereits unterstützt; das Laufzeitverhalten bleibt weiterhin Eigentum des Plugins.
+- `syntheticAuthRefs` ist der kostengünstige Metadatenpfad für provider-eigene synthetische
+ Auth-Hooks, die für die kalte Modell-Discovery sichtbar sein müssen, bevor die Laufzeit-
+ Registry existiert. Listen Sie nur Referenzen auf, deren Laufzeit-Provider oder CLI-Backend tatsächlich
+ `resolveSyntheticAuth` implementiert.
+- `nonSecretAuthMarkers` ist der kostengünstige Metadatenpfad für Platzhalter-API-Schlüssel,
+ die gebündelten Plugins gehören, etwa Marker für lokale, OAuth- oder ambiente Anmeldedaten.
+ Der Core behandelt diese für Auth-Anzeige und Secret-Audits als Nicht-Geheimnisse, ohne
+ den besitzenden Provider fest zu codieren.
+- `channelEnvVars` ist der kostengünstige Metadatenpfad für Shell-Env-Fallback, Setup-
+ Eingabeaufforderungen und ähnliche Kanaloberflächen, die die Plugin-Laufzeit nicht starten
+ sollten, nur um Umgebungsvariablennamen zu prüfen.
+- `providerAuthChoices` ist der kostengünstige Metadatenpfad für Auswahlen von
+ Authentifizierungsoptionen, die Auflösung von `--auth-choice`, Zuordnungen bevorzugter Provider
+ und die einfache Registrierung von Onboarding-CLI-Flags, bevor die Provider-Laufzeit geladen wird. Für Metadaten von Laufzeit-Wizards,
+ die Provider-Code erfordern, siehe
+ [Provider-Laufzeit-Hooks](/de/plugins/architecture#provider-runtime-hooks).
+- Exklusive Plugin-Arten werden über `plugins.slots.*` ausgewählt.
+ - `kind: "memory"` wird durch `plugins.slots.memory` ausgewählt.
+ - `kind: "context-engine"` wird durch `plugins.slots.contextEngine`
+ ausgewählt (Standard: integriertes `legacy`).
+- `channels`, `providers`, `cliBackends` und `skills` können weggelassen werden, wenn ein
+ Plugin sie nicht benötigt.
+- Wenn Ihr Plugin von nativen Modulen abhängt, dokumentieren Sie die Build-Schritte und alle
+ Anforderungen an die Allowlist des Paketmanagers (zum Beispiel pnpm `allow-build-scripts`
+ - `pnpm rebuild `).
## Verwandt
-- [Plugins erstellen](/de/plugins/building-plugins) — erste Schritte mit Plugins
+- [Plugins erstellen](/de/plugins/building-plugins) — Einstieg in Plugins
- [Plugin-Architektur](/de/plugins/architecture) — interne Architektur
-- [SDK-Übersicht](/de/plugins/sdk-overview) — Referenz zum Plugin-SDK
+- [SDK-Überblick](/de/plugins/sdk-overview) — Referenz zum Plugin SDK
diff --git a/docs/de/plugins/sdk-channel-plugins.md b/docs/de/plugins/sdk-channel-plugins.md
index 399a3628c..fdbc277ef 100644
--- a/docs/de/plugins/sdk-channel-plugins.md
+++ b/docs/de/plugins/sdk-channel-plugins.md
@@ -1,89 +1,89 @@
---
read_when:
- - Sie erstellen ein neues Messaging-Kanal-Plugin
+ - Sie erstellen ein neues Messaging-Channel-Plugin
- Sie möchten OpenClaw mit einer Messaging-Plattform verbinden
- - Sie müssen die Adapteroberfläche von ChannelPlugin verstehen
+ - Sie müssen die Adapter-Oberfläche von ChannelPlugin verstehen
sidebarTitle: Channel Plugins
-summary: Schritt-für-Schritt-Anleitung zum Erstellen eines Messaging-Kanal-Plugins für OpenClaw
-title: Kanal-Plugins erstellen
+summary: Schritt-für-Schritt-Anleitung zum Erstellen eines Messaging-Channel-Plugins für OpenClaw
+title: Erstellen von Channel-Plugins
x-i18n:
- generated_at: "2026-04-21T06:28:20Z"
+ generated_at: "2026-04-21T19:20:43Z"
model: gpt-5.4
provider: openai
- source_hash: 569394aeefa0231ae3157a13406f91c97fe7eeff2b62df0d35a893f1ad4d5d05
+ source_hash: 35cae55c13b69f2219bd2f9bd3ee2f7d8c4075bd87f0be11c35a0fddb070fe1e
source_path: plugins/sdk-channel-plugins.md
workflow: 15
---
-# Kanal-Plugins erstellen
+# Erstellen von Channel-Plugins
-Diese Anleitung führt Sie durch die Erstellung eines Kanal-Plugins, das OpenClaw mit einer Messaging-Plattform verbindet. Am Ende haben Sie einen funktionierenden Kanal mit DM-Sicherheit, Pairing, Antwort-Threading und ausgehendem Messaging.
+Dieser Leitfaden führt Sie durch das Erstellen eines Channel-Plugins, das OpenClaw mit einer Messaging-Plattform verbindet. Am Ende haben Sie einen funktionierenden Channel mit DM-Sicherheit, Kopplung, Antwort-Threading und ausgehender Nachrichtenübermittlung.
- Wenn Sie noch nie ein OpenClaw-Plugin erstellt haben, lesen Sie zuerst
+ Wenn Sie bisher noch kein OpenClaw-Plugin erstellt haben, lesen Sie zuerst
[Erste Schritte](/de/plugins/building-plugins) für die grundlegende Paketstruktur
und die Manifest-Einrichtung.
-## So funktionieren Kanal-Plugins
+## So funktionieren Channel-Plugins
-Kanal-Plugins benötigen keine eigenen Tools zum Senden/Bearbeiten/Reagieren. OpenClaw hält ein gemeinsames `message`-Tool im Core. Ihr Plugin besitzt:
+Channel-Plugins benötigen keine eigenen Senden-/Bearbeiten-/Reagieren-Tools. OpenClaw hält ein gemeinsames `message`-Tool im Core. Ihr Plugin ist zuständig für:
-- **Konfiguration** — Kontoauflösung und Setup-Assistent
-- **Sicherheit** — DM-Richtlinie und Allowlists
-- **Pairing** — DM-Genehmigungsablauf
+- **Konfiguration** — Kontenauflösung und Einrichtungsassistent
+- **Sicherheit** — DM-Richtlinie und Zulassungslisten
+- **Kopplung** — DM-Genehmigungsablauf
- **Sitzungsgrammatik** — wie anbieterspezifische Konversations-IDs auf Basis-Chats, Thread-IDs und Parent-Fallbacks abgebildet werden
- **Ausgehend** — Senden von Text, Medien und Umfragen an die Plattform
- **Threading** — wie Antworten in Threads organisiert werden
-Der Core besitzt das gemeinsame Message-Tool, die Prompt-Anbindung, die äußere Form des Sitzungsschlüssels, generische `:thread:`-Buchführung und Dispatch.
+Der Core verwaltet das gemeinsame Message-Tool, Prompt-Verkabelung, die äußere Session-Key-Form, generische `:thread:`-Buchführung und Dispatch.
-Wenn Ihr Kanal Message-Tool-Parameter hinzufügt, die Medienquellen transportieren, stellen Sie diese Parameternamen über `describeMessageTool(...).mediaSourceParams` bereit. Der Core verwendet diese explizite Liste für die Normalisierung von Sandbox-Pfaden und die Richtlinie für ausgehenden Medienzugriff, sodass Plugins keine Spezialfälle im gemeinsamen Core für anbieterspezifische Avatar-, Anhangs- oder Cover-Image-Parameter benötigen.
-Bevorzugen Sie die Rückgabe einer aktionsbezogenen Map wie
-`{ "set-profile": ["avatarUrl", "avatarPath"] }`, damit nicht zusammenhängende Aktionen nicht die Medienargumente anderer Aktionen erben. Ein flaches Array funktioniert weiterhin für Parameter, die absichtlich über jede bereitgestellte Aktion hinweg geteilt werden.
+Wenn Ihr Channel Message-Tool-Parameter hinzufügt, die Medienquellen transportieren, legen Sie diese Parameternamen über `describeMessageTool(...).mediaSourceParams` offen. Der Core verwendet diese explizite Liste für die Normalisierung von Sandbox-Pfaden und die Richtlinie für ausgehenden Medienzugriff, sodass Plugins keine Shared-Core-Sonderfälle für anbieterspezifische Avatar-, Anhang- oder Titelbild-Parameter benötigen.
+Bevorzugen Sie die Rückgabe einer nach Aktionen sortierten Map wie
+`{ "set-profile": ["avatarUrl", "avatarPath"] }`, damit nicht zusammenhängende Aktionen nicht die Medienargumente anderer Aktionen übernehmen. Ein flaches Array funktioniert weiterhin für Parameter, die absichtlich über alle offengelegten Aktionen hinweg gemeinsam genutzt werden.
-Wenn Ihre Plattform zusätzlichen Scope in Konversations-IDs speichert, halten Sie dieses Parsing mit `messaging.resolveSessionConversation(...)` im Plugin. Das ist der kanonische Hook, um `rawId` auf die Basis-Konversations-ID, optionale Thread-ID, explizite `baseConversationId` und etwaige `parentConversationCandidates` abzubilden.
-Wenn Sie `parentConversationCandidates` zurückgeben, halten Sie sie in der Reihenfolge vom engsten Parent bis zur breitesten/Basis-Konversation.
+Wenn Ihre Plattform zusätzlichen Geltungsbereich in Konversations-IDs speichert, halten Sie dieses Parsing mit `messaging.resolveSessionConversation(...)` im Plugin. Das ist der kanonische Hook zum Abbilden von `rawId` auf die Basis-Konversations-ID, eine optionale Thread-ID, eine explizite `baseConversationId` und mögliche `parentConversationCandidates`.
+Wenn Sie `parentConversationCandidates` zurückgeben, halten Sie deren Reihenfolge von dem engsten Parent bis zur breitesten/Basis-Konversation ein.
-Gebündelte Plugins, die dasselbe Parsing benötigen, bevor die Kanal-Registry startet, können auch eine Top-Level-Datei `session-key-api.ts` mit einem passenden Export `resolveSessionConversation(...)` bereitstellen. Der Core verwendet diese bootstrap-sichere Oberfläche nur dann, wenn die Laufzeit-Plugin-Registry noch nicht verfügbar ist.
+Gebündelte Plugins, die dasselbe Parsing benötigen, bevor die Channel-Registry startet, können außerdem eine Top-Level-Datei `session-key-api.ts` mit einem passenden Export `resolveSessionConversation(...)` bereitstellen. Der Core verwendet diese Bootstrap-sichere Oberfläche nur dann, wenn die Laufzeit-Plugin-Registry noch nicht verfügbar ist.
`messaging.resolveParentConversationCandidates(...)` bleibt als Legacy-Kompatibilitäts-Fallback verfügbar, wenn ein Plugin nur Parent-Fallbacks zusätzlich zur generischen/raw ID benötigt. Wenn beide Hooks existieren, verwendet der Core zuerst `resolveSessionConversation(...).parentConversationCandidates` und greift nur auf `resolveParentConversationCandidates(...)` zurück, wenn der kanonische Hook sie auslässt.
-## Genehmigungen und Kanalfähigkeiten
+## Genehmigungen und Channel-Fähigkeiten
-Die meisten Kanal-Plugins benötigen keinen genehmigungsspezifischen Code.
+Die meisten Channel-Plugins benötigen keinen Genehmigungscode.
-- Der Core besitzt dasselbe Chat-`/approve`, gemeinsame Payloads für Genehmigungsbuttons und generische Fallback-Zustellung.
-- Bevorzugen Sie ein einzelnes Objekt `approvalCapability` auf dem Kanal-Plugin, wenn der Kanal genehmigungsspezifisches Verhalten benötigt.
-- `ChannelPlugin.approvals` wurde entfernt. Legen Sie Fakten zu Genehmigungszustellung/nativem Verhalten/Rendering/Auth in `approvalCapability`.
+- Der Core verwaltet `/approve` im selben Chat, gemeinsame Payloads für Genehmigungsbuttons und generische Fallback-Zustellung.
+- Bevorzugen Sie ein einzelnes `approvalCapability`-Objekt auf dem Channel-Plugin, wenn der Channel genehmigungsspezifisches Verhalten benötigt.
+- `ChannelPlugin.approvals` wurde entfernt. Legen Sie Zustellung/Native/Rendering/Auth-Fakten für Genehmigungen in `approvalCapability` ab.
- `plugin.auth` ist nur für Login/Logout; der Core liest keine Genehmigungs-Auth-Hooks mehr aus diesem Objekt.
-- `approvalCapability.authorizeActorAction` und `approvalCapability.getActionAvailabilityState` sind die kanonische Nahtstelle für Genehmigungs-Auth.
-- Verwenden Sie `approvalCapability.getActionAvailabilityState` für die Verfügbarkeit derselben Chat-Genehmigungs-Auth.
-- Wenn Ihr Kanal native Exec-Genehmigungen bereitstellt, verwenden Sie `approvalCapability.getExecInitiatingSurfaceState` für den Zustand der auslösenden Oberfläche/des nativen Clients, wenn dieser sich von der Genehmigungs-Auth im selben Chat unterscheidet. Der Core verwendet diesen exec-spezifischen Hook, um `enabled` vs. `disabled` zu unterscheiden, zu entscheiden, ob der auslösende Kanal native Exec-Genehmigungen unterstützt, und den Kanal in Fallback-Hinweise für native Clients aufzunehmen. `createApproverRestrictedNativeApprovalCapability(...)` füllt dies für den häufigen Fall aus.
-- Verwenden Sie `outbound.shouldSuppressLocalPayloadPrompt` oder `outbound.beforeDeliverPayload` für kanalspezifisches Verhalten im Payload-Lebenszyklus, etwa das Ausblenden doppelter lokaler Genehmigungs-Prompts oder das Senden von Tippindikatoren vor der Zustellung.
-- Verwenden Sie `approvalCapability.delivery` nur für natives Genehmigungsrouting oder die Unterdrückung von Fallbacks.
-- Verwenden Sie `approvalCapability.nativeRuntime` für kanal-eigene Fakten zu nativen Genehmigungen. Halten Sie es auf heißen Kanaleinstiegspunkten lazy mit `createLazyChannelApprovalNativeRuntimeAdapter(...)`, das Ihr Laufzeitmodul bei Bedarf importieren kann, während der Core weiterhin den Genehmigungslebenszyklus zusammensetzt.
-- Verwenden Sie `approvalCapability.render` nur dann, wenn ein Kanal wirklich benutzerdefinierte Genehmigungs-Payloads statt des gemeinsamen Renderers benötigt.
-- Verwenden Sie `approvalCapability.describeExecApprovalSetup`, wenn der Kanal möchte, dass die Antwort für den deaktivierten Pfad die genauen Konfigurationsschalter erklärt, die zum Aktivieren nativer Exec-Genehmigungen nötig sind. Der Hook erhält `{ channel, channelLabel, accountId }`; Kanäle mit benannten Konten sollten kontobezogene Pfade wie `channels..accounts..execApprovals.*` statt Defaults auf oberster Ebene rendern.
-- Wenn ein Kanal stabile, owner-ähnliche DM-Identitäten aus bestehender Konfiguration ableiten kann, verwenden Sie `createResolvedApproverActionAuthAdapter` aus `openclaw/plugin-sdk/approval-runtime`, um dasselbe Chat-`/approve` einzuschränken, ohne genehmigungsspezifische Core-Logik hinzuzufügen.
-- Wenn ein Kanal native Genehmigungszustellung benötigt, halten Sie den Kanalcode auf Zielnormalisierung sowie Fakten zu Transport/Präsentation fokussiert. Verwenden Sie `createChannelExecApprovalProfile`, `createChannelNativeOriginTargetResolver`, `createChannelApproverDmTargetResolver` und `createApproverRestrictedNativeApprovalCapability` aus `openclaw/plugin-sdk/approval-runtime`. Legen Sie die kanalspezifischen Fakten hinter `approvalCapability.nativeRuntime`, idealerweise über `createChannelApprovalNativeRuntimeAdapter(...)` oder `createLazyChannelApprovalNativeRuntimeAdapter(...)`, damit der Core den Handler zusammensetzen und Anfragefilterung, Routing, Deduplizierung, Ablauf, Gateway-Abonnement und Hinweise auf andere Routen besitzen kann. `nativeRuntime` ist in einige kleinere Nahtstellen aufgeteilt:
-- `availability` — ob das Konto konfiguriert ist und ob eine Anfrage behandelt werden soll
-- `presentation` — das gemeinsame Genehmigungs-View-Modell auf ausstehende/aufgelöste/abgelaufene native Payloads oder finale Aktionen abbilden
-- `transport` — Ziele vorbereiten sowie native Genehmigungsnachrichten senden/aktualisieren/löschen
+- `approvalCapability.authorizeActorAction` und `approvalCapability.getActionAvailabilityState` sind die kanonische Oberfläche für Genehmigungs-Auth.
+- Verwenden Sie `approvalCapability.getActionAvailabilityState` für die Verfügbarkeit von Genehmigungs-Auth im selben Chat.
+- Wenn Ihr Channel native Exec-Genehmigungen bereitstellt, verwenden Sie `approvalCapability.getExecInitiatingSurfaceState` für den Status der initiierenden Oberfläche/des nativen Clients, wenn dieser sich von der Genehmigungs-Auth im selben Chat unterscheidet. Der Core verwendet diesen exec-spezifischen Hook, um `enabled` und `disabled` zu unterscheiden, zu entscheiden, ob der initiierende Channel native Exec-Genehmigungen unterstützt, und den Channel in Guidance für Native-Client-Fallbacks einzubeziehen. `createApproverRestrictedNativeApprovalCapability(...)` füllt dies für den gängigen Fall aus.
+- Verwenden Sie `outbound.shouldSuppressLocalPayloadPrompt` oder `outbound.beforeDeliverPayload` für channelspezifisches Verhalten im Payload-Lebenszyklus, etwa das Ausblenden doppelter lokaler Genehmigungs-Prompts oder das Senden von Tippindikatoren vor der Zustellung.
+- Verwenden Sie `approvalCapability.delivery` nur für native Genehmigungsweiterleitung oder Fallback-Unterdrückung.
+- Verwenden Sie `approvalCapability.nativeRuntime` für channel-eigene Fakten zu nativen Genehmigungen. Halten Sie ihn auf Hot-Channel-Entrypoints lazy mit `createLazyChannelApprovalNativeRuntimeAdapter(...)`, das Ihr Runtime-Modul bei Bedarf importieren kann, während der Core weiterhin den Genehmigungslebenszyklus zusammensetzen kann.
+- Verwenden Sie `approvalCapability.render` nur dann, wenn ein Channel wirklich benutzerdefinierte Genehmigungs-Payloads anstelle des gemeinsamen Renderers benötigt.
+- Verwenden Sie `approvalCapability.describeExecApprovalSetup`, wenn der Channel in der Disabled-Antwort genau erläutern soll, welche Konfigurationsregler zum Aktivieren nativer Exec-Genehmigungen erforderlich sind. Der Hook erhält `{ channel, channelLabel, accountId }`; Channels mit benannten Konten sollten kontobezogene Pfade wie `channels..accounts..execApprovals.*` statt Top-Level-Standards rendern.
+- Wenn ein Channel stabile DM-Identitäten mit Besitzercharakter aus vorhandener Konfiguration ableiten kann, verwenden Sie `createResolvedApproverActionAuthAdapter` aus `openclaw/plugin-sdk/approval-runtime`, um `/approve` im selben Chat einzuschränken, ohne genehmigungsspezifische Core-Logik hinzuzufügen.
+- Wenn ein Channel native Genehmigungszustellung benötigt, konzentrieren Sie den Channel-Code auf Zielnormalisierung sowie Transport-/Darstellungsfakten. Verwenden Sie `createChannelExecApprovalProfile`, `createChannelNativeOriginTargetResolver`, `createChannelApproverDmTargetResolver` und `createApproverRestrictedNativeApprovalCapability` aus `openclaw/plugin-sdk/approval-runtime`. Legen Sie die channelspezifischen Fakten hinter `approvalCapability.nativeRuntime`, idealerweise über `createChannelApprovalNativeRuntimeAdapter(...)` oder `createLazyChannelApprovalNativeRuntimeAdapter(...)`, sodass der Core den Handler zusammensetzen und Request-Filtering, Routing, Deduplizierung, Ablauf, Gateway-Abonnement und Hinweise auf anderswo erfolgte Weiterleitung verwalten kann. `nativeRuntime` ist in einige kleinere Oberflächen aufgeteilt:
+- `availability` — ob das Konto konfiguriert ist und ob eine Anfrage verarbeitet werden soll
+- `presentation` — Zuordnung des gemeinsamen Genehmigungs-View-Models zu nativen Payloads für ausstehend/aufgelöst/abgelaufen oder zu finalen Aktionen
+- `transport` — Vorbereiten von Zielen sowie Senden/Aktualisieren/Löschen nativer Genehmigungsnachrichten
- `interactions` — optionale Hooks zum Binden/Entbinden/Löschen von Aktionen für native Buttons oder Reaktionen
- `observe` — optionale Hooks für Zustellungsdiagnostik
-- Wenn der Kanal laufzeiteigene Objekte wie einen Client, Token, eine Bolt-App oder einen Webhook-Empfänger benötigt, registrieren Sie diese über `openclaw/plugin-sdk/channel-runtime-context`. Die generische Runtime-Context-Registry erlaubt dem Core, fähigkeitsgetriebene Handler aus dem Kanal-Startzustand zu bootstrappen, ohne genehmigungsspezifischen Wrapper-Glue hinzuzufügen.
-- Greifen Sie nur zu `createChannelApprovalHandler` oder `createChannelNativeApprovalRuntime` auf niedrigerer Ebene, wenn die fähigkeitsgetriebene Nahtstelle noch nicht ausdrucksstark genug ist.
-- Native Genehmigungskanäle müssen sowohl `accountId` als auch `approvalKind` durch diese Helfer routen. `accountId` hält die Richtlinie für Multi-Account-Genehmigungen auf das richtige Bot-Konto beschränkt, und `approvalKind` hält Verhalten für Exec- vs. Plugin-Genehmigungen für den Kanal verfügbar, ohne fest codierte Branches im Core.
-- Der Core besitzt jetzt auch Hinweise auf umgeleitete Genehmigungen. Kanal-Plugins sollten keine eigenen Folgemeldungen wie „Genehmigung ging an DMs / einen anderen Kanal“ aus `createChannelNativeApprovalRuntime` senden; stattdessen sollten sie genaue Ursprung- und Approver-DM-Routen über die gemeinsamen Hilfen für Genehmigungsfähigkeiten verfügbar machen und den Core tatsächliche Zustellungen aggregieren lassen, bevor ein Hinweis zurück in den auslösenden Chat gepostet wird.
-- Behalten Sie die Art der zugestellten Genehmigungs-ID Ende-zu-Ende bei. Native Clients sollten das Routing für Exec- vs. Plugin-Genehmigungen nicht aus kanal-lokalem Zustand erraten oder umschreiben.
-- Verschiedene Arten von Genehmigungen können absichtlich unterschiedliche native Oberflächen bereitstellen.
+- Wenn der Channel laufzeiteigene Objekte wie einen Client, Token, eine Bolt-App oder einen Webhook-Empfänger benötigt, registrieren Sie diese über `openclaw/plugin-sdk/channel-runtime-context`. Die generische Runtime-Context-Registry ermöglicht es dem Core, capability-gesteuerte Handler aus dem Startup-Status des Channels zu bootstrappen, ohne genehmigungsspezifischen Wrapper-Glue hinzuzufügen.
+- Greifen Sie nur dann zu den Low-Level-Funktionen `createChannelApprovalHandler` oder `createChannelNativeApprovalRuntime`, wenn die capability-gesteuerte Oberfläche noch nicht ausdrucksstark genug ist.
+- Native Genehmigungs-Channels müssen sowohl `accountId` als auch `approvalKind` durch diese Hilfen routen. `accountId` hält die Richtlinie für Multi-Account-Genehmigungen auf das richtige Bot-Konto beschränkt, und `approvalKind` hält das Verhalten für Exec- vs. Plugin-Genehmigungen für den Channel verfügbar, ohne hartcodierte Verzweigungen im Core.
+- Der Core verwaltet jetzt auch Hinweise zur Umleitung von Genehmigungen. Channel-Plugins sollten keine eigenen Follow-up-Nachrichten wie „Genehmigung ging an DMs / einen anderen Channel“ aus `createChannelNativeApprovalRuntime` senden; stattdessen sollten sie korrektes Routing für Ursprung + Approver-DM über die gemeinsamen Hilfen für Genehmigungsfähigkeiten bereitstellen und den Core die tatsächlichen Zustellungen aggregieren lassen, bevor er einen Hinweis zurück in den initiierenden Chat sendet.
+- Bewahren Sie die Art der zugestellten Genehmigungs-ID Ende-zu-Ende. Native Clients sollten das Routing für Exec- vs. Plugin-Genehmigungen nicht aus channel-lokalem Zustand erraten oder umschreiben.
+- Verschiedene Genehmigungsarten können absichtlich unterschiedliche native Oberflächen bereitstellen.
Aktuelle gebündelte Beispiele:
- - Slack hält natives Genehmigungsrouting sowohl für Exec- als auch Plugin-IDs verfügbar.
- - Matrix behält dasselbe native DM-/Kanal-Routing und dieselbe Reaktions-UX für Exec- und Plugin-Genehmigungen bei, während Auth weiterhin je nach Genehmigungsart unterschiedlich sein darf.
-- `createApproverRestrictedNativeApprovalAdapter` existiert weiterhin als Kompatibilitäts-Wrapper, aber neuer Code sollte den Capability-Builder bevorzugen und `approvalCapability` auf dem Plugin bereitstellen.
+ - Slack hält natives Genehmigungsrouting sowohl für Exec- als auch für Plugin-IDs verfügbar.
+ - Matrix behält dasselbe native DM-/Channel-Routing und dieselbe Reaktions-UX für Exec- und Plugin-Genehmigungen bei, lässt Auth aber weiterhin je nach Genehmigungsart unterschiedlich sein.
+- `createApproverRestrictedNativeApprovalAdapter` existiert weiterhin als Kompatibilitäts-Wrapper, neuer Code sollte jedoch den Capability-Builder bevorzugen und `approvalCapability` im Plugin offenlegen.
-Für heiße Kanaleinstiegspunkte bevorzugen Sie die schmaleren Runtime-Unterpfade, wenn Sie nur einen Teil dieser Familie benötigen:
+Für Hot-Channel-Entrypoints bevorzugen Sie die schmaleren Runtime-Unterpfade, wenn Sie nur einen Teil dieser Familie benötigen:
- `openclaw/plugin-sdk/approval-auth-runtime`
- `openclaw/plugin-sdk/approval-client-runtime`
@@ -100,78 +100,92 @@ Bevorzugen Sie ebenso `openclaw/plugin-sdk/setup-runtime`,
`openclaw/plugin-sdk/reply-runtime`,
`openclaw/plugin-sdk/reply-dispatch-runtime`,
`openclaw/plugin-sdk/reply-reference` und
-`openclaw/plugin-sdk/reply-chunking`, wenn Sie die breitere Umbrella-Oberfläche nicht benötigen.
+`openclaw/plugin-sdk/reply-chunking`, wenn Sie die umfassendere Umbrella-Oberfläche nicht benötigen.
-Speziell für Setup:
+Speziell für Setup gilt:
-- `openclaw/plugin-sdk/setup-runtime` deckt die runtime-sicheren Setup-Helfer ab:
+- `openclaw/plugin-sdk/setup-runtime` umfasst die runtime-sicheren Setup-Helfer:
import-sichere Setup-Patch-Adapter (`createPatchedAccountSetupAdapter`,
`createEnvPatchedAccountSetupAdapter`,
`createSetupInputPresenceValidator`), Ausgabe von Lookup-Hinweisen,
- `promptResolvedAllowFrom`, `splitSetupEntries` und die Builder für delegierte
- Setup-Proxys
-- `openclaw/plugin-sdk/setup-adapter-runtime` ist die schmale env-bewusste Adapter-Nahtstelle für `createEnvPatchedAccountSetupAdapter`
-- `openclaw/plugin-sdk/channel-setup` deckt die optionalen Setup-Builder plus einige setup-sichere Primitive ab:
+ `promptResolvedAllowFrom`, `splitSetupEntries` und die delegierten
+ Setup-Proxy-Builder
+- `openclaw/plugin-sdk/setup-adapter-runtime` ist die schmale umgebungsbewusste Adapter-Oberfläche
+ für `createEnvPatchedAccountSetupAdapter`
+- `openclaw/plugin-sdk/channel-setup` umfasst die optionalen Installations-Setup-Builder
+ plus einige setup-sichere Primitive:
`createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`,
-Wenn Ihr Kanal env-gesteuertes Setup oder Auth unterstützt und generische Start-/Konfigurationsabläufe diese Env-Namen kennen sollen, bevor die Laufzeit geladen wird, deklarieren Sie sie im Plugin-Manifest mit `channelEnvVars`. Halten Sie Runtime-`envVars` des Kanals oder lokale Konstanten nur für operatororientierte Texte.
+Wenn Ihr Channel env-gesteuertes Setup oder Auth unterstützt und generische Startup-/Konfigurationsabläufe diese env-Namen vor dem Laden der Runtime kennen sollen, deklarieren Sie sie im Plugin-Manifest mit `channelEnvVars`. Behalten Sie Runtime-`envVars` des Channels oder lokale Konstanten nur für operatororientierte Texte bei.
+
+Wenn Ihr Channel in `status`, `channels list`, `channels status` oder SecretRef-Scans erscheinen kann, bevor die Plugin-Runtime startet, fügen Sie `openclaw.setupEntry` in `package.json` hinzu. Dieser Entrypoint sollte in schreibgeschützten Befehlspfaden sicher importierbar sein und die für diese Zusammenfassungen benötigten Channel-Metadaten, den setup-sicheren Konfigurationsadapter, den Statusadapter und die Zielmetadaten für Channel-Secrets zurückgeben. Starten Sie aus dem Setup-Entry keine Clients, Listener oder Transportruntimes.
+
`createOptionalChannelSetupWizard`, `DEFAULT_ACCOUNT_ID`,
`createTopLevelChannelDmPolicy`, `setSetupChannelEnabled` und
`splitSetupEntries`
-- verwenden Sie die breitere Nahtstelle `openclaw/plugin-sdk/setup` nur dann, wenn Sie auch die schwereren gemeinsamen Setup-/Konfigurationshelfer wie
+- verwenden Sie die umfassendere Oberfläche `openclaw/plugin-sdk/setup` nur dann, wenn Sie zusätzlich die
+ schwergewichtigeren gemeinsamen Setup-/Konfigurationshelfer wie
`moveSingleAccountChannelSectionToDefaultAccount(...)` benötigen
-Wenn Ihr Kanal nur „Installieren Sie dieses Plugin zuerst“ in Setup-Oberflächen bewerben möchte, bevorzugen Sie `createOptionalChannelSetupSurface(...)`. Der erzeugte Adapter/Assistent schlägt bei Konfigurationsschreibvorgängen und Finalisierung fail-closed fehl und verwendet dieselbe Meldung „Installation erforderlich“ für Validierung, Finalisierung und Docs-Link-Text wieder.
+Wenn Ihr Channel in Setup-Oberflächen nur „installieren Sie zuerst dieses Plugin“ anzeigen möchte, bevorzugen Sie `createOptionalChannelSetupSurface(...)`. Der generierte Adapter/Assistent schlägt bei Konfigurationsschreibvorgängen und Finalisierung fail-closed fehl und verwendet dieselbe Installationsmeldung für Validierung, Finalisierung und Docs-Link-Text erneut.
-Für andere heiße Kanalpfade bevorzugen Sie die schmalen Helfer gegenüber breiteren Legacy-Oberflächen:
+Für andere Hot-Channel-Pfade bevorzugen Sie die schmalen Helfer gegenüber breiteren Legacy-Oberflächen:
- `openclaw/plugin-sdk/account-core`,
`openclaw/plugin-sdk/account-id`,
`openclaw/plugin-sdk/account-resolution` und
- `openclaw/plugin-sdk/account-helpers` für Multi-Account-Konfiguration und Fallback auf Standardkonto
+ `openclaw/plugin-sdk/account-helpers` für Multi-Account-Konfiguration und
+ Default-Account-Fallback
- `openclaw/plugin-sdk/inbound-envelope` und
- `openclaw/plugin-sdk/inbound-reply-dispatch` für inbound Route/Envelope und Record-and-Dispatch-Anbindung
-- `openclaw/plugin-sdk/messaging-targets` für Target-Parsing/-Matching
+ `openclaw/plugin-sdk/inbound-reply-dispatch` für eingehende Route/Envelope und
+ Record-and-Dispatch-Verkabelung
+- `openclaw/plugin-sdk/messaging-targets` für Ziel-Parsing/-Matching
- `openclaw/plugin-sdk/outbound-media` und
- `openclaw/plugin-sdk/outbound-runtime` für Medienladen plus Delegates für ausgehende Identität/Senden und Payload-Planung
-- `openclaw/plugin-sdk/thread-bindings-runtime` für den Lebenszyklus von Thread-Bindings und Adapter-Registrierung
-- `openclaw/plugin-sdk/agent-media-payload` nur dann, wenn weiterhin ein Legacy-Feldlayout für Agent-/Medien-Payload erforderlich ist
-- `openclaw/plugin-sdk/telegram-command-config` für die Normalisierung benutzerdefinierter Telegram-Befehle, Validierung von Duplikaten/Konflikten und einen fallback-stabilen Vertrag für die Befehlskonfiguration
+ `openclaw/plugin-sdk/outbound-runtime` für Medienladen sowie Delegates für ausgehende
+ Identität/Senden und Payload-Planung
+- `openclaw/plugin-sdk/thread-bindings-runtime` für den Thread-Binding-Lebenszyklus
+ und die Adapter-Registrierung
+- `openclaw/plugin-sdk/agent-media-payload` nur dann, wenn weiterhin ein Legacy-Agent-/Medien-
+ Payload-Feldlayout erforderlich ist
+- `openclaw/plugin-sdk/telegram-command-config` für Telegram-Normalisierung benutzerdefinierter Befehle,
+ Validierung von Duplikaten/Konflikten und einen fallback-stabilen
+ Befehlskonfigurationsvertrag
-Auth-only-Kanäle können normalerweise beim Standardpfad stehen bleiben: Der Core behandelt Genehmigungen, und das Plugin stellt nur Outbound-/Auth-Fähigkeiten bereit. Kanäle mit nativen Genehmigungen wie Matrix, Slack, Telegram und benutzerdefinierte Chat-Transporte sollten die gemeinsamen nativen Helfer verwenden, statt ihren eigenen Genehmigungslebenszyklus zu bauen.
+Reine Auth-Channels können meist beim Standardpfad bleiben: Der Core verwaltet Genehmigungen, und das Plugin stellt nur Outbound-/Auth-Fähigkeiten bereit. Native Genehmigungs-Channels wie Matrix, Slack, Telegram und benutzerdefinierte Chat-Transporte sollten die gemeinsamen nativen Helfer verwenden, anstatt ihren eigenen Genehmigungslebenszyklus zu implementieren.
## Richtlinie für eingehende Erwähnungen
-Halten Sie die Behandlung eingehender Erwähnungen in zwei Ebenen getrennt:
+Halten Sie die Verarbeitung eingehender Erwähnungen in zwei Ebenen getrennt:
-- plugin-eigene Erfassung von Nachweisen
+- plugin-eigene Belegsammlung
- gemeinsame Richtlinienauswertung
Verwenden Sie `openclaw/plugin-sdk/channel-mention-gating` für Entscheidungen zur Erwähnungsrichtlinie.
-Verwenden Sie `openclaw/plugin-sdk/channel-inbound` nur dann, wenn Sie die breitere Helper-Barrel für eingehende Nachrichten benötigen.
+Verwenden Sie `openclaw/plugin-sdk/channel-inbound` nur dann, wenn Sie das umfassendere Barrel für eingehende
+Helfer benötigen.
-Gute Kandidaten für plugin-lokale Logik:
+Gut geeignet für plugin-lokale Logik:
- Erkennung von Antworten an den Bot
- Erkennung von Zitaten des Bots
- Prüfungen auf Thread-Beteiligung
- Ausschlüsse von Service-/Systemnachrichten
-- plattformnative Caches, die nötig sind, um die Beteiligung des Bots nachzuweisen
+- plattformnative Caches, die benötigt werden, um Bot-Beteiligung nachzuweisen
-Gute Kandidaten für den gemeinsamen Helper:
+Gut geeignet für den gemeinsamen Helfer:
- `requireMention`
- explizites Erwähnungsergebnis
-- implizite Erwähnungs-Allowlist
-- Command-Bypass
-- finale Skip-Entscheidung
+- implizite Erwähnungs-Zulassungsliste
+- Befehls-Bypass
+- endgültige Skip-Entscheidung
Bevorzugter Ablauf:
-1. Lokale Erwähnungsfakten berechnen.
-2. Diese Fakten an `resolveInboundMentionDecision({ facts, policy })` übergeben.
-3. `decision.effectiveWasMentioned`, `decision.shouldBypassMention` und `decision.shouldSkip` in Ihrem Inbound-Gate verwenden.
+1. Berechnen Sie lokale Erwähnungsfakten.
+2. Übergeben Sie diese Fakten an `resolveInboundMentionDecision({ facts, policy })`.
+3. Verwenden Sie `decision.effectiveWasMentioned`, `decision.shouldBypassMention` und `decision.shouldSkip` in Ihrem eingehenden Gate.
```typescript
import {
@@ -210,7 +224,8 @@ const decision = resolveInboundMentionDecision({
if (decision.shouldSkip) return;
```
-`api.runtime.channel.mentions` stellt dieselben gemeinsamen Erwähnungs-Helper für gebündelte Kanal-Plugins bereit, die bereits von Laufzeit-Injection abhängen:
+`api.runtime.channel.mentions` stellt dieselben gemeinsamen Erwähnungshelfer für
+gebündelte Channel-Plugins bereit, die bereits von Runtime-Injection abhängen:
- `buildMentionRegexes`
- `matchesMentionPatterns`
@@ -218,16 +233,23 @@ if (decision.shouldSkip) return;
- `implicitMentionKindWhen`
- `resolveInboundMentionDecision`
-Wenn Sie nur `implicitMentionKindWhen` und `resolveInboundMentionDecision` benötigen, importieren Sie aus `openclaw/plugin-sdk/channel-mention-gating`, um das Laden nicht zusammenhängender Inbound-Runtime-Helper zu vermeiden.
+Wenn Sie nur `implicitMentionKindWhen` und
+`resolveInboundMentionDecision` benötigen, importieren Sie aus
+`openclaw/plugin-sdk/channel-mention-gating`, um das Laden nicht zusammenhängender eingehender
+Runtime-Helfer zu vermeiden.
-Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/channel-inbound` nur noch als Kompatibilitäts-Exporte erhalten. Neuer Code sollte `resolveInboundMentionDecision({ facts, policy })` verwenden.
+Die älteren Helfer `resolveMentionGating*` bleiben auf
+`openclaw/plugin-sdk/channel-inbound` nur als Kompatibilitätsexporte erhalten. Neuer Code
+sollte `resolveInboundMentionDecision({ facts, policy })` verwenden.
-## Schritt-für-Schritt
+## Durchgang
- Erstellen Sie die Standarddateien des Plugins. Das Feld `channel` in `package.json` macht dieses Plugin zu einem Kanal-Plugin. Für die vollständige Oberfläche der Paketmetadaten siehe [Plugin-Setup und Konfiguration](/de/plugins/sdk-setup#openclaw-channel):
+ Erstellen Sie die Standard-Plugin-Dateien. Das Feld `channel` in `package.json`
+ macht dies zu einem Channel-Plugin. Die vollständige Oberfläche der Paketmetadaten
+ finden Sie unter [Plugin-Setup und -Konfiguration](/de/plugins/sdk-setup#openclaw-channel):
```json package.json
@@ -241,7 +263,7 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
"channel": {
"id": "acme-chat",
"label": "Acme Chat",
- "blurb": "Verbinden Sie OpenClaw mit Acme Chat."
+ "blurb": "Connect OpenClaw to Acme Chat."
}
}
}
@@ -253,7 +275,7 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
"kind": "channel",
"channels": ["acme-chat"],
"name": "Acme Chat",
- "description": "Acme-Chat-Kanal-Plugin",
+ "description": "Acme Chat channel plugin",
"configSchema": {
"type": "object",
"additionalProperties": false,
@@ -276,8 +298,9 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
-
- Die Schnittstelle `ChannelPlugin` hat viele optionale Adapteroberflächen. Beginnen Sie mit dem Minimum — `id` und `setup` — und fügen Sie Adapter hinzu, wenn Sie sie benötigen.
+
+ Die Schnittstelle `ChannelPlugin` hat viele optionale Adapter-Oberflächen. Beginnen Sie mit
+ dem Minimum — `id` und `setup` — und fügen Sie Adapter nach Bedarf hinzu.
Erstellen Sie `src/channel.ts`:
@@ -287,7 +310,7 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
createChannelPluginBase,
} from "openclaw/plugin-sdk/channel-core";
import type { OpenClawConfig } from "openclaw/plugin-sdk/channel-core";
- import { acmeChatApi } from "./client.js"; // Ihr Plattform-API-Client
+ import { acmeChatApi } from "./client.js"; // your platform API client
type ResolvedAccount = {
accountId: string | null;
@@ -328,7 +351,7 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
},
}),
- // DM-Sicherheit: Wer dem Bot Nachrichten senden darf
+ // DM security: who can message the bot
security: {
dm: {
channelKey: "acme-chat",
@@ -338,21 +361,21 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
},
},
- // Pairing: Genehmigungsablauf für neue DM-Kontakte
+ // Pairing: approval flow for new DM contacts
pairing: {
text: {
- idLabel: "Acme-Chat-Benutzername",
- message: "Senden Sie diesen Code, um Ihre Identität zu verifizieren:",
+ idLabel: "Acme Chat username",
+ message: "Send this code to verify your identity:",
notify: async ({ target, code }) => {
await acmeChatApi.sendDm(target, `Pairing code: ${code}`);
},
},
},
- // Threading: Wie Antworten zugestellt werden
+ // Threading: how replies are delivered
threading: { topLevelReplyToMode: "reply" },
- // Outbound: Nachrichten an die Plattform senden
+ // Outbound: send messages to the platform
outbound: {
attachedResults: {
sendText: async (params) => {
@@ -372,22 +395,24 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
});
```
-
- Statt Adapter-Schnittstellen auf niedriger Ebene manuell zu implementieren, übergeben Sie deklarative Optionen, und der Builder setzt sie zusammen:
+
+ Statt Low-Level-Adapter-Schnittstellen manuell zu implementieren, übergeben Sie
+ deklarative Optionen, und der Builder setzt sie zusammen:
- | Option | Was damit verdrahtet wird |
+ | Option | Was es verdrahtet |
| --- | --- |
- | `security.dm` | Bereichsbezogener DM-Sicherheits-Resolver aus Konfigurationsfeldern |
- | `pairing.text` | Textbasierter DM-Pairing-Ablauf mit Code-Austausch |
- | `threading` | Resolver für Reply-to-Modi (fest, kontobezogen oder benutzerdefiniert) |
+ | `security.dm` | Scoped-DM-Sicherheits-Resolver aus Konfigurationsfeldern |
+ | `pairing.text` | Textbasierter DM-Kopplungsablauf mit Codeaustausch |
+ | `threading` | Reply-to-Mode-Resolver (fest, kontobezogen oder benutzerdefiniert) |
| `outbound.attachedResults` | Sendefunktionen, die Ergebnis-Metadaten zurückgeben (Nachrichten-IDs) |
- Sie können auch rohe Adapterobjekte statt der deklarativen Optionen übergeben, wenn Sie vollständige Kontrolle benötigen.
+ Sie können auch rohe Adapter-Objekte statt deklarativer Optionen übergeben,
+ wenn Sie die vollständige Kontrolle benötigen.
-
+
Erstellen Sie `index.ts`:
```typescript index.ts
@@ -404,13 +429,13 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
({ program }) => {
program
.command("acme-chat")
- .description("Acme-Chat-Verwaltung");
+ .description("Acme Chat management");
},
{
descriptors: [
{
name: "acme-chat",
- description: "Acme-Chat-Verwaltung",
+ description: "Acme Chat management",
hasSubcommands: false,
},
],
@@ -423,13 +448,20 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
});
```
- Legen Sie kanal-eigene CLI-Deskriptoren in `registerCliMetadata(...)`, damit OpenClaw sie in der Root-Hilfe anzeigen kann, ohne die vollständige Kanal-Laufzeit zu aktivieren, während normale vollständige Ladevorgänge dieselben Deskriptoren weiterhin für die echte Befehlsregistrierung aufgreifen. Verwenden Sie `registerFull(...)` für Arbeit nur zur Laufzeit.
- Wenn `registerFull(...)` Gateway-RPC-Methoden registriert, verwenden Sie ein plugin-spezifisches Präfix. Core-Admin-Namespaces (`config.*`, `exec.approvals.*`, `wizard.*`, `update.*`) bleiben reserviert und werden immer zu `operator.admin` aufgelöst.
- `defineChannelPluginEntry` übernimmt die Trennung des Registrierungsmodus automatisch. Siehe [Entry Points](/de/plugins/sdk-entrypoints#definechannelpluginentry) für alle Optionen.
+ Legen Sie channel-eigene CLI-Deskriptoren in `registerCliMetadata(...)` ab, damit OpenClaw
+ sie in der Root-Hilfe anzeigen kann, ohne die vollständige Channel-Runtime zu aktivieren,
+ während normale Vollladungen dieselben Deskriptoren weiterhin für die echte Befehls-
+ Registrierung übernehmen. Halten Sie `registerFull(...)` für Runtime-Only-Arbeit vor.
+ Wenn `registerFull(...)` Gateway-RPC-Methoden registriert, verwenden Sie ein
+ pluginspezifisches Präfix. Core-Admin-Namespaces (`config.*`,
+ `exec.approvals.*`, `wizard.*`, `update.*`) bleiben reserviert und werden immer
+ zu `operator.admin` aufgelöst.
+ `defineChannelPluginEntry` behandelt die Trennung der Registrierungsmodi automatisch. Alle
+ Optionen finden Sie unter [Entrypoints](/de/plugins/sdk-entrypoints#definechannelpluginentry).
-
+
Erstellen Sie `setup-entry.ts` für leichtgewichtiges Laden während des Onboardings:
```typescript setup-entry.ts
@@ -439,27 +471,33 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
export default defineSetupPluginEntry(acmeChatPlugin);
```
- OpenClaw lädt dies anstelle des vollständigen Einstiegspunkts, wenn der Kanal deaktiviert oder unkonfiguriert ist. So wird vermieden, während des Setups schwere Laufzeitlogik zu laden.
- Siehe [Setup und Konfiguration](/de/plugins/sdk-setup#setup-entry) für Details.
+ OpenClaw lädt dies anstelle des vollständigen Entrypoints, wenn der Channel deaktiviert
+ oder nicht konfiguriert ist. So wird vermieden, während Setup-Abläufen schwergewichtigen Runtime-Code zu laden.
+ Details finden Sie unter [Setup und Konfiguration](/de/plugins/sdk-setup#setup-entry).
- Gebündelte Workspace-Kanäle, die setup-sichere Exporte in Sidecar-Module aufteilen, können `defineBundledChannelSetupEntry(...)` aus `openclaw/plugin-sdk/channel-entry-contract` verwenden, wenn sie außerdem einen expliziten Setter für die Laufzeit zur Setup-Zeit benötigen.
+ Gebündelte Workspace-Channels, die setup-sichere Exporte in Sidecar-Module
+ aufteilen, können `defineBundledChannelSetupEntry(...)` aus
+ `openclaw/plugin-sdk/channel-entry-contract` verwenden, wenn sie zusätzlich einen
+ expliziten setupzeitigen Runtime-Setter benötigen.
-
- Ihr Plugin muss Nachrichten von der Plattform empfangen und an OpenClaw weiterleiten. Das typische Muster ist ein Webhook, der die Anfrage verifiziert und sie durch den Inbound-Handler Ihres Kanals dispatcht:
+
+ Ihr Plugin muss Nachrichten von der Plattform empfangen und an
+ OpenClaw weiterleiten. Das typische Muster ist ein Webhook, der die Anfrage verifiziert und
+ sie über den Inbound-Handler Ihres Channels dispatcht:
```typescript
registerFull(api) {
api.registerHttpRoute({
path: "/acme-chat/webhook",
- auth: "plugin", // plugin-verwaltete Auth (Signaturen selbst verifizieren)
+ auth: "plugin", // pluginverwaltete Auth (Signaturen selbst verifizieren)
handler: async (req, res) => {
const event = parseWebhookPayload(req);
// Ihr Inbound-Handler dispatcht die Nachricht an OpenClaw.
// Die genaue Verdrahtung hängt von Ihrem Plattform-SDK ab —
- // siehe ein echtes Beispiel im gebündelten Microsoft-Teams- oder Google-Chat-Plugin-Paket.
+ // ein echtes Beispiel finden Sie im gebündelten Plugin-Paket für Microsoft Teams oder Google Chat.
await handleAcmeChatInbound(api, event);
res.statusCode = 200;
@@ -471,8 +509,9 @@ Die älteren Helper `resolveMentionGating*` bleiben auf `openclaw/plugin-sdk/cha
```
- Die Behandlung eingehender Nachrichten ist kanalspezifisch. Jedes Kanal-Plugin besitzt seine eigene Inbound-Pipeline. Sehen Sie sich gebündelte Kanal-Plugins an
- (zum Beispiel das Microsoft-Teams- oder Google-Chat-Plugin-Paket) für echte Muster.
+ Die Verarbeitung eingehender Nachrichten ist channelspezifisch. Jedes Channel-Plugin verwaltet
+ seine eigene Inbound-Pipeline. Sehen Sie sich gebündelte Channel-Plugins
+ an (zum Beispiel das Plugin-Paket für Microsoft Teams oder Google Chat), um reale Muster zu sehen.
@@ -486,7 +525,7 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
import { acmeChatPlugin } from "./channel.js";
describe("acme-chat plugin", () => {
- it("löst das Konto aus der Konfiguration auf", () => {
+ it("resolves account from config", () => {
const cfg = {
channels: {
"acme-chat": { token: "test-token", allowFrom: ["user1"] },
@@ -496,7 +535,7 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
expect(account.token).toBe("test-token");
});
- it("prüft das Konto, ohne Geheimnisse zu materialisieren", () => {
+ it("inspects account without materializing secrets", () => {
const cfg = {
channels: { "acme-chat": { token: "test-token" } },
} as any;
@@ -505,7 +544,7 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
expect(result.tokenStatus).toBe("available");
});
- it("meldet fehlende Konfiguration", () => {
+ it("reports missing config", () => {
const cfg = { channels: {} } as any;
const result = acmeChatPlugin.setup!.inspectAccount!(cfg, undefined);
expect(result.configured).toBe(false);
@@ -517,7 +556,7 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
pnpm test -- /acme-chat/
```
- Für gemeinsame Test-Helper siehe [Testing](/de/plugins/sdk-testing).
+ Gemeinsame Testhilfen finden Sie unter [Testing](/de/plugins/sdk-testing).
@@ -531,12 +570,12 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
├── index.ts # defineChannelPluginEntry
├── setup-entry.ts # defineSetupPluginEntry
├── api.ts # Öffentliche Exporte (optional)
-├── runtime-api.ts # Interne Laufzeit-Exporte (optional)
+├── runtime-api.ts # Interne Runtime-Exporte (optional)
└── src/
├── channel.ts # ChannelPlugin über createChatChannelPlugin
├── channel.test.ts # Tests
├── client.ts # Plattform-API-Client
- └── runtime.ts # Laufzeitspeicher (falls nötig)
+ └── runtime.ts # Runtime-Store (falls erforderlich)
```
## Erweiterte Themen
@@ -551,18 +590,21 @@ Schreiben Sie colocated Tests in `src/channel.test.ts`:
inferTargetChatType, looksLikeId, resolveTarget
-
+
TTS, STT, Medien, Subagent über api.runtime
-Einige gebündelte Helper-Seams existieren weiterhin für die Wartung gebündelter Plugins und aus Kompatibilitätsgründen. Sie sind nicht das empfohlene Muster für neue Kanal-Plugins; bevorzugen Sie die generischen Subpfade für Kanal/Setup/Antwort/Laufzeit aus der gemeinsamen SDK-Oberfläche, es sei denn, Sie warten direkt diese Familie gebündelter Plugins.
+Einige gebündelte Helper-Seams existieren weiterhin für die Wartung gebündelter Plugins und
+zur Kompatibilität. Sie sind nicht das empfohlene Muster für neue Channel-Plugins;
+bevorzugen Sie die generischen Unterpfade channel/setup/reply/runtime aus der gemeinsamen SDK-
+Oberfläche, es sei denn, Sie warten direkt diese gebündelte Plugin-Familie.
## Nächste Schritte
-- [Anbieter-Plugins](/de/plugins/sdk-provider-plugins) — wenn Ihr Plugin auch Modelle bereitstellt
-- [SDK-Überblick](/de/plugins/sdk-overview) — vollständige Referenz für Subpfad-Importe
-- [SDK Testing](/de/plugins/sdk-testing) — Test-Utilities und Vertragstests
+- [Provider-Plugins](/de/plugins/sdk-provider-plugins) — wenn Ihr Plugin auch Modelle bereitstellt
+- [SDK-Überblick](/de/plugins/sdk-overview) — vollständige Referenz für Subpath-Importe
+- [SDK-Testing](/de/plugins/sdk-testing) — Test-Utilities und Vertragstests
- [Plugin-Manifest](/de/plugins/manifest) — vollständiges Manifest-Schema
diff --git a/docs/de/providers/github-copilot.md b/docs/de/providers/github-copilot.md
index bfb6edf19..1f062e47d 100644
--- a/docs/de/providers/github-copilot.md
+++ b/docs/de/providers/github-copilot.md
@@ -1,44 +1,42 @@
---
read_when:
- - Sie möchten GitHub Copilot als Modell-Provider verwenden.
- - Sie benötigen den Ablauf `openclaw models auth login-github-copilot`.
-summary: Bei GitHub Copilot aus OpenClaw heraus 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 aus bei GitHub Copilot an
title: GitHub Copilot
x-i18n:
- generated_at: "2026-04-21T06:30:07Z"
+ generated_at: "2026-04-21T19:20:43Z"
model: gpt-5.4
provider: openai
- source_hash: f7faafbd3bdcd8886e75fb0d40c3eec66355df3fca6160ebbbb9a0018b7839fe
+ source_hash: b5169839322f64b24b194302b61c5bad67c6cb6595989f9a1ef65867d8b68659
source_path: providers/github-copilot.md
workflow: 15
---
# GitHub Copilot
-GitHub Copilot ist der KI-Coding-Assistent von GitHub. 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.
+GitHub Copilot ist der KI-Coding-Assistent von GitHub. Er bietet Zugriff auf Copilot-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-Flow, um ein GitHub-Token zu erhalten, und tauschen Sie es dann gegen
- Copilot-API-Tokens aus, wenn OpenClaw läuft. Dies ist der **Standard** und der einfachste Weg,
- da dafür kein VS Code erforderlich ist.
+ Verwenden Sie den nativen Geräte-Login-Ablauf, um ein GitHub-Token zu erhalten, und tauschen Sie es dann gegen
+ Copilot-API-Tokens aus, wenn OpenClaw ausgeführt wird. Dies ist der **Standard** und der einfachste Weg,
+ da er kein VS Code erfordert.
-
+
```bash
openclaw models auth login-github-copilot
```
- Sie werden aufgefordert, eine URL zu besuchen und einen einmaligen Code einzugeben. Lassen Sie das
- Terminal geöffnet, bis der Vorgang abgeschlossen ist.
+ 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/claude-opus-4.6
+ openclaw models set github-copilot/claude-opus-4.7
```
Oder in der Konfiguration:
@@ -46,7 +44,7 @@ als Modell-Provider verwenden.
```json5
{
agents: {
- defaults: { model: { primary: "github-copilot/claude-opus-4.6" } },
+ defaults: { model: { primary: "github-copilot/claude-opus-4.7" } },
},
}
```
@@ -56,12 +54,12 @@ als Modell-Provider verwenden.
- Verwenden Sie die VS-Code-Extension **Copilot Proxy** als lokale Bridge. OpenClaw kommuniziert mit
+ 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 darüber
- routen müssen. Sie müssen das Plugin aktivieren und die VS-Code-Extension weiter ausführen.
+ 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 weiter ausführen.
@@ -69,10 +67,10 @@ als Modell-Provider verwenden.
## Optionale Flags
-| Flag | Beschreibung |
-| --------------- | --------------------------------------------------- |
-| `--yes` | Bestätigungsabfrage überspringen |
-| `--set-default` | Zusätzlich das empfohlene Standardmodell des Providers anwenden |
+| Flag | Beschreibung |
+| --------------- | ------------------------------------------------- |
+| `--yes` | Bestätigungsabfrage überspringen |
+| `--set-default` | Zusätzlich das empfohlene Standardmodell des Anbieters anwenden |
```bash
# Bestätigung überspringen
@@ -83,62 +81,61 @@ openclaw models auth login --provider github-copilot --method device --set-defau
```
-
- Der Device-Login-Flow erfordert ein interaktives TTY. Führen Sie ihn direkt in einem
+
+ Der Geräte-Login-Ablauf erfordert eine interaktive 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`).
- Modell-IDs von Claude verwenden automatisch den Transport Anthropic Messages. GPT-,
- o-series- und Gemini-Modelle verwenden weiterhin den Transport OpenAI Responses. OpenClaw
- wählt den richtigen Transport basierend auf der Modell-Ref aus.
+ 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.
-
- OpenClaw löst die Copilot-Authentifizierung in der folgenden
- Prioritätsreihenfolge aus Umgebungsvariablen auf:
+
+ OpenClaw löst die Copilot-Authentifizierung anhand von Umgebungsvariablen in der folgenden
+ Prioritätsreihenfolge auf:
- | 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) |
+ | Priority | Variable | Notes |
+ | -------- | --------------------- | -------------------------------- |
+ | 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) |
- Wenn mehrere Variablen gesetzt sind, verwendet OpenClaw die Variable mit der höchsten Priorität.
- Der Device-Login-Flow (`openclaw models auth login-github-copilot`) speichert
- sein Token im Auth-Profil-Store und hat Vorrang vor allen Umgebungsvariablen.
+ Wenn mehrere Variablen gesetzt sind, verwendet OpenClaw die mit der höchsten Priorität.
+ Der Geräte-Login-Ablauf (`openclaw models auth login-github-copilot`) speichert
+ sein Token im Auth-Profile-Store und hat Vorrang vor allen Umgebungsvariablen.
-
- Beim Login wird ein GitHub-Token im Auth-Profil-Store gespeichert und beim Ausführen von OpenClaw
- gegen ein Copilot-API-Token ausgetauscht. Sie müssen das
- Token nicht manuell verwalten.
+
+ Beim Login wird ein GitHub-Token im Auth-Profile-Store gespeichert und beim Ausführen von OpenClaw
+ gegen ein Copilot-API-Token ausgetauscht. 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 eine interaktive TTY. Führen Sie den Login-Befehl direkt in einem Terminal aus, nicht
+innerhalb eines Headless-Skripts oder CI-Jobs.
-## Embeddings für die Memory-Suche
+## Einbettungen für die Memory-Suche
-GitHub Copilot kann auch als Embedding-Provider für die
-[Memory-Suche](/de/concepts/memory-search) dienen. Wenn Sie ein Copilot-Abonnement haben und
-angemeldet sind, kann OpenClaw es ohne separaten API-Key für Embeddings verwenden.
+GitHub Copilot kann auch als Einbettungsanbieter für die
+[memory search](/de/concepts/memory-search) dienen. Wenn Sie ein Copilot-Abonnement haben und
+angemeldet sind, kann OpenClaw es ohne separaten API-Schlüssel für Einbettungen verwenden.
### Automatische Erkennung
-Wenn `memorySearch.provider` auf `"auto"` gesetzt ist (Standard), wird GitHub Copilot
-mit Priorität 15 ausprobiert — nach lokalen Embeddings, aber vor OpenAI und anderen kostenpflichtigen
-Providern. Wenn ein GitHub-Token verfügbar ist, erkennt OpenClaw verfügbare
-Embedding-Modelle über die Copilot-API und wählt automatisch das beste aus.
+Wenn `memorySearch.provider` auf `"auto"` gesetzt 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
@@ -148,7 +145,7 @@ Embedding-Modelle über die Copilot-API und wählt automatisch das beste aus.
defaults: {
memorySearch: {
provider: "github-copilot",
- // Optional: das automatisch erkannte Modell überschreiben
+ // Optional: override the auto-discovered model
model: "text-embedding-3-small",
},
},
@@ -156,24 +153,24 @@ Embedding-Modelle über die Copilot-API und wählt automatisch das beste aus.
}
```
-### So funktioniert es
+### Funktionsweise
-1. OpenClaw löst Ihr GitHub-Token auf (aus Env-Variablen oder dem Auth-Profil).
+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-Endpunkt `/models` ab, um verfügbare Embedding-Modelle zu erkennen.
+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 Embedding-Anfragen an den Copilot-Endpunkt `/embeddings`.
+5. Sendet Einbettungsanfragen an den Copilot-`/embeddings`-Endpunkt.
-Die Modellverfügbarkeit hängt von Ihrem GitHub-Tarif ab. Wenn keine Embedding-Modelle
-verfügbar sind, überspringt OpenClaw Copilot und probiert den nächsten Provider aus.
+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
- Provider, Modell-Refs und Failover-Verhalten auswählen.
+ Auswahl von Anbietern, Modell-Referenzen und Failover-Verhalten.
-
- Details zur Authentifizierung und Regeln zur Wiederverwendung von Zugangsdaten.
+
+ Details zur Authentifizierung und Regeln zur Wiederverwendung von Anmeldedaten.
diff --git a/docs/de/tools/subagents.md b/docs/de/tools/subagents.md
index 8b8cb72f4..15f30e6e7 100644
--- a/docs/de/tools/subagents.md
+++ b/docs/de/tools/subagents.md
@@ -1,26 +1,26 @@
---
read_when:
- - Du möchtest Hintergrund-/Parallelarbeit über den Agenten
- - Du änderst `sessions_spawn` oder die Tool-Richtlinie für Sub-Agents
- - Du implementierst oder behebst threadgebundene Subagent-Sessions
-summary: 'Sub-Agents: isolierte Agent-Läufe starten, die Ergebnisse zurück in den anfragenden Chat ankündigen'
+ - Sie möchten Hintergrund-/Parallelarbeit über den Agenten ausführen.
+ - Sie ändern die Richtlinie für `sessions_spawn` oder das Sub-Agent-Tool.
+ - Sie implementieren oder beheben Probleme bei threadgebundenen Subagent-Sitzungen.
+summary: 'Sub-Agents: isolierte Agentenläufe starten, die Ergebnisse an den anfragenden Chat zurückmelden'
title: Sub-Agents
x-i18n:
- generated_at: "2026-04-05T12:59:28Z"
+ generated_at: "2026-04-21T19:20:45Z"
model: gpt-5.4
provider: openai
- source_hash: 9df7cc35a3069ce4eb9c92a95df3ce5365a00a3fae92ff73def75461b58fec3f
+ source_hash: 218913f0db88d40e1b5fdb0201b8d23e7af23df572c86ff4be2637cb62498281
source_path: tools/subagents.md
workflow: 15
---
# Sub-Agents
-Sub-Agents sind Hintergrund-Agent-Läufe, die aus einem bestehenden Agent-Lauf heraus gestartet werden. Sie laufen in ihrer eigenen Session (`agent::subagent:`) und **kündigen** ihr Ergebnis nach Abschluss zurück im Chat-Channel des Anfragenden an. Jeder Sub-Agent-Lauf wird als [background task](/de/automation/tasks) verfolgt.
+Sub-Agents sind Hintergrund-Agentenläufe, die aus einem bestehenden Agentenlauf heraus gestartet werden. Sie laufen in ihrer eigenen Sitzung (`agent::subagent:`) und **melden** ihr Ergebnis nach Abschluss an den anfragenden Chat-Kanal zurück. Jeder Sub-Agent-Lauf wird als [Hintergrundaufgabe](/de/automation/tasks) verfolgt.
## Slash-Befehl
-Verwende `/subagents`, um Sub-Agent-Läufe für die **aktuelle Session** zu prüfen oder zu steuern:
+Verwenden Sie `/subagents`, um Sub-Agent-Läufe für die **aktuelle Sitzung** zu prüfen oder zu steuern:
- `/subagents list`
- `/subagents kill `
@@ -30,9 +30,9 @@ Verwende `/subagents`, um Sub-Agent-Läufe für die **aktuelle Session** zu prü
- `/subagents steer `
- `/subagents spawn [--model ] [--thinking ]`
-Steuerung für Thread-Bindungen:
+Steuerelemente für Thread-Bindung:
-Diese Befehle funktionieren auf Channels, die persistente Thread-Bindungen unterstützen. Siehe **Channels mit Thread-Unterstützung** unten.
+Diese Befehle funktionieren auf Kanälen, die persistente Thread-Bindungen unterstützen. Siehe **Kanäle mit Thread-Unterstützung** unten.
- `/focus `
- `/unfocus`
@@ -40,268 +40,269 @@ Diese Befehle funktionieren auf Channels, die persistente Thread-Bindungen unter
- `/session idle `
- `/session max-age `
-`/subagents info` zeigt Lauf-Metadaten (Status, Zeitstempel, Session-ID, Transkriptpfad, Bereinigung).
-Verwende `sessions_history` für eine begrenzte, sicherheitsgefilterte Ansicht des Verlaufs; prüfe den
-Transkriptpfad auf dem Datenträger, wenn du das rohe vollständige Transkript brauchst.
+`/subagents info` zeigt Lauf-Metadaten an (Status, Zeitstempel, Sitzungs-ID, Transkriptpfad, Bereinigung).
+Verwenden Sie `sessions_history` für eine begrenzte, sicherheitsgefilterte Erinnerungsansicht; prüfen Sie den
+Transkriptpfad auf dem Datenträger, wenn Sie das rohe vollständige Transkript benötigen.
### Spawn-Verhalten
-`/subagents spawn` startet einen Hintergrund-Sub-Agenten als Benutzerbefehl, nicht als internen Relay, und sendet ein finales Abschluss-Update zurück in den Chat des Anfragenden, wenn der Lauf beendet ist.
+`/subagents spawn` startet einen Sub-Agenten im Hintergrund als Benutzerbefehl, nicht als interne Weiterleitung, und sendet ein abschließendes Abschluss-Update an den anfragenden Chat, wenn der Lauf beendet ist.
- Der Spawn-Befehl blockiert nicht; er gibt sofort eine Lauf-ID zurück.
-- Nach Abschluss kündigt der Sub-Agent eine Zusammenfassung/Ergebnisnachricht im Chat-Channel des Anfragenden an.
-- Der Abschluss ist push-basiert. Sobald er gestartet wurde, solltest du nicht in einer Schleife `/subagents list`,
- `sessions_list` oder `sessions_history` pollen, nur um auf das Ende zu warten; prüfe den Status nur bei Bedarf zur Fehlersuche oder für Eingriffe.
-- Nach Abschluss schließt OpenClaw best-effort verfolgte Browser-Tabs/Prozesse, die von dieser Sub-Agent-Session geöffnet wurden, bevor der Bereinigungsablauf der Ankündigung weiterläuft.
+- Nach Abschluss meldet der Sub-Agent eine Zusammenfassungs-/Ergebnisnachricht an den anfragenden Chat-Kanal zurück.
+- Der Abschluss ist push-basiert. Nach dem Start sollten Sie nicht in einer Schleife `/subagents list`,
+ `sessions_list` oder `sessions_history` abfragen, nur um auf den Abschluss zu
+ warten; prüfen Sie den Status nur bei Bedarf für Debugging oder Eingriffe.
+- Nach Abschluss schließt OpenClaw nach bestem Bemühen verfolgte Browser-Tabs/Prozesse, die von dieser Sub-Agent-Sitzung geöffnet wurden, bevor der Bereinigungsablauf der Meldung fortgesetzt wird.
- Für manuelle Spawns ist die Zustellung robust:
- - OpenClaw versucht zuerst direkte `agent`-Zustellung mit einem stabilen Idempotenz-Schlüssel.
- - Wenn direkte Zustellung fehlschlägt, fällt es auf Queue-Routing zurück.
- - Wenn Queue-Routing weiterhin nicht verfügbar ist, wird die Ankündigung mit kurzem exponentiellem Backoff erneut versucht, bevor endgültig aufgegeben wird.
-- Die Zustellung des Abschlusses behält die aufgelöste Route des Anfragenden bei:
- - threadgebundene oder konversationsgebundene Abschlussrouten gewinnen, wenn verfügbar
- - wenn der Abschluss-Ursprung nur einen Channel angibt, ergänzt OpenClaw das fehlende Ziel/Konto aus der aufgelösten Route der anfragenden Session (`lastChannel` / `lastTo` / `lastAccountId`), damit direkte Zustellung weiterhin funktioniert
-- Die Abschluss-Übergabe an die Session des Anfragenden ist intern zur Laufzeit erzeugter Kontext (kein vom Benutzer verfasster Text) und enthält:
- - `Result` (neuester sichtbarer `assistant`-Antworttext, andernfalls bereinigter neuester `tool`-/`toolResult`-Text)
+ - OpenClaw versucht zuerst die direkte `agent`-Zustellung mit einem stabilen Idempotenzschlüssel.
+ - Wenn die direkte Zustellung fehlschlägt, erfolgt ein Fallback auf Queue-Routing.
+ - Wenn Queue-Routing weiterhin nicht verfügbar ist, wird die Meldung mit einem kurzen exponentiellen Backoff erneut versucht, bevor endgültig aufgegeben wird.
+- Die Abschlusszustellung behält die aufgelöste Anfrageroute bei:
+ - threadgebundene oder konversationsgebundene Abschlussrouten haben Vorrang, wenn verfügbar
+ - wenn der Abschlussursprung nur einen Kanal bereitstellt, ergänzt OpenClaw das fehlende Ziel/Konto aus der aufgelösten Route der Anfragersitzung (`lastChannel` / `lastTo` / `lastAccountId`), sodass die direkte Zustellung weiterhin funktioniert
+- Die Abschlussübergabe an die Anfragersitzung ist zur Laufzeit generierter interner Kontext (kein vom Benutzer verfasster Text) und enthält:
+ - `Result` (letzter sichtbarer `assistant`-Antworttext, andernfalls bereinigter letzter Tool-/`toolResult`-Text; terminal fehlgeschlagene Läufe verwenden keinen erfassten Antworttext erneut)
- `Status` (`completed successfully` / `failed` / `timed out` / `unknown`)
- kompakte Laufzeit-/Token-Statistiken
- - eine Zustellanweisung, die dem anfragenden Agenten sagt, in normaler Assistentenstimme umzuschreiben (keine rohen internen Metadaten weiterleiten)
-- `--model` und `--thinking` überschreiben die Standardwerte für genau diesen Lauf.
-- Verwende `info`/`log`, um Details und Ausgabe nach Abschluss zu prüfen.
-- `/subagents spawn` ist Einmalmodus (`mode: "run"`). Für persistente threadgebundene Sessions verwende `sessions_spawn` mit `thread: true` und `mode: "session"`.
-- Für ACP-Harness-Sessions (Codex, Claude Code, Gemini CLI) verwende `sessions_spawn` mit `runtime: "acp"` und siehe [ACP Agents](/tools/acp-agents).
+ - eine Zustellungsanweisung, die dem anfragenden Agenten mitteilt, in normaler Assistant-Stimme umzuschreiben (keine rohen internen Metadaten weiterleiten)
+- `--model` und `--thinking` überschreiben die Standardwerte für diesen spezifischen Lauf.
+- Verwenden Sie `info`/`log`, um Details und Ausgabe nach Abschluss zu prüfen.
+- `/subagents spawn` ist der Einmalmodus (`mode: "run"`). Für persistente threadgebundene Sitzungen verwenden Sie `sessions_spawn` mit `thread: true` und `mode: "session"`.
+- Für ACP-Harness-Sitzungen (Codex, Claude Code, Gemini CLI) verwenden Sie `sessions_spawn` mit `runtime: "acp"` und siehe [ACP Agents](/de/tools/acp-agents).
Primäre Ziele:
- „Recherche / lange Aufgabe / langsames Tool“-Arbeit parallelisieren, ohne den Hauptlauf zu blockieren.
-- Sub-Agents standardmäßig isoliert halten (Session-Trennung + optionales Sandboxing).
-- Die Tool-Oberfläche schwer missbrauchbar halten: Sub-Agents erhalten standardmäßig **keine** Session-Tools.
+- Sub-Agents standardmäßig isoliert halten (Sitzungstrennung + optionales Sandboxing).
+- Die Tool-Oberfläche schwer missbrauchbar halten: Sub-Agents erhalten standardmäßig **keine** Sitzungs-Tools.
- Konfigurierbare Verschachtelungstiefe für Orchestrator-Muster unterstützen.
-Hinweis zu Kosten: Jeder Sub-Agent hat seinen **eigenen** Kontext und eigenen Token-Verbrauch. Für schwere oder wiederkehrende
-Aufgaben setze ein günstigeres Modell für Sub-Agents und behalte deinen Hauptagenten auf einem hochwertigeren Modell.
-Du kannst dies über `agents.defaults.subagents.model` oder agentenspezifische Overrides konfigurieren.
+Hinweis zu Kosten: Jeder Sub-Agent hat seinen **eigenen** Kontext und eigenen Token-Verbrauch. Für schwere oder wiederholte
+Aufgaben sollten Sie ein günstigeres Modell für Sub-Agents festlegen und Ihren Hauptagenten auf einem hochwertigeren Modell belassen.
+Sie können dies über `agents.defaults.subagents.model` oder agentenspezifische Überschreibungen konfigurieren.
## Tool
-Verwende `sessions_spawn`:
+Verwenden Sie `sessions_spawn`:
- Startet einen Sub-Agent-Lauf (`deliver: false`, globale Lane: `subagent`)
-- Führt dann einen Ankündigungsschritt aus und postet die Ankündigungsantwort in den Chat-Channel des Anfragenden
-- Standardmodell: übernimmt den Aufrufer, außer du setzt `agents.defaults.subagents.model` (oder pro Agent `agents.list[].subagents.model`); ein explizites `sessions_spawn.model` gewinnt weiterhin.
-- Standard-Reasoning: übernimmt den Aufrufer, außer du setzt `agents.defaults.subagents.thinking` (oder pro Agent `agents.list[].subagents.thinking`); ein explizites `sessions_spawn.thinking` gewinnt weiterhin.
-- Standard-Run-Timeout: Wenn `sessions_spawn.runTimeoutSeconds` weggelassen wird, verwendet OpenClaw `agents.defaults.subagents.runTimeoutSeconds`, falls gesetzt; andernfalls fällt es auf `0` zurück (kein Timeout).
+- Führt dann einen Meldungsschritt aus und veröffentlicht die Meldungsantwort im anfragenden Chat-Kanal
+- Standardmodell: übernimmt den Aufrufer, sofern Sie nicht `agents.defaults.subagents.model` (oder agentenspezifisch `agents.list[].subagents.model`) festlegen; ein explizites `sessions_spawn.model` hat weiterhin Vorrang.
+- Standard-`thinking`: übernimmt den Aufrufer, sofern Sie nicht `agents.defaults.subagents.thinking` (oder agentenspezifisch `agents.list[].subagents.thinking`) festlegen; ein explizites `sessions_spawn.thinking` hat weiterhin Vorrang.
+- Standard-Lauf-Timeout: Wenn `sessions_spawn.runTimeoutSeconds` weggelassen wird, verwendet OpenClaw `agents.defaults.subagents.runTimeoutSeconds`, wenn gesetzt; andernfalls wird auf `0` zurückgefallen (kein Timeout).
Tool-Parameter:
- `task` (erforderlich)
- `label?` (optional)
-- `agentId?` (optional; unter einer anderen Agent-ID starten, falls erlaubt)
-- `model?` (optional; überschreibt das Sub-Agent-Modell; ungültige Werte werden übersprungen und der Sub-Agent läuft mit dem Standardmodell weiter, mit einer Warnung im Tool-Ergebnis)
-- `thinking?` (optional; überschreibt den Thinking-Level für den Sub-Agent-Lauf)
-- `runTimeoutSeconds?` (Standard ist `agents.defaults.subagents.runTimeoutSeconds`, wenn gesetzt, sonst `0`; wenn gesetzt, wird der Sub-Agent-Lauf nach N Sekunden abgebrochen)
-- `thread?` (Standard `false`; wenn `true`, wird für diese Sub-Agent-Session eine Channel-Thread-Bindung angefordert)
+- `agentId?` (optional; unter einer anderen Agenten-ID starten, falls erlaubt)
+- `model?` (optional; überschreibt das Sub-Agent-Modell; ungültige Werte werden übersprungen und der Sub-Agent läuft mit dem Standardmodell mit einer Warnung im Tool-Ergebnis)
+- `thinking?` (optional; überschreibt die Thinking-Stufe für den Sub-Agent-Lauf)
+- `runTimeoutSeconds?` (standardmäßig `agents.defaults.subagents.runTimeoutSeconds`, wenn gesetzt, andernfalls `0`; wenn gesetzt, wird der Sub-Agent-Lauf nach N Sekunden abgebrochen)
+- `thread?` (standardmäßig `false`; wenn `true`, wird eine Kanal-Thread-Bindung für diese Sub-Agent-Sitzung angefordert)
- `mode?` (`run|session`)
- Standard ist `run`
- - wenn `thread: true` und `mode` weggelassen wird, wird der Standard zu `session`
+ - wenn `thread: true` und `mode` ausgelassen wird, wird standardmäßig `session`
- `mode: "session"` erfordert `thread: true`
-- `cleanup?` (`delete|keep`, Standard `keep`)
-- `sandbox?` (`inherit|require`, Standard `inherit`; `require` lehnt den Spawn ab, wenn die Laufzeit des Ziel-Childs nicht sandboxed ist)
-- `sessions_spawn` akzeptiert **keine** Parameter für Channel-Zustellung (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Für Zustellung verwende `message`/`sessions_send` aus dem gestarteten Lauf.
+- `cleanup?` (`delete|keep`, standardmäßig `keep`)
+- `sandbox?` (`inherit|require`, standardmäßig `inherit`; `require` lehnt den Spawn ab, es sei denn, die Ziel-Child-Runtime ist sandboxed)
+- `sessions_spawn` akzeptiert **keine** Kanal-Zustellparameter (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Für die Zustellung verwenden Sie `message`/`sessions_send` aus dem gestarteten Lauf.
-## Threadgebundene Sessions
+## Threadgebundene Sitzungen
-Wenn Thread-Bindungen für einen Channel aktiviert sind, kann ein Sub-Agent an einen Thread gebunden bleiben, sodass nachfolgende Benutzernachrichten in diesem Thread weiterhin an dieselbe Sub-Agent-Session geroutet werden.
+Wenn Thread-Bindungen für einen Kanal aktiviert sind, kann ein Sub-Agent an einen Thread gebunden bleiben, sodass nachfolgende Benutzernachrichten in diesem Thread weiterhin an dieselbe Sub-Agent-Sitzung geleitet werden.
-### Channels mit Thread-Unterstützung
+### Kanäle mit Thread-Unterstützung
-- Discord (derzeit der einzige unterstützte Channel): unterstützt persistente threadgebundene Subagent-Sessions (`sessions_spawn` mit `thread: true`), manuelle Thread-Steuerung (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) und Adapter-Schlüssel `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` und `channels.discord.threadBindings.spawnSubagentSessions`.
+- Discord (derzeit der einzige unterstützte Kanal): unterstützt persistente threadgebundene Sub-Agent-Sitzungen (`sessions_spawn` mit `thread: true`), manuelle Thread-Steuerung (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) und Adapter-Schlüssel `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` und `channels.discord.threadBindings.spawnSubagentSessions`.
-Schneller Ablauf:
+Kurzer Ablauf:
-1. Starte mit `sessions_spawn` unter Verwendung von `thread: true` (und optional `mode: "session"`).
-2. OpenClaw erstellt oder bindet einen Thread an dieses Session-Ziel im aktiven Channel.
-3. Antworten und Folge-Nachrichten in diesem Thread werden an die gebundene Session geroutet.
-4. Verwende `/session idle`, um automatisches Entfokussieren bei Inaktivität zu prüfen/aktualisieren, und `/session max-age`, um die harte Obergrenze zu steuern.
-5. Verwende `/unfocus`, um die Bindung manuell zu lösen.
+1. Starten Sie mit `sessions_spawn` unter Verwendung von `thread: true` (und optional `mode: "session"`).
+2. OpenClaw erstellt einen Thread oder bindet einen Thread an dieses Sitzungsziel im aktiven Kanal.
+3. Antworten und Folgemeldungen in diesem Thread werden an die gebundene Sitzung weitergeleitet.
+4. Verwenden Sie `/session idle`, um die automatische Entfokussierung bei Inaktivität zu prüfen/aktualisieren, und `/session max-age`, um die harte Obergrenze zu steuern.
+5. Verwenden Sie `/unfocus`, um die Bindung manuell zu lösen.
-Manuelle Steuerung:
+Manuelle Steuerelemente:
-- `/focus ` bindet den aktuellen Thread (oder erstellt einen) an ein Sub-Agent-/Session-Ziel.
+- `/focus ` bindet den aktuellen Thread (oder erstellt einen) an ein Sub-Agent-/Sitzungsziel.
- `/unfocus` entfernt die Bindung für den aktuell gebundenen Thread.
-- `/agents` listet aktive Läufe und den Bindungszustand auf (`thread:` oder `unbound`).
+- `/agents` listet aktive Läufe und den Bindungsstatus auf (`thread:` oder `unbound`).
- `/session idle` und `/session max-age` funktionieren nur für fokussierte gebundene Threads.
Konfigurationsschalter:
- Globaler Standard: `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`
-- Channel-Override- und Spawn-Auto-Bind-Schlüssel sind adapterspezifisch. Siehe **Channels mit Thread-Unterstützung** oben.
+- Kanalüberschreibung und Schlüssel für automatisches Spawn-Binding sind adapterspezifisch. Siehe **Kanäle mit Thread-Unterstützung** oben.
-Siehe [Configuration Reference](/de/gateway/configuration-reference) und [Slash commands](/tools/slash-commands) für aktuelle Adapter-Details.
+Siehe [Configuration Reference](/de/gateway/configuration-reference) und [Slash commands](/de/tools/slash-commands) für aktuelle Adapterdetails.
Allowlist:
-- `agents.list[].subagents.allowAgents`: Liste von Agent-IDs, die über `agentId` angesprochen werden dürfen (`["*"]`, um beliebige zu erlauben). Standard: nur der anfragende Agent.
-- `agents.defaults.subagents.allowAgents`: Standard-Allowlist für Ziel-Agenten, wenn der anfragende Agent nicht seine eigene `subagents.allowAgents` setzt.
-- Guard für Sandbox-Vererbung: Wenn die anfragende Session sandboxed ist, lehnt `sessions_spawn` Ziele ab, die unsandboxed laufen würden.
-- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: wenn `true`, blockiert `sessions_spawn`-Aufrufe ohne `agentId` (erzwingt explizite Profilauswahl). Standard: false.
+- `agents.list[].subagents.allowAgents`: Liste von Agenten-IDs, die über `agentId` als Ziel verwendet werden können (`["*"]`, um beliebige zu erlauben). Standard: nur der anfragende Agent.
+- `agents.defaults.subagents.allowAgents`: Standard-Zielagenten-Allowlist, die verwendet wird, wenn der anfragende Agent keine eigene `subagents.allowAgents` setzt.
+- Sandbox-Vererbungswächter: Wenn die Anfragersitzung sandboxed ist, lehnt `sessions_spawn` Ziele ab, die unsandboxed laufen würden.
+- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: Wenn `true`, werden `sessions_spawn`-Aufrufe blockiert, die `agentId` auslassen (erzwingt explizite Profilauswahl). Standard: `false`.
Erkennung:
-- Verwende `agents_list`, um zu sehen, welche Agent-IDs derzeit für `sessions_spawn` erlaubt sind.
+- Verwenden Sie `agents_list`, um zu sehen, welche Agenten-IDs derzeit für `sessions_spawn` erlaubt sind.
-Auto-Archivierung:
+Automatische Archivierung:
-- Sub-Agent-Sessions werden nach `agents.defaults.subagents.archiveAfterMinutes` automatisch archiviert (Standard: 60).
+- Sub-Agent-Sitzungen werden nach `agents.defaults.subagents.archiveAfterMinutes` automatisch archiviert (Standard: 60).
- Die Archivierung verwendet `sessions.delete` und benennt das Transkript in `*.deleted.` um (im selben Ordner).
-- `cleanup: "delete"` archiviert sofort nach der Ankündigung (behält das Transkript dennoch durch Umbenennung).
-- Auto-Archivierung ist best-effort; ausstehende Timer gehen verloren, wenn das Gateway neu gestartet wird.
-- `runTimeoutSeconds` archiviert **nicht** automatisch; es stoppt nur den Lauf. Die Session bleibt bis zur Auto-Archivierung bestehen.
-- Auto-Archivierung gilt gleichermaßen für Sessions der Tiefe 1 und Tiefe 2.
-- Browser-Bereinigung ist getrennt von Archiv-Bereinigung: verfolgte Browser-Tabs/Prozesse werden best-effort geschlossen, wenn der Lauf endet, auch wenn Transkript/Session-Eintrag erhalten bleiben.
+- `cleanup: "delete"` archiviert unmittelbar nach der Meldung (behält das Transkript dennoch durch Umbenennung).
+- Die automatische Archivierung erfolgt nach bestem Bemühen; ausstehende Timer gehen verloren, wenn das Gateway neu startet.
+- `runTimeoutSeconds` archiviert nicht automatisch; es stoppt nur den Lauf. Die Sitzung bleibt bis zur automatischen Archivierung bestehen.
+- Die automatische Archivierung gilt gleichermaßen für Sitzungen der Tiefe 1 und Tiefe 2.
+- Browser-Bereinigung ist von der Archivbereinigung getrennt: Verfolgte Browser-Tabs/Prozesse werden nach bestem Bemühen geschlossen, wenn der Lauf endet, selbst wenn das Transkript/der Sitzungsdatensatz erhalten bleibt.
## Verschachtelte Sub-Agents
-Standardmäßig können Sub-Agents keine eigenen Sub-Agents starten (`maxSpawnDepth: 1`). Du kannst eine Ebene der Verschachtelung aktivieren, indem du `maxSpawnDepth: 2` setzt; das erlaubt das **Orchestrator-Muster**: main → Orchestrator-Sub-Agent → Worker-Sub-Sub-Agents.
+Standardmäßig können Sub-Agents keine eigenen Sub-Agents starten (`maxSpawnDepth: 1`). Sie können eine Ebene der Verschachtelung aktivieren, indem Sie `maxSpawnDepth: 2` setzen; dadurch wird das **Orchestrator-Muster** erlaubt: Hauptagent → Orchestrator-Sub-Agent → Worker-Sub-Sub-Agents.
-### So wird es aktiviert
+### Aktivierung
```json5
{
agents: {
defaults: {
subagents: {
- maxSpawnDepth: 2, // erlaubt Sub-Agents, Childs zu starten (Standard: 1)
- maxChildrenPerAgent: 5, // maximale Anzahl aktiver Childs pro Agent-Session (Standard: 5)
- maxConcurrent: 8, // globale Concurrency-Lane-Obergrenze (Standard: 8)
- runTimeoutSeconds: 900, // Standard-Timeout für sessions_spawn, wenn weggelassen (0 = kein Timeout)
+ maxSpawnDepth: 2, // Sub-Agents dürfen Children starten (Standard: 1)
+ maxChildrenPerAgent: 5, // maximal aktive Children pro Agentensitzung (Standard: 5)
+ maxConcurrent: 8, // globale Obergrenze für gleichzeitige Ausführung in der Lane (Standard: 8)
+ runTimeoutSeconds: 900, // Standard-Timeout für sessions_spawn, wenn ausgelassen (0 = kein Timeout)
},
},
},
}
```
-### Tiefenstufen
+### Tiefenebenen
-| Tiefe | Form des Session-Keys | Rolle | Kann Childs starten? |
-| ----- | -------------------------------------------- | -------------------------------------------- | ---------------------------- |
-| 0 | `agent::main` | Hauptagent | Immer |
+| Tiefe | Form des Sitzungsschlüssels | Rolle | Kann starten? |
+| ----- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
+| 0 | `agent::main` | Hauptagent | Immer |
| 1 | `agent::subagent:` | Sub-Agent (Orchestrator, wenn Tiefe 2 erlaubt) | Nur wenn `maxSpawnDepth >= 2` |
-| 2 | `agent::subagent::subagent:` | Sub-Sub-Agent (Leaf-Worker) | Niemals |
+| 2 | `agent::subagent::subagent:` | Sub-Sub-Agent (Leaf-Worker) | Niemals |
-### Ankündigungskette
+### Meldekette
Ergebnisse fließen die Kette zurück nach oben:
-1. Worker der Tiefe 2 beendet → kündigt seinem Parent an (Orchestrator der Tiefe 1)
-2. Orchestrator der Tiefe 1 erhält die Ankündigung, synthetisiert Ergebnisse, beendet → kündigt main an
-3. Der Hauptagent erhält die Ankündigung und liefert an den Benutzer aus
+1. Worker der Tiefe 2 wird abgeschlossen → meldet an seinen Parent (Orchestrator der Tiefe 1)
+2. Orchestrator der Tiefe 1 empfängt die Meldung, synthetisiert Ergebnisse, wird abgeschlossen → meldet an den Hauptagenten
+3. Hauptagent empfängt die Meldung und stellt sie dem Benutzer zu
-Jede Ebene sieht nur Ankündigungen ihrer direkten Childs.
+Jede Ebene sieht nur Meldungen ihrer direkten Children.
Betriebshinweise:
-- Starte Child-Arbeit einmal und warte auf Abschlussereignisse, statt Poll-
+- Starten Sie Child-Arbeit einmal und warten Sie auf Abschlussereignisse, anstatt Polling-
Schleifen um `sessions_list`, `sessions_history`, `/subagents list` oder
- `exec`-Sleep-Befehle zu bauen.
-- Wenn ein Child-Abschlussereignis eintrifft, nachdem du bereits die finale Antwort gesendet hast,
+ `exec`-sleep-Befehle zu bauen.
+- Wenn ein Child-Abschlussereignis eintrifft, nachdem Sie bereits die endgültige Antwort gesendet haben,
ist die korrekte Folgeaktion das exakte stille Token `NO_REPLY` / `no_reply`.
### Tool-Richtlinie nach Tiefe
-- Rolle und Kontrollumfang werden beim Spawn in Session-Metadaten geschrieben. Das verhindert, dass flache oder wiederhergestellte Session-Keys versehentlich wieder Orchestrator-Rechte erhalten.
-- **Tiefe 1 (Orchestrator, wenn `maxSpawnDepth >= 2`)**: Erhält `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, damit Childs verwaltet werden können. Andere Session-/System-Tools bleiben verweigert.
-- **Tiefe 1 (Leaf, wenn `maxSpawnDepth == 1`)**: Keine Session-Tools (aktuelles Standardverhalten).
-- **Tiefe 2 (Leaf-Worker)**: Keine Session-Tools — `sessions_spawn` ist auf Tiefe 2 immer verweigert. Es können keine weiteren Childs gestartet werden.
+- Rolle und Kontrollumfang werden beim Start in die Sitzungsmetadaten geschrieben. Dadurch wird verhindert, dass flache oder wiederhergestellte Sitzungsschlüssel versehentlich wieder Orchestrator-Berechtigungen erhalten.
+- **Tiefe 1 (Orchestrator, wenn `maxSpawnDepth >= 2`)**: Erhält `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, damit er seine Children verwalten kann. Andere Sitzungs-/System-Tools bleiben weiterhin verweigert.
+- **Tiefe 1 (Leaf, wenn `maxSpawnDepth == 1`)**: Keine Sitzungs-Tools (aktuelles Standardverhalten).
+- **Tiefe 2 (Leaf-Worker)**: Keine Sitzungs-Tools — `sessions_spawn` wird in Tiefe 2 immer verweigert. Kann keine weiteren Children starten.
### Spawn-Limit pro Agent
-Jede Agent-Session (in beliebiger Tiefe) kann höchstens `maxChildrenPerAgent` (Standard: 5) aktive Childs gleichzeitig haben. Das verhindert unkontrolliertes Aufspalten von einem einzelnen Orchestrator aus.
+Jede Agentensitzung (in jeder Tiefe) kann höchstens `maxChildrenPerAgent` (Standard: 5) aktive Children gleichzeitig haben. Das verhindert unkontrolliertes Fan-out von einem einzelnen Orchestrator.
### Kaskadierendes Stoppen
-Das Stoppen eines Orchestrators der Tiefe 1 stoppt automatisch alle Childs der Tiefe 2:
+Das Stoppen eines Orchestrators der Tiefe 1 stoppt automatisch alle seine Children der Tiefe 2:
-- `/stop` im Hauptchat stoppt alle Agenten der Tiefe 1 und kaskadiert zu deren Childs der Tiefe 2.
-- `/subagents kill ` stoppt einen bestimmten Sub-Agenten und kaskadiert zu seinen Childs.
+- `/stop` im Hauptchat stoppt alle Agenten der Tiefe 1 und kaskadiert zu ihren Children der Tiefe 2.
+- `/subagents kill ` stoppt einen bestimmten Sub-Agenten und kaskadiert zu seinen Children.
- `/subagents kill all` stoppt alle Sub-Agents für den Anfragenden und kaskadiert.
## Authentifizierung
-Die Authentifizierung für Sub-Agents wird anhand der **Agent-ID** aufgelöst, nicht anhand des Session-Typs:
+Die Authentifizierung für Sub-Agents wird über die **Agenten-ID** aufgelöst, nicht über den Sitzungstyp:
-- Der Session-Key des Sub-Agenten ist `agent::subagent:`.
+- Der Sitzungsschlüssel des Sub-Agenten ist `agent::subagent:`.
- Der Auth-Store wird aus dem `agentDir` dieses Agenten geladen.
-- Die Auth-Profile des Hauptagenten werden als **Fallback** zusammengeführt; bei Konflikten überschreiben Agent-Profile die Profile von main.
+- Die Auth-Profile des Hauptagenten werden als **Fallback** zusammengeführt; Agentenprofile überschreiben bei Konflikten die Profile des Hauptagenten.
-Hinweis: Das Zusammenführen ist additiv, daher sind Profile von main immer als Fallbacks verfügbar. Vollständig isolierte Authentifizierung pro Agent wird derzeit noch nicht unterstützt.
+Hinweis: Die Zusammenführung ist additiv, daher sind die Profile des Hauptagenten immer als Fallbacks verfügbar. Vollständig isolierte Authentifizierung pro Agent wird derzeit noch nicht unterstützt.
-## Ankündigung
+## Meldung
-Sub-Agents melden sich über einen Ankündigungsschritt zurück:
+Sub-Agents melden sich über einen Meldungsschritt zurück:
-- Der Ankündigungsschritt läuft innerhalb der Sub-Agent-Session (nicht in der Session des Anfragenden).
-- Wenn der Sub-Agent exakt `ANNOUNCE_SKIP` antwortet, wird nichts gepostet.
-- Wenn der neueste Assistententext das exakte stille Token `NO_REPLY` / `no_reply` ist,
- wird die Ankündigungsausgabe unterdrückt, selbst wenn es zuvor sichtbaren Fortschritt gab.
-- Andernfalls hängt die Zustellung von der Tiefe des Anfragenden ab:
- - Sessions von Anfragenden auf oberster Ebene verwenden einen nachgelagerten `agent`-Aufruf mit externer Zustellung (`deliver=true`)
- - verschachtelte Subagent-Sessions des Anfragenden erhalten eine interne Follow-up-Injektion (`deliver=false`), sodass der Orchestrator Child-Ergebnisse in der Session synthetisieren kann
- - wenn eine verschachtelte Session eines anfragenden Subagenten nicht mehr existiert, fällt OpenClaw, wenn möglich, auf den Anfragenden dieser Session zurück
-- Für Sessions von Anfragenden auf oberster Ebene löst direkte Zustellung im Completion-Modus zuerst jede gebundene Konversations-/Thread-Route und jeden Hook-Override auf und ergänzt dann fehlende Channel-Zielfelder aus der gespeicherten Route der anfragenden Session. So bleiben Abschlüsse im richtigen Chat/Topic, selbst wenn der Abschluss-Ursprung nur den Channel identifiziert.
-- Die Aggregation von Child-Abschlüssen ist beim Erstellen verschachtelter Completion-Funde auf den aktuellen Lauf des Anfragenden beschränkt, damit keine veralteten Child-Ausgaben früherer Läufe in die aktuelle Ankündigung gelangen.
-- Ankündigungsantworten behalten Thread-/Topic-Routing bei, wenn dies in Channel-Adaptern verfügbar ist.
-- Der Ankündigungskontext wird zu einem stabilen internen Ereignisblock normalisiert:
+- Der Meldungsschritt läuft innerhalb der Sub-Agent-Sitzung (nicht in der Anfragersitzung).
+- Wenn der Sub-Agent exakt `ANNOUNCE_SKIP` antwortet, wird nichts veröffentlicht.
+- Wenn der letzte Assistant-Text das exakte stille Token `NO_REPLY` / `no_reply` ist,
+ wird die Meldungsausgabe unterdrückt, selbst wenn es zuvor sichtbaren Fortschritt gab.
+- Andernfalls hängt die Zustellung von der Anfragertiefe ab:
+ - Anfragersitzungen der obersten Ebene verwenden einen nachgelagerten `agent`-Aufruf mit externer Zustellung (`deliver=true`)
+ - verschachtelte Anfrager-Subagent-Sitzungen erhalten eine interne nachgelagerte Injektion (`deliver=false`), damit der Orchestrator Child-Ergebnisse in der Sitzung synthetisieren kann
+ - wenn eine verschachtelte Anfrager-Subagent-Sitzung nicht mehr existiert, fällt OpenClaw, wenn verfügbar, auf den Anfragenden dieser Sitzung zurück
+- Für Anfragersitzungen der obersten Ebene löst die direkte Zustellung im Abschlussmodus zunächst jede gebundene Konversations-/Thread-Route und Hook-Überschreibung auf und ergänzt dann fehlende Kanal-Zielfelder aus der gespeicherten Route der Anfragersitzung. Dadurch bleiben Abschlüsse im richtigen Chat/Topic, auch wenn der Abschlussursprung nur den Kanal identifiziert.
+- Die Aggregation von Child-Abschlüssen wird beim Erstellen verschachtelter Abschlussbefunde auf den aktuellen Anfragerlauf begrenzt, damit veraltete Child-Ausgaben aus früheren Läufen nicht in die aktuelle Meldung gelangen.
+- Meldungsantworten behalten Thread-/Topic-Routing bei, wenn dies in Kanaladaptern verfügbar ist.
+- Der Meldungskontext wird zu einem stabilen internen Ereignisblock normalisiert:
- Quelle (`subagent` oder `cron`)
- - Child-Session-Key/-ID
- - Ankündigungstyp + Aufgabenlabel
- - Statuszeile aus Laufzeitsignalen (`success`, `error`, `timeout` oder `unknown`)
- - Ergebnisinhalt aus dem neuesten sichtbaren Assistententext, andernfalls aus bereinigtem neuesten `tool`-/`toolResult`-Text
- - eine Follow-up-Anweisung, die beschreibt, wann geantwortet und wann still geblieben werden soll
-- `Status` wird nicht aus der Modellausgabe abgeleitet; er stammt aus Laufzeitsignalen.
-- Bei Timeout kann die Ankündigung, wenn das Child nur Tool-Aufrufe geschafft hat, diesen Verlauf in eine kurze Zusammenfassung des Teilfortschritts zusammenziehen, statt rohe Tool-Ausgabe erneut wiederzugeben.
+ - Child-Sitzungsschlüssel/-ID
+ - Meldungstyp + Aufgabenlabel
+ - Statuszeile, abgeleitet aus dem Laufzeitergebnis (`success`, `error`, `timeout` oder `unknown`)
+ - Ergebnisinhalt, ausgewählt aus dem letzten sichtbaren Assistant-Text, andernfalls bereinigter letzter Tool-/`toolResult`-Text; terminal fehlgeschlagene Läufe melden den Fehlerstatus, ohne erfassten Antworttext erneut wiederzugeben
+ - eine Folgeanweisung, die beschreibt, wann geantwortet und wann still geblieben werden soll
+- `Status` wird nicht aus der Modellausgabe abgeleitet; er stammt aus Laufzeit-Ergebnissignalen.
+- Bei einem Timeout kann die Meldung diese Historie zu einer kurzen Zusammenfassung des Teilfortschritts verdichten, wenn das Child nur bis zu Tool-Aufrufen gekommen ist, statt rohe Tool-Ausgabe wiederzugeben.
-Ankündigungs-Payloads enthalten am Ende eine Statistikzeile (auch wenn umbrochen):
+Meldungs-Payloads enthalten am Ende eine Statistikzeile (auch wenn sie umschlossen sind):
- Laufzeit (z. B. `runtime 5m12s`)
-- Token-Verbrauch (Eingabe/Ausgabe/Gesamt)
+- Token-Nutzung (Eingabe/Ausgabe/Gesamt)
- Geschätzte Kosten, wenn Modellpreise konfiguriert sind (`models.providers.*.models[].cost`)
- `sessionKey`, `sessionId` und Transkriptpfad (damit der Hauptagent den Verlauf über `sessions_history` abrufen oder die Datei auf dem Datenträger prüfen kann)
-- Interne Metadaten sind nur für Orchestrierung gedacht; benutzerseitige Antworten sollten in normaler Assistentenstimme umgeschrieben werden.
+- Interne Metadaten sind nur für die Orchestrierung gedacht; benutzerseitige Antworten sollten in normaler Assistant-Stimme umgeschrieben werden.
`sessions_history` ist der sicherere Orchestrierungspfad:
-- Assistenten-Recall wird zuerst normalisiert:
+- Assistant-Recall wird zuerst normalisiert:
- Thinking-Tags werden entfernt
- `` / ``-Gerüstblöcke werden entfernt
- - Klartext-XML-Payload-Blöcke für Tool-Aufrufe wie `...`,
+ - XML-Payload-Blöcke für Tool-Aufrufe im Klartext wie `...`,
`...`, `...` und
- `...` werden entfernt, einschließlich abgeschnittener
- Payloads, die nie sauber geschlossen wurden
- - herabgestuftes Tool-Call-/Result-Gerüst und Marker für historischen Kontext werden entfernt
- - durchgesickerte Kontroll-Tokens des Modells wie `<|assistant|>`, andere ASCII-
- `<|...|>`-Tokens und Full-Width-Varianten `<｜...｜>` werden entfernt
- - fehlerhaftes MiniMax-XML für Tool-Aufrufe wird entfernt
-- Credentials-/Token-ähnlicher Text wird geschwärzt
-- lange Blöcke können abgeschnitten werden
+ `...` werden entfernt, einschließlich
+ abgeschnittener Payloads, die nie sauber geschlossen werden
+ - herabgestufte Tool-Call-/Ergebnisgerüste und historische Kontextmarker werden entfernt
+ - ausgetretene Modell-Steuerungstoken wie `<|assistant|>`, andere ASCII-
+ `<|...|>`-Token und Varianten in voller Breite `<｜...｜>` werden entfernt
+ - fehlerhaftes MiniMax-Tool-Call-XML wird entfernt
+- credential-/tokenähnlicher Text wird geschwärzt
+- lange Blöcke können gekürzt werden
- sehr große Verläufe können ältere Zeilen verwerfen oder eine übergroße Zeile durch
`[sessions_history omitted: message too large]` ersetzen
-- die Prüfung des rohen On-Disk-Transkripts ist der Fallback, wenn du das vollständige Byte-für-Byte-Transkript brauchst
+- die Prüfung des rohen Transkripts auf dem Datenträger ist der Fallback, wenn Sie das vollständige bytegenaue Transkript benötigen
## Tool-Richtlinie (Sub-Agent-Tools)
-Standardmäßig erhalten Sub-Agents **alle Tools außer Session-Tools** und System-Tools:
+Standardmäßig erhalten Sub-Agents **alle Tools außer Sitzungs-Tools** und System-Tools:
- `sessions_list`
- `sessions_history`
- `sessions_send`
- `sessions_spawn`
-`sessions_history` bleibt auch hier eine begrenzte, bereinigte Recall-Ansicht; es ist
-kein roher Transkript-Dump.
+`sessions_history` bleibt auch hier eine begrenzte, bereinigte Erinnerungsansicht; es ist
+kein Rohdump des Transkripts.
-Wenn `maxSpawnDepth >= 2`, erhalten Orchestrator-Sub-Agents der Tiefe 1 zusätzlich `sessions_spawn`, `subagents`, `sessions_list` und `sessions_history`, damit sie ihre Childs verwalten können.
+Wenn `maxSpawnDepth >= 2`, erhalten Orchestrator-Sub-Agents der Tiefe 1 zusätzlich `sessions_spawn`, `subagents`, `sessions_list` und `sessions_history`, damit sie ihre Children verwalten können.
-Per Konfiguration überschreiben:
+Überschreibung per Konfiguration:
```json5
{
@@ -317,7 +318,7 @@ Per Konfiguration überschreiben:
tools: {
// deny gewinnt
deny: ["gateway", "cron"],
- // wenn allow gesetzt ist, wird es zur exklusiven Allowlist (deny gewinnt weiterhin)
+ // wenn allow gesetzt ist, wird es zu einer reinen Allowlist (deny gewinnt weiterhin)
// allow: ["read", "exec", "process"]
},
},
@@ -327,21 +328,21 @@ Per Konfiguration überschreiben:
## Nebenläufigkeit
-Sub-Agents verwenden eine dedizierte In-Process-Queue-Lane:
+Sub-Agents verwenden eine dedizierte prozessinterne Queue-Lane:
- Lane-Name: `subagent`
- Nebenläufigkeit: `agents.defaults.subagents.maxConcurrent` (Standard `8`)
## Stoppen
-- Das Senden von `/stop` im Chat des Anfragenden bricht die anfragende Session ab und stoppt alle aktiven Sub-Agent-Läufe, die daraus gestartet wurden, einschließlich kaskadierender Childs.
-- `/subagents kill ` stoppt einen bestimmten Sub-Agenten und kaskadiert zu seinen Childs.
+- Das Senden von `/stop` im Anfrager-Chat bricht die Anfragersitzung ab und stoppt alle aktiven Sub-Agent-Läufe, die daraus gestartet wurden, einschließlich kaskadierter verschachtelter Children.
+- `/subagents kill ` stoppt einen bestimmten Sub-Agenten und kaskadiert zu seinen Children.
## Einschränkungen
-- Die Ankündigung von Sub-Agents ist **best-effort**. Wenn das Gateway neu startet, geht ausstehende „zurück ankündigen“-Arbeit verloren.
-- Sub-Agents teilen sich weiterhin dieselben Prozessressourcen des Gateway; betrachte `maxConcurrent` als Sicherheitsventil.
+- Die Meldung von Sub-Agenten erfolgt **nach bestem Bemühen**. Wenn das Gateway neu startet, gehen ausstehende „Zurückmelden“-Aufgaben verloren.
+- Sub-Agents teilen sich weiterhin dieselben Gateway-Prozessressourcen; behandeln Sie `maxConcurrent` als Sicherheitsventil.
- `sessions_spawn` blockiert nie: Es gibt sofort `{ status: "accepted", runId, childSessionKey }` zurück.
-- Der Kontext von Sub-Agents injiziert nur `AGENTS.md` + `TOOLS.md` (kein `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` oder `BOOTSTRAP.md`).
-- Die maximale Verschachtelungstiefe ist 5 (`maxSpawnDepth`-Bereich: 1–5). Tiefe 2 wird für die meisten Anwendungsfälle empfohlen.
-- `maxChildrenPerAgent` begrenzt aktive Childs pro Session (Standard: 5, Bereich: 1–20).
+- Der Kontext von Sub-Agenten injiziert nur `AGENTS.md` + `TOOLS.md` (kein `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` oder `BOOTSTRAP.md`).
+- Die maximale Verschachtelungstiefe beträgt 5 (`maxSpawnDepth`-Bereich: 1–5). Tiefe 2 wird für die meisten Anwendungsfälle empfohlen.
+- `maxChildrenPerAgent` begrenzt aktive Children pro Sitzung (Standard: 5, Bereich: 1–20).
diff --git a/docs/de/tools/thinking.md b/docs/de/tools/thinking.md
index c8bf72a72..7e7eaa113 100644
--- a/docs/de/tools/thinking.md
+++ b/docs/de/tools/thinking.md
@@ -1,131 +1,131 @@
---
read_when:
- - Parsing oder Standardwerte für Thinking-, Fast-Mode- oder Verbose-Direktiven anpassen
-summary: Direktivsyntax für /think, /fast, /verbose, /trace und die Sichtbarkeit von Reasoning
-title: Thinking-Level
+ - Anpassen der Verarbeitung oder Standardwerte für Direktiven zu Denkniveau, Fast-Modus oder Ausführlichkeit
+summary: Direktivsyntax für /think, /fast, /verbose, /trace und Sichtbarkeit der Begründung
+title: Denkstufen
x-i18n:
- generated_at: "2026-04-21T13:38:06Z"
+ generated_at: "2026-04-21T19:21:09Z"
model: gpt-5.4
provider: openai
- source_hash: 1b0217f6e5a5cb3400090f31ad5271ca61848a40f77d3f942851e7c2f2352886
+ source_hash: c77f6f1318c428bbd21725ea5f32f8088506a10cbbf5b5cbca5973c72a5a81f9
source_path: tools/thinking.md
workflow: 15
---
-# Thinking-Level (/think-Direktiven)
+# Denkstufen (/think-Direktiven)
## Was es bewirkt
-- Inline-Direktive in jedem eingehenden Body: `/t `, `/think:` oder `/thinking `.
-- Level (Aliase): `off | minimal | low | medium | high | xhigh | adaptive | max`
- - minimal → „think“
- - low → „think hard“
- - medium → „think harder“
+- Inline-Direktive in jedem eingehenden Text: `/t `, `/think:` oder `/thinking `.
+- Stufen (Aliasse): `off | minimal | low | medium | high | xhigh | adaptive | max`
+ - minimal → „denken“
+ - low → „intensiv denken“
+ - medium → „noch intensiver denken“
- high → „ultrathink“ (maximales Budget)
- - xhigh → „ultrathink+“ (GPT-5.2- und Codex-Modelle sowie Anthropic Claude Opus 4.7 effort)
- - adaptive → vom Provider verwaltetes adaptives Thinking (unterstützt für Claude 4.6 auf Anthropic/Bedrock und Anthropic Claude Opus 4.7)
- - max → maximales Provider-Reasoning (derzeit Anthropic Claude Opus 4.7)
+ - xhigh → „ultrathink+“ (GPT-5.2 + Codex-Modelle und Anthropic Claude Opus 4.7-Aufwand)
+ - adaptive → vom Anbieter verwaltetes adaptives Denken (unterstützt für Claude 4.6 auf Anthropic/Bedrock und Anthropic Claude Opus 4.7)
+ - max → maximales Reasoning des Anbieters (derzeit Anthropic Claude Opus 4.7)
- `x-high`, `x_high`, `extra-high`, `extra high` und `extra_high` werden auf `xhigh` abgebildet.
- `highest` wird auf `high` abgebildet.
-- Hinweise zu Providern:
- - Thinking-Menüs und -Picker sind providerprofilgesteuert. Provider-Plugins deklarieren den genauen Level-Satz für das ausgewählte Modell, einschließlich Labels wie binäres `on`.
- - `adaptive`, `xhigh` und `max` werden nur für Provider-/Modellprofile angezeigt, die sie unterstützen. Eingegebene Direktiven für nicht unterstützte Level werden mit den gültigen Optionen dieses Modells abgelehnt.
- - Bereits gespeicherte, nicht unterstützte Level, einschließlich alter `max`-Werte nach einem Modellwechsel, werden auf das höchste unterstützte Level für das ausgewählte Modell umgebildet.
- - Anthropic-Claude-4.6-Modelle verwenden standardmäßig `adaptive`, wenn kein explizites Thinking-Level gesetzt ist.
- - Anthropic Claude Opus 4.7 verwendet standardmäßig kein adaptives Thinking. Sein standardmäßiger API-effort bleibt providerseitig verwaltet, sofern Sie nicht explizit ein Thinking-Level setzen.
- - Anthropic Claude Opus 4.7 bildet `/think xhigh` auf adaptives Thinking plus `output_config.effort: "xhigh"` ab, weil `/think` eine Thinking-Direktive ist und `xhigh` die Opus-4.7-effort-Einstellung ist.
- - Anthropic Claude Opus 4.7 stellt auch `/think max` bereit; dies wird auf denselben providerseitigen Pfad für maximalen effort abgebildet.
- - OpenAI-GPT-Modelle bilden `/think` über modellabhängige Unterstützung für effort in der Responses API ab. `/think off` sendet `reasoning.effort: "none"` nur dann, wenn das Zielmodell dies unterstützt; andernfalls lässt OpenClaw die deaktivierte Reasoning-Payload weg, statt einen nicht unterstützten Wert zu senden.
- - MiniMax (`minimax/*`) auf dem Anthropic-kompatiblen Streaming-Pfad verwendet standardmäßig `thinking: { type: "disabled" }`, sofern Sie Thinking nicht explizit in Modellparametern oder Request-Parametern setzen. Dies verhindert durchgesickerte `reasoning_content`-Deltas aus dem nicht nativen Anthropic-Stream-Format von MiniMax.
- - Z.AI (`zai/*`) unterstützt nur binäres Thinking (`on`/`off`). Jedes andere Level als `off` wird als `on` behandelt (abgebildet auf `low`).
- - Moonshot (`moonshot/*`) bildet `/think off` auf `thinking: { type: "disabled" }` und jedes andere Level als `off` auf `thinking: { type: "enabled" }` ab. Wenn Thinking aktiviert ist, akzeptiert Moonshot für `tool_choice` nur `auto|none`; OpenClaw normalisiert inkompatible Werte auf `auto`.
+- Hinweise zu Anbietern:
+ - Menüs und Auswahllisten für Denkstufen werden durch Anbieterprofile gesteuert. Provider-Plugins deklarieren die genaue Stufenmenge für das ausgewählte Modell, einschließlich Bezeichnungen wie dem binären `on`.
+ - `adaptive`, `xhigh` und `max` werden nur für Anbieter-/Modellprofile angezeigt, die sie unterstützen. Getippte Direktiven für nicht unterstützte Stufen werden mit den gültigen Optionen dieses Modells zurückgewiesen.
+ - Bereits gespeicherte, nicht unterstützte Stufen werden anhand des Rangs des Anbieterprofils neu zugeordnet. `adaptive` fällt bei nicht adaptiven Modellen auf `medium` zurück, während `xhigh` und `max` auf die größte unterstützte Stufe ungleich `off` für das ausgewählte Modell zurückfallen.
+ - Anthropic Claude 4.6-Modelle verwenden standardmäßig `adaptive`, wenn keine explizite Denkstufe gesetzt ist.
+ - Anthropic Claude Opus 4.7 verwendet adaptives Denken nicht standardmäßig. Der Standardwert für den API-Aufwand bleibt vom Anbieter gesteuert, sofern Sie nicht explizit eine Denkstufe setzen.
+ - Anthropic Claude Opus 4.7 ordnet `/think xhigh` adaptivem Denken plus `output_config.effort: "xhigh"` zu, weil `/think` eine Denk-Direktive ist und `xhigh` die Aufwandseinstellung von Opus 4.7 ist.
+ - Anthropic Claude Opus 4.7 stellt auch `/think max` bereit; es wird auf denselben vom Anbieter gesteuerten Pfad für maximalen Aufwand abgebildet.
+ - OpenAI-GPT-Modelle bilden `/think` über die modellspezifische Unterstützung für Aufwand in der Responses API ab. `/think off` sendet `reasoning.effort: "none"` nur, wenn das Zielmodell dies unterstützt; andernfalls lässt OpenClaw die deaktivierte Reasoning-Nutzlast weg, statt einen nicht unterstützten Wert zu senden.
+ - MiniMax (`minimax/*`) auf dem Anthropic-kompatiblen Streaming-Pfad verwendet standardmäßig `thinking: { type: "disabled" }`, sofern Sie Denken nicht explizit in den Modellparametern oder Anfrageparametern setzen. Dadurch werden durchgesickerte `reasoning_content`-Deltas aus dem nicht nativen Anthropic-Streamformat von MiniMax vermieden.
+ - Z.AI (`zai/*`) unterstützt nur binäres Denken (`on`/`off`). Jede Stufe ungleich `off` wird als `on` behandelt (auf `low` abgebildet).
+ - Moonshot (`moonshot/*`) bildet `/think off` auf `thinking: { type: "disabled" }` und jede Stufe ungleich `off` auf `thinking: { type: "enabled" }` ab. Wenn Denken aktiviert ist, akzeptiert Moonshot für `tool_choice` nur `auto|none`; OpenClaw normalisiert inkompatible Werte auf `auto`.
## Auflösungsreihenfolge
1. Inline-Direktive in der Nachricht (gilt nur für diese Nachricht).
2. Sitzungsüberschreibung (gesetzt durch Senden einer Nachricht, die nur aus einer Direktive besteht).
-3. Standardwert pro Agent (`agents.list[].thinkingDefault` in der Konfiguration).
-4. Globaler Standardwert (`agents.defaults.thinkingDefault` in der Konfiguration).
-5. Fallback: vom Provider deklarierter Standardwert, falls verfügbar, `low` für andere Katalogmodelle mit aktivierter Reasoning-Fähigkeit, sonst `off`.
+3. Standard pro Agent (`agents.list[].thinkingDefault` in der Konfiguration).
+4. Globaler Standard (`agents.defaults.thinkingDefault` in der Konfiguration).
+5. Rückfall: vom Anbieter deklarierter Standard, falls verfügbar, `low` für andere Katalogmodelle mit Reasoning-Fähigkeit, andernfalls `off`.
-## Einen Sitzungsstandard setzen
+## Einen Sitzungsstandard festlegen
- Senden Sie eine Nachricht, die **nur** aus der Direktive besteht (Leerraum erlaubt), z. B. `/think:medium` oder `/t high`.
-- Das bleibt für die aktuelle Sitzung bestehen (standardmäßig pro Absender); zurückgesetzt durch `/think:off` oder Sitzungs-Idle-Reset.
-- Eine Bestätigungsantwort wird gesendet (`Thinking level set to high.` / `Thinking disabled.`). Wenn das Level ungültig ist (z. B. `/thinking big`), wird der Befehl mit einem Hinweis abgelehnt und der Sitzungszustand bleibt unverändert.
-- Senden Sie `/think` (oder `/think:`) ohne Argument, um das aktuelle Thinking-Level anzuzeigen.
+- Das bleibt für die aktuelle Sitzung erhalten (standardmäßig pro Absender); wird durch `/think:off` oder einen Sitzungs-Idle-Reset gelöscht.
+- Eine Bestätigungsantwort wird gesendet (`Thinking level set to high.` / `Thinking disabled.`). Wenn die Stufe ungültig ist (z. B. `/thinking big`), wird der Befehl mit einem Hinweis zurückgewiesen und der Sitzungszustand bleibt unverändert.
+- Senden Sie `/think` (oder `/think:`) ohne Argument, um die aktuelle Denkstufe anzuzeigen.
## Anwendung nach Agent
-- **Eingebettetes Pi**: Das aufgelöste Level wird an die In-Process-Agent-Laufzeit von Pi übergeben.
+- **Embedded Pi**: Die aufgelöste Stufe wird an die In-Process-Laufzeit des Pi-Agenten übergeben.
## Fast-Modus (/fast)
-- Level: `on|off`.
+- Stufen: `on|off`.
- Eine Nachricht, die nur aus einer Direktive besteht, schaltet eine Sitzungsüberschreibung für den Fast-Modus um und antwortet mit `Fast mode enabled.` / `Fast mode disabled.`.
-- Senden Sie `/fast` (oder `/fast status`) ohne Modus, um den aktuell wirksamen Fast-Mode-Status anzuzeigen.
+- Senden Sie `/fast` (oder `/fast status`) ohne Modus, um den aktuell wirksamen Fast-Modus-Status anzuzeigen.
- OpenClaw löst den Fast-Modus in dieser Reihenfolge auf:
- 1. Inline-/Direktive-only-`/fast on|off`
+ 1. Inline-/direktivenbasiert nur `/fast on|off`
2. Sitzungsüberschreibung
- 3. Standardwert pro Agent (`agents.list[].fastModeDefault`)
+ 3. Standard pro Agent (`agents.list[].fastModeDefault`)
4. Konfiguration pro Modell: `agents.defaults.models["/"].params.fastMode`
- 5. Fallback: `off`
-- Für `openai/*` wird der Fast-Modus auf priorisierte OpenAI-Verarbeitung abgebildet, indem bei unterstützten Responses-Requests `service_tier=priority` gesendet wird.
-- Für `openai-codex/*` sendet der Fast-Modus dasselbe Flag `service_tier=priority` bei Codex Responses. OpenClaw verwendet einen gemeinsamen `/fast`-Schalter über beide Auth-Pfade hinweg.
-- Für direkte öffentliche `anthropic/*`-Requests, einschließlich per OAuth authentifiziertem Traffic an `api.anthropic.com`, wird der Fast-Modus auf Anthropic-Service-Tiers abgebildet: `/fast on` setzt `service_tier=auto`, `/fast off` setzt `service_tier=standard_only`.
+ 5. Rückfall: `off`
+- Für `openai/*` wird der Fast-Modus auf priorisierte OpenAI-Verarbeitung abgebildet, indem bei unterstützten Responses-Anfragen `service_tier=priority` gesendet wird.
+- Für `openai-codex/*` sendet der Fast-Modus dasselbe Flag `service_tier=priority` bei Codex-Responses. OpenClaw verwendet einen gemeinsamen Schalter `/fast` über beide Auth-Pfade hinweg.
+- Für direkte öffentliche `anthropic/*`-Anfragen, einschließlich OAuth-authentifiziertem Verkehr an `api.anthropic.com`, wird der Fast-Modus auf Anthropic-Service-Tiers abgebildet: `/fast on` setzt `service_tier=auto`, `/fast off` setzt `service_tier=standard_only`.
- Für `minimax/*` auf dem Anthropic-kompatiblen Pfad schreibt `/fast on` (oder `params.fastMode: true`) `MiniMax-M2.7` in `MiniMax-M2.7-highspeed` um.
-- Explizite Anthropic-Modellparameter `serviceTier` / `service_tier` überschreiben den Standard des Fast-Modus, wenn beide gesetzt sind. OpenClaw überspringt weiterhin die Einfügung von Anthropic-Service-Tiers für nicht-Anthropic-Proxy-`baseUrl`s.
+- Explizite Anthropic-Modellparameter `serviceTier` / `service_tier` überschreiben den Fast-Modus-Standard, wenn beide gesetzt sind. OpenClaw überspringt weiterhin die Einfügung von Anthropic-Service-Tiers für nicht-Anthropic-Proxy-Basis-URLs.
-## Verbose-Direktiven (/verbose oder /v)
+## Direktiven für Ausführlichkeit (/verbose oder /v)
-- Level: `on` (minimal) | `full` | `off` (Standard).
-- Eine Nachricht, die nur aus einer Direktive besteht, schaltet Verbose auf Sitzungsebene um und antwortet mit `Verbose logging enabled.` / `Verbose logging disabled.`; ungültige Level liefern einen Hinweis zurück, ohne den Zustand zu ändern.
-- `/verbose off` speichert eine explizite Sitzungsüberschreibung; löschen Sie sie über die Sessions-UI, indem Sie `inherit` auswählen.
-- Eine Inline-Direktive gilt nur für diese Nachricht; Sitzungs-/globale Standardwerte gelten sonst.
-- Senden Sie `/verbose` (oder `/verbose:`) ohne Argument, um das aktuelle Verbose-Level anzuzeigen.
-- Wenn Verbose aktiviert ist, senden Agenten, die strukturierte Tool-Ergebnisse ausgeben (Pi, andere JSON-Agenten), jeden Tool-Aufruf als eigene Nachricht nur mit Metadaten zurück, sofern verfügbar mit Präfix ` : ` (Pfad/Befehl). Diese Tool-Zusammenfassungen werden gesendet, sobald jedes Tool startet (separate Bubbles), nicht als Streaming-Deltas.
-- Zusammenfassungen von Tool-Fehlern bleiben im normalen Modus sichtbar, aber rohe Detailsuffixe von Fehlern werden ausgeblendet, sofern Verbose nicht `on` oder `full` ist.
-- Wenn Verbose `full` ist, werden Tool-Ausgaben nach Abschluss ebenfalls weitergeleitet (separate Bubble, auf eine sichere Länge gekürzt). Wenn Sie `/verbose on|full|off` während einer laufenden Ausführung umschalten, berücksichtigen nachfolgende Tool-Bubbles die neue Einstellung.
+- Stufen: `on` (minimal) | `full` | `off` (Standard).
+- Eine Nachricht, die nur aus einer Direktive besteht, schaltet die Sitzungsausführlichkeit um und antwortet mit `Verbose logging enabled.` / `Verbose logging disabled.`; ungültige Stufen geben einen Hinweis zurück, ohne den Zustand zu ändern.
+- `/verbose off` speichert eine explizite Sitzungsüberschreibung; löschen Sie sie in der Sitzungen-UI, indem Sie `inherit` wählen.
+- Eine Inline-Direktive wirkt sich nur auf diese Nachricht aus; Sitzungs-/globale Standards gelten sonst.
+- Senden Sie `/verbose` (oder `/verbose:`) ohne Argument, um die aktuelle Ausführlichkeitsstufe anzuzeigen.
+- Wenn die Ausführlichkeit aktiviert ist, senden Agents, die strukturierte Tool-Ergebnisse ausgeben (Pi, andere JSON-Agents), jeden Tool-Aufruf als eigene Nur-Metadaten-Nachricht zurück, sofern verfügbar mit dem Präfix ` : ` (Pfad/Befehl). Diese Tool-Zusammenfassungen werden gesendet, sobald jedes Tool startet (separate Nachrichtenblasen), nicht als Streaming-Deltas.
+- Zusammenfassungen von Tool-Fehlern bleiben im normalen Modus sichtbar, aber rohe Fehlerdetailsuffixe werden ausgeblendet, sofern `verbose` nicht `on` oder `full` ist.
+- Wenn `verbose` auf `full` steht, werden Tool-Ausgaben nach Abschluss ebenfalls weitergeleitet (separate Blase, auf eine sichere Länge gekürzt). Wenn Sie `/verbose on|full|off` während eines laufenden Vorgangs umschalten, beachten nachfolgende Tool-Blasen die neue Einstellung.
## Plugin-Trace-Direktiven (/trace)
-- Level: `on` | `off` (Standard).
-- Eine Nachricht, die nur aus einer Direktive besteht, schaltet die Plugin-Trace-Ausgabe auf Sitzungsebene um und antwortet mit `Plugin trace enabled.` / `Plugin trace disabled.`.
-- Eine Inline-Direktive gilt nur für diese Nachricht; Sitzungs-/globale Standardwerte gelten sonst.
-- Senden Sie `/trace` (oder `/trace:`) ohne Argument, um das aktuelle Trace-Level anzuzeigen.
-- `/trace` ist enger als `/verbose`: Es zeigt nur plugin-eigene Trace-/Debug-Zeilen wie Debug-Zusammenfassungen von Active Memory an.
-- Trace-Zeilen können in `/status` und als nachfolgende Diagnosenachricht nach der normalen Assistant-Antwort erscheinen.
+- Stufen: `on` | `off` (Standard).
+- Eine Nachricht, die nur aus einer Direktive besteht, schaltet die Plugin-Trace-Ausgabe der Sitzung um und antwortet mit `Plugin trace enabled.` / `Plugin trace disabled.`.
+- Eine Inline-Direktive wirkt sich nur auf diese Nachricht aus; Sitzungs-/globale Standards gelten sonst.
+- Senden Sie `/trace` (oder `/trace:`) ohne Argument, um die aktuelle Trace-Stufe anzuzeigen.
+- `/trace` ist enger gefasst als `/verbose`: Es zeigt nur Plugin-eigene Trace-/Debug-Zeilen wie Active Memory-Debugzusammenfassungen an.
+- Trace-Zeilen können in `/status` und als diagnostische Folgemeldung nach der normalen Assistant-Antwort erscheinen.
## Sichtbarkeit von Reasoning (/reasoning)
-- Level: `on|off|stream`.
+- Stufen: `on|off|stream`.
- Eine Nachricht, die nur aus einer Direktive besteht, schaltet um, ob Thinking-Blöcke in Antworten angezeigt werden.
- Wenn aktiviert, wird Reasoning als **separate Nachricht** mit dem Präfix `Reasoning:` gesendet.
-- `stream` (nur Telegram): streamt Reasoning in die Telegram-Entwurfs-Bubble, während die Antwort erzeugt wird, und sendet dann die finale Antwort ohne Reasoning.
+- `stream` (nur Telegram): streamt Reasoning in die Telegram-Entwurfsblase, während die Antwort erzeugt wird, und sendet dann die endgültige Antwort ohne Reasoning.
- Alias: `/reason`.
-- Senden Sie `/reasoning` (oder `/reasoning:`) ohne Argument, um das aktuelle Reasoning-Level anzuzeigen.
-- Auflösungsreihenfolge: Inline-Direktive, dann Sitzungsüberschreibung, dann Standardwert pro Agent (`agents.list[].reasoningDefault`), dann Fallback (`off`).
+- Senden Sie `/reasoning` (oder `/reasoning:`) ohne Argument, um die aktuelle Reasoning-Stufe anzuzeigen.
+- Auflösungsreihenfolge: Inline-Direktive, dann Sitzungsüberschreibung, dann Standard pro Agent (`agents.list[].reasoningDefault`), dann Rückfall (`off`).
## Verwandt
-- Die Dokumentation zum Elevated mode finden Sie unter [Elevated mode](/de/tools/elevated).
+- Die Dokumentation zum Elevated-Modus befindet sich unter [Elevated mode](/de/tools/elevated).
## Heartbeats
-- Der Heartbeat-Probe-Body ist der konfigurierte Heartbeat-Prompt (Standard: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Inline-Direktiven in einer Heartbeat-Nachricht gelten wie üblich (vermeiden Sie aber, Sitzungsstandardwerte über Heartbeats zu ändern).
-- Die Heartbeat-Zustellung verwendet standardmäßig nur die finale Payload. Um zusätzlich die separate `Reasoning:`-Nachricht zu senden (falls verfügbar), setzen Sie `agents.defaults.heartbeat.includeReasoning: true` oder pro Agent `agents.list[].heartbeat.includeReasoning: true`.
+- Der Nachrichtentext für Heartbeat-Probes ist die konfigurierte Heartbeat-Eingabeaufforderung (Standard: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Inline-Direktiven in einer Heartbeat-Nachricht gelten wie üblich (vermeiden Sie es jedoch, Sitzungsstandards durch Heartbeats zu ändern).
+- Die Heartbeat-Zustellung verwendet standardmäßig nur die endgültige Nutzlast. Um zusätzlich die separate Nachricht `Reasoning:` zu senden (falls verfügbar), setzen Sie `agents.defaults.heartbeat.includeReasoning: true` oder pro Agent `agents.list[].heartbeat.includeReasoning: true`.
## Web-Chat-UI
-- Der Thinking-Selektor im Web-Chat spiegelt beim Laden der Seite das gespeicherte Level der Sitzung aus dem eingehenden Sitzungs-Store bzw. der Konfiguration wider.
-- Die Auswahl eines anderen Levels schreibt die Sitzungsüberschreibung sofort über `sessions.patch`; sie wartet nicht auf das nächste Senden und ist keine einmalige `thinkingOnce`-Überschreibung.
-- Die erste Option ist immer `Default ()`, wobei der aufgelöste Standardwert aus dem Thinking-Profil des Providers des aktiven Sitzungsmodells stammt.
-- Der Picker verwendet `thinkingOptions`, die von der Gateway-Sitzungszeile zurückgegeben werden. Die Browser-UI verwaltet keine eigene Regex-Liste für Provider; Plugins besitzen die modellspezifischen Level-Sätze.
-- `/think:` funktioniert weiterhin und aktualisiert dasselbe gespeicherte Sitzungslevel, sodass Chat-Direktiven und der Picker synchron bleiben.
+- Der Thinking-Selektor im Web-Chat spiegelt beim Laden der Seite die gespeicherte Stufe der Sitzung aus dem eingehenden Sitzungsspeicher bzw. der Konfiguration wider.
+- Das Auswählen einer anderen Stufe schreibt die Sitzungsüberschreibung sofort über `sessions.patch`; es wartet nicht auf das nächste Senden und ist keine einmalige Überschreibung `thinkingOnce`.
+- Die erste Option ist immer `Default ()`, wobei der aufgelöste Standard aus dem Thinking-Profil des Anbieters für das aktive Sitzungsmodell stammt.
+- Die Auswahl verwendet `thinkingOptions`, die von der Gateway-Sitzungszeile zurückgegeben werden. Die Browser-UI führt keine eigene Regex-Liste für Anbieter; Plugins besitzen die modellspezifischen Stufenmengen.
+- `/think:` funktioniert weiterhin und aktualisiert dieselbe gespeicherte Sitzungsstufe, sodass Chat-Direktiven und die Auswahl synchron bleiben.
-## Provider-Profile
+## Anbieterprofile
-- Provider-Plugins können `resolveThinkingProfile(ctx)` bereitstellen, um die unterstützten Level und den Standardwert des Modells zu definieren.
-- Jedes Profil-Level hat eine gespeicherte kanonische `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` oder `max`) und kann ein Anzeige-`label` enthalten. Binäre Provider verwenden `{ id: "low", label: "on" }`.
-- Veröffentliche Legacy-Hooks (`supportsXHighThinking`, `isBinaryThinking` und `resolveDefaultThinkingLevel`) bleiben als Kompatibilitätsadapter erhalten, aber neue benutzerdefinierte Level-Sätze sollten `resolveThinkingProfile` verwenden.
-- Gateway-Zeilen stellen `thinkingOptions` und `thinkingDefault` bereit, sodass ACP/Chat-Clients dasselbe Profil rendern, das auch von der Laufzeitvalidierung verwendet wird.
+- Provider-Plugins können `resolveThinkingProfile(ctx)` bereitstellen, um die unterstützten Stufen und den Standard des Modells zu definieren.
+- Jede Profilstufe hat eine gespeicherte kanonische `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` oder `max`) und kann eine Anzeige-`label` enthalten. Binäre Anbieter verwenden `{ id: "low", label: "on" }`.
+- Veröffentlichten Legacy-Hooks (`supportsXHighThinking`, `isBinaryThinking` und `resolveDefaultThinkingLevel`) bleiben als Kompatibilitätsadapter erhalten, aber neue benutzerdefinierte Stufenmengen sollten `resolveThinkingProfile` verwenden.
+- Gateway-Zeilen stellen `thinkingOptions` und `thinkingDefault` bereit, damit ACP-/Chat-Clients dasselbe Profil rendern, das auch die Laufzeitvalidierung verwendet.