ทีมงานสามคนที่จัดการเองได้อยู่แล้ว ยังไม่จำเป็นต้องรีบใช้ Subagent

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

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

บทความนี้จะอธิบาย Subagent คืออะไรกันแน่ ต่างจาก Custom Agent อย่างไร แล้ววางเกณฑ์ที่ใช้ตัดสินใจได้จริงว่าเมื่อไรควรใช้ และเมื่อไรควรปล่อยให้ Agent ตัวเดียวทำงานต่อไปแบบเดิม

Subagent คืออะไร และทำงานต่างจาก Agent หลักอย่างไร

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

ตัวอย่างที่เห็นภาพชัดคือ Agent หลักที่กำลังช่วยรีวิวโค้ดขนาดใหญ่ อาจเรียก Subagent สามตัวขึ้นมาพร้อมกัน ตัวหนึ่งตรวจสอบความปลอดภัย ตัวหนึ่งตรวจสอบ performance และตัวหนึ่งตรวจสอบ style ให้ตรงตาม convention แต่ละตัวทำงานเฉพาะทางของตัวเองแบบขนาน แล้ว Agent หลักรวบรวมผลลัพธ์ทั้งสามมาสรุปเป็นรายงานเดียวให้ผู้ใช้เห็น

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

ต่างจาก Custom Agent ที่เคยอธิบายไปก่อนหน้านี้อย่างไร

Custom Agent คือ Agent ที่ตั้งค่าไว้ล่วงหน้าสำหรับบทบาทหนึ่งโดยเฉพาะ มีอยู่ต่อเนื่องพร้อมรับงานได้ตลอดเวลาเหมือนพนักงานประจำตำแหน่งหนึ่ง ส่วน Subagent มักถูกสร้างขึ้นชั่วคราวเฉพาะตอนที่ Agent หลักต้องการความช่วยเหลือในงานย่อยหนึ่ง แล้วหายไปหลังทำงานเสร็จ เหมือนการเรียกที่ปรึกษาชั่วคราวมาช่วยงานเฉพาะกิจแล้วจบสัญญาหลังงานเสร็จ

ความสัมพันธ์ระหว่างสองแนวคิดนี้ไม่ใช่การแข่งขันแทนที่กัน แต่ใช้ร่วมกันได้ เช่น Custom Agent ตัวหนึ่งที่ตั้งไว้สำหรับดูแลงานรีวิวโค้ดโดยเฉพาะ อาจเรียก Subagent ย่อยขึ้นมาช่วยตรวจแต่ละด้านตามตัวอย่างก่อนหน้า การมี Custom Agent เป็นตัวหลักที่รู้จักบริบทงานตลอด แล้วใช้ Subagent เป็นเครื่องมือช่วยแบ่งงานย่อยเฉพาะกิจ มักให้ผลลัพธ์ที่จัดการง่ายกว่าการพยายามทำทุกอย่างในระดับเดียว

สัญญาณที่บอกว่างานนี้เหมาะกับการใช้ Subagent จริง

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

ทีมงานสามคนที่จัดการเองได้อยู่แล้ว ทำไมยังไม่ต้องรีบใช้ Subagent

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

ต้นทุนที่มองไม่เห็นในตอนแรกของการใช้ Subagent คือเวลาที่เสียไปกับการประสานงานระหว่าง Agent หลักกับ Subagent แต่ละตัว การเรียก Subagent ขึ้นมาแต่ละครั้งมีค่าใช้จ่ายด้าน latency และบางระบบมีค่าใช้จ่ายด้าน token ที่เพิ่มขึ้นตามจำนวน Agent ที่ทำงานพร้อมกัน ถ้างานเล็กพอที่ Agent ตัวเดียวทำเสร็จในเวลาไล่เลี่ยกัน การแบ่งงานออกไปอาจช้ากว่าเดิมด้วยซ้ำ

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

ตารางเปรียบเทียบ Agent ตัวเดียวกับการใช้ Subagent

ตารางนี้สรุปปัจจัยที่ควรใช้ตัดสินใจก่อนเพิ่ม Subagent เข้าไปในระบบที่มีอยู่:

ออกแบบการส่งงานระหว่าง Agent หลักกับ Subagent ให้ไม่พังกลางทาง

เมื่อตัดสินใจใช้ Subagent จริง จุดที่ต้องออกแบบให้รอบคอบคือข้อมูลที่ส่งให้ Subagent ตอนเริ่มงานและรูปแบบผลลัพธ์ที่ Subagent ต้องส่งกลับ ควรส่งเฉพาะข้อมูลที่จำเป็นต่องานนั้นจริง ไม่ใช่ส่ง context ทั้งหมดของบทสนทนาไปให้ เพราะนอกจากจะกินพื้นที่โดยไม่จำเป็นแล้ว ยังเสี่ยงให้ Subagent ไปโฟกัสผิดจุดจากข้อมูลที่ไม่เกี่ยวข้องปนอยู่

รูปแบบผลลัพธ์ที่ Subagent ส่งกลับควรมีโครงสร้างชัดเจนเช่นเดียวกับหลักการออกแบบผลลัพธ์ของ MCP tool เพราะ Agent หลักต้องเอาผลลัพธ์จาก Subagent หลายตัวมารวมกันเป็นคำตอบเดียว ถ้าแต่ละตัวส่งกลับมาเป็นข้อความอิสระที่ไม่มีโครงสร้างร่วมกัน การรวมผลจะทำได้ยากและเสี่ยงตีความผิด ควรกำหนดรูปแบบผลลัพธ์มาตรฐาน เช่น ระบุสถานะสำเร็จหรือไม่ พร้อมสรุปผลและรายละเอียดที่จำเป็นแยกกันชัดเจน

ควรมีแผนรองรับเมื่อ Subagent ตัวใดตัวหนึ่งทำงานไม่สำเร็จหรือใช้เวลานานเกินไป Agent หลักไม่ควรค้างรอเฉย ๆ โดยไม่มีขีดจำกัดเวลา ควรกำหนด timeout ที่เหมาะสมและมีทางเลือกสำรอง เช่น ถ้า Subagent ด้านความปลอดภัยไม่ตอบภายในเวลาที่กำหนด Agent หลักควรแจ้งผู้ใช้ว่าส่วนนี้ยังตรวจสอบไม่เสร็จ แทนที่จะปล่อยให้ทั้งระบบค้างรอไม่มีกำหนด

วัดผลจริงว่า Subagent คุ้มค่ากับความซับซ้อนที่เพิ่มขึ้นหรือไม่

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

ตัวอย่างสมมติที่พบได้ทั่วไปคือทีมหนึ่งวัดเวลาทำงานรีวิวโค้ดชุดหนึ่งด้วย Agent ตัวเดียวใช้เวลาเฉลี่ย 40 วินาทีต่อไฟล์ ส่วนเมื่อแบ่งเป็น Subagent สามตัวทำขนานกัน เวลารวมลดลงเหลือประมาณ 25 วินาทีต่อไฟล์สำหรับไฟล์ขนาดใหญ่ที่มีหลายด้านต้องตรวจ แต่สำหรับไฟล์เล็กที่มีโค้ดไม่กี่บรรทัด การใช้ Subagent กลับใช้เวลานานกว่าเดิมเพราะค่าใช้จ่ายในการเรียกและรวมผลมากกว่าเวลาที่ประหยัดได้จากการทำขนาน ตัวเลขเหล่านี้เป็นตัวอย่างสมมติที่ใช้อธิบายกรอบวิเคราะห์ ไม่ใช่ผลวัดจริงจากระบบใดระบบหนึ่ง

ข้อสรุปที่ได้จากการวัดผลลักษณะนี้คือ Subagent ไม่ได้ให้ผลดีเสมอในทุกขนาดงาน ทีมควรกำหนดเกณฑ์ว่างานขนาดไหนถึงคุ้มค่าที่จะแบ่งเป็น Subagent เช่น เฉพาะไฟล์ที่มีจำนวนบรรทัดเกินเกณฑ์ที่กำหนด แล้วปล่อยให้ Agent ตัวเดียวจัดการงานขนาดเล็กไปตามปกติ วิธีนี้ช่วยให้ระบบใช้ทรัพยากรอย่างเหมาะสมกับขนาดของแต่ละงานจริง

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอบ่อยตอนใช้ Subagent

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

สรุป

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

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

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

คำถามที่พบบ่อย