ข้อความ

ข้อความขาเข้าจะผ่านการกำหนดเส้นทาง การขจัดข้อความซ้ำ/การหน่วงรวมข้อความ การรันเอเจนต์ และการส่งขาออก:

ข้อความขาเข้า  -> การกำหนดเส้นทาง/การผูก -> คีย์เซสชัน  -> ขจัดข้อความซ้ำ + หน่วงรวมข้อความ  -> คิว (หากมีการรันที่กำลังทำงานอยู่แล้ว)  -> การรันเอเจนต์ (สตรีมมิง + เครื่องมือ)  -> การตอบกลับขาออก (ขีดจำกัดของช่องทาง + การแบ่งส่วน)

พื้นผิวการกำหนดค่าหลัก:

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

ดูสคีมาทั้งหมดที่ การกำหนดค่า

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

ช่องทางอาจส่งข้อความเดิมซ้ำหลังจากเชื่อมต่อใหม่ OpenClaw เก็บแคชในหน่วยความจำโดยใช้ขอบเขตเอเจนต์ เส้นทางช่องทาง (ช่องทาง + คู่สนทนา + บัญชี + เธรด) และรหัสข้อความเป็นคีย์ เพื่อไม่ให้ข้อความที่ส่งซ้ำเรียกใช้การรันเอเจนต์ครั้งที่สอง รายการแคชจะหมดอายุหลังจาก 20 นาทีหรือเมื่อมีการติดตามครบ 5000 รายการ แล้วแต่ว่าเงื่อนไขใดเกิดขึ้นก่อน

การหน่วงรวมข้อความขาเข้า

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

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

• การหน่วงรวมข้อความใช้กับข้อความตัวอักษรเท่านั้น ส่วนสื่อ/ไฟล์แนบจะถูกส่งต่อทันที
• คำสั่งควบคุม (หยุด/ยกเลิก/สถานะ เป็นต้น) จะข้ามการหน่วงรวมข้อความเพื่อให้ส่งต่อทันที
• ปิดใช้งานโดยค่าเริ่มต้น: messages.inbound.debounceMs ไม่มีค่าเริ่มต้นในตัว ดังนั้นการหน่วงรวมข้อความจะเปิดใช้งานเมื่อกำหนดค่าแล้วเท่านั้น (แบบส่วนกลางหรือรายช่องทาง)
• การเลือกใช้ coalesceSameSenderDms ของ iMessage เป็นข้อยกเว้นเพียงกรณีเดียว โดยจะพักข้อความ DM ทั้งหมดจากผู้ส่งคนเดียวกัน (รวมคำสั่ง) ไว้นานพอให้การส่งคำสั่ง+URL แบบแยกข้อความของ Apple มาถึงเป็นหนึ่งเทิร์น แชตกลุ่มจะส่งต่อทันทีเสมอโดยไม่ขึ้นกับการตั้งค่านี้

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

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

• แชตโดยตรงจะรวมไว้ในคีย์เซสชันหลักของเอเจนต์
• กลุ่ม/ช่องทางจะมีคีย์เซสชันของตนเอง
• ที่เก็บเซสชันและบันทึกบทสนทนาอยู่บนโฮสต์ Gateway

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

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

เนื้อหาพรอมต์และบริบทประวัติ

Plugin ของช่องทางจะเติมฟิลด์ข้อความหลายรายการในบริบทขาเข้า โดยเรียงจากที่ควรใช้มากที่สุดไปน้อยที่สุด:

เมื่อช่องทางส่งประวัติมาด้วย ระบบจะครอบประวัติด้วย:

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

สำหรับแชตที่ไม่ใช่แชตโดยตรง (กลุ่ม/ช่องทาง/ห้อง) เนื้อหาข้อความปัจจุบันจะมีป้ายชื่อผู้ส่งนำหน้า โดยใช้รูปแบบเดียวกับรายการประวัติ การตัดไดเรกทีฟจะใช้กับส่วนข้อความปัจจุบันเท่านั้น เพื่อให้ประวัติยังคงสมบูรณ์ ช่องทางที่ครอบประวัติควรกำหนด BodyForCommands (หรือ CommandBody / RawBody แบบเดิม) เป็นข้อความต้นฉบับ และเก็บ Body เป็นพรอมต์ที่รวมแล้ว

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

กำหนดขนาดประวัติด้วย messages.groupChat.historyLimit (ค่าเริ่มต้นส่วนกลาง) หรือการกำหนดค่าแทนที่รายช่องทาง เช่น channels.slack.historyLimit และ channels.telegram.accounts.<id>.historyLimit (กำหนด 0 เพื่อปิดใช้งาน)

ข้อมูลเมตาของผลลัพธ์เครื่องมือ

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

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

การเข้าคิวและข้อความติดตาม

เมื่อมีการรันที่กำลังทำงานอยู่แล้ว ข้อความขาเข้าจะถูกนำไปชี้นำการรันนั้นโดยค่าเริ่มต้น messages.queue ควบคุมโหมด:

คิวใช้การหน่วงรวมข้อความในตัว 500ms สำหรับการชี้นำ ข้อความติดตาม และการรวมชุด messages.queue.cap มีค่าเริ่มต้นเป็นข้อความในคิว 20 รายการ และ messages.queue.drop มีค่าเริ่มต้นเป็น summarize (มี old และ new ให้ใช้ด้วย) กำหนดค่าแทนที่รายช่องทางผ่าน messages.queue.byChannel และ messages.queue.debounceMsByChannel

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

การเป็นเจ้าของการรันของช่องทาง

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

การสตรีม การแบ่งส่วน และการรวมชุด

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

• agents.defaults.blockStreamingDefault (on|off, ค่าเริ่มต้น off)
• agents.defaults.blockStreamingBreak (text_end|message_end)
• agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
• agents.defaults.blockStreamingCoalesce (การรวมชุดตามช่วงที่ไม่มีการใช้งาน)
• agents.defaults.humanDelay (ช่วงพักคล้ายมนุษย์ระหว่างการตอบกลับแบบบล็อก)
• การกำหนดค่าแทนที่ของช่องทาง: *.streaming.block.enabled และ *.streaming.block.coalesce ในช่องทางที่รวมมาให้ คีย์แบบแบนที่ล้าสมัยจะถูกย้ายโดย openclaw doctor --fix การสตรีมแบบบล็อกจะปิดอยู่ เว้นแต่เปิดใช้งานอย่างชัดเจนในทุกช่องทาง รวมถึง Telegram ข้อยกเว้นคือ QQ Bot ซึ่งไม่มีคีย์ streaming.block และจะสตรีมการตอบกลับแบบบล็อก เว้นแต่ channels.qqbot.streaming.mode เป็น "off"

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

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

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

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

คำนำหน้า เธรด และการตอบกลับ

• ลำดับการใช้คำนำหน้าขาออก: messages.responsePrefix, channels.<channel>.responsePrefix, channels.<channel>.accounts.<id>.responsePrefix นอกจากนี้ WhatsApp ยังมี channels.whatsapp.messagePrefix สำหรับคำนำหน้าขาเข้า
• การทำเธรดการตอบกลับผ่าน replyToMode และค่าเริ่มต้นรายช่องทาง

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

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

โทเค็นแบบเงียบ NO_REPLY (ไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ ดังนั้น no_reply จึงตรงกันด้วย) หมายถึง "ไม่ส่งการตอบกลับที่ผู้ใช้มองเห็น" เมื่อเทิร์นหนึ่งมีสื่อจากเครื่องมือที่รอส่งอยู่ด้วย เช่น เสียง TTS ที่สร้างขึ้น OpenClaw จะตัดข้อความแบบเงียบออก แต่ยังคงส่งไฟล์แนบสื่อ

นโยบายความเงียบจะพิจารณาตามประเภทการสนทนา:

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

ค่าเริ่มต้นอยู่ภายใต้ agents.defaults.silentReply โดย surfaces.<id>.silentReply สามารถกำหนดนโยบายกลุ่ม/ภายในแทนเป็นรายพื้นผิวได้

OpenClaw ยังใช้การตอบกลับแบบเงียบสำหรับความล้มเหลวทั่วไปของตัวรันภายในแชตที่ไม่ใช่แชตโดยตรง เพื่อไม่ให้กลุ่ม/ช่องทางเห็นข้อความข้อผิดพลาดมาตรฐานของ Gateway ความล้มเหลวที่จัดประเภทแล้วและมีข้อความแนะนำการกู้คืนสำหรับผู้ใช้ เช่น การแจ้งว่าไม่มีการยืนยันตัวตน ถึงขีดจำกัดอัตรา หรือระบบทำงานหนักเกินไป ยังคงส่งได้ แชตโดยตรงจะแสดงข้อความความล้มเหลวแบบย่อโดยค่าเริ่มต้น ส่วนรายละเอียดดิบของตัวรันจะแสดงเมื่อเปิดใช้งาน /verbose full เท่านั้น

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

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

• การปรับโครงสร้างวงจรชีวิตข้อความ - การออกแบบเป้าหมายสำหรับการส่งและรับที่คงทน
• การสตรีม - การส่งข้อความแบบเรียลไทม์
• การลองใหม่ - พฤติกรรมการลองส่งข้อความใหม่
• คิว - คิวประมวลผลข้อความ
• ช่องทาง - การผสานรวมแพลตฟอร์มรับส่งข้อความ