คิวการกำกับทิศทาง

เมื่อมีข้อความเข้ามาขณะที่การรันเซสชันกำลังสตรีมอยู่ OpenClaw สามารถ ส่งข้อความนั้นเข้าไปในรันไทม์ที่ใช้งานอยู่ แทนที่จะเริ่มการรันใหม่อีกครั้งสำหรับ เซสชันเดียวกัน โหมดสาธารณะเป็นกลางต่อรันไทม์ ส่วน Pi และฮาร์เนส app-server ดั้งเดิมของ Codex ใช้รายละเอียดการส่งมอบที่ต่างกัน

# ขอบเขตรันไทม์

การสั่งทิศทางจะไม่ขัดจังหวะ tool call ที่กำลังทำงานอยู่ Pi จะตรวจสอบ ข้อความสั่งทิศทางที่รอคิวอยู่ที่ขอบเขตของโมเดล:

1. ผู้ช่วยขอ tool calls
2. Pi เรียกใช้ชุด tool-call ของข้อความผู้ช่วยปัจจุบัน
3. Pi ส่งเหตุการณ์สิ้นสุดเทิร์น
4. Pi ระบายข้อความสั่งทิศทางที่รอคิว
5. Pi ผนวกข้อความเหล่านั้นเป็นข้อความของผู้ใช้ก่อนการเรียก LLM ถัดไป

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

ฮาร์เนส app-server ดั้งเดิมของ Codex เปิดเผย turn/steer แทนคิวสั่งทิศทาง ภายในของ Pi OpenClaw ปรับใช้โหมดเดียวกันที่นั่น:

• steer รวมข้อความที่รอคิวไว้เป็นชุดตามช่วงเวลานิ่งที่กำหนดค่าไว้ จากนั้นส่ง คำขอ turn/steer เดียวพร้อมอินพุตผู้ใช้ทั้งหมดที่รวบรวมมาเรียงตามลำดับที่มาถึง
• queue คงรูปแบบที่เรียงลำดับแบบเดิมไว้ โดยส่งคำขอ turn/steer แยกกัน
• followup, collect, steer-backlog, และ interrupt ยังคงเป็น พฤติกรรมคิวที่ OpenClaw เป็นเจ้าของรอบเทิร์น Codex ที่ใช้งานอยู่

เทิร์นรีวิวของ Codex และเทิร์น Compaction แบบแมนนวลจะปฏิเสธการสั่งทิศทางในเทิร์นเดียวกัน เมื่อรันไทม์ไม่สามารถรับการสั่งทิศทางได้ OpenClaw จะถอยกลับไปใช้คิว followup ในกรณีที่โหมดนั้นอนุญาต

หน้านี้อธิบายการสั่งทิศทางในโหมดคิวสำหรับข้อความขาเข้าปกติ สำหรับคำสั่ง /steer <message> แบบชัดเจน โปรดดู สั่งทิศทาง

# โหมด

โหมด	พฤติกรรมเมื่อมีการรันที่ใช้งานอยู่	พฤติกรรม followup ภายหลัง
steer	แทรกข้อความสั่งทิศทางที่รอคิวทั้งหมดพร้อมกันที่ขอบเขตรันไทม์ถัดไป นี่คือค่าเริ่มต้น	ถอยกลับไปใช้ followup เฉพาะเมื่อการสั่งทิศทางไม่พร้อมใช้งาน
queue	การสั่งทิศทางแบบเดิมทีละรายการ Pi แทรกข้อความที่รอคิวหนึ่งข้อความต่อขอบเขตโมเดลหนึ่งครั้ง; Codex ส่งคำขอ turn/steer แยกกัน	ถอยกลับไปใช้ followup เฉพาะเมื่อการสั่งทิศทางไม่พร้อมใช้งาน
steer-backlog	พฤติกรรมการสั่งทิศทางเมื่อมีการรันที่ใช้งานอยู่เหมือนกับ steer	ยังเก็บข้อความเดียวกันไว้สำหรับเทิร์น followup ภายหลังด้วย
followup	ไม่สั่งทิศทางการรันปัจจุบัน	รันข้อความที่รอคิวในภายหลัง
collect	ไม่สั่งทิศทางการรันปัจจุบัน	รวมข้อความที่รอคิวที่เข้ากันได้เป็นเทิร์นภายหลังหนึ่งเทิร์นหลังช่วงเวลา debounce
interrupt	ยกเลิกการรันที่ใช้งานอยู่ จากนั้นเริ่มข้อความล่าสุด	ไม่มี

# ตัวอย่างการส่งข้อความเป็นชุด

หากผู้ใช้สี่คนส่งข้อความขณะที่ agent กำลังเรียกใช้ tool call:

• steer: รันไทม์ที่ใช้งานอยู่ได้รับข้อความทั้งสี่ตามลำดับที่มาถึงก่อน การตัดสินใจของโมเดลครั้งถัดไป Pi ระบายข้อความเหล่านั้นที่ขอบเขตโมเดลถัดไป; Codex ได้รับเป็น turn/steer แบบรวมชุดหนึ่งรายการ
• queue: การสั่งทิศทางแบบเดิมที่เรียงลำดับทีละรายการ Pi แทรกข้อความที่รอคิวทีละข้อความ; Codex ได้รับคำขอ turn/steer แยกกัน
• collect: OpenClaw รอจนกว่าการรันที่ใช้งานอยู่จะสิ้นสุด จากนั้นสร้างเทิร์น followup พร้อมข้อความที่รอคิวซึ่งเข้ากันได้หลังช่วงเวลา debounce

# ขอบเขต

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

ใช้ collect เมื่อคุณต้องการให้ OpenClaw สร้างเทิร์น followup ภายหลังที่สามารถ รวมข้อความที่เข้ากันได้และรักษานโยบายการดรอปของคิว followup ไว้ ใช้ queue เฉพาะเมื่อคุณต้องการพฤติกรรมการสั่งทิศทางแบบเก่าทีละรายการ

# Debounce

messages.queue.debounceMs ใช้กับการส่งมอบ followup รวมถึง collect, followup, steer-backlog, และการถอยกลับของ steer เมื่อการสั่งทิศทางขณะมีการรันที่ใช้งานอยู่ ไม่พร้อมใช้งาน สำหรับ Pi ตัว steer ที่ใช้งานอยู่เองไม่ใช้ตัวจับเวลา debounce เพราะ Pi รวมข้อความเป็นชุดตามธรรมชาติจนถึงขอบเขตโมเดลถัดไป สำหรับฮาร์เนส Codex ดั้งเดิม OpenClaw ใช้ค่า debounce เดียวกันเป็นช่วงเวลานิ่งก่อน ส่ง turn/steer แบบรวมชุด

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

• คิวคำสั่ง
• สั่งทิศทาง
• ข้อความ
• ลูป agent