---
read_when:
    - อธิบายวิธีการทำงานของการสตรีมหรือการแบ่งเป็นชิ้นบนช่องทาง
    - การเปลี่ยนพฤติกรรมการสตรีมบล็อกหรือการแบ่งชิ้นส่วนของช่องทาง
    - การดีบักการตอบกลับแบบบล็อกที่ซ้ำ/มาเร็วเกินไป หรือการสตรีมตัวอย่างช่องทาง
summary: พฤติกรรมการสตรีม + การแบ่งเป็นชิ้น (การตอบกลับแบบบล็อก, การสตรีมตัวอย่างช่องทาง, การแมปโหมด)
title: การสตรีมและการแบ่งเป็นชิ้น
x-i18n:
    generated_at: "2026-06-27T17:30:21Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 6667e95a1ed89e6bd8990a1b8784edb73885c59c7a3905eabc14184270efcfe1
    source_path: concepts/streaming.md
    workflow: 16
---

OpenClaw มีเลเยอร์การสตรีมแยกกันสองชั้น:

- **การสตรีมบล็อก (ช่องทาง):** ส่ง **บล็อก** ที่เสร็จแล้วขณะที่ผู้ช่วยเขียนอยู่ สิ่งเหล่านี้คือข้อความช่องทางปกติ (ไม่ใช่เดลตาโทเคน)
- **การสตรีมตัวอย่างก่อนส่ง (Telegram/Discord/Slack):** อัปเดต **ข้อความตัวอย่างก่อนส่ง** ชั่วคราวระหว่างการสร้าง

ปัจจุบัน **ยังไม่มีการสตรีมเดลตาโทเคนจริง** ไปยังข้อความช่องทาง การสตรีมตัวอย่างก่อนส่งทำงานแบบอิงข้อความ (ส่ง + แก้ไข/ต่อท้าย)

## การสตรีมบล็อก (ข้อความช่องทาง)

การสตรีมบล็อกจะส่งเอาต์พุตของผู้ช่วยเป็นชิ้นใหญ่แบบหยาบเมื่อพร้อมใช้งาน

```
Model output
  └─ text_delta/events
       ├─ (blockStreamingBreak=text_end)
       │    └─ chunker emits blocks as buffer grows
       └─ (blockStreamingBreak=message_end)
            └─ chunker flushes at message_end
                   └─ channel send (block replies)
```

คำอธิบาย:

- `text_delta/events`: เหตุการณ์สตรีมของโมเดล (อาจเบาบางสำหรับโมเดลที่ไม่ใช่แบบสตรีม)
- `chunker`: `EmbeddedBlockChunker` ที่ใช้ขอบเขตต่ำสุด/สูงสุด + ค่ากำหนดจุดแบ่ง
- `channel send`: ข้อความขาออกจริง (การตอบกลับแบบบล็อก)

**ตัวควบคุม:**

- `agents.defaults.blockStreamingDefault`: `"on"`/`"off"` (ค่าเริ่มต้นคือปิด)
- การแทนที่รายช่องทาง: `*.blockStreaming` (และรูปแบบรายบัญชี) เพื่อบังคับ `"on"`/`"off"` ต่อช่องทาง
- `agents.defaults.blockStreamingBreak`: `"text_end"` หรือ `"message_end"`
- `agents.defaults.blockStreamingChunk`: `{ minChars, maxChars, breakPreference? }`
- `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (รวมบล็อกที่สตรีมก่อนส่ง)
- เพดานตายตัวของช่องทาง: `*.textChunkLimit` (เช่น `channels.whatsapp.textChunkLimit`)
- โหมดแบ่งชิ้นของช่องทาง: `*.chunkMode` (ค่าเริ่มต้น `length`, `newline` จะแบ่งตามบรรทัดว่าง (ขอบเขตย่อหน้า) ก่อนการแบ่งตามความยาว)
- เพดานแบบยืดหยุ่นของ Discord: `channels.discord.maxLinesPerMessage` (ค่าเริ่มต้น 17) แบ่งการตอบกลับที่สูงเกินไปเพื่อหลีกเลี่ยงการถูกตัดใน UI

**ความหมายของขอบเขต:**

- `text_end`: สตรีมบล็อกทันทีเมื่อ chunker ส่งออก; flush ในแต่ละ `text_end`
- `message_end`: รอจนข้อความผู้ช่วยจบ แล้วจึง flush เอาต์พุตที่บัฟเฟอร์ไว้

`message_end` ยังคงใช้ chunker หากข้อความที่บัฟเฟอร์ไว้เกิน `maxChars` ดังนั้นจึงสามารถส่งออกหลายชิ้นในตอนท้ายได้

### การส่งสื่อพร้อมการสตรีมบล็อก

สื่อที่สตรีมต้องใช้ฟิลด์เพย์โหลดแบบมีโครงสร้าง เช่น `mediaUrl` หรือ
`mediaUrls`; ข้อความที่สตรีมจะไม่ถูกแยกวิเคราะห์เป็นคำสั่งแนบไฟล์ เมื่อการสตรีมบล็อก
ส่งสื่อตั้งแต่เนิ่น ๆ OpenClaw จะจดจำการส่งนั้นสำหรับรอบสนทนานั้น หาก
เพย์โหลดสุดท้ายของผู้ช่วยทำซ้ำ URL สื่อเดียวกัน การส่งครั้งสุดท้าย
จะตัดสื่อที่ซ้ำออกแทนที่จะส่งไฟล์แนบอีกครั้ง

เพย์โหลดสุดท้ายที่ซ้ำกันทุกประการจะถูกระงับ หากเพย์โหลดสุดท้ายเพิ่ม
ข้อความที่แตกต่างรอบสื่อที่สตรีมไปแล้ว OpenClaw จะยังคงส่ง
ข้อความใหม่โดยคงให้สื่อถูกส่งเพียงครั้งเดียว วิธีนี้ป้องกันการส่งโน้ตเสียง
หรือไฟล์ซ้ำในช่องทาง เช่น Telegram

## อัลกอริทึมการแบ่งชิ้น (ขอบเขตต่ำ/สูง)

การแบ่งชิ้นบล็อกดำเนินการโดย `EmbeddedBlockChunker`:

- **ขอบเขตต่ำ:** อย่าส่งออกจนกว่าบัฟเฟอร์ >= `minChars` (เว้นแต่ถูกบังคับ)
- **ขอบเขตสูง:** เลือกแบ่งก่อน `maxChars`; หากถูกบังคับ ให้แบ่งที่ `maxChars`
- **ค่ากำหนดจุดแบ่ง:** `paragraph` → `newline` → `sentence` → `whitespace` → การแบ่งแบบแข็ง
- **รั้วโค้ด:** ไม่แบ่งภายในรั้วโค้ด; เมื่อถูกบังคับที่ `maxChars` ให้ปิด + เปิดรั้วใหม่เพื่อให้ Markdown ยังถูกต้อง

`maxChars` จะถูกจำกัดไม่ให้เกิน `textChunkLimit` ของช่องทาง ดังนั้นคุณจึงไม่สามารถเกินเพดานรายช่องทางได้

## การรวมชิ้น (รวมบล็อกที่สตรีม)

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

- การรวมชิ้นจะรอ **ช่วงว่างที่ไม่มีการทำงาน** (`idleMs`) ก่อน flush
- บัฟเฟอร์ถูกจำกัดด้วย `maxChars` และจะ flush หากเกินค่านี้
- `minChars` ป้องกันไม่ให้ส่งเศษข้อความเล็ก ๆ จนกว่าจะมีข้อความสะสมเพียงพอ
  (การ flush สุดท้ายจะส่งข้อความที่เหลือเสมอ)
- ตัวเชื่อมจะอิงจาก `blockStreamingChunk.breakPreference`
  (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → เว้นวรรค)
- มีการแทนที่รายช่องทางผ่าน `*.blockStreamingCoalesce` (รวมถึงการกำหนดค่ารายบัญชี)
- ค่าเริ่มต้นของการรวมชิ้น `minChars` ถูกเพิ่มเป็น 1500 สำหรับ Signal/Slack/Discord เว้นแต่ถูกแทนที่

## จังหวะระหว่างบล็อกแบบคล้ายมนุษย์

เมื่อเปิดใช้การสตรีมบล็อก คุณสามารถเพิ่ม **การหยุดแบบสุ่ม** ระหว่าง
การตอบกลับแบบบล็อก (หลังบล็อกแรก) ได้ วิธีนี้ทำให้การตอบกลับแบบหลายบับเบิล
รู้สึกเป็นธรรมชาติมากขึ้น

- การกำหนดค่า: `agents.defaults.humanDelay` (แทนที่ต่อเอเจนต์ผ่าน `agents.list[].humanDelay`)
- โหมด: `off` (ค่าเริ่มต้น), `natural` (800-2500ms), `custom` (`minMs`/`maxMs`)
- ใช้เฉพาะกับ **การตอบกลับแบบบล็อก** ไม่ใช่การตอบกลับสุดท้ายหรือสรุปเครื่องมือ

## "สตรีมชิ้นข้อความหรือทั้งหมด"

สิ่งนี้แมปเป็น:

- **สตรีมชิ้นข้อความ:** `blockStreamingDefault: "on"` + `blockStreamingBreak: "text_end"` (ส่งออกไปเรื่อย ๆ) ช่องทางที่ไม่ใช่ Telegram ต้องตั้ง `*.blockStreaming: true` ด้วย
- **สตรีมทั้งหมดตอนท้าย:** `blockStreamingBreak: "message_end"` (flush หนึ่งครั้ง อาจเป็นหลายชิ้นหากยาวมาก)
- **ไม่มีการสตรีมบล็อก:** `blockStreamingDefault: "off"` (เฉพาะการตอบกลับสุดท้าย)

**หมายเหตุช่องทาง:** การสตรีมบล็อกจะ **ปิด เว้นแต่**
ตั้งค่า `*.blockStreaming` เป็น `true` อย่างชัดเจน ช่องทางสามารถสตรีมตัวอย่างก่อนส่งแบบสด
(`channels.<channel>.streaming`) ได้โดยไม่มีการตอบกลับแบบบล็อก

เตือนตำแหน่งการกำหนดค่า: ค่าเริ่มต้น `blockStreaming*` อยู่ภายใต้
`agents.defaults` ไม่ใช่ config ราก

## โหมดการสตรีมตัวอย่างก่อนส่ง

คีย์แบบบัญญัติ: `channels.<channel>.streaming`

โหมด:

- `off`: ปิดการสตรีมตัวอย่างก่อนส่ง
- `partial`: ตัวอย่างก่อนส่งเดียวที่ถูกแทนที่ด้วยข้อความล่าสุด
- `block`: ตัวอย่างก่อนส่งอัปเดตเป็นขั้นตอนแบบแบ่งชิ้น/ต่อท้าย
- `progress`: ตัวอย่างก่อนส่งสถานะ/ความคืบหน้าระหว่างการสร้าง คำตอบสุดท้ายเมื่อเสร็จสิ้น

`streaming.mode: "block"` เป็นโหมดการสตรีมตัวอย่างก่อนส่งสำหรับช่องทางที่แก้ไขได้
เช่น Discord และ Telegram มันไม่ได้เปิดใช้การส่งบล็อกผ่านช่องทางนั้น
ใช้ `streaming.block.enabled` หรือคีย์ช่องทางเดิม `blockStreaming` เมื่อ
คุณต้องการการตอบกลับแบบบล็อกปกติ Microsoft Teams เป็นข้อยกเว้น: ไม่มี
ทรานสปอร์ตบล็อกแบบร่างตัวอย่างก่อนส่ง ดังนั้น `streaming.mode: "block"` จะแมปไปยังการส่งบล็อกของ Teams
แทนการสตรีมบางส่วน/ความคืบหน้าแบบเนทีฟ

### การแมปช่องทาง

| ช่องทาง    | `off` | `partial` | `block` | `progress`              |
| ---------- | ----- | --------- | ------- | ----------------------- |
| Telegram   | ✅    | ✅        | ✅      | แบบร่างความคืบหน้าที่แก้ไขได้ |
| Discord    | ✅    | ✅        | ✅      | แบบร่างความคืบหน้าที่แก้ไขได้ |
| Slack      | ✅    | ✅        | ✅      | ✅                      |
| Mattermost | ✅    | ✅        | ✅      | ✅                      |
| MS Teams   | ✅    | ✅        | ✅      | สตรีมความคืบหน้าแบบเนทีฟ  |

เฉพาะ Slack:

- `channels.slack.streaming.nativeTransport` สลับการเรียก API สตรีมมิงแบบเนทีฟของ Slack เมื่อ `channels.slack.streaming.mode="partial"` (ค่าเริ่มต้น: `true`)
- การสตรีมแบบเนทีฟของ Slack และสถานะเธรดผู้ช่วยของ Slack ต้องมีเป้าหมายเธรดตอบกลับ DM ระดับบนสุดไม่แสดงตัวอย่างก่อนส่งแบบเธรดนั้น แต่ยังสามารถใช้โพสต์ตัวอย่างก่อนส่งแบบร่างของ Slack และการแก้ไขได้

การย้ายคีย์เดิม:

- Telegram: ค่าเดิม `streamMode` และค่า `streaming` แบบสเกลาร์/บูลีนจะถูกตรวจพบและย้ายโดยเส้นทางความเข้ากันได้ของ doctor/config ไปยัง `streaming.mode`
- Discord: `streamMode` + `streaming` แบบบูลีนยังคงเป็นนามแฝง runtime สำหรับ enum `streaming`; รัน `openclaw doctor --fix` เพื่อเขียน config ที่บันทึกไว้ใหม่
- Slack: `streamMode` ยังคงเป็นนามแฝง runtime สำหรับ `streaming.mode`; `streaming` แบบบูลีนยังคงเป็นนามแฝง runtime สำหรับ `streaming.mode` รวมถึง `streaming.nativeTransport`; `nativeStreaming` เดิมยังคงเป็นนามแฝง runtime สำหรับ `streaming.nativeTransport` รัน `openclaw doctor --fix` เพื่อเขียน config ที่บันทึกไว้ใหม่

### พฤติกรรม runtime

Telegram:

- ใช้ `sendMessage` + `editMessageText` สำหรับการอัปเดตตัวอย่างก่อนส่งทั้งใน DM และกลุ่ม/หัวข้อ
- ตัวอย่างก่อนส่งเริ่มต้นสั้น ๆ ยังคงถูก debounce เพื่อ UX การแจ้งเตือนแบบพุช แต่ตอนนี้ Telegram จะทำให้มองเห็นได้หลังจากดีเลย์ที่มีขอบเขต เพื่อให้รันที่กำลังทำงานอยู่ไม่เงียบทางภาพ
- ข้อความสุดท้ายจะแก้ไขตัวอย่างก่อนส่งที่ใช้งานอยู่แทนที่; ข้อความสุดท้ายที่ยาวจะใช้ข้อความนั้นซ้ำสำหรับชิ้นแรก และส่งเฉพาะชิ้นที่เหลือ
- โหมด `block` จะหมุนตัวอย่างก่อนส่งเป็นข้อความใหม่ที่ `streaming.preview.chunk.maxChars` (ค่าเริ่มต้น 800, จำกัดด้วยขีดจำกัดการแก้ไข 4096 ของ Telegram); โหมดอื่น ๆ จะขยายตัวอย่างก่อนส่งหนึ่งรายการได้สูงสุด 4096 อักขระ
- โหมด `progress` จะเก็บความคืบหน้าของเครื่องมือไว้ในแบบร่างสถานะที่แก้ไขได้ ทำให้ป้ายสถานะมองเห็นได้เมื่อการสตรีมคำตอบทำงานอยู่แต่ยังไม่มีบรรทัดเครื่องมือ ล้างแบบร่างนั้นเมื่อเสร็จสิ้น และส่งคำตอบสุดท้ายผ่านการส่งปกติ
- หากการแก้ไขสุดท้ายล้มเหลวก่อนยืนยันข้อความที่เสร็จสมบูรณ์ OpenClaw จะใช้การส่งคำตอบสุดท้ายแบบปกติและล้างตัวอย่างก่อนส่งที่ค้างอยู่
- การสตรีมตัวอย่างก่อนส่งจะถูกข้ามเมื่อเปิดใช้การสตรีมบล็อกของ Telegram อย่างชัดเจน (เพื่อหลีกเลี่ยงการสตรีมซ้ำ)
- `/reasoning stream` สามารถเขียนเหตุผลไปยังตัวอย่างก่อนส่งชั่วคราวที่จะถูกลบหลังการส่งสุดท้าย

Discord:

- ใช้การส่ง + แก้ไขข้อความตัวอย่างก่อนส่ง
- โหมด `block` ใช้การแบ่งชิ้นแบบร่าง (`draftChunk`)
- การสตรีมตัวอย่างก่อนส่งจะถูกข้ามเมื่อเปิดใช้การสตรีมบล็อกของ Discord อย่างชัดเจน
- สื่อสุดท้าย ข้อผิดพลาด และเพย์โหลดตอบกลับแบบชัดเจนจะยกเลิกตัวอย่างก่อนส่งที่รออยู่โดยไม่ flush แบบร่างใหม่ จากนั้นใช้การส่งปกติ

Slack:

- `partial` สามารถใช้การสตรีมแบบเนทีฟของ Slack (`chat.startStream`/`append`/`stop`) เมื่อพร้อมใช้งาน
- `block` ใช้ตัวอย่างก่อนส่งแบบร่างลักษณะต่อท้าย
- `progress` ใช้ข้อความตัวอย่างก่อนส่งสถานะ แล้วจึงเป็นคำตอบสุดท้าย
- DM ระดับบนสุดที่ไม่มีเธรดตอบกลับจะใช้โพสต์ตัวอย่างก่อนส่งแบบร่างและการแก้ไขแทนการสตรีมแบบเนทีฟของ Slack
- การสตรีมตัวอย่างก่อนส่งทั้งแบบเนทีฟและแบบร่างจะระงับการตอบกลับแบบบล็อกสำหรับรอบสนทนานั้น ดังนั้นการตอบกลับของ Slack จะถูกสตรีมผ่านเส้นทางการส่งเพียงเส้นทางเดียว
- เพย์โหลดสื่อ/ข้อผิดพลาดสุดท้ายและผลลัพธ์สุดท้ายของความคืบหน้าจะไม่สร้างข้อความแบบร่างชั่วคราว; เฉพาะผลลัพธ์สุดท้ายแบบข้อความ/บล็อกที่แก้ไขตัวอย่างก่อนส่งได้เท่านั้นที่จะ flush ข้อความแบบร่างที่รออยู่

Mattermost:

- สตรีมการคิด กิจกรรมเครื่องมือ และข้อความตอบกลับบางส่วนเข้าไปในโพสต์ตัวอย่างก่อนส่งแบบร่างเดียว ซึ่งจะ finalizes แทนที่เมื่อส่งคำตอบสุดท้ายได้อย่างปลอดภัย
- ถอยกลับไปส่งโพสต์สุดท้ายใหม่หากโพสต์ตัวอย่างก่อนส่งถูกลบหรือไม่พร้อมใช้งานเมื่อถึงเวลาจบ
- เพย์โหลดสื่อ/ข้อผิดพลาดสุดท้ายจะยกเลิกการอัปเดตตัวอย่างก่อนส่งที่รออยู่ก่อนการส่งปกติ แทนที่จะ flush โพสต์ตัวอย่างก่อนส่งชั่วคราว

Matrix:

- ตัวอย่างก่อนส่งแบบร่างจะ finalizes แทนที่เมื่อข้อความสุดท้ายสามารถใช้เหตุการณ์ตัวอย่างก่อนส่งซ้ำได้
- ผลลัพธ์สุดท้ายแบบมีสื่ออย่างเดียว ข้อผิดพลาด และเป้าหมายตอบกลับไม่ตรงกันจะยกเลิกการอัปเดตตัวอย่างก่อนส่งที่รออยู่ก่อนการส่งปกติ; ตัวอย่างก่อนส่งที่ค้างซึ่งมองเห็นแล้วจะถูก redact

### การอัปเดตตัวอย่างก่อนส่งความคืบหน้าเครื่องมือ

การสตรีมตัวอย่างก่อนส่งยังสามารถรวมการอัปเดต **ความคืบหน้าเครื่องมือ** ได้ด้วย - บรรทัดสถานะสั้น ๆ เช่น "กำลังค้นหาเว็บ", "กำลังอ่านไฟล์" หรือ "กำลังเรียกเครื่องมือ" - ซึ่งปรากฏในข้อความตัวอย่างก่อนส่งเดียวกันขณะที่เครื่องมือกำลังทำงาน ก่อนการตอบกลับสุดท้าย ในโหมดเซิร์ฟเวอร์แอป Codex ข้อความ preamble/commentary ของ Codex ใช้เส้นทางตัวอย่างก่อนส่งเดียวกันนี้ ดังนั้นโน้ตความคืบหน้าสั้น ๆ อย่าง "กำลังตรวจสอบ..." สามารถสตรีมเข้าสู่แบบร่างที่แก้ไขได้โดยไม่กลายเป็นส่วนหนึ่งของคำตอบสุดท้าย วิธีนี้ทำให้รอบสนทนาเครื่องมือหลายขั้นตอนมีความเคลื่อนไหวทางภาพ แทนที่จะเงียบระหว่างตัวอย่างก่อนส่งการคิดครั้งแรกและคำตอบสุดท้าย

เครื่องมือที่ทำงานนานอาจส่งความคืบหน้าแบบ typed ก่อนคืนค่า ตัวอย่างเช่น
`web_fetch` จะตั้งตัวจับเวลาห้าวินาทีเมื่อเริ่มทำงาน: หากการ fetch ยัง
รออยู่ ตัวอย่างก่อนส่งสามารถแสดง `Fetching page content...`; หากการ fetch เสร็จ
หรือถูกยกเลิกก่อนหน้านั้น จะไม่มีการส่งบรรทัดความคืบหน้า ผลลัพธ์เครื่องมือสุดท้ายในภายหลัง
ยังคงถูกส่งไปยังโมเดลตามปกติ

พื้นผิวที่รองรับ:

- **Discord**, **Slack**, **Telegram** และ **Matrix** จะสตรีมความคืบหน้าของเครื่องมือและการอัปเดตคำนำของ Codex เข้าไปในการแก้ไขตัวอย่างสดตามค่าเริ่มต้นเมื่อการสตรีมตัวอย่างทำงานอยู่ Microsoft Teams ใช้สตรีมความคืบหน้าแบบเนทีฟในแชทส่วนตัว
- Telegram เปิดใช้การอัปเดตตัวอย่างความคืบหน้าของเครื่องมือมาตั้งแต่ `v2026.4.22`; การเปิดใช้ต่อไปจะรักษาพฤติกรรมที่เผยแพร่แล้วนั้นไว้
- **Mattermost** รวมกิจกรรมของเครื่องมือไว้ในโพสต์ตัวอย่างแบบร่างเดียวของตัวเองอยู่แล้ว (ดูด้านบน)
- การแก้ไขความคืบหน้าของเครื่องมือจะตามโหมดการสตรีมตัวอย่างที่ใช้งานอยู่; จะถูกข้ามเมื่อการสตรีมตัวอย่างเป็น `off` หรือเมื่อการสตรีมแบบบล็อกเข้าควบคุมข้อความแล้ว บน Telegram, `streaming.mode: "off"` เป็นแบบผลลัพธ์สุดท้ายเท่านั้น: ข้อความความคืบหน้าทั่วไปจะถูกระงับด้วย แทนที่จะส่งเป็นข้อความสถานะแยกต่างหาก ขณะที่พรอมป์อนุมัติ เพย์โหลดสื่อ และข้อผิดพลาดยังคงถูกส่งตามเส้นทางปกติ
- หากต้องการคงการสตรีมตัวอย่างไว้แต่ซ่อนบรรทัดความคืบหน้าของเครื่องมือ ให้ตั้งค่า `streaming.preview.toolProgress` เป็น `false` สำหรับช่องทางนั้น หากต้องการให้บรรทัดความคืบหน้าของเครื่องมือยังมองเห็นได้แต่ซ่อนข้อความคำสั่ง/การรัน ให้ตั้งค่า `streaming.preview.commandText` เป็น `"status"` หรือ `streaming.progress.commandText` เป็น `"status"`; ค่าเริ่มต้นคือ `"raw"` เพื่อรักษาพฤติกรรมที่เผยแพร่แล้ว นโยบายนี้ใช้ร่วมกันโดยช่องทางแบบร่าง/ความคืบหน้าที่ใช้ตัวเรนเดอร์ความคืบหน้าแบบกะทัดรัดของ OpenClaw รวมถึง Discord, Matrix, Microsoft Teams, Mattermost, ตัวอย่างแบบร่างของ Slack และ Telegram หากต้องการปิดการแก้ไขตัวอย่างทั้งหมด ให้ตั้งค่า `streaming.mode` เป็น `off`
- การตอบกลับคำพูดที่เลือกบน Telegram เป็นข้อยกเว้น: เมื่อ `replyToMode` ไม่ใช่ `"off"` และมีข้อความคำพูดที่เลือกอยู่ OpenClaw จะข้ามสตรีมตัวอย่างคำตอบสำหรับรอบนั้น เพื่อไม่ให้บรรทัดตัวอย่างความคืบหน้าของเครื่องมือเรนเดอร์ได้ การตอบกลับข้อความปัจจุบันที่ไม่มีข้อความคำพูดที่เลือกยังคงใช้การสตรีมตัวอย่างต่อไป ดูรายละเอียดใน [เอกสารช่องทาง Telegram](/th/channels/telegram)

คงบรรทัดความคืบหน้าให้มองเห็นได้ แต่ซ่อนข้อความคำสั่ง/การรันแบบดิบ:

```json
{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "partial",
        "preview": {
          "toolProgress": true,
          "commandText": "status"
        }
      }
    }
  }
}
```

ใช้รูปแบบเดียวกันภายใต้คีย์ช่องทางความคืบหน้าแบบกะทัดรัดอื่น เช่น `channels.discord`, `channels.matrix`, `channels.msteams`, `channels.mattermost` หรือตัวอย่างแบบร่างของ Slack สำหรับโหมดแบบร่างความคืบหน้า ให้ใส่นโยบายเดียวกันไว้ใต้ `streaming.progress`:

```json
{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "progress",
        "progress": {
          "toolProgress": true,
          "commandText": "status"
        }
      }
    }
  }
}
```

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

- [การปรับโครงสร้างวงจรชีวิตข้อความ](/th/concepts/message-lifecycle-refactor) - การออกแบบเป้าหมายที่ใช้ร่วมกันสำหรับตัวอย่าง การแก้ไข สตรีม และการสรุปผล
- [แบบร่างความคืบหน้า](/th/concepts/progress-drafts) - ข้อความงานที่กำลังดำเนินการซึ่งมองเห็นได้และอัปเดตระหว่างรอบที่ใช้เวลานาน
- [ข้อความ](/th/concepts/messages) - วงจรชีวิตและการส่งข้อความ
- [ลองใหม่](/th/concepts/retry) - พฤติกรรมการลองใหม่เมื่อส่งไม่สำเร็จ
- [ช่องทาง](/th/channels) - การรองรับการสตรีมรายช่องทาง