ステアリングキュー

通常のプロンプトが到着した時点でセッション実行がすでにストリーミング中の場合、キューモードが steer であれば、OpenClaw はデフォルトでそのプロンプトをアクティブなランタイムへ送信しようとします。このデフォルト動作に設定エントリやキューディレクティブは必要ありません。OpenClaw とネイティブの Codex app-server ハーネスでは、配信の詳細の実装が異なります。

ランタイム境界

ステアリングは、すでに実行中のツール呼び出しを中断しません。OpenClaw はモデル境界でキュー内のステアリングメッセージを確認します。

1. アシスタントがツール呼び出しを要求します。
2. OpenClaw が現在のアシスタントメッセージのツール呼び出しバッチを実行します。
3. OpenClaw がターン終了イベントを発行します。
4. OpenClaw がキュー内のステアリングメッセージを排出します。
5. OpenClaw が次の LLM 呼び出しの前に、それらのメッセージをユーザーメッセージとして追加します。

これにより、ツール結果はそれを要求したアシスタントメッセージと対応付けられたままになり、その後のモデル呼び出しで最新のユーザー入力を参照できます。

ネイティブの Codex app-server ハーネスは、OpenClaw ランタイムの内部ステアリングキューの代わりに turn/steer を公開します。OpenClaw は、設定された静止ウィンドウの間、キュー内のプロンプトをバッチ化し、その後、収集したすべてのユーザー入力を到着順に含む単一の turn/steer リクエストを送信します。

Codex レビューと手動 Compaction ターンは、同一ターンのステアリングを拒否します。ランタイムが steer モードでステアリングを受け付けられない場合、OpenClaw はアクティブな実行が完了するまで待ってからプロンプトを開始します。

このページでは、モードが steer の場合の通常の受信メッセージに対するキューモードのステアリングについて説明します。モードが followup または collect の場合、通常のメッセージはこのステアリング経路に入りません。アクティブな実行が完了するまで待機します。明示的な /steer <message> コマンドについては、ステアリングを参照してください。

モード

バーストの例

エージェントがツール呼び出しを実行している間に 4 人のユーザーがメッセージを送信した場合:

• デフォルト動作では、アクティブなランタイムは次のモデル判断の前に 4 件すべてのメッセージを到着順で受け取ります。OpenClaw は次のモデル境界でそれらを排出し、Codex はそれらを 1 つのバッチ化された turn/steer として受け取ります。
• /queue collect では、OpenClaw はステアリングしません。アクティブな実行が終了するまで待機し、その後、デバウンスウィンドウ後に互換性のあるキュー内のメッセージでフォローアップターンを作成します。
• /queue interrupt では、OpenClaw はアクティブな実行を中止し、ステアリングする代わりに最新のメッセージを開始します。

スコープ

ステアリングは常に現在のアクティブなセッション実行を対象にします。新しいセッションを作成したり、アクティブな実行のツールポリシーを変更したり、送信者ごとにメッセージを分割したりすることはありません。複数ユーザーのチャンネルでは、受信プロンプトに送信者とルートのコンテキストがすでに含まれているため、次のモデル呼び出しは各メッセージを誰が送信したかを参照できます。

アクティブな実行をステアリングする代わりに、デフォルトでメッセージをキューに入れたい場合は followup または collect を使用します。最新のプロンプトでアクティブな実行を置き換えるべき場合は interrupt を使用します。

デバウンス

messages.queue.debounceMs は、キュー内の followup および collect 配信に適用されます。ネイティブの Codex ハーネスで steer モードを使用する場合は、バッチ化された turn/steer を送信する前の静止ウィンドウも設定します。OpenClaw では、アクティブなステアリング自体はデバウンスタイマーを使用しません。OpenClaw は次のモデル境界まで自然にメッセージをバッチ化するためです。

関連

• コマンドキュー
• ステアリング
• メッセージ
• エージェントループ