From 4bb4460efeb14299e79593ea99135a1212fa366d Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 4 May 2026 07:05:38 +0000 Subject: [PATCH] chore(i18n): refresh de translations --- docs/de/channels/discord.md | 485 ++++++++++++++++++---------------- docs/de/channels/slack.md | 357 +++++++++++++------------ docs/de/channels/telegram.md | 471 ++++++++++++++++++--------------- docs/de/concepts/streaming.md | 205 +++++++------- 4 files changed, 796 insertions(+), 722 deletions(-) diff --git a/docs/de/channels/discord.md b/docs/de/channels/discord.md index 25a558bc1..dc1f09b27 100644 --- a/docs/de/channels/discord.md +++ b/docs/de/channels/discord.md @@ -1,18 +1,18 @@ --- read_when: - - Arbeiten an Discord-Kanalfunktionen + - Arbeiten an Funktionen für Discord-Kanäle summary: Supportstatus, Funktionen und Konfiguration des Discord-Bots title: Discord x-i18n: - generated_at: "2026-05-04T02:21:24Z" + generated_at: "2026-05-04T07:02:52Z" model: gpt-5.5 provider: openai - source_hash: df4e045e39f8977f779fe409abf41dad0d950c92f1230c51ff356343513df812 + source_hash: 1e00f9d9b134296ac1ca52bb4058fc62ea7a95c4d46d9478648b2ecdd448652a source_path: channels/discord.md workflow: 16 --- -Bereit für DMs und Guild-Kanäle über das offizielle Discord-Gateway. +Bereit für Direktnachrichten (DMs) und Guild-Kanäle über den offiziellen Discord-Gateway. @@ -26,7 +26,7 @@ Bereit für DMs und Guild-Kanäle über das offizielle Discord-Gateway. -## Schnelleinrichtung +## Schnelle Einrichtung Sie müssen eine neue Anwendung mit einem Bot erstellen, den Bot zu Ihrem Server hinzufügen und ihn mit OpenClaw koppeln. Wir empfehlen, Ihren Bot zu Ihrem eigenen privaten Server hinzuzufügen. Falls Sie noch keinen haben, [erstellen Sie zuerst einen](https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server) (wählen Sie **Create My Own > For me and my friends**). @@ -34,7 +34,7 @@ Sie müssen eine neue Anwendung mit einem Bot erstellen, den Bot zu Ihrem Server Gehen Sie zum [Discord Developer Portal](https://discord.com/developers/applications) und klicken Sie auf **New Application**. Geben Sie ihr einen Namen wie „OpenClaw“. - Klicken Sie in der Seitenleiste auf **Bot**. Setzen Sie den **Username** auf den Namen, den Sie für Ihren OpenClaw-Agenten verwenden. + Klicken Sie in der Seitenleiste auf **Bot**. Setzen Sie den **Username** auf den Namen, den Sie Ihrem OpenClaw-Agenten geben. @@ -42,7 +42,7 @@ Sie müssen eine neue Anwendung mit einem Bot erstellen, den Bot zu Ihrem Server Scrollen Sie weiterhin auf der Seite **Bot** nach unten zu **Privileged Gateway Intents** und aktivieren Sie: - **Message Content Intent** (erforderlich) - - **Server Members Intent** (empfohlen; erforderlich für Rollen-Allowlists und Namens-zu-ID-Abgleich) + - **Server Members Intent** (empfohlen; erforderlich für Rollen-Allowlists und die Zuordnung von Namen zu IDs) - **Presence Intent** (optional; nur für Präsenzaktualisierungen erforderlich) @@ -51,15 +51,15 @@ Sie müssen eine neue Anwendung mit einem Bot erstellen, den Bot zu Ihrem Server Scrollen Sie auf der Seite **Bot** wieder nach oben und klicken Sie auf **Reset Token**. - Trotz des Namens wird hier Ihr erstes Token generiert – es wird nichts „zurückgesetzt“. + Trotz des Namens wird dadurch Ihr erstes Token erzeugt — es wird nichts „zurückgesetzt“. - Kopieren Sie das Token und speichern Sie es. Dies ist Ihr **Bot Token**, und Sie benötigen es gleich. + Kopieren Sie das Token und speichern Sie es an einem sicheren Ort. Dies ist Ihr **Bot Token**, das Sie gleich benötigen. - - Klicken Sie in der Seitenleiste auf **OAuth2**. Sie generieren eine Einladungs-URL mit den richtigen Berechtigungen, um den Bot zu Ihrem Server hinzuzufügen. + + Klicken Sie in der Seitenleiste auf **OAuth2**. Sie erzeugen eine Einladungs-URL mit den richtigen Berechtigungen, um den Bot zu Ihrem Server hinzuzufügen. Scrollen Sie nach unten zu **OAuth2 URL Generator** und aktivieren Sie: @@ -77,31 +77,31 @@ Sie müssen eine neue Anwendung mit einem Bot erstellen, den Bot zu Ihrem Server - Dateien anhängen - Reaktionen hinzufügen (optional) - Dies ist der Basissatz für normale Textkanäle. Wenn Sie in Discord-Threads posten möchten, einschließlich Workflows für Foren- oder Medienkanäle, die einen Thread erstellen oder fortsetzen, aktivieren Sie zusätzlich **Send Messages in Threads**. - Kopieren Sie die generierte URL unten, fügen Sie sie in Ihren Browser ein, wählen Sie Ihren Server aus und klicken Sie auf **Continue**, um die Verbindung herzustellen. Sie sollten Ihren Bot nun auf dem Discord-Server sehen. + Dies ist der Basissatz für normale Textkanäle. Wenn Sie vorhaben, in Discord-Threads zu posten, einschließlich Forum- oder Medienkanal-Workflows, die einen Thread erstellen oder fortsetzen, aktivieren Sie außerdem **Send Messages in Threads**. + Kopieren Sie unten die erzeugte URL, fügen Sie sie in Ihren Browser ein, wählen Sie Ihren Server aus und klicken Sie auf **Continue**, um die Verbindung herzustellen. Sie sollten Ihren Bot nun im Discord-Server sehen. - - Zurück in der Discord-App müssen Sie den Entwicklermodus aktivieren, damit Sie interne IDs kopieren können. + + Zurück in der Discord-App müssen Sie den Developer Mode aktivieren, damit Sie interne IDs kopieren können. 1. Klicken Sie auf **User Settings** (Zahnradsymbol neben Ihrem Avatar) → **Advanced** → aktivieren Sie **Developer Mode** - 2. Klicken Sie mit der rechten Maustaste auf Ihr **Serversymbol** in der Seitenleiste → **Copy Server ID** + 2. Klicken Sie in der Seitenleiste mit der rechten Maustaste auf Ihr **Server-Symbol** → **Copy Server ID** 3. Klicken Sie mit der rechten Maustaste auf Ihren **eigenen Avatar** → **Copy User ID** - Speichern Sie Ihre **Server ID** und **User ID** zusammen mit Ihrem Bot Token – Sie senden alle drei im nächsten Schritt an OpenClaw. + Speichern Sie Ihre **Server ID** und **User ID** zusammen mit Ihrem Bot Token — Sie senden alle drei im nächsten Schritt an OpenClaw. - - Damit die Kopplung funktioniert, muss Discord Ihrem Bot erlauben, Ihnen eine DM zu senden. Klicken Sie mit der rechten Maustaste auf Ihr **Serversymbol** → **Privacy Settings** → aktivieren Sie **Direct Messages**. + + Damit die Kopplung funktioniert, muss Discord Ihrem Bot erlauben, Ihnen eine DM zu senden. Klicken Sie mit der rechten Maustaste auf Ihr **Server-Symbol** → **Privacy Settings** → aktivieren Sie **Direct Messages**. Dadurch können Servermitglieder (einschließlich Bots) Ihnen DMs senden. Lassen Sie dies aktiviert, wenn Sie Discord-DMs mit OpenClaw verwenden möchten. Wenn Sie nur Guild-Kanäle verwenden möchten, können Sie DMs nach der Kopplung deaktivieren. - Ihr Discord-Bot-Token ist ein Geheimnis (wie ein Passwort). Setzen Sie es auf dem Rechner, auf dem OpenClaw läuft, bevor Sie Ihrem Agenten eine Nachricht senden. + Ihr Discord-Bot-Token ist ein Geheimnis (wie ein Passwort). Setzen Sie es auf dem Rechner, auf dem OpenClaw läuft, bevor Sie Ihrem Agenten schreiben. ```bash export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN" @@ -120,8 +120,8 @@ openclaw config patch --file ./discord.patch.json5 openclaw gateway ``` - Wenn OpenClaw bereits als Hintergrunddienst läuft, starten Sie es über die OpenClaw-Mac-App neu oder indem Sie den Prozess `openclaw gateway run` stoppen und neu starten. - Führen Sie bei verwalteten Dienstinstallationen `openclaw gateway install` aus einer Shell aus, in der `DISCORD_BOT_TOKEN` vorhanden ist, oder speichern Sie die Variable in `~/.openclaw/.env`, damit der Dienst den env SecretRef nach dem Neustart auflösen kann. + Wenn OpenClaw bereits als Hintergrunddienst läuft, starten Sie es über die OpenClaw-Mac-App neu oder beenden und starten Sie den Prozess `openclaw gateway run` erneut. + Führen Sie bei verwalteten Dienstinstallationen `openclaw gateway install` aus einer Shell aus, in der `DISCORD_BOT_TOKEN` vorhanden ist, oder speichern Sie die Variable in `~/.openclaw/.env`, damit der Dienst die Env-SecretRef nach dem Neustart auflösen kann. Wenn Ihr Host durch Discords Anwendungsabfrage beim Start blockiert oder rate-limitiert wird, setzen Sie die Discord-Anwendungs-/Client-ID aus dem Developer Portal, damit der Start diesen REST-Aufruf überspringen kann. Verwenden Sie `channels.discord.applicationId` für das Standardkonto oder `channels.discord.accounts..applicationId`, wenn Sie mehrere Discord-Bots betreiben. @@ -129,10 +129,10 @@ openclaw gateway - - Chatten Sie mit Ihrem OpenClaw-Agenten in einem beliebigen vorhandenen Kanal (z. B. Telegram) und teilen Sie es ihm mit. Wenn Discord Ihr erster Kanal ist, verwenden Sie stattdessen den Tab CLI / Konfiguration. + + Chatten Sie mit Ihrem OpenClaw-Agenten in einem bestehenden Kanal (z. B. Telegram) und teilen Sie es ihm mit. Wenn Discord Ihr erster Kanal ist, verwenden Sie stattdessen den Tab CLI / Konfiguration. - > „Ich habe mein Discord-Bot-Token bereits in der Konfiguration gesetzt. Bitte schließe die Discord-Einrichtung mit User ID `` und Server ID `` ab.“ + > „Ich habe mein Discord-Bot-Token bereits in der Konfiguration gesetzt. Bitte schließen Sie die Discord-Einrichtung mit User ID `` und Server ID `` ab.“ Wenn Sie dateibasierte Konfiguration bevorzugen, setzen Sie: @@ -158,9 +158,9 @@ openclaw gateway DISCORD_BOT_TOKEN=... ``` - Für skriptgesteuerte oder Remote-Einrichtung schreiben Sie denselben JSON5-Block mit `openclaw config patch --file ./discord.patch.json5 --dry-run` und führen ihn anschließend erneut ohne `--dry-run` aus. Klartextwerte für `token` werden unterstützt. SecretRef-Werte werden ebenfalls für `channels.discord.token` über env-/file-/exec-Provider unterstützt. Siehe [Secrets Management](/de/gateway/secrets). + Schreiben Sie für skriptgesteuerte oder Remote-Einrichtung denselben JSON5-Block mit `openclaw config patch --file ./discord.patch.json5 --dry-run` und führen Sie ihn anschließend erneut ohne `--dry-run` aus. Klartextwerte für `token` werden unterstützt. SecretRef-Werte werden ebenfalls für `channels.discord.token` über Env-/Datei-/Exec-Provider hinweg unterstützt. Siehe [Geheimnisverwaltung](/de/gateway/secrets). - Für mehrere Discord-Bots halten Sie jedes Bot-Token und jede Anwendungs-ID unter dem jeweiligen Konto. Ein `channels.discord.applicationId` auf oberster Ebene wird von Konten geerbt. Setzen Sie ihn dort daher nur, wenn jedes Konto dieselbe Anwendungs-ID verwenden soll. + Bei mehreren Discord-Bots speichern Sie jedes Bot-Token und jede Anwendungs-ID unter dem jeweiligen Konto. Ein `channels.discord.applicationId` auf oberster Ebene wird von Konten geerbt; setzen Sie es dort also nur, wenn jedes Konto dieselbe Anwendungs-ID verwenden soll. ```json5 { @@ -188,13 +188,13 @@ DISCORD_BOT_TOKEN=... - Warten Sie, bis das Gateway läuft, und senden Sie Ihrem Bot dann in Discord eine DM. Er antwortet mit einem Kopplungscode. + Warten Sie, bis der Gateway läuft, und senden Sie Ihrem Bot dann in Discord eine DM. Er antwortet mit einem Kopplungscode. - - Senden Sie den Kopplungscode über Ihren vorhandenen Kanal an Ihren Agenten: + + Senden Sie den Kopplungscode in Ihrem bestehenden Kanal an Ihren Agenten: - > „Genehmige diesen Discord-Kopplungscode: ``“ + > „Genehmigen Sie diesen Discord-Kopplungscode: ``“ @@ -214,22 +214,22 @@ openclaw pairing approve discord -Die Token-Auflösung ist kontobewusst. Konfigurationswerte für Token haben Vorrang vor dem env-Fallback. `DISCORD_BOT_TOKEN` wird nur für das Standardkonto verwendet. -Wenn zwei aktivierte Discord-Konten dasselbe Bot-Token auflösen, startet OpenClaw nur einen Gateway-Monitor für dieses Token. Ein aus der Konfiguration stammendes Token hat Vorrang vor dem Standard-env-Fallback; andernfalls gewinnt das erste aktivierte Konto und das doppelte Konto wird als deaktiviert gemeldet. -Für erweiterte ausgehende Aufrufe (Nachrichten-Tool/Kanalaktionen) wird ein explizites `token` pro Aufruf für diesen Aufruf verwendet. Dies gilt für Aktionen im Stil von Senden und Lesen/Probe (zum Beispiel read/search/fetch/thread/pins/permissions). Kontorichtlinien und Wiederholungseinstellungen stammen weiterhin aus dem ausgewählten Konto im aktiven Runtime-Snapshot. +Die Token-Auflösung ist kontobewusst. Konfigurierte Token-Werte haben Vorrang vor Env-Fallbacks. `DISCORD_BOT_TOKEN` wird nur für das Standardkonto verwendet. +Wenn zwei aktivierte Discord-Konten auf dasselbe Bot-Token auflösen, startet OpenClaw nur einen Gateway-Monitor für dieses Token. Ein aus der Konfiguration stammendes Token hat Vorrang vor dem Standard-Env-Fallback; andernfalls gewinnt das erste aktivierte Konto, und das doppelte Konto wird als deaktiviert gemeldet. +Bei erweiterten ausgehenden Aufrufen (Nachrichten-Tool/Kanalaktionen) wird ein explizites `token` pro Aufruf für diesen Aufruf verwendet. Dies gilt für Aktionen im Stil von Senden und Lesen/Prüfen (zum Beispiel Lesen/Suchen/Abrufen/Thread/Pins/Berechtigungen). Kontorichtlinien und Wiederholungseinstellungen stammen weiterhin aus dem ausgewählten Konto im aktiven Laufzeit-Snapshot. -## Empfohlen: Einen Guild-Arbeitsbereich einrichten +## Empfohlen: Guild-Arbeitsbereich einrichten -Sobald DMs funktionieren, können Sie Ihren Discord-Server als vollständigen Arbeitsbereich einrichten, in dem jeder Kanal seine eigene Agentensitzung mit eigenem Kontext erhält. Dies wird für private Server empfohlen, auf denen nur Sie und Ihr Bot sind. +Sobald DMs funktionieren, können Sie Ihren Discord-Server als vollständigen Arbeitsbereich einrichten, in dem jeder Kanal eine eigene Agentensitzung mit eigenem Kontext erhält. Dies wird für private Server empfohlen, auf denen nur Sie und Ihr Bot aktiv sind. - + Dadurch kann Ihr Agent in jedem Kanal auf Ihrem Server antworten, nicht nur in DMs. - - > „Füge meine Discord Server ID `` zur Guild-Allowlist hinzu“ + + > „Fügen Sie meine Discord Server ID `` zur Guild-Allowlist hinzu“ @@ -254,16 +254,16 @@ Sobald DMs funktionieren, können Sie Ihren Discord-Server als vollständigen Ar - - Standardmäßig antwortet Ihr Agent in Guild-Kanälen nur, wenn er per @Mention erwähnt wird. Für einen privaten Server möchten Sie wahrscheinlich, dass er auf jede Nachricht antwortet. + + Standardmäßig antwortet Ihr Agent in Guild-Kanälen nur, wenn er @erwähnt wird. Für einen privaten Server möchten Sie wahrscheinlich, dass er auf jede Nachricht reagiert. - In Guild-Kanälen bleiben normale abschließende Assistentenantworten standardmäßig privat. Sichtbare Discord-Ausgabe muss explizit mit dem `message`-Tool gesendet werden, sodass der Agent standardmäßig mitlesen und nur posten kann, wenn er entscheidet, dass eine Kanalantwort nützlich ist. + In Guild-Kanälen bleiben normale finale Assistant-Antworten standardmäßig privat. Sichtbare Discord-Ausgaben müssen explizit mit dem Tool `message` gesendet werden, sodass der Agent standardmäßig mitlesen und nur posten kann, wenn er entscheidet, dass eine Kanalantwort sinnvoll ist. - Das bedeutet, dass das ausgewählte Modell zuverlässig Tools aufrufen muss. Wenn Discord „Tippt ...“ anzeigt und die Logs Token-Nutzung zeigen, aber keine Nachricht gepostet wird, prüfen Sie das Sitzungslog auf Assistententext mit `didSendViaMessagingTool: false`. Das bedeutet, dass das Modell eine private abschließende Antwort erzeugt hat, anstatt `message(action=send)` aufzurufen. Wechseln Sie zu einem stärkeren Tool-Calling-Modell oder verwenden Sie die folgende Konfiguration, um die alten automatischen abschließenden Antworten wiederherzustellen. + Das bedeutet, dass das ausgewählte Modell zuverlässig Tools aufrufen muss. Wenn Discord Tippen anzeigt und die Logs Token-Nutzung zeigen, aber keine Nachricht gepostet wird, prüfen Sie das Sitzungslog auf Assistant-Text mit `didSendViaMessagingTool: false`. Das bedeutet, dass das Modell eine private finale Antwort erzeugt hat, statt `message(action=send)` aufzurufen. Wechseln Sie zu einem stärkeren Tool-Calling-Modell oder verwenden Sie die folgende Konfiguration, um ältere automatische finale Antworten wiederherzustellen. - - > „Erlaube meinem Agenten, auf diesem Server zu antworten, ohne @mentioned werden zu müssen“ + + > „Erlauben Sie meinem Agenten, auf diesem Server zu antworten, ohne @erwähnt werden zu müssen“ Setzen Sie `requireMention: false` in Ihrer Guild-Konfiguration: @@ -282,54 +282,54 @@ Sobald DMs funktionieren, können Sie Ihren Discord-Server als vollständigen Ar } ``` - Um alte automatische abschließende Antworten für Gruppen-/Kanalräume wiederherzustellen, setzen Sie `messages.groupChat.visibleReplies: "automatic"`. + Um ältere automatische finale Antworten für Gruppen-/Kanalräume wiederherzustellen, setzen Sie `messages.groupChat.visibleReplies: "automatic"`. - + Standardmäßig wird Langzeitspeicher (MEMORY.md) nur in DM-Sitzungen geladen. Guild-Kanäle laden MEMORY.md nicht automatisch. - - > „Wenn ich Fragen in Discord-Kanälen stelle, verwende memory_search oder memory_get, falls du Langzeitkontext aus MEMORY.md benötigst.“ + + > „Wenn ich in Discord-Kanälen Fragen stelle, verwenden Sie memory_search oder memory_get, wenn Sie Langzeitkontext aus MEMORY.md benötigen.“ - Wenn Sie gemeinsamen Kontext in jedem Kanal benötigen, legen Sie die stabilen Anweisungen in `AGENTS.md` oder `USER.md` ab (sie werden für jede Sitzung injiziert). Bewahren Sie Langzeitnotizen in `MEMORY.md` auf und greifen Sie bei Bedarf mit Speicher-Tools darauf zu. + Wenn Sie geteilten Kontext in jedem Kanal benötigen, legen Sie die stabilen Anweisungen in `AGENTS.md` oder `USER.md` ab (sie werden in jede Sitzung injiziert). Bewahren Sie Langzeitnotizen in `MEMORY.md` auf und greifen Sie bei Bedarf mit Speicher-Tools darauf zu. -Erstellen Sie nun einige Kanäle auf Ihrem Discord-Server und beginnen Sie zu chatten. Ihr Agent kann den Kanalnamen sehen, und jeder Kanal erhält seine eigene isolierte Sitzung – sodass Sie `#coding`, `#home`, `#research` oder etwas anderes einrichten können, das zu Ihrem Workflow passt. +Erstellen Sie nun einige Kanäle auf Ihrem Discord-Server und beginnen Sie zu chatten. Ihr Agent kann den Kanalnamen sehen, und jeder Kanal erhält seine eigene isolierte Sitzung — Sie können also `#coding`, `#home`, `#research` oder alles einrichten, was zu Ihrem Workflow passt. ## Laufzeitmodell -- Gateway besitzt die Discord-Verbindung. -- Die Antwortweiterleitung ist deterministisch: Eingehende Discord-Antworten gehen zurück an Discord. +- Der Gateway verwaltet die Discord-Verbindung. +- Antwort-Routing ist deterministisch: Eingehende Discord-Antworten werden zurück an Discord geleitet. - Discord-Guild-/Kanal-Metadaten werden dem Modell-Prompt als nicht vertrauenswürdiger - Kontext hinzugefügt, nicht als für Benutzer sichtbares Antwortpräfix. Wenn ein Modell diese Hülle - zurückkopiert, entfernt OpenClaw die kopierten Metadaten aus ausgehenden Antworten und aus - zukünftigem Wiedergabekontext. + Kontext hinzugefügt, nicht als für Benutzer sichtbares Antwortpräfix. Wenn ein Modell diesen Umschlag + zurückkopiert, entfernt OpenClaw die kopierten Metadaten aus ausgehenden Antworten und aus dem + künftigen Replay-Kontext. - Standardmäßig (`session.dmScope=main`) teilen direkte Chats die Hauptsitzung des Agenten (`agent:main:main`). - Guild-Kanäle sind isolierte Sitzungsschlüssel (`agent::discord:channel:`). - Gruppen-DMs werden standardmäßig ignoriert (`channels.discord.dm.groupEnabled=false`). -- Native Slash-Befehle laufen in isolierten Befehlssitzungen (`agent::discord:slash:`), tragen dabei aber weiterhin `CommandTargetSessionKey` zur weitergeleiteten Unterhaltungssitzung. -- Die Zustellung von reinen Text-Cron-/Heartbeat-Ankündigungen an Discord verwendet die finale - für den Assistenten sichtbare Antwort genau einmal. Medien und strukturierte Komponenten-Payloads bleiben - Mehrfachnachrichten, wenn der Agent mehrere zustellbare Payloads ausgibt. +- Native Slash-Befehle laufen in isolierten Befehlssitzungen (`agent::discord:slash:`), während sie weiterhin `CommandTargetSessionKey` zur gerouteten Unterhaltungssitzung mitführen. +- Die reine Text-Auslieferung von Cron-/Heartbeat-Ankündigungen an Discord verwendet die finale, + für den Assistenten sichtbare Antwort einmal. Medien und strukturierte Komponenten-Payloads bleiben + mehrteilig, wenn der Agent mehrere auslieferbare Payloads ausgibt. ## Forum-Kanäle Discord-Forum- und Medienkanäle akzeptieren nur Thread-Beiträge. OpenClaw unterstützt zwei Möglichkeiten, sie zu erstellen: -- Senden Sie eine Nachricht an das übergeordnete Forum (`channel:`), um automatisch einen Thread zu erstellen. Der Thread-Titel verwendet die erste nicht leere Zeile Ihrer Nachricht. +- Senden Sie eine Nachricht an den Forum-Parent (`channel:`), um automatisch einen Thread zu erstellen. Der Thread-Titel verwendet die erste nicht leere Zeile Ihrer Nachricht. - Verwenden Sie `openclaw message thread create`, um direkt einen Thread zu erstellen. Übergeben Sie für Forum-Kanäle nicht `--message-id`. -Beispiel: An das übergeordnete Forum senden, um einen Thread zu erstellen +Beispiel: An Forum-Parent senden, um einen Thread zu erstellen ```bash openclaw message send --channel discord --target channel: \ @@ -343,11 +343,11 @@ openclaw message thread create --channel discord --target channel: \ --thread-name "Topic title" --message "Body of the post" ``` -Übergeordnete Foren akzeptieren keine Discord-Komponenten. Wenn Sie Komponenten benötigen, senden Sie an den Thread selbst (`channel:`). +Forum-Parents akzeptieren keine Discord-Komponenten. Wenn Sie Komponenten benötigen, senden Sie an den Thread selbst (`channel:`). ## Interaktive Komponenten -OpenClaw unterstützt Discord-Komponenten-v2-Container für Agentennachrichten. Verwenden Sie das Nachrichten-Tool mit einem `components`-Payload. Interaktionsergebnisse werden als normale eingehende Nachrichten zurück an den Agenten geleitet und folgen den vorhandenen Discord-`replyToMode`-Einstellungen. +OpenClaw unterstützt Discord-Komponenten-v2-Container für Agenten-Nachrichten. Verwenden Sie das Nachrichten-Tool mit einer `components`-Payload. Interaktionsergebnisse werden als normale eingehende Nachrichten zurück an den Agenten geleitet und folgen den bestehenden Discord-`replyToMode`-Einstellungen. Unterstützte Blöcke: @@ -355,23 +355,23 @@ Unterstützte Blöcke: - Aktionszeilen erlauben bis zu 5 Schaltflächen oder ein einzelnes Auswahlmenü - Auswahltypen: `string`, `user`, `role`, `mentionable`, `channel` -Standardmäßig können Komponenten nur einmal verwendet werden. Setzen Sie `components.reusable=true`, damit Schaltflächen, Auswahllisten und Formulare bis zu ihrem Ablauf mehrfach verwendet werden können. +Standardmäßig sind Komponenten nur einmal verwendbar. Setzen Sie `components.reusable=true`, damit Schaltflächen, Auswahlen und Formulare bis zu ihrem Ablauf mehrfach verwendet werden können. -Um einzuschränken, wer auf eine Schaltfläche klicken kann, setzen Sie `allowedUsers` auf dieser Schaltfläche (Discord-Benutzer-IDs, Tags oder `*`). Bei entsprechender Konfiguration erhalten nicht passende Benutzer eine ephemere Ablehnung. +Um einzuschränken, wer auf eine Schaltfläche klicken kann, setzen Sie `allowedUsers` für diese Schaltfläche (Discord-Benutzer-IDs, Tags oder `*`). Wenn dies konfiguriert ist, erhalten nicht passende Benutzer eine flüchtige Ablehnung. -Die Slash-Befehle `/model` und `/models` öffnen eine interaktive Modellauswahl mit Provider-, Modell- und kompatiblen Runtime-Dropdowns plus einem Absenden-Schritt. `/models add` ist veraltet und gibt jetzt eine Veraltungsmeldung zurück, statt Modelle aus dem Chat zu registrieren. Die Picker-Antwort ist ephemer, und nur der aufrufende Benutzer kann sie verwenden. +Die Slash-Befehle `/model` und `/models` öffnen eine interaktive Modellauswahl mit Dropdowns für Provider, Modell und kompatible Laufzeit sowie einem Absenden-Schritt. `/models add` ist veraltet und gibt jetzt eine Veraltungsmeldung zurück, statt Modelle aus dem Chat zu registrieren. Die Auswahlantwort ist flüchtig, und nur der aufrufende Benutzer kann sie verwenden. Dateianhänge: - `file`-Blöcke müssen auf eine Anhangsreferenz verweisen (`attachment://`) - Stellen Sie den Anhang über `media`/`path`/`filePath` bereit (einzelne Datei); verwenden Sie `media-gallery` für mehrere Dateien -- Verwenden Sie `filename`, um den Upload-Namen zu überschreiben, wenn er zur Anhangsreferenz passen soll +- Verwenden Sie `filename`, um den Upload-Namen zu überschreiben, wenn er mit der Anhangsreferenz übereinstimmen soll Modale Formulare: - Fügen Sie `components.modal` mit bis zu 5 Feldern hinzu - Feldtypen: `text`, `checkbox`, `radio`, `select`, `role-select`, `user-select` -- OpenClaw fügt automatisch eine Auslöse-Schaltfläche hinzu +- OpenClaw fügt automatisch eine Auslöseschaltfläche hinzu Beispiel: @@ -427,10 +427,10 @@ Beispiel: } ``` -## Zugriffskontrolle und Weiterleitung +## Zugriffskontrolle und Routing - + `channels.discord.dmPolicy` steuert den DM-Zugriff. `channels.discord.allowFrom` ist die kanonische DM-Allowlist. - `pairing` (Standard) @@ -438,30 +438,30 @@ Beispiel: - `open` (erfordert, dass `channels.discord.allowFrom` `"*"` enthält) - `disabled` - Wenn die DM-Richtlinie nicht offen ist, werden unbekannte Benutzer blockiert (oder im Modus `pairing` zur Kopplung aufgefordert). + Wenn die DM-Richtlinie nicht offen ist, werden unbekannte Benutzer blockiert (oder im Modus `pairing` zum Pairing aufgefordert). Vorrang bei mehreren Konten: - `channels.discord.accounts.default.allowFrom` gilt nur für das Konto `default`. - - Bei einem Konto hat `allowFrom` Vorrang vor dem veralteten `dm.allowFrom`. - - Benannte Konten erben `channels.discord.allowFrom`, wenn ihr eigenes `allowFrom` und das veraltete `dm.allowFrom` nicht gesetzt sind. - - Benannte Konten erben `channels.discord.accounts.default.allowFrom` nicht. + - Bei einem Konto hat `allowFrom` Vorrang vor dem alten `dm.allowFrom`. + - Benannte Konten erben `channels.discord.allowFrom`, wenn ihr eigenes `allowFrom` und das alte `dm.allowFrom` nicht gesetzt sind. + - Benannte Konten erben nicht `channels.discord.accounts.default.allowFrom`. - Das veraltete `channels.discord.dm.policy` und `channels.discord.dm.allowFrom` werden aus Kompatibilitätsgründen weiterhin gelesen. `openclaw doctor --fix` migriert sie zu `dmPolicy` und `allowFrom`, wenn dies ohne Änderung des Zugriffs möglich ist. + Die alten Optionen `channels.discord.dm.policy` und `channels.discord.dm.allowFrom` werden aus Kompatibilitätsgründen weiterhin gelesen. `openclaw doctor --fix` migriert sie zu `dmPolicy` und `allowFrom`, wenn dies ohne Änderung des Zugriffs möglich ist. - DM-Zielformat für die Zustellung: + DM-Zielformat für die Auslieferung: - `user:` - `<@id>`-Erwähnung - Reine numerische IDs werden normalerweise als Kanal-IDs aufgelöst, wenn ein Kanalstandard aktiv ist, aber IDs, die im effektiven DM-`allowFrom` des Kontos aufgeführt sind, werden aus Kompatibilitätsgründen als Benutzer-DM-Ziele behandelt. + Bloße numerische IDs werden normalerweise als Kanal-IDs aufgelöst, wenn ein Kanalstandard aktiv ist, aber IDs, die in der effektiven DM-`allowFrom` des Kontos aufgeführt sind, werden aus Kompatibilitätsgründen als Benutzer-DM-Ziele behandelt. - + Discord-DMs können dynamische `accessGroup:`-Einträge in `channels.discord.allowFrom` verwenden. - Zugriffgruppennamen werden kanalübergreifend für Nachrichten geteilt. Verwenden Sie `type: "message.senders"` für eine statische Gruppe, deren Mitglieder in der normalen `allowFrom`-Syntax des jeweiligen Kanals ausgedrückt werden, oder `type: "discord.channelAudience"`, wenn die aktuelle `ViewChannel`-Zielgruppe eines Discord-Kanals die Mitgliedschaft dynamisch definieren soll. Das gemeinsame Verhalten von Zugriffsgruppen ist hier dokumentiert: [Zugriffsgruppen](/de/channels/access-groups). + Zugriffsgruppennamen werden über Nachrichtenkanäle hinweg geteilt. Verwenden Sie `type: "message.senders"` für eine statische Gruppe, deren Mitglieder in der normalen `allowFrom`-Syntax des jeweiligen Kanals ausgedrückt werden, oder `type: "discord.channelAudience"`, wenn die aktuelle `ViewChannel`-Zielgruppe eines Discord-Kanals die Mitgliedschaft dynamisch definieren soll. Das gemeinsame Verhalten von Zugriffsgruppen ist hier dokumentiert: [Zugriffsgruppen](/de/channels/access-groups). ```json5 { @@ -484,9 +484,9 @@ Beispiel: } ``` - Ein Discord-Textkanal hat keine separate Mitgliederliste. `type: "discord.channelAudience"` modelliert die Mitgliedschaft so: Der DM-Absender ist Mitglied der konfigurierten Guild und hat derzeit nach Anwendung von Rollen- und Kanalüberschreibungen die effektive Berechtigung `ViewChannel` für den konfigurierten Kanal. + Ein Discord-Textkanal hat keine separate Mitgliederliste. `type: "discord.channelAudience"` modelliert Mitgliedschaft so: Der DM-Absender ist Mitglied der konfigurierten Guild und hat derzeit effektive `ViewChannel`-Berechtigung für den konfigurierten Kanal, nachdem Rollen- und Kanalüberschreibungen angewendet wurden. - Beispiel: Allen Personen, die `#maintainers` sehen können, erlauben, dem Bot eine DM zu senden, während DMs für alle anderen geschlossen bleiben. + Beispiel: Allen, die `#maintainers` sehen können, erlauben, dem Bot eine DM zu senden, während DMs für alle anderen geschlossen bleiben. ```json5 { @@ -527,29 +527,29 @@ Beispiel: } ``` - Abfragen schlagen geschlossen fehl. Wenn Discord `Missing Access` zurückgibt, die Mitgliedsabfrage fehlschlägt oder der Kanal zu einer anderen Guild gehört, wird der DM-Absender als nicht autorisiert behandelt. + Nachschlagen schlägt geschlossen fehl. Wenn Discord `Missing Access` zurückgibt, die Mitgliedersuche fehlschlägt oder der Kanal zu einer anderen Guild gehört, wird der DM-Absender als nicht autorisiert behandelt. - Aktivieren Sie im Discord Developer Portal die **Server Members Intent** für den Bot, wenn Sie zugriffsgruppen mit Kanalzielgruppen verwenden. DMs enthalten keinen Guild-Mitgliedsstatus, daher löst OpenClaw das Mitglied zum Autorisierungszeitpunkt über Discord REST auf. + Aktivieren Sie im Discord Developer Portal **Server Members Intent** für den Bot, wenn Sie kanalzielgruppenbasierte Zugriffsgruppen verwenden. DMs enthalten keinen Guild-Mitgliedsstatus, daher löst OpenClaw das Mitglied zur Autorisierungszeit über Discord REST auf. - + Die Guild-Behandlung wird durch `channels.discord.groupPolicy` gesteuert: - `open` - `allowlist` - `disabled` - Die sichere Basislinie, wenn `channels.discord` existiert, ist `allowlist`. + Die sichere Basislinie, wenn `channels.discord` vorhanden ist, ist `allowlist`. `allowlist`-Verhalten: - - Die Guild muss mit `channels.discord.guilds` übereinstimmen (`id` bevorzugt, Slug akzeptiert) - - optionale Absender-Allowlisten: `users` (stabile IDs empfohlen) und `roles` (nur Rollen-IDs); wenn eine davon konfiguriert ist, sind Absender erlaubt, wenn sie mit `users` ODER `roles` übereinstimmen - - direkter Namens-/Tag-Abgleich ist standardmäßig deaktiviert; aktivieren Sie `channels.discord.dangerouslyAllowNameMatching: true` nur als Break-Glass-Kompatibilitätsmodus + - Guild muss mit `channels.discord.guilds` übereinstimmen (`id` bevorzugt, Slug akzeptiert) + - optionale Absender-Allowlists: `users` (stabile IDs empfohlen) und `roles` (nur Rollen-IDs); wenn eine davon konfiguriert ist, sind Absender erlaubt, wenn sie mit `users` ODER `roles` übereinstimmen + - direkte Namens-/Tag-Übereinstimmung ist standardmäßig deaktiviert; aktivieren Sie `channels.discord.dangerouslyAllowNameMatching: true` nur als Break-Glass-Kompatibilitätsmodus - Namen/Tags werden für `users` unterstützt, aber IDs sind sicherer; `openclaw security audit` warnt, wenn Namens-/Tag-Einträge verwendet werden - - Wenn für eine Guild `channels` konfiguriert ist, werden nicht aufgeführte Kanäle abgelehnt - - Wenn eine Guild keinen `channels`-Block hat, sind alle Kanäle in dieser allowgelisteten Guild erlaubt + - wenn für eine Guild `channels` konfiguriert ist, werden nicht aufgeführte Kanäle abgelehnt + - wenn eine Guild keinen `channels`-Block hat, sind alle Kanäle in dieser in der Allowlist enthaltenen Guild erlaubt Beispiel: @@ -575,20 +575,20 @@ Beispiel: } ``` - Wenn Sie nur `DISCORD_BOT_TOKEN` setzen und keinen `channels.discord`-Block erstellen, ist der Runtime-Fallback `groupPolicy="allowlist"` (mit einer Warnung in den Logs), selbst wenn `channels.defaults.groupPolicy` `open` ist. + Wenn Sie nur `DISCORD_BOT_TOKEN` setzen und keinen `channels.discord`-Block erstellen, ist der Laufzeit-Fallback `groupPolicy="allowlist"` (mit einer Warnung in den Logs), selbst wenn `channels.defaults.groupPolicy` `open` ist. - - Guild-Nachrichten sind standardmäßig erwähnungsgesteuert. + + Guild-Nachrichten erfordern standardmäßig eine Erwähnung. - Die Erwähnungserkennung umfasst: + Die Erkennung von Erwähnungen umfasst: - explizite Bot-Erwähnung - konfigurierte Erwähnungsmuster (`agents.list[].groupChat.mentionPatterns`, Fallback `messages.groupChat.mentionPatterns`) - implizites Antwort-an-Bot-Verhalten in unterstützten Fällen - Verwenden Sie beim Schreiben ausgehender Discord-Nachrichten die kanonische Erwähnungssyntax: `<@USER_ID>` für Benutzer, `<#CHANNEL_ID>` für Kanäle und `<@&ROLE_ID>` für Rollen. Verwenden Sie nicht die veraltete Nickname-Erwähnungsform `<@!USER_ID>`. + Verwenden Sie beim Schreiben ausgehender Discord-Nachrichten die kanonische Erwähnungssyntax: `<@USER_ID>` für Benutzer, `<#CHANNEL_ID>` für Kanäle und `<@&ROLE_ID>` für Rollen. Verwenden Sie nicht die alte Nickname-Erwähnungsform `<@!USER_ID>`. `requireMention` wird pro Guild/Kanal konfiguriert (`channels.discord.guilds...`). `ignoreOtherMentions` verwirft optional Nachrichten, die einen anderen Benutzer/eine andere Rolle erwähnen, aber nicht den Bot (ausgenommen @everyone/@here). @@ -601,9 +601,9 @@ Beispiel: -### Rollenbasierte Agentenweiterleitung +### Rollenbasiertes Agenten-Routing -Verwenden Sie `bindings[].match.roles`, um Discord-Guild-Mitglieder nach Rollen-ID an verschiedene Agenten weiterzuleiten. Rollenbasierte Bindings akzeptieren nur Rollen-IDs und werden nach Peer- oder Parent-Peer-Bindings und vor reinen Guild-Bindings ausgewertet. Wenn ein Binding auch andere Abgleichsfelder setzt (zum Beispiel `peer` + `guildId` + `roles`), müssen alle konfigurierten Felder übereinstimmen. +Verwenden Sie `bindings[].match.roles`, um Discord-Guild-Mitglieder anhand der Rollen-ID an verschiedene Agenten zu leiten. Rollenbasierte Bindings akzeptieren nur Rollen-IDs und werden nach Peer- oder Parent-Peer-Bindings und vor reinen Guild-Bindings ausgewertet. Wenn ein Binding auch andere Abgleichsfelder setzt (zum Beispiel `peer` + `guildId` + `roles`), müssen alle konfigurierten Felder übereinstimmen. ```json5 { @@ -627,17 +627,17 @@ Verwenden Sie `bindings[].match.roles`, um Discord-Guild-Mitglieder nach Rollen- } ``` -## Native Befehle und Befehlsauthentifizierung +## Native Befehle und Befehlsautorisierung - `commands.native` ist standardmäßig `"auto"` und für Discord aktiviert. -- Kanalbezogene Überschreibung: `channels.discord.commands.native`. -- `commands.native=false` überspringt die Registrierung und Bereinigung von Discord-Slash-Befehlen beim Start. Zuvor registrierte Befehle können in Discord sichtbar bleiben, bis Sie sie aus der Discord-App entfernen. -- Die Authentifizierung nativer Befehle verwendet dieselben Discord-Allowlists/Richtlinien wie die normale Nachrichtenverarbeitung. -- Befehle können in der Discord-UI weiterhin für Benutzer sichtbar sein, die nicht autorisiert sind; die Ausführung erzwingt weiterhin die OpenClaw-Authentifizierung und gibt "nicht autorisiert" zurück. +- Überschreibung pro Kanal: `channels.discord.commands.native`. +- `commands.native=false` überspringt beim Start die Registrierung und Bereinigung von Discord-Slash-Commands. Zuvor registrierte Commands können in Discord sichtbar bleiben, bis Sie sie aus der Discord-App entfernen. +- Native Command-Authentifizierung verwendet dieselben Discord-Allowlists/-Richtlinien wie die normale Nachrichtenverarbeitung. +- Commands können in der Discord UI weiterhin für Benutzer sichtbar sein, die nicht autorisiert sind; die Ausführung erzwingt dennoch die OpenClaw-Authentifizierung und gibt „not authorized“ zurück. -Siehe [Slash-Befehle](/de/tools/slash-commands) für Befehlskatalog und Verhalten. +Siehe [Slash-Commands](/de/tools/slash-commands) für Command-Katalog und Verhalten. -Standardeinstellungen für Slash-Befehle: +Standardmäßige Slash-Command-Einstellungen: - `ephemeral: true` @@ -645,7 +645,7 @@ Standardeinstellungen für Slash-Befehle: - Discord unterstützt Antwort-Tags in der Agentenausgabe: + Discord unterstützt Antwort-Tags in Agentenausgaben: - `[[reply_to_current]]` - `[[reply_to:]]` @@ -657,21 +657,21 @@ Standardeinstellungen für Slash-Befehle: - `all` - `batched` - Hinweis: `off` deaktiviert implizites Antwort-Threading. Explizite `[[reply_to_*]]`-Tags werden weiterhin berücksichtigt. - `first` hängt die implizite native Antwortreferenz immer an die erste ausgehende Discord-Nachricht für den Turn an. - `batched` hängt die implizite native Antwortreferenz von Discord nur an, wenn der - eingehende Turn ein entprellter Batch aus mehreren Nachrichten war. Dies ist nützlich, - wenn Sie native Antworten vor allem für mehrdeutige, stoßweise Chats wünschen, nicht für jeden - einzelnen Nachrichten-Turn. + Hinweis: `off` deaktiviert implizites Reply-Threading. Explizite `[[reply_to_*]]`-Tags werden weiterhin berücksichtigt. + `first` hängt die implizite native Reply-Referenz immer an die erste ausgehende Discord-Nachricht für den Durchlauf an. + `batched` hängt die implizite native Reply-Referenz von Discord nur an, wenn der + eingehende Durchlauf ein entprellter Batch aus mehreren Nachrichten war. Das ist nützlich, + wenn Sie native Replies vor allem für mehrdeutige, stoßweise Chats wünschen, nicht für jeden + Durchlauf mit einer einzelnen Nachricht. Nachrichten-IDs werden im Kontext/Verlauf bereitgestellt, damit Agenten gezielt bestimmte Nachrichten adressieren können. - OpenClaw kann Antwortentwürfe streamen, indem es eine temporäre Nachricht sendet und sie bearbeitet, während Text eintrifft. `channels.discord.streaming` akzeptiert `off` (Standard) | `partial` | `block` | `progress`. `progress` behält einen bearbeitbaren Statusentwurf bei und aktualisiert ihn bis zur finalen Zustellung mit Tool-Fortschritt; `streamMode` ist ein Legacy-Alias und wird automatisch migriert. + OpenClaw kann Antwortentwürfe streamen, indem es eine temporäre Nachricht sendet und sie bearbeitet, sobald Text eintrifft. `channels.discord.streaming` akzeptiert `off` (Standard) | `partial` | `block` | `progress`. `progress` behält einen bearbeitbaren Statusentwurf bei und aktualisiert ihn mit Tool-Fortschritt bis zur finalen Zustellung; `streamMode` ist ein Legacy-Alias und wird automatisch migriert. - Der Standard bleibt `off`, da Discord-Vorschaubearbeitungen schnell Ratenlimits erreichen, wenn mehrere Bots oder Gateways ein Konto teilen. + Die Standardeinstellung bleibt `off`, weil Discord-Vorschaubearbeitungen schnell an Rate Limits stoßen, wenn mehrere Bots oder Gateways ein Konto gemeinsam nutzen. ```json5 { @@ -689,48 +689,67 @@ Standardeinstellungen für Slash-Befehle: ``` - `partial` bearbeitet eine einzelne Vorschaunachricht, während Tokens eintreffen. - - `block` gibt Entwurfsgroße Blöcke aus (verwenden Sie `draftChunk`, um Größe und Umbruchpunkte abzustimmen, begrenzt durch `textChunkLimit`). - - Medien, Fehler und finale Antworten mit expliziter Antwortreferenz brechen ausstehende Vorschaubearbeitungen ab. + - `block` gibt Entwurfs-Chunks in Entwurfsgröße aus (verwenden Sie `draftChunk`, um Größe und Umbruchpunkte anzupassen, begrenzt auf `textChunkLimit`). + - Medien, Fehler und finale Antworten mit explizitem Reply brechen ausstehende Vorschaubearbeitungen ab. - `streaming.preview.toolProgress` (Standard `true`) steuert, ob Tool-/Fortschrittsaktualisierungen die Vorschaunachricht wiederverwenden. + - `streaming.preview.commandText` / `streaming.progress.commandText` steuert Command-/Exec-Details in kompakten Fortschrittszeilen: `raw` (Standard) oder `status` (nur Tool-Bezeichnung). - Vorschau-Streaming ist rein textbasiert; Medienantworten fallen auf die normale Zustellung zurück. Wenn `block`-Streaming explizit aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden. + Rohtext von Command/Exec ausblenden, aber kompakte Fortschrittszeilen beibehalten: + + ```json + { + "channels": { + "discord": { + "streaming": { + "mode": "progress", + "progress": { + "toolProgress": true, + "commandText": "status" + } + } + } + } + } + ``` + + Vorschau-Streaming ist nur textbasiert; Medienantworten fallen auf normale Zustellung zurück. Wenn `block`-Streaming explizit aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden. - Verlaufskontext für Guilds: + Guild-Verlaufskontext: - `channels.discord.historyLimit` Standard `20` - Fallback: `messages.groupChat.historyLimit` - `0` deaktiviert - DM-Verlaufskontrollen: + DM-Verlaufssteuerung: - `channels.discord.dmHistoryLimit` - `channels.discord.dms[""].historyLimit` Thread-Verhalten: - - Discord-Threads werden als Kanalsitzungen geroutet und übernehmen die Konfiguration des übergeordneten Kanals, sofern sie nicht überschrieben wird. - - Thread-Sitzungen übernehmen die `/model`-Auswahl auf Sitzungsebene des übergeordneten Kanals als reinen Modell-Fallback; Thread-lokale `/model`-Auswahlen haben weiterhin Vorrang, und der Transkriptverlauf des übergeordneten Kanals wird nicht kopiert, sofern Transkriptvererbung nicht aktiviert ist. - - `channels.discord.thread.inheritParent` (Standard `false`) optiert neue Auto-Threads in das Seeding aus dem übergeordneten Transkript ein. Kontoübergreifende Überschreibungen befinden sich unter `channels.discord.accounts..thread.inheritParent`. - - Reaktionen des Nachrichten-Tools können `user:`-DM-Ziele auflösen. - - `guilds..channels..requireMention: false` bleibt während des Aktivierungs-Fallbacks in der Antwortphase erhalten. + - Discord-Threads werden als Kanalsitzungen geroutet und erben die Konfiguration des übergeordneten Kanals, sofern sie nicht überschrieben wird. + - Thread-Sitzungen erben die sitzungsbezogene `/model`-Auswahl des übergeordneten Kanals als reine Modell-Fallback-Option; thread-lokale `/model`-Auswahlen haben weiterhin Vorrang, und der Transkriptverlauf des übergeordneten Kanals wird nur kopiert, wenn Transkriptvererbung aktiviert ist. + - `channels.discord.thread.inheritParent` (Standard `false`) aktiviert für neue Auto-Threads das Initialisieren aus dem übergeordneten Transkript. Überschreibungen pro Konto befinden sich unter `channels.discord.accounts..thread.inheritParent`. + - Message-Tool-Reaktionen können `user:`-DM-Ziele auflösen. + - `guilds..channels..requireMention: false` bleibt beim Reply-Stage-Aktivierungs-Fallback erhalten. - Kanalthemen werden als **nicht vertrauenswürdiger** Kontext injiziert. Allowlists steuern, wer den Agenten auslösen kann, sind aber keine vollständige Redaktionsgrenze für ergänzenden Kontext. + Kanalthemen werden als **nicht vertrauenswürdiger** Kontext eingefügt. Allowlists steuern, wer den Agenten auslösen kann, nicht eine vollständige Redaktionsgrenze für ergänzenden Kontext. - Discord kann einen Thread an ein Sitzungsziel binden, sodass Folgenachrichten in diesem Thread weiterhin an dieselbe Sitzung geroutet werden (einschließlich Subagent-Sitzungen). + Discord kann einen Thread an ein Sitzungsziel binden, sodass Follow-up-Nachrichten in diesem Thread weiterhin zur selben Sitzung geroutet werden (einschließlich Subagent-Sitzungen). - Befehle: + Commands: - - `/focus ` bindet den aktuellen/neuen Thread an ein Subagent-/Sitzungsziel + - `/focus ` bindet aktuellen/neuen Thread an ein Subagent-/Sitzungsziel - `/unfocus` entfernt die aktuelle Thread-Bindung - - `/agents` zeigt aktive Läufe und Bindungsstatus - - `/session idle ` prüft/aktualisiert das automatische Entfokussieren bei Inaktivität für fokussierte Bindungen - - `/session max-age ` prüft/aktualisiert das harte Höchstalter für fokussierte Bindungen + - `/agents` zeigt aktive Läufe und Bindungsstatus an + - `/session idle ` prüft/aktualisiert Auto-Unfocus bei Inaktivität für fokussierte Bindungen + - `/session max-age ` prüft/aktualisiert das harte Maximalalter für fokussierte Bindungen Konfiguration: @@ -760,18 +779,18 @@ Standardeinstellungen für Slash-Befehle: Hinweise: - `session.threadBindings.*` legt globale Standardwerte fest. - - `channels.discord.threadBindings.*` überschreibt das Discord-Verhalten. + - `channels.discord.threadBindings.*` überschreibt Discord-Verhalten. - `spawnSessions` steuert das automatische Erstellen/Binden von Threads für `sessions_spawn({ thread: true })` und ACP-Thread-Spawns. Standard: `true`. - `defaultSpawnContext` steuert den nativen Subagent-Kontext für Thread-gebundene Spawns. Standard: `"fork"`. - Veraltete Schlüssel `spawnSubagentSessions`/`spawnAcpSessions` werden durch `openclaw doctor --fix` migriert. - - Wenn Thread-Bindungen für ein Konto deaktiviert sind, sind `/focus` und zugehörige Thread-Bindungsoperationen nicht verfügbar. + - Wenn Thread-Bindungen für ein Konto deaktiviert sind, sind `/focus` und verwandte Thread-Bindungsoperationen nicht verfügbar. Siehe [Subagenten](/de/tools/subagents), [ACP-Agenten](/de/tools/acp-agents) und [Konfigurationsreferenz](/de/gateway/configuration-reference). - Für stabile, "immer aktive" ACP-Arbeitsbereiche konfigurieren Sie typisierte ACP-Bindungen auf oberster Ebene, die auf Discord-Unterhaltungen zielen. + Für stabile „always-on“-ACP-Arbeitsbereiche konfigurieren Sie typisierte ACP-Bindungen auf oberster Ebene, die auf Discord-Unterhaltungen abzielen. Konfigurationspfad: @@ -827,9 +846,9 @@ Standardeinstellungen für Slash-Befehle: Hinweise: - - `/acp spawn codex --bind here` bindet den aktuellen Kanal oder Thread an Ort und Stelle und hält zukünftige Nachrichten auf derselben ACP-Sitzung. Thread-Nachrichten übernehmen die Bindung des übergeordneten Kanals. + - `/acp spawn codex --bind here` bindet den aktuellen Kanal oder Thread an Ort und Stelle und hält zukünftige Nachrichten in derselben ACP-Sitzung. Thread-Nachrichten erben die Bindung des übergeordneten Kanals. - In einem gebundenen Kanal oder Thread setzen `/new` und `/reset` dieselbe ACP-Sitzung an Ort und Stelle zurück. Temporäre Thread-Bindungen können die Zielauflösung überschreiben, solange sie aktiv sind. - - `spawnSessions` steuert die Erstellung/Bindung von Child-Threads über `--thread auto|here`. + - `spawnSessions` steuert die Erstellung/Bindung untergeordneter Threads über `--thread auto|here`. Siehe [ACP-Agenten](/de/tools/acp-agents) für Details zum Bindungsverhalten. @@ -847,7 +866,7 @@ Standardeinstellungen für Slash-Befehle: - + `ackReaction` sendet ein Bestätigungs-Emoji, während OpenClaw eine eingehende Nachricht verarbeitet. Auflösungsreihenfolge: @@ -855,7 +874,7 @@ Standardeinstellungen für Slash-Befehle: - `channels.discord.accounts..ackReaction` - `channels.discord.ackReaction` - `messages.ackReaction` - - Fallback auf das Emoji der Agentenidentität (`agents.list[].identity.emoji`, andernfalls "👀") + - Fallback auf Agentenidentitäts-Emoji (`agents.list[].identity.emoji`, sonst "👀") Hinweise: @@ -867,7 +886,7 @@ Standardeinstellungen für Slash-Befehle: Kanalinitiierte Konfigurationsschreibvorgänge sind standardmäßig aktiviert. - Dies betrifft `/config set|unset`-Abläufe (wenn Befehlsfunktionen aktiviert sind). + Dies betrifft `/config set|unset`-Abläufe (wenn Command-Funktionen aktiviert sind). Deaktivieren: @@ -884,7 +903,7 @@ Standardeinstellungen für Slash-Befehle: - Leiten Sie Discord-Gateway-WebSocket-Datenverkehr und REST-Abfragen beim Start (Anwendungs-ID + Allowlist-Auflösung) mit `channels.discord.proxy` über einen HTTP(S)-Proxy. + Routen Sie Discord-Gateway-WebSocket-Datenverkehr und REST-Lookups beim Start (Application-ID + Allowlist-Auflösung) über einen HTTP(S)-Proxy mit `channels.discord.proxy`. ```json5 { @@ -896,7 +915,7 @@ Standardeinstellungen für Slash-Befehle: } ``` - Kontoübergreifende Überschreibung: + Überschreibung pro Konto: ```json5 { @@ -915,7 +934,7 @@ Standardeinstellungen für Slash-Befehle: - Aktivieren Sie die PluralKit-Auflösung, um weitergeleitete Nachrichten der Identität von Systemmitgliedern zuzuordnen: + Aktivieren Sie die PluralKit-Auflösung, um proxied Messages der Identität eines Systemmitglieds zuzuordnen: ```json5 { @@ -934,13 +953,13 @@ Standardeinstellungen für Slash-Befehle: - Allowlists können `pk:` verwenden - Anzeigenamen von Mitgliedern werden nur nach Name/Slug abgeglichen, wenn `channels.discord.dangerouslyAllowNameMatching: true` - - Abfragen verwenden die ursprüngliche Nachrichten-ID und sind zeitfensterbeschränkt - - Wenn die Abfrage fehlschlägt, werden weitergeleitete Nachrichten als Bot-Nachrichten behandelt und verworfen, sofern `allowBots=true` nicht gesetzt ist + - Lookups verwenden die ursprüngliche Nachrichten-ID und sind zeitfensterbeschränkt + - Wenn der Lookup fehlschlägt, werden proxied Messages als Bot-Nachrichten behandelt und verworfen, sofern `allowBots=true` nicht gesetzt ist - - Verwenden Sie `mentionAliases`, wenn Agenten deterministische ausgehende Erwähnungen für bekannte Discord-Benutzer benötigen. Schlüssel sind Handles ohne führendes `@`; Werte sind Discord-Benutzer-IDs. Unbekannte Handles, `@everyone`, `@here` und Erwähnungen innerhalb von Markdown-Code-Spans bleiben unverändert. + + Verwenden Sie `mentionAliases`, wenn Agenten deterministische ausgehende Mentions für bekannte Discord-Benutzer benötigen. Schlüssel sind Handles ohne führendes `@`; Werte sind Discord-Benutzer-IDs. Unbekannte Handles, `@everyone`, `@here` und Mentions innerhalb von Markdown-Code-Spans bleiben unverändert. ```json5 { @@ -964,9 +983,9 @@ Standardeinstellungen für Slash-Befehle: - Presence-Aktualisierungen werden angewendet, wenn Sie ein Status- oder Aktivitätsfeld setzen oder automatische Presence aktivieren. + Presence-Aktualisierungen werden angewendet, wenn Sie ein Status- oder Aktivitätsfeld festlegen oder Auto-Presence aktivieren. - Beispiel nur mit Status: + Beispiel nur für Status: ```json5 { @@ -978,7 +997,7 @@ Standardeinstellungen für Slash-Befehle: } ``` - Aktivitätsbeispiel (benutzerdefinierter Status ist der Standardaktivitätstyp): + Aktivitätsbeispiel (benutzerdefinierter Status ist der Standard-Aktivitätstyp): ```json5 { @@ -1005,16 +1024,16 @@ Standardeinstellungen für Slash-Befehle: } ``` - Zuordnung der Aktivitätstypen: + Aktivitätstyp-Zuordnung: - 0: Spielen - 1: Streaming (erfordert `activityUrl`) - - 2: Zuhören - - 3: Zuschauen + - 2: Hören + - 3: Ansehen - 4: Benutzerdefiniert (verwendet den Aktivitätstext als Statuszustand; Emoji ist optional) - - 5: Teilnehmen + - 5: Konkurrieren - Beispiel für automatische Presence (Laufzeit-Integritätssignal): + Auto-Presence-Beispiel (Runtime-Zustandssignal): ```json5 { @@ -1031,16 +1050,16 @@ Standardeinstellungen für Slash-Befehle: } ``` - Automatische Presence ordnet die Laufzeitverfügbarkeit dem Discord-Status zu: gesund => online, beeinträchtigt oder unbekannt => idle, ausgeschöpft oder nicht verfügbar => dnd. Optionale Textüberschreibungen: + Auto-Präsenz ordnet die Runtime-Verfügbarkeit dem Discord-Status zu: healthy => online, degraded oder unknown => idle, exhausted oder unavailable => dnd. Optionale Textüberschreibungen: - `autoPresence.healthyText` - `autoPresence.degradedText` - - `autoPresence.exhaustedText` (unterstützt `{reason}`-Platzhalter) + - `autoPresence.exhaustedText` (unterstützt den Platzhalter `{reason}`) - - Discord unterstützt die buttonbasierte Genehmigungsverarbeitung in DMs und kann Genehmigungsaufforderungen optional im ursprünglichen Kanal posten. + + Discord unterstützt buttonbasierte Freigabeabläufe in DMs und kann Freigabeaufforderungen optional im ursprünglichen Kanal posten. Konfigurationspfad: @@ -1049,25 +1068,25 @@ Standardeinstellungen für Slash-Befehle: - `channels.discord.execApprovals.target` (`dm` | `channel` | `both`, Standard: `dm`) - `agentFilter`, `sessionFilter`, `cleanupAfterResolve` - Discord aktiviert native Exec-Genehmigungen automatisch, wenn `enabled` nicht gesetzt ist oder `"auto"` ist und mindestens ein Genehmiger aufgelöst werden kann, entweder aus `execApprovals.approvers` oder aus `commands.ownerAllowFrom`. Discord leitet Exec-Genehmiger nicht aus Kanal-`allowFrom`, dem älteren `dm.allowFrom` oder Direktnachrichten-`defaultTo` ab. Setzen Sie `enabled: false`, um Discord ausdrücklich als nativen Genehmigungsclient zu deaktivieren. + Discord aktiviert native Exec-Freigaben automatisch, wenn `enabled` nicht gesetzt oder `"auto"` ist und mindestens ein Freigebender aufgelöst werden kann, entweder aus `execApprovals.approvers` oder aus `commands.ownerAllowFrom`. Discord leitet keine Exec-Freigebenden aus Kanal-`allowFrom`, dem Legacy-`dm.allowFrom` oder Direct-Message-`defaultTo` ab. Setzen Sie `enabled: false`, um Discord explizit als nativen Freigabe-Client zu deaktivieren. - Bei sensiblen gruppenbezogenen Befehlen, die nur Eigentümern vorbehalten sind, etwa `/diagnostics` und `/export-trajectory`, sendet OpenClaw Genehmigungsaufforderungen und Endergebnisse privat. Es versucht zuerst eine Discord-DM, wenn der aufrufende Eigentümer eine Discord-Eigentümerroute hat; falls diese nicht verfügbar ist, fällt es auf die erste verfügbare Eigentümerroute aus `commands.ownerAllowFrom` zurück, etwa Telegram. + Für sensible, nur Ownern vorbehaltene Gruppenbefehle wie `/diagnostics` und `/export-trajectory` sendet OpenClaw Freigabeaufforderungen und Endergebnisse privat. Zuerst versucht es Discord-DM, wenn der aufrufende Owner eine Discord-Owner-Route hat; falls diese nicht verfügbar ist, fällt es auf die erste verfügbare Owner-Route aus `commands.ownerAllowFrom` zurück, zum Beispiel Telegram. - Wenn `target` `channel` oder `both` ist, ist die Genehmigungsaufforderung im Kanal sichtbar. Nur aufgelöste Genehmiger können die Schaltflächen verwenden; andere Benutzer erhalten eine flüchtige Ablehnung. Genehmigungsaufforderungen enthalten den Befehlstext, aktivieren Sie die Kanalzustellung daher nur in vertrauenswürdigen Kanälen. Wenn die Kanal-ID nicht aus dem Sitzungsschlüssel abgeleitet werden kann, fällt OpenClaw auf DM-Zustellung zurück. + Wenn `target` `channel` oder `both` ist, ist die Freigabeaufforderung im Kanal sichtbar. Nur aufgelöste Freigebende können die Buttons verwenden; andere Benutzer erhalten eine ephemere Ablehnung. Freigabeaufforderungen enthalten den Befehlstext, aktivieren Sie die Kanalzustellung daher nur in vertrauenswürdigen Kanälen. Wenn die Kanal-ID nicht aus dem Sitzungsschlüssel abgeleitet werden kann, fällt OpenClaw auf DM-Zustellung zurück. - Discord rendert außerdem die gemeinsam genutzten Genehmigungsschaltflächen, die auch von anderen Chatkanälen verwendet werden. Der native Discord-Adapter ergänzt hauptsächlich Genehmiger-DM-Routing und Kanal-Fanout. - Wenn diese Schaltflächen vorhanden sind, sind sie die primäre Genehmigungs-UX; OpenClaw - sollte nur dann einen manuellen `/approve`-Befehl einschließen, wenn das Tool-Ergebnis angibt, - dass Chatgenehmigungen nicht verfügbar sind oder die manuelle Genehmigung der einzige Weg ist. - Wenn die native Discord-Genehmigungsruntime nicht aktiv ist, hält OpenClaw die + Discord rendert außerdem die gemeinsam genutzten Freigabe-Buttons, die von anderen Chat-Kanälen verwendet werden. Der native Discord-Adapter ergänzt hauptsächlich Freigebenden-DM-Routing und Kanal-Fanout. + Wenn diese Buttons vorhanden sind, sind sie die primäre Freigabe-UX; OpenClaw + sollte nur dann einen manuellen `/approve`-Befehl einschließen, wenn das Tool-Ergebnis meldet, + dass Chat-Freigaben nicht verfügbar sind oder die manuelle Freigabe der einzige Weg ist. + Wenn die native Discord-Freigabe-Runtime nicht aktiv ist, lässt OpenClaw die lokale deterministische Aufforderung `/approve ` sichtbar. Wenn die - Runtime aktiv ist, aber keine native Karte an ein Ziel zugestellt werden kann, + Runtime aktiv ist, aber keine native Karte an irgendein Ziel zugestellt werden kann, sendet OpenClaw einen Fallback-Hinweis im selben Chat mit dem exakten `/approve`- - Befehl aus der ausstehenden Genehmigung. + Befehl aus der ausstehenden Freigabe. - Gateway-Authentifizierung und Genehmigungsauflösung folgen dem gemeinsamen Gateway-Clientvertrag (`plugin:`-IDs werden über `plugin.approval.resolve` aufgelöst; andere IDs über `exec.approval.resolve`). Genehmigungen laufen standardmäßig nach 30 Minuten ab. + Gateway-Authentifizierung und Freigabeauflösung folgen dem gemeinsamen Gateway-Client-Vertrag (`plugin:`-IDs werden über `plugin.approval.resolve` aufgelöst; andere IDs über `exec.approval.resolve`). Freigaben laufen standardmäßig nach 30 Minuten ab. - Siehe [Exec-Genehmigungen](/de/tools/exec-approvals). + Siehe [Exec-Freigaben](/de/tools/exec-approvals). @@ -1087,20 +1106,20 @@ Die Aktion `event-create` akzeptiert einen optionalen Parameter `image` (URL ode Aktions-Gates befinden sich unter `channels.discord.actions.*`. -Standardverhalten der Gates: +Standardmäßiges Gate-Verhalten: -| Aktionsgruppe | Standard | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ | -| reactions, messages, threads, pins, polls, search, memberInfo, roleInfo, channelInfo, channels, voiceStatus, events, stickers, emojiUploads, stickerUploads, permissions | aktiviert | -| roles | deaktiviert | -| moderation | deaktiviert | -| presence | deaktiviert | +| Aktionsgruppe | Standard | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------- | +| reactions, messages, threads, pins, polls, search, memberInfo, roleInfo, channelInfo, channels, voiceStatus, events, stickers, emojiUploads, stickerUploads, permissions | aktiviert | +| roles | deaktiviert | +| moderation | deaktiviert | +| presence | deaktiviert | ## Components-v2-UI -OpenClaw verwendet Discord Components v2 für Exec-Genehmigungen und kontextübergreifende Marker. Discord-Nachrichtenaktionen können außerdem `components` für benutzerdefinierte UI akzeptieren (fortgeschritten; erfordert das Erstellen eines Komponenten-Payloads über das Discord-Tool), während ältere `embeds` weiterhin verfügbar sind, aber nicht empfohlen werden. +OpenClaw verwendet Discord Components v2 für Exec-Freigaben und Cross-Context-Markierungen. Discord-Nachrichtenaktionen können auch `components` für benutzerdefinierte UI akzeptieren (fortgeschritten; erfordert das Erstellen eines Component-Payloads über das Discord-Tool), während Legacy-`embeds` weiterhin verfügbar sind, aber nicht empfohlen werden. -- `channels.discord.ui.components.accentColor` legt die Akzentfarbe fest, die von Discord-Komponentencontainern verwendet wird (Hex). +- `channels.discord.ui.components.accentColor` legt die Akzentfarbe fest, die von Discord-Component-Containern verwendet wird (hex). - Pro Konto mit `channels.discord.accounts..ui.components.accentColor` festlegen. - `embeds` werden ignoriert, wenn Components v2 vorhanden sind. @@ -1122,11 +1141,11 @@ Beispiel: ## Voice -Discord hat zwei unterschiedliche Voice-Oberflächen: Echtzeit-**Voice-Kanäle** (fortlaufende Gespräche) und **Voice-Nachrichtenanhänge** (das Format mit Wellenformvorschau). Das Gateway unterstützt beides. +Discord hat zwei verschiedene Voice-Oberflächen: Echtzeit-**Voice-Kanäle** (fortlaufende Gespräche) und **Voice-Message-Anhänge** (das Waveform-Vorschauformat). Das Gateway unterstützt beides. ### Voice-Kanäle -Einrichtungscheckliste: +Einrichtungs-Checkliste: 1. Aktivieren Sie Message Content Intent im Discord Developer Portal. 2. Aktivieren Sie Server Members Intent, wenn Rollen-/Benutzer-Allowlists verwendet werden. @@ -1135,7 +1154,7 @@ Einrichtungscheckliste: 5. Aktivieren Sie native Befehle (`commands.native` oder `channels.discord.commands.native`). 6. Konfigurieren Sie `channels.discord.voice`. -Verwenden Sie `/vc join|leave|status`, um Sitzungen zu steuern. Der Befehl verwendet den Standard-Agenten des Kontos und folgt denselben Allowlist- und Gruppenrichtlinienregeln wie andere Discord-Befehle. +Verwenden Sie `/vc join|leave|status`, um Sitzungen zu steuern. Der Befehl verwendet den Standard-Agent des Kontos und folgt denselben Allowlist- und Gruppenrichtlinienregeln wie andere Discord-Befehle. ```bash /vc join channel: @@ -1175,32 +1194,32 @@ Auto-Join-Beispiel: Hinweise: - `voice.tts` überschreibt `messages.tts` nur für Voice-Wiedergabe. -- `voice.model` überschreibt nur das LLM, das für Discord-Voice-Kanalantworten verwendet wird. Lassen Sie es ungesetzt, um das geroutete Agentenmodell zu übernehmen. +- `voice.model` überschreibt nur das LLM, das für Discord-Voice-Kanalantworten verwendet wird. Lassen Sie es nicht gesetzt, um das Modell des gerouteten Agent zu übernehmen. - STT verwendet `tools.media.audio`; `voice.model` wirkt sich nicht auf die Transkription aus. -- Pro Kanal geltende Discord-`systemPrompt`-Überschreibungen gelten für Voice-Transkript-Turns in diesem Voice-Kanal. -- Voice-Transkript-Turns leiten den Eigentümerstatus aus Discord-`allowFrom` (oder `dm.allowFrom`) ab; Sprecher ohne Eigentümerstatus können nicht auf Tools zugreifen, die nur Eigentümern vorbehalten sind (zum Beispiel `gateway` und `cron`). +- Pro-Kanal-Discord-`systemPrompt`-Überschreibungen gelten für Voice-Transkript-Turns dieses Voice-Kanals. +- Voice-Transkript-Turns leiten den Owner-Status aus Discord-`allowFrom` (oder `dm.allowFrom`) ab; Nicht-Owner-Sprecher können nicht auf Owner-only-Tools zugreifen (zum Beispiel `gateway` und `cron`). - Discord Voice ist für reine Textkonfigurationen Opt-in; setzen Sie `channels.discord.voice.enabled=true` (oder behalten Sie einen vorhandenen `channels.discord.voice`-Block bei), um `/vc`-Befehle, die Voice-Runtime und den Gateway-Intent `GuildVoiceStates` zu aktivieren. -- `channels.discord.intents.voiceStates` kann die Voice-State-Intent-Subscription ausdrücklich überschreiben. Lassen Sie es ungesetzt, damit der Intent der wirksamen Voice-Aktivierung folgt. -- `voice.daveEncryption` und `voice.decryptionFailureTolerance` werden an die Join-Optionen von `@discordjs/voice` durchgereicht. -- Die Standards von `@discordjs/voice` sind `daveEncryption=true` und `decryptionFailureTolerance=24`, wenn sie nicht gesetzt sind. -- `voice.connectTimeoutMs` steuert die anfängliche Ready-Wartezeit von `@discordjs/voice` für `/vc join` und Auto-Join-Versuche. Standard: `30000`. -- `voice.reconnectGraceMs` steuert, wie lange OpenClaw wartet, bis eine getrennte Voice-Sitzung mit der Wiederverbindung beginnt, bevor sie zerstört wird. Standard: `15000`. -- OpenClaw überwacht außerdem Empfangs-Entschlüsselungsfehler und stellt automatisch wieder her, indem es den Voice-Kanal nach wiederholten Fehlern in einem kurzen Zeitfenster verlässt und erneut beitritt. -- Wenn Empfangsprotokolle nach einer Aktualisierung wiederholt `DecryptionFailed(UnencryptedWhenPassthroughDisabled)` anzeigen, sammeln Sie einen Abhängigkeitsbericht und Protokolle. Die gebündelte `@discordjs/voice`-Linie enthält den Upstream-Padding-Fix aus discord.js PR #11449, der discord.js-Issue #11419 geschlossen hat. +- `channels.discord.intents.voiceStates` kann das Voice-State-Intent-Abonnement explizit überschreiben. Lassen Sie es nicht gesetzt, damit der Intent der effektiven Voice-Aktivierung folgt. +- `voice.daveEncryption` und `voice.decryptionFailureTolerance` werden an die Join-Optionen von `@discordjs/voice` weitergereicht. +- Die Standardwerte von `@discordjs/voice` sind `daveEncryption=true` und `decryptionFailureTolerance=24`, wenn nicht gesetzt. +- `voice.connectTimeoutMs` steuert die anfängliche `@discordjs/voice`-Ready-Wartezeit für `/vc join` und Auto-Join-Versuche. Standard: `30000`. +- `voice.reconnectGraceMs` steuert, wie lange OpenClaw auf den Beginn der Wiederverbindung einer getrennten Voice-Sitzung wartet, bevor sie zerstört wird. Standard: `15000`. +- OpenClaw überwacht außerdem Empfangs-Entschlüsselungsfehler und stellt sich automatisch wieder her, indem es den Voice-Kanal nach wiederholten Fehlern in einem kurzen Zeitfenster verlässt und erneut beitritt. +- Wenn Empfangslogs nach der Aktualisierung wiederholt `DecryptionFailed(UnencryptedWhenPassthroughDisabled)` anzeigen, sammeln Sie einen Dependency-Bericht und Logs. Die gebündelte `@discordjs/voice`-Linie enthält den Upstream-Padding-Fix aus discord.js-PR #11449, der discord.js-Issue #11419 geschlossen hat. Voice-Kanal-Pipeline: - Discord-PCM-Erfassung wird in eine temporäre WAV-Datei konvertiert. - `tools.media.audio` verarbeitet STT, zum Beispiel `openai/gpt-4o-mini-transcribe`. -- Das Transkript wird durch Discord-Ingress und Routing gesendet, während das Antwort-LLM mit einer Voice-Ausgaberichtlinie ausgeführt wird, die das Agenten-Tool `tts` ausblendet und zurückgegebenen Text anfordert, da Discord Voice die finale TTS-Wiedergabe besitzt. +- Das Transkript wird durch Discord-Ingress und Routing gesendet, während das Antwort-LLM mit einer Voice-Output-Richtlinie läuft, die das Agent-`tts`-Tool verbirgt und zurückgegebenen Text anfordert, weil Discord Voice die finale TTS-Wiedergabe besitzt. - `voice.model` überschreibt, wenn gesetzt, nur das Antwort-LLM für diesen Voice-Kanal-Turn. -- `voice.tts` wird über `messages.tts` zusammengeführt; das resultierende Audio wird im beigetretenen Kanal abgespielt. +- `voice.tts` wird über `messages.tts` gemergt; das resultierende Audio wird im beigetretenen Kanal abgespielt. Anmeldedaten werden pro Komponente aufgelöst: LLM-Routen-Authentifizierung für `voice.model`, STT-Authentifizierung für `tools.media.audio` und TTS-Authentifizierung für `messages.tts`/`voice.tts`. ### Voice-Nachrichten -Discord-Voice-Nachrichten zeigen eine Wellenformvorschau und erfordern OGG/Opus-Audio. OpenClaw generiert die Wellenform automatisch, benötigt aber `ffmpeg` und `ffprobe` auf dem Gateway-Host, um zu prüfen und zu konvertieren. +Discord-Voice-Nachrichten zeigen eine Waveform-Vorschau und erfordern OGG/Opus-Audio. OpenClaw generiert die Waveform automatisch, benötigt aber `ffmpeg` und `ffprobe` auf dem Gateway-Host, um zu prüfen und zu konvertieren. - Geben Sie einen **lokalen Dateipfad** an (URLs werden abgelehnt). - Lassen Sie Textinhalt weg (Discord lehnt Text + Voice-Nachricht im selben Payload ab). @@ -1216,7 +1235,7 @@ message(action="send", channel="discord", target="channel:123", path="/path/to/a - Message Content Intent aktivieren - - Server Members Intent aktivieren, wenn Sie auf Benutzer-/Member-Auflösung angewiesen sind + - Server Members Intent aktivieren, wenn Sie von Benutzer-/Member-Auflösung abhängen - Gateway nach dem Ändern von Intents neu starten @@ -1225,8 +1244,8 @@ message(action="send", channel="discord", target="channel:123", path="/path/to/a - `groupPolicy` prüfen - Guild-Allowlist unter `channels.discord.guilds` prüfen - - wenn eine Guild-`channels`-Map vorhanden ist, sind nur aufgelistete Kanäle erlaubt - - Verhalten von `requireMention` und Erwähnungsmuster prüfen + - wenn eine Guild-`channels`-Map existiert, sind nur aufgelistete Kanäle erlaubt + - `requireMention`-Verhalten und Erwähnungsmuster prüfen Nützliche Prüfungen: @@ -1238,29 +1257,29 @@ openclaw logs --follow - + Häufige Ursachen: - `groupPolicy="allowlist"` ohne passende Guild-/Kanal-Allowlist - - `requireMention` an der falschen Stelle konfiguriert (muss unter `channels.discord.guilds` oder dem Kanaleintrag stehen) + - `requireMention` an der falschen Stelle konfiguriert (muss unter `channels.discord.guilds` oder dem Kanaleintrag liegen) - Absender durch Guild-/Kanal-`users`-Allowlist blockiert - Typische Protokolle: + Typische Logs: - `Slow listener detected ...` - `stuck session: sessionKey=agent:...:discord:... state=processing ...` - Discord-Gateway-Warteschlangenoptionen: + Discord-Gateway-Queue-Regler: - Einzelkonto: `channels.discord.eventQueue.listenerTimeout` - - Mehrkonto: `channels.discord.accounts..eventQueue.listenerTimeout` - - dies steuert nur die Listener-Arbeit des Discord-Gateway, nicht die Lebensdauer des Agenten-Turns + - Mehrere Konten: `channels.discord.accounts..eventQueue.listenerTimeout` + - dies steuert nur Discord-Gateway-Listener-Arbeit, nicht die Agent-Turn-Laufzeit - Discord wendet kein kanaleigenes Timeout auf eingereihte Agenten-Turns an. Nachrichten-Listener übergeben sofort, und eingereihte Discord-Ausführungen bewahren die Reihenfolge pro Sitzung, bis der Sitzungs-/Tool-/Runtime-Lebenszyklus abgeschlossen ist oder die Arbeit abbricht. + Discord wendet kein kanal-eigenes Timeout auf eingereihte Agent-Turns an. Nachrichten-Listener übergeben sofort, und eingereihte Discord-Läufe bewahren die Reihenfolge pro Sitzung, bis der Sitzungs-/Tool-/Runtime-Lebenszyklus abgeschlossen ist oder die Arbeit abbricht. ```json5 { @@ -1280,53 +1299,53 @@ openclaw logs --follow - - OpenClaw ruft Discord-`/gateway/bot`-Metadaten vor dem Verbindungsaufbau ab. Vorübergehende Fehler fallen auf die Standard-Gateway-URL von Discord zurück und werden in Protokollen rate-limitiert. + + OpenClaw ruft Discord-`/gateway/bot`-Metadaten vor dem Verbindungsaufbau ab. Vorübergehende Fehler fallen auf Discords Standard-Gateway-URL zurück und werden in den Logs ratenbegrenzt. - Metadaten-Timeout-Optionen: + Metadaten-Timeout-Schalter: - Einzelkonto: `channels.discord.gatewayInfoTimeoutMs` - - Mehrkonto: `channels.discord.accounts..gatewayInfoTimeoutMs` + - Mehrfachkonto: `channels.discord.accounts..gatewayInfoTimeoutMs` - Env-Fallback, wenn die Konfiguration nicht gesetzt ist: `OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS` - - Standard: `30000` (30 Sekunden), Maximum: `120000` + - Standard: `30000` (30 Sekunden), max.: `120000` - OpenClaw wartet beim Start und nach Laufzeit-Neuverbindungen auf Discords Gateway-Ereignis `READY`. Multi-Account-Setups mit gestaffeltem Start können ein längeres READY-Startfenster benötigen als den Standardwert. + OpenClaw wartet während des Starts und nach Runtime-Reconnects auf Discords Gateway-`READY`-Ereignis. Mehrfachkonto-Setups mit gestaffeltem Start können ein längeres READY-Startfenster benötigen als der Standard. - READY-Timeout-Einstellungen: + READY-Timeout-Schalter: - - Start einzelnes Konto: `channels.discord.gatewayReadyTimeoutMs` - - Start Multi-Account: `channels.discord.accounts..gatewayReadyTimeoutMs` + - Start Einzelkonto: `channels.discord.gatewayReadyTimeoutMs` + - Start Mehrfachkonto: `channels.discord.accounts..gatewayReadyTimeoutMs` - Start-Env-Fallback, wenn die Konfiguration nicht gesetzt ist: `OPENCLAW_DISCORD_READY_TIMEOUT_MS` - - Start-Standardwert: `15000` (15 Sekunden), max.: `120000` - - Laufzeit einzelnes Konto: `channels.discord.gatewayRuntimeReadyTimeoutMs` - - Laufzeit Multi-Account: `channels.discord.accounts..gatewayRuntimeReadyTimeoutMs` - - Laufzeit-Env-Fallback, wenn die Konfiguration nicht gesetzt ist: `OPENCLAW_DISCORD_RUNTIME_READY_TIMEOUT_MS` - - Laufzeit-Standardwert: `30000` (30 Sekunden), max.: `120000` + - Startstandard: `15000` (15 Sekunden), max.: `120000` + - Runtime Einzelkonto: `channels.discord.gatewayRuntimeReadyTimeoutMs` + - Runtime Mehrfachkonto: `channels.discord.accounts..gatewayRuntimeReadyTimeoutMs` + - Runtime-Env-Fallback, wenn die Konfiguration nicht gesetzt ist: `OPENCLAW_DISCORD_RUNTIME_READY_TIMEOUT_MS` + - Runtime-Standard: `30000` (30 Sekunden), max.: `120000` Berechtigungsprüfungen mit `channels status --probe` funktionieren nur für numerische Kanal-IDs. - Wenn Sie Slug-Schlüssel verwenden, kann der Laufzeitabgleich weiterhin funktionieren, aber die Prüfung kann Berechtigungen nicht vollständig verifizieren. + Wenn Sie Slug-Schlüssel verwenden, kann der Runtime-Abgleich weiterhin funktionieren, aber Probe kann Berechtigungen nicht vollständig verifizieren. - + - DM deaktiviert: `channels.discord.dm.enabled=false` - DM-Richtlinie deaktiviert: `channels.discord.dmPolicy="disabled"` (Legacy: `channels.discord.dm.policy`) - - Warten auf Pairing-Genehmigung im Modus `pairing` + - wartet im Modus `pairing` auf Kopplungsgenehmigung Standardmäßig werden von Bots verfasste Nachrichten ignoriert. - Wenn Sie `channels.discord.allowBots=true` festlegen, verwenden Sie strenge Erwähnungs- und Allowlist-Regeln, um Schleifenverhalten zu vermeiden. + Wenn Sie `channels.discord.allowBots=true` setzen, verwenden Sie strenge Erwähnungs- und Allowlist-Regeln, um Schleifenverhalten zu vermeiden. Bevorzugen Sie `channels.discord.allowBots="mentions"`, um nur Bot-Nachrichten zu akzeptieren, die den Bot erwähnen. ```json5 @@ -1356,13 +1375,13 @@ openclaw logs --follow - - halten Sie OpenClaw aktuell (`openclaw update`), damit die Wiederherstellungslogik für den Empfang von Discord-Sprachdaten vorhanden ist + - halten Sie OpenClaw aktuell (`openclaw update`), damit die Wiederherstellungslogik für Discord-Voice-Empfang vorhanden ist - bestätigen Sie `channels.discord.voice.daveEncryption=true` (Standard) - beginnen Sie mit `channels.discord.voice.decryptionFailureTolerance=24` (Upstream-Standard) und passen Sie den Wert nur bei Bedarf an - - beobachten Sie die Logs auf: + - achten Sie in den Logs auf: - `discord voice: DAVE decrypt failures detected` - `discord voice: repeated decrypt failures; attempting rejoin` - - wenn die Fehler nach dem automatischen erneuten Beitreten weiterhin auftreten, sammeln Sie Logs und vergleichen Sie sie mit der Upstream-DAVE-Empfangshistorie in [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) und [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) + - wenn die Fehler nach dem automatischen erneuten Beitritt weiter auftreten, sammeln Sie Logs und vergleichen Sie sie mit der Upstream-DAVE-Empfangshistorie in [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) und [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) @@ -1371,7 +1390,7 @@ openclaw logs --follow Primäre Referenz: [Konfigurationsreferenz - Discord](/de/gateway/config-channels#discord). - + - Start/Auth: `enabled`, `token`, `accounts.*`, `allowBots` - Richtlinie: `groupPolicy`, `dm.*`, `guilds.*`, `guilds.*.channels.*` @@ -1385,20 +1404,20 @@ Primäre Referenz: [Konfigurationsreferenz - Discord](/de/gateway/config-channel - Aktionen: `actions.*` - Präsenz: `activity`, `status`, `activityType`, `activityUrl` - UI: `ui.components.accentColor` -- Funktionen: `threadBindings`, Top-Level-`bindings[]` (`type: "acp"`), `pluralkit`, `execApprovals`, `intents`, `agentComponents`, `heartbeat`, `responsePrefix` +- Funktionen: `threadBindings`, oberste Ebene `bindings[]` (`type: "acp"`), `pluralkit`, `execApprovals`, `intents`, `agentComponents`, `heartbeat`, `responsePrefix` ## Sicherheit und Betrieb - Behandeln Sie Bot-Token als Geheimnisse (`DISCORD_BOT_TOKEN` wird in überwachten Umgebungen bevorzugt). -- Gewähren Sie Discord-Berechtigungen nach dem Prinzip der geringsten Rechte. -- Wenn Befehlsbereitstellung oder -zustand veraltet ist, starten Sie das Gateway neu und prüfen Sie erneut mit `openclaw channels status --probe`. +- Erteilen Sie Discord-Berechtigungen nach dem Least-Privilege-Prinzip. +- Wenn Befehlsbereitstellung oder -status veraltet sind, starten Sie das Gateway neu und prüfen Sie erneut mit `openclaw channels status --probe`. -## Verwandt +## Verwandte Themen - + Koppeln Sie einen Discord-Benutzer mit dem Gateway. @@ -1414,6 +1433,6 @@ Primäre Referenz: [Konfigurationsreferenz - Discord](/de/gateway/config-channel Ordnen Sie Guilds und Kanäle Agenten zu. - Verhalten nativer Befehle. + Natives Befehlsverhalten. diff --git a/docs/de/channels/slack.md b/docs/de/channels/slack.md index 27d9fe220..6ecbc83ef 100644 --- a/docs/de/channels/slack.md +++ b/docs/de/channels/slack.md @@ -1,13 +1,13 @@ --- read_when: - Slack einrichten oder den Slack-Socket-/HTTP-Modus debuggen -summary: Einrichtung von Slack und Laufzeitverhalten (Socket Mode + HTTP Request URLs) +summary: Slack-Einrichtung und Laufzeitverhalten (Socket Mode + HTTP-Anfrage-URLs) title: Slack x-i18n: - generated_at: "2026-05-04T02:22:13Z" + generated_at: "2026-05-04T07:02:50Z" model: gpt-5.5 provider: openai - source_hash: 2be45f03511a64373b1f4316c59800eeeef8baccb4c00454b49999258b2e546b + source_hash: d4a91fc1ae5f1e03f714308be54e164ef204809e74efabed8dc75c3035c14228 source_path: channels/slack.md workflow: 16 --- @@ -15,33 +15,33 @@ x-i18n: Produktionsbereit für DMs und Channels über Slack-App-Integrationen. Der Standardmodus ist Socket Mode; HTTP Request URLs werden ebenfalls unterstützt. - - Slack-DMs verwenden standardmäßig den Kopplungsmodus. + + Slack-DMs verwenden standardmäßig den Pairing-Modus. - + Natives Befehlsverhalten und Befehlskatalog. - + Channel-übergreifende Diagnose- und Reparatur-Playbooks. -## Schnelleinrichtung +## Schnelle Einrichtung - + - + Drücken Sie in den Slack-App-Einstellungen die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**: - wählen Sie **from a manifest** und wählen Sie einen Workspace für Ihre App aus - - fügen Sie das [Beispielmanifest](#manifest-and-scope-checklist) unten ein und fahren Sie mit der Erstellung fort + - fügen Sie das [Beispielmanifest](#manifest-and-scope-checklist) unten ein und fahren Sie mit dem Erstellen fort - generieren Sie ein **App-Level Token** (`xapp-...`) mit `connections:write` - installieren Sie die App und kopieren Sie das angezeigte **Bot Token** (`xoxb-...`) - + Empfohlene SecretRef-Einrichtung: @@ -73,7 +73,7 @@ SLACK_BOT_TOKEN=xoxb-... - + ```bash openclaw gateway @@ -86,17 +86,17 @@ openclaw gateway - + Drücken Sie in den Slack-App-Einstellungen die Schaltfläche **[Create New App](https://api.slack.com/apps/new)**: - wählen Sie **from a manifest** und wählen Sie einen Workspace für Ihre App aus - fügen Sie das [Beispielmanifest](#manifest-and-scope-checklist) ein und aktualisieren Sie die URLs vor dem Erstellen - - speichern Sie das **Signing Secret** für die Anfrageverifizierung + - speichern Sie das **Signing Secret** für die Anforderungsprüfung - installieren Sie die App und kopieren Sie das angezeigte **Bot Token** (`xoxb-...`) - + Empfohlene SecretRef-Einrichtung: @@ -123,12 +123,12 @@ openclaw config patch --file ./slack.http.patch.json5 Verwenden Sie eindeutige Webhook-Pfade für HTTP mit mehreren Konten - Geben Sie jedem Konto einen eigenen `webhookPath` (Standard `/slack/events`), damit Registrierungen nicht kollidieren. + Geben Sie jedem Konto einen eigenen `webhookPath` (Standard: `/slack/events`), damit Registrierungen nicht kollidieren. - + ```bash openclaw gateway @@ -140,9 +140,9 @@ openclaw gateway -## Transport-Feinabstimmung für Socket Mode +## Transport-Tuning für Socket Mode -OpenClaw setzt das Pong-Timeout des Slack-SDK-Clients für Socket Mode standardmäßig auf 15 Sekunden. Überschreiben Sie die Transporteinstellungen nur, wenn Sie Workspace- oder Host-spezifische Feinabstimmung benötigen: +OpenClaw setzt das Pong-Timeout des Slack-SDK-Clients standardmäßig auf 15 Sekunden für Socket Mode. Überschreiben Sie die Transporteinstellungen nur, wenn Sie workspace- oder hostspezifisches Tuning benötigen: ```json5 { @@ -159,11 +159,11 @@ OpenClaw setzt das Pong-Timeout des Slack-SDK-Clients für Socket Mode standardm } ``` -Verwenden Sie dies nur für Socket-Mode-Workspaces, die Slack-WebSocket-Pong-/Server-Ping-Timeouts protokollieren, oder für Hosts mit bekannter Event-Loop-Starvation. `clientPingTimeout` ist die Wartezeit auf Pong, nachdem das SDK einen Client-Ping sendet; `serverPingTimeout` ist die Wartezeit auf Slack-Server-Pings. App-Nachrichten und Events bleiben Anwendungszustand, keine Signale für Transport-Liveness. +Verwenden Sie dies nur für Socket-Mode-Workspaces, die Slack-WebSocket-Pong- oder Server-Ping-Timeouts protokollieren oder auf Hosts mit bekannter Event-Loop-Überlastung laufen. `clientPingTimeout` ist die Pong-Wartezeit, nachdem das SDK einen Client-Ping gesendet hat; `serverPingTimeout` ist die Wartezeit auf Slack-Server-Pings. App-Nachrichten und Events bleiben Anwendungsstatus, keine Signale für die Transportverfügbarkeit. ## Manifest- und Scope-Checkliste -Das Basismanifest der Slack-App ist für Socket Mode und HTTP Request URLs gleich. Nur der Block `settings` (und die Slash-Befehls-`url`) unterscheidet sich. +Das Basismanifest der Slack-App ist für Socket Mode und HTTP Request URLs identisch. Nur der Block `settings` (und die Slash-Command-`url`) unterscheidet sich. Basismanifest (Socket Mode als Standard): @@ -240,7 +240,7 @@ Basismanifest (Socket Mode als Standard): } ``` -Ersetzen Sie für den Modus **HTTP Request URLs** `settings` durch die HTTP-Variante und fügen Sie jedem Slash-Befehl `url` hinzu. Öffentliche URL erforderlich: +Für den Modus **HTTP Request URLs** ersetzen Sie `settings` durch die HTTP-Variante und fügen jedem Slash Command `url` hinzu. Öffentliche URL erforderlich: ```json { @@ -284,22 +284,22 @@ Ersetzen Sie für den Modus **HTTP Request URLs** `settings` durch die HTTP-Vari ### Zusätzliche Manifest-Einstellungen -Aktivieren Sie unterschiedliche Funktionen, die die obigen Standards erweitern. +Aktivieren Sie verschiedene Funktionen, die die obigen Standardwerte erweitern. -Das Standardmanifest aktiviert den Tab Slack App Home **Home** und abonniert `app_home_opened`. Wenn ein Workspace-Mitglied den Home-Tab öffnet, veröffentlicht OpenClaw mit `views.publish` eine sichere Standard-Home-Ansicht; es werden keine Konversations-Payloads oder private Konfigurationen einbezogen. Der Tab **Messages** bleibt für Slack-DMs aktiviert. +Das Standardmanifest aktiviert den Slack-App-Home-Tab **Home** und abonniert `app_home_opened`. Wenn ein Workspace-Mitglied den Home-Tab öffnet, veröffentlicht OpenClaw mit `views.publish` eine sichere Standard-Home-Ansicht; keine Konversations-Payload oder private Konfiguration wird einbezogen. Der Tab **Messages** bleibt für Slack-DMs aktiviert. - + - Mehrere [native Slash-Befehle](#commands-and-slash-behavior) können statt eines einzelnen konfigurierten Befehls mit differenziertem Verhalten verwendet werden: + Mehrere [native Slash Commands](#commands-and-slash-behavior) können anstelle eines einzelnen konfigurierten Befehls mit Nuancen verwendet werden: - Verwenden Sie `/agentstatus` statt `/status`, da der Befehl `/status` reserviert ist. - - Es können höchstens 25 Slash-Befehle gleichzeitig verfügbar gemacht werden. + - Es können nicht mehr als 25 Slash Commands gleichzeitig verfügbar gemacht werden. Ersetzen Sie Ihren vorhandenen Abschnitt `features.slash_commands` durch eine Teilmenge der [verfügbaren Befehle](/de/tools/slash-commands#command-list): - + ```json { @@ -443,19 +443,19 @@ Das Standardmanifest aktiviert den Tab Slack App Home **Home** und abonniert `ap } ``` - Wiederholen Sie diesen `url`-Wert für jeden Befehl in der Liste. + Wiederholen Sie diesen `url`-Wert bei jedem Befehl in der Liste. - - Fügen Sie den Bot-Scope `chat:write.customize` hinzu, wenn ausgehende Nachrichten die aktive Agent-Identität (benutzerdefinierter Benutzername und Icon) statt der Standardidentität der Slack-App verwenden sollen. + + Fügen Sie den Bot-Scope `chat:write.customize` hinzu, wenn ausgehende Nachrichten die aktive Agentenidentität (benutzerdefinierter Benutzername und Icon) statt der standardmäßigen Slack-App-Identität verwenden sollen. Wenn Sie ein Emoji-Icon verwenden, erwartet Slack die Syntax `:emoji_name:`. - + Wenn Sie `channels.slack.userToken` konfigurieren, sind typische Lese-Scopes: - `channels:history`, `groups:history`, `im:history`, `mpim:history` @@ -464,56 +464,56 @@ Das Standardmanifest aktiviert den Tab Slack App Home **Home** und abonniert `ap - `reactions:read` - `pins:read` - `emoji:read` - - `search:read` (wenn Sie auf Lesezugriffe über die Slack-Suche angewiesen sind) + - `search:read` (wenn Sie von Slack-Suchvorgängen zum Lesen abhängen) ## Token-Modell -- `botToken` + `appToken` sind für den Socket Mode erforderlich. +- `botToken` + `appToken` sind für Socket Mode erforderlich. - Der HTTP-Modus erfordert `botToken` + `signingSecret`. - `botToken`, `appToken`, `signingSecret` und `userToken` akzeptieren Klartext- - Zeichenfolgen oder SecretRef-Objekte. + Strings oder SecretRef-Objekte. - Konfigurations-Token überschreiben den Env-Fallback. - Der Env-Fallback `SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN` gilt nur für das Standardkonto. -- `userToken` (`xoxp-...`) ist nur per Konfiguration verfügbar (kein Env-Fallback) und nutzt standardmäßig schreibgeschütztes Verhalten (`userTokenReadOnly: true`). +- `userToken` (`xoxp-...`) ist ausschließlich konfigurierbar (kein Env-Fallback) und nutzt standardmäßig schreibgeschütztes Verhalten (`userTokenReadOnly: true`). Verhalten des Status-Snapshots: -- Die Slack-Kontoprüfung verfolgt pro Zugangsdaten `*Source`- und `*Status`- +- Die Slack-Kontoprüfung verfolgt pro Anmeldeinformation `*Source`- und `*Status`- Felder (`botToken`, `appToken`, `signingSecret`, `userToken`). - Der Status ist `available`, `configured_unavailable` oder `missing`. - `configured_unavailable` bedeutet, dass das Konto über SecretRef - oder eine andere nicht inline angegebene Secret-Quelle konfiguriert ist, der aktuelle Befehls-/Laufzeitpfad + oder eine andere nicht inline angegebene Secret-Quelle konfiguriert ist, der aktuelle Befehls-/Runtime-Pfad den tatsächlichen Wert aber nicht auflösen konnte. -- Im HTTP-Modus ist `signingSecretStatus` enthalten; im Socket Mode ist das +- Im HTTP-Modus ist `signingSecretStatus` enthalten; in Socket Mode ist das erforderliche Paar `botTokenStatus` + `appTokenStatus`. -Für Aktionen/Verzeichnis-Lesezugriffe kann das Benutzer-Token bevorzugt werden, wenn es konfiguriert ist. Für Schreibzugriffe bleibt das Bot-Token bevorzugt; Schreibzugriffe mit Benutzer-Token sind nur erlaubt, wenn `userTokenReadOnly: false` gesetzt ist und das Bot-Token nicht verfügbar ist. +Für Aktionen/Verzeichnis-Lesevorgänge kann das Benutzer-Token bevorzugt werden, wenn es konfiguriert ist. Für Schreibvorgänge bleibt das Bot-Token bevorzugt; Schreibvorgänge mit Benutzer-Token sind nur erlaubt, wenn `userTokenReadOnly: false` gesetzt ist und das Bot-Token nicht verfügbar ist. ## Aktionen und Gates -Slack-Aktionen werden über `channels.slack.actions.*` gesteuert. +Slack-Aktionen werden durch `channels.slack.actions.*` gesteuert. Verfügbare Aktionsgruppen im aktuellen Slack-Tooling: -| Gruppe | Standard | -| ---------- | --------- | +| Gruppe | Standard | +| ---------- | -------- | | messages | aktiviert | | reactions | aktiviert | | pins | aktiviert | | memberInfo | aktiviert | | emojiList | aktiviert | -Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` und `emoji-list`. `download-file` akzeptiert Slack-Datei-IDs, die in eingehenden Datei-Platzhaltern angezeigt werden, und gibt Bildvorschauen für Bilder oder lokale Dateimetadaten für andere Dateitypen zurück. +Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-file`, `read`, `edit`, `delete`, `pin`, `unpin`, `list-pins`, `member-info` und `emoji-list`. `download-file` akzeptiert Slack-Datei-IDs, die in Platzhaltern für eingehende Dateien angezeigt werden, und gibt Bildvorschauen für Bilder oder lokale Dateimetadaten für andere Dateitypen zurück. ## Zugriffskontrolle und Routing - + `channels.slack.dmPolicy` steuert den DM-Zugriff. `channels.slack.allowFrom` ist die kanonische DM-Allowlist. - `pairing` (Standard) @@ -529,7 +529,7 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil - `dm.groupEnabled` (Gruppen-DMs standardmäßig false) - `dm.groupChannels` (optionale MPIM-Allowlist) - Priorität bei mehreren Konten: + Vorrang bei mehreren Konten: - `channels.slack.accounts.default.allowFrom` gilt nur für das Konto `default`. - Benannte Konten erben `channels.slack.allowFrom`, wenn ihr eigenes `allowFrom` nicht gesetzt ist. @@ -541,7 +541,7 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil - + `channels.slack.groupPolicy` steuert die Kanalbehandlung: - `open` @@ -550,18 +550,18 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil Die Kanal-Allowlist befindet sich unter `channels.slack.channels` und **muss stabile Slack-Kanal-IDs** (zum Beispiel `C12345678`) als Konfigurationsschlüssel verwenden. - Laufzeithinweis: Wenn `channels.slack` vollständig fehlt (reines Env-Setup), fällt die Laufzeit auf `groupPolicy="allowlist"` zurück und protokolliert eine Warnung (auch wenn `channels.defaults.groupPolicy` gesetzt ist). + Runtime-Hinweis: Wenn `channels.slack` vollständig fehlt (nur Env-Einrichtung), fällt die Runtime auf `groupPolicy="allowlist"` zurück und protokolliert eine Warnung (auch wenn `channels.defaults.groupPolicy` gesetzt ist). Namens-/ID-Auflösung: - - Einträge in Kanal-Allowlists und DM-Allowlists werden beim Start aufgelöst, wenn der Token-Zugriff dies erlaubt - - nicht aufgelöste Kanalnamen-Einträge bleiben wie konfiguriert erhalten, werden aber standardmäßig für das Routing ignoriert - - eingehende Autorisierung und Kanal-Routing sind standardmäßig ID-first; direkter Benutzername-/Slug-Abgleich erfordert `channels.slack.dangerouslyAllowNameMatching: true` + - Kanal-Allowlist-Einträge und DM-Allowlist-Einträge werden beim Start aufgelöst, wenn der Token-Zugriff dies erlaubt + - Nicht aufgelöste Kanalnamen-Einträge werden wie konfiguriert beibehalten, aber standardmäßig für Routing ignoriert + - Eingehende Autorisierung und Kanal-Routing sind standardmäßig ID-first; direkter Benutzername-/Slug-Abgleich erfordert `channels.slack.dangerouslyAllowNameMatching: true` - Namensbasierte Schlüssel (`#channel-name` oder `channel-name`) stimmen unter `groupPolicy: "allowlist"` **nicht** überein. Die Kanalauflösung ist standardmäßig ID-first, daher wird ein namensbasierter Schlüssel nie erfolgreich routen und alle Nachrichten in diesem Kanal werden stillschweigend blockiert. Dies unterscheidet sich von `groupPolicy: "open"`, wo der Kanalschlüssel für das Routing nicht erforderlich ist und ein namensbasierter Schlüssel zu funktionieren scheint. + Namensbasierte Schlüssel (`#channel-name` oder `channel-name`) passen unter `groupPolicy: "allowlist"` **nicht**. Die Kanalsuche ist standardmäßig ID-first, daher wird ein namensbasierter Schlüssel niemals erfolgreich routen, und alle Nachrichten in diesem Kanal werden still blockiert. Dies unterscheidet sich von `groupPolicy: "open"`, wo der Kanalschlüssel für das Routing nicht erforderlich ist und ein namensbasierter Schlüssel scheinbar funktioniert. - Verwenden Sie immer die Slack-Kanal-ID als Schlüssel. So finden Sie sie: Klicken Sie mit der rechten Maustaste auf den Kanal in Slack → **Link kopieren** — die ID (`C...`) steht am Ende der URL. + Verwenden Sie immer die Slack-Kanal-ID als Schlüssel. So finden Sie sie: Klicken Sie in Slack mit der rechten Maustaste auf den Kanal → **Link kopieren** — die ID (`C...`) erscheint am Ende der URL. Richtig: @@ -578,7 +578,7 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil } ``` - Falsch (unter `groupPolicy: "allowlist"` stillschweigend blockiert): + Incorrect (unter `groupPolicy: "allowlist"` stillschweigend blockiert): ```json5 { @@ -597,7 +597,7 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil - Kanalnachrichten sind standardmäßig durch Erwähnungen geschützt. + Channel-Nachrichten sind standardmäßig durch Erwähnungen geschützt. Erwähnungsquellen: @@ -606,7 +606,7 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil - Erwähnungs-Regex-Muster (`agents.list[].groupChat.mentionPatterns`, Fallback `messages.groupChat.mentionPatterns`) - implizites Antwort-an-Bot-Thread-Verhalten (deaktiviert, wenn `thread.requireExplicitMention` `true` ist) - Kanalbezogene Steuerelemente (`channels.slack.channels.`; Namen nur über Startauflösung oder `dangerouslyAllowNameMatching`): + Steuerungen pro Channel (`channels.slack.channels.`; Namen nur über Auflösung beim Start oder `dangerouslyAllowNameMatching`): - `requireMention` - `users` (Allowlist) @@ -615,29 +615,29 @@ Aktuelle Slack-Nachrichtenaktionen umfassen `send`, `upload-file`, `download-fil - `systemPrompt` - `tools`, `toolsBySender` - Schlüsselformat für `toolsBySender`: `id:`, `e164:`, `username:`, `name:` oder Platzhalter `"*"` - (Legacy-Schlüssel ohne Präfix werden weiterhin nur `id:` zugeordnet) + (veraltete Schlüssel ohne Präfix werden weiterhin nur `id:` zugeordnet) - `allowBots` ist für Kanäle und private Kanäle konservativ: Von Bots verfasste Raumnachrichten werden nur akzeptiert, wenn der sendende Bot explizit in der `users`-Allowlist dieses Raums aufgeführt ist oder wenn mindestens eine explizite Slack-Owner-ID aus `channels.slack.allowFrom` aktuell ein Raummitglied ist. Platzhalter und Owner-Einträge mit Anzeigenamen erfüllen die Owner-Anwesenheit nicht. Owner-Anwesenheit verwendet Slack `conversations.members`; stellen Sie sicher, dass die App den passenden Lese-Scope für den Raumtyp hat (`channels:read` für öffentliche Kanäle, `groups:read` für private Kanäle). Wenn die Mitgliederabfrage fehlschlägt, verwirft OpenClaw die von einem Bot verfasste Raumnachricht. + `allowBots` ist für Channels und private Channels konservativ: Von Bots verfasste Raumnachrichten werden nur akzeptiert, wenn der sendende Bot explizit in der `users`-Allowlist dieses Raums aufgeführt ist oder wenn mindestens eine explizite Slack-Owner-ID aus `channels.slack.allowFrom` aktuell Mitglied des Raums ist. Platzhalter und Owner-Einträge mit Anzeigenamen erfüllen die Owner-Präsenz nicht. Die Owner-Präsenz verwendet Slack `conversations.members`; stellen Sie sicher, dass die App den passenden Lese-Scope für den Raumtyp hat (`channels:read` für öffentliche Channels, `groups:read` für private Channels). Wenn die Mitgliedersuche fehlschlägt, verwirft OpenClaw die von einem Bot verfasste Raumnachricht. -## Threads, Sitzungen und Antwort-Tags +## Threading, Sitzungen und Antwort-Tags -- DMs werden als `direct` geroutet; Kanäle als `channel`; MPIMs als `group`. -- Slack-Routenbindungen akzeptieren unverarbeitete Peer-IDs sowie Slack-Zielformen wie `channel:C12345678`, `user:U12345678` und `<@U12345678>`. +- DMs werden als `direct` geroutet; Channels als `channel`; MPIMs als `group`. +- Slack-Routenbindungen akzeptieren rohe Peer-IDs sowie Slack-Zielformen wie `channel:C12345678`, `user:U12345678` und `<@U12345678>`. - Mit dem Standard `session.dmScope=main` werden Slack-DMs auf die Hauptsitzung des Agenten zusammengeführt. -- Kanalsitzungen: `agent::slack:channel:`. -- Thread-Antworten können, wenn zutreffend, Thread-Sitzungssuffixe (`:thread:`) erzeugen. +- Channel-Sitzungen: `agent::slack:channel:`. +- Thread-Antworten können, wenn anwendbar, Thread-Sitzungssuffixe erstellen (`:thread:`). - Der Standard für `channels.slack.thread.historyScope` ist `thread`; der Standard für `thread.inheritParent` ist `false`. - `channels.slack.thread.initialHistoryLimit` steuert, wie viele vorhandene Thread-Nachrichten abgerufen werden, wenn eine neue Thread-Sitzung startet (Standard `20`; setzen Sie `0`, um dies zu deaktivieren). -- `channels.slack.thread.requireExplicitMention` (Standard `false`): Wenn `true`, werden implizite Thread-Erwähnungen unterdrückt, sodass der Bot nur auf explizite `@bot`-Erwähnungen innerhalb von Threads reagiert, selbst wenn der Bot bereits am Thread teilgenommen hat. Ohne dies umgehen Antworten in einem Thread mit Bot-Beteiligung das `requireMention`-Gate. +- `channels.slack.thread.requireExplicitMention` (Standard `false`): Wenn `true`, werden implizite Thread-Erwähnungen unterdrückt, sodass der Bot innerhalb von Threads nur auf explizite `@bot`-Erwähnungen antwortet, selbst wenn der Bot bereits am Thread teilgenommen hat. Ohne dies umgehen Antworten in einem Thread mit Bot-Beteiligung die `requireMention`-Prüfung. -Steuerung des Antwort-Threadings: +Steuerungen für Antwort-Threading: - `channels.slack.replyToMode`: `off|first|all|batched` (Standard `off`) - `channels.slack.replyToModeByChatType`: pro `direct|group|channel` -- Legacy-Fallback für direkte Chats: `channels.slack.dm.replyToMode` +- veralteter Fallback für direkte Chats: `channels.slack.dm.replyToMode` Manuelle Antwort-Tags werden unterstützt: @@ -645,10 +645,10 @@ Manuelle Antwort-Tags werden unterstützt: - `[[reply_to:]]` -`replyToMode="off"` deaktiviert **alles** Antwort-Threading in Slack, einschließlich expliziter `[[reply_to_*]]`-Tags. Dies unterscheidet sich von Telegram, wo explizite Tags im Modus `"off"` weiterhin beachtet werden. Slack-Threads verbergen Nachrichten vor dem Kanal, während Telegram-Antworten inline sichtbar bleiben. +`replyToMode="off"` deaktiviert **alles** Antwort-Threading in Slack, einschließlich expliziter `[[reply_to_*]]`-Tags. Dies unterscheidet sich von Telegram, wo explizite Tags im Modus `"off"` weiterhin beachtet werden. Slack-Threads verbergen Nachrichten aus dem Channel, während Telegram-Antworten inline sichtbar bleiben. -## Ack-Reaktionen +## Bestätigungsreaktionen `ackReaction` sendet ein Bestätigungs-Emoji, während OpenClaw eine eingehende Nachricht verarbeitet. @@ -657,7 +657,7 @@ Auflösungsreihenfolge: - `channels.slack.accounts..ackReaction` - `channels.slack.ackReaction` - `messages.ackReaction` -- Emoji-Fallback der Agent-Identität (`agents.list[].identity.emoji`, sonst "👀") +- Fallback auf Emoji der Agentenidentität (`agents.list[].identity.emoji`, sonst "👀") Hinweise: @@ -666,24 +666,43 @@ Hinweise: ## Text-Streaming -`channels.slack.streaming` steuert das Live-Vorschauverhalten: +`channels.slack.streaming` steuert das Verhalten der Live-Vorschau: - `off`: Live-Vorschau-Streaming deaktivieren. - `partial` (Standard): Vorschautext durch die neueste Teilausgabe ersetzen. -- `block`: Vorschauaktualisierungen in Chunks anhängen. -- `progress`: Fortschrittsstatustext während der Generierung anzeigen und anschließend den endgültigen Text senden. -- `streaming.preview.toolProgress`: Wenn die Entwurfsvorschau aktiv ist, werden Tool-/Fortschrittsaktualisierungen in dieselbe bearbeitete Vorschaunachricht geroutet (Standard: `true`). Setzen Sie `false`, um separate Tool-/Fortschrittsnachrichten beizubehalten. +- `block`: Vorschauaktualisierungen in Blöcken anhängen. +- `progress`: Fortschrittsstatustext während der Generierung anzeigen, dann finalen Text senden. +- `streaming.preview.toolProgress`: Wenn die Entwurfsvorschau aktiv ist, Tool-/Fortschrittsaktualisierungen in dieselbe bearbeitete Vorschau-Nachricht routen (Standard: `true`). Setzen Sie dies auf `false`, um separate Tool-/Fortschrittsnachrichten beizubehalten. +- `streaming.preview.commandText` / `streaming.progress.commandText`: Auf `status` setzen, um kompakte Tool-Fortschrittszeilen beizubehalten und gleichzeitig rohen Befehls-/Ausführungstext auszublenden (Standard: `raw`). -`channels.slack.streaming.nativeTransport` steuert Slack-natives Text-Streaming, wenn `channels.slack.streaming.mode` `partial` ist (Standard: `true`). +Rohen Befehls-/Ausführungstext ausblenden und kompakte Fortschrittszeilen beibehalten: -- Ein Antwort-Thread muss verfügbar sein, damit natives Text-Streaming und der Slack-Assistent-Thread-Status angezeigt werden. Die Thread-Auswahl folgt weiterhin `replyToMode`. -- Kanal-, Gruppenchat- und Top-Level-DM-Wurzeln können weiterhin die normale Entwurfsvorschau verwenden, wenn natives Streaming nicht verfügbar ist oder kein Antwort-Thread existiert. -- Top-Level-Slack-DMs bleiben standardmäßig außerhalb von Threads, daher zeigen sie nicht Slacks Thread-artige native Stream-/Statusvorschau; OpenClaw postet und bearbeitet stattdessen eine Entwurfsvorschau in der DM. +```json +{ + "channels": { + "slack": { + "streaming": { + "mode": "progress", + "progress": { + "toolProgress": true, + "commandText": "status" + } + } + } + } +} +``` + +`channels.slack.streaming.nativeTransport` steuert natives Slack-Text-Streaming, wenn `channels.slack.streaming.mode` `partial` ist (Standard: `true`). + +- Für natives Text-Streaming und den Slack-Assistenten-Threadstatus muss ein Antwort-Thread verfügbar sein. Die Thread-Auswahl folgt weiterhin `replyToMode`. +- Channel-, Gruppenchat- und Top-Level-DM-Wurzeln können weiterhin die normale Entwurfsvorschau verwenden, wenn natives Streaming nicht verfügbar ist oder kein Antwort-Thread existiert. +- Top-Level-Slack-DMs bleiben standardmäßig außerhalb von Threads, daher zeigen sie keine native Stream-/Statusvorschau im Thread-Stil von Slack an; OpenClaw postet und bearbeitet stattdessen eine Entwurfsvorschau in der DM. - Medien und Nicht-Text-Payloads fallen auf normale Zustellung zurück. -- Medien-/Fehler-Endausgaben brechen ausstehende Vorschau-Bearbeitungen ab; geeignete Text-/Block-Endausgaben werden nur ausgespielt, wenn sie die Vorschau direkt bearbeiten können. -- Wenn Streaming mitten in einer Antwort fehlschlägt, fällt OpenClaw für verbleibende Payloads auf normale Zustellung zurück. +- Medien-/Fehler-Finals brechen ausstehende Vorschau-Bearbeitungen ab; geeignete Text-/Block-Finals werden nur geleert, wenn sie die Vorschau direkt bearbeiten können. +- Wenn Streaming mitten in der Antwort fehlschlägt, fällt OpenClaw für verbleibende Payloads auf normale Zustellung zurück. -Entwurfsvorschau statt Slack-nativem Text-Streaming verwenden: +Entwurfsvorschau statt nativem Slack-Text-Streaming verwenden: ```json5 { @@ -698,15 +717,15 @@ Entwurfsvorschau statt Slack-nativem Text-Streaming verwenden: } ``` -Legacy-Schlüssel: +Veraltete Schlüssel: - `channels.slack.streamMode` (`replace | status_final | append`) wird automatisch zu `channels.slack.streaming.mode` migriert. -- Der boolesche Wert `channels.slack.streaming` wird automatisch zu `channels.slack.streaming.mode` und `channels.slack.streaming.nativeTransport` migriert. -- Legacy-`channels.slack.nativeStreaming` wird automatisch zu `channels.slack.streaming.nativeTransport` migriert. +- Boolesches `channels.slack.streaming` wird automatisch zu `channels.slack.streaming.mode` und `channels.slack.streaming.nativeTransport` migriert. +- Veraltetes `channels.slack.nativeStreaming` wird automatisch zu `channels.slack.streaming.nativeTransport` migriert. ## Fallback für Tippreaktion -`typingReaction` fügt der eingehenden Slack-Nachricht eine temporäre Reaktion hinzu, während OpenClaw eine Antwort verarbeitet, und entfernt sie anschließend, wenn der Lauf abgeschlossen ist. Dies ist vor allem außerhalb von Thread-Antworten nützlich, die einen standardmäßigen Statusindikator „is typing...“ verwenden. +`typingReaction` fügt der eingehenden Slack-Nachricht eine temporäre Reaktion hinzu, während OpenClaw eine Antwort verarbeitet, und entfernt sie anschließend, wenn der Lauf abgeschlossen ist. Dies ist vor allem außerhalb von Thread-Antworten nützlich, die standardmäßig eine Statusanzeige „is typing...“ verwenden. Auflösungsreihenfolge: @@ -716,25 +735,25 @@ Auflösungsreihenfolge: Hinweise: - Slack erwartet Shortcodes (zum Beispiel `"hourglass_flowing_sand"`). -- Die Reaktion erfolgt nach Best-Effort-Prinzip, und nach Abschluss des Antwort- oder Fehlerpfads wird automatisch eine Bereinigung versucht. +- Die Reaktion erfolgt nach Best Effort, und die Bereinigung wird nach Abschluss des Antwort- oder Fehlerpfads automatisch versucht. ## Medien, Chunking und Zustellung - Slack-Dateianhänge werden von Slack-gehosteten privaten URLs heruntergeladen (tokenauthentifizierter Request-Flow) und bei erfolgreichem Abruf sowie zulässigen Größenlimits in den Medienspeicher geschrieben. Datei-Platzhalter enthalten die Slack-`fileId`, damit Agenten die Originaldatei mit `download-file` abrufen können. + Slack-Dateianhänge werden von Slack-gehosteten privaten URLs heruntergeladen (tokenauthentifizierter Anfragefluss) und in den Medienspeicher geschrieben, wenn der Abruf erfolgreich ist und Größenlimits dies erlauben. Dateiplatzhalter enthalten die Slack-`fileId`, damit Agenten die Originaldatei mit `download-file` abrufen können. - Downloads verwenden begrenzte Leerlauf- und Gesamtzeitlimits. Wenn der Abruf einer Slack-Datei stockt oder fehlschlägt, verarbeitet OpenClaw die Nachricht weiter und fällt auf den Datei-Platzhalter zurück. + Downloads verwenden begrenzte Leerlauf- und Gesamtzeitlimits. Wenn der Abruf einer Slack-Datei hängen bleibt oder fehlschlägt, verarbeitet OpenClaw die Nachricht weiter und fällt auf den Dateiplatzhalter zurück. - Die Laufzeit-Obergrenze für eingehende Dateien ist standardmäßig `20MB`, sofern sie nicht durch `channels.slack.mediaMaxMb` überschrieben wird. + Die Laufzeit-Obergrenze für eingehende Inhalte ist standardmäßig `20MB`, sofern sie nicht durch `channels.slack.mediaMaxMb` überschrieben wird. - Text-Chunks verwenden `channels.slack.textChunkLimit` (Standard 4000) - `channels.slack.chunkMode="newline"` aktiviert absatzorientiertes Aufteilen - - Datei-Sendungen verwenden Slack-Upload-APIs und können Thread-Antworten (`thread_ts`) enthalten - - Die Obergrenze für ausgehende Medien folgt `channels.slack.mediaMaxMb`, wenn konfiguriert; andernfalls verwenden Channel-Sendungen MIME-Art-Standardwerte aus der Medien-Pipeline + - Dateisendungen verwenden Slack-Upload-APIs und können Thread-Antworten (`thread_ts`) enthalten + - Die Obergrenze für ausgehende Medien folgt `channels.slack.mediaMaxMb`, wenn konfiguriert; andernfalls verwenden Kanalsendungen MIME-Typ-Standards aus der Medienpipeline @@ -742,16 +761,16 @@ Hinweise: Bevorzugte explizite Ziele: - `user:` für DMs - - `channel:` für Channels + - `channel:` für Kanäle - Reine Text-/Block-Slack-DMs können direkt an Benutzer-IDs posten; Datei-Uploads und Thread-Sendungen öffnen zuerst die DM über Slack-Conversation-APIs, weil diese Pfade eine konkrete Conversation-ID benötigen. + Text-/Block-only-Slack-DMs können direkt an Benutzer-IDs posten; Datei-Uploads und Thread-Sendungen öffnen die DM zuerst über Slack Conversation APIs, da diese Pfade eine konkrete Konversations-ID benötigen. ## Befehle und Slash-Verhalten -Slash-Befehle erscheinen in Slack entweder als einzelner konfigurierter Befehl oder als mehrere native Befehle. Konfigurieren Sie `channels.slack.slashCommand`, um Befehlsstandardwerte zu ändern: +Slash-Befehle erscheinen in Slack entweder als einzelner konfigurierter Befehl oder als mehrere native Befehle. Konfigurieren Sie `channels.slack.slashCommand`, um Befehlsstandards zu ändern: - `enabled: false` - `name: "openclaw"` @@ -770,7 +789,7 @@ Native Befehle erfordern [zusätzliche Manifest-Einstellungen](#additional-manif /help ``` -Native Argumentmenüs verwenden eine adaptive Rendering-Strategie, die vor dem Ausführen eines ausgewählten Optionswerts ein Bestätigungsmodal anzeigt: +Native Argumentmenüs verwenden eine adaptive Rendering-Strategie, die vor dem Auslösen eines ausgewählten Optionswerts ein Bestätigungsmodal anzeigt: - bis zu 5 Optionen: Button-Blöcke - 6-100 Optionen: statisches Auswahlmenü @@ -781,13 +800,13 @@ Native Argumentmenüs verwenden eine adaptive Rendering-Strategie, die vor dem A /think ``` -Slash-Sessions verwenden isolierte Schlüssel wie `agent::slack:slash:` und leiten Befehlsausführungen weiterhin mit `CommandTargetSessionKey` an die Ziel-Conversation-Session weiter. +Slash-Sitzungen verwenden isolierte Schlüssel wie `agent::slack:slash:` und leiten Befehlsausführungen weiterhin mit `CommandTargetSessionKey` an die Ziel-Konversationssitzung weiter. ## Interaktive Antworten -Slack kann von Agenten erstellte interaktive Antwortsteuerelemente rendern, aber diese Funktion ist standardmäßig deaktiviert. +Slack kann von Agenten verfasste interaktive Antwortsteuerelemente rendern, diese Funktion ist jedoch standardmäßig deaktiviert. -Aktivieren Sie sie global: +Global aktivieren: ```json5 { @@ -801,7 +820,7 @@ Aktivieren Sie sie global: } ``` -Oder aktivieren Sie sie nur für ein Slack-Konto: +Oder nur für ein Slack-Konto aktivieren: ```json5 { @@ -819,42 +838,42 @@ Oder aktivieren Sie sie nur für ein Slack-Konto: } ``` -Wenn aktiviert, können Agenten nur für Slack bestimmte Antwortdirektiven ausgeben: +Wenn aktiviert, können Agenten Slack-only-Antwortdirektiven ausgeben: - `[[slack_buttons: Approve:approve, Reject:reject]]` - `[[slack_select: Choose a target | Canary:canary, Production:production]]` -Diese Direktiven werden in Slack Block Kit kompiliert und leiten Klicks oder Auswahlen über den bestehenden Slack-Interaktionsereignispfad zurück. +Diese Direktiven werden in Slack Block Kit kompiliert und leiten Klicks oder Auswahlen über den bestehenden Ereignispfad für Slack-Interaktionen zurück. Hinweise: -- Dies ist Slack-spezifische UI. Andere Channels übersetzen Slack-Block-Kit-Direktiven nicht in ihre eigenen Button-Systeme. -- Die interaktiven Callback-Werte sind von OpenClaw generierte opake Tokens, keine rohen von Agenten erstellten Werte. -- Wenn generierte interaktive Blöcke Slack-Block-Kit-Limits überschreiten würden, fällt OpenClaw auf die ursprüngliche Textantwort zurück, statt eine ungültige Block-Payload zu senden. +- Dies ist Slack-spezifische UI. Andere Kanäle übersetzen Slack-Block-Kit-Direktiven nicht in ihre eigenen Button-Systeme. +- Die interaktiven Callback-Werte sind von OpenClaw generierte opake Tokens, keine rohen, von Agenten verfassten Werte. +- Wenn generierte interaktive Blöcke Slack-Block-Kit-Limits überschreiten würden, fällt OpenClaw auf die ursprüngliche Textantwort zurück, statt eine ungültige Blocks-Payload zu senden. ## Exec-Genehmigungen in Slack -Slack kann als nativer Genehmigungsclient mit interaktiven Buttons und Interaktionen fungieren, statt auf die Web-UI oder das Terminal zurückzufallen. +Slack kann als nativer Genehmigungsclient mit interaktiven Buttons und Interaktionen dienen, statt auf die Web-UI oder das Terminal zurückzufallen. -- Exec-Genehmigungen verwenden `channels.slack.execApprovals.*` für natives DM-/Channel-Routing. -- Plugin-Genehmigungen können weiterhin über dieselbe Slack-native Button-Oberfläche aufgelöst werden, wenn die Anfrage bereits in Slack landet und die Art der Genehmigungs-ID `plugin:` ist. -- Die Autorisierung von Genehmigenden wird weiterhin erzwungen: Nur als Genehmigende identifizierte Benutzer können Anfragen über Slack genehmigen oder ablehnen. +- Exec-Genehmigungen verwenden `channels.slack.execApprovals.*` für natives DM-/Kanal-Routing. +- Plugin-Genehmigungen können weiterhin über dieselbe Slack-native Button-Oberfläche aufgelöst werden, wenn die Anfrage bereits in Slack ankommt und die Art der Genehmigungs-ID `plugin:` ist. +- Die Autorisierung genehmigender Personen wird weiterhin erzwungen: Nur als Genehmigende identifizierte Benutzer können Anfragen über Slack genehmigen oder ablehnen. -Dies verwendet dieselbe gemeinsame Genehmigungsbutton-Oberfläche wie andere Channels. Wenn `interactivity` in Ihren Slack-App-Einstellungen aktiviert ist, werden Genehmigungsaufforderungen direkt in der Conversation als Block-Kit-Buttons gerendert. +Dies verwendet dieselbe gemeinsame Genehmigungsbutton-Oberfläche wie andere Kanäle. Wenn `interactivity` in Ihren Slack-App-Einstellungen aktiviert ist, werden Genehmigungsaufforderungen direkt in der Konversation als Block-Kit-Buttons gerendert. Wenn diese Buttons vorhanden sind, sind sie die primäre Genehmigungs-UX; OpenClaw -sollte einen manuellen `/approve`-Befehl nur einschließen, wenn das Tool-Ergebnis besagt, dass Chat- -Genehmigungen nicht verfügbar sind oder die manuelle Genehmigung der einzige Pfad ist. +sollte nur dann einen manuellen `/approve`-Befehl einbeziehen, wenn das Tool-Ergebnis sagt, dass Chat- +Genehmigungen nicht verfügbar sind oder manuelle Genehmigung der einzige Pfad ist. Konfigurationspfad: - `channels.slack.execApprovals.enabled` -- `channels.slack.execApprovals.approvers` (optional; fällt wenn möglich auf `commands.ownerAllowFrom` zurück) +- `channels.slack.execApprovals.approvers` (optional; fällt nach Möglichkeit auf `commands.ownerAllowFrom` zurück) - `channels.slack.execApprovals.target` (`dm` | `channel` | `both`, Standard: `dm`) - `agentFilter`, `sessionFilter` -Slack aktiviert native Exec-Genehmigungen automatisch, wenn `enabled` nicht gesetzt oder `"auto"` ist und mindestens ein -Genehmigender aufgelöst wird. Setzen Sie `enabled: false`, um Slack explizit als nativen Genehmigungsclient zu deaktivieren. -Setzen Sie `enabled: true`, um native Genehmigungen zu erzwingen, wenn Genehmigende aufgelöst werden. +Slack aktiviert native Exec-Genehmigungen automatisch, wenn `enabled` nicht gesetzt oder `"auto"` ist und mindestens eine +genehmigende Person aufgelöst wird. Setzen Sie `enabled: false`, um Slack als nativen Genehmigungsclient explizit zu deaktivieren. +Setzen Sie `enabled: true`, um native Genehmigungen zu erzwingen, wenn genehmigende Personen aufgelöst werden. Standardverhalten ohne explizite Slack-Exec-Genehmigungskonfiguration: @@ -866,8 +885,8 @@ Standardverhalten ohne explizite Slack-Exec-Genehmigungskonfiguration: } ``` -Eine explizite Slack-native Konfiguration ist nur erforderlich, wenn Sie Genehmigende überschreiben, Filter hinzufügen oder -sich für die Zustellung im Ursprungs-Chat entscheiden möchten: +Eine explizite Slack-native Konfiguration ist nur erforderlich, wenn Sie genehmigende Personen überschreiben, Filter hinzufügen oder +die Zustellung im Ursprungschat aktivieren möchten: ```json5 { @@ -883,25 +902,25 @@ sich für die Zustellung im Ursprungs-Chat entscheiden möchten: } ``` -Gemeinsame `approvals.exec`-Weiterleitung ist separat. Verwenden Sie sie nur, wenn Exec-Genehmigungsaufforderungen auch -an andere Chats oder explizite Out-of-Band-Ziele weitergeleitet werden müssen. Gemeinsame `approvals.plugin`-Weiterleitung ist ebenfalls -separat; Slack-native Buttons können Plugin-Genehmigungen weiterhin auflösen, wenn diese Anfragen bereits -in Slack landen. +Die gemeinsame `approvals.exec`-Weiterleitung ist getrennt. Verwenden Sie sie nur, wenn Exec-Genehmigungsaufforderungen auch +an andere Chats oder explizite Out-of-band-Ziele geleitet werden müssen. Die gemeinsame `approvals.plugin`-Weiterleitung ist ebenfalls +getrennt; Slack-native Buttons können Plugin-Genehmigungen weiterhin auflösen, wenn diese Anfragen bereits +in Slack ankommen. -Same-Chat-`/approve` funktioniert auch in Slack-Channels und DMs, die bereits Befehle unterstützen. Siehe [Exec-Genehmigungen](/de/tools/exec-approvals) für das vollständige Weiterleitungsmodell für Genehmigungen. +Same-chat-`/approve` funktioniert auch in Slack-Kanälen und DMs, die bereits Befehle unterstützen. Siehe [Exec-Genehmigungen](/de/tools/exec-approvals) für das vollständige Modell der Genehmigungsweiterleitung. ## Ereignisse und Betriebsverhalten - Nachrichtenbearbeitungen/-löschungen werden Systemereignissen zugeordnet. -- Thread-Broadcasts (Thread-Antworten mit „Auch an Channel senden“) werden als normale Benutzernachrichten verarbeitet. +- Thread-Broadcasts (Thread-Antworten mit „Also send to channel“) werden als normale Benutzernachrichten verarbeitet. - Ereignisse zum Hinzufügen/Entfernen von Reaktionen werden Systemereignissen zugeordnet. -- Ereignisse zu Beitritt/Austritt von Mitgliedern, erstellten/umbenannten Channels und hinzugefügten/entfernten Pins werden Systemereignissen zugeordnet. -- `channel_id_changed` kann Channel-Konfigurationsschlüssel migrieren, wenn `configWrites` aktiviert ist. -- Metadaten zu Channel-Thema/-Zweck werden als nicht vertrauenswürdiger Kontext behandelt und können in den Routing-Kontext injiziert werden. -- Thread-Starter und anfängliches Seeding des Thread-Verlaufskontexts werden, falls zutreffend, durch konfigurierte Absender-Allowlists gefiltert. -- Block-Aktionen und Modal-Interaktionen geben strukturierte Systemereignisse `Slack interaction: ...` mit umfangreichen Payload-Feldern aus: - - Block-Aktionen: ausgewählte Werte, Labels, Picker-Werte und `workflow_*`-Metadaten - - modale `view_submission`- und `view_closed`-Ereignisse mit gerouteten Channel-Metadaten und Formulareingaben +- Ereignisse zu Mitgliederbeitritt/-austritt, Kanal erstellt/umbenannt und Pin hinzufügen/entfernen werden Systemereignissen zugeordnet. +- `channel_id_changed` kann Kanalkonfigurationsschlüssel migrieren, wenn `configWrites` aktiviert ist. +- Metadaten zu Kanalthema/-zweck werden als nicht vertrauenswürdiger Kontext behandelt und können in den Routing-Kontext injiziert werden. +- Thread-Starter und anfängliches Seeding des Thread-Verlaufskontexts werden durch konfigurierte Sender-Allowlists gefiltert, wenn zutreffend. +- Blockaktionen und Modalinteraktionen geben strukturierte `Slack interaction: ...`-Systemereignisse mit umfangreichen Payload-Feldern aus: + - Blockaktionen: ausgewählte Werte, Labels, Picker-Werte und `workflow_*`-Metadaten + - Modale `view_submission`- und `view_closed`-Ereignisse mit gerouteten Kanalmetadaten und Formulareingaben ## Konfigurationsreferenz @@ -911,8 +930,8 @@ Primäre Referenz: [Konfigurationsreferenz - Slack](/de/gateway/config-channels# - Modus/Auth: `mode`, `botToken`, `appToken`, `signingSecret`, `webhookPath`, `accounts.*` - DM-Zugriff: `dm.enabled`, `dmPolicy`, `allowFrom` (Legacy: `dm.policy`, `dm.allowFrom`), `dm.groupEnabled`, `dm.groupChannels` -- Kompatibilitätsumschalter: `dangerouslyAllowNameMatching` (Break-Glass; ausgeschaltet lassen, sofern nicht benötigt) -- Channel-Zugriff: `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention` +- Kompatibilitätsschalter: `dangerouslyAllowNameMatching` (Break-glass; deaktiviert lassen, sofern nicht benötigt) +- Kanalzugriff: `groupPolicy`, `channels.*`, `channels.*.users`, `channels.*.requireMention` - Threading/Verlauf: `replyToMode`, `replyToModeByChatType`, `thread.*`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit` - Zustellung: `textChunkLimit`, `chunkMode`, `mediaMaxMb`, `streaming`, `streaming.nativeTransport`, `streaming.preview.toolProgress` - Betrieb/Funktionen: `configWrites`, `commands.native`, `slashCommand.*`, `actions.*`, `userToken`, `userTokenReadOnly` @@ -926,9 +945,9 @@ Primäre Referenz: [Konfigurationsreferenz - Slack](/de/gateway/config-channels# Prüfen Sie der Reihe nach: - `groupPolicy` - - Channel-Allowlist (`channels.slack.channels`) — **Schlüssel müssen Channel-IDs sein** (`C12345678`), keine Namen (`#channel-name`). Namensbasierte Schlüssel schlagen unter `groupPolicy: "allowlist"` still fehl, weil Channel-Routing standardmäßig ID-first ist. So finden Sie eine ID: Rechtsklick auf den Channel in Slack → **Link kopieren** — der `C...`-Wert am Ende der URL ist die Channel-ID. + - Kanal-Allowlist (`channels.slack.channels`) — **Schlüssel müssen Kanal-IDs sein** (`C12345678`), keine Namen (`#channel-name`). Namensbasierte Schlüssel schlagen unter `groupPolicy: "allowlist"` stillschweigend fehl, da Kanal-Routing standardmäßig ID-first ist. So finden Sie eine ID: Rechtsklick auf den Kanal in Slack → **Copy link** — der `C...`-Wert am Ende der URL ist die Kanal-ID. - `requireMention` - - `users`-Allowlist pro Channel + - `users`-Allowlist pro Kanal Nützliche Befehle: @@ -946,9 +965,9 @@ openclaw doctor - `channels.slack.dm.enabled` - `channels.slack.dmPolicy` (oder Legacy `channels.slack.dm.policy`) - Pairing-Genehmigungen / Allowlist-Einträge - - Slack-Assistant-DM-Ereignisse: Ausführliche Logs mit `drop message_changed` - bedeuten meist, dass Slack ein bearbeitetes Assistant-Thread-Ereignis ohne - wiederherstellbaren menschlichen Absender in den Nachrichtenmetadaten gesendet hat + - Slack-Assistant-DM-Ereignisse: Ausführliche Logs mit Erwähnung von `drop message_changed` + bedeuten in der Regel, dass Slack ein bearbeitetes Assistant-Thread-Ereignis ohne + wiederherstellbaren menschlichen Sender in den Nachrichtenmetadaten gesendet hat ```bash openclaw pairing list slack @@ -957,7 +976,7 @@ openclaw pairing list slack - Validieren Sie Bot- und App-Tokens sowie die Socket-Mode-Aktivierung in den Slack-App-Einstellungen. + Validieren Sie Bot- und App-Tokens sowie die Aktivierung von Socket Mode in den Slack-App-Einstellungen. Wenn `openclaw channels status --probe --json` `botTokenStatus` oder `appTokenStatus: "configured_unavailable"` anzeigt, ist das Slack-Konto @@ -986,40 +1005,40 @@ openclaw pairing list slack - nativer Befehlsmodus (`channels.slack.commands.native: true`) mit passenden in Slack registrierten Slash-Befehlen - oder einzelner Slash-Befehlsmodus (`channels.slack.slashCommand.enabled: true`) - Prüfen Sie auch `commands.useAccessGroups` und Channel-/Benutzer-Allowlists. + Prüfen Sie außerdem `commands.useAccessGroups` und Kanal-/Benutzer-Allowlists. -## Referenz für Attachment Vision +## Referenz für Attachment-Vision -Slack kann heruntergeladene Medien an den Agenten-Turn anhängen, wenn Slack-Dateidownloads erfolgreich sind und Größenlimits dies zulassen. Bilddateien können über den Pfad für Medienverständnis oder direkt an ein antwortendes Modell mit Vision-Fähigkeit übergeben werden; andere Dateien werden als herunterladbarer Dateikontext beibehalten, statt als Bildeingabe behandelt zu werden. +Slack kann heruntergeladene Medien an den Agententurn anhängen, wenn Slack-Dateidownloads erfolgreich sind und Größenlimits dies erlauben. Bilddateien können über den Pfad für Medienverständnis oder direkt an ein vision-fähiges Antwortmodell weitergegeben werden; andere Dateien werden als herunterladbarer Dateikontext beibehalten, statt als Bildeingabe behandelt zu werden. ### Unterstützte Medientypen -| Medientyp | Quelle | Aktuelles Verhalten | Hinweise | -| ------------------------------ | -------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | -| JPEG-/PNG-/GIF-/WebP-Bilder | Slack-Datei-URL | Heruntergeladen und dem Turn für visionfähige Verarbeitung angehängt | Limit pro Datei: `channels.slack.mediaMaxMb` (Standard 20 MB) | -| PDF-Dateien | Slack-Datei-URL | Heruntergeladen und als Dateikontext für Tools wie `download-file` oder `pdf` bereitgestellt | Slack-Inbound wandelt PDFs nicht automatisch in Eingaben für Bild-Vision um | -| Andere Dateien | Slack-Datei-URL | Nach Möglichkeit heruntergeladen und als Dateikontext bereitgestellt | Binärdateien werden nicht als Bildeingabe behandelt | -| Thread-Antworten | Dateien des Thread-Starters | Dateien der Root-Nachricht können als Kontext geladen werden, wenn die Antwort keine direkten Medien hat | Starter nur mit Dateien verwenden einen Anhang-Platzhalter | -| Nachrichten mit mehreren Bildern | Mehrere Slack-Dateien | Jede Datei wird unabhängig ausgewertet | Die Slack-Verarbeitung ist auf acht Dateien pro Nachricht begrenzt | +| Medientyp | Quelle | Aktuelles Verhalten | Hinweise | +| ------------------------------ | -------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | +| JPEG-/PNG-/GIF-/WebP-Bilder | Slack-Datei-URL | Heruntergeladen und der Konversationsrunde für bildfähige Verarbeitung angehängt | Limit pro Datei: `channels.slack.mediaMaxMb` (Standard: 20 MB) | +| PDF-Dateien | Slack-Datei-URL | Heruntergeladen und als Dateikontext für Tools wie `download-file` oder `pdf` bereitgestellt | Eingehende Slack-Nachrichten konvertieren PDFs nicht automatisch in Bild-Vision-Eingaben | +| Andere Dateien | Slack-Datei-URL | Wenn möglich heruntergeladen und als Dateikontext bereitgestellt | Binärdateien werden nicht als Bildeingabe behandelt | +| Thread-Antworten | Dateien des Thread-Starters | Dateien der Root-Nachricht können als Kontext hydratisiert werden, wenn die Antwort keine direkten Medien hat | Starter nur mit Dateien verwenden einen Anhang-Platzhalter | +| Nachrichten mit mehreren Bildern | Mehrere Slack-Dateien | Jede Datei wird unabhängig ausgewertet | Die Slack-Verarbeitung ist auf acht Dateien pro Nachricht begrenzt | -### Inbound-Pipeline +### Eingehende Pipeline Wenn eine Slack-Nachricht mit Dateianhängen eingeht: -1. OpenClaw lädt die Datei von Slacks privater URL mit dem Bot-Token (`xoxb-...`) herunter. +1. OpenClaw lädt die Datei über die private URL von Slack mit dem Bot-Token (`xoxb-...`) herunter. 2. Die Datei wird bei Erfolg in den Medienspeicher geschrieben. -3. Heruntergeladene Medienpfade und Inhaltstypen werden dem Inbound-Kontext hinzugefügt. +3. Heruntergeladene Medienpfade und Inhaltstypen werden dem eingehenden Kontext hinzugefügt. 4. Bildfähige Modell-/Tool-Pfade können Bildanhänge aus diesem Kontext verwenden. -5. Nicht-Bilddateien bleiben als Dateimetadaten oder Medienreferenzen für Tools verfügbar, die sie verarbeiten können. +5. Nicht-Bilddateien bleiben als Dateimetadaten oder Medienreferenzen für Tools verfügbar, die damit umgehen können. ### Vererbung von Thread-Root-Anhängen -Wenn eine Nachricht in einem Thread eingeht (mit einem übergeordneten `thread_ts`): +Wenn eine Nachricht in einem Thread eingeht (mit einem `thread_ts`-Parent): -- Wenn die Antwort selbst keine direkten Medien hat und die enthaltene Root-Nachricht Dateien enthält, kann Slack die Root-Dateien als Thread-Starter-Kontext laden. +- Wenn die Antwort selbst keine direkten Medien hat und die enthaltene Root-Nachricht Dateien enthält, kann Slack die Root-Dateien als Thread-Starter-Kontext hydratisieren. - Direkte Antwortanhänge haben Vorrang vor Anhängen der Root-Nachricht. - Eine Root-Nachricht, die nur Dateien und keinen Text enthält, wird mit einem Anhang-Platzhalter dargestellt, damit der Fallback ihre Dateien weiterhin einbeziehen kann. @@ -1028,31 +1047,31 @@ Wenn eine Nachricht in einem Thread eingeht (mit einem übergeordneten `thread_t Wenn eine einzelne Slack-Nachricht mehrere Dateianhänge enthält: - Jeder Anhang wird unabhängig durch die Medien-Pipeline verarbeitet. -- Heruntergeladene Medienreferenzen werden im Nachrichtenkontext zusammengeführt. -- Die Verarbeitungsreihenfolge folgt Slacks Dateireihenfolge in der Event-Payload. +- Heruntergeladene Medienreferenzen werden im Nachrichtenkontext aggregiert. +- Die Verarbeitungsreihenfolge folgt der Dateireihenfolge von Slack im Event-Payload. - Ein Fehler beim Herunterladen eines Anhangs blockiert die anderen nicht. ### Größen-, Download- und Modelllimits - **Größenlimit**: Standardmäßig 20 MB pro Datei. Konfigurierbar über `channels.slack.mediaMaxMb`. -- **Downloadfehler**: Dateien, die Slack nicht ausliefern kann, abgelaufene URLs, nicht zugängliche Dateien, zu große Dateien und Slack-Auth-/Login-HTML-Antworten werden übersprungen, statt als nicht unterstützte Formate gemeldet zu werden. +- **Download-Fehler**: Dateien, die Slack nicht bereitstellen kann, abgelaufene URLs, nicht zugängliche Dateien, übergroße Dateien und Slack-Auth-/Login-HTML-Antworten werden übersprungen, statt als nicht unterstützte Formate gemeldet zu werden. - **Vision-Modell**: Die Bildanalyse verwendet das aktive Antwortmodell, wenn es Vision unterstützt, oder das unter `agents.defaults.imageModel` konfigurierte Bildmodell. -### Bekannte Einschränkungen +### Bekannte Limits -| Szenario | Aktuelles Verhalten | Problemumgehung | -| -------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------- | -| Abgelaufene Slack-Datei-URL | Datei übersprungen; kein Fehler angezeigt | Laden Sie die Datei erneut in Slack hoch | -| Vision-Modell nicht konfiguriert | Bildanhänge werden als Medienreferenzen gespeichert, aber nicht als Bilder analysiert | Konfigurieren Sie `agents.defaults.imageModel` oder verwenden Sie ein visionfähiges Antwortmodell | -| Sehr große Bilder (> 20 MB standardmäßig) | Gemäß Größenlimit übersprungen | Erhöhen Sie `channels.slack.mediaMaxMb`, wenn Slack dies zulässt | -| Weitergeleitete/geteilte Anhänge | Text und von Slack gehostete Bild-/Dateimedien werden nach bestem Aufwand verarbeitet | Teilen Sie sie direkt erneut im OpenClaw-Thread | -| PDF-Anhänge | Als Datei-/Medienkontext gespeichert, nicht automatisch durch Bild-Vision geleitet | Verwenden Sie `download-file` für Dateimetadaten oder das Tool `pdf` für die PDF-Analyse | +| Szenario | Aktuelles Verhalten | Umgehung | +| -------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------- | +| Abgelaufene Slack-Datei-URL | Datei wird übersprungen; es wird kein Fehler angezeigt | Laden Sie die Datei erneut in Slack hoch | +| Vision-Modell nicht konfiguriert | Bildanhänge werden als Medienreferenzen gespeichert, aber nicht als Bilder analysiert | Konfigurieren Sie `agents.defaults.imageModel` oder verwenden Sie ein bildfähiges Antwortmodell | +| Sehr große Bilder (> 20 MB standardmäßig) | Wird gemäß Größenlimit übersprungen | Erhöhen Sie `channels.slack.mediaMaxMb`, sofern Slack dies zulässt | +| Weitergeleitete/geteilte Anhänge | Text und von Slack gehostete Bild-/Dateimedien werden nach bestem Aufwand verarbeitet | Teilen Sie sie direkt im OpenClaw-Thread erneut | +| PDF-Anhänge | Als Datei-/Medienkontext gespeichert, nicht automatisch über Image Vision weitergeleitet | Verwenden Sie `download-file` für Dateimetadaten oder das `pdf`-Tool für PDF-Analysen | ### Zugehörige Dokumentation - [Pipeline für Medienverständnis](/de/nodes/media-understanding) - [PDF-Tool](/de/tools/pdf) -- Epic: [#51349](https://github.com/openclaw/openclaw/issues/51349) — Aktivierung von Slack-Anhang-Vision +- Epic: [#51349](https://github.com/openclaw/openclaw/issues/51349) — Aktivierung von Vision für Slack-Anhänge - Regressionstests: [#51353](https://github.com/openclaw/openclaw/issues/51353) - Live-Verifizierung: [#51354](https://github.com/openclaw/openclaw/issues/51354) @@ -1063,16 +1082,16 @@ Wenn eine einzelne Slack-Nachricht mehrere Dateianhänge enthält: Koppeln Sie einen Slack-Benutzer mit dem Gateway. - Channel- und Gruppen-DM-Verhalten. + Verhalten von Channels und Gruppen-DMs. - Leiten Sie Inbound-Nachrichten an Agents weiter. + Leiten Sie eingehende Nachrichten an Agenten weiter. Bedrohungsmodell und Härtung. - Konfigurationslayout und Rangfolge. + Konfigurationslayout und Vorrangregeln. Befehlskatalog und Verhalten. diff --git a/docs/de/channels/telegram.md b/docs/de/channels/telegram.md index 92b78eb4b..e1768b9d7 100644 --- a/docs/de/channels/telegram.md +++ b/docs/de/channels/telegram.md @@ -1,42 +1,42 @@ --- read_when: - Arbeiten an Telegram-Funktionen oder Webhooks -summary: Supportstatus, Funktionen und Konfiguration für den Telegram-Bot +summary: Supportstatus, Funktionen und Konfiguration des Telegram-Bots title: Telegram x-i18n: - generated_at: "2026-05-04T06:41:15Z" + generated_at: "2026-05-04T07:02:48Z" model: gpt-5.5 provider: openai - source_hash: c7f49db5f3fe8fd724e53a2ae3d226446f248bf9d021fcc01c1cf816649381d2 + source_hash: 6ef1b019a6a0e261b33972b5edffaedd29310b1333d112bade2e79e9d56887c6 source_path: channels/telegram.md workflow: 16 --- -Produktionsreif für Bot-DMs und Gruppen über grammY. Long Polling ist der Standardmodus; der Webhook-Modus ist optional. +Produktionsbereit für Bot-DMs und Gruppen über grammY. Long Polling ist der Standardmodus; Webhook-Modus ist optional. - - Die Standard-DM-Richtlinie für Telegram ist Pairing. + + Die Standard-DM-Richtlinie für Telegram ist Kopplung. - + Kanalübergreifende Diagnosen und Reparatur-Playbooks. - - Vollständige Channel-Konfigurationsmuster und Beispiele. + + Vollständige Kanalkonfigurationsmuster und Beispiele. ## Schnelle Einrichtung - - Öffnen Sie Telegram und chatten Sie mit **@BotFather** (stellen Sie sicher, dass der Handle exakt `@BotFather` lautet). + + Öffnen Sie Telegram und chatten Sie mit **@BotFather** (bestätigen Sie, dass der Handle genau `@BotFather` lautet). - Führen Sie `/newbot` aus, folgen Sie den Eingabeaufforderungen und speichern Sie das Token. + Führen Sie `/newbot` aus, folgen Sie den Aufforderungen und speichern Sie das Token. - + ```json5 { @@ -52,11 +52,11 @@ Produktionsreif für Bot-DMs und Gruppen über grammY. Long Polling ist der Stan ``` Env-Fallback: `TELEGRAM_BOT_TOKEN=...` (nur Standardkonto). - Telegram verwendet **nicht** `openclaw channels login telegram`; konfigurieren Sie das Token in der Konfiguration/Umgebung und starten Sie dann den Gateway. + Telegram verwendet **nicht** `openclaw channels login telegram`; konfigurieren Sie das Token in config/env und starten Sie dann das Gateway. - + ```bash openclaw gateway @@ -64,12 +64,12 @@ openclaw pairing list telegram openclaw pairing approve telegram ``` - Pairing-Codes laufen nach 1 Stunde ab. + Kopplungscodes laufen nach 1 Stunde ab. - - Fügen Sie den Bot Ihrer Gruppe hinzu und setzen Sie dann `channels.telegram.groups` und `groupPolicy` passend zu Ihrem Zugriffsmodell. + + Fügen Sie den Bot zu Ihrer Gruppe hinzu und legen Sie dann `channels.telegram.groups` und `groupPolicy` passend zu Ihrem Zugriffsmodell fest. @@ -80,26 +80,26 @@ Die Reihenfolge der Token-Auflösung ist kontobewusst. In der Praxis haben Konfi ## Telegram-seitige Einstellungen - - Telegram-Bots verwenden standardmäßig den **Privatsphäre-Modus**, der begrenzt, welche Gruppennachrichten sie empfangen. + + Telegram-Bots verwenden standardmäßig den **Privatsphäremodus**, der einschränkt, welche Gruppennachrichten sie empfangen. - Wenn der Bot alle Gruppennachrichten sehen muss, können Sie entweder: + Wenn der Bot alle Gruppennachrichten sehen muss, entweder: - - den Privatsphäre-Modus über `/setprivacy` deaktivieren oder - - den Bot zum Gruppenadministrator machen. + - deaktivieren Sie den Privatsphäremodus über `/setprivacy`, oder + - machen Sie den Bot zum Gruppenadministrator. - Wenn Sie den Privatsphäre-Modus umschalten, entfernen Sie den Bot aus jeder Gruppe und fügen Sie ihn erneut hinzu, damit Telegram die Änderung übernimmt. + Wenn Sie den Privatsphäremodus umschalten, entfernen Sie den Bot aus jeder Gruppe und fügen Sie ihn erneut hinzu, damit Telegram die Änderung anwendet. - - Der Adminstatus wird in den Telegram-Gruppeneinstellungen gesteuert. + + Der Administratorstatus wird in den Telegram-Gruppeneinstellungen gesteuert. - Admin-Bots empfangen alle Gruppennachrichten, was für dauerhaft aktive Gruppenfunktionen nützlich ist. + Administrator-Bots empfangen alle Gruppennachrichten, was für immer aktive Gruppenfunktionen nützlich ist. - + - `/setjoingroups`, um Gruppenhinzufügungen zu erlauben/zu verweigern - `/setprivacy` für das Verhalten der Gruppensichtbarkeit @@ -110,35 +110,35 @@ Die Reihenfolge der Token-Auflösung ist kontobewusst. In der Praxis haben Konfi ## Zugriffskontrolle und Aktivierung - - `channels.telegram.dmPolicy` steuert den Zugriff auf Direktnachrichten: + + `channels.telegram.dmPolicy` steuert den Direktnachrichtenzugriff: - `pairing` (Standard) - `allowlist` (erfordert mindestens eine Absender-ID in `allowFrom`) - `open` (erfordert, dass `allowFrom` `"*"` enthält) - `disabled` - `dmPolicy: "open"` mit `allowFrom: ["*"]` erlaubt jedem Telegram-Konto, das den Bot-Benutzernamen findet oder errät, dem Bot Befehle zu geben. Verwenden Sie dies nur für bewusst öffentliche Bots mit stark eingeschränkten Tools; Bots mit einem einzelnen Besitzer sollten `allowlist` mit numerischen Benutzer-IDs verwenden. + `dmPolicy: "open"` mit `allowFrom: ["*"]` erlaubt jedem Telegram-Konto, das den Bot-Benutzernamen findet oder errät, dem Bot Befehle zu geben. Verwenden Sie dies nur für bewusst öffentliche Bots mit stark eingeschränkten Tools; Bots mit einem einzelnen Owner sollten `allowlist` mit numerischen Benutzer-IDs verwenden. `channels.telegram.allowFrom` akzeptiert numerische Telegram-Benutzer-IDs. Präfixe `telegram:` / `tg:` werden akzeptiert und normalisiert. - In Multi-Konto-Konfigurationen wird ein restriktives `channels.telegram.allowFrom` auf oberster Ebene als Sicherheitsgrenze behandelt: `allowFrom: ["*"]`-Einträge auf Kontoebene machen dieses Konto nicht öffentlich, es sei denn, die effektive Konto-Allowlist enthält nach dem Zusammenführen weiterhin einen expliziten Platzhalter. + In Mehrkontokonfigurationen wird ein restriktives `channels.telegram.allowFrom` auf oberster Ebene als Sicherheitsgrenze behandelt: Kontospezifische `allowFrom: ["*"]`-Einträge machen dieses Konto nicht öffentlich, es sei denn, die effektive Allowlist des Kontos enthält nach dem Zusammenführen weiterhin einen expliziten Platzhalter. `dmPolicy: "allowlist"` mit leerem `allowFrom` blockiert alle DMs und wird von der Konfigurationsvalidierung abgelehnt. Die Einrichtung fragt nur nach numerischen Benutzer-IDs. Wenn Sie ein Upgrade durchgeführt haben und Ihre Konfiguration `@username`-Allowlist-Einträge enthält, führen Sie `openclaw doctor --fix` aus, um sie aufzulösen (nach bestem Bemühen; erfordert ein Telegram-Bot-Token). - Wenn Sie sich zuvor auf Pairing-Store-Allowlist-Dateien verlassen haben, kann `openclaw doctor --fix` Einträge in Allowlist-Flows in `channels.telegram.allowFrom` wiederherstellen (zum Beispiel, wenn `dmPolicy: "allowlist"` noch keine expliziten IDs hat). + Wenn Sie zuvor Allowlist-Dateien des Kopplungsspeichers verwendet haben, kann `openclaw doctor --fix` Einträge in Allowlist-Flows in `channels.telegram.allowFrom` wiederherstellen (zum Beispiel, wenn `dmPolicy: "allowlist"` noch keine expliziten IDs hat). - Für Bots mit einem einzelnen Besitzer bevorzugen Sie `dmPolicy: "allowlist"` mit expliziten numerischen `allowFrom`-IDs, damit die Zugriffsrichtlinie dauerhaft in der Konfiguration liegt (statt von früheren Pairing-Genehmigungen abzuhängen). + Für Bots mit einem einzelnen Owner bevorzugen Sie `dmPolicy: "allowlist"` mit expliziten numerischen `allowFrom`-IDs, damit die Zugriffsrichtlinie dauerhaft in der Konfiguration liegt (statt von früheren Kopplungsgenehmigungen abzuhängen). - Häufige Verwirrung: DM-Pairing-Genehmigung bedeutet nicht „dieser Absender ist überall autorisiert“. - Pairing gewährt DM-Zugriff. Wenn noch kein Befehlsbesitzer existiert, setzt das erste genehmigte Pairing außerdem `commands.ownerAllowFrom`, damit Besitzer-only-Befehle und Ausführungsgenehmigungen ein explizites Operatorkonto haben. - Die Autorisierung von Gruppensendern kommt weiterhin aus expliziten Konfigurations-Allowlists. - Wenn Sie möchten: „Ich bin einmal autorisiert und sowohl DMs als auch Gruppenbefehle funktionieren“, setzen Sie Ihre numerische Telegram-Benutzer-ID in `channels.telegram.allowFrom`; stellen Sie für Besitzer-only-Befehle sicher, dass `commands.ownerAllowFrom` `telegram:` enthält. + Häufige Verwirrung: Die Genehmigung einer DM-Kopplung bedeutet nicht „dieser Absender ist überall autorisiert“. + Kopplung gewährt DM-Zugriff. Wenn noch kein Befehls-Owner existiert, setzt die erste genehmigte Kopplung auch `commands.ownerAllowFrom`, sodass Owner-only-Befehle und Exec-Genehmigungen ein explizites Betreiberkonto haben. + Die Autorisierung von Gruppenabsendern stammt weiterhin aus expliziten Konfigurations-Allowlists. + Wenn Sie möchten „Ich bin einmal autorisiert und sowohl DMs als auch Gruppenbefehle funktionieren“, setzen Sie Ihre numerische Telegram-Benutzer-ID in `channels.telegram.allowFrom`; stellen Sie für Owner-only-Befehle sicher, dass `commands.ownerAllowFrom` `telegram:` enthält. ### Ihre Telegram-Benutzer-ID finden Sicherer (kein Drittanbieter-Bot): - 1. Schreiben Sie Ihrem Bot eine DM. + 1. Senden Sie Ihrem Bot eine DM. 2. Führen Sie `openclaw logs --follow` aus. 3. Lesen Sie `from.id`. @@ -148,35 +148,35 @@ Die Reihenfolge der Token-Auflösung ist kontobewusst. In der Praxis haben Konfi curl "https://api.telegram.org/bot/getUpdates" ``` - Drittanbieter-Methode (weniger privat): `@userinfobot` oder `@getidsbot`. + Drittanbietermethode (weniger privat): `@userinfobot` oder `@getidsbot`. - + Zwei Steuerungen gelten zusammen: 1. **Welche Gruppen erlaubt sind** (`channels.telegram.groups`) - keine `groups`-Konfiguration: - mit `groupPolicy: "open"`: Jede Gruppe kann Gruppen-ID-Prüfungen bestehen - - mit `groupPolicy: "allowlist"` (Standard): Gruppen werden blockiert, bis Sie `groups`-Einträge hinzufügen (oder `"*"`) - - `groups` konfiguriert: wirkt als Allowlist (explizite IDs oder `"*"`) + - mit `groupPolicy: "allowlist"` (Standard): Gruppen werden blockiert, bis Sie `groups`-Einträge (oder `"*"`) hinzufügen + - `groups` konfiguriert: fungiert als Allowlist (explizite IDs oder `"*"`) 2. **Welche Absender in Gruppen erlaubt sind** (`channels.telegram.groupPolicy`) - `open` - `allowlist` (Standard) - `disabled` - `groupAllowFrom` wird für die Gruppensender-Filterung verwendet. Wenn es nicht gesetzt ist, fällt Telegram auf `allowFrom` zurück. + `groupAllowFrom` wird für die Filterung von Gruppenabsendern verwendet. Wenn nicht gesetzt, fällt Telegram auf `allowFrom` zurück. `groupAllowFrom`-Einträge sollten numerische Telegram-Benutzer-IDs sein (Präfixe `telegram:` / `tg:` werden normalisiert). - Setzen Sie keine Telegram-Gruppen- oder Supergruppen-Chat-IDs in `groupAllowFrom`. Negative Chat-IDs gehören unter `channels.telegram.groups`. - Nicht numerische Einträge werden für die Senderautorisierung ignoriert. - Sicherheitsgrenze (`2026.2.25+`): Gruppensender-Auth erbt **keine** DM-Pairing-Store-Genehmigungen. - Pairing bleibt DM-only. Legen Sie für Gruppen `groupAllowFrom` oder `allowFrom` pro Gruppe/pro Thema fest. - Wenn `groupAllowFrom` nicht gesetzt ist, fällt Telegram auf die Konfiguration `allowFrom` zurück, nicht auf den Pairing-Store. - Praktisches Muster für Bots mit einem einzelnen Besitzer: Setzen Sie Ihre Benutzer-ID in `channels.telegram.allowFrom`, lassen Sie `groupAllowFrom` unset und erlauben Sie die Zielgruppen unter `channels.telegram.groups`. - Laufzeithinweis: Wenn `channels.telegram` vollständig fehlt, verwendet die Laufzeit standardmäßig fail-closed `groupPolicy="allowlist"`, sofern `channels.defaults.groupPolicy` nicht explizit gesetzt ist. + Tragen Sie keine Telegram-Gruppen- oder Supergruppen-Chat-IDs in `groupAllowFrom` ein. Negative Chat-IDs gehören unter `channels.telegram.groups`. + Nicht numerische Einträge werden für die Absenderautorisierung ignoriert. + Sicherheitsgrenze (`2026.2.25+`): Die Authentifizierung von Gruppenabsendern erbt **keine** Genehmigungen aus dem DM-Kopplungsspeicher. + Kopplung bleibt nur für DMs. Legen Sie für Gruppen `groupAllowFrom` oder `allowFrom` pro Gruppe/pro Topic fest. + Wenn `groupAllowFrom` nicht gesetzt ist, fällt Telegram auf die Konfiguration `allowFrom` zurück, nicht auf den Kopplungsspeicher. + Praktisches Muster für Bots mit einem einzelnen Owner: Setzen Sie Ihre Benutzer-ID in `channels.telegram.allowFrom`, lassen Sie `groupAllowFrom` unset und erlauben Sie die Zielgruppen unter `channels.telegram.groups`. + Laufzeithinweis: Wenn `channels.telegram` vollständig fehlt, verwendet die Laufzeit standardmäßig fail-closed `groupPolicy="allowlist"`, es sei denn, `channels.defaults.groupPolicy` ist explizit gesetzt. - Beispiel: Jedes Mitglied in einer bestimmten Gruppe erlauben: + Beispiel: Beliebiges Mitglied in einer bestimmten Gruppe erlauben: ```json5 { @@ -215,28 +215,28 @@ curl "https://api.telegram.org/bot/getUpdates" - Setzen Sie negative Telegram-Gruppen- oder Supergruppen-Chat-IDs wie `-1001234567890` unter `channels.telegram.groups`. - Setzen Sie Telegram-Benutzer-IDs wie `8734062810` unter `groupAllowFrom`, wenn Sie begrenzen möchten, welche Personen innerhalb einer erlaubten Gruppe den Bot auslösen können. - - Verwenden Sie `groupAllowFrom: ["*"]` nur, wenn jedes Mitglied einer erlaubten Gruppe mit dem Bot sprechen dürfen soll. + - Verwenden Sie `groupAllowFrom: ["*"]` nur, wenn jedes Mitglied einer erlaubten Gruppe mit dem Bot sprechen können soll. - + Gruppenantworten erfordern standardmäßig eine Erwähnung. - Die Erwähnung kann stammen von: + Die Erwähnung kann kommen von: - - nativer `@botusername`-Erwähnung oder + - nativer `@botusername`-Erwähnung, oder - Erwähnungsmustern in: - `agents.list[].groupChat.mentionPatterns` - `messages.groupChat.mentionPatterns` - Befehlsumschaltungen auf Sitzungsebene: + Sitzungsbezogene Befehlsumschalter: - `/activation always` - `/activation mention` - Diese aktualisieren nur den Sitzungszustand. Verwenden Sie die Konfiguration für Persistenz. + Diese aktualisieren nur den Sitzungszustand. Verwenden Sie Konfiguration für Persistenz. Beispiel für persistente Konfiguration: @@ -252,9 +252,9 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Gruppen-Chat-ID abrufen: + Gruppen-Chat-ID erhalten: - - Leiten Sie eine Gruppennachricht an `@userinfobot` / `@getidsbot` weiter + - leiten Sie eine Gruppennachricht an `@userinfobot` / `@getidsbot` weiter - oder lesen Sie `chat.id` aus `openclaw logs --follow` - oder prüfen Sie Bot API `getUpdates` @@ -263,33 +263,34 @@ curl "https://api.telegram.org/bot/getUpdates" ## Laufzeitverhalten -- Telegram gehört dem Gateway-Prozess. -- Routing ist deterministisch: Eingehende Telegram-Antworten gehen zurück an Telegram (das Modell wählt keine Channels). -- Eingehende Nachrichten werden in den gemeinsamen Channel-Umschlag mit Antwortmetadaten und Medienplatzhaltern normalisiert. -- Gruppensitzungen werden nach Gruppen-ID isoliert. Forum-Themen hängen `:topic:` an, um Themen isoliert zu halten. -- DM-Nachrichten können `message_thread_id` enthalten; OpenClaw bewahrt die Thread-ID für Antworten, hält DMs standardmäßig aber in der flachen Sitzung. Konfigurieren Sie `channels.telegram.dm.threadReplies: "inbound"`, `channels.telegram.direct..threadReplies: "inbound"`, `requireTopic: true` oder eine passende Themenkonfiguration, wenn Sie absichtlich DM-Themensitzungsisolation möchten. -- Long Polling verwendet grammY runner mit Sequenzierung pro Chat/pro Thread. Die Gesamt-Runner-Sink-Nebenläufigkeit verwendet `agents.defaults.maxConcurrent`. -- Long Polling wird innerhalb jedes Gateway-Prozesses geschützt, sodass jeweils nur ein aktiver Poller ein Bot-Token verwenden kann. Wenn Sie weiterhin `getUpdates`-409-Konflikte sehen, verwendet wahrscheinlich ein anderer OpenClaw-Gateway, ein Skript oder ein externer Poller dasselbe Token. -- Neustarts des Long-Polling-Watchdogs werden standardmäßig nach 120 Sekunden ohne abgeschlossene `getUpdates`-Liveness ausgelöst. Erhöhen Sie `channels.telegram.pollingStallThresholdMs` nur, wenn Ihre Bereitstellung während lang laufender Arbeit weiterhin falsche Polling-Stall-Neustarts sieht. Der Wert ist in Millisekunden und von `30000` bis `600000` erlaubt; Überschreibungen pro Konto werden unterstützt. -- Die Telegram Bot API unterstützt keine Lesebestätigungen (`sendReadReceipts` gilt nicht). +- Telegram gehört zum Gateway-Prozess. +- Das Routing ist deterministisch: Eingehende Telegram-Nachrichten werden an Telegram beantwortet (das Modell wählt keine Kanäle aus). +- Eingehende Nachrichten werden in den gemeinsamen Kanalumschlag mit Antwortmetadaten und Medienplatzhaltern normalisiert. +- Gruppensitzungen werden nach Gruppen-ID isoliert. Forum-Topics hängen `:topic:` an, um Topics isoliert zu halten. +- DM-Nachrichten können `message_thread_id` enthalten; OpenClaw erhält die Thread-ID für Antworten, hält DMs aber standardmäßig in der flachen Sitzung. Konfigurieren Sie `channels.telegram.dm.threadReplies: "inbound"`, `channels.telegram.direct..threadReplies: "inbound"`, `requireTopic: true` oder eine passende Topic-Konfiguration, wenn Sie bewusst DM-Topic-Sitzungsisolation wünschen. +- Long Polling verwendet grammY Runner mit Sequenzierung pro Chat/pro Thread. Die gesamte Runner-Sink-Parallelität verwendet `agents.defaults.maxConcurrent`. +- Long Polling wird innerhalb jedes Gateway-Prozesses geschützt, sodass immer nur ein aktiver Poller ein Bot-Token gleichzeitig verwenden kann. Wenn Sie weiterhin `getUpdates`-409-Konflikte sehen, verwendet wahrscheinlich ein anderes OpenClaw-Gateway, Skript oder externer Poller dasselbe Token. +- Neustarts des Long-Polling-Watchdogs werden standardmäßig nach 120 Sekunden ohne abgeschlossene `getUpdates`-Liveness ausgelöst. Erhöhen Sie `channels.telegram.pollingStallThresholdMs` nur, wenn Ihre Bereitstellung bei lang laufenden Arbeiten weiterhin falsche Polling-Stall-Neustarts sieht. Der Wert ist in Millisekunden angegeben und von `30000` bis `600000` zulässig; kontospezifische Überschreibungen werden unterstützt. +- Die Telegram Bot API bietet keine Unterstützung für Lesebestätigungen (`sendReadReceipts` gilt nicht). ## Funktionsreferenz - + OpenClaw kann Teilantworten in Echtzeit streamen: - - Direktchats: Vorschaunachricht + `editMessageText` - - Gruppen/Themen: Vorschaunachricht + `editMessageText` + - direkte Chats: Vorschaunachricht + `editMessageText` + - Gruppen/Topics: Vorschaunachricht + `editMessageText` Anforderung: - `channels.telegram.streaming` ist `off | partial | block | progress` (Standard: `partial`) - - `progress` behält einen editierbaren Statusentwurf und aktualisiert ihn mit Tool-Fortschritt bis zur finalen Zustellung - - `streaming.preview.toolProgress` steuert, ob Tool-/Fortschrittsupdates dieselbe bearbeitete Vorschaunachricht wiederverwenden (Standard: `true`, wenn Vorschau-Streaming aktiv ist) - - Legacy-Werte `channels.telegram.streamMode` und boolesche `streaming`-Werte werden erkannt; führen Sie `openclaw doctor --fix` aus, um sie nach `channels.telegram.streaming.mode` zu migrieren + - `progress` hält einen bearbeitbaren Statusentwurf und aktualisiert ihn mit Tool-Fortschritt bis zur finalen Zustellung + - `streaming.preview.toolProgress` steuert, ob Tool-/Fortschrittsaktualisierungen dieselbe bearbeitete Vorschaunachricht wiederverwenden (Standard: `true`, wenn Vorschau-Streaming aktiv ist) + - `streaming.preview.commandText` steuert Befehls-/Exec-Details innerhalb dieser Tool-Fortschrittszeilen: `raw` (Standard, erhält veröffentlichtes Verhalten) oder `status` (nur Tool-Label) + - veraltete `channels.telegram.streamMode`- und boolesche `streaming`-Werte werden erkannt; führen Sie `openclaw doctor --fix` aus, um sie nach `channels.telegram.streaming.mode` zu migrieren - Vorschau-Updates für Tool-Fortschritt sind die kurzen Statuszeilen, die angezeigt werden, während Tools laufen, zum Beispiel Befehlsausführung, Dateilesevorgänge, Planungsupdates oder Patch-Zusammenfassungen. Telegram lässt diese standardmäßig aktiviert, um dem veröffentlichten OpenClaw-Verhalten ab `v2026.4.22` und später zu entsprechen. Um die bearbeitete Vorschau für Antworttext beizubehalten, aber Tool-Fortschrittszeilen auszublenden, setzen Sie: + Tool-Fortschrittsvorschau-Aktualisierungen sind die kurzen Statuszeilen, die angezeigt werden, während Tools laufen, zum Beispiel Befehlsausführung, Dateilesevorgänge, Planungsaktualisierungen oder Patch-Zusammenfassungen. Telegram lässt diese standardmäßig aktiviert, um dem veröffentlichten OpenClaw-Verhalten ab `v2026.4.22` und später zu entsprechen. Um die bearbeitete Vorschau für Antworttext beizubehalten, aber Tool-Fortschrittszeilen auszublenden, setzen Sie: ```json { @@ -306,26 +307,61 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Verwenden Sie `streaming.mode: "off"` nur, wenn Sie ausschließlich finale Auslieferung wünschen: Telegram-Vorschau-Edits werden deaktiviert, und generisches Tool-/Fortschrittsrauschen wird unterdrückt, statt als eigenständige Statusmeldungen gesendet zu werden. Genehmigungsabfragen, Medien-Payloads und Fehler werden weiterhin über die normale finale Auslieferung geleitet. Verwenden Sie `streaming.preview.toolProgress: false`, wenn Sie nur Antwortvorschau-Edits beibehalten und gleichzeitig die Tool-Fortschrittsstatuszeilen ausblenden möchten. + Um Tool-Fortschritt sichtbar zu halten, aber Befehls-/Exec-Text auszublenden, setzen Sie: + + ```json + { + "channels": { + "telegram": { + "streaming": { + "mode": "partial", + "preview": { + "commandText": "status" + } + } + } + } + } + ``` + + Für den Fortschrittsentwurfsmodus legen Sie dieselbe Richtlinie für Befehlstext unter `streaming.progress` ab: + + ```json + { + "channels": { + "telegram": { + "streaming": { + "mode": "progress", + "progress": { + "toolProgress": true, + "commandText": "status" + } + } + } + } + } + ``` + + Verwenden Sie `streaming.mode: "off"` nur, wenn Sie ausschließlich finale Zustellung wünschen: Telegram-Vorschau-Bearbeitungen sind deaktiviert, und generisches Tool-/Fortschrittsrauschen wird unterdrückt, statt als eigenständige Statusmeldungen gesendet zu werden. Genehmigungsabfragen, Mediennutzlasten und Fehler laufen weiterhin über die normale finale Zustellung. Verwenden Sie `streaming.preview.toolProgress: false`, wenn Sie nur Antwortvorschau-Bearbeitungen beibehalten möchten, während Sie die Statuszeilen zum Tool-Fortschritt ausblenden. - Telegram-Antworten auf ausgewählte Zitate sind die Ausnahme. Wenn `replyToMode` `"first"`, `"all"` oder `"batched"` ist und die eingehende Nachricht ausgewählten Zitattext enthält, sendet OpenClaw die finale Antwort über Telegrams nativen Zitat-Antwortpfad, statt die Antwortvorschau zu bearbeiten. Daher kann `streaming.preview.toolProgress` die kurzen Statuszeilen für diesen Durchlauf nicht anzeigen. Antworten auf aktuelle Nachrichten ohne ausgewählten Zitattext behalten weiterhin Preview Streaming. Setzen Sie `replyToMode: "off"`, wenn die Sichtbarkeit des Tool-Fortschritts wichtiger ist als native Zitatantworten, oder setzen Sie `streaming.preview.toolProgress: false`, um den Kompromiss bewusst zu akzeptieren. + Ausgewählte Telegram-Zitatantworten sind die Ausnahme. Wenn `replyToMode` `"first"`, `"all"` oder `"batched"` ist und die eingehende Nachricht ausgewählten Zitattext enthält, sendet OpenClaw die finale Antwort über Telegrams nativen Zitatantwort-Pfad, statt die Antwortvorschau zu bearbeiten. Deshalb kann `streaming.preview.toolProgress` für diesen Durchlauf die kurzen Statuszeilen nicht anzeigen. Antworten auf die aktuelle Nachricht ohne ausgewählten Zitattext behalten weiterhin Vorschau-Streaming bei. Setzen Sie `replyToMode: "off"`, wenn Sichtbarkeit des Tool-Fortschritts wichtiger ist als native Zitatantworten, oder setzen Sie `streaming.preview.toolProgress: false`, um den Kompromiss anzuerkennen. Für reine Textantworten: - - kurze DM-/Gruppen-/Themenvorschauen: OpenClaw behält dieselbe Vorschaunachricht bei und führt eine finale Bearbeitung an Ort und Stelle aus, sofern nach dem Erscheinen der Vorschau keine sichtbare Nicht-Vorschaunachricht gesendet wurde - - Vorschauen, gefolgt von sichtbarer Nicht-Vorschauausgabe: OpenClaw sendet die fertige Antwort als neue finale Nachricht und räumt die ältere Vorschau auf, sodass die finale Antwort nach der Zwischenausgabe erscheint - - Vorschauen, die älter als etwa eine Minute sind: OpenClaw sendet die fertige Antwort als neue finale Nachricht und räumt anschließend die Vorschau auf, sodass Telegrams sichtbarer Zeitstempel die Abschlusszeit statt der Erstellungszeit der Vorschau widerspiegelt + - kurze DM-/Gruppen-/Themenvorschauen: OpenClaw behält dieselbe Vorschaunachricht bei und führt eine finale Bearbeitung direkt dort aus, sofern nach dem Erscheinen der Vorschau keine sichtbare Nicht-Vorschaunachricht gesendet wurde + - Vorschauen, denen sichtbare Nicht-Vorschauausgabe folgt: OpenClaw sendet die abgeschlossene Antwort als neue finale Nachricht und räumt die ältere Vorschau auf, sodass die finale Antwort nach der Zwischenausgabe erscheint + - Vorschauen, die älter als etwa eine Minute sind: OpenClaw sendet die abgeschlossene Antwort als neue finale Nachricht und räumt danach die Vorschau auf, sodass Telegrams sichtbarer Zeitstempel die Abschlusszeit statt der Erstellungszeit der Vorschau widerspiegelt - Bei komplexen Antworten (zum Beispiel Medien-Payloads) fällt OpenClaw auf die normale finale Auslieferung zurück und räumt anschließend die Vorschaunachricht auf. + Bei komplexen Antworten (zum Beispiel Mediennutzlasten) fällt OpenClaw auf die normale finale Zustellung zurück und räumt anschließend die Vorschaunachricht auf. - Preview Streaming ist getrennt von Block Streaming. Wenn Block Streaming für Telegram ausdrücklich aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden. + Vorschau-Streaming ist getrennt von Block-Streaming. Wenn Block-Streaming für Telegram explizit aktiviert ist, überspringt OpenClaw den Vorschaustream, um doppeltes Streaming zu vermeiden. Reiner Telegram-Reasoning-Stream: - `/reasoning stream` sendet Reasoning während der Generierung an die Live-Vorschau - - die Reasoning-Vorschau wird nach der finalen Auslieferung gelöscht; verwenden Sie `/reasoning on`, wenn Reasoning sichtbar bleiben soll + - die Reasoning-Vorschau wird nach finaler Zustellung gelöscht; verwenden Sie `/reasoning on`, wenn Reasoning sichtbar bleiben soll - die finale Antwort wird ohne Reasoning-Text gesendet @@ -333,8 +369,8 @@ curl "https://api.telegram.org/bot/getUpdates" Ausgehender Text verwendet Telegram `parse_mode: "HTML"`. - - Markdown-ähnlicher Text wird zu Telegram-sicherem HTML gerendert. - - Rohes Modell-HTML wird escaped, um Telegram-Parsefehler zu reduzieren. + - Markdown-ähnlicher Text wird in Telegram-sicheres HTML gerendert. + - Rohes Modell-HTML wird escaped, um Telegram-Parse-Fehler zu reduzieren. - Wenn Telegram geparstes HTML ablehnt, versucht OpenClaw es erneut als Klartext. Linkvorschauen sind standardmäßig aktiviert und können mit `channels.telegram.linkPreview: false` deaktiviert werden. @@ -348,7 +384,7 @@ curl "https://api.telegram.org/bot/getUpdates" - `commands.native: "auto"` aktiviert native Befehle für Telegram - Fügen Sie benutzerdefinierte Befehlsmenüeinträge hinzu: + Benutzerdefinierte Befehlsmenüeinträge hinzufügen: ```json5 { @@ -365,7 +401,7 @@ curl "https://api.telegram.org/bot/getUpdates" Regeln: - - Namen werden normalisiert (führendes `/` entfernen, Kleinschreibung) + - Namen werden normalisiert (führendes `/` entfernen, Kleinbuchstaben) - gültiges Muster: `a-z`, `0-9`, `_`, Länge `1..32` - benutzerdefinierte Befehle können native Befehle nicht überschreiben - Konflikte/Duplikate werden übersprungen und protokolliert @@ -373,38 +409,38 @@ curl "https://api.telegram.org/bot/getUpdates" Hinweise: - benutzerdefinierte Befehle sind nur Menüeinträge; sie implementieren kein Verhalten automatisch - - Plugin-/Skills-Befehle können weiterhin funktionieren, wenn sie eingegeben werden, auch wenn sie nicht im Telegram-Menü angezeigt werden + - Plugin-/Skill-Befehle können bei Eingabe weiterhin funktionieren, auch wenn sie im Telegram-Menü nicht angezeigt werden Wenn native Befehle deaktiviert sind, werden integrierte Befehle entfernt. Benutzerdefinierte/Plugin-Befehle können sich weiterhin registrieren, wenn sie konfiguriert sind. Häufige Einrichtungsfehler: - - `setMyCommands failed` mit `BOT_COMMANDS_TOO_MUCH` bedeutet, dass das Telegram-Menü nach dem Kürzen immer noch überlaufen ist; reduzieren Sie Plugin-/Skills-/benutzerdefinierte Befehle oder deaktivieren Sie `channels.telegram.commands.native`. - - Wenn `deleteWebhook`, `deleteMyCommands` oder `setMyCommands` mit `404: Not Found` fehlschlägt, während direkte Bot-API-curl-Befehle funktionieren, kann das bedeuten, dass `channels.telegram.apiRoot` auf den vollständigen `/bot`-Endpunkt gesetzt wurde. `apiRoot` darf nur der Bot-API-Root sein, und `openclaw doctor --fix` entfernt ein versehentlich angehängtes `/bot`. - - `getMe returned 401` bedeutet, dass Telegram das konfigurierte Bot-Token abgelehnt hat. Aktualisieren Sie `botToken`, `tokenFile` oder `TELEGRAM_BOT_TOKEN` mit dem aktuellen BotFather-Token; OpenClaw stoppt vor dem Polling, sodass dies nicht als Webhook-Aufräumfehler gemeldet wird. + - `setMyCommands failed` mit `BOT_COMMANDS_TOO_MUCH` bedeutet, dass das Telegram-Menü nach dem Kürzen weiterhin überfüllt war; reduzieren Sie Plugin-/Skill-/benutzerdefinierte Befehle oder deaktivieren Sie `channels.telegram.commands.native`. + - Wenn `deleteWebhook`, `deleteMyCommands` oder `setMyCommands` mit `404: Not Found` fehlschlagen, während direkte Bot-API-curl-Befehle funktionieren, kann das bedeuten, dass `channels.telegram.apiRoot` auf den vollständigen `/bot`-Endpunkt gesetzt wurde. `apiRoot` darf nur der Bot-API-Root sein, und `openclaw doctor --fix` entfernt ein versehentliches abschließendes `/bot`. + - `getMe returned 401` bedeutet, dass Telegram das konfigurierte Bot-Token abgelehnt hat. Aktualisieren Sie `botToken`, `tokenFile` oder `TELEGRAM_BOT_TOKEN` mit dem aktuellen BotFather-Token; OpenClaw stoppt vor dem Polling, daher wird dies nicht als Webhook-Bereinigungsfehler gemeldet. - `setMyCommands failed` mit Netzwerk-/Fetch-Fehlern bedeutet normalerweise, dass ausgehendes DNS/HTTPS zu `api.telegram.org` blockiert ist. - ### Gerätekopplungsbefehle (`device-pair`-Plugin) + ### Befehle zur Gerätekopplung (`device-pair`-Plugin) Wenn das `device-pair`-Plugin installiert ist: 1. `/pair` erzeugt Einrichtungscode - 2. Code in der iOS-App einfügen + 2. Code in die iOS-App einfügen 3. `/pair pending` listet ausstehende Anfragen auf (einschließlich Rolle/Scopes) - 4. Anfrage genehmigen: - - `/pair approve ` für ausdrückliche Genehmigung - - `/pair approve`, wenn es nur eine ausstehende Anfrage gibt - - `/pair approve latest` für die neueste + 4. die Anfrage genehmigen: + - `/pair approve ` für explizite Genehmigung + - `/pair approve`, wenn nur eine ausstehende Anfrage vorhanden ist + - `/pair approve latest` für die aktuellste Anfrage - Der Einrichtungscode enthält ein kurzlebiges Bootstrap-Token. Die integrierte Bootstrap-Übergabe hält das primäre Node-Token bei `scopes: []`; jedes übergebene Operator-Token bleibt auf `operator.approvals`, `operator.read`, `operator.talk.secrets` und `operator.write` begrenzt. Bootstrap-Scope-Prüfungen sind rollenpräfixiert, sodass diese Operator-Allowlist nur Operator-Anfragen erfüllt; Nicht-Operator-Rollen benötigen weiterhin Scopes unter ihrem eigenen Rollenpräfix. + Der Einrichtungscode trägt ein kurzlebiges Bootstrap-Token. Die integrierte Bootstrap-Übergabe belässt das primäre Node-Token bei `scopes: []`; jedes übergebene Operator-Token bleibt auf `operator.approvals`, `operator.read`, `operator.talk.secrets` und `operator.write` begrenzt. Bootstrap-Scope-Prüfungen sind rollenpräfixiert, daher erfüllt diese Operator-Allowlist nur Operator-Anfragen; Nicht-Operator-Rollen benötigen weiterhin Scopes unter ihrem eigenen Rollenpräfix. - Wenn ein Gerät es mit geänderten Authentifizierungsdetails erneut versucht (zum Beispiel Rolle/Scopes/öffentlicher Schlüssel), wird die vorherige ausstehende Anfrage ersetzt und die neue Anfrage verwendet eine andere `requestId`. Führen Sie `/pair pending` vor der Genehmigung erneut aus. + Wenn ein Gerät mit geänderten Authentifizierungsdetails erneut versucht (zum Beispiel Rolle/Scopes/öffentlicher Schlüssel), wird die vorherige ausstehende Anfrage ersetzt und die neue Anfrage verwendet eine andere `requestId`. Führen Sie `/pair pending` erneut aus, bevor Sie genehmigen. Weitere Details: [Kopplung](/de/channels/pairing#pair-via-telegram-recommended-for-ios). - + Inline-Tastatur-Scope konfigurieren: ```json5 @@ -445,9 +481,9 @@ curl "https://api.telegram.org/bot/getUpdates" - `all` - `allowlist` (Standard) - Veraltetes `capabilities: ["inlineButtons"]` wird auf `inlineButtons: "all"` abgebildet. + Veraltetes `capabilities: ["inlineButtons"]` wird `inlineButtons: "all"` zugeordnet. - Beispiel für eine Nachrichtenaktion: + Beispiel für Nachrichtenaktion: ```json5 { @@ -465,13 +501,13 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Callback-Klicks werden als Text an den Agenten übergeben: + Callback-Klicks werden als Text an den Agent übergeben: `callback_data: ` - - Telegram-Tool-Aktionen umfassen: + + Telegram-Tool-Aktionen enthalten: - `sendMessage` (`to`, `content`, optional `mediaUrl`, `replyToMessageId`, `messageThreadId`) - `react` (`chatId`, `messageId`, `emoji`) @@ -479,9 +515,9 @@ curl "https://api.telegram.org/bot/getUpdates" - `editMessage` (`chatId`, `messageId`, `content`) - `createForumTopic` (`chatId`, `name`, optional `iconColor`, `iconCustomEmojiId`) - Channel-Nachrichtenaktionen stellen ergonomische Aliase bereit (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). + Channel-Nachrichtenaktionen stellen ergonomische Aliasse bereit (`send`, `react`, `delete`, `edit`, `sticker`, `sticker-search`, `topic-create`). - Gating-Steuerungen: + Gating-Steuerelemente: - `channels.telegram.actions.sendMessage` - `channels.telegram.actions.deleteMessage` @@ -489,14 +525,14 @@ curl "https://api.telegram.org/bot/getUpdates" - `channels.telegram.actions.sticker` (Standard: deaktiviert) Hinweis: `edit` und `topic-create` sind derzeit standardmäßig aktiviert und haben keine separaten `channels.telegram.actions.*`-Schalter. - Laufzeit-Sendevorgänge verwenden den aktiven Konfigurations-/Secrets-Snapshot (Start/Reload), sodass Aktionspfade keine Ad-hoc-Neuauflösung von SecretRef pro Sendevorgang durchführen. + Laufzeit-Sends verwenden den aktiven Config-/Secrets-Snapshot (Start/Reload), daher führen Aktionspfade keine Ad-hoc-Neuauflösung von SecretRef pro Send aus. - Semantik zum Entfernen von Reaktionen: [/tools/reactions](/de/tools/reactions) + Semantik zum Entfernen von Reactions: [/tools/reactions](/de/tools/reactions) - - Telegram unterstützt explizite Antwort-Threading-Tags in generierter Ausgabe: + + Telegram unterstützt explizite Tags für Antwort-Threading in generierter Ausgabe: - `[[reply_to_current]]` antwortet auf die auslösende Nachricht - `[[reply_to:]]` antwortet auf eine bestimmte Telegram-Nachrichten-ID @@ -507,29 +543,29 @@ curl "https://api.telegram.org/bot/getUpdates" - `first` - `all` - Wenn Antwort-Threading aktiviert ist und der ursprüngliche Telegram-Text oder die Beschriftung verfügbar ist, fügt OpenClaw automatisch einen nativen Telegram-Zitatauszug ein. Telegram begrenzt nativen Zitattext auf 1024 UTF-16-Codeeinheiten, sodass längere Nachrichten vom Anfang an zitiert werden und auf eine einfache Antwort zurückfallen, wenn Telegram das Zitat ablehnt. + Wenn Antwort-Threading aktiviert ist und der ursprüngliche Telegram-Text oder die Beschriftung verfügbar ist, fügt OpenClaw automatisch einen nativen Telegram-Zitatauszug ein. Telegram begrenzt nativen Zitattext auf 1024 UTF-16-Codeeinheiten, daher werden längere Nachrichten vom Anfang an zitiert und fallen auf eine einfache Antwort zurück, wenn Telegram das Zitat ablehnt. Hinweis: `off` deaktiviert implizites Antwort-Threading. Explizite `[[reply_to_*]]`-Tags werden weiterhin berücksichtigt. - + Forum-Supergruppen: - - Themenschlüssel für Sessions hängen `:topic:` an - - Antworten und Tippen zielen auf den Themen-Thread - - Pfad der Themenkonfiguration: + - Themen-Sitzungsschlüssel hängen `:topic:` an + - Antworten und Tippanzeige zielen auf den Themen-Thread + - Themen-Config-Pfad: `channels.telegram.groups..topics.` - Sonderfall allgemeines Thema (`threadId=1`): + Spezialfall allgemeines Thema (`threadId=1`): - - Nachrichtensendungen lassen `message_thread_id` weg (Telegram lehnt `sendMessage(...thread_id=1)` ab) + - Nachrichten-Sends lassen `message_thread_id` aus (Telegram lehnt `sendMessage(...thread_id=1)` ab) - Tippaktionen enthalten weiterhin `message_thread_id` Themenvererbung: Themeneinträge erben Gruppeneinstellungen, sofern sie nicht überschrieben werden (`requireMention`, `allowFrom`, `skills`, `systemPrompt`, `enabled`, `groupPolicy`). - `agentId` ist themenspezifisch und erbt nicht von Gruppenvorgaben. + `agentId` ist nur themenspezifisch und wird nicht von Gruppenstandardwerten geerbt. - **Agent-Routing pro Thema**: Jedes Thema kann durch Setzen von `agentId` in der Themenkonfiguration an einen anderen Agenten weitergeleitet werden. Dadurch erhält jedes Thema seinen eigenen isolierten Workspace, Speicher und seine eigene Session. Beispiel: + **Agent-Routing pro Thema**: Jedes Thema kann zu einem anderen Agent routen, indem `agentId` in der Themen-Config gesetzt wird. Dadurch erhält jedes Thema seinen eigenen isolierten Workspace, Speicher und seine eigene Sitzung. Beispiel: ```json5 { @@ -549,28 +585,28 @@ curl "https://api.telegram.org/bot/getUpdates" } ``` - Danach hat jedes Thema seinen eigenen Session-Schlüssel: `agent:zu:telegram:group:-1001234567890:topic:3` + Jedes Thema hat dann seinen eigenen Sitzungsschlüssel: `agent:zu:telegram:group:-1001234567890:topic:3` - **Persistente ACP-Themenbindung**: Forumsthemen können ACP-Harness-Sessions über typisierte ACP-Bindings auf oberster Ebene pinnen (`bindings[]` mit `type: "acp"` und `match.channel: "telegram"`, `peer.kind: "group"` sowie einer themenqualifizierten ID wie `-1001234567890:topic:42`). Derzeit auf Forumsthemen in Gruppen/Supergruppen begrenzt. Siehe [ACP-Agenten](/de/tools/acp-agents). + **Persistente ACP-Themenbindung**: Forumthemen können ACP-Harness-Sitzungen über typisierte ACP-Bindings der obersten Ebene anpinnen (`bindings[]` mit `type: "acp"` und `match.channel: "telegram"`, `peer.kind: "group"` sowie einer themenqualifizierten ID wie `-1001234567890:topic:42`). Derzeit auf Forumthemen in Gruppen/Supergruppen beschränkt. Siehe [ACP Agents](/de/tools/acp-agents). - **Thread-gebundener ACP-Spawn aus dem Chat**: `/acp spawn --thread here|auto` bindet das aktuelle Thema an eine neue ACP-Session; Folgeanfragen werden direkt dorthin geleitet. OpenClaw pinnt die Spawn-Bestätigung im Thema. Erfordert, dass `channels.telegram.threadBindings.spawnSessions` aktiviert bleibt (Standard: `true`). + **Thread-gebundener ACP-Spawn aus dem Chat**: `/acp spawn --thread here|auto` bindet das aktuelle Thema an eine neue ACP-Sitzung; Folgebeiträge werden direkt dorthin geroutet. OpenClaw pinnt die Spawn-Bestätigung im Thema an. Erfordert, dass `channels.telegram.threadBindings.spawnSessions` aktiviert bleibt (Standard: `true`). - Der Template-Kontext stellt `MessageThreadId` und `IsForum` bereit. DM-Chats mit `message_thread_id` behalten standardmäßig DM-Routing und Antwortmetadaten auf flachen Sessions; sie verwenden thread-bewusste Session-Schlüssel nur, wenn sie mit `threadReplies: "inbound"`, `threadReplies: "always"`, `requireTopic: true` oder einer passenden Themenkonfiguration konfiguriert sind. Verwenden Sie `channels.telegram.dm.threadReplies` auf oberster Ebene für die Kontovorgabe oder `direct..threadReplies` für eine einzelne DM. + Der Template-Kontext stellt `MessageThreadId` und `IsForum` bereit. DM-Chats mit `message_thread_id` behalten standardmäßig DM-Routing und Antwortmetadaten in flachen Sitzungen bei; thread-aware Sitzungsschlüssel werden nur verwendet, wenn `threadReplies: "inbound"`, `threadReplies: "always"`, `requireTopic: true` oder eine passende Themenkonfiguration konfiguriert ist. Verwenden Sie `channels.telegram.dm.threadReplies` auf oberster Ebene für den Kontostandard oder `direct..threadReplies` für eine einzelne DM. ### Audionachrichten - Telegram unterscheidet Sprachnotizen von Audiodateien. + Telegram unterscheidet Sprachnachrichten von Audiodateien. - Standard: Audiodateiverhalten - - Tag `[[audio_as_voice]]` in der Agentenantwort, um das Senden als Sprachnotiz zu erzwingen - - Eingehende Sprachnotiz-Transkripte werden im Agentenkontext als maschinell erzeugter, - nicht vertrauenswürdiger Text gerahmt; Erwähnungserkennung verwendet weiterhin das rohe - Transkript, sodass erwähnungsgesteuerte Sprachnachrichten weiterhin funktionieren. + - Tag `[[audio_as_voice]]` in der Agent-Antwort, um das Senden als Sprachnachricht zu erzwingen + - Eingehende Transkripte von Sprachnachrichten werden im Agent-Kontext als maschinell erzeugter, + nicht vertrauenswürdiger Text gerahmt; die Erwähnungserkennung verwendet weiterhin das rohe + Transkript, sodass erwähnungsgesteuerte Sprachnachrichten weiter funktionieren. - Beispiel für eine Nachrichtenaktion: + Beispiel für Nachrichtenaktion: ```json5 { @@ -586,7 +622,7 @@ curl "https://api.telegram.org/bot/getUpdates" Telegram unterscheidet Videodateien von Videonotizen. - Beispiel für eine Nachrichtenaktion: + Beispiel für Nachrichtenaktion: ```json5 { @@ -602,7 +638,7 @@ curl "https://api.telegram.org/bot/getUpdates" ### Sticker - Behandlung eingehender Sticker: + Verarbeitung eingehender Sticker: - statisches WEBP: heruntergeladen und verarbeitet (Platzhalter ``) - animiertes TGS: übersprungen @@ -674,13 +710,13 @@ curl "https://api.telegram.org/bot/getUpdates" Hinweise: - - `own` bedeutet nur Benutzerreaktionen auf vom Bot gesendete Nachrichten (Best-Effort über den Cache gesendeter Nachrichten). - - Reaktionsereignisse beachten weiterhin die Telegram-Zugriffssteuerungen (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`); nicht autorisierte Absender werden verworfen. + - `own` bedeutet nur Benutzerreaktionen auf vom Bot gesendete Nachrichten (Best-Effort über Cache gesendeter Nachrichten). + - Reaktionsereignisse beachten weiterhin Telegram-Zugriffskontrollen (`dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`); nicht autorisierte Absender werden verworfen. - Telegram stellt in Reaktions-Updates keine Thread-IDs bereit. - - Nicht-Forum-Gruppen werden an die Gruppenchat-Sitzung geleitet - - Forum-Gruppen werden an die allgemeine Themen-Sitzung der Gruppe (`:topic:1`) geleitet, nicht an das exakte ursprüngliche Thema + - Nicht-Forum-Gruppen routen zur Gruppenchat-Sitzung + - Forum-Gruppen routen zur Sitzung des allgemeinen Themas der Gruppe (`:topic:1`), nicht zum genauen ursprünglichen Thema - `allowed_updates` für Polling/Webhook enthält automatisch `message_reaction`. + `allowed_updates` für Polling/Webhook enthält `message_reaction` automatisch. @@ -692,19 +728,19 @@ curl "https://api.telegram.org/bot/getUpdates" - `channels.telegram.accounts..ackReaction` - `channels.telegram.ackReaction` - `messages.ackReaction` - - Fallback auf das Emoji der Agent-Identität (`agents.list[].identity.emoji`, andernfalls "👀") + - Fallback auf Emoji der Agent-Identität (`agents.list[].identity.emoji`, sonst "👀") Hinweise: - Telegram erwartet Unicode-Emoji (zum Beispiel "👀"). - - Verwenden Sie `""`, um die Reaktion für einen Kanal oder ein Konto zu deaktivieren. + - Verwenden Sie `""`, um die Reaktion für einen Channel oder ein Konto zu deaktivieren. - Schreibvorgänge für die Kanal-Konfiguration sind standardmäßig aktiviert (`configWrites !== false`). + Channel-Konfigurationsschreibvorgänge sind standardmäßig aktiviert (`configWrites !== false`). - Von Telegram ausgelöste Schreibvorgänge umfassen: + Durch Telegram ausgelöste Schreibvorgänge umfassen: - Gruppenmigrationsereignisse (`migrate_to_chat_id`) zum Aktualisieren von `channels.telegram.groups` - `/config set` und `/config unset` (erfordert aktivierte Befehle) @@ -724,31 +760,31 @@ curl "https://api.telegram.org/bot/getUpdates" - Standard ist Long Polling. Legen Sie für den Webhook-Modus `channels.telegram.webhookUrl` und `channels.telegram.webhookSecret` fest; optional `webhookPath`, `webhookHost`, `webhookPort` (Standardwerte `/telegram-webhook`, `127.0.0.1`, `8787`). + Standard ist Long Polling. Für den Webhook-Modus setzen Sie `channels.telegram.webhookUrl` und `channels.telegram.webhookSecret`; optional `webhookPath`, `webhookHost`, `webhookPort` (Standardwerte `/telegram-webhook`, `127.0.0.1`, `8787`). - Der lokale Listener bindet an `127.0.0.1:8787`. Für öffentlichen Ingress setzen Sie entweder einen Reverse-Proxy vor den lokalen Port oder legen `webhookHost: "0.0.0.0"` bewusst fest. + Der lokale Listener bindet an `127.0.0.1:8787`. Für öffentlichen Eingang setzen Sie entweder einen Reverse Proxy vor den lokalen Port oder setzen Sie bewusst `webhookHost: "0.0.0.0"`. - Der Webhook-Modus validiert Request-Guards, das geheime Telegram-Token und den JSON-Body, bevor `200` an Telegram zurückgegeben wird. - OpenClaw verarbeitet das Update dann asynchron über dieselben Bot-Lanes pro Chat/pro Thema wie beim Long Polling, sodass langsame Agent-Durchläufe das Zustellungs-ACK von Telegram nicht blockieren. + Der Webhook-Modus validiert Request Guards, das Telegram-Secret-Token und den JSON-Body, bevor `200` an Telegram zurückgegeben wird. + OpenClaw verarbeitet das Update anschließend asynchron über dieselben Bot-Lanes pro Chat/pro Thema wie beim Long Polling, sodass langsame Agent-Durchläufe das Zustellungs-ACK von Telegram nicht blockieren. - `channels.telegram.textChunkLimit` ist standardmäßig 4000. - - `channels.telegram.chunkMode="newline"` bevorzugt Absatzgrenzen (Leerzeilen) vor der Aufteilung nach Länge. + - `channels.telegram.chunkMode="newline"` bevorzugt Absatzgrenzen (Leerzeilen) vor der Längenaufteilung. - `channels.telegram.mediaMaxMb` (Standard 100) begrenzt die Größe eingehender und ausgehender Telegram-Medien. - - `channels.telegram.mediaGroupFlushMs` (Standard 500) steuert, wie lange Telegram-Alben/Mediengruppen gepuffert werden, bevor OpenClaw sie als eine eingehende Nachricht weitergibt. Erhöhen Sie den Wert, wenn Albumteile spät eintreffen; verringern Sie ihn, um die Antwortlatenz für Alben zu reduzieren. - - `channels.telegram.timeoutSeconds` überschreibt das Timeout des Telegram-API-Clients (wenn nicht gesetzt, gilt der grammY-Standard). Bot-Clients begrenzen konfigurierte Werte unterhalb des 60-Sekunden-Request-Guards für ausgehende Text-/Typing-Anfragen, damit grammY die sichtbare Antwortzustellung nicht abbricht, bevor OpenClaws Transport-Guard und Fallback ausgeführt werden können. Long Polling verwendet weiterhin einen 45-Sekunden-Request-Guard für `getUpdates`, damit inaktive Polls nicht unbegrenzt aufgegeben werden. + - `channels.telegram.mediaGroupFlushMs` (Standard 500) steuert, wie lange Telegram-Alben/Mediengruppen gepuffert werden, bevor OpenClaw sie als eine eingehende Nachricht ausliefert. Erhöhen Sie den Wert, wenn Albenteile verspätet eintreffen; verringern Sie ihn, um die Antwortlatenz für Alben zu reduzieren. + - `channels.telegram.timeoutSeconds` überschreibt das Timeout des Telegram-API-Clients (wenn nicht gesetzt, gilt der grammY-Standard). Bot-Clients begrenzen konfigurierte Werte unterhalb des 60-Sekunden-Guards für ausgehende Text-/Typing-Requests, damit grammY die sichtbare Antwortzustellung nicht abbricht, bevor OpenClaws Transport-Guard und Fallback ausgeführt werden können. Long Polling verwendet weiterhin einen 45-Sekunden-Request-Guard für `getUpdates`, damit inaktive Polls nicht unbegrenzt aufgegeben werden. - `channels.telegram.pollingStallThresholdMs` ist standardmäßig `120000`; passen Sie den Wert nur bei falsch-positiven Polling-Stall-Neustarts zwischen `30000` und `600000` an. - - Der Verlauf des Gruppenkontexts verwendet `channels.telegram.historyLimit` oder `messages.groupChat.historyLimit` (Standard 50); `0` deaktiviert ihn. - - Zusätzlicher Kontext für Antwort/Zitat/Weiterleitung wird derzeit so weitergegeben, wie er empfangen wurde. - - Telegram-Zulassungslisten steuern primär, wer den Agent auslösen kann, nicht eine vollständige Redaktionsgrenze für Zusatzkontext. - - Steuerungen für den DM-Verlauf: + - Gruppen-Kontexthistorie verwendet `channels.telegram.historyLimit` oder `messages.groupChat.historyLimit` (Standard 50); `0` deaktiviert sie. + - Ergänzender Kontext für Antworten/Zitate/Weiterleitungen wird derzeit unverändert weitergegeben. + - Telegram-Allowlists steuern hauptsächlich, wer den Agent auslösen kann, nicht eine vollständige Schwelle zur Schwärzung ergänzender Kontexte. + - DM-Historiensteuerung: - `channels.telegram.dmHistoryLimit` - `channels.telegram.dms[""].historyLimit` - - Die Konfiguration `channels.telegram.retry` gilt für Telegram-Sendehelfer (CLI/Tools/Aktionen) bei behebbaren ausgehenden API-Fehlern. Die Zustellung der endgültigen eingehenden Antwort verwendet ebenfalls eine begrenzte Safe-Send-Wiederholung bei Telegram-Fehlern vor der Verbindung, wiederholt jedoch keine mehrdeutigen Netzwerk-Hüllen nach dem Senden, die sichtbare Nachrichten duplizieren könnten. + - Die Konfiguration `channels.telegram.retry` gilt für Telegram-Sendehelfer (CLI/Tools/Aktionen) bei wiederherstellbaren ausgehenden API-Fehlern. Die Zustellung der endgültigen eingehenden Antwort verwendet ebenfalls eine begrenzte Safe-Send-Wiederholung bei Telegram-Fehlern vor der Verbindung, wiederholt aber keine mehrdeutigen Netzwerkumschläge nach dem Senden, die sichtbare Nachrichten duplizieren könnten. - Das CLI-Sendeziel kann eine numerische Chat-ID oder ein Benutzername sein: + CLI-Sendeziel kann eine numerische Chat-ID oder ein Benutzername sein: ```bash openclaw message send --channel telegram --target 123456789 --message "hi" @@ -765,7 +801,7 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ --poll-duration-seconds 300 --poll-public ``` - Nur-Telegram-Poll-Flags: + Nur für Telegram verfügbare Poll-Flags: - `--poll-duration-seconds` (5-600) - `--poll-anonymous` @@ -776,44 +812,44 @@ openclaw message poll --channel telegram --target -1001234567890:topic:42 \ - `--presentation` mit `buttons`-Blöcken für Inline-Tastaturen, wenn `channels.telegram.capabilities.inlineButtons` dies erlaubt - `--pin` oder `--delivery '{"pin":true}'`, um angeheftete Zustellung anzufordern, wenn der Bot in diesem Chat anheften kann - - `--force-document`, um ausgehende Bilder und GIFs als Dokumente statt als komprimierte Foto- oder animierte Medien-Uploads zu senden + - `--force-document`, um ausgehende Bilder und GIFs als Dokumente statt als komprimierte Foto- oder Animated-Media-Uploads zu senden - Aktions-Gating: + Aktionssteuerung: - `channels.telegram.actions.sendMessage=false` deaktiviert ausgehende Telegram-Nachrichten, einschließlich Polls - - `channels.telegram.actions.poll=false` deaktiviert das Erstellen von Telegram-Polls, während reguläre Sends aktiviert bleiben + - `channels.telegram.actions.poll=false` deaktiviert die Erstellung von Telegram-Polls, während reguläres Senden aktiviert bleibt - - Telegram unterstützt Exec-Genehmigungen in Genehmiger-DMs und kann Prompts optional im ursprünglichen Chat oder Thema posten. Genehmiger müssen numerische Telegram-Benutzer-IDs sein. + + Telegram unterstützt Exec-Freigaben in Freigabe-DMs und kann optional Prompts im ursprünglichen Chat oder Thema posten. Freigebende Personen müssen numerische Telegram-Benutzer-IDs sein. Konfigurationspfad: - - `channels.telegram.execApprovals.enabled` (aktiviert sich automatisch, wenn mindestens ein Genehmiger auflösbar ist) + - `channels.telegram.execApprovals.enabled` (wird automatisch aktiviert, wenn mindestens eine freigebende Person auflösbar ist) - `channels.telegram.execApprovals.approvers` (fällt auf numerische Besitzer-IDs aus `commands.ownerAllowFrom` zurück) - `channels.telegram.execApprovals.target`: `dm` (Standard) | `channel` | `both` - `agentFilter`, `sessionFilter` - `channels.telegram.allowFrom`, `groupAllowFrom` und `defaultTo` steuern, wer mit dem Bot sprechen kann und wohin er normale Antworten sendet. Sie machen niemanden zu einem Exec-Genehmiger. Die erste genehmigte DM-Kopplung bootstrapt `commands.ownerAllowFrom`, wenn noch kein Befehlsbesitzer vorhanden ist, sodass die Einrichtung mit einem Besitzer weiterhin funktioniert, ohne IDs unter `execApprovals.approvers` zu duplizieren. + `channels.telegram.allowFrom`, `groupAllowFrom` und `defaultTo` steuern, wer mit dem Bot sprechen kann und wohin er normale Antworten sendet. Sie machen niemanden zur exec-freigebenden Person. Die erste genehmigte DM-Kopplung initialisiert `commands.ownerAllowFrom`, wenn noch kein Befehlsbesitzer vorhanden ist, sodass die Einrichtung mit einem Besitzer weiterhin funktioniert, ohne IDs unter `execApprovals.approvers` zu duplizieren. - Die Kanalzustellung zeigt den Befehlstext im Chat; aktivieren Sie `channel` oder `both` nur in vertrauenswürdigen Gruppen/Themen. Wenn der Prompt in einem Forum-Thema landet, bewahrt OpenClaw das Thema für den Genehmigungs-Prompt und die Folgeaktion. Exec-Genehmigungen laufen standardmäßig nach 30 Minuten ab. + Die Channel-Zustellung zeigt den Befehlstext im Chat; aktivieren Sie `channel` oder `both` nur in vertrauenswürdigen Gruppen/Themen. Wenn der Prompt in einem Forum-Thema landet, behält OpenClaw das Thema für den Freigabe-Prompt und die Folgeaktion bei. Exec-Freigaben laufen standardmäßig nach 30 Minuten ab. - Inline-Genehmigungsbuttons erfordern außerdem, dass `channels.telegram.capabilities.inlineButtons` die Zieloberfläche (`dm`, `group` oder `all`) erlaubt. Genehmigungs-IDs mit dem Präfix `plugin:` werden über Plugin-Genehmigungen aufgelöst; andere werden zuerst über Exec-Genehmigungen aufgelöst. + Inline-Freigabeschaltflächen erfordern außerdem, dass `channels.telegram.capabilities.inlineButtons` die Zieloberfläche (`dm`, `group` oder `all`) erlaubt. Freigabe-IDs mit Präfix `plugin:` werden über Plugin-Freigaben aufgelöst; andere werden zuerst über Exec-Freigaben aufgelöst. - Siehe [Exec-Genehmigungen](/de/tools/exec-approvals). + Siehe [Exec-Freigaben](/de/tools/exec-approvals). ## Steuerung von Fehlerantworten -Wenn der Agent auf einen Zustellungs- oder Provider-Fehler stößt, kann Telegram entweder mit dem Fehlertext antworten oder ihn unterdrücken. Zwei Konfigurationsschlüssel steuern dieses Verhalten: +Wenn der Agent auf einen Zustellungs- oder Provider-Fehler trifft, kann Telegram entweder mit dem Fehlertext antworten oder ihn unterdrücken. Zwei Konfigurationsschlüssel steuern dieses Verhalten: -| Schlüssel | Werte | Standard | Beschreibung | -| ----------------------------------- | ----------------- | -------- | --------------------------------------------------------------------------------------------------------- | +| Schlüssel | Werte | Standard | Beschreibung | +| ----------------------------------- | ----------------- | -------- | ---------------------------------------------------------------------------------------------------- | | `channels.telegram.errorPolicy` | `reply`, `silent` | `reply` | `reply` sendet eine freundliche Fehlermeldung an den Chat. `silent` unterdrückt Fehlerantworten vollständig. | -| `channels.telegram.errorCooldownMs` | Zahl (ms) | `60000` | Mindestzeit zwischen Fehlerantworten an denselben Chat. Verhindert Fehler-Spam während Ausfällen. | +| `channels.telegram.errorCooldownMs` | Zahl (ms) | `60000` | Mindestzeit zwischen Fehlerantworten an denselben Chat. Verhindert Fehler-Spam während Ausfällen. | Überschreibungen pro Konto, pro Gruppe und pro Thema werden unterstützt (dieselbe Vererbung wie bei anderen Telegram-Konfigurationsschlüsseln). @@ -836,31 +872,31 @@ Wenn der Agent auf einen Zustellungs- oder Provider-Fehler stößt, kann Telegra ## Fehlerbehebung - + - - Wenn `requireMention=false`, muss der Telegram-Privatsphäre-Modus vollständige Sichtbarkeit erlauben. + - Wenn `requireMention=false`, muss der Telegram-Privatsphärenmodus vollständige Sichtbarkeit erlauben. - BotFather: `/setprivacy` -> Deaktivieren - - Entfernen Sie den Bot anschließend aus der Gruppe und fügen Sie ihn erneut hinzu - - `openclaw channels status` warnt, wenn die Konfiguration Gruppennachrichten ohne Erwähnung erwartet. - - `openclaw channels status --probe` kann explizite numerische Gruppen-IDs prüfen; die Wildcard `"*"` kann nicht auf Mitgliedschaft geprüft werden. + - entfernen Sie den Bot anschließend aus der Gruppe und fügen Sie ihn erneut hinzu + - `openclaw channels status` warnt, wenn die Konfiguration nicht erwähnte Gruppennachrichten erwartet. + - `openclaw channels status --probe` kann explizite numerische Gruppen-IDs prüfen; Wildcard `"*"` kann nicht auf Mitgliedschaft geprüft werden. - Schneller Sitzungstest: `/activation always`. - - Wenn `channels.telegram.groups` vorhanden ist, muss die Gruppe aufgeführt sein (oder `"*"` enthalten) - - Bot-Mitgliedschaft in der Gruppe verifizieren - - Logs prüfen: `openclaw logs --follow` für Gründe zum Überspringen + - wenn `channels.telegram.groups` vorhanden ist, muss die Gruppe aufgeführt sein (oder `"*"` enthalten) + - Bot-Mitgliedschaft in der Gruppe prüfen + - Logs prüfen: `openclaw logs --follow` für Gründe für das Überspringen - - Autorisieren Sie Ihre Absenderidentität (Kopplung und/oder numerisches `allowFrom`) + - autorisieren Sie Ihre Absenderidentität (Pairing und/oder numerisches `allowFrom`) - Befehlsautorisierung gilt weiterhin, auch wenn die Gruppenrichtlinie `open` ist - `setMyCommands failed` mit `BOT_COMMANDS_TOO_MUCH` bedeutet, dass das native Menü zu viele Einträge hat; reduzieren Sie Plugin-/Skill-/benutzerdefinierte Befehle oder deaktivieren Sie native Menüs - - `deleteMyCommands`- / `setMyCommands`-Startaufrufe und `sendChatAction`-Typing-Aufrufe sind begrenzt und werden bei Request-Timeout einmal über Telegrams Transport-Fallback wiederholt. Anhaltende Netzwerk-/Fetch-Fehler weisen in der Regel auf DNS-/HTTPS-Erreichbarkeitsprobleme zu `api.telegram.org` hin + - `deleteMyCommands`- / `setMyCommands`-Startaufrufe und `sendChatAction`-Tippaufrufe sind begrenzt und werden bei einem Anfrage-Timeout einmal über Telegrams Transport-Fallback erneut versucht. Anhaltende Netzwerk-/Fetch-Fehler weisen üblicherweise auf DNS-/HTTPS-Erreichbarkeitsprobleme zu `api.telegram.org` hin @@ -868,24 +904,24 @@ Wenn der Agent auf einen Zustellungs- oder Provider-Fehler stößt, kann Telegra - `getMe returned 401` ist ein Telegram-Authentifizierungsfehler für das konfigurierte Bot-Token. - Kopieren oder generieren Sie das Bot-Token in BotFather erneut und aktualisieren Sie dann `channels.telegram.botToken`, `channels.telegram.tokenFile`, `channels.telegram.accounts..botToken` oder `TELEGRAM_BOT_TOKEN` für das Standardkonto. - - `deleteWebhook 401 Unauthorized` beim Start ist ebenfalls ein Authentifizierungsfehler; dies als „kein Webhook vorhanden“ zu behandeln, würde denselben Fehler durch ein ungültiges Token nur auf spätere API-Aufrufe verschieben. + - `deleteWebhook 401 Unauthorized` während des Starts ist ebenfalls ein Authentifizierungsfehler; es als „kein Webhook vorhanden“ zu behandeln, würde denselben Fehler durch ein ungültiges Token nur auf spätere API-Aufrufe verschieben. - + - - Node 22+ + benutzerdefiniertes fetch/Proxy kann sofortiges Abbruchverhalten auslösen, wenn AbortSignal-Typen nicht übereinstimmen. - - Einige Hosts lösen `api.telegram.org` zuerst zu IPv6 auf; defekter IPv6-Egress kann zu zeitweiligen Telegram-API-Fehlern führen. - - Wenn Logs `TypeError: fetch failed` oder `Network request for 'getUpdates' failed!` enthalten, wiederholt OpenClaw diese nun als wiederherstellbare Netzwerkfehler. - - Beim Polling-Start verwendet OpenClaw den erfolgreichen Start-`getMe`-Probe für grammY wieder, sodass der Runner vor dem ersten `getUpdates` keinen zweiten `getMe` benötigt. - - Wenn `deleteWebhook` beim Polling-Start mit einem vorübergehenden Netzwerkfehler fehlschlägt, fährt OpenClaw mit Long Polling fort, statt einen weiteren Control-Plane-Aufruf vor dem Polling auszuführen. Ein weiterhin aktiver Webhook erscheint als `getUpdates`-Konflikt; OpenClaw baut dann den Telegram-Transport neu auf und versucht die Webhook-Bereinigung erneut. - - Wenn Telegram-Sockets in einem kurzen festen Takt wiederverwendet werden, prüfen Sie auf einen niedrigen Wert für `channels.telegram.timeoutSeconds`; Bot-Clients begrenzen konfigurierte Werte unterhalb der ausgehenden und `getUpdates`-Request-Guards, ältere Releases konnten jedoch jeden Poll oder jede Antwort abbrechen, wenn dies unter diese Guards gesetzt war. - - Wenn Logs `Polling stall detected` enthalten, startet OpenClaw standardmäßig das Polling neu und baut den Telegram-Transport neu auf, nachdem 120 Sekunden lang keine abgeschlossene Long-Poll-Liveness festgestellt wurde. + - Node 22+ mit benutzerdefiniertem Fetch/Proxy kann sofortiges Abbruchverhalten auslösen, wenn AbortSignal-Typen nicht übereinstimmen. + - Einige Hosts lösen `api.telegram.org` zuerst nach IPv6 auf; fehlerhafter IPv6-Egress kann zeitweilige Telegram-API-Fehler verursachen. + - Wenn Logs `TypeError: fetch failed` oder `Network request for 'getUpdates' failed!` enthalten, versucht OpenClaw diese jetzt als wiederherstellbare Netzwerkfehler erneut. + - Beim Polling-Start verwendet OpenClaw die erfolgreiche `getMe`-Startprüfung für grammY erneut, sodass der Runner vor dem ersten `getUpdates` kein zweites `getMe` benötigt. + - Wenn `deleteWebhook` beim Polling-Start mit einem vorübergehenden Netzwerkfehler fehlschlägt, fährt OpenClaw mit Long Polling fort, statt einen weiteren Control-Plane-Aufruf vor dem Polling auszuführen. Ein weiterhin aktiver Webhook zeigt sich als `getUpdates`-Konflikt; OpenClaw baut dann den Telegram-Transport neu auf und versucht die Webhook-Bereinigung erneut. + - Wenn Telegram-Sockets in einem kurzen festen Takt wiederverwendet werden, prüfen Sie auf einen niedrigen Wert für `channels.telegram.timeoutSeconds`; Bot-Clients begrenzen konfigurierte Werte unterhalb der Guards für ausgehende Anfragen und `getUpdates`, aber ältere Releases konnten jeden Poll oder jede Antwort abbrechen, wenn dieser Wert unter diesen Guards lag. + - Wenn Logs `Polling stall detected` enthalten, startet OpenClaw das Polling neu und baut den Telegram-Transport nach standardmäßig 120 Sekunden ohne abgeschlossene Long-Poll-Liveness neu auf. - `openclaw channels status --probe` und `openclaw doctor` warnen, wenn ein laufendes Polling-Konto nach der Start-Kulanzzeit `getUpdates` nicht abgeschlossen hat, wenn ein laufendes Webhook-Konto nach der Start-Kulanzzeit `setWebhook` nicht abgeschlossen hat oder wenn die letzte erfolgreiche Polling-Transportaktivität veraltet ist. - - Erhöhen Sie `channels.telegram.pollingStallThresholdMs` nur, wenn lang laufende `getUpdates`-Aufrufe gesund sind, Ihr Host aber weiterhin fälschliche Polling-Stall-Neustarts meldet. Dauerhafte Stalls deuten in der Regel auf Proxy-, DNS-, IPv6- oder TLS-Egress-Probleme zwischen dem Host und `api.telegram.org` hin. - - Telegram berücksichtigt für den Bot-API-Transport auch Prozess-Proxy-Umgebungsvariablen, einschließlich `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` und deren Kleinschreibungsvarianten. `NO_PROXY` / `no_proxy` kann `api.telegram.org` weiterhin umgehen. + - Erhöhen Sie `channels.telegram.pollingStallThresholdMs` nur, wenn lang laufende `getUpdates`-Aufrufe fehlerfrei sind, Ihr Host aber weiterhin fälschliche Polling-Stall-Neustarts meldet. Anhaltende Stalls weisen üblicherweise auf Proxy-, DNS-, IPv6- oder TLS-Egress-Probleme zwischen dem Host und `api.telegram.org` hin. + - Telegram berücksichtigt außerdem Prozess-Proxy-Umgebungsvariablen für den Bot-API-Transport, einschließlich `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` und deren kleingeschriebene Varianten. `NO_PROXY` / `no_proxy` kann `api.telegram.org` weiterhin umgehen. - Wenn der von OpenClaw verwaltete Proxy über `OPENCLAW_PROXY_URL` für eine Service-Umgebung konfiguriert ist und keine Standard-Proxy-Umgebungsvariable vorhanden ist, verwendet Telegram diese URL ebenfalls für den Bot-API-Transport. - - Leiten Sie Telegram-API-Aufrufe auf VPS-Hosts mit instabilem direktem Egress/TLS über `channels.telegram.proxy`: + - Leiten Sie auf VPS-Hosts mit instabilem direktem Egress/TLS Telegram-API-Aufrufe über `channels.telegram.proxy`: ```yaml channels: @@ -893,8 +929,8 @@ channels: proxy: socks5://:@proxy-host:1080 ``` - - Node 22+ verwendet standardmäßig `autoSelectFamily=true` (außer WSL2). Die Reihenfolge der Telegram-DNS-Ergebnisse berücksichtigt `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER`, dann `channels.telegram.network.dnsResultOrder`, dann den Prozessstandard wie `NODE_OPTIONS=--dns-result-order=ipv4first`; wenn nichts davon zutrifft, fällt Node 22+ auf `ipv4first` zurück. - - Wenn Ihr Host WSL2 ist oder ausdrücklich besser mit reinem IPv4-Verhalten funktioniert, erzwingen Sie die Family-Auswahl: + - Node 22+ verwendet standardmäßig `autoSelectFamily=true` (außer WSL2). Die Reihenfolge der Telegram-DNS-Ergebnisse berücksichtigt zuerst `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER`, dann `channels.telegram.network.dnsResultOrder`, dann die Prozessvorgabe wie `NODE_OPTIONS=--dns-result-order=ipv4first`; wenn nichts davon zutrifft, fällt Node 22+ auf `ipv4first` zurück. + - Wenn Ihr Host WSL2 ist oder ausdrücklich mit reinem IPv4-Verhalten besser funktioniert, erzwingen Sie die Family-Auswahl: ```yaml channels: @@ -903,7 +939,7 @@ channels: autoSelectFamily: false ``` - - Antworten aus dem RFC-2544-Benchmark-Bereich (`198.18.0.0/15`) sind für Telegram-Mediendownloads standardmäßig bereits erlaubt. Wenn ein vertrauenswürdiger Fake-IP- oder transparenter Proxy `api.telegram.org` während Mediendownloads auf eine andere private/interne/Sondernutzungsadresse umschreibt, können Sie den Telegram-spezifischen Bypass aktivieren: + - Antworten aus dem RFC-2544-Benchmark-Bereich (`198.18.0.0/15`) sind für Telegram-Mediendownloads standardmäßig bereits erlaubt. Wenn ein vertrauenswürdiger Fake-IP- oder transparenter Proxy `api.telegram.org` während Mediendownloads auf eine andere private/interne/Special-Use-Adresse umschreibt, können Sie den nur für Telegram geltenden Bypass aktivieren: ```yaml channels: @@ -912,25 +948,26 @@ channels: dangerouslyAllowPrivateNetwork: true ``` - - Dasselbe Opt-in ist pro Konto unter + - Dieselbe Opt-in-Option ist pro Konto unter `channels.telegram.accounts..network.dangerouslyAllowPrivateNetwork` verfügbar. - - Wenn Ihr Proxy Telegram-Medienhosts nach `198.18.x.x` auflöst, lassen Sie - das gefährliche Flag zunächst deaktiviert. Telegram-Medien erlauben den - RFC-2544-Benchmark-Bereich standardmäßig bereits. + - Wenn Ihr Proxy Telegram-Medienhosts in `198.18.x.x` auflöst, lassen Sie das + gefährliche Flag zunächst deaktiviert. Telegram-Medien erlauben den RFC-2544- + Benchmark-Bereich bereits standardmäßig. - `channels.telegram.network.dangerouslyAllowPrivateNetwork` schwächt die Telegram- - Medien-SSRF-Schutzmaßnahmen. Verwenden Sie es nur für vertrauenswürdige, vom Betreiber kontrollierte Proxy- - Umgebungen wie Clash-, Mihomo- oder Surge-Fake-IP-Routing, wenn diese - private oder Sondernutzungsantworten außerhalb des RFC-2544-Benchmark- - Bereichs synthetisieren. Lassen Sie es für normalen öffentlichen Telegram-Zugriff deaktiviert. + `channels.telegram.network.dangerouslyAllowPrivateNetwork` schwächt Telegram- + Medien-SSRF-Schutzmechanismen. Verwenden Sie es nur für vertrauenswürdige, + operatorgesteuerte Proxy-Umgebungen wie Clash-, Mihomo- oder Surge-Fake-IP- + Routing, wenn diese private oder Special-Use-Antworten außerhalb des RFC-2544- + Benchmark-Bereichs erzeugen. Lassen Sie es für normalen öffentlichen + Telegram-Zugriff über das Internet deaktiviert. - - Umgebungsüberschreibungen (temporär): + - Umgebungs-Overrides (temporär): - `OPENCLAW_TELEGRAM_DISABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1` - `OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=ipv4first` - - DNS-Antworten validieren: + - DNS-Antworten prüfen: ```bash dig +short api.telegram.org A @@ -940,23 +977,23 @@ dig +short api.telegram.org AAAA -Weitere Hilfe: [Channel-Fehlerbehebung](/de/channels/troubleshooting). +Weitere Hilfe: [Kanal-Fehlerbehebung](/de/channels/troubleshooting). ## Konfigurationsreferenz Primäre Referenz: [Konfigurationsreferenz - Telegram](/de/gateway/config-channels#telegram). - + -- Start/Authentifizierung: `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` muss auf eine reguläre Datei zeigen; Symlinks werden abgelehnt) -- Zugriffskontrolle: `dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`, `groups`, `groups.*.topics.*`, `bindings[]` auf oberster Ebene (`type: "acp"`) +- Start/Authentifizierung: `enabled`, `botToken`, `tokenFile`, `accounts.*` (`tokenFile` muss auf eine reguläre Datei verweisen; Symlinks werden abgelehnt) +- Zugriffskontrolle: `dmPolicy`, `allowFrom`, `groupPolicy`, `groupAllowFrom`, `groups`, `groups.*.topics.*`, Top-Level-`bindings[]` (`type: "acp"`) - Ausführungsgenehmigungen: `execApprovals`, `accounts.*.execApprovals` - Befehl/Menü: `commands.native`, `commands.nativeSkills`, `customCommands` - Threading/Antworten: `replyToMode`, `dm.threadReplies`, `direct.*.threadReplies` - Streaming: `streaming` (Vorschau), `streaming.preview.toolProgress`, `blockStreaming` - Formatierung/Zustellung: `textChunkLimit`, `chunkMode`, `linkPreview`, `responsePrefix` - Medien/Netzwerk: `mediaMaxMb`, `mediaGroupFlushMs`, `timeoutSeconds`, `pollingStallThresholdMs`, `retry`, `network.autoSelectFamily`, `network.dangerouslyAllowPrivateNetwork`, `proxy` -- benutzerdefinierte API-Root: `apiRoot` (nur Bot-API-Root; `/bot` nicht einschließen) +- Benutzerdefinierte API-Root: `apiRoot` (nur Bot-API-Root; `/bot` nicht einschließen) - Webhook: `webhookUrl`, `webhookSecret`, `webhookPath`, `webhookHost` - Aktionen/Fähigkeiten: `capabilities.inlineButtons`, `actions.sendMessage|editMessage|deleteMessage|reactions|sticker` - Reaktionen: `reactionNotifications`, `reactionLevel` @@ -966,28 +1003,28 @@ Primäre Referenz: [Konfigurationsreferenz - Telegram](/de/gateway/config-channe -Priorität bei mehreren Konten: Wenn zwei oder mehr Konto-IDs konfiguriert sind, setzen Sie `channels.telegram.defaultAccount` (oder schließen Sie `channels.telegram.accounts.default` ein), um das Standard-Routing explizit zu machen. Andernfalls fällt OpenClaw auf die erste normalisierte Konto-ID zurück, und `openclaw doctor` warnt. Benannte Konten erben `channels.telegram.allowFrom` / `groupAllowFrom`, jedoch keine Werte von `accounts.default.*`. +Priorität bei mehreren Konten: Wenn zwei oder mehr Konto-IDs konfiguriert sind, legen Sie `channels.telegram.defaultAccount` fest (oder fügen Sie `channels.telegram.accounts.default` hinzu), um das Standard-Routing explizit zu machen. Andernfalls fällt OpenClaw auf die erste normalisierte Konto-ID zurück und `openclaw doctor` warnt. Benannte Konten erben `channels.telegram.allowFrom` / `groupAllowFrom`, aber keine `accounts.default.*`-Werte. ## Verwandt - + Koppeln Sie einen Telegram-Benutzer mit dem Gateway. Allowlist-Verhalten für Gruppen und Themen. - - Leiten Sie eingehende Nachrichten an Agenten weiter. + + Eingehende Nachrichten an Agenten weiterleiten. Bedrohungsmodell und Härtung. - Ordnen Sie Gruppen und Themen Agenten zu. + Gruppen und Themen Agenten zuordnen. - Channel-übergreifende Diagnosen. + Kanalübergreifende Diagnose. diff --git a/docs/de/concepts/streaming.md b/docs/de/concepts/streaming.md index cca268743..b9fcca3ed 100644 --- a/docs/de/concepts/streaming.md +++ b/docs/de/concepts/streaming.md @@ -1,29 +1,29 @@ --- read_when: - - Erklären, wie Streaming oder Chunking in Kanälen funktioniert - - Block-Streaming oder Channel-Chunking-Verhalten ändern - - Fehlersuche bei doppelten/verfrühten Blockantworten oder beim Streaming der Kanalvorschau -summary: Streaming- und Chunking-Verhalten (Block-Antworten, Kanalvorschau-Streaming, Moduszuordnung) + - Erklärung, wie Streaming oder Chunking in Kanälen funktioniert + - Block-Streaming- oder Kanal-Chunking-Verhalten ändern + - Fehlerbehebung bei doppelten oder verfrühten Blockantworten oder beim Kanalvorschau-Streaming +summary: Streaming- + Chunking-Verhalten (Blockantworten, Kanalvorschau-Streaming, Moduszuordnung) title: Streaming und Chunking x-i18n: - generated_at: "2026-05-04T06:42:24Z" + generated_at: "2026-05-04T07:03:06Z" model: gpt-5.5 provider: openai - source_hash: fcb41ceb5602ab42c3fd41a59de62cc965ea61fdbc058c052fb93689a9c5299b + source_hash: ff7b6cd8127255352fe16fb746469e9828e7d5aea183d3799ab10cc768515bd1 source_path: concepts/streaming.md workflow: 16 --- -OpenClaw hat zwei getrennte Streaming-Ebenen: +OpenClaw hat zwei separate Streaming-Ebenen: -- **Block-Streaming (Kanäle):** gibt abgeschlossene **Blöcke** aus, während der Assistent schreibt. Das sind normale Kanalnachrichten (keine Token-Deltas). +- **Block-Streaming (Kanäle):** gibt abgeschlossene **Blöcke** aus, während der Assistent schreibt. Dies sind normale Kanalnachrichten (keine Token-Deltas). - **Vorschau-Streaming (Telegram/Discord/Slack):** aktualisiert während der Generierung eine temporäre **Vorschaunachricht**. -Aktuell gibt es **kein echtes Token-Delta-Streaming** in Kanalnachrichten. Vorschau-Streaming ist nachrichtenbasiert (Senden + Bearbeitungen/Anhänge). +Es gibt derzeit **kein echtes Token-Delta-Streaming** zu Kanalnachrichten. Vorschau-Streaming ist nachrichtenbasiert (Senden + Bearbeitungen/Anhänge). ## Block-Streaming (Kanalnachrichten) -Block-Streaming sendet Assistentenausgaben in groben Teilstücken, sobald sie verfügbar werden. +Block-Streaming sendet Assistentenausgaben in groben Abschnitten, sobald sie verfügbar werden. ``` Model output @@ -38,19 +38,19 @@ Model output Legende: - `text_delta/events`: Modell-Stream-Ereignisse (können bei nicht streamenden Modellen spärlich sein). -- `chunker`: `EmbeddedBlockChunker`, der Mindest-/Höchstgrenzen + Umbruchpräferenz anwendet. +- `chunker`: `EmbeddedBlockChunker`, der Mindest-/Höchstgrenzen + bevorzugte Umbrüche anwendet. - `channel send`: tatsächliche ausgehende Nachrichten (Block-Antworten). **Steuerungen:** - `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (standardmäßig aus). -- Kanal-Overrides: `*.blockStreaming` (und kontoabhängige Varianten), um pro Kanal `"on"`/`"off"` zu erzwingen. +- Kanal-Overrides: `*.blockStreaming` (und Varianten pro Konto), um pro Kanal `"on"`/`"off"` zu erzwingen. - `agents.defaults.blockStreamingBreak`: `"text_end"` oder `"message_end"`. - `agents.defaults.blockStreamingChunk`: `{ minChars, maxChars, breakPreference? }`. -- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (streamende Blöcke vor dem Senden zusammenführen). -- Harte Kanalgrenze: `*.textChunkLimit` (z. B. `channels.whatsapp.textChunkLimit`). -- Kanal-Chunk-Modus: `*.chunkMode` (`length` standardmäßig, `newline` trennt vor dem Längen-Chunking an Leerzeilen (Absatzgrenzen)). -- Discord-Softlimit: `channels.discord.maxLinesPerMessage` (standardmäßig 17) teilt hohe Antworten auf, um UI-Clipping zu vermeiden. +- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (führt gestreamte Blöcke vor dem Senden zusammen). +- Harte Kanalobergrenze: `*.textChunkLimit` (z. B. `channels.whatsapp.textChunkLimit`). +- Kanal-Chunk-Modus: `*.chunkMode` (Standard `length`, `newline` teilt vor dem Längen-Chunking an Leerzeilen (Absatzgrenzen)). +- Discord-Soft-Cap: `channels.discord.maxLinesPerMessage` (Standard 17) teilt hohe Antworten, um UI-Clipping zu vermeiden. **Grenzsemantik:** @@ -59,69 +59,54 @@ Legende: `message_end` verwendet weiterhin den Chunker, wenn der gepufferte Text `maxChars` überschreitet, sodass am Ende mehrere Chunks ausgegeben werden können. -### Medienzustellung mit Block-Streaming +### Medienauslieferung mit Block-Streaming -`MEDIA:`-Direktiven sind normale Zustellungsmetadaten. Wenn Block-Streaming einen -Medienblock früh sendet, merkt sich OpenClaw diese Zustellung für den Turn. Wenn die finale -Assistenten-Nutzlast dieselbe Medien-URL wiederholt, entfernt die finale Zustellung das -duplizierte Medium, statt den Anhang erneut zu senden. +`MEDIA:`-Direktiven sind normale Auslieferungsmetadaten. Wenn Block-Streaming einen Medienblock früh sendet, merkt sich OpenClaw diese Auslieferung für den Turn. Wenn die endgültige Assistenten-Nutzlast dieselbe Medien-URL wiederholt, entfernt die endgültige Auslieferung das doppelte Medium, statt den Anhang erneut zu senden. -Exakt duplizierte finale Nutzlasten werden unterdrückt. Wenn die finale Nutzlast -eindeutigen Text um Medien ergänzt, die bereits gestreamt wurden, sendet OpenClaw weiterhin den -neuen Text und stellt das Medium dabei nur einmal zu. Das verhindert doppelte Sprachnotizen -oder Dateien in Kanälen wie Telegram, wenn ein Agent während des Streamings `MEDIA:` ausgibt -und der Provider es auch in der abgeschlossenen Antwort enthält. +Exakt doppelte endgültige Nutzlasten werden unterdrückt. Wenn die endgültige Nutzlast zusätzlichen Text um Medien ergänzt, die bereits gestreamt wurden, sendet OpenClaw den neuen Text weiterhin, behält aber die einmalige Medienauslieferung bei. Dies verhindert doppelte Sprachnachrichten oder Dateien in Kanälen wie Telegram, wenn ein Agent während des Streamings `MEDIA:` ausgibt und der Provider sie auch in die abgeschlossene Antwort einfügt. -## Chunking-Algorithmus (niedrige/hohe Grenzen) +## Chunking-Algorithmus (untere/obere Grenzen) -Block-Chunking wird von `EmbeddedBlockChunker` implementiert: +Block-Chunking wird durch `EmbeddedBlockChunker` implementiert: -- **Niedrige Grenze:** erst ausgeben, wenn Puffer >= `minChars` ist (außer erzwungen). -- **Hohe Grenze:** Trennungen vor `maxChars` bevorzugen; wenn erzwungen, bei `maxChars` trennen. +- **Untere Grenze:** nicht ausgeben, bevor Puffer >= `minChars` ist (außer erzwungen). +- **Obere Grenze:** Teilungen vor `maxChars` bevorzugen; wenn erzwungen, bei `maxChars` teilen. - **Umbruchpräferenz:** `paragraph` → `newline` → `sentence` → `whitespace` → harter Umbruch. -- **Code-Fences:** niemals innerhalb von Fences trennen; wenn bei `maxChars` erzwungen wird, den Fence schließen + erneut öffnen, damit Markdown gültig bleibt. +- **Code-Fences:** niemals innerhalb von Fences teilen; wenn bei `maxChars` erzwungen, den Fence schließen + erneut öffnen, um gültiges Markdown zu erhalten. -`maxChars` wird auf das Kanal-`textChunkLimit` begrenzt, sodass Sie kanalbezogene Grenzen nicht überschreiten können. +`maxChars` wird auf das Kanal-`textChunkLimit` begrenzt, sodass Sie die Grenzwerte pro Kanal nicht überschreiten können. -## Zusammenführen (streamende Blöcke zusammenführen) +## Coalescing (gestreamte Blöcke zusammenführen) -Wenn Block-Streaming aktiviert ist, kann OpenClaw **aufeinanderfolgende Block-Chunks zusammenführen**, -bevor sie gesendet werden. Das reduziert „Einzeilen-Spam“ und liefert trotzdem -fortlaufende Ausgaben. +Wenn Block-Streaming aktiviert ist, kann OpenClaw **aufeinanderfolgende Block-Chunks zusammenführen**, bevor sie ausgegeben werden. Dies reduziert „Ein-Zeilen-Spam“ und liefert dennoch fortlaufende Ausgaben. -- Das Zusammenführen wartet vor dem Leeren auf **Leerlaufpausen** (`idleMs`). -- Puffer werden durch `maxChars` begrenzt und werden geleert, wenn sie diese Grenze überschreiten. -- `minChars` verhindert, dass winzige Fragmente gesendet werden, bevor genug Text angesammelt ist - (das finale Leeren sendet immer den verbleibenden Text). -- Der Joiner wird aus `blockStreamingChunk.breakPreference` abgeleitet - (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → Leerzeichen). -- Kanal-Overrides sind über `*.blockStreamingCoalesce` verfügbar (einschließlich kontoabhängiger Konfigurationen). -- Der standardmäßige Zusammenführungswert `minChars` wird für Signal/Slack/Discord auf 1500 angehoben, sofern er nicht überschrieben wird. +- Coalescing wartet vor dem Leeren auf **Leerlaufpausen** (`idleMs`). +- Puffer sind durch `maxChars` begrenzt und werden geleert, wenn sie diese Grenze überschreiten. +- `minChars` verhindert, dass winzige Fragmente gesendet werden, bis genug Text angesammelt wurde (der finale Flush sendet immer den verbleibenden Text). +- Der Joiner wird aus `blockStreamingChunk.breakPreference` abgeleitet (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → Leerzeichen). +- Kanal-Overrides sind über `*.blockStreamingCoalesce` verfügbar (einschließlich Konfigurationen pro Konto). +- Der standardmäßige Coalesce-`minChars`-Wert wird für Signal/Slack/Discord auf 1500 erhöht, sofern er nicht überschrieben wird. ## Menschlich wirkende Pausen zwischen Blöcken -Wenn Block-Streaming aktiviert ist, können Sie zwischen -Block-Antworten (nach dem ersten Block) eine **zufällige Pause** hinzufügen. Dadurch wirken Antworten mit mehreren Sprechblasen -natürlicher. +Wenn Block-Streaming aktiviert ist, können Sie zwischen Block-Antworten (nach dem ersten Block) eine **randomisierte Pause** hinzufügen. Dadurch wirken Antworten mit mehreren Sprechblasen natürlicher. -- Konfiguration: `agents.defaults.humanDelay` (pro Agent über `agents.list[].humanDelay` überschreiben). -- Modi: `off` (Standard), `natural` (800-2500 ms), `custom` (`minMs`/`maxMs`). -- Gilt nur für **Block-Antworten**, nicht für finale Antworten oder Tool-Zusammenfassungen. +- Konfiguration: `agents.defaults.humanDelay` (pro Agent über `agents.list[].humanDelay` überschreibbar). +- Modi: `off` (Standard), `natural` (800–2500 ms), `custom` (`minMs`/`maxMs`). +- Gilt nur für **Block-Antworten**, nicht für endgültige Antworten oder Tool-Zusammenfassungen. -## „Chunks streamen oder alles“ +## „Chunks oder alles streamen“ Dies entspricht: -- **Chunks streamen:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (ausgeben, während generiert wird). Nicht-Telegram-Kanäle benötigen außerdem `*.blockStreaming: true`. -- **Alles am Ende streamen:** `blockStreamingBreak: "message_end"` (einmal leeren, bei sehr langen Antworten ggf. in mehreren Chunks). -- **Kein Block-Streaming:** `blockStreamingDefault: "off"` (nur finale Antwort). +- **Chunks streamen:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (während der Ausgabe senden). Nicht-Telegram-Kanäle benötigen außerdem `*.blockStreaming: true`. +- **Alles am Ende streamen:** `blockStreamingBreak: "message_end"` (einmal leeren, bei sehr langer Ausgabe möglicherweise in mehreren Chunks). +- **Kein Block-Streaming:** `blockStreamingDefault: "off"` (nur endgültige Antwort). -**Kanalhinweis:** Block-Streaming ist **aus, sofern nicht** -`*.blockStreaming` explizit auf `true` gesetzt ist. Kanäle können eine Live-Vorschau -(`channels..streaming`) ohne Block-Antworten streamen. +**Kanalhinweis:** Block-Streaming ist **aus, sofern** +`*.blockStreaming` nicht explizit auf `true` gesetzt ist. Kanäle können eine Live-Vorschau streamen (`channels..streaming`), ohne Block-Antworten zu senden. -Konfigurationshinweis: Die `blockStreaming*`-Standardwerte befinden sich unter -`agents.defaults`, nicht in der Root-Konfiguration. +Erinnerung zum Konfigurationsort: Die `blockStreaming*`-Defaults befinden sich unter `agents.defaults`, nicht in der Root-Konfiguration. ## Vorschau-Streaming-Modi @@ -131,87 +116,82 @@ Modi: - `off`: Vorschau-Streaming deaktivieren. - `partial`: einzelne Vorschau, die durch den neuesten Text ersetzt wird. -- `block`: Vorschau wird in gestückelten/angehängten Schritten aktualisiert. -- `progress`: Fortschritts-/Statusvorschau während der Generierung, finale Antwort bei Abschluss. +- `block`: Vorschau wird in gechunkten/angehängten Schritten aktualisiert. +- `progress`: Fortschritts-/Statusvorschau während der Generierung, endgültige Antwort bei Abschluss. -`streaming.mode: "block"` ist ein Vorschau-Streaming-Modus für Kanäle mit Bearbeitungsfunktion -wie Discord und Telegram. Er aktiviert dort keine Block-Zustellung im Kanal. -Verwenden Sie `streaming.block.enabled` oder den alten Kanal-Schlüssel `blockStreaming`, wenn -Sie normale Block-Antworten möchten. Microsoft Teams ist die Ausnahme: Es hat keinen -Block-Transport für Entwurfsvorschauen, daher wird `streaming.mode: "block"` auf die Teams-Block-Zustellung -statt auf natives Partial-/Fortschritts-Streaming abgebildet. +`streaming.mode: "block"` ist ein Vorschau-Streaming-Modus für bearbeitungsfähige Kanäle wie Discord und Telegram. Er aktiviert dort keine Kanal-Blockauslieferung. Verwenden Sie `streaming.block.enabled` oder den Legacy-Kanalschlüssel `blockStreaming`, wenn Sie normale Block-Antworten wünschen. Microsoft Teams ist die Ausnahme: Es hat keinen Entwurfs-Vorschau-Blocktransport, daher wird `streaming.mode: "block"` auf Teams-Blockauslieferung statt auf natives Partial-/Progress-Streaming abgebildet. ### Kanalzuordnung -| Kanal | `off` | `partial` | `block` | `progress` | -| ---------- | ----- | --------- | ------- | ---------------------------- | +| Kanal | `off` | `partial` | `block` | `progress` | +| ---------- | ----- | --------- | ------- | --------------------------- | | Telegram | ✅ | ✅ | ✅ | bearbeitbarer Fortschrittsentwurf | | Discord | ✅ | ✅ | ✅ | bearbeitbarer Fortschrittsentwurf | -| Slack | ✅ | ✅ | ✅ | ✅ | -| Mattermost | ✅ | ✅ | ✅ | ✅ | -| MS Teams | ✅ | ✅ | ✅ | nativer Fortschrittsstream | +| Slack | ✅ | ✅ | ✅ | ✅ | +| Mattermost | ✅ | ✅ | ✅ | ✅ | +| MS Teams | ✅ | ✅ | ✅ | nativer Fortschrittsstream | Nur Slack: - `channels.slack.streaming.nativeTransport` schaltet native Slack-Streaming-API-Aufrufe um, wenn `channels.slack.streaming.mode="partial"` ist (Standard: `true`). -- Natives Slack-Streaming und der Slack-Assistenten-Threadstatus erfordern ein Antwort-Thread-Ziel. Top-Level-DMs zeigen diese Thread-artige Vorschau nicht an, können aber weiterhin Slack-Entwurfsvorschau-Beiträge und -Bearbeitungen verwenden. +- Natives Slack-Streaming und Slack-Assistenten-Thread-Status benötigen ein Antwort-Thread-Ziel. Top-Level-DMs zeigen diese Thread-Vorschau nicht an, können aber weiterhin Slack-Entwurfs-Vorschauposts und Bearbeitungen verwenden. -Migration alter Schlüssel: +Legacy-Schlüsselmigration: -- Telegram: alte `streamMode`- und skalare/boolesche `streaming`-Werte werden erkannt und durch Doctor-/Konfigurationskompatibilitätspfade zu `streaming.mode` migriert. -- Discord: `streamMode` + boolesches `streaming` migrieren automatisch zum `streaming`-Enum. -- Slack: `streamMode` migriert automatisch zu `streaming.mode`; boolesches `streaming` migriert automatisch zu `streaming.mode` plus `streaming.nativeTransport`; altes `nativeStreaming` migriert automatisch zu `streaming.nativeTransport`. +- Telegram: Legacy-`streamMode` und skalare/boolesche `streaming`-Werte werden erkannt und über Doctor-/Konfigurationskompatibilitätspfade zu `streaming.mode` migriert. +- Discord: `streamMode` + boolesches `streaming` werden automatisch zur `streaming`-Enum migriert. +- Slack: `streamMode` wird automatisch zu `streaming.mode` migriert; boolesches `streaming` wird automatisch zu `streaming.mode` plus `streaming.nativeTransport` migriert; Legacy-`nativeStreaming` wird automatisch zu `streaming.nativeTransport` migriert. ### Laufzeitverhalten Telegram: -- Verwendet `sendMessage` + `editMessageText` für Vorschauaktualisierungen über DMs und Gruppen/Themen hinweg. -- Sendet eine neue finale Nachricht, statt sie an Ort und Stelle zu bearbeiten, wenn eine Vorschau ungefähr eine Minute sichtbar war, und räumt anschließend die Vorschau auf, damit der Telegram-Zeitstempel den Abschluss der Antwort widerspiegelt. +- Verwendet `sendMessage` + `editMessageText`-Vorschauaktualisierungen über DMs und Gruppen/Themen hinweg. +- Sendet eine neue endgültige Nachricht, statt an Ort und Stelle zu bearbeiten, wenn eine Vorschau etwa eine Minute sichtbar war, und bereinigt anschließend die Vorschau, damit der Telegram-Zeitstempel den Abschluss der Antwort widerspiegelt. - Vorschau-Streaming wird übersprungen, wenn Telegram-Block-Streaming explizit aktiviert ist (um doppeltes Streaming zu vermeiden). -- `/reasoning stream` kann Reasoning in eine temporäre Vorschau schreiben, die nach der finalen Zustellung gelöscht wird. +- `/reasoning stream` kann Reasoning in eine flüchtige Vorschau schreiben, die nach der endgültigen Auslieferung gelöscht wird. Discord: - Verwendet Senden + Bearbeiten von Vorschaunachrichten. -- Der `block`-Modus verwendet Entwurfs-Chunking (`draftChunk`). +- Der Modus `block` verwendet Entwurfs-Chunking (`draftChunk`). - Vorschau-Streaming wird übersprungen, wenn Discord-Block-Streaming explizit aktiviert ist. -- Finale Medien-, Fehler- und explizite Antwort-Nutzlasten brechen ausstehende Vorschauen ab, ohne einen neuen Entwurf zu leeren, und verwenden dann die normale Zustellung. +- Endgültige Medien-, Fehler- und explizite Antwortnutzlasten brechen ausstehende Vorschauen ab, ohne einen neuen Entwurf zu leeren, und verwenden anschließend die normale Auslieferung. Slack: - `partial` kann natives Slack-Streaming (`chat.startStream`/`append`/`stop`) verwenden, wenn verfügbar. -- `block` verwendet angehängte Entwurfsvorschauen. -- `progress` verwendet Statustext als Vorschau und danach die finale Antwort. -- Top-Level-DMs ohne Antwort-Thread verwenden Entwurfsvorschau-Beiträge und -Bearbeitungen statt nativem Slack-Streaming. -- Natives Streaming und Entwurfsvorschau-Streaming unterdrücken Block-Antworten für diesen Turn, sodass eine Slack-Antwort nur über einen Zustellungspfad gestreamt wird. -- Finale Medien-/Fehler-Nutzlasten und Fortschrittsfinale erzeugen keine Wegwerf-Entwurfsnachrichten; nur Text-/Block-Finale, die die Vorschau bearbeiten können, leeren ausstehenden Entwurfstext. +- `block` verwendet Entwurfsvorschauen im Append-Stil. +- `progress` verwendet Statusvorschautext und anschließend die endgültige Antwort. +- Top-Level-DMs ohne Antwort-Thread verwenden Entwurfs-Vorschauposts und Bearbeitungen statt nativem Slack-Streaming. +- Native und Entwurfs-Vorschau-Streams unterdrücken Block-Antworten für diesen Turn, sodass eine Slack-Antwort nur über einen Auslieferungspfad gestreamt wird. +- Endgültige Medien-/Fehlernutzlasten und Progress-Finals erzeugen keine Wegwerf-Entwurfsnachrichten; nur Text-/Block-Finals, die die Vorschau bearbeiten können, leeren ausstehenden Entwurfstext. Mattermost: -- Streamt Denken, Tool-Aktivität und teilweisen Antworttext in einen einzelnen Entwurfsvorschau-Beitrag, der an Ort und Stelle finalisiert wird, wenn die finale Antwort sicher gesendet werden kann. -- Fällt auf das Senden eines neuen finalen Beitrags zurück, wenn der Vorschaubeitrag gelöscht wurde oder zum Finalisierungszeitpunkt anderweitig nicht verfügbar ist. -- Finale Medien-/Fehler-Nutzlasten brechen ausstehende Vorschauaktualisierungen vor der normalen Zustellung ab, statt einen temporären Vorschaubeitrag zu leeren. +- Streamt Thinking, Tool-Aktivität und teilweisen Antworttext in einen einzelnen Entwurfs-Vorschaupost, der an Ort und Stelle finalisiert wird, wenn die endgültige Antwort sicher gesendet werden kann. +- Fällt auf das Senden eines neuen endgültigen Posts zurück, wenn der Vorschaupost gelöscht wurde oder zum Finalisierungszeitpunkt anderweitig nicht verfügbar ist. +- Endgültige Medien-/Fehlernutzlasten brechen ausstehende Vorschauaktualisierungen vor der normalen Auslieferung ab, statt einen temporären Vorschaupost zu leeren. Matrix: -- Entwurfsvorschauen werden an Ort und Stelle finalisiert, wenn der finale Text das Vorschauereignis wiederverwenden kann. -- Reine Medien-, Fehler- und Antwortzielkonflikt-Finale brechen ausstehende Vorschauaktualisierungen vor der normalen Zustellung ab; eine bereits sichtbare veraltete Vorschau wird redigiert. +- Entwurfsvorschauen werden an Ort und Stelle finalisiert, wenn der endgültige Text das Vorschauereignis wiederverwenden kann. +- Reine Medien-, Fehler- und Antwortziel-Nichtübereinstimmungs-Finals brechen ausstehende Vorschauaktualisierungen vor der normalen Auslieferung ab; eine bereits sichtbare veraltete Vorschau wird redigiert. -### Vorschauaktualisierungen für Tool-Fortschritt +### Tool-Fortschritts-Vorschauaktualisierungen -Vorschau-Streaming kann auch **Tool-Fortschritts**-Aktualisierungen enthalten — kurze Statuszeilen wie „Web wird durchsucht“, „Datei wird gelesen“ oder „Tool wird aufgerufen“ —, die in derselben Vorschaunachricht erscheinen, während Tools ausgeführt werden, noch vor der finalen Antwort. Dadurch bleiben mehrstufige Tool-Turns visuell aktiv, statt zwischen der ersten Denk-Vorschau und der finalen Antwort still zu sein. +Vorschau-Streaming kann auch **Tool-Fortschritts**-Aktualisierungen enthalten — kurze Statuszeilen wie „Durchsuchen des Webs“, „Datei lesen“ oder „Tool aufrufen“ — die in derselben Vorschaunachricht erscheinen, während Tools laufen, vor der endgültigen Antwort. Dadurch bleiben mehrstufige Tool-Turns visuell aktiv, statt zwischen der ersten Thinking-Vorschau und der endgültigen Antwort still zu wirken. Unterstützte Oberflächen: - **Discord**, **Slack**, **Telegram** und **Matrix** streamen Tool-Fortschritt standardmäßig in die Live-Vorschau-Bearbeitung, wenn Vorschau-Streaming aktiv ist. Microsoft Teams verwendet in persönlichen Chats seinen nativen Fortschrittsstream. - Telegram wird seit `v2026.4.22` mit aktivierten Tool-Fortschritts-Vorschauaktualisierungen ausgeliefert; sie aktiviert zu lassen, bewahrt dieses veröffentlichte Verhalten. -- **Mattermost** integriert Tool-Aktivität bereits in seinen einzelnen Entwurfsvorschau-Beitrag (siehe oben). -- Tool-Fortschritts-Bearbeitungen folgen dem aktiven Vorschau-Streaming-Modus; sie werden übersprungen, wenn Vorschau-Streaming `off` ist oder wenn Block-Streaming die Nachricht übernommen hat. Bei Telegram ist `streaming.mode: "off"` final-only: allgemeines Fortschrittsgerede wird ebenfalls unterdrückt, statt als eigenständige Statusnachrichten zugestellt zu werden, während Genehmigungsaufforderungen, Medien-Nutzlasten und Fehler weiterhin normal geroutet werden. -- Um Vorschau-Streaming beizubehalten, aber Tool-Fortschrittszeilen auszublenden, setzen Sie `streaming.preview.toolProgress` für diesen Kanal auf `false`. Um Vorschaubearbeitungen vollständig zu deaktivieren, setzen Sie `streaming.mode` auf `off`. -- Ausgewählte Telegram-Zitatantworten sind eine Ausnahme: Wenn `replyToMode` nicht `"off"` ist und ausgewählter Zitattext vorhanden ist, überspringt OpenClaw den Antwortvorschau-Stream für diesen Turn, sodass Tool-Fortschritts-Vorschauzeilen nicht gerendert werden können. Aktuelle-Nachricht-Antworten ohne ausgewählten Zitattext behalten weiterhin Vorschau-Streaming bei. Details finden Sie in der [Telegram-Kanaldokumentation](/de/channels/telegram). +- **Mattermost** integriert Tool-Aktivität bereits in seinen einzelnen Entwurfs-Vorschaupost (siehe oben). +- Tool-Fortschritts-Bearbeitungen folgen dem aktiven Vorschau-Streaming-Modus; sie werden übersprungen, wenn Vorschau-Streaming `off` ist oder wenn Block-Streaming die Nachricht übernommen hat. Bei Telegram ist `streaming.mode: "off"` nur final: generisches Fortschrittsgeplauder wird ebenfalls unterdrückt, statt als eigenständige Statusnachrichten ausgeliefert zu werden, während Genehmigungsaufforderungen, Mediennutzlasten und Fehler weiterhin normal geroutet werden. +- Um Vorschau-Streaming beizubehalten, aber Tool-Fortschrittszeilen auszublenden, setzen Sie `streaming.preview.toolProgress` für diesen Kanal auf `false`. Um Tool-Fortschrittszeilen sichtbar zu halten und gleichzeitig Befehls-/Ausführungstext auszublenden, setzen Sie `streaming.preview.commandText` auf `"status"` oder `streaming.progress.commandText` auf `"status"`; Standard ist `"raw"`, um veröffentlichtes Verhalten beizubehalten. Diese Richtlinie wird von Entwurfs-/Progress-Kanälen geteilt, die OpenClaws kompakten Fortschrittsrenderer verwenden, einschließlich Discord, Matrix, Microsoft Teams, Mattermost, Slack-Entwurfsvorschauen und Telegram. Um Vorschau-Bearbeitungen vollständig zu deaktivieren, setzen Sie `streaming.mode` auf `off`. +- Ausgewählte Telegram-Zitatantworten sind eine Ausnahme: Wenn `replyToMode` nicht `"off"` ist und ausgewählter Zitattext vorhanden ist, überspringt OpenClaw den Antwort-Vorschaustream für diesen Turn, sodass Tool-Fortschritts-Vorschauzeilen nicht gerendert werden können. Antworten auf aktuelle Nachrichten ohne ausgewählten Zitattext behalten das Vorschau-Streaming weiterhin bei. Details finden Sie in der [Telegram-Kanaldokumentation](/de/channels/telegram). -Beispiel: +Halten Sie Fortschrittszeilen sichtbar, blenden Sie aber rohen Befehls-/Ausführungstext aus: ```json { @@ -220,7 +200,8 @@ Beispiel: "streaming": { "mode": "partial", "preview": { - "toolProgress": false + "toolProgress": true, + "commandText": "status" } } } @@ -228,9 +209,27 @@ Beispiel: } ``` -## Verwandt +Verwenden Sie dieselbe Struktur unter einem anderen kompakten Fortschrittskanal-Schlüssel, zum Beispiel `channels.discord`, `channels.matrix`, `channels.msteams`, `channels.mattermost` oder Slack-Entwurfsvorschauen. Für den Fortschrittsentwurfsmodus legen Sie dieselbe Richtlinie unter `streaming.progress` ab: -- [Fortschrittsentwürfe](/de/concepts/progress-drafts) — sichtbare Nachrichten zum Bearbeitungsfortschritt, die während langer Durchläufe aktualisiert werden +```json +{ + "channels": { + "telegram": { + "streaming": { + "mode": "progress", + "progress": { + "toolProgress": true, + "commandText": "status" + } + } + } + } +} +``` + +## Verwandte Themen + +- [Fortschrittsentwürfe](/de/concepts/progress-drafts) — sichtbare Zwischenstandsnachrichten, die während langer Turns aktualisiert werden - [Nachrichten](/de/concepts/messages) — Nachrichtenlebenszyklus und Zustellung -- [Erneuter Versuch](/de/concepts/retry) — Verhalten bei erneuten Zustellversuchen nach Zustellungsfehlern +- [Wiederholen](/de/concepts/retry) — Wiederholungsverhalten bei Zustellfehlern - [Kanäle](/de/channels) — Streaming-Unterstützung pro Kanal