คิวคำสั่ง (2026-01-16)¶

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

ทำไม¶

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

ทำงานอย่างไร¶

• คิว FIFO ที่รับรู้เลนจะระบายงานในแต่ละเลนด้วยเพดานความพร้อมกันที่กำหนดค่าได้ (ค่าเริ่มต้น 1 สำหรับเลนที่ไม่ได้กำหนด; เลนหลักค่าเริ่มต้น 4, subagent 8)
• runEmbeddedPiAgent จะเข้าคิวตาม คีย์เซสชัน (เลน session:<key>) เพื่อรับประกันว่ามีการรันที่ทำงานอยู่เพียงหนึ่งรายการต่อเซสชัน
• จากนั้นการรันของแต่ละเซสชันจะถูกเข้าคิวไปยัง เลนส่วนกลาง (main โดยค่าเริ่มต้น) เพื่อจำกัดความพร้อมกันโดยรวมตาม agents.defaults.maxConcurrent
• เมื่อเปิดบันทึกแบบ verbose การรันที่ถูกเข้าคิวจะส่งประกาศสั้นๆหากรอมากกว่า ~2 วินาทีก่อนเริ่ม
• ตัวบ่งชี้การพิมพ์ยังคงทำงานทันทีเมื่อเข้าคิว (เมื่อช่องทางรองรับ) ดังนั้นประสบการณ์ผู้ใช้ไม่เปลี่ยนแปลงระหว่างรอคิว

โหมดคิว (ต่อช่องทาง)¶

ข้อความขาเข้าสามารถชี้นำการรันปัจจุบัน รอรอบถัดไป หรือทำทั้งสองอย่าง:

• steer: แทรกเข้าสู่การรันปัจจุบันทันที (ยกเลิกการเรียกเครื่องมือที่ค้างอยู่หลังขอบเขตเครื่องมือถัดไป) หากไม่สตรีมจะถอยกลับไปเป็น followup 25. หากไม่สตรีม จะถอยกลับไปใช้ followup
• followup: เข้าคิวสำหรับรอบเอเจนต์ถัดไปหลังการรันปัจจุบันจบ
• collect: รวมข้อความที่เข้าคิวทั้งหมดเป็นรอบ followup เดียว (ค่าเริ่มต้น) หากข้อความมุ่งไปยังช่องทาง/เธรดต่างกัน จะระบายแยกกันเพื่อคงการกำหนดเส้นทาง 26. หากข้อความมุ่งไปยังช่องทาง/เธรดที่ต่างกัน ข้อความจะถูกระบายแยกกันเพื่อคงการกำหนดเส้นทาง
• steer-backlog (หรือ steer+backlog): ชี้นำตอนนี้ และเก็บข้อความไว้สำหรับรอบ followup
• interrupt (เดิม): ยกเลิกการรันที่กำลังทำงานสำหรับเซสชันนั้น แล้วรันข้อความล่าสุด
• queue (นามแฝงเดิม): เหมือนกับ steer

Steer-backlog หมายความว่าคุณอาจได้รับการตอบกลับ followup หลังจากการรันที่ถูกชี้นำ ดังนั้นพื้นผิวที่สตรีมอาจดูเหมือนซ้ำ แนะนำให้ใช้ collect/steer หากต้องการหนึ่งการตอบกลับต่อหนึ่งข้อความขาเข้า ส่ง /queue collect เป็นคำสั่งเดี่ยว (ต่อเซสชัน) หรือกำหนด messages.queue.byChannel.discord: "collect". 27. แนะนำให้ใช้ collect/steer หากคุณต้องการ หนึ่งคำตอบต่อหนึ่งข้อความขาเข้า 28. ส่ง /queue collect เป็นคำสั่งเดี่ยว (ต่อเซสชัน) หรือกำหนด messages.queue.byChannel.discord: "collect"

ค่าเริ่มต้น (เมื่อไม่ได้ตั้งค่าในคอนฟิก):

• ทุกพื้นผิว → collect

กำหนดค่าระดับโกลบอลหรือรายช่องทางผ่าน messages.queue:

{
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
      byChannel: { discord: "collect" },
    },
  },
}

ตัวเลือกคิว¶

ตัวเลือกมีผลกับ followup, collect, และ steer-backlog (และกับ steer เมื่อถอยกลับไปเป็น followup):

• debounceMs: รอความเงียบก่อนเริ่มรอบ followup (ป้องกัน “ต่อ, ต่อ”)
• cap: จำนวนข้อความที่เข้าคิวสูงสุดต่อเซสชัน
• drop: นโยบายล้น (old, new, summarize)

29. Summarize จะเก็บรายการสั้น ๆ แบบหัวข้อย่อยของข้อความที่ถูกทิ้ง และแทรกเป็นพรอมป์ followup แบบสังเคราะห์ Summarize จะเก็บรายการหัวข้อย่อยสั้นๆของข้อความที่ถูกทิ้ง และแทรกเป็นพรอมป์ต์ followup แบบสังเคราะห์ ค่าเริ่มต้น: debounceMs: 1000, cap: 20, drop: summarize.

30. การแทนที่ค่าแบบต่อเซสชัน¶

• ส่ง /queue <mode> เป็นคำสั่งเดี่ยวเพื่อบันทึกโหมดสำหรับเซสชันปัจจุบัน
• สามารถรวมตัวเลือกได้: /queue collect debounce:2s cap:25 drop:summarize
• /queue default หรือ /queue reset จะล้างการแทนที่ของเซสชัน

ขอบเขตและการรับประกัน¶

• ใช้กับการรันเอเจนต์ตอบกลับอัตโนมัติในทุกช่องทางขาเข้าที่ใช้ pipeline การตอบกลับของ Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat ฯลฯ)
• เลนค่าเริ่มต้น (main) เป็นระดับโปรเซสสำหรับขาเข้า+ฮาร์ตบีตหลัก; ตั้งค่า agents.defaults.maxConcurrent เพื่ออนุญาตหลายเซสชันทำงานขนาน
• อาจมีเลนเพิ่มเติม (เช่น cron, subagent) เพื่อให้งานเบื้องหลังรันขนานได้โดยไม่บล็อกการตอบกลับขาเข้า
• เลนระดับเซสชันรับประกันว่ามีการรันเอเจนต์เพียงหนึ่งรายการแตะต้องเซสชันใดเซสชันหนึ่งในเวลาเดียวกัน
• ไม่มีการพึ่งพาภายนอกหรือเธรดเวิร์กเกอร์เบื้องหลัง; เป็น TypeScript ล้วน+promises

การแก้ไขปัญหา¶

• หากคำสั่งดูเหมือนค้าง ให้เปิดบันทึกแบบ verbose และมองหาบรรทัด “queued for …ms” เพื่อยืนยันว่าคิวกำลังระบายงาน
• หากต้องการความลึกของคิว ให้เปิดบันทึกแบบ verbose และสังเกตบรรทัดเวลาของคิว