เลนเฉพาะทางแบบขนาน

เลนเฉพาะทางแบบขนานช่วยให้ Gateway เดียวกำหนดเส้นทางแชตหรือห้องต่าง ๆ ไปยัง ตัวแทนที่แตกต่างกันได้ พร้อมกับรักษาประสบการณ์ผู้ใช้ให้รวดเร็ว เคล็ดลับคือการมอง การทำงานแบบขนานเป็นปัญหาการออกแบบทรัพยากรที่มีจำกัด ไม่ใช่แค่การมี "ตัวแทนมากขึ้น"

# หลักการพื้นฐาน

เลนเฉพาะทางจะเพิ่มปริมาณงานได้ก็ต่อเมื่อช่วยลดการแย่งใช้ คอขวดจริง:

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

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

# การเปิดใช้ที่แนะนำ

# ระยะที่ 1: ข้อตกลงของเลน + งานหนักเบื้องหลัง

ให้ทุกเลนมีข้อตกลงเป็นลายลักษณ์อักษรในเวิร์กสเปซและพรอมป์ต์ระบบของตน:

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

นี่คือระยะที่ต้นทุนต่ำที่สุดและแก้การอุดตันส่วนใหญ่ได้: งานเขียนโค้ดหนึ่งงานจะไม่ ทำให้เลนวิจัยช้าจนหน่วงอีกต่อไป และแต่ละแชตรักษาบริบทของตัวเองให้สะอาด

# ระยะที่ 2: การควบคุมลำดับความสำคัญและการทำงานพร้อมกัน

ปรับคิวและความจุโมเดลตามคุณค่าทางธุรกิจของแต่ละเลน:

{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8 },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}

ใช้แชตโดยตรง/ส่วนตัวและตัวแทนงานปฏิบัติการโปรดักชันสำหรับงานที่มีลำดับความสำคัญสูง ให้ งานวิจัย งานร่าง และงานเขียนโค้ดแบบแบตช์ย้ายไปเป็นงานเบื้องหลังเมื่อระบบ ไม่ว่าง

# ระยะที่ 3: ผู้ประสานงาน / ตัวควบคุมทราฟฟิก

เพิ่มรูปแบบผู้ประสานงานขนาดเล็กเมื่อมีหลายเลนทำงานอยู่:

• ติดตามงานและเจ้าของของเลนที่กำลังทำงาน
• ตรวจจับคำขอซ้ำกันข้ามกลุ่ม
• กำหนดเส้นทางสรุปการส่งต่อระหว่างเลน
• แสดงเฉพาะตัวบล็อก ผลลัพธ์ที่เสร็จแล้ว และการตัดสินใจที่มนุษย์ต้องทำ

อย่าเริ่มจากจุดนี้ ผู้ประสานงานที่ไม่มีข้อตกลงของเลนมีแต่จะประสานความโกลาหล

# เทมเพลตข้อตกลงของเลนขั้นต่ำ

# Lane contract

## Owns

- <job this lane is responsible for>

## Does not own

- <work to hand off>

## Chat budget

- Answer quick questions directly.
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
  the work, then return the result when complete.

## Handoff

If another lane owns the request, reply with:

- target lane
- objective
- relevant context
- exact next action

## Tool posture

Use the smallest tool surface that can complete the task. Avoid broad shell or
network work unless this lane explicitly owns it.

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

• การกำหนดเส้นทางแบบหลายตัวแทน
• คิวคำสั่ง
• ตัวแทนย่อย