Claude Code Subagents: วิธีการและเวลาที่เหมาะสมในการรันทีม Agent

อัปเดตล่าสุด: June 28, 2026

Claude Code subagent คือเซสชัน Claude แยกต่างหากที่ agent หลักสร้างขึ้นสำหรับงานเฉพาะอย่าง จากนั้นจึงนำผลลัพธ์กลับไปรวมกับงานของคุณ สัปดาห์ที่แล้วฉันได้ส่งมันออกไปสามตัวแบบขนานเพื่อแยกการทำ refactor ออกเป็นส่วนของ schema, API, และ tests และพวกมันก็เสร็จก่อนที่เซสชันยาวๆ ครั้งเดียวจะวางแผนเสร็จเสียอีก บทความนี้ครอบคลุมวิธีการกำหนดและส่ง subagents รูปแบบการจัดระเบียบ (orchestration patterns) ที่ฉันใช้เพื่อจำลองทีมขนาดเล็ก และขีดเส้นที่บอกว่าเมื่อไหร่ที่ subagents มีค่าใช้จ่ายมากกว่าสิ่งที่ประหยัดได้

คำตอบสั้นๆ: subagent ของ Claude Code คืออะไร?

subagent คือ instance ของ Claude ที่มี context window เป็นของตัวเอง มี system prompt เฉพาะ และชุดเครื่องมือที่จำกัด การทำงานหลักจะไม่สูญเสีย context เมื่อเรียกใช้ subagent เพราะ subagent ทำงานแบบแยกส่วนและส่งคืนเพียงสรุปเท่านั้น ลองนึกภาพว่าเป็นการมอบหมายงานให้เพื่อนร่วมทีมที่ไม่เคยขัดจังหวะหน้าจอของคุณเลย

กลไกอย่างเป็นทางการนั้นง่ายมาก คุณเพียงแค่ใส่ไฟล์ markdown ที่มี YAML frontmatter ลงใน .claude/agents/ และ Claude Code สามารถเรียกใช้ผ่าน Task tool ได้เมื่องานที่ทำตรงกับคำอธิบายของมัน sub-agents documentation คือแหล่งข้อมูลความจริงสำหรับ field ต่างๆ และ Claude Code repo จะติดตามการเปลี่ยนแปลงรูปแบบ

คำจำกัดความของ subagent ขั้นต่ำมีลักษณะดังนี้:

---
name: migration-writer
description: Writes and runs database migrations for this repo. Use for schema changes.
tools: Read, Edit, Bash
model: inherit
---
You are a migration specialist. Always check existing migrations first, never drop columns without a confirmation step, and run the migration against the local DB before reporting done.

เมื่อไฟล์นั้นมีอยู่แล้ว ฉันจะขอให้ main agent ว่า "use the migration-writer subagent to add the orders table" และมันก็จะส่ง scoped worker ออกไปแทนที่จะทำแบบสุ่มใน inline การระบุบรรทัด model: inherit ช่วยรักษาต้นทุนและคุณภาพให้อยู่ในระดับเดียวกับ main session; การกำหนด model ที่ราคาถูกกว่า เช่น haiku ให้กับ subagent ที่เน้นการอ่านเป็นเครื่องมือที่สำคัญเมื่อคุณเรียกใช้หลายตัว

ควรใช้ subagent เมื่อใด แทนที่จะใช้เซสชันเดียว?

ควรใช้ subagent เมื่องานนั้นเป็นแบบ รันยาว (long-running), ต้องอาศัยบริบทมาก (context-heavy), หรือ ต้องการชุดเครื่องมือที่คุณไม่ต้องการให้อยู่ในเซสชันหลัก ให้คงไว้ในเซสชันเดียวเมื่องานมีขนาดเล็ก, มีความเชื่อมโยงอย่างแน่นหนากับสิ่งที่คุณกำลังทำอยู่แล้ว, หรือต้องการการโต้ตอบไปมาที่กระชับ

ผมใช้ subagents สำหรับงานที่หากทำในเซสชันหลักอาจทำให้บริบทของผมสกปรกด้วย logs, การอ่านข้อมูลขนาดใหญ่, หรือการลองผิดลองถูก การตรวจสอบโค้ดเบสทั้งหมดที่ greps 200 files จึงเป็นตัวเลือกที่สมบูรณ์แบบ เพราะ subagent จะอ่านทั้งหมดและส่งสรุปมาให้สองย่อหน้า ในขณะที่เซสชันหลักของผมยังคงสะอาด

หากคุณยังใหม่กับตัว agent เอง บทความ Claude Code ultimate guide จะครอบคลุมพื้นฐานก่อนที่คุณจะเพิ่ม subagents เข้าไป

การเรียกใช้ subagent ใน Claude Code ทำได้อย่างไร?

การเรียกใช้ (Dispatching) สามารถทำได้สองวิธี ตัวแทนหลัก (main agent) สามารถเรียกใช้ Task tool ได้ด้วยตัวเองเมื่องานนั้นตรงกับคำอธิบายของ subagent หรือคุณสามารถระบุชื่อมันอย่างชัดเจนใน prompt ของคุณก็ได้ ผมชอบการระบุชื่อมากกว่า เพราะบางครั้งการ dispatch แบบโดยนัยอาจข้าม subagent ที่ผมต้องการไปได้

ตัวอย่างรูปแบบที่ผมใช้เป็นประจำมีดังนี้:

• "ให้ใช้ code-reviewer subagent กับ diff ใน branch นี้ แล้วนำข้อเสนอแนะของมันไปใช้"
• "ให้เรียกใช้ migration-writer เพื่อเพิ่มคอลัมน์ users.email_verified และเรียกใช้ test-writer เพื่อครอบคลุมส่วนนั้น รันทั้งสองตัว"
• "เรียกใช้ api-docs subagent กับ src/routes/ และส่งคืนเฉพาะโครงร่าง (skeleton) ของ OpenAPI"

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

รูปแบบที่ฉันใช้สำหรับเวิร์กโฟลว์ที่เหมือนทีมงาน

เคล็ดลับคือการคัดลอกวิธีการแบ่งงานของทีมจริง แล้วแมปแต่ละบทบาทไปยัง subagent นี่คือรูปแบบที่ฉันกลับมาใช้ซ้ำๆ

วิจัยก่อน แล้วจึงขยายผล (fan out) ฉันส่ง subagent หนึ่งตัวไปรวบรวมบริบท อ่านสรุปของมัน จากนั้นจึงส่ง subagent สำหรับการใช้งานหลายตัวไปยัง interface ที่ใช้ร่วมกัน สิ่งนี้สะท้อนถึง tech lead ที่กำหนดขอบเขตงานก่อนที่จะแจก ticket

สร้างโดยอิงตามสัญญา (contract) กำหนด API หรือ component props ก่อน จากนั้นจึงรัน backend subagent และ frontend subagent แบบขนานกันโดยยึดตามสัญญานั้น ทั้งสองตัวไม่บล็อกซึ่งกันและกัน และความขัดแย้งก็เกิดขึ้นได้ยากเพราะพวกมันแตะไฟล์ที่แตกต่างกัน

การตรวจสอบในฐานะบทบาทแยกต่างหาก (separate role) ฉันเก็บ code-reviewer subagent ที่มีเพียงเครื่องมือสำหรับอ่านเท่านั้น หลังจากมีการเปลี่ยนแปลงที่ไม่เล็กน้อยใดๆ ฉันจะรันมันเทียบกับ diff การจำกัดเครื่องมือของมันหมายความว่ามันไม่สามารถแก้ไขได้จริง ซึ่งทำให้การตรวจสอบมีความซื่อสัตย์

สำหรับเวิร์กโฟลว์ที่ทำซ้ำได้แบบนี้ ให้จับคู่ subagents กับ Claude Code skills: skill จะทำการเข้ารหัสขั้นตอน และ subagents จะทำงานแยกส่วน และหาก subagent ต้องการข้อมูลภายนอก ก็ให้เชื่อมต่อกับ MCP server ตามที่ Claude Code MCP integration guide อธิบาย

ตัวอย่างการทำงานจริง: คำสั่งซื้อและการชำระเงิน

เมื่อเดือนที่แล้ว ฉันได้แยกฟีเจอร์ orders-plus-payments ออกเป็นสาม subagents โดยยึดตาม typed contract สัญญาดังกล่าวคือ TypeScript interface เดียวสำหรับ 'Order' ที่มี 'status', 'totalCents', และ 'paymentId' ฉันได้ส่ง: backend subagent เพื่อใช้งานการสร้างคำสั่งซื้อและการเปลี่ยนสถานะ; payments subagent เพื่อเชื่อมต่อ Stripe call และจัดเก็บ 'paymentId'; และ test subagent เพื่อครอบคลุม happy path และกรณีขอบของการคืนเงิน ทั้งสามตัวแตะไฟล์ที่แตกต่างกัน ดังนั้นการ merge จึงเป็นเพียงการ copy-paste ที่สะอาด 3 ครั้ง แทนที่จะเป็นการทำ session แก้ไขความขัดแย้ง การรันทั้งหมดใช้เวลา 14 นาที; งานเดียวกันในเซสชันแบบอนุกรมครั้งเดียวเมื่อสัปดาห์ก่อนใช้เวลา 41 นาที เพราะ context เดียวกันต้องโหลด Stripe docs ซ้ำๆ

คุณจะจัดการงานแบบขนานโดยไม่สูญเสียบริบทได้อย่างไร?

เซสชันหลักคือผู้ประสานงานของคุณ หน้าที่ของมันคือการแบ่งงาน การแจกพร้อมท์ที่มีขอบเขต และการรวบรวมผลลัพธ์กลับเข้าด้วยกัน ให้รักษาผู้ประสานงานให้กระชับและปล่อยให้เอเจนต์ย่อยรับภาระการอ่านที่หนัก

การรันแบบขนานทั่วไปสำหรับฉันมีลักษณะดังนี้:

1. เขียนสัญญาและขอบเขตไฟล์ในเซสชันหลัก
2. ส่งเอเจนต์ย่อย 2 ถึง 4 ตัว โดยแต่ละตัวรับผิดชอบส่วนงาน (slice) หนึ่งส่วน และมีเงื่อนไขความสำเร็จที่ชัดเจน
3. อ่านสรุปผลแต่ละรายการเมื่อได้รับ ไม่ใช่ระหว่างการรัน
4. รวมในเซสชันหลัก โดยที่คุณต้องแก้ไขส่วนที่ต่อกัน (seams) ด้วยตัวเอง
5. รันเอเจนต์ย่อยทดสอบเป็นตัวสุดท้ายกับผลลัพธ์ที่รวมแล้ว

ความเป็นขนานจะคุ้มค่าก็ต่อเมื่อส่วนงานเหล่านั้นเป็นอิสระอย่างแท้จริง หากเอเจนต์ย่อยสองตัวแก้ไข schema.prisma ทั้งคู่ นั่นหมายความว่าคุณไม่ได้แบ่งงาน แต่คุณได้สร้างปัญหาการรวม (merge problem) กำหนดขอบเขตที่ไฟล์และสัญญา จากนั้นบังคับใช้ในพร้อมท์

เมื่อไหร่ที่ subagents เพิ่มภาระ (overhead) มากกว่าที่ประหยัดได้?

Subagents เพิ่ม latency, tokens, และค่าใช้จ่ายในการประสานงาน การส่งต่อสรุป (summary handoff) จะทำให้รายละเอียดสูญหาย ดังนั้นสิ่งใดที่ต้องการความต่อเนื่องในระดับลึกจึงไม่เหมาะสม ควรซื่อสัตย์เกี่ยวกับข้อแลกเปลี่ยนนี้ก่อนที่จะใช้งานพวกมัน

ครั้งหนึ่งฉันได้ทำการ benchmark บน feature branch: subagent หนึ่งตัวต่อ microservice เทียบกับการทำในเซสชันเดียวตามลำดับ สำหรับบริการที่เชื่อมโยงกันหลวมๆ 5 ตัว การทำงานแบบขนาน (parallel) ชนะไปประมาณ 40 percent ในแง่ของ wall-clock time แต่สำหรับสามบริการที่ใช้ data model ร่วมกัน เซสชันเดียวเร็วกว่า เพราะการรวมและอธิบายซ้ำได้กินกำไรจากการทำแบบขนานไป

บทเรียนคือ: การทำแบบขนานจะตอบแทนความเป็นอิสระ แต่ลงโทษการเชื่อมโยง (coupling) หากส่วนย่อยของคุณแชร์ state อย่าทำการ parallelize พวกมัน

ข้อผิดพลาดทั่วไปมีอะไรบ้าง?

• การใช้ subagents มากเกินไป ฉันจำกัดจำนวนครั้งในการรันไว้ที่สามถึงห้าตัว เกินกว่านั้น ต้นทุนในการประสานงานจะมากกว่าผลประโยชน์จากการทำงานแบบขนาน
• คำสั่งที่คลุมเครือ "Fix the auth" ล้มเหลว แต่ "Add a JWT refresh endpoint at /auth/refresh, returning { token }, with a test" สำเร็จ
• ไม่มีเกณฑ์ความสำเร็จ ระบุว่าสิ่งที่ทำเสร็จแล้วหมายถึงอะไร "Migration applied locally and rollback tested" ดีกว่า "handle the schema"
• ชุดเครื่องมือที่ไม่ถูกต้อง ให้เครื่องมือสำหรับรีวิวที่อ่านได้อย่างเดียว และให้ deploy agent คำสั่งที่แน่นอนที่มันต้องการ ไม่ใช่คำสั่งที่กว้างกว่านั้น
• การเพิกเฉยต่อความล้มเหลว หาก subagent ส่งคืนข้อผิดพลาด ให้อ่านมัน การลองซ้ำแบบไม่ดูอะไรเลยจะเผาผลาญ tokens และซ่อนปัญหาจริง
• การข้ามขั้นตอนการรวม (merge) subagents ส่งคืนผลลัพธ์ แต่คุณยังคงต้องรับผิดชอบในการรวมระบบ จัดสรรเวลาจริงสำหรับสิ่งนี้

ข้อผิดพลาดที่แพงที่สุดคือการปฏิบัติต่อ subagents ว่าเป็นความสามารถในการทำงานแบบขนานฟรีสำหรับทุกสิ่ง พวกมันคือนักทำงานที่มีขอบเขตอยู่เบื้องหลังขอบเขตสรุป (summary boundary) และขอบเขตนั้นมีค่าใช้จ่าย

สรุป

Subagents เปลี่ยน Claude Code ให้เป็นสิ่งที่ให้ความรู้สึกเหมือนทีมขนาดเล็ก: ผู้ประสานงานที่กระชับซึ่งส่งมอบ worker ที่มีขอบเขตเฉพาะ โดยแต่ละตัวจะนำบริบทของตัวเองและรายงานผลลัพธ์กลับมา กำหนดพวกมันใน .claude/agents/, ส่งมอบด้วย Task tool, และรักษาเซสชันหลักของคุณให้สะอาดโดยการย้ายงานที่ต้องอ่านหนักๆ (heavy reads) และบทบาทที่ซ้ำๆ เข้าไปใน subagents

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

ข้อควรระวังที่สำคัญอย่างหนึ่งคือ: subagents จะเพิ่ม throughput ไม่ใช่ judgment พวกมันสามารถสร้างสิ่งที่ผิดพลาดในลักษณะขนาน ข้ามบริบทที่แยกจากกันสี่แห่งได้อย่างง่ายดาย งานประสานงาน, การกำหนดสัญญา, และการตรวจสอบขั้นสุดท้ายยังคงเป็นหน้าที่ของคุณ ดังนั้น leverage จึงจะปรากฏก็ต่อเมื่อส่วนย่อยเหล่านั้นเป็นอิสระอย่างแท้จริงและเกณฑ์ความสำเร็จมีความแม่นยำ หากคุณต้องการข้อมูลพื้นฐานที่ลึกกว่าเกี่ยวกับโปรโตคอลที่ขับเคลื่อนการเชื่อมโยงเครื่องมือเหล่านี้ MCP explainer เป็นแหล่งอ่านที่ดีถัดไป และ Claude Code docs ได้กล่าวถึงการตั้งค่าที่ฉันไม่ได้กล่าวซ้ำในที่นี้

ที่มาของรูปภาพ

• ทีมพัฒนาที่ทำงานด้วยกันที่คอมพิวเตอร์ในสำนักงานเทคโนโลยีสมัยใหม่ — photo by Rebrand Cities on Pexels
• รหัสโปรแกรมที่เต็มไปด้วยสีสันบนหน้าจอคอมพิวเตอร์ — photo by inna mykytas on Pexels
• นักพัฒนาที่กำลังเขียนโค้ดบนแล็ปท็อปหน้าจอหลายจอ — photo by Christina Morillo on Pexels
• โปรแกรมเมอร์สองคนที่กำลังตั้งใจเขียนโค้ดเคียงข้างกันในสำนักงานสมัยใหม่ — photo by Rebrand Cities on Pexels