Coordinator กับ subagent แบบ hub-and-spoke

แนวคิด

เมื่องานใหญ่เกินกว่าจะให้ agent เดียวทำไหว เราแบ่งเป็นระบบหลาย agent รูปแบบที่นิยมคือ hub-and-spoke มี coordinator เป็นดุมกลาง และ subagent หลายตัวเป็นซี่ล้อ การสื่อสารทุกทิศทางวิ่งผ่าน coordinator ไม่ใช่ให้ subagent คุยกันเองโดยตรง

coordinator รับผิดชอบสี่อย่าง คือ แตกงานเป็นงานย่อย, มอบหมายให้ subagent ที่เหมาะ, รวบรวมผลลัพธ์กลับมา, และตัดสินใจว่าคำถามนี้ต้องเรียก subagent ตัวไหนบ้างตามความซับซ้อน coordinator ที่ดีจะวิเคราะห์คำขอแล้วเลือกเรียกเฉพาะ subagent ที่จำเป็น ไม่ใช่ยิงผ่านทั้ง pipeline ทุกครั้ง

subagent แต่ละตัวทำงานในบริบทแยกของตัวเอง ผลลัพธ์กลาง tool call และการค้นข้อมูลจะอยู่ภายใน subagent ตัวนั้น มีแค่ข้อความสุดท้ายที่ส่งกลับให้ coordinator ทำให้บริบทของดุมกลางไม่บวมด้วยรายละเอียดยิบย่อยของทุกซี่ล้อ

ทำไมสำคัญ

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

พิจารณ Sample Question ข้อ 8 ว่า subagent ค้นเว็บ time out ระหว่างค้นหัวข้อยาก คำถามคือควรออกแบบให้ข้อมูลความล้มเหลวไหลกลับสู่ coordinator แบบไหน คำตอบที่ดีคือส่ง error ที่มีโครงสร้างกลับไป ประกอบด้วยชนิดของความล้มเหลว, query ที่พยายามใช้, ผลบางส่วนที่ได้มา, และทางเลือกที่พอเป็นไปได้ coordinator จึงตัดสินใจอย่างมีข้อมูลว่าจะลองใหม่ด้วย query อื่น หรือเดินหน้าด้วยผลบางส่วน

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

ตัวอย่าง

{
  "failure_type": "timeout",
  "attempted_query": "AI impact on music industry 2025",
  "partial_results": ["บทความ 2 ชิ้นที่โหลดทัน"],
  "suggested_alternatives": ["ลด scope เป็นรายปี", "เปลี่ยนคำค้น"]
}

โครงสร้างแบบนี้ให้ coordinator มีทุกอย่างที่ต้องใช้ตัดสินใจกู้คืน แทนที่จะรู้แค่ว่าล้มเหลว

เช็คความเข้าใจ

อ่านต่อ

• Subagents in the Agent SDK
• Tool use overview