---
read_when:
    - อธิบายว่าข้อความขาเข้ากลายเป็นการตอบกลับได้อย่างไร
    - การอธิบายเซสชัน โหมดการจัดคิว หรือพฤติกรรมการสตรีมให้ชัดเจน
    - การจัดทำเอกสารเกี่ยวกับการมองเห็นการให้เหตุผลและผลกระทบด้านการใช้งาน
summary: โฟลว์ข้อความ เซสชัน การเข้าคิว และการมองเห็นการให้เหตุผล
title: ข้อความ
x-i18n:
    generated_at: "2026-06-27T17:27:49Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: d5585ae95fc65cb64240e4bf5d0bbe2eb54f55461b9fa4ee331d4d703d62e76f
    source_path: concepts/messages.md
    workflow: 16
---

OpenClaw จัดการข้อความขาเข้าผ่านไปป์ไลน์ของการแก้ไขเซสชัน การเข้าคิว การสตรีม การเรียกใช้เครื่องมือ และการมองเห็นการให้เหตุผล หน้านี้แสดงเส้นทางตั้งแต่ข้อความขาเข้าจนถึงการตอบกลับ

## โฟลว์ข้อความ (ภาพรวมระดับสูง)

```
ข้อความขาเข้า
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)
```

ปุ่มปรับหลักอยู่ในการกำหนดค่า:

- `messages.*` สำหรับคำนำหน้า การเข้าคิว และพฤติกรรมของกลุ่ม
- `agents.defaults.*` สำหรับค่าเริ่มต้นของการสตรีมแบบบล็อกและการแบ่งชิ้น
- การ override ของช่องทาง (`channels.whatsapp.*`, `channels.telegram.*` เป็นต้น) สำหรับเพดานและตัวเปิด/ปิดการสตรีม

ดู [การกำหนดค่า](/th/gateway/configuration) สำหรับสคีมาแบบเต็ม

## การตัดข้อความขาเข้าซ้ำ

ช่องทางอาจส่งข้อความเดิมซ้ำหลังจากเชื่อมต่อใหม่ OpenClaw เก็บแคชอายุสั้น
โดยใช้ channel/account/peer/session/message id เป็นคีย์ เพื่อไม่ให้การส่งซ้ำ
กระตุ้น agent run อีกครั้ง

## การ debounce ข้อความขาเข้า

ข้อความต่อเนื่องอย่างรวดเร็วจาก **ผู้ส่งคนเดียวกัน** สามารถถูกรวมเป็นเทิร์น
agent เดียวผ่าน `messages.inbound` ได้ การ debounce ถูกจำกัดขอบเขตต่อช่องทาง + บทสนทนา
และใช้ข้อความล่าสุดสำหรับการ thread การตอบกลับ/ID

การกำหนดค่า (ค่าเริ่มต้นส่วนกลาง + การ override รายช่องทาง):

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

หมายเหตุ:

- Debounce ใช้กับข้อความ **ที่เป็นข้อความล้วน**; สื่อ/ไฟล์แนบจะ flush ทันที
- คำสั่งควบคุมจะข้ามการ debounce เพื่อให้ยังคงเป็นรายการเดี่ยว ช่องทางที่เลือกใช้การรวม DM จากผู้ส่งคนเดียวกันอย่างชัดเจนสามารถเก็บคำสั่ง DM ไว้ในหน้าต่าง debounce เพื่อให้ payload ที่ส่งแยกกันสามารถรวมเข้าเทิร์น agent เดียวกันได้

## เซสชันและอุปกรณ์

เซสชันเป็นของ Gateway ไม่ใช่ของไคลเอนต์

- แชทโดยตรงจะถูกรวมเป็น session key หลักของ agent
- กลุ่ม/ช่องทางจะได้ session key ของตัวเอง
- ที่เก็บเซสชันและ transcript อยู่บนโฮสต์ Gateway

อุปกรณ์/ช่องทางหลายรายการสามารถแมปไปยังเซสชันเดียวกันได้ แต่ประวัติจะไม่ถูก
ซิงค์กลับไปยังทุกไคลเอนต์อย่างสมบูรณ์ คำแนะนำ: ใช้อุปกรณ์หลักหนึ่งเครื่องสำหรับ
บทสนทนายาวเพื่อหลีกเลี่ยงบริบทที่แตกต่างกัน Control UI และ TUI จะแสดง transcript
ของเซสชันที่มี Gateway หนุนหลังเสมอ จึงเป็นแหล่งข้อมูลจริง

รายละเอียด: [การจัดการเซสชัน](/th/concepts/session)

## เมทาดาทาของผลลัพธ์เครื่องมือ

`content` ของผลลัพธ์เครื่องมือคือผลลัพธ์ที่โมเดลมองเห็น `details` ของผลลัพธ์เครื่องมือคือ
เมทาดาทารันไทม์สำหรับการเรนเดอร์ UI การวินิจฉัย การส่งสื่อ และ Plugin

OpenClaw รักษาขอบเขตนี้ให้ชัดเจน:

- `toolResult.details` จะถูกตัดออกก่อนการ replay ของผู้ให้บริการและอินพุตของ Compaction
- transcript เซสชันที่คงอยู่จะเก็บเฉพาะ `details` ที่มีขอบเขต; เมทาดาทาที่ใหญ่เกินไป
  จะถูกแทนที่ด้วยสรุปขนาดกะทัดรัดที่ทำเครื่องหมาย `persistedDetailsTruncated: true`
- Plugin และเครื่องมือควรใส่ข้อความที่โมเดลต้องอ่านไว้ใน `content` ไม่ใช่เฉพาะ
  ใน `details`

## เนื้อความขาเข้าและบริบทประวัติ

OpenClaw แยก **เนื้อความ prompt** ออกจาก **เนื้อความคำสั่ง**:

- `BodyForAgent`: ข้อความหลักที่ส่งให้โมเดลสำหรับข้อความปัจจุบัน Plugin
  ของช่องทางควรทำให้ส่วนนี้โฟกัสกับข้อความปัจจุบันของผู้ส่งที่มี prompt
- `Body`: fallback prompt แบบเดิม ส่วนนี้อาจรวม envelope ของช่องทางและ
  wrapper ประวัติเสริม แต่ช่องทางปัจจุบันไม่ควรพึ่งพาส่วนนี้เป็นอินพุตหลักของโมเดล
  เมื่อมี `BodyForAgent`
- `CommandBody`: ข้อความผู้ใช้ดิบสำหรับการแยก directive/คำสั่ง
- `RawBody`: alias เดิมสำหรับ `CommandBody` (คงไว้เพื่อความเข้ากันได้)

เมื่อช่องทางส่งประวัติมา จะใช้ wrapper ร่วมกัน:

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

สำหรับ **แชทที่ไม่ใช่แชทโดยตรง** (กลุ่ม/ช่องทาง/ห้อง) **เนื้อความข้อความปัจจุบัน** จะขึ้นต้นด้วย
ป้ายกำกับผู้ส่ง (สไตล์เดียวกับที่ใช้กับรายการประวัติ) สิ่งนี้ทำให้ข้อความแบบเรียลไทม์และข้อความที่เข้าคิว/ประวัติ
สอดคล้องกันใน prompt ของ agent

บัฟเฟอร์ประวัติเป็นแบบ **pending-only**: รวมข้อความกลุ่มที่ _ไม่ได้_
กระตุ้น run (ตัวอย่างเช่น ข้อความที่ต้องมีการ mention) และ **ไม่รวม** ข้อความ
ที่อยู่ใน transcript เซสชันแล้ว

การตัด directive ใช้กับส่วน **ข้อความปัจจุบัน** เท่านั้น เพื่อให้ประวัติ
ยังคงอยู่ครบถ้วน ช่องทางที่ wrap ประวัติควรตั้ง `CommandBody` (หรือ
`RawBody`) เป็นข้อความต้นฉบับ และเก็บ `Body` เป็น prompt ที่รวมแล้ว
ประวัติแบบมีโครงสร้าง การตอบกลับ การส่งต่อ และเมทาดาทาช่องทางจะถูกเรนเดอร์เป็น
บล็อกบริบทที่ไม่น่าเชื่อถือในบทบาทผู้ใช้ระหว่างการประกอบ prompt
บัฟเฟอร์ประวัติกำหนดค่าได้ผ่าน `messages.groupChat.historyLimit` (ค่าเริ่มต้นส่วนกลาง)
และการ override รายช่องทาง เช่น `channels.slack.historyLimit` หรือ
`channels.telegram.accounts.<id>.historyLimit` (ตั้ง `0` เพื่อปิดใช้งาน)

## การเข้าคิวและ followup

ถ้า run กำลังทำงานอยู่แล้ว ข้อความขาเข้าจะถูกนำเข้าสู่ run ปัจจุบันโดย
ค่าเริ่มต้น `messages.queue` เลือกว่าข้อความระหว่าง active-run จะ steer, เข้าคิวไว้
ภายหลัง, รวบรวมเป็นเทิร์นภายหลังเทิร์นเดียว, หรือขัดจังหวะ active run

- กำหนดค่าผ่าน `messages.queue` (และ `messages.queue.byChannel`)
- โหมดเริ่มต้นคือ `steer` โดยมี debounce 500ms สำหรับชุดการ steer ของ Codex และ
  คิว followup/collect
- โหมด: `steer`, `followup`, `collect`, และ `interrupt`

รายละเอียด: [คิวคำสั่ง](/th/concepts/queue) และ [คิวการ steer](/th/concepts/queue-steering)

## ความเป็นเจ้าของ run ของช่องทาง

Plugin ของช่องทางอาจรักษาลำดับ, debounce อินพุต, และใช้ backpressure ของ transport
ก่อนที่ข้อความจะเข้าสู่คิวเซสชัน ไม่ควรกำหนด timeout แยกต่างหากรอบเทิร์นของ agent เอง
เมื่อข้อความถูก route ไปยังเซสชันแล้ว งานที่ใช้เวลานานจะถูกกำกับโดย lifecycle
ของเซสชัน เครื่องมือ และรันไทม์ เพื่อให้ทุกช่องทางรายงานและกู้คืนจากเทิร์นที่ช้าได้อย่างสม่ำเสมอ

## การสตรีม การแบ่งชิ้น และการ batch

การสตรีมแบบบล็อกส่งการตอบกลับบางส่วนเมื่อโมเดลสร้างบล็อกข้อความ
การแบ่งชิ้นเคารพขีดจำกัดข้อความของช่องทางและหลีกเลี่ยงการแยก fenced code

การตั้งค่าหลัก:

- `agents.defaults.blockStreamingDefault` (`on|off`, ค่าเริ่มต้นปิด)
- `agents.defaults.blockStreamingBreak` (`text_end|message_end`)
- `agents.defaults.blockStreamingChunk` (`minChars|maxChars|breakPreference`)
- `agents.defaults.blockStreamingCoalesce` (การ batch ตาม idle)
- `agents.defaults.humanDelay` (การหยุดแบบมนุษย์ระหว่างการตอบกลับแบบบล็อก)
- การ override ของช่องทาง: `*.blockStreaming` และ `*.blockStreamingCoalesce` (ช่องทางที่ไม่ใช่ Telegram ต้องมี `*.blockStreaming: true` อย่างชัดเจน)

รายละเอียด: [การสตรีม + การแบ่งชิ้น](/th/concepts/streaming)

## การมองเห็นการให้เหตุผลและโทเค็น

OpenClaw สามารถเปิดเผยหรือซ่อนการให้เหตุผลของโมเดลได้:

- `/reasoning on|off|stream` ควบคุมการมองเห็น
- เนื้อหาการให้เหตุผลยังนับรวมในการใช้โทเค็นเมื่อโมเดลสร้างขึ้น
- Telegram รองรับสตรีมการให้เหตุผลเข้าไปใน draft bubble ชั่วคราวที่จะถูกลบหลังส่งมอบขั้นสุดท้าย; ใช้ `/reasoning on` สำหรับเอาต์พุตการให้เหตุผลแบบคงอยู่

รายละเอียด: [directive การคิด + การให้เหตุผล](/th/tools/thinking) และ [การใช้โทเค็น](/th/reference/token-use)

## คำนำหน้า การ thread และการตอบกลับ

การจัดรูปแบบข้อความขาออกรวมศูนย์อยู่ใน `messages`:

- `messages.responsePrefix`, `channels.<channel>.responsePrefix`, และ `channels.<channel>.accounts.<id>.responsePrefix` (ลำดับ cascade ของคำนำหน้าขาออก), รวมถึง `channels.whatsapp.messagePrefix` (คำนำหน้าขาเข้าของ WhatsApp)
- การ thread การตอบกลับผ่าน `replyToMode` และค่าเริ่มต้นรายช่องทาง

รายละเอียด: [การกำหนดค่า](/th/gateway/config-agents#messages) และเอกสารช่องทาง

## การตอบกลับแบบเงียบ

โทเค็นเงียบที่ตรงกันทุกประการ `NO_REPLY` / `no_reply` หมายถึง "ไม่ต้องส่งการตอบกลับที่ผู้ใช้มองเห็น"
เมื่อเทิร์นหนึ่งยังมีสื่อเครื่องมือที่ pending อยู่ เช่น เสียง TTS ที่สร้างขึ้น OpenClaw
จะตัดข้อความเงียบออกแต่ยังส่งไฟล์แนบสื่อนั้น
OpenClaw แก้ไขพฤติกรรมนั้นตามประเภทบทสนทนา:

- บทสนทนาโดยตรงจะไม่เคยได้รับคำแนะนำ prompt `NO_REPLY` ถ้า direct
  run คืนค่าเป็นโทเค็นเงียบล้วนโดยไม่ได้ตั้งใจ OpenClaw จะ suppress โทเค็นนั้นแทน
  การ rewrite หรือส่งมอบ
- กลุ่ม/ช่องทางอนุญาตให้เงียบโดยค่าเริ่มต้นเฉพาะสำหรับการตอบกลับกลุ่มอัตโนมัติ
  ในโหมดตอบกลับที่มองเห็นได้ของ `message_tool` ความเงียบหมายถึงโมเดลไม่เรียก
  `message(action=send)`
- การ orchestration ภายในอนุญาตให้เงียบโดยค่าเริ่มต้น

OpenClaw ยังใช้การตอบกลับแบบเงียบสำหรับความล้มเหลวทั่วไปของ runner ภายในใน
แชทที่ไม่ใช่แชทโดยตรง เพื่อให้กลุ่ม/ช่องทางไม่เห็น boilerplate ข้อผิดพลาดของ Gateway
ความล้มเหลวที่จำแนกแล้วพร้อมข้อความการกู้คืนสำหรับผู้ใช้ เช่น auth ขาดหาย,
rate-limit, หรือประกาศ overload ยังสามารถถูกส่งได้ แชทโดยตรงแสดง
ข้อความความล้มเหลวแบบกะทัดรัดโดยค่าเริ่มต้น; รายละเอียด runner ดิบจะแสดงเฉพาะเมื่อ
เปิดใช้ `/verbose full`

ค่าเริ่มต้นอยู่ใต้ `agents.defaults.silentReply`; `surfaces.<id>.silentReply`
สามารถ override นโยบายกลุ่ม/ภายในต่อ surface ได้

การตอบกลับแบบเงียบล้วนจะถูกทิ้งบนทุก surface เพื่อให้เซสชันแม่ยังคงเงียบ
แทนการ rewrite sentinel text เป็น fallback chatter

## ที่เกี่ยวข้อง

- [การ refactor lifecycle ข้อความ](/th/concepts/message-lifecycle-refactor) - เป้าหมายการออกแบบการส่งและรับที่ทนทาน
- [การสตรีม](/th/concepts/streaming) — การส่งข้อความแบบเรียลไทม์
- [Retry](/th/concepts/retry) — พฤติกรรมการ retry การส่งข้อความ
- [คิว](/th/concepts/queue) — คิวการประมวลผลข้อความ
- [ช่องทาง](/th/channels) — การผสานรวมแพลตฟอร์มรับส่งข้อความ