Subagents: ให้ Claude Code แตกงานใหญ่เป็นทีมที่ทำขนานกัน

เวลาผมโยนงานใหญ่ ๆ ให้ Claude Code ในหัวข้อเดียว ผมสังเกตว่าคุณภาพมันค่อย ๆ ตกตอนใกล้จบ มันเริ่มลืมสิ่งที่อ่านไปตอนต้น และคำตอบเริ่มหลวม ทางออกที่เปลี่ยนเกมจริง ๆ คือเลิกบังคับให้มันทำทุกอย่างในหัวเดียว แล้วให้มัน แตกงานเป็น subagent หลายตัวที่วิ่งพร้อมกัน แล้วค่อยรวมผลเป็นคำตอบเดียว งานอย่าง "อ่านทั้ง repo แล้วสรุปสถาปัตยกรรม" หรือ "เทียบหลายทางเลือกแล้วเสนอข้อสรุป" คือตัวอย่างที่เห็นผลชัด นี่คือโครงคิดและกับดักที่ผมเจอจากการใช้มันจริง

ทำไมงานใหญ่ต้องแตก

หัวของ Claude มี context จำกัด เหมือนโต๊ะทำงานที่วางของได้เท่าที่มันวางได้ ถ้าคุณกองทุกไฟล์ ทุกบริบท ทุกคำสั่งลงบนโต๊ะตัวเดียว สุดท้ายของจะล้นและมันจะมองไม่เห็นภาพรวม งานที่ต้องอ่านเยอะ ๆ แล้วสังเคราะห์พร้อมกัน คือจุดที่คุณภาพตกง่ายที่สุด

ทางแก้ไม่ใช่ขยายโต๊ะ แต่คือ แบ่งงานออกเป็นโต๊ะหลายตัว ให้แต่ละ subagent รับผิดชอบส่วนเล็ก ๆ ที่มันโฟกัสได้เต็มที่ แล้วส่งกลับมาแค่ "ข้อสรุปที่ใช้ได้" ไม่ใช่กองวัตถุดิบทั้งหมด แบบนี้แต่ละตัวทำงานบนบริบทที่สะอาดและพอดีมือ

• งานยาวในหัวเดียว — รายละเอียดตอนต้นจะถูกทับด้วยตอนปลาย
• งานที่แตกแล้ว — แต่ละ subagent เห็นเฉพาะส่วนของมัน คุณภาพต่อชิ้นจึงสูงกว่า
• ตัวหลักไม่ต้องแบกทุกอย่าง มันเหลือพื้นที่ไว้ "คิดรวม" อย่างเดียว

แตกงานให้เป็นชิ้นที่อิสระต่อกัน

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

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

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

ทำขนานแล้วรวมผล

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

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

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

กับดักที่ต้องระวัง

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

กับดักที่สองคือ การรวมผลมั่ว ถ้าตัวสังเคราะห์แค่เอาทุกคำตอบมาต่อกันโดยไม่ตัดสิน คุณจะได้รายงานยาว ๆ ที่ขัดแย้งกันเองและไม่มีข้อสรุป — เสียทั้งเวลาและต้นทุน

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

หลักง่าย ๆ ที่ผมยึดคือ แตกเมื่องานใหญ่ อิสระต่อกัน และมีคนรวบได้ นอกนั้นทำตรง ๆ ดีกว่า

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