> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Nachrichten

OpenClaw verarbeitet eingehende Nachrichten über eine Pipeline aus Sitzungsauflösung, Warteschlangenbildung, Streaming, Tool-Ausführung und Reasoning-Sichtbarkeit. Diese Seite zeichnet den Weg von der eingehenden Nachricht bis zur Antwort nach.

## Nachrichtenfluss (allgemein)

```
Inbound message
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)
```

Wichtige Stellschrauben befinden sich in der Konfiguration:

* `messages.*` für Präfixe, Warteschlangenbildung und Gruppenverhalten.
* `agents.defaults.*` für Block-Streaming- und Chunking-Standardwerte.
* Kanal-Overrides (`channels.whatsapp.*`, `channels.telegram.*` usw.) für Limits und Streaming-Schalter.

Das vollständige Schema finden Sie unter [Konfiguration](/de/gateway/configuration).

## Deduplizierung eingehender Nachrichten

Kanäle können dieselbe Nachricht nach erneuten Verbindungen erneut zustellen. OpenClaw hält einen kurzlebigen Cache vor, der nach Kanal/Konto/Peer/Sitzung/Nachrichten-ID geschlüsselt ist, damit doppelte Zustellungen keine weitere Agent-Ausführung auslösen.

## Entprellung eingehender Nachrichten

Schnell aufeinanderfolgende Nachrichten desselben **Absenders** können über `messages.inbound` zu einem einzigen Agent-Turn gebündelt werden. Die Entprellung ist pro Kanal + Unterhaltung begrenzt und verwendet die neueste Nachricht für Antwort-Threading/IDs.

Konfiguration (globaler Standard + kanalbezogene Overrides):

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
```

Hinweise:

* Entprellung gilt für reine **Textnachrichten**; Medien/Anhänge lösen sofortiges Flushen aus.
* Steuerbefehle umgehen die Entprellung, damit sie eigenständig bleiben. Kanäle, die ausdrücklich in das Zusammenführen von Direktnachrichten desselben Absenders einwilligen, können DM-Befehle innerhalb des Entprellungsfensters behalten, sodass ein aufgeteiltes Payload in denselben Agent-Turn einfließen kann.

## Sitzungen und Geräte

Sitzungen gehören dem Gateway, nicht den Clients.

* Direktchats werden auf den Hauptsitzungsschlüssel des Agents zusammengeführt.
* Gruppen/Kanäle erhalten eigene Sitzungsschlüssel.
* Sitzungsspeicher und Transkripte liegen auf dem Gateway-Host.

Mehrere Geräte/Kanäle können derselben Sitzung zugeordnet werden, der Verlauf wird jedoch nicht vollständig an jeden Client zurücksynchronisiert. Empfehlung: Verwenden Sie für lange Unterhaltungen ein primäres Gerät, um abweichenden Kontext zu vermeiden. Die Control UI und TUI zeigen immer das Gateway-gestützte Sitzungstranskript und sind daher die Quelle der Wahrheit.

Details: [Sitzungsverwaltung](/de/concepts/session).

## Tool-Ergebnis-Metadaten

Tool-Ergebnis-`content` ist das für das Modell sichtbare Ergebnis. Tool-Ergebnis-`details` sind Laufzeitmetadaten für UI-Rendering, Diagnose, Medienzustellung und Plugins.

OpenClaw hält diese Grenze ausdrücklich ein:

* `toolResult.details` wird vor Provider-Replay und Compaction-Eingabe entfernt.
* Persistierte Sitzungstranskripte behalten nur begrenzte `details`; übergroße Metadaten werden durch eine kompakte Zusammenfassung mit `persistedDetailsTruncated: true` ersetzt.
* Plugins und Tools sollten Text, den das Modell lesen muss, in `content` ablegen, nicht nur in `details`.

## Eingehende Inhalte und Verlaufskontext

OpenClaw trennt den **Prompt-Text** vom **Befehlstext**:

* `BodyForAgent`: Primärer modellbezogener Text für die aktuelle Nachricht. Kanal-Plugins sollten diesen auf den aktuellen prompt-tragenden Text des Absenders fokussieren.
* `Body`: Legacy-Prompt-Fallback. Dies kann Kanalumschläge und optionale Verlaufs-Wrapper enthalten, aktuelle Kanäle sollten sich jedoch nicht darauf als primäre Modelleingabe verlassen, wenn `BodyForAgent` verfügbar ist.
* `CommandBody`: Roher Benutzertext für Direktiven-/Befehls-Parsing.
* `RawBody`: Legacy-Alias für `CommandBody` (aus Kompatibilitätsgründen beibehalten).

Wenn ein Kanal Verlauf bereitstellt, verwendet er einen gemeinsamen Wrapper:

* `[Chat messages since your last reply - for context]`
* `[Current message - respond to this]`

Bei **Nicht-Direktchats** (Gruppen/Kanäle/Räume) wird dem **aktuellen Nachrichtentext** das Absenderlabel vorangestellt (im selben Stil wie bei Verlaufseinträgen). Dadurch bleiben Echtzeit- und Warteschlangen-/Verlaufsnachrichten im Agent-Prompt konsistent.

Verlaufspuffer sind **nur ausstehend**: Sie enthalten Gruppennachrichten, die *keine* Ausführung ausgelöst haben (zum Beispiel erwähnungsgesteuerte Nachrichten), und **schließen** Nachrichten aus, die bereits im Sitzungstranskript stehen.

Das Entfernen von Direktiven gilt nur für den Abschnitt der **aktuellen Nachricht**, damit der Verlauf intakt bleibt. Kanäle, die Verlauf wrappen, sollten `CommandBody` (oder `RawBody`) auf den ursprünglichen Nachrichtentext setzen und `Body` als kombinierten Prompt behalten. Strukturierte Verlaufs-, Antwort-, Weiterleitungs- und Kanalmetadaten werden bei der Prompt-Zusammenstellung als nicht vertrauenswürdige Kontextblöcke mit Benutzerrolle gerendert.
Verlaufspuffer sind über `messages.groupChat.historyLimit` (globaler Standard) und kanalbezogene Overrides wie `channels.slack.historyLimit` oder `channels.telegram.accounts.<id>.historyLimit` konfigurierbar (setzen Sie `0`, um sie zu deaktivieren).

## Warteschlangenbildung und Follow-ups

Wenn bereits eine Ausführung aktiv ist, werden eingehende Nachrichten standardmäßig in die aktuelle Ausführung gelenkt. `messages.queue` legt fest, ob Nachrichten während aktiver Ausführungen lenken, für später in die Warteschlange gestellt, zu einem späteren Turn gesammelt oder die aktive Ausführung unterbrechen.

* Konfigurieren Sie dies über `messages.queue` (und `messages.queue.byChannel`).
* Der Standardmodus ist `steer`, mit 500 ms Entprellung für Codex-Steuerungsbündel und Follow-up-/Sammelwarteschlangen.
* Modi: `steer`, `followup`, `collect` und `interrupt`.

Details: [Befehlswarteschlange](/de/concepts/queue) und [Steuerungswarteschlange](/de/concepts/queue-steering).

## Besitz der Kanalausführung

Kanal-Plugins können Reihenfolge beibehalten, Eingaben entprellen und Transport-Backpressure anwenden, bevor eine Nachricht in die Sitzungswarteschlange gelangt. Sie sollten keinen separaten Timeout um den Agent-Turn selbst erzwingen. Sobald eine Nachricht an eine Sitzung geroutet wurde, wird langlaufende Arbeit durch den Sitzungs-, Tool- und Laufzeit-Lebenszyklus gesteuert, sodass alle Kanäle langsame Turns konsistent melden und wiederherstellen.

## Streaming, Chunking und Bündelung

Block-Streaming sendet Teilantworten, während das Modell Textblöcke erzeugt. Chunking respektiert Textlimits des Kanals und vermeidet das Aufteilen von eingezäunten Codeblöcken.

Wichtige Einstellungen:

* `agents.defaults.blockStreamingDefault` (`on|off`, standardmäßig aus)
* `agents.defaults.blockStreamingBreak` (`text_end|message_end`)
* `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`)
* `agents.defaults.blockStreamingCoalesce` (leerlaufbasierte Bündelung)
* `agents.defaults.humanDelay` (menschenähnliche Pause zwischen Blockantworten)
* Kanal-Overrides: `*.blockStreaming` und `*.blockStreamingCoalesce` (Nicht-Telegram-Kanäle erfordern ausdrücklich `*.blockStreaming: true`)

Details: [Streaming + Chunking](/de/concepts/streaming).

## Reasoning-Sichtbarkeit und Token

OpenClaw kann Modell-Reasoning einblenden oder ausblenden:

* `/reasoning on|off|stream` steuert die Sichtbarkeit.
* Reasoning-Inhalte zählen weiterhin zur Token-Nutzung, wenn sie vom Modell erzeugt werden.
* Telegram unterstützt Reasoning-Streaming in eine flüchtige Entwurfsblase, die nach der endgültigen Zustellung gelöscht wird; verwenden Sie `/reasoning on` für persistente Reasoning-Ausgabe.

Details: [Thinking + Reasoning-Direktiven](/de/tools/thinking) und [Token-Nutzung](/de/reference/token-use).

## Präfixe, Threading und Antworten

Die Formatierung ausgehender Nachrichten ist in `messages` zentralisiert:

* `messages.responsePrefix`, `channels.<channel>.responsePrefix` und `channels.<channel>.accounts.<id>.responsePrefix` (Kaskade ausgehender Präfixe), plus `channels.whatsapp.messagePrefix` (eingehendes WhatsApp-Präfix)
* Antwort-Threading über `replyToMode` und kanalbezogene Standardwerte

Details: [Konfiguration](/de/gateway/config-agents#messages) und Kanaldokumentation.

## Stille Antworten

Das genaue stille Token `NO_REPLY` / `no_reply` bedeutet „keine für Benutzer sichtbare Antwort zustellen“.
Wenn ein Turn auch ausstehende Tool-Medien enthält, etwa erzeugtes TTS-Audio, entfernt OpenClaw den stillen Text, stellt den Medienanhang aber dennoch zu.
OpenClaw löst dieses Verhalten nach Unterhaltungstyp auf:

* Direkte Unterhaltungen erhalten nie `NO_REPLY`-Prompt-Anleitung. Wenn eine direkte Ausführung versehentlich ein nacktes stilles Token zurückgibt, unterdrückt OpenClaw es, statt es umzuschreiben oder zuzustellen.
* Gruppen/Kanäle erlauben Stille standardmäßig nur für automatische Gruppenantworten. Im sichtbaren Antwortmodus `message_tool` bedeutet Stille, dass das Modell `message(action=send)` nicht aufruft.
* Interne Orchestrierung erlaubt Stille standardmäßig.

OpenClaw verwendet stille Antworten auch für generische interne Runner-Fehler in Nicht-Direktchats, sodass Gruppen/Kanäle keine Gateway-Fehlerstandardtexte sehen.
Klassifizierte Fehler mit benutzerorientiertem Wiederherstellungstext, etwa fehlende Authentifizierung, Rate-Limit- oder Überlastungshinweise, können weiterhin zugestellt werden. Direktchats zeigen standardmäßig kompakte Fehlertexte; rohe Runner-Details werden nur angezeigt, wenn `/verbose full` aktiviert ist.

Standardwerte befinden sich unter `agents.defaults.silentReply`; `surfaces.<id>.silentReply` kann Gruppen-/interne Richtlinien pro Oberfläche überschreiben.

Nackte stille Antworten werden auf allen Oberflächen verworfen, sodass übergeordnete Sitzungen still bleiben, statt Sentinel-Text in Fallback-Geplauder umzuschreiben.

## Verwandte Themen

* [Refaktorierung des Nachrichtenlebenszyklus](/de/concepts/message-lifecycle-refactor) - Zielentwurf für dauerhaftes Senden und Empfangen
* [Streaming](/de/concepts/streaming) — Nachrichtenzustellung in Echtzeit
* [Retry](/de/concepts/retry) — Wiederholungsverhalten bei der Nachrichtenzustellung
* [Warteschlange](/de/concepts/queue) — Warteschlange für Nachrichtenverarbeitung
* [Kanäle](/de/channels) — Integrationen für Messaging-Plattformen