Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

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

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

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.* ฯลฯ) สำหรับเพดานจำกัดและสวิตช์การสตรีม
ดูสคีมาฉบับเต็มได้ที่ การกำหนดค่า

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

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

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

ข้อความที่ส่งต่อเนื่องอย่างรวดเร็วจาก ผู้ส่งคนเดียวกัน สามารถถูกรวมเป็นเทิร์นเอเจนต์เดียวได้ผ่าน messages.inbound การ debounce มีขอบเขตต่อช่องทาง + บทสนทนา และใช้ข้อความล่าสุดสำหรับ threading/ID ของการตอบกลับ การกำหนดค่า (ค่าเริ่มต้นส่วนกลาง + การแทนที่รายช่องทาง): 
{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}
หมายเหตุ:
  • Debounce ใช้กับข้อความ ข้อความล้วน เท่านั้น สื่อ/ไฟล์แนบจะ flush ทันที
  • คำสั่งควบคุมจะข้ามการ debounce เพื่อให้ยังคงเป็นรายการเดี่ยว ช่องทางที่เลือกใช้การรวม DM จากผู้ส่งเดียวกันอย่างชัดเจนสามารถเก็บคำสั่ง DM ไว้ในช่วง debounce ได้ เพื่อให้ payload ที่ถูกแยกส่งเข้าร่วมเทิร์นเอเจนต์เดียวกันได้

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

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

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

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

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

OpenClaw แยก เนื้อความพรอมป์ ออกจาก เนื้อความคำสั่ง:
  • BodyForAgent: ข้อความหลักที่ส่งให้โมเดลสำหรับข้อความปัจจุบัน Plugin ช่องทางควรรักษาส่วนนี้ให้โฟกัสที่ข้อความปัจจุบันของผู้ส่งซึ่งมีพรอมป์อยู่
  • Body: fallback พรอมป์แบบเดิม ส่วนนี้อาจมีซองห่อของช่องทางและ wrapper ประวัติที่เลือกใช้ได้ แต่ช่องทางปัจจุบันไม่ควรพึ่งพาส่วนนี้เป็นอินพุตหลักของโมเดลเมื่อมี BodyForAgent
  • CommandBody: ข้อความผู้ใช้ดิบสำหรับการแยกวิเคราะห์ directive/คำสั่ง
  • RawBody: alias แบบเดิมของ CommandBody (เก็บไว้เพื่อความเข้ากันได้)
เมื่อช่องทางส่งประวัติมา จะใช้ wrapper ร่วมกัน:
  • [Chat messages since your last reply - for context]
  • [Current message - respond to this]
สำหรับ แชทที่ไม่ใช่แชทโดยตรง (กลุ่ม/ช่องทาง/ห้อง) เนื้อความข้อความปัจจุบัน จะมีป้ายชื่อผู้ส่งนำหน้า (รูปแบบเดียวกับที่ใช้กับรายการประวัติ) สิ่งนี้ทำให้ข้อความแบบเรียลไทม์และข้อความที่อยู่ในคิว/ประวัติสอดคล้องกันในพรอมป์ของเอเจนต์ บัฟเฟอร์ประวัติเป็นแบบ pending-only: จะรวมข้อความกลุ่มที่ ไม่ได้ ทริกเกอร์การรัน (เช่น ข้อความที่ถูกกั้นด้วยการ mention) และ ไม่รวม ข้อความที่อยู่ในทรานสคริปต์เซสชันแล้ว การตัด directive ออกจะใช้กับส่วน ข้อความปัจจุบัน เท่านั้น เพื่อให้ประวัติยังคงครบถ้วน ช่องทางที่ห่อประวัติควรตั้ง CommandBody (หรือ RawBody) เป็นข้อความต้นฉบับ และเก็บ Body เป็นพรอมป์ที่รวมแล้ว ประวัติแบบมีโครงสร้าง การตอบกลับ ข้อความที่ส่งต่อ และเมตาดาตาช่องทางจะถูกเรนเดอร์เป็นบล็อกบริบทที่ไม่น่าเชื่อถือในบทบาทผู้ใช้ระหว่างการประกอบพรอมป์ บัฟเฟอร์ประวัติกำหนดค่าได้ผ่าน messages.groupChat.historyLimit (ค่าเริ่มต้นส่วนกลาง) และการแทนที่รายช่องทาง เช่น channels.slack.historyLimit หรือ channels.telegram.accounts.<id>.historyLimit (ตั้งเป็น 0 เพื่อปิดใช้งาน)

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

หากมีการรันที่กำลังทำงานอยู่แล้ว ข้อความขาเข้าสามารถถูกเข้าคิว ชี้นำเข้าในการรันปัจจุบัน หรือรวบรวมไว้สำหรับเทิร์น followup ได้
  • กำหนดค่าผ่าน messages.queue (และ messages.queue.byChannel)
  • โหมดเริ่มต้นคือ steer พร้อม debounce followup 500ms เมื่อการชี้นำ fallback ไปเป็นการส่ง followup ที่เข้าคิว
  • โหมด: steer, followup, collect, steer-backlog, interrupt และโหมดเดิม queue ที่ทำทีละรายการ
รายละเอียด: คิวคำสั่ง และ คิวการชี้นำ

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

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

​
การสตรีม การแบ่งชิ้นข้อความ และการ batching

การสตรีมแบบบล็อกจะส่งการตอบกลับบางส่วนขณะที่โมเดลสร้างบล็อกข้อความ การแบ่งชิ้นข้อความเคารพขีดจำกัดข้อความของช่องทางและหลีกเลี่ยงการตัด fenced code การตั้งค่าหลัก:
  • agents.defaults.blockStreamingDefault (on|off, ค่าเริ่มต้นปิดอยู่)
  • agents.defaults.blockStreamingBreak (text_end|message_end)
  • agents.defaults.blockStreamingChunk (minChars|maxChars|breakPreference)
  • agents.defaults.blockStreamingCoalesce (การ batching ตามช่วงว่าง)
  • agents.defaults.humanDelay (การหยุดพักคล้ายมนุษย์ระหว่างการตอบกลับแบบบล็อก)
  • การแทนที่ตามช่องทาง: *.blockStreaming และ *.blockStreamingCoalesce (ช่องทางที่ไม่ใช่ Telegram ต้องมี *.blockStreaming: true อย่างชัดเจน)
รายละเอียด: การสตรีม + การแบ่งชิ้นข้อความ

​
การมองเห็น reasoning และโทเค็น

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

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

การจัดรูปแบบข้อความขาออกถูกรวมศูนย์ไว้ใน messages:
  • messages.responsePrefix, channels.<channel>.responsePrefix และ channels.<channel>.accounts.<id>.responsePrefix (ลำดับ cascade ของคำนำหน้าขาออก) รวมถึง channels.whatsapp.messagePrefix (คำนำหน้าขาเข้าของ WhatsApp)
  • Reply threading ผ่าน replyToMode และค่าเริ่มต้นรายช่องทาง
รายละเอียด: การกำหนดค่า และเอกสารช่องทาง

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

โทเค็นเงียบที่ตรงตัว NO_REPLY / no_reply หมายถึง “อย่าส่งการตอบกลับที่ผู้ใช้มองเห็นได้” เมื่อเทิร์นหนึ่งยังมีสื่อเครื่องมือที่รออยู่ เช่น เสียง TTS ที่สร้างขึ้น OpenClaw จะตัดข้อความเงียบออกแต่ยังส่งไฟล์แนบสื่อนั้น OpenClaw แก้พฤติกรรมนั้นตามประเภทบทสนทนา:
  • บทสนทนาโดยตรงไม่อนุญาตความเงียบโดยค่าเริ่มต้น และเขียนการตอบกลับเงียบล้วนใหม่เป็น fallback สั้น ๆ ที่มองเห็นได้
  • กลุ่ม/ช่องทางอนุญาตความเงียบโดยค่าเริ่มต้น
  • การประสานงานภายในอนุญาตความเงียบโดยค่าเริ่มต้น
OpenClaw ยังใช้การตอบกลับแบบเงียบสำหรับความล้มเหลวของ runner ภายในที่เกิดขึ้นก่อนมีการตอบกลับจาก assistant ในแชทที่ไม่ใช่แชทโดยตรง เพื่อให้กลุ่ม/ช่องทางไม่เห็นข้อความสำเร็จรูปข้อผิดพลาดของ Gateway แชทโดยตรงจะแสดงข้อความล้มเหลวแบบกะทัดรัดโดยค่าเริ่มต้น รายละเอียด runner ดิบจะแสดงเฉพาะเมื่อ /verbose เป็น on หรือ full ค่าเริ่มต้นอยู่ภายใต้ agents.defaults.silentReply และ agents.defaults.silentReplyRewrite; surfaces.<id>.silentReply และ surfaces.<id>.silentReplyRewrite สามารถแทนที่เป็นราย surface ได้ เมื่อเซสชันแม่มีการรัน subagent ที่ spawn แล้วและรอดำเนินการอย่างน้อยหนึ่งรายการ การตอบกลับเงียบล้วนจะถูกทิ้งในทุก surface แทนที่จะถูกเขียนใหม่ เพื่อให้เซสชันแม่เงียบอยู่จนกว่าเหตุการณ์เสร็จสิ้นของ child จะส่งการตอบกลับจริง

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