Nachrichten

Diese Seite erklaert, wie OpenClaw eingehende Nachrichten, Sessions, Warteschlangen, Streaming und Reasoning-Sichtbarkeit handhabt.

Nachrichtenfluss (Ueberblick)

Eingehende Nachricht
  -> Routing/Bindings -> Session-Key
  -> Warteschlange (falls ein Run aktiv ist)
  -> Agent Run (Streaming + Tools)
  -> Ausgehende Antworten (Channel-Limits + Chunking)

Die wichtigsten Einstellungen findest du in der Konfiguration:

  • messages.* fuer Praefixe, Warteschlangen und Gruppenverhalten.
  • agents.defaults.* fuer Block-Streaming und Chunking-Standardwerte.
  • Channel-Overrides (channels.whatsapp.*, channels.telegram.*, etc.) fuer Limits und Streaming-Optionen.

Details: Konfiguration.

Deduplizierung eingehender Nachrichten

Channels koennen dieselbe Nachricht nach Reconnects erneut senden. OpenClaw fuehrt einen kurzlebigen Cache mit Channel/Account/Peer/Session/Message-ID, damit doppelte Zustellungen keinen neuen Agent Run ausloesen.

Debouncing eingehender Nachrichten

Schnell aufeinanderfolgende Nachrichten vom selben Absender koennen ueber messages.inbound zu einem einzigen Agent-Turn zusammengefasst werden. Das Debouncing gilt pro Channel + Konversation und verwendet die neueste Nachricht fuer Reply-Threading/IDs.

Konfiguration (globaler Standard + Channel-Overrides):

{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}

Hinweise:

  • Debouncing gilt nur fuer reine Textnachrichten; Medien/Anhaenge werden sofort verarbeitet.
  • Steuerungsbefehle umgehen das Debouncing und bleiben eigenstaendig.

Sessions und Geraete

Sessions gehoeren dem Gateway, nicht den Clients.

  • Direkte Chats werden in den Haupt-Session-Key des Agents zusammengefasst.
  • Gruppen/Channels bekommen eigene Session-Keys.
  • Der Session-Store und die Transkripte liegen auf dem Gateway-Host.

Mehrere Geraete/Channels koennen auf dieselbe Session gemappt werden, aber der Verlauf wird nicht vollstaendig zu jedem Client synchronisiert. Empfehlung: Nutze ein primaeres Geraet fuer lange Konversationen, um unterschiedliche Kontexte zu vermeiden. Die Control UI und TUI zeigen immer das Gateway-gestuetzte Session-Transkript — sie sind die Quelle der Wahrheit.

Details: Session-Verwaltung.

Nachrichteninhalt und Verlaufskontext

OpenClaw trennt den Prompt-Body vom Command-Body:

  • Body: Prompt-Text, der an den Agent gesendet wird. Kann Channel-Envelopes und optionale History-Wrapper enthalten.
  • CommandBody: Roher Benutzertext fuer Direktiven-/Befehlsparsing.
  • RawBody: Legacy-Alias fuer CommandBody (aus Kompatibilitaetsgruenden beibehalten).

Wenn ein Channel Verlauf liefert, verwendet er einen gemeinsamen Wrapper:

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

Bei nicht-direkten Chats (Gruppen/Channels/Raeume) wird dem aktuellen Nachrichteninhalt das Absender-Label vorangestellt (im selben Stil wie bei Verlaufseintraegen). So bleiben Echtzeit- und Warteschlangen-/Verlaufsnachrichten im Agent-Prompt konsistent.

Verlaufspuffer sind nur ausstehend: Sie enthalten Gruppennachrichten, die keinen Run ausgeloest haben (z.B. Mention-gesteuerte Nachrichten) und schliessen Nachrichten aus, die bereits im Session-Transkript sind.

Direktiven-Stripping gilt nur fuer den aktuellen Nachrichtenabschnitt, damit der Verlauf intakt bleibt. Channels, die Verlauf wrappen, sollten CommandBody (oder RawBody) auf den urspruenglichen Nachrichtentext setzen und Body als kombinierten Prompt behalten. Verlaufspuffer sind konfigurierbar ueber messages.groupChat.historyLimit (globaler Standard) und Channel-Overrides wie channels.slack.historyLimit oder channels.telegram.accounts.<id>.historyLimit (setze 0 zum Deaktivieren).

Warteschlangen und Followups

Wenn bereits ein Run aktiv ist, koennen eingehende Nachrichten in die Warteschlange gestellt, in den aktuellen Run gelenkt oder fuer einen Followup-Turn gesammelt werden.

  • Konfiguriere ueber messages.queue (und messages.queue.byChannel).
  • Modi: interrupt, steer, followup, collect, plus Backlog-Varianten.

Details: Warteschlangen.

Streaming, Chunking und Batching

Block-Streaming sendet Teilantworten, waehrend das Modell Textbloecke produziert. Chunking respektiert Channel-Textlimits und vermeidet das Aufteilen von Code-Bloecken.

Wichtige Einstellungen:

  • agents.defaults.blockStreamingDefault (on|off, Standard: off)
  • agents.defaults.blockStreamingBreak (text_end|message_end)
  • agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
  • agents.defaults.blockStreamingCoalesce (Idle-basiertes Batching)
  • agents.defaults.humanDelay (menschenaehnliche Pause zwischen Block-Antworten)
  • Channel-Overrides: *.blockStreaming und *.blockStreamingCoalesce (Nicht-Telegram-Channels erfordern explizit *.blockStreaming: true)

Details: Streaming + Chunking.

Reasoning-Sichtbarkeit und Tokens

OpenClaw kann Model-Reasoning anzeigen oder verbergen:

  • /reasoning on|off|stream steuert die Sichtbarkeit.
  • Reasoning-Inhalte zaehlen trotzdem zum Token-Verbrauch, wenn sie vom Modell produziert werden.
  • Telegram unterstuetzt Reasoning-Stream in die Draft-Bubble.

Details: Thinking + Reasoning-Direktiven und Token-Verbrauch.

Praefixe, Threading und Antworten

Die Formatierung ausgehender Nachrichten ist in messages zentralisiert:

  • messages.responsePrefix (ausgehendes Praefix) und channels.whatsapp.messagePrefix (WhatsApp eingehendes Praefix)
  • Reply-Threading ueber replyToMode und Channel-spezifische Standards

Details: Konfiguration und Channel-Dokumentation.