Nachrichten

Diese Seite verbindet die verschiedenen Aspekte, wie OpenClaw eingehende Nachrichten, Sitzungen, Queueing, Streaming und Reasoning-Sichtbarkeit handhabt.

Nachrichtenfluss (Ueberblick)

Eingehende Nachricht
  -> Routing/Bindings -> Sitzungsschluessel
  -> Queue (wenn ein Durchlauf aktiv ist)
  -> Agent-Durchlauf (Streaming + Tools)
  -> Ausgehende Antworten (Kanal-Limits + Chunking)

Die wichtigsten Stellschrauben liegen in der Konfiguration:

• messages.* fuer Praefixe, Queueing und Gruppenverhalten.
• agents.defaults.* fuer Block-Streaming- und Chunking-Defaults.
• Kanal-Overrides (channels.whatsapp.*, channels.telegram.* usw.) fuer Limits und Streaming-Toggles.

Siehe Konfiguration fuer das vollstaendige Schema.

Eingangs-Deduplizierung

Kanaele koennen dieselbe Nachricht nach Reconnects erneut zustellen. OpenClaw haelt einen kurzlebigen Cache, geschluesselt nach Kanal/Account/Peer/Sitzung/Nachrichten-ID, damit doppelte Zustellungen keinen weiteren Agent-Durchlauf ausloesen.

Eingangs-Debouncing

Schnell aufeinanderfolgende Nachrichten vom selben Absender koennen ueber messages.inbound zu einem einzelnen Agent-Turn zusammengefasst werden. Debouncing ist pro Kanal + Konversation begrenzt und nutzt die neueste Nachricht fuer Reply-Threading/IDs.

Config (globaler Standard + kanalspezifische Overrides):

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

Hinweise:

• Debounce gilt fuer reine Textnachrichten; Medien/Anhaenge werden sofort verarbeitet.
• Steuerbefehle umgehen das Debouncing, damit sie eigenstaendig bleiben.

Sitzungen und Geraete

Sitzungen gehoeren dem Gateway, nicht den Clients.

• Direktchats werden in den Hauptsitzungsschluessel des Agenten zusammengefuehrt.
• Gruppen/Kanaele bekommen eigene Sitzungsschluessel.
• Der Sitzungsspeicher und die Transkripte liegen auf dem Gateway-Host.

Mehrere Geraete/Kanaele koennen auf dieselbe Sitzung abgebildet werden, aber die Historie wird nicht vollstaendig an jeden Client zuruecksynchronisiert. Empfehlung: Nutze ein primaeres Geraet fuer lange Konversationen, um divergierenden Kontext zu vermeiden. Die Control-UI und das TUI zeigen immer das gateway-gestuetzte Sitzungstranskript — sie sind die Wahrheitsquelle.

Details: Sitzungsverwaltung.

Eingangs-Bodies und Historienkontext

OpenClaw trennt den Prompt-Body vom Command-Body:

• Body: Prompt-Text, der an den Agenten gesendet wird. Kann Kanal-Envelopes und optionale Historien-Wrapper enthalten.
• CommandBody: roher Nutzertext fuer Direktive-/Befehlsanalyse.
• RawBody: Legacy-Alias fuer CommandBody (aus Kompatibilitaetsgruenden beibehalten).

Wenn ein Kanal Historie liefert, verwendet er einen gemeinsamen Wrapper:

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

Fuer Nicht-Direktchats (Gruppen/Kanaele/Raeume) wird dem aktuellen Nachrichtentext das Absender-Label vorangestellt (im selben Stil wie bei Historieneintraegen). Das haelt Echtzeit- und gepufferte/Historiennachrichten im Agent-Prompt konsistent.

Historienpuffer sind nur ausstehende Nachrichten: Sie enthalten Gruppennachrichten, die keinen Durchlauf ausgeloest haben (zum Beispiel Mention-gesteuerte Nachrichten) und schliessen Nachrichten aus, die bereits im Sitzungstranskript stehen.

Direktiven-Stripping gilt nur fuer den aktuellen Nachricht-Abschnitt, damit die Historie intakt bleibt. Kanaele, die Historie einbetten, sollten CommandBody (oder RawBody) auf den originalen Nachrichtentext setzen und Body als kombinierten Prompt belassen. Historienpuffer sind konfigurierbar ueber messages.groupChat.historyLimit (globaler Standard) und kanalspezifische Overrides wie channels.slack.historyLimit oder channels.telegram.accounts.<id>.historyLimit (setze 0 zum Deaktivieren).

Queueing und Followups

Wenn ein Durchlauf bereits aktiv ist, koennen eingehende Nachrichten in die Queue gestellt, in den aktuellen Durchlauf gesteuert oder fuer einen Followup-Turn gesammelt werden.

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

Details: Queueing.

Streaming, Chunking und Batching

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

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)
• Kanal-Overrides: *.blockStreaming und *.blockStreamingCoalesce (Nicht-Telegram-Kanaele brauchen explizites *.blockStreaming: true)

Details: Streaming und Chunking.

Reasoning-Sichtbarkeit und Tokens

OpenClaw kann Modell-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- und Reasoning-Direktiven und Token-Nutzung.

Praefixe, Threading und Antworten

Die Formatierung ausgehender Nachrichten ist zentralisiert in messages:

• messages.responsePrefix, channels.<channel>.responsePrefix und channels.<channel>.accounts.<id>.responsePrefix (ausgehende Praefix-Kaskade), plus channels.whatsapp.messagePrefix (WhatsApp-Eingangs-Praefix)
• Reply-Threading ueber replyToMode und kanalspezifische Standards

Details: Konfiguration und Kanal-Dokumentation.