EP3 Subagent ส่งงานให้ผู้ช่วยที่มีห้องของตัวเอง หัวหลักไม่รก ทำขนานได้

EP2 เราให้ AI มีความรู้ มีคู่มือ และมีกฎบังคับแล้ว แต่มันยังทำทุกอย่างในหัวเดียว งานใหญ่ ๆ จึงเจอปัญหาสองข้อ หัวรกเพราะต้องอ่านไฟล์เยอะ และทำได้ทีละอย่าง ตอนนี้จะแก้ด้วย subagent

ปัญหา: หัวเดียวรับไม่ไหว

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

ในบริษัท หัวหน้าไม่ได้ไปค้นแฟ้มเองทุกแฟ้ม เขาส่งให้ผู้ช่วยไปหา แล้วรับแค่สรุปกลับมา

หลักการ: งานที่อ่านเยอะแต่ผลสั้น หรืองานที่แยกทำได้ ให้ผู้ช่วยทำในห้องของเขา แล้วส่งกลับแค่ผล

Subagent ทำงานยังไง

1. AI หลักเขียนใบสั่งงานให้ subagent
2. subagent เริ่มใน context ใหม่ที่ว่างเปล่า อ่านไฟล์ รันคำสั่ง ทำงานจนเสร็จ
3. ส่งกลับแค่ผลสรุป ไฟล์ที่อ่านไปทั้งหมดไม่ตามกลับมา
4. ถ้างานแยกกันได้ ส่งหลายตัวพร้อมกันได้

Claude Code มี subagent สำเร็จรูปมาให้บางส่วน เช่น ตัวค้นหาโค้ดแบบอ่านอย่างเดียว และเราสร้างผู้ช่วยเฉพาะทางของเราเองได้

สร้างผู้ช่วยเฉพาะทาง

เก็บไว้ที่ .claude/agents/<ชื่อ>.md หน้าตาคล้าย skill แต่เป็น “คน” ไม่ใช่ “คู่มือ”

---
name: reviewer
description: รีวิวโค้ดที่เพิ่งแก้ หาบั๊กและช่องโหว่ ใช้หลังแก้โค้ดเสร็จ ก่อน commit
tools: Read, Grep, Glob, Bash
---

คุณคือผู้รีวิวโค้ด อ่าน diff ล่าสุด หาบั๊กที่ทำให้ผลผิดจริง
ห้ามแก้ไฟล์ รายงานเป็นรายการ: ไฟล์:บรรทัด ปัญหา วิธีแก้

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

ตัวอย่างจริง: ผู้ช่วยที่พกบทเรียนติดตัว

เว็บออกแบบชิ้นงาน 3D ที่เราทำ มีผู้ช่วยเฉพาะทางชื่อ forge-smith ทำหน้าที่เดียว คือสร้างและแก้ตัวสร้างโมเดล 3D ไฟล์ agent ของมันพกบทเรียนแพง ๆ ไว้สองข้อ

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

บทเรียนแบบนี้ถ้าอยู่ใน CLAUDE.md ของทั้งโปรเจกต์ จะปนกับเรื่องอื่นจนจม แต่อยู่ในไฟล์ของผู้ช่วยที่ทำงานนั้นโดยตรง มันจะเห็นทุกครั้งที่ถูกเรียก

ทำขนาน: แต่ละคนมีโต๊ะของตัวเอง

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

โปรเจกต์ 3D เดียวกันนี้เคยส่ง subagent ทำงานขนานกันจนมี worktree ค้างอยู่ 8 ชุด ได้งานเร็วขึ้นจริง แต่ก็ได้บทเรียนว่าต้องมีคนเก็บกวาด worktree ที่ใช้เสร็จแล้วด้วย

ข้อเสียที่ต้องรู้

• มันไม่เห็นบทสนทนาหลัก ใบสั่งงานต้องครบในตัว: ทำอะไร ไฟล์ไหน เสร็จแปลว่าอะไร ส่งผลกลับแบบไหน
• token รวมอาจมากขึ้น เพราะแต่ละตัวเริ่มจากศูนย์และอ่านไฟล์เอง ได้ความเร็วกับหัวที่ไม่รก ไม่ได้ได้ความถูกฟรี
• ผลสรุปอาจตกหล่น สิ่งที่ subagent ไม่ได้เขียนกลับมา ตัวหลักจะไม่รู้ งานสำคัญจึงควรสั่งให้รายงานสิ่งที่ “ยังไม่ได้ตรวจ” ด้วย

ลองเองใน 10 นาที

1. สร้าง .claude/agents/reviewer.md ตามตัวอย่างข้างบน
2. แก้โค้ดอะไรสักอย่าง แล้วสั่งว่า “ให้ reviewer รีวิวสิ่งที่เพิ่งแก้”
3. สังเกตว่าตัวหลักได้กลับมาแค่รายการปัญหา ไม่ได้มีไฟล์ทั้งหมดที่ reviewer อ่านปนกลับมาด้วย

ตรงไหนที่คนต้องทำ

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

ตอนหน้า

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