Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
สถานะ: ทดลอง เพิ่มใน 2026.1.9
ภาพรวม
กลุ่มบรอดคาสต์ช่วยให้เอเจนต์หลายตัวประมวลผลและตอบกลับข้อความเดียวกันได้พร้อมกัน วิธีนี้ช่วยให้คุณสร้างทีมเอเจนต์เฉพาะทางที่ทำงานร่วมกันในกลุ่ม WhatsApp หรือ DM เดียว โดยทั้งหมดใช้หมายเลขโทรศัพท์เดียว ขอบเขตปัจจุบัน: เฉพาะ WhatsApp เท่านั้น (ช่องทางเว็บ) กลุ่มบรอดคาสต์จะถูกประเมินหลังจากรายการอนุญาตของช่องทางและกฎการเปิดใช้งานกลุ่ม ในกลุ่ม WhatsApp หมายความว่าการบรอดคาสต์จะเกิดขึ้นเมื่อ OpenClaw ปกติควรตอบกลับ (เช่น เมื่อถูกกล่าวถึง ขึ้นอยู่กับการตั้งค่ากลุ่มของคุณ)กรณีการใช้งาน
1. ทีมเอเจนต์เฉพาะทาง
1. ทีมเอเจนต์เฉพาะทาง
ปรับใช้เอเจนต์หลายตัวที่มีความรับผิดชอบแบบแยกย่อยและชัดเจน:เอเจนต์แต่ละตัวจะประมวลผลข้อความเดียวกันและให้มุมมองเฉพาะทางของตน
2. การรองรับหลายภาษา
2. การรองรับหลายภาษา
3. เวิร์กโฟลว์การประกันคุณภาพ
3. เวิร์กโฟลว์การประกันคุณภาพ
4. งานอัตโนมัติ
4. งานอัตโนมัติ
การกำหนดค่า
การตั้งค่าพื้นฐาน
เพิ่มส่วนbroadcast ระดับบนสุด (ถัดจาก bindings) คีย์คือ WhatsApp peer ids:
- แชตกลุ่ม: group JID (เช่น
120363403215116621@g.us) - DM: หมายเลขโทรศัพท์ E.164 (เช่น
+15551234567)
กลยุทธ์การประมวลผล
ควบคุมวิธีที่เอเจนต์ประมวลผลข้อความ:- parallel (ค่าเริ่มต้น)
- sequential
เอเจนต์ทั้งหมดประมวลผลพร้อมกัน:
ตัวอย่างแบบสมบูรณ์
วิธีการทำงาน
ลำดับการไหลของข้อความ
ถ้าอยู่ในรายการบรอดคาสต์
- เอเจนต์ทั้งหมดที่ระบุไว้จะประมวลผลข้อความ
- เอเจนต์แต่ละตัวมีคีย์เซสชันและบริบทที่แยกจากกัน
- เอเจนต์ประมวลผลแบบขนาน (ค่าเริ่มต้น) หรือตามลำดับ
กลุ่มบรอดคาสต์ไม่ข้ามรายการอนุญาตของช่องทางหรือกฎการเปิดใช้งานกลุ่ม (การกล่าวถึง/คำสั่ง/ฯลฯ) กลุ่มเหล่านี้เปลี่ยนเฉพาะ เอเจนต์ตัวใดที่จะรัน เมื่อข้อความมีสิทธิ์ถูกประมวลผล
การแยกเซสชัน
เอเจนต์แต่ละตัวในกลุ่มบรอดคาสต์จะรักษาสิ่งต่อไปนี้แยกจากกันโดยสมบูรณ์:- คีย์เซสชัน (
agent:alfred:whatsapp:group:120363...เทียบกับagent:baerbel:whatsapp:group:120363...) - ประวัติการสนทนา (เอเจนต์จะไม่เห็นข้อความของเอเจนต์อื่น)
- เวิร์กสเปซ (sandbox แยกกันหากกำหนดค่าไว้)
- การเข้าถึงเครื่องมือ (รายการอนุญาต/ปฏิเสธต่างกัน)
- หน่วยความจำ/บริบท (IDENTITY.md, SOUL.md ฯลฯ แยกกัน)
- บัฟเฟอร์บริบทกลุ่ม (ข้อความกลุ่มล่าสุดที่ใช้เป็นบริบท) ถูกแชร์ต่อ peer ดังนั้นเอเจนต์บรอดคาสต์ทั้งหมดจะเห็นบริบทเดียวกันเมื่อถูกทริกเกอร์
- บุคลิกที่แตกต่างกัน
- การเข้าถึงเครื่องมือต่างกัน (เช่น อ่านอย่างเดียว เทียบกับ อ่าน-เขียน)
- โมเดลต่างกัน (เช่น opus เทียบกับ sonnet)
- Skills ที่ติดตั้งต่างกัน
ตัวอย่าง: เซสชันที่แยกจากกัน
ในกลุ่ม120363403215116621@g.us ที่มีเอเจนต์ ["alfred", "baerbel"]:
- บริบทของ Alfred
- บริบทของ Bärbel
แนวทางปฏิบัติที่ดีที่สุด
1. ให้เอเจนต์มีขอบเขตชัดเจน
1. ให้เอเจนต์มีขอบเขตชัดเจน
ออกแบบเอเจนต์แต่ละตัวให้มีความรับผิดชอบเดียวที่ชัดเจน:✅ ดี: เอเจนต์แต่ละตัวมีงานเดียว ❌ ไม่ดี: เอเจนต์ “dev-helper” แบบทั่วไปตัวเดียว
2. ใช้ชื่อที่สื่อความหมาย
2. ใช้ชื่อที่สื่อความหมาย
ทำให้ชัดเจนว่าเอเจนต์แต่ละตัวทำอะไร:
3. กำหนดค่าการเข้าถึงเครื่องมือที่แตกต่างกัน
3. กำหนดค่าการเข้าถึงเครื่องมือที่แตกต่างกัน
ให้เอเจนต์เข้าถึงเฉพาะเครื่องมือที่จำเป็น:
reviewer อ่านได้อย่างเดียว fixer อ่านและเขียนได้4. ตรวจสอบประสิทธิภาพ
4. ตรวจสอบประสิทธิภาพ
เมื่อมีเอเจนต์จำนวนมาก ให้พิจารณา:
- ใช้
"strategy": "parallel"(ค่าเริ่มต้น) เพื่อความเร็ว - จำกัดกลุ่มบรอดคาสต์ไว้ที่ 5-10 เอเจนต์
- ใช้โมเดลที่เร็วกว่าสำหรับเอเจนต์ที่เรียบง่ายกว่า
5. จัดการความล้มเหลวอย่างเหมาะสม
5. จัดการความล้มเหลวอย่างเหมาะสม
เอเจนต์ล้มเหลวแยกจากกัน ข้อผิดพลาดของเอเจนต์ตัวหนึ่งจะไม่บล็อกตัวอื่น:
ความเข้ากันได้
ผู้ให้บริการ
ปัจจุบันกลุ่มบรอดคาสต์ทำงานกับ:- ✅ WhatsApp (นำไปใช้แล้ว)
- 🚧 Telegram (วางแผนไว้)
- 🚧 Discord (วางแผนไว้)
- 🚧 Slack (วางแผนไว้)
การกำหนดเส้นทาง
กลุ่มบรอดคาสต์ทำงานควบคู่กับการกำหนดเส้นทางที่มีอยู่:GROUP_A: มีเพียง alfred ที่ตอบกลับ (การกำหนดเส้นทางปกติ)GROUP_B: agent1 และ agent2 ตอบกลับ (บรอดคาสต์)
ลำดับความสำคัญ:
broadcast มีลำดับความสำคัญสูงกว่า bindingsการแก้ไขปัญหา
เอเจนต์ไม่ตอบกลับ
เอเจนต์ไม่ตอบกลับ
ตรวจสอบ:
- Agent IDs มีอยู่ใน
agents.list - รูปแบบ peer ID ถูกต้อง (เช่น
120363403215116621@g.us) - เอเจนต์ไม่อยู่ในรายการปฏิเสธ
มีเอเจนต์เพียงตัวเดียวที่ตอบกลับ
มีเอเจนต์เพียงตัวเดียวที่ตอบกลับ
สาเหตุ: peer ID อาจอยู่ใน
bindings แต่ไม่อยู่ใน broadcastวิธีแก้: เพิ่มลงในการกำหนดค่า broadcast หรือลบออกจาก bindingsปัญหาด้านประสิทธิภาพ
ปัญหาด้านประสิทธิภาพ
หากช้าเมื่อมีเอเจนต์จำนวนมาก:
- ลดจำนวนเอเจนต์ต่อกลุ่ม
- ใช้โมเดลที่เบากว่า (sonnet แทน opus)
- ตรวจสอบเวลาเริ่มต้นของ sandbox
ตัวอย่าง
ตัวอย่างที่ 1: ทีมรีวิวโค้ด
ตัวอย่างที่ 1: ทีมรีวิวโค้ด
- code-formatter: “แก้การเยื้องและเพิ่ม type hints แล้ว”
- security-scanner: “⚠️ ช่องโหว่ SQL injection ในบรรทัดที่ 12”
- test-coverage: “Coverage อยู่ที่ 45% ยังขาดเทสต์สำหรับกรณีข้อผิดพลาด”
- docs-checker: “ไม่มี docstring สำหรับฟังก์ชัน
process_data”
ตัวอย่างที่ 2: การรองรับหลายภาษา
ตัวอย่างที่ 2: การรองรับหลายภาษา
ข้อมูลอ้างอิง API
สคีมาการกำหนดค่า
ฟิลด์
วิธีประมวลผลเอเจนต์
parallel รันเอเจนต์ทั้งหมดพร้อมกัน ส่วน sequential รันตามลำดับในอาร์เรย์WhatsApp group JID, หมายเลข E.164 หรือ peer ID อื่น ค่าเป็นอาร์เรย์ของ agent IDs ที่ควรประมวลผลข้อความ
ข้อจำกัด
- จำนวนเอเจนต์สูงสุด: ไม่มีขีดจำกัดตายตัว แต่เอเจนต์ 10+ ตัวอาจทำงานช้า
- บริบทที่แชร์: เอเจนต์จะไม่เห็นคำตอบของกันและกัน (โดยออกแบบไว้เช่นนั้น)
- ลำดับข้อความ: คำตอบแบบขนานอาจมาถึงในลำดับใดก็ได้
- ขีดจำกัดอัตรา: เอเจนต์ทั้งหมดนับรวมในขีดจำกัดอัตราของ WhatsApp
การปรับปรุงในอนาคต
ฟีเจอร์ที่วางแผนไว้:- โหมดบริบทที่แชร์ (เอเจนต์เห็นคำตอบของกันและกัน)
- การประสานงานของเอเจนต์ (เอเจนต์สามารถส่งสัญญาณหากันได้)
- การเลือกเอเจนต์แบบไดนามิก (เลือกเอเจนต์ตามเนื้อหาข้อความ)
- ลำดับความสำคัญของเอเจนต์ (เอเจนต์บางตัวตอบกลับก่อนตัวอื่น)