Messages and delivery

ข้อความ

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

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

Code

ข้อความขาเข้า  -> 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.* เป็นต้น) สำหรับเพดานและตัวเปิด/ปิดการสตรีม

ดู การกำหนดค่า สำหรับสคีมาแบบเต็ม

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

ช่องทางอาจส่งข้อความเดิมซ้ำหลังจากเชื่อมต่อใหม่ 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 หนุนหลังเสมอ จึงเป็นแหล่งข้อมูลจริง

รายละเอียด: การจัดการเซสชัน

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

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

รายละเอียด: คิวคำสั่ง และ คิวการ steer

ความเป็นเจ้าของ 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 อย่างชัดเจน)

รายละเอียด: การสตรีม + การแบ่งชิ้น

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

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

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

รายละเอียด: directive การคิด + การให้เหตุผล และ การใช้โทเค็น

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

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

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

รายละเอียด: การกำหนดค่า และเอกสารช่องทาง

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

โทเค็นเงียบที่ตรงกันทุกประการ 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 ข้อความ - เป้าหมายการออกแบบการส่งและรับที่ทนทาน
การสตรีม — การส่งข้อความแบบเรียลไทม์
Retry — พฤติกรรมการ retry การส่งข้อความ
คิว — คิวการประมวลผลข้อความ
ช่องทาง — การผสานรวมแพลตฟอร์มรับส่งข้อความ

Was this useful?