メッセージ
このページでは、OpenClawが受信メッセージ、セッション、キューイング、ストリーミング、および推論の可視性をどのように処理するかをまとめています。
メッセージフロー（概要）
受信メッセージ
-> ルーティング/バインディング -> セッションキー
-> キュー (実行がアクティブな場合)
-> エージェント実行 (ストリーミング + ツール)
-> 送信返信 (チャネル制限 + チャンキング)
主要な設定項目は設定にあります:
messages.*は、プレフィックス、キューイング、およびグループ動作のためです。agents.defaults.*は、ブロックストリーミングとチャンキングのデフォルトのためです。- チャネルオーバーライド (
channels.whatsapp.*,channels.telegram.*など) は、上限とストリーミングの切り替えのためです。
完全なスキーマについては 設定 を参照してください。
受信重複排除
チャネルは再接続後に同じメッセージを再配信することがあります。OpenClawは、チャネル/アカウント/ピア/セッション/メッセージIDをキーとする短命のキャッシュを保持するため、重複配信によって別のエージェント実行がトリガーされることはありません。
受信デバウンス
同じ送信者からの連続した高速なメッセージは、messages.inbound を介して単一のエージェントターンにバッチ処理できます。デバウンスはチャネル + 会話ごとにスコープされ、最新のメッセージが返信のスレッド/IDに使用されます。設定 (グローバルデフォルト + チャネルごとのオーバーライド):
{
messages: {
inbound: {
debounceMs: 2000,
byChannel: {
whatsapp: 5000,
slack: 1500,
discord: 1500,
},
},
},
}
注意:
- デバウンスは テキストのみ のメッセージに適用されます。メディア/添付ファイルは即座にフラッシュされます。
- 制御コマンドはデバウンスをバイパスするため、独立したままです。
セッションとデバイス
セッションはクライアントではなく、ゲートウェイによって所有されます。
- ダイレクトチャットはエージェントのメインセッションキーに統合されます。
- グループ/チャネルは独自のセッションキーを取得します。
- セッションストアとトランスクリプトはゲートウェイホスト上に存在します。
複数のデバイス/チャネルが同じセッションにマッピングされることがありますが、履歴はすべてのクライアントに完全に同期されません。推奨: コンテキストの分岐を避けるために、長い会話には1つのプライマリデバイスを使用してください。Control UIとTUIは常にゲートウェイが保持するセッショントランスクリプトを表示するため、これらが信頼できる情報源となります。詳細: セッション管理。
受信本文と履歴コンテキスト
OpenClawは プロンプト本文 と コマンド本文 を分離します:
Body: エージェントに送信されるプロンプトテキスト。これにはチャネルエンベロープとオプションの履歴ラッパーが含まれる場合があります。CommandBody: ディレクティブ/コマンド解析のための生のユーザーテキスト。RawBody:CommandBodyのレガシーエイリアス (互換性のために保持)。
チャネルが履歴を提供する場合、共有ラッパーを使用します:
[前回の返信以降のチャットメッセージ - コンテキスト用][現在のメッセージ - これに応答してください]
非ダイレクトチャット (グループ/チャネル/ルーム) の場合、現在のメッセージ本文には送信者ラベルがプレフィックスとして付加されます (履歴エントリで使用されるのと同じスタイル)。これにより、エージェントプロンプト内のリアルタイムメッセージとキュー/履歴メッセージの一貫性が保たれます。履歴バッファは 保留中のみ です: これには実行をトリガーしなかったグループメッセージ (例えば、メンションゲートされたメッセージ) が含まれ、セッショントランスクリプトに既にあるメッセージは除外されます。ディレクティブの除去は 現在のメッセージ セクションにのみ適用されるため、履歴はそのまま残ります。履歴をラップするチャネルは、CommandBody (または RawBody) を元のメッセージテキストに設定し、Body を結合されたプロンプトとして保持する必要があります。履歴バッファは messages.groupChat.historyLimit (グローバルデフォルト) および channels.slack.historyLimit や channels.telegram.accounts.<id>.historyLimit などのチャネルごとのオーバーライドで設定可能です (0 に設定すると無効になります)。
キューイングとフォローアップ
実行が既にアクティブな場合、受信メッセージはキューイングされたり、現在の実行に誘導されたり、フォローアップターン用に収集されたりすることがあります。
messages.queue(およびmessages.queue.byChannel) で設定します。- モード:
interrupt,steer,followup,collect、およびバックログバリアント。
詳細: キューイング。
ストリーミング、チャンキング、バッチ処理
ブロックストリーミングは、モデルがテキストブロックを生成する際に部分的な返信を送信します。チャンキングはチャネルのテキスト制限を尊重し、フェンスで囲まれたコードの分割を避けます。主要な設定:
agents.defaults.blockStreamingDefault(on|off、デフォルト off)agents.defaults.blockStreamingBreak(text_end|message_end)agents.defaults.blockStreamingChunk(minChars|maxChars|breakPreference)agents.defaults.blockStreamingCoalesce(アイドルベースのバッチ処理)agents.defaults.humanDelay(ブロック返信間の人間らしい一時停止)- チャネルオーバーライド:
*.blockStreamingおよび*.blockStreamingCoalesce(Telegram以外のチャネルでは明示的な*.blockStreaming: trueが必要)
詳細: ストリーミング + チャンキング。
推論の可視性とトークン
OpenClawはモデルの推論を公開または非表示にできます:
/reasoning on|off|streamが可視性を制御します。- 推論コンテンツは、モデルによって生成された場合、トークン使用量に依然としてカウントされます。
- Telegramはドラフトバブルへの推論ストリームをサポートしています。
詳細: 思考 + 推論ディレクティブ および トークン使用。
プレフィックス、スレッド化、返信
送信メッセージのフォーマットは messages に一元化されています:
messages.responsePrefix,channels.<channel>.responsePrefix, およびchannels.<channel>.accounts.<id>.responsePrefix(送信プレフィックスカスケード)、さらにchannels.whatsapp.messagePrefix(WhatsApp受信プレフィックス)replyToModeおよびチャネルごとのデフォルトによる返信スレッド化
詳細: 設定 およびチャネルドキュメント。