อย่างไรก็ตาม คำถามเพิ่มเติม

/btw ช่วยให้คุณถามคำถามข้างเคียงสั้น ๆ เกี่ยวกับเซสชันปัจจุบันได้โดยไม่ เปลี่ยนคำถามนั้นให้เป็นประวัติการสนทนาปกติ /side เป็น alias

มีต้นแบบจากพฤติกรรม /btw ของ Claude Code แต่ปรับให้เข้ากับ Gateway และ สถาปัตยกรรมหลายช่องทางของ OpenClaw

สิ่งที่ทำ

เมื่อคุณส่ง:

/btw what changed?

OpenClaw จะ:

1. snapshot บริบทเซสชันปัจจุบัน
2. รันคำถามข้างเคียงชั่วคราวแยกต่างหาก
3. ตอบเฉพาะคำถามข้างเคียง
4. ปล่อยให้การรันหลักทำงานตามเดิม
5. ไม่ เขียนคำถามหรือคำตอบ BTW ลงในประวัติเซสชัน
6. ส่งคำตอบออกมาเป็นผลลัพธ์ข้างเคียงแบบสดแทนข้อความ assistant ปกติ

โมเดลความคิดที่สำคัญคือ:

• บริบทเซสชันเดียวกัน
• คำถามข้างเคียงแบบ one-shot ที่แยกต่างหาก
• ใช้ transport ของ native harness เดียวกันเมื่อเซสชันใช้ native harness
• ไม่ปนเปื้อนบริบทในอนาคต
• ไม่บันทึก transcript ถาวร

สำหรับเซสชัน Codex harness, BTW จะอยู่ภายใน Codex โดย fork เธรด app-server ที่ใช้งานอยู่เป็นเธรดข้างเคียงชั่วคราว วิธีนี้รักษาพฤติกรรม Codex OAuth และเธรด native ไว้ครบถ้วน ขณะเดียวกันยังแยกคำตอบข้างเคียงออกจาก transcript ของ parent เช่นเดียวกับ /side ของ Codex เธรดข้างเคียงจะคง สิทธิ์ Codex ปัจจุบันและพื้นผิวเครื่องมือ native ไว้ พร้อม guardrails ที่บอกโมเดลว่าอย่า ถือว่างานที่สืบทอดมาจากเธรด parent เป็นคำสั่งที่ยังทำงานอยู่

สำหรับ alias ของ CLI runtime, BTW จะใช้ backend CLI เจ้าของในโหมดคำถามข้างเคียง แทนการ fallback ไปเรียก provider โดยตรง OpenClaw จะใส่บริบทการสนทนาที่ sanitize แล้ว ลงในการเรียก CLI แบบ one-shot ใหม่ ปิดการรวมเครื่องมือ OpenClaw MCP และสถานะเซสชัน CLI ที่ใช้ซ้ำได้สำหรับการเรียกนั้น และให้ backend เพิ่ม flag แบบ CLI-native สำหรับ no-resume หรือ no-tools เท่าที่รองรับได้ runtime แบบ direct ที่ไม่ใช่ CLI จะยังใช้เส้นทาง one-shot โดยตรง

สิ่งที่ไม่ทำ

/btw ไม่:

• สร้างเซสชันถาวรใหม่
• ทำงานหลักที่ยังไม่เสร็จต่อ
• เขียนข้อมูลคำถาม/คำตอบ BTW ลงในประวัติ transcript
• ปรากฏใน chat.history
• อยู่รอดหลัง reload

โดยตั้งใจให้เป็นชั่วคราว

วิธีทำงานของบริบท

BTW ใช้เซสชันปัจจุบันเป็นบริบทพื้นหลังเท่านั้น

หากการรันหลักกำลังทำงานอยู่ OpenClaw จะ snapshot สถานะข้อความปัจจุบัน และรวม prompt หลักที่กำลังดำเนินอยู่เป็นบริบทพื้นหลัง พร้อมบอกโมเดลอย่างชัดเจนว่า:

• ตอบเฉพาะคำถามข้างเคียง
• อย่า resume หรือทำงานหลักที่ยังไม่เสร็จให้เสร็จ
• อย่าบังคับทิศทางการสนทนา parent

สิ่งนี้ทำให้ BTW แยกจากการรันหลัก ขณะเดียวกันยังรับรู้ว่าเซสชันนี้เกี่ยวกับอะไร

โมเดลการส่งมอบ

BTW ไม่ ถูกส่งเป็นข้อความ transcript ของ assistant ปกติ

ในระดับโปรโตคอล Gateway:

• แชท assistant ปกติใช้ event chat
• BTW ใช้ event chat.side_result

การแยกนี้เป็นความตั้งใจ หาก BTW ใช้เส้นทาง event chat ปกติซ้ำ client จะถือว่ามันเป็นประวัติการสนทนาปกติ

เพราะ BTW ใช้ event สดแยกต่างหากและไม่ได้ replay จาก chat.history จึงหายไปหลัง reload

พฤติกรรมบนพื้นผิว

TUI

ใน TUI, BTW จะแสดง inline ในมุมมองเซสชันปัจจุบัน แต่ยังคงเป็น ข้อมูลชั่วคราว:

• มองเห็นว่าแตกต่างจากคำตอบ assistant ปกติ
• ปิดได้ด้วย Enter หรือ Esc
• ไม่ replay เมื่อ reload

ช่องทางภายนอก

บนช่องทางอย่าง Telegram, WhatsApp และ Discord, BTW จะถูกส่งเป็น คำตอบครั้งเดียวที่มีป้ายกำกับชัดเจน เพราะพื้นผิวเหล่านั้นไม่มีแนวคิด overlay ชั่วคราวแบบ local

คำตอบยังคงถูกปฏิบัติเป็นผลลัพธ์ข้างเคียง ไม่ใช่ประวัติเซสชันปกติ

Control UI / เว็บ

Gateway ส่ง BTW อย่างถูกต้องเป็น chat.side_result และ BTW ไม่ถูกรวมอยู่ใน chat.history ดังนั้นสัญญาการคงอยู่จึงถูกต้องแล้วสำหรับเว็บ

Control UI ปัจจุบันยังต้องมี consumer เฉพาะสำหรับ chat.side_result เพื่อ render BTW แบบสดใน browser จนกว่าการรองรับฝั่ง client นี้จะเสร็จ BTW จึงเป็น ฟีเจอร์ระดับ Gateway ที่มีพฤติกรรมครบถ้วนใน TUI และช่องทางภายนอก แต่ยังไม่ใช่ UX บน browser ที่สมบูรณ์

เมื่อใดควรใช้ BTW

ใช้ /btw เมื่อคุณต้องการ:

• การชี้แจงสั้น ๆ เกี่ยวกับงานปัจจุบัน
• คำตอบข้อเท็จจริงข้างเคียงขณะที่การรันยาวยังดำเนินอยู่
• คำตอบชั่วคราวที่ไม่ควรกลายเป็นส่วนหนึ่งของบริบทเซสชันในอนาคต

ตัวอย่าง:

/btw what file are we editing?/side what changed while the main run continued?/btw what does this error mean?/btw summarize the current task in one sentence/btw what is 17 * 19?

เมื่อใดไม่ควรใช้ BTW

อย่าใช้ /btw เมื่อคุณต้องการให้คำตอบกลายเป็นส่วนหนึ่งของบริบทการทำงาน ในอนาคตของเซสชัน

ในกรณีนั้น ให้ถามตามปกติในเซสชันหลักแทนการใช้ BTW

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