---
read_when:
    - การเปลี่ยนแปลงการทำงานหรือ concurrency ของการตอบกลับอัตโนมัติ
summary: การออกแบบคิวคำสั่งที่จัดลำดับการรันการตอบกลับอัตโนมัติขาเข้าแบบอนุกรม
title: คิวคำสั่ง
x-i18n:
    generated_at: "2026-04-25T13:45:56Z"
    model: gpt-5.4
    provider: openai
    source_hash: 0c027be3e9a67f91a49c5d4d69fa8191d3e7651265a152c4723b10062b339f2a
    source_path: concepts/queue.md
    workflow: 15
---

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

## ทำไม

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

## วิธีการทำงาน

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

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

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

- `steer`: inject เข้าไปในการรันปัจจุบันทันที (ยกเลิกการเรียก tool ที่รอดำเนินการหลังจากถึง tool boundary ถัดไป) หากไม่ได้สตรีม จะ fallback ไปเป็น followup
- `followup`: เข้าคิวสำหรับรอบถัดไปของเอเจนต์หลังจากการรันปัจจุบันจบลง
- `collect`: รวมข้อความทั้งหมดที่อยู่ในคิวให้เป็นรอบ followup **รอบเดียว** (ค่าเริ่มต้น) หากข้อความมุ่งไปยังช่องทาง/เธรดที่ต่างกัน จะระบายแยกกันเพื่อรักษาการกำหนดเส้นทาง
- `steer-backlog` (หรือ `steer+backlog`): steer ตอนนี้ **และ** เก็บข้อความไว้สำหรับรอบ followup
- `interrupt` (แบบเดิม): abort การรันที่กำลังทำงานของเซสชันนั้น แล้วจึงรันข้อความล่าสุด
- `queue` (alias แบบเดิม): เหมือนกับ `steer`

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

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

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

กำหนดค่าแบบ global หรือแยกตามช่องทางผ่าน `messages.queue`:

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

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

ตัวเลือกเหล่านี้ใช้กับ `followup`, `collect` และ `steer-backlog` (และใช้กับ `steer` เมื่อ fallback ไปเป็น followup):

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

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

## การแทนที่ต่อเซสชัน

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

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

- ใช้กับการรันเอเจนต์แบบตอบกลับอัตโนมัติในทุกช่องทางขาเข้าที่ใช้ gateway reply pipeline (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat เป็นต้น)
- lane เริ่มต้น (`main`) ใช้ร่วมกันทั้งโปรเซสสำหรับข้อความขาเข้า + main Heartbeat; ตั้งค่า `agents.defaults.maxConcurrent` เพื่ออนุญาตให้หลายเซสชันทำงานขนานกันได้
- อาจมี lane เพิ่มเติม (เช่น `cron`, `subagent`) เพื่อให้งานพื้นหลังทำงานขนานกันได้โดยไม่บล็อกการตอบกลับขาเข้า การรันแบบ detached เหล่านี้จะถูกติดตามเป็น [background tasks](/th/automation/tasks)
- lane ต่อเซสชันรับประกันว่าจะมีการรันของเอเจนต์เพียงรายการเดียวที่แตะเซสชันนั้นในเวลาเดียวกัน
- ไม่มี dependency ภายนอกหรือ background worker thread; เป็น TypeScript + promises ล้วน

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

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

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

- [การจัดการเซสชัน](/th/concepts/session)
- [นโยบายการลองใหม่](/th/concepts/retry)
