訊息

OpenClaw 透過會話解析、佇列、串流、工具執行和推理可見性的管線來處理傳入訊息。本頁面繪製了從傳入訊息到回覆的路徑。

訊息流程（高層級）

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

關鍵調整選項位於設定中：

messages.* 用於前綴、佇列和群組行為。
agents.defaults.* 用於區塊串流和分塊預設值。
頻道覆寫（channels.whatsapp.*、channels.telegram.* 等）用於上限和串流切換。

完整架構請參閱 Configuration。

傳入去重

頻道可能會在重新連線後重新傳送相同的訊息。OpenClaw 會維護一個短期快取，以頻道/帳戶/對等/會話/訊息 ID 作為鍵值，以確保重複傳送不會觸發另一次代理程式執行。

傳入防抖

來自相同發送者的快速連續訊息可以透過 messages.inbound 合併為單一代理程式回合。防抖範圍涵蓋每個頻道 + 對話，並使用最新的訊息進行回覆執行緒/ID 處理。

設定（全域預設值 + 各頻道覆寫）：

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

註記：

防抖僅適用於純文字訊息；媒體/附件會立即清除。
控制指令會略過去彈跳（debounce），使其保持獨立。明確選擇加入相同發送者私訊合併的頻道，可以將私訊指令保留在去彈跳視窗內，以便分割發送的酬載能加入同一個代理回合。

會話和裝置

會話由閘道擁有，而非由用戶端擁有。

直接聊天會合併為代理程式主會話金鑰。
群組/頻道會獲得自己的會話金鑰。
會話儲存和逐字稿位於閘道主機上。

多個裝置/頻道可以對應到同一個會話，但歷史記錄不會完全同步回每個用戶端。建議：使用一個主要裝置進行長時間對話，以避免上下文分歧。控制 UI 和 TUI 始終顯示閘道支援的會話逐字稿，因此它們是事實來源。

詳情：Session management。

工具結果元資料

工具結果 content 是模型可見的結果。工具結果 details 是用於 UI 渲染、診斷、媒體傳遞和外掛程式的執行時期中繼資料。

OpenClaw 保持該邊界清晰：

toolResult.details 會在提供者重播和壓縮輸入之前被移除。
持久化的會話記錄僅保留有界的 details；過大的中繼資料會被標記為 persistedDetailsTruncated: true 的精簡摘要所取代。
外掛程式和工具應將模型必須閱讀的文字放在 content 中，而不僅僅是在 details 中。

輸入內容與歷史記錄上下文

OpenClaw 將 提示主體 與 指令主體 分開：

BodyForAgent：當前訊息的主要面向模型的文字。頻道外掛程式應將此內容重點放在發送者當前的提示文字上。
Body：舊版提示後援。這可能包含頻道封包和可選的歷史記錄包裝器，但當 BodyForAgent 可用時，目前的頻道不應將其依賴為主要的模型輸入。
CommandBody：用於指令/命令解析的原始使用者文字。
RawBody：CommandBody 的舊版別名（為了相容性而保留）。

當頻道提供歷史記錄時，它會使用一個共用的包裝器：

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

對於非直接聊天（群組/頻道/聊天室），目前訊息內文會加上發送者標籤的前綴（與歷史記錄項目使用的樣式相同）。這能確保即時訊息和佇列/歷史訊息在代理提示中保持一致。

歷史緩衝區是僅待處理的：它們包含未觸發執行的群組訊息（例如，提及閘道的訊息），並且排除已經在會話記錄中的訊息。

指令移除 (Directive stripping) 僅適用於 當前訊息 部分，因此歷史記錄保持不變。打包歷史記錄的頻道應將 CommandBody (或 RawBody) 設定為原始訊息文字，並將 Body 保留為組合後的提示詞。結構化的歷史記錄、回覆、轉發和頻道元數據在組裝提示詞期間會被渲染為使用者角色的非受信任內容區塊。歷史記錄緩衝區可透過 messages.groupChat.historyLimit (全域預設值) 和各頻道的覆寫設定來配置，例如 channels.slack.historyLimit 或 channels.telegram.accounts.<id>.historyLimit (設定 0 以停用)。

佇列與後續處理

如果運作已經處於活動狀態，傳入訊息預設會被導向目前的運作。messages.queue 選擇了活動運作訊息的導向方式：排入稍後佇列、收集為稍後的一個輪次，或中斷目前的運作。

透過 messages.queue (以及 messages.queue.byChannel) 進行設定。
預設模式是 steer，針對 Codex 導向批次以及後續/收集佇列有 500 毫秒的防動。
模式：steer、followup、collect 和 interrupt。

詳細資訊：指令佇列和導向佇列。

頻道執行權

頻道外掛程式可以在訊息進入工作階段佇列之前維持順序、對輸入進行防抖處理，並套用傳輸反向壓力。它們不應在代理輪次周圍設定獨立的逾時。一旦訊息被路由到工作階段，長時間執行的工作即由工作階段、工具和執行時生命週期管理，以便所有頻道都能一致地回報並從緩慢的輪次中恢復。

串流、分塊與批次處理

區塊串流會在模型產生文字區塊時發送部分回覆。分塊會遵守頻道文字限制，並避免分割圍欄程式碼。

關鍵設定：

agents.defaults.blockStreamingDefault (on|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)

詳情：串流 + 分塊。

推理可見性和 Token

OpenClaw 可以顯示或隱藏模型推理：

/reasoning on|off|stream 控制可見度。
當推理內容由模型生成時，仍會計入 Token 使用量。
Telegram 支援將推理串流到暫時的草稿氣泡中，該氣泡會在最終傳送後刪除；請使用 /reasoning on 進行持續性的推理輸出。

詳情：思考 + 推理指令和 Token 使用。

前綴、串接和回覆

傳出訊息格式化集中在 messages 中：

messages.responsePrefix、channels.<channel>.responsePrefix 和 channels.<channel>.accounts.<id>.responsePrefix (傳出前綴級聯)，加上 channels.whatsapp.messagePrefix (WhatsApp 傳入前綴)
透過 replyToMode 和各頻道預設值進行回覆串接

詳情：組態和頻道文件。

靜默回覆

確切的靜默權杖 NO_REPLY / no_reply 意指「不傳送使用者可見的回覆」。當某個輪次也有待處理的工具媒體（例如生成的 TTS 音訊）時，OpenClaw 會移除靜默文字，但仍會傳送媒體附件。 OpenClaw 會根據對話類型解析該行為：

直接對話從不接收 NO_REPLY 提示指導。如果直接運作意外返回單純的靜默權杖，OpenClaw 會將其抑制，而非重寫或傳送它。
群組/頻道僅針對自動群組回覆預設允許靜默。在 message_tool visible-reply 模式下，靜默意味著模型不會呼叫 message(action=send)。
內部協調預設允許靜默。

在非直接聊天中，若在任何助理回覆之前發生內部執行器失敗，OpenClaw 也會使用靜默回覆，因此群組/頻道不會看到閘道錯誤範本。直接聊天預設會顯示簡潔的失敗訊息；只有當 /verbose 為 on 或 full 時，才會顯示原始執行器詳細資訊。

預設值位於 agents.defaults.silentReply 之下； surfaces.<id>.silentReply 可以針對每個介面覆寫群組/內部原則。

純靜默回覆會在所有介面上被捨棄，因此父階段會保持安靜，而不會將標記文字重寫為備用閒聊。

訊息