chore(i18n): refresh de translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
5d5e02cf85
commit
4bb4460efe
File diff suppressed because it is too large
Load Diff
@ -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.
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Kopplung" icon="link" href="/de/channels/pairing">
|
||||
Slack-DMs verwenden standardmäßig den Kopplungsmodus.
|
||||
<Card title="Pairing" icon="link" href="/de/channels/pairing">
|
||||
Slack-DMs verwenden standardmäßig den Pairing-Modus.
|
||||
</Card>
|
||||
<Card title="Slash-Befehle" icon="terminal" href="/de/tools/slash-commands">
|
||||
<Card title="Slash commands" icon="terminal" href="/de/tools/slash-commands">
|
||||
Natives Befehlsverhalten und Befehlskatalog.
|
||||
</Card>
|
||||
<Card title="Channel-Fehlerbehebung" icon="wrench" href="/de/channels/troubleshooting">
|
||||
<Card title="Channel troubleshooting" icon="wrench" href="/de/channels/troubleshooting">
|
||||
Channel-übergreifende Diagnose- und Reparatur-Playbooks.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Schnelleinrichtung
|
||||
## Schnelle Einrichtung
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Socket Mode (Standard)">
|
||||
<Tab title="Socket Mode (default)">
|
||||
<Steps>
|
||||
<Step title="Neue Slack-App erstellen">
|
||||
<Step title="Create a new Slack app">
|
||||
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-...`)
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="OpenClaw konfigurieren">
|
||||
<Step title="Configure OpenClaw">
|
||||
|
||||
Empfohlene SecretRef-Einrichtung:
|
||||
|
||||
@ -73,7 +73,7 @@ SLACK_BOT_TOKEN=xoxb-...
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Gateway starten">
|
||||
<Step title="Start gateway">
|
||||
|
||||
```bash
|
||||
openclaw gateway
|
||||
@ -86,17 +86,17 @@ openclaw gateway
|
||||
|
||||
<Tab title="HTTP Request URLs">
|
||||
<Steps>
|
||||
<Step title="Neue Slack-App erstellen">
|
||||
<Step title="Create a new Slack app">
|
||||
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-...`)
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="OpenClaw konfigurieren">
|
||||
<Step title="Configure OpenClaw">
|
||||
|
||||
Empfohlene SecretRef-Einrichtung:
|
||||
|
||||
@ -123,12 +123,12 @@ openclaw config patch --file ./slack.http.patch.json5
|
||||
<Note>
|
||||
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.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Gateway starten">
|
||||
<Step title="Start gateway">
|
||||
|
||||
```bash
|
||||
openclaw gateway
|
||||
@ -140,9 +140,9 @@ openclaw gateway
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## 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.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Optionale native Slash-Befehle">
|
||||
<Accordion title="Optional native slash commands">
|
||||
|
||||
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):
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Socket Mode (Standard)">
|
||||
<Tab title="Socket Mode (default)">
|
||||
|
||||
```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.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Optional authorship scopes (write operations)">
|
||||
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.
|
||||
<Accordion title="Optionale Autorschafts-Scopes (Schreibvorgänge)">
|
||||
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:`.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Optional user-token scopes (read operations)">
|
||||
<Accordion title="Optionale Benutzer-Token-Scopes (Lesevorgänge)">
|
||||
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)
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## 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`.
|
||||
|
||||
<Tip>
|
||||
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.
|
||||
</Tip>
|
||||
|
||||
## 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
|
||||
|
||||
<Tabs>
|
||||
<Tab title="DM policy">
|
||||
<Tab title="DM-Richtlinie">
|
||||
`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
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Channel policy">
|
||||
<Tab title="Kanalrichtlinie">
|
||||
`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`
|
||||
|
||||
<Warning>
|
||||
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
|
||||
</Tab>
|
||||
|
||||
<Tab title="Mentions and channel users">
|
||||
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.<id>`; Namen nur über Startauflösung oder `dangerouslyAllowNameMatching`):
|
||||
Steuerungen pro Channel (`channels.slack.channels.<id>`; 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.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## 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:<agentId>:slack:channel:<channelId>`.
|
||||
- Thread-Antworten können, wenn zutreffend, Thread-Sitzungssuffixe (`:thread:<threadTs>`) erzeugen.
|
||||
- Channel-Sitzungen: `agent:<agentId>:slack:channel:<channelId>`.
|
||||
- Thread-Antworten können, wenn anwendbar, Thread-Sitzungssuffixe erstellen (`:thread:<threadTs>`).
|
||||
- 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:<id>]]`
|
||||
|
||||
<Note>
|
||||
`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.
|
||||
</Note>
|
||||
|
||||
## 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.<accountId>.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
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Inbound attachments">
|
||||
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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Outbound text and files">
|
||||
- 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
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -742,16 +761,16 @@ Hinweise:
|
||||
Bevorzugte explizite Ziele:
|
||||
|
||||
- `user:<id>` für DMs
|
||||
- `channel:<id>` für Channels
|
||||
- `channel:<id>` 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.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## 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:<agentId>:slack:slash:<userId>` und leiten Befehlsausführungen weiterhin mit `CommandTargetSessionKey` an die Ziel-Conversation-Session weiter.
|
||||
Slash-Sitzungen verwenden isolierte Schlüssel wie `agent:<agentId>:slack:slash:<userId>` 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
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Socket mode not connecting">
|
||||
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.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## 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.
|
||||
</Card>
|
||||
<Card title="Groups" icon="users" href="/de/channels/groups">
|
||||
Channel- und Gruppen-DM-Verhalten.
|
||||
Verhalten von Channels und Gruppen-DMs.
|
||||
</Card>
|
||||
<Card title="Channel routing" icon="route" href="/de/channels/channel-routing">
|
||||
Leiten Sie Inbound-Nachrichten an Agents weiter.
|
||||
Leiten Sie eingehende Nachrichten an Agenten weiter.
|
||||
</Card>
|
||||
<Card title="Security" icon="shield" href="/de/gateway/security">
|
||||
Bedrohungsmodell und Härtung.
|
||||
</Card>
|
||||
<Card title="Configuration" icon="sliders" href="/de/gateway/configuration">
|
||||
Konfigurationslayout und Rangfolge.
|
||||
Konfigurationslayout und Vorrangregeln.
|
||||
</Card>
|
||||
<Card title="Slash commands" icon="terminal" href="/de/tools/slash-commands">
|
||||
Befehlskatalog und Verhalten.
|
||||
|
||||
@ -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.
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Pairing" icon="link" href="/de/channels/pairing">
|
||||
Die Standard-DM-Richtlinie für Telegram ist Pairing.
|
||||
<Card title="Kopplung" icon="link" href="/de/channels/pairing">
|
||||
Die Standard-DM-Richtlinie für Telegram ist Kopplung.
|
||||
</Card>
|
||||
<Card title="Channel troubleshooting" icon="wrench" href="/de/channels/troubleshooting">
|
||||
<Card title="Kanal-Fehlerbehebung" icon="wrench" href="/de/channels/troubleshooting">
|
||||
Kanalübergreifende Diagnosen und Reparatur-Playbooks.
|
||||
</Card>
|
||||
<Card title="Gateway configuration" icon="settings" href="/de/gateway/configuration">
|
||||
Vollständige Channel-Konfigurationsmuster und Beispiele.
|
||||
<Card title="Gateway-Konfiguration" icon="settings" href="/de/gateway/configuration">
|
||||
Vollständige Kanalkonfigurationsmuster und Beispiele.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Schnelle Einrichtung
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the bot token in BotFather">
|
||||
Öffnen Sie Telegram und chatten Sie mit **@BotFather** (stellen Sie sicher, dass der Handle exakt `@BotFather` lautet).
|
||||
<Step title="Bot-Token in BotFather erstellen">
|
||||
Ö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.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Configure token and DM policy">
|
||||
<Step title="Token und DM-Richtlinie konfigurieren">
|
||||
|
||||
```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.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Start gateway and approve first DM">
|
||||
<Step title="Gateway starten und erste DM genehmigen">
|
||||
|
||||
```bash
|
||||
openclaw gateway
|
||||
@ -64,12 +64,12 @@ openclaw pairing list telegram
|
||||
openclaw pairing approve telegram <CODE>
|
||||
```
|
||||
|
||||
Pairing-Codes laufen nach 1 Stunde ab.
|
||||
Kopplungscodes laufen nach 1 Stunde ab.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Add the bot to a group">
|
||||
Fügen Sie den Bot Ihrer Gruppe hinzu und setzen Sie dann `channels.telegram.groups` und `groupPolicy` passend zu Ihrem Zugriffsmodell.
|
||||
<Step title="Bot zu einer Gruppe hinzufügen">
|
||||
Fügen Sie den Bot zu Ihrer Gruppe hinzu und legen Sie dann `channels.telegram.groups` und `groupPolicy` passend zu Ihrem Zugriffsmodell fest.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@ -80,26 +80,26 @@ Die Reihenfolge der Token-Auflösung ist kontobewusst. In der Praxis haben Konfi
|
||||
## Telegram-seitige Einstellungen
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Privacy mode and group visibility">
|
||||
Telegram-Bots verwenden standardmäßig den **Privatsphäre-Modus**, der begrenzt, welche Gruppennachrichten sie empfangen.
|
||||
<Accordion title="Privatsphäremodus und Gruppensichtbarkeit">
|
||||
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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Group permissions">
|
||||
Der Adminstatus wird in den Telegram-Gruppeneinstellungen gesteuert.
|
||||
<Accordion title="Gruppenberechtigungen">
|
||||
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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Helpful BotFather toggles">
|
||||
<Accordion title="Hilfreiche BotFather-Umschalter">
|
||||
|
||||
- `/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
|
||||
|
||||
<Tabs>
|
||||
<Tab title="DM policy">
|
||||
`channels.telegram.dmPolicy` steuert den Zugriff auf Direktnachrichten:
|
||||
<Tab title="DM-Richtlinie">
|
||||
`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:<your user id>` 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:<your user id>` 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<bot_token>/getUpdates"
|
||||
```
|
||||
|
||||
Drittanbieter-Methode (weniger privat): `@userinfobot` oder `@getidsbot`.
|
||||
Drittanbietermethode (weniger privat): `@userinfobot` oder `@getidsbot`.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Group policy and allowlists">
|
||||
<Tab title="Gruppenrichtlinie und Allowlists">
|
||||
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<bot_token>/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.
|
||||
|
||||
</Warning>
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="Mention behavior">
|
||||
<Tab title="Erwähnungsverhalten">
|
||||
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<bot_token>/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<bot_token>/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:<threadId>` 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.<chatId>.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:<threadId>` 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.<chatId>.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
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Live stream preview (message edits)">
|
||||
<Accordion title="Live-Stream-Vorschau (Nachrichtenbearbeitungen)">
|
||||
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<bot_token>/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.
|
||||
|
||||
<Note>
|
||||
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.
|
||||
</Note>
|
||||
|
||||
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
|
||||
|
||||
</Accordion>
|
||||
@ -333,8 +369,8 @@ curl "https://api.telegram.org/bot<bot_token>/getUpdates"
|
||||
<Accordion title="Formatierung und HTML-Fallback">
|
||||
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<bot_token>/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<bot_token>/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<bot_token>/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<TOKEN>`-Endpunkt gesetzt wurde. `apiRoot` darf nur der Bot-API-Root sein, und `openclaw doctor --fix` entfernt ein versehentlich angehängtes `/bot<TOKEN>`.
|
||||
- `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<TOKEN>`-Endpunkt gesetzt wurde. `apiRoot` darf nur der Bot-API-Root sein, und `openclaw doctor --fix` entfernt ein versehentliches abschließendes `/bot<TOKEN>`.
|
||||
- `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 <requestId>` 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 <requestId>` 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).
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Inline-Schaltflächen">
|
||||
<Accordion title="Inline-Buttons">
|
||||
Inline-Tastatur-Scope konfigurieren:
|
||||
|
||||
```json5
|
||||
@ -445,9 +481,9 @@ curl "https://api.telegram.org/bot<bot_token>/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<bot_token>/getUpdates"
|
||||
}
|
||||
```
|
||||
|
||||
Callback-Klicks werden als Text an den Agenten übergeben:
|
||||
Callback-Klicks werden als Text an den Agent übergeben:
|
||||
`callback_data: <value>`
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Telegram-Nachrichtenaktionen für Agenten und Automatisierung">
|
||||
Telegram-Tool-Aktionen umfassen:
|
||||
<Accordion title="Telegram-Nachrichtenaktionen für Agents und Automatisierung">
|
||||
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<bot_token>/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<bot_token>/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)
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Antwort-Threading-Tags">
|
||||
Telegram unterstützt explizite Antwort-Threading-Tags in generierter Ausgabe:
|
||||
<Accordion title="Tags für Antwort-Threading">
|
||||
Telegram unterstützt explizite Tags für Antwort-Threading in generierter Ausgabe:
|
||||
|
||||
- `[[reply_to_current]]` antwortet auf die auslösende Nachricht
|
||||
- `[[reply_to:<id>]]` antwortet auf eine bestimmte Telegram-Nachrichten-ID
|
||||
@ -507,29 +543,29 @@ curl "https://api.telegram.org/bot<bot_token>/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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Forumsthemen und Thread-Verhalten">
|
||||
<Accordion title="Forumthemen und Thread-Verhalten">
|
||||
Forum-Supergruppen:
|
||||
|
||||
- Themenschlüssel für Sessions hängen `:topic:<threadId>` an
|
||||
- Antworten und Tippen zielen auf den Themen-Thread
|
||||
- Pfad der Themenkonfiguration:
|
||||
- Themen-Sitzungsschlüssel hängen `:topic:<threadId>` an
|
||||
- Antworten und Tippanzeige zielen auf den Themen-Thread
|
||||
- Themen-Config-Pfad:
|
||||
`channels.telegram.groups.<chatId>.topics.<threadId>`
|
||||
|
||||
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<bot_token>/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 <agent> --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 <agent> --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.<chatId>.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.<chatId>.threadReplies` für eine einzelne DM.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Audio, Video und Sticker">
|
||||
### 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<bot_token>/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<bot_token>/getUpdates"
|
||||
|
||||
### Sticker
|
||||
|
||||
Behandlung eingehender Sticker:
|
||||
Verarbeitung eingehender Sticker:
|
||||
|
||||
- statisches WEBP: heruntergeladen und verarbeitet (Platzhalter `<media:sticker>`)
|
||||
- animiertes TGS: übersprungen
|
||||
@ -674,13 +710,13 @@ curl "https://api.telegram.org/bot<bot_token>/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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -692,19 +728,19 @@ curl "https://api.telegram.org/bot<bot_token>/getUpdates"
|
||||
- `channels.telegram.accounts.<accountId>.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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Konfigurationsschreibvorgänge aus Telegram-Ereignissen und -Befehlen">
|
||||
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<bot_token>/getUpdates"
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Long Polling vs. Webhook">
|
||||
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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Limits, Wiederholung und CLI-Ziele">
|
||||
- `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["<user_id>"].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
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Exec-Genehmigungen in Telegram">
|
||||
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.
|
||||
<Accordion title="Exec-Freigaben in Telegram">
|
||||
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).
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## 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
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Bot antwortet nicht auf Gruppennachrichten ohne Erwähnung">
|
||||
<Accordion title="Bot reagiert nicht auf Gruppennachrichten ohne Erwähnung">
|
||||
|
||||
- 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`.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Bot sieht überhaupt keine Gruppennachrichten">
|
||||
|
||||
- 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
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Befehle funktionieren teilweise oder gar nicht">
|
||||
|
||||
- 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
|
||||
|
||||
</Accordion>
|
||||
|
||||
@ -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.<id>.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.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Polling oder Netzwerkinstabilität">
|
||||
<Accordion title="Polling- oder Netzwerkinstabilität">
|
||||
|
||||
- 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://<user>:<password>@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.<accountId>.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.
|
||||
|
||||
<Warning>
|
||||
`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.
|
||||
</Warning>
|
||||
|
||||
- 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
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
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).
|
||||
|
||||
<Accordion title="Telegram-Felder mit hoher Aussagekraft">
|
||||
<Accordion title="Aussagekräftige Telegram-Felder">
|
||||
|
||||
- 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<TOKEN>` nicht einschließen)
|
||||
- Benutzerdefinierte API-Root: `apiRoot` (nur Bot-API-Root; `/bot<TOKEN>` 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
|
||||
</Accordion>
|
||||
|
||||
<Note>
|
||||
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.
|
||||
</Note>
|
||||
|
||||
## Verwandt
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Kopplung" icon="link" href="/de/channels/pairing">
|
||||
<Card title="Pairing" icon="link" href="/de/channels/pairing">
|
||||
Koppeln Sie einen Telegram-Benutzer mit dem Gateway.
|
||||
</Card>
|
||||
<Card title="Gruppen" icon="users" href="/de/channels/groups">
|
||||
Allowlist-Verhalten für Gruppen und Themen.
|
||||
</Card>
|
||||
<Card title="Channel-Routing" icon="route" href="/de/channels/channel-routing">
|
||||
Leiten Sie eingehende Nachrichten an Agenten weiter.
|
||||
<Card title="Kanal-Routing" icon="route" href="/de/channels/channel-routing">
|
||||
Eingehende Nachrichten an Agenten weiterleiten.
|
||||
</Card>
|
||||
<Card title="Sicherheit" icon="shield" href="/de/gateway/security">
|
||||
Bedrohungsmodell und Härtung.
|
||||
</Card>
|
||||
<Card title="Multi-Agent-Routing" icon="sitemap" href="/de/concepts/multi-agent">
|
||||
Ordnen Sie Gruppen und Themen Agenten zu.
|
||||
Gruppen und Themen Agenten zuordnen.
|
||||
</Card>
|
||||
<Card title="Fehlerbehebung" icon="wrench" href="/de/channels/troubleshooting">
|
||||
Channel-übergreifende Diagnosen.
|
||||
Kanalübergreifende Diagnose.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -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.<channel>.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.<channel>.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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user