Sub Agent: เมื่อไหร่ควรแยก เมื่อไหร่ไม่ต้อง

เมื่อไหร่ควรใช้ sub agent และเมื่อไหร่ไม่ควร


ใน Claude Code มีเครื่องมือ Agent ที่สามารถเปิด sub agent อิสระระหว่างการสนทนาเพื่อไปทำงานแยก sub agent มี context เป็นของตัวเอง ทำเสร็จแล้วส่งผลลัพธ์กลับมาให้ agent หลัก

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

กลไกการทำงานของ Sub Agent

คุณไม่สามารถเรียกใช้ Agent tool โดยตรงจาก CLAUDE.md หรือ slash command ได้ Claude Code จะตัดสินใจเองว่าจะใช้มันหรือไม่ แต่คุณสามารถชี้นำการตัดสินใจผ่าน prompt ได้

วิธีการทำงาน:

  1. Agent หลักเปิด sub agent พร้อม prompt ที่กำหนด
  2. Sub agent ทำงานใน context อิสระ สามารถใช้เครื่องมือส่วนใหญ่ได้ (อ่านไฟล์ ค้นหา รันคำสั่ง ฯลฯ)
  3. เมื่อทำเสร็จ sub agent ส่งผลลัพธ์กลับเป็นข้อความเดียวให้ agent หลัก
  4. Agent หลักรับผลลัพธ์แล้วทำงานต่อ

คุณสมบัติสำคัญ:
- Context อิสระ: Sub agent มองไม่เห็นประวัติการสนทนาหลัก เห็นแค่ prompt ที่ได้รับตอนเริ่มต้น
- การบีบอัดผลลัพธ์: ไม่ว่า sub agent จะอ่านไฟล์กี่ไฟล์หรือรันคำสั่งกี่ครั้ง สิ่งที่ส่งกลับ agent หลักคือสรุปเท่านั้น
- รันแบบขนาน: สามารถเปิด sub agent หลายตัวพร้อมกันได้

3 สถานการณ์ที่ควรใช้ Sub Agent

1. ค้นหาและวิจัยแบบขนาน

สถานการณ์คลาสสิกที่สุด คุณให้ Claude Code สำรวจปัญหาที่ต้องค้นหาหลายทิศทางพร้อมกัน

เช่น ถามว่า: "ระบบ authentication ของโปรเจกต์นี้ทำงานยังไง?"

ถ้าไม่แยก agent, Claude Code จะทำทีละขั้น: อ่าน auth controller -> อ่าน middleware -> อ่าน routes -> อ่าน model -> อ่าน config... ทีละอย่าง ช้า

แยกเป็น sub agent:

เปิด 3 sub agent พร้อมกัน:
- Agent 1: ตรวจสอบ logic การ authenticate ในชั้น controller และ middleware
- Agent 2: ตรวจสอบการออกแบบ user และ session ในชั้น model
- Agent 3: ตรวจสอบการตั้งค่า authentication ในไฟล์ config และ environment variables

สามทิศทางรันพร้อมกัน แล้วรวมผลลัพธ์ คุณสามารถชี้นำใน CLAUDE.md ได้แบบนี้:

## งานสำรวจ
เมื่อต้องสำรวจปัญหาที่ข้ามหลายโมดูล ให้เปิด sub agent หลายตัวแบบขนาน
เพื่อสำรวจแต่ละส่วน แล้วรวมข้อสรุป

2. ปกป้อง Context หลัก

Context window ของ Claude Code มีจำกัด ถ้างานย่อยต้องอ่านไฟล์จำนวนมากแต่สุดท้ายต้องการแค่ข้อสรุปเดียว การใช้ sub agent ช่วยกันไม่ให้ "ขยะระหว่างกระบวนการ" เข้ามาเต็ม context หลัก

ตัวอย่างที่พบบ่อย:

  • ค้นหาใน 50 ไฟล์ว่า API ตัวหนึ่งถูกเรียกใช้ที่ไหนบ้าง แล้ววิเคราะห์รูปแบบการเรียกใช้
  • วิเคราะห์ไฟล์ config ขนาดใหญ่ โดยต้องการแค่ดึงค่าสำคัญไม่กี่ตัว
  • ตรวจสอบกลุ่มไฟล์ test เพื่อดูว่า test coverage เพียงพอหรือไม่

ลักษณะเด่นของงานเหล่านี้คือ input ใหญ่ output เล็ก Sub agent ย่อยข้อมูลจำนวนมากภายใน แล้วส่งกลับเฉพาะแก่นสาร

3. แยกการทำงานที่มีความเสี่ยง

บางงานคุณไม่แน่ใจว่าผลลัพธ์จะออกมาดีหรือเปล่า ใช้ sub agent พร้อมพารามิเตอร์ isolation: "worktree" มันจะทำงานใน git worktree แยกต่างหาก ถ้าทำพังก็ไม่กระทบ working directory ปัจจุบัน

## การ Refactor ที่มีความเสี่ยงสูง
สำหรับงาน refactor ขนาดใหญ่ ให้ใช้ sub agent พร้อม worktree isolation
ตรวจสอบผลลัพธ์ให้แน่ใจก่อน merge

สถานการณ์ที่เหมาะ:
- Refactor แบบทดลอง: ไม่แน่ใจว่าแนวทางหนึ่งจะเวิร์กหรือเปล่า ให้ sub agent ลองก่อน
- เปรียบเทียบแนวทางแบบขนาน: ลงมือทำสองวิธีพร้อมกัน แล้วเปรียบเทียบผลลัพธ์
- สร้างโค้ด: สร้าง boilerplate จำนวนมาก review ก่อนแล้วค่อย merge

เมื่อไหร่ไม่ควรใช้ Sub Agent

งานง่าย ๆ ตรงไปตรงมา

"เปลี่ยนชื่อฟังก์ชันจาก camelCase เป็น snake_case" แบบนี้ทำเลยได้เลย ค่าใช้จ่ายในการเปิด sub agent (สร้าง context, รอผลลัพธ์, ตีความผล) กลับช้ากว่าทำตรง ๆ

เกณฑ์ตัดสิน: ถ้า Grep หนึ่งครั้ง + Edit หนึ่งครั้งจัดการได้ อย่าแยก agent

งานที่ต้องทำตามลำดับและมี dependency แน่น

"อ่าน config -> แก้โค้ดตาม config -> อัปเดต test ตามที่แก้"

งานแบบเชนที่แต่ละขั้นตอนต้องพึ่งผลลัพธ์ของขั้นก่อนหน้า ถ้าแยกเป็น sub agent คุณต้องส่งผลลัพธ์ระหว่างทางผ่าน prompt ซึ่งทั้งยุ่งยากและเสี่ยงต่อการสูญเสียข้อมูล ทำตามลำดับไปเลยดีกว่า

การแก้ไขที่ต้องการความแม่นยำสูง

สิ่งที่ sub agent ส่งกลับมาคือข้อความสรุป ไม่ใช่ structured data ถ้าคุณต้องการการแก้ไขที่แม่นยำ (เช่น แทรกโค้ดเฉพาะที่บรรทัด 47) ให้ agent หลักทำเองจะเชื่อถือได้มากกว่า

Sub agent เหมาะกับ "สำรวจแล้วสรุป" ไม่เหมาะกับ "แก้ไขอย่างแม่นยำ"

เมื่อ Context ยังเหลือเฟือ

ถ้าการสนทนาเพิ่งเริ่ม context window ยังว่างอยู่ ไม่จำเป็นต้องแยก agent เพื่อ "ปกป้อง context" รอจนกว่าการสนทนาจะยาวขึ้นและ agent หลักเริ่มบีบอัดข้อความเก่า ค่อยพิจารณาใช้ sub agent สำหรับงานหนัก

เปรียบเทียบผลลัพธ์จริง

ลองดูสถานการณ์จริง: สำรวจ controller ทั้งหมดที่ใช้ before_action ในโปรเจกต์ Rails วิเคราะห์รูปแบบ authentication และ authorization

ไม่ใช้ sub agent:

Claude Code จะอ่านไฟล์ controller ทีละไฟล์ แต่ละไฟล์กิน context หลัก ถ้ามี 20 controller เนื้อหาไฟล์อย่างเดียวอาจกิน token ไปมหาศาล ตอนสรุปผลวิเคราะห์ รายละเอียดที่อ่านก่อนหน้าอาจหายไปจากการบีบอัดแล้ว

ใช้ sub agent:

เปิด sub agent: "อ่าน controller ทั้งหมดใน app/controllers/
หา callback ประเภท before_action ทั้งหมด
วิเคราะห์รูปแบบ authentication และ authorization
แล้วสรุปเป็นหมวดหมู่"

Sub agent อ่านไฟล์ทั้งหมดใน context ของตัวเอง แล้วส่งสรุปที่สะอาดกลับมา Context หลักแทบไม่ถูกใช้ agent หลักได้ข้อสรุปแล้วเดินหน้าต่อได้ทันที

ชี้นำการใช้ Sub Agent ใน CLAUDE.md

คุณบังคับให้ Claude Code ใช้หรือไม่ใช้ sub agent ไม่ได้ แต่สามารถแสดงความต้องการใน CLAUDE.md ได้:

## ความต้องการในการใช้ Agent

### งานที่เหมาะจะแยก sub agent
- สำรวจข้ามโมดูล (ค้นหาใน 3 ไดเรกทอรีขึ้นไป)
- ค้นหาและนับสถิติในโค้ดขอบเขตกว้าง
- Refactor แบบทดลอง (พร้อม worktree isolation)

### งานที่ไม่ควรแยก sub agent
- แก้ไขไฟล์เดียว
- การทำงานหลายขั้นตอนที่มี dependency ตามลำดับ
- แก้ bug ที่รู้ตำแหน่งแน่ชัดแล้ว

หลักตัดสินในประโยคเดียว

"กระบวนการ" ของงานนี้ใหญ่กว่า "ข้อสรุป" มากไหม?

ถ้าใช่ — ใช้ sub agent ให้มันย่อยกระบวนการแล้วส่งกลับแค่ข้อสรุป
ถ้าไม่ — ทำตรง ๆ ไม่ต้องเพิ่มชั้นตรงกลาง

Sub agent ไม่ใช่ยิ่งมากยิ่งดี มันเป็นเครื่องมือจัดการ context ไม่ใช่ framework สำหรับ concurrent programming ใช้ถูกที่จะช่วยให้ Claude Code ทำงานได้อย่างมีสติในโปรเจกต์ใหญ่ ใช้ผิดที่ก็แค่เสียเวลาเริ่มต้นเปล่า ๆ