คู่มือสร้างซับเอเจนต์โค้ด Claude แบบกำหนดเอง

มีขีดจำกัดที่คุณจะเจอในการทำงานโค้ดด้วย AI ครั้งเดียว นั่นคือขอบเขตบริบท (context window) ลองนึกภาพการสนทนาที่อัดแน่นไปด้วยการปรับโครงสร้างโค้ดครั้งใหญ่ ผลลัพธ์การทดสอบสามรอบ และการรีวิวโค้ด แล้วเอเจนต์ก็จะเริ่มสับสน Claude Code subagents คือทางออก แทนที่จะให้เอเจนต์เดียวจัดการทุกอย่างในบริบทเดียว คุณสามารถแยกย่อยเป็นพนักงานเฉพาะทาง แต่ละคนมีหน้าต่างบริบท คำสั่ง และสิทธิ์การใช้งานเครื่องมือของตัวเอง พวกเขาทำงานเดียว ส่งผลลัพธ์กลับมา และทำให้เธรดหลักสะอาดอยู่เสมอ

นี่คือคู่มือการสร้างแบบลงมือทำจริง อธิบายวิธีการสร้าง subagent แบบกำหนดเองในรูปแบบไฟล์การตั้งค่า แต่ละฟิลด์ในส่วนหัว (frontmatter) ทำหน้าที่อะไร Claude ตัดสินใจมอบหมายงานอย่างไร และวิธีการตั้งค่าที่ใช้งานได้จริงที่เอเจนต์หนึ่งรีวิวโค้ดในขณะที่อีกเอเจนต์หนึ่งเขียนการทดสอบแบบขนาน หากคุณต้องการภาพรวมแนวคิดก่อน บทความของเราเรื่อง Claude Code sub-agents คืออะไรและทำไมถึงสำคัญ จะครอบคลุมพื้นฐานทั้งหมด ที่นี่เราเน้นการสร้างมันขึ้นมา และมุมมองการทดสอบ API ที่เปลี่ยน subagent สำหรับทดสอบให้กลายเป็นขั้นตอนการตรวจสอบที่คุณเชื่อถือได้

TL;DR

คุณสร้าง Claude Code subagent ได้โดยการเขียนไฟล์ Markdown ใน .claude/agents/ พร้อมกับส่วนหัว YAML: name, description ที่บอก Claude ว่าเมื่อไหร่ควรมอบหมายงาน, tools allowlist ที่เป็นทางเลือก, และ model ที่เป็นทางเลือก เนื้อหาของไฟล์จะกลายเป็น system prompt ของ subagent แต่ละ subagent ทำงานในหน้าต่างบริบทของตัวเองพร้อมเครื่องมือของตัวเอง คุณจึงได้รับการแยกบริบท การทำงานแบบขนาน และความเชี่ยวชาญเฉพาะทาง Claude มอบหมายงานโดยอัตโนมัติตาม description หรือคุณสามารถเรียกใช้ subagent โดยระบุชื่อก็ได้ เอกสารอ้างอิงอย่างเป็นทางการคือ Claude Code subagents docs

Subagents ใน 60 วินาที

Subagent คืออินสแตนซ์เอเจนต์แยกต่างหากที่เอเจนต์หลักของ Claude Code มอบหมายงานให้ เอเจนต์หลักคือหัวหน้าวิศวกร ส่วน subagent คือผู้เชี่ยวชาญที่ถูกดึงเข้ามา ผู้เชี่ยวชาญจะทำงานในการสนทนาของตัวเอง โดยมีหน้าต่างบริบทและ system prompt ของตัวเอง จากนั้นก็ส่งคืนเฉพาะผลลัพธ์เท่านั้น มีคุณสมบัติสามประการที่ทำให้พวกเขาน่าตั้งค่า:

• หน้าต่างบริบทของตัวเอง Subagent เริ่มต้นใหม่พร้อมกับงานที่ได้รับมอบหมายเท่านั้น ดังนั้นเธรดหลักจึงไม่เคยเต็มไปด้วยการทำงานระดับกลาง
• System prompt ที่กำหนดเอง คุณสามารถกำหนดพฤติกรรมของมันได้: ผู้รีวิวที่ค้นหาช่องโหว่ด้านความปลอดภัย, ผู้เขียนทดสอบที่ปฏิบัติตามแนวปฏิบัติของคุณ
• เครื่องมือที่กำหนดค่าได้ คุณให้เครื่องมือที่ subagent แต่ละตัวต้องการเท่านั้น ดังนั้นผู้รีวิวจะไม่สามารถเขียนโค้ดได้ และผู้รันการทดสอบจะได้รับสิทธิ์เข้าถึง shell เท่าที่จำเป็นเท่านั้น

นั่นคือแนวคิดพื้นฐาน ภาพรวมแนวคิด จะเจาะลึกถึงเหตุผลเพิ่มเติม ส่วนที่เหลือของคู่มือนี้เกี่ยวกับการสร้างมันขึ้นมา ซึ่งเป็นหลักการเดียวกับที่อยู่เบื้องหลัง Claude Code agent harness ที่นำมาใช้ในระดับของแต่ละงาน

ทำไมต้องใช้ Subagents

มีสามเหตุผล และพวกมันทำงานร่วมกัน

การแยกบริบท (Context isolation) เซสชันที่ยาวนานจะเสื่อมประสิทธิภาพลงเมื่อหน้าต่างบริบทเต็ม การอ่านไฟล์ทุกครั้ง การรันการทดสอบทุกครั้ง และการแตกประเด็นทุกครั้งจะกินงบประมาณและทำให้การโฟกัสลดลง การมอบหมายงานใหญ่ๆ ให้กับ subagent จะเก็บงานทั้งหมดนั้นไว้ในบริบทของ subagent ไม่ใช่บริบทหลัก เอเจนต์หลักจะได้รับสรุปที่สะอาดแทนที่จะเป็น 50,000 โทเค็นของข้อมูลรบกวนระดับกลาง การแยกนี้ยังเป็นตัวช่วยลดต้นทุนด้วย เนื่องจากคุณไม่ต้องลากบริบทที่เทอะทะไปทุกครั้ง บันทึกของเราเกี่ยวกับ การลดต้นทุนโทเค็นของเอเจนต์ ได้กล่าวถึงเรื่องเศรษฐศาสตร์ไว้แล้ว

การทำงานแบบขนาน (Parallelism) งานอิสระไม่จำเป็นต้องรันทีละงาน เอเจนต์หลักสามารถส่ง subagent หลายตัวพร้อมกันได้: รีวิวโมดูลนี้พร้อมกับทดสอบโมดูลนั้นในขณะที่จัดทำเอกสารโมดูลที่สาม เวลาที่ใช้จริงจะลดลงเหลือเวลาของงานเดี่ยวที่ช้าที่สุด แทนที่จะเป็นผลรวม Dynamic workflows ของ Claude Code ผลักดันสิ่งนี้ให้ถึงขีดจำกัด โดยแยกงานออกเป็น subagent แบบขนานหลายร้อยตัวจากเซสชันเดียว

ความเชี่ยวชาญเฉพาะทาง (Specialization) เอเจนต์ทั่วไปทำงานได้ดีในทุกเรื่องแต่ไม่เก่งเป็นพิเศษในเรื่องใดเรื่องหนึ่ง Subagent ที่มี system prompt ที่เข้มงวดและเครื่องมือที่เหมาะสมจะเก่งกาจในเรื่องเดียว ผู้รีวิวที่ได้รับคำสั่งให้เป็นปรปักษ์จะพบข้อผิดพลาดได้มากกว่าผู้เชี่ยวชาญทั่วไปที่มองผ่าน diff ผู้เขียนทดสอบที่รู้จักสไตล์การยืนยันของคุณจะสร้างการทดสอบที่คุณจะเก็บไว้ใช้จริง คุณสร้างทีมผู้เชี่ยวชาญขนาดเล็กแทนที่จะเป็นผู้เชี่ยวชาญทั่วไปที่ทำงานหนักเกินไปคนเดียว

วิธีสร้าง subagent แบบกำหนดเอง

Subagents เป็นไฟล์ Markdown ธรรมดา วางไฟล์ระดับโปรเจกต์ไว้ใน .claude/agents/ และไฟล์ส่วนตัวไว้ใน ~/.claude/agents/ แต่ละไฟล์มี YAML frontmatter และเนื้อหาที่จะกลายเป็น system prompt ของ subagent

นี่คือตัวอย่างผู้รีวิวโค้ด:

---
name: code-reviewer
description: Reviews code changes for bugs, security issues, and convention violations. Use after writing or editing code.
tools: Read, Grep, Glob
model: sonnet
---

You are a senior code reviewer. When given a diff or a set of files:

1. Look for correctness bugs, security holes, and missed edge cases.
2. Check that the code matches the project's existing conventions.
3. Report only high-confidence issues, ranked by severity.

Be specific. Cite file and line. Do not rubber-stamp.

ฟิลด์ frontmatter:

• name — ตัวระบุที่คุณใช้เพื่อเรียกใช้
• description — นี่คือส่วนสำคัญ Claude จะอ่านมันเพื่อตัดสินใจว่าจะมอบหมายงานโดยอัตโนมัติเมื่อใด เขียนเป็นตัวกระตุ้นที่ชัดเจน (“ใช้หลังจากเขียนโค้ด”) ไม่ใช่ป้ายกำกับที่คลุมเครือ
• tools — รายการที่อนุญาต ละเว้นเพื่อรับเครื่องมือของเอเจนต์หลัก หรือระบุเครื่องมือที่ต้องการจำกัด ผู้รีวิวที่ไม่สามารถเขียนโค้ดได้จะไม่สามารถเปลี่ยนแปลงโค้ดโดยไม่ตั้งใจ
• model — สามารถกำหนดโมเดลที่ใช้ได้ ใช้โมเดลที่ถูกกว่าและเร็วกว่าสำหรับ subagent ที่ทำงานเชิงกล และโมเดลที่แข็งแกร่งกว่าสำหรับการให้เหตุผลที่ซับซ้อน

เนื้อหาคือ system prompt นี่คือที่ที่ความเชี่ยวชาญเฉพาะทางอยู่ ดังนั้นจงเขียนเหมือนกับที่คุณจะสรุปให้พนักงานใหม่ฟัง: ทำอะไร, จัดลำดับความสำคัญอะไร, หลีกเลี่ยงอะไร การจับคู่กับไฟล์ design.md หรือ AGENTS.md ของโปรเจกต์จะช่วยให้ subagent รู้จักแนวปฏิบัติของคุณโดยไม่ต้องทำซ้ำในทุกไฟล์

วิธีเรียกใช้ Subagents

มีสองวิธีที่ subagent ทำงาน

การมอบหมายงานอัตโนมัติ Claude จะอ่านฟิลด์ description ของ subagent ที่พร้อมใช้งานทั้งหมด และมอบหมายงานด้วยตัวเองเมื่อมีงานตรงกัน เมื่อแก้ไขไฟล์เสร็จ เอเจนต์หลักอาจส่ง diff ไปยัง code-reviewer ของคุณโดยไม่ต้องสั่ง เพราะ description ระบุว่า "ใช้หลังจากเขียนโค้ด" คำอธิบายที่ดีนำไปสู่การมอบหมายงานที่ดี

การเรียกใช้งานโดยตรง คุณยังสามารถระบุชื่อได้โดยตรง: "ใช้ subagent code-reviewer ในการเปลี่ยนแปลงในโมดูล orders" นี่คือวิธีที่คุณบังคับใช้ผู้เชี่ยวชาญเฉพาะเมื่อคุณไม่ต้องการให้การมอบหมายงานเป็นไปโดยบังเอิญ

ไม่ว่าจะด้วยวิธีใด subagent จะทำงานในบริบทของตัวเอง ทำงาน และส่งคืนผลลัพธ์ไปยังเธรดหลัก คุณจะเห็นการส่งมอบงานเกิดขึ้น และคุณสามารถกำหนดได้ว่าจะให้รายละเอียดปรากฏมากน้อยเพียงใด สำหรับการเชื่อมโยง subagent เข้าด้วยกันเป็นลำดับที่กำหนดได้และทำซ้ำได้ การใช้ slash command และ SDK จะให้การควบคุมที่มากกว่าการใช้ prompting แบบเฉพาะกิจ ภาพรวมของ Claude Code ครอบคลุมพื้นผิวการกำหนดค่า

Subagents เทียบกับ Agent SDK เทียบกับ Dynamic Workflows

สิ่งเหล่านี้มีความทับซ้อนกัน ดังนั้นนี่คือเวลาที่แต่ละอย่างเหมาะสม

Subagents เป็นตัวเลือกในเซสชันแบบสนทนา: คุณกำลังทำงานใน Claude Code และต้องการผู้เชี่ยวชาญหนึ่งหรือสองคน เมื่อคุณต้องการลูปแบบโปรแกรมที่ทำงานตามกำหนดเวลาโดยไม่มีมนุษย์อยู่ คุณจะเปลี่ยนไปใช้ Claude Agent SDK และเขียนการจัดการด้วยตัวเอง หากคุณกำลังชั่งน้ำหนักระหว่างตัวเลือกแบบโฮสต์กับแบบสร้างเอง การเปรียบเทียบ managed agents vs Agent SDK ของเราจะอธิบายข้อดีข้อเสียทั้งสองแบบ ทั้งสามไม่ใช่คู่แข่งกันมากนัก แต่เป็นเหมือนขั้นบันไดจากแบบโต้ตอบไปสู่แบบอัตโนมัติเต็มรูปแบบ

ตัวอย่างการใช้งานจริง: การรีวิวและการเขียนการทดสอบแบบขนาน

ลองนำมาใช้ร่วมกัน สมมติว่าคุณเพิ่งให้เอเจนต์หลักติดตั้งใช้งาน orders endpoint ใหม่ คุณต้องการให้มีการรีวิวและทดสอบ และไม่มีเหตุผลที่จะต้องทำตามลำดับ

กำหนด subagent สองตัว: code-reviewer ตามที่กล่าวไว้ข้างต้น และ test writer:

---
name: api-test-writer
description: Writes API test cases for new or changed endpoints. Use after an endpoint is implemented.
tools: Read, Grep, Write, Bash
model: sonnet
---

You write API tests against the project's OpenAPI spec.

1. Read the spec and the endpoint implementation.
2. Write tests covering success, validation errors, and auth.
3. Assert status codes and validate response bodies against the schema.
4. Run the suite and report pass/fail with reasons.

ตอนนี้เอเจนต์หลักจะส่งงานทั้งสองพร้อมกัน: ผู้รีวิวจะอ่าน diff ในขณะที่ผู้เขียนทดสอบจะอ่าน spec และเขียน coverage ผู้เชี่ยวชาญสองคน สองบริบทแยกต่างหาก ทำงานแบบขนาน เธรดหลักยังคงสะอาดและได้รับสรุปสองรายการ: รายงานการรีวิวและผลการทดสอบ

ผลการทดสอบนั่นแหละคือส่วนที่ทำให้สิ่งนี้เชื่อถือได้ Subagent ที่รัน API suite ของคุณคือด่านการตรวจสอบ (verification gate) ซึ่งเป็นการตรวจสอบที่แน่นอนที่บอกว่า endpoint ทำงานได้จริงหรือไม่ ไม่ใช่แค่ดูเหมือนจะเสร็จสิ้น นี่คือแนวคิดหลักจาก coding agent loops: ความมั่นใจของเอเจนต์เองไม่นับ การตัดสินของด่านการตรวจสอบต่างหากที่สำคัญ เชื่อมต่อ subagent สำหรับทดสอบเข้ากับแพลตฟอร์มทดสอบ API จริง แล้วผลตอบรับจะคมชัดขึ้น ทีมที่ใช้ Apidog จะชี้ subagent ไปที่สถานการณ์ทดสอบของ Apidog เพื่อให้ทุกการตอบสนองได้รับการตรวจสอบตาม schema และกำหนดเส้นทางการเรียกใช้ endpoint สดของเอเจนต์ผ่าน Apidog AI agent debugger เพื่อให้มันตรวจสอบคำขอเหมือนกับที่ผู้ทดสอบที่เป็นมนุษย์ทำ นำการตั้งค่าเดียวกันนั้นมาวนซ้ำ คุณก็จะได้เวิร์กโฟลว์อัตโนมัติที่เราสร้างขึ้นใน Claude workflows ที่ทำงานได้โดยไม่มีคุณ ดาวน์โหลด Apidog หากคุณต้องการให้ด่านการทดสอบสามารถตรวจสอบ schema ได้ทันที

แนวทางปฏิบัติที่ดีที่สุด

นิสัยบางอย่างช่วยให้ subagent มีประโยชน์แทนที่จะเกิดความวุ่นวาย

• หนึ่งความรับผิดชอบต่อ subagent หนึ่งตัว ผู้รีวิวรีวิว ผู้ทดสอบทดสอบ อย่าสร้าง subagent ที่ทำได้ทุกอย่าง นั่นก็แค่เอเจนต์หลักที่มีขั้นตอนพิเศษเพิ่มขึ้นมา
• เขียนคำอธิบายสำหรับการมอบหมายงาน ฟิลด์ description คือวิธีที่ Claude ตัดสินใจจะเรียก subagent ของคุณ ทำให้เป็นตัวกระตุ้นที่ชัดเจน ไม่ใช่แค่ชื่อเรื่อง "ใช้หลังจากแก้ไขโค้ดเพื่อรีวิวหาข้อบกพร่อง" ดีกว่า "Code reviewer"
• ให้สิทธิ์น้อยที่สุด (least privilege) ระบุเฉพาะเครื่องมือที่ subagent แต่ละตัวต้องการ ผู้รีวิวที่ไม่มีสิทธิ์เขียนไม่สามารถเปลี่ยนแปลงสิ่งที่กำลังรีวิวได้ สิ่งนี้สำคัญยิ่งขึ้นเมื่อการทำงานเป็นแบบอัตโนมัติ
• กำหนดโมเดลที่เหมาะสมสำหรับแต่ละงาน Subagent ที่ทำงานเชิงกลสามารถทำงานบนโมเดลที่เร็วกว่าและถูกกว่าได้ สงวนโมเดลที่แข็งแกร่งที่สุดไว้สำหรับ subagent ที่ทำงานต้องใช้การให้เหตุผลที่ซับซ้อน สิ่งนี้ควบคุมทั้งความเร็วและต้นทุน
• ส่งคืนผลลัพธ์ที่มีโครงสร้าง ขอให้ subagent รายงานผลในรูปแบบที่สอดคล้องกัน (เช่น คำตัดสิน รายการปัญหา หรือการผ่าน/ไม่ผ่าน) ผลลัพธ์ที่มีโครงสร้างจะง่ายต่อการที่เอเจนต์หลักและคุณจะนำไปดำเนินการ
• อย่าซ้อนกันมากเกินไป การที่ subagent เรียก subagent ที่เรียก subagent ต่อไปเรื่อยๆ ทำให้ติดตามยากและมีค่าใช้จ่ายสูง รักษาระดับลำดับชั้นให้ตื้น

สิ่งเหล่านี้สะท้อนรูปแบบการเชื่อมต่อที่เราครอบคลุมใน agentic workflow tool wiring และยังคงใช้ได้ไม่ว่าคุณจะมี subagent สองตัวหรือยี่สิบตัว

เมื่อใดควรใช้ subagent (และเมื่อใดไม่ควรใช้)

Subagents เป็นเครื่องมือ ไม่ใช่ค่าเริ่มต้น การรู้ว่าเมื่อใดควรข้ามการใช้งานจะช่วยให้การตั้งค่าของคุณรวดเร็วและประหยัด

ควรใช้ subagent เมื่อภารกิจ มีขอบเขตจำกัด เป็นอิสระ และมีข้อมูลรบกวนมาก (bounded, independent, and noisy) การรีวิวโค้ดมีขอบเขตจำกัด (มีจุดสิ้นสุดที่ชัดเจน) เป็นอิสระ (ไม่ต้องการสถานะการทำงานของเธรดหลัก) และมีข้อมูลรบกวนมาก (สร้างการอ่านข้อมูลระดับกลางจำนวนมากที่คุณไม่ต้องการให้มาขัดขวางบริบทหลัก) เช่นเดียวกับการเขียนชุดทดสอบ การจำลองข้อบกพร่อง หรือการตรวจสอบโมดูลเพื่อหาช่องโหว่ด้านความปลอดภัย นี่คือการมอบหมายงานที่สมบูรณ์แบบ: แยกงานออกไป ได้รับคำตัดสินกลับมา

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

หลักการง่ายๆ: มอบหมายงานที่สมบูรณ์ในตัวเองมากพอที่จะอธิบายได้ในย่อหน้าเดียว และมีคุณค่ามากพอที่จะรันแบบขนานได้ การรีวิวและทดสอบ endpoint ใหม่นั้นเหมาะสม การแก้ไขคำผิดไม่จำเป็นต้องใช้ เมื่อคุณขยายไปสู่ subagent จำนวนมากที่ทำงานพร้อมกัน รูปแบบการจัดการใน dynamic workflows จะเข้ามามีบทบาท แต่การตัดสินใจเดียวกันยังคงใช้ได้: ทำงานที่เป็นอิสระแบบขนาน รักษาการทำงานที่สัมพันธ์กันไว้ด้วยกัน

ข้อผิดพลาดที่พบบ่อย

• คำอธิบายที่คลุมเครือ หาก description เป็นเพียงป้ายกำกับ การมอบหมายงานอัตโนมัติจะไม่ทำงานตามที่คุณคาดหวัง จงเขียนให้เป็นตัวกระตุ้นการใช้งาน
• Subagent ตัวเดียวที่ทำงานหนักเกินไป การยัดทุกงานลงใน subagent ตัวเดียวจะทำลายประโยชน์ของความเชี่ยวชาญเฉพาะทาง แบ่งตามความรับผิดชอบ
• การรับมรดกเครื่องมือทั้งหมดโดยค่าเริ่มต้น การไม่กำหนด tools จะทำให้ subagent ได้รับทุกอย่างที่เอเจนต์หลักมี ดีสำหรับงานที่เชื่อถือได้ แต่เสี่ยงสำหรับสิ่งที่เป็นอัตโนมัติ จงเลือกอนุญาตเครื่องมืออย่างรอบคอบ
• ไม่มี subagent สำหรับการตรวจสอบ การตั้งค่ารีวิวและสร้างที่ไม่มีด่านทดสอบจะส่งโค้ดที่ดูเหมือนถูกต้องแต่เสียเมื่อเจอกับสถานการณ์ขอบ (edges) จงรวม subagent ที่รันการทดสอบจริงเสมอ
• การปฏิบัติต่อ subagent เหมือน SDK Subagents ถูกเรียกใช้โดยโมเดลและทำงานในเซสชัน หากคุณต้องการการควบคุมการทำงานที่เป็นลำดับที่แน่นอนตามกำหนดเวลา นั่นคือหน้าที่ของ Agent SDK ไม่ใช่การใช้ subagent จำนวนมาก

หากคุณทำสิ่งเหล่านี้ได้อย่างถูกต้อง subagent จำนวนไม่กี่ตัวที่กำหนดขอบเขตมาอย่างดีจะเปลี่ยน Claude Code จากผู้ช่วยที่ยุ่งอยู่คนเดียวให้กลายเป็นทีมขนาดเล็กที่เน้นงานเฉพาะ Anthropic ในหัวข้อ building effective agents ได้ให้กรณีศึกษาที่กว้างขึ้น: โครงสร้างรอบโมเดลนั้นดีกว่าการใช้ prompt ที่ยาวกว่า

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

Claude Code subagent คืออะไร? คืออินสแตนซ์เอเจนต์แยกต่างหากที่เอเจนต์หลักของ Claude Code มอบหมายงานให้ subagent แต่ละตัวมีหน้าต่างบริบทของตัวเอง system prompt ที่กำหนดเอง และชุดเครื่องมือที่กำหนดค่าได้ มันทำงานเฉพาะและส่งคืนผลลัพธ์ ทำให้การสนทนาหลักสะอาด และช่วยให้คุณเรียกใช้ผู้เชี่ยวชาญแบบขนานได้

ฉันจะสร้าง Claude Code subagent ได้อย่างไร? สร้างไฟล์ Markdown ใน .claude/agents/ (สำหรับโปรเจกต์) หรือ ~/.claude/agents/ (สำหรับส่วนตัว) เพิ่ม YAML frontmatter ที่มี name, description, tools (ทางเลือก) และ model (ทางเลือก) จากนั้นเขียน system prompt ในเนื้อหา คำอธิบายจะบอก Claude ว่าเมื่อใดควรมอบหมายงานให้โดยอัตโนมัติ

Claude ตัดสินใจเลือก subagent ที่จะใช้อย่างไร? มันอ่านฟิลด์ description ของ subagent ที่พร้อมใช้งานแต่ละตัว และมอบหมายงานโดยอัตโนมัติเมื่อมีงานตรงกัน คุณยังสามารถเรียกใช้โดยตรงโดยระบุชื่อได้ เช่น "ใช้ subagent code-reviewer" คำอธิบายที่ชัดเจนในรูปแบบตัวกระตุ้นทำให้การมอบหมายงานอัตโนมัติเชื่อถือได้

ความแตกต่างระหว่าง subagent กับ Claude Agent SDK คืออะไร? Subagents เป็นแบบในเซสชันและถูกเรียกใช้โดยโมเดล: คุณกำลังทำงานใน Claude Code และมันดึงผู้เชี่ยวชาญเข้ามา Agent SDK เป็นแบบโปรแกรมที่คุณเขียนการไหลของการควบคุมในโค้ดสำหรับการทำงานที่แน่นอนหรือแบบอัตโนมัติ ใช้ subagent สำหรับความเชี่ยวชาญเฉพาะทางแบบโต้ตอบ ใช้ SDK สำหรับลูปตามกำหนดเวลา

Subagent สามารถทำงานแบบขนานได้หรือไม่? ได้ เอเจนต์หลักสามารถส่ง subagent หลายตัวพร้อมกันสำหรับงานที่เป็นอิสระ ดังนั้นการรีวิว การทดสอบ และการจัดทำเอกสารจึงเกิดขึ้นพร้อมกันแทนที่จะทำตามลำดับ สำหรับการกระจายงานขนาดใหญ่ dynamic workflows ของ Claude Code จะขยายสิ่งนี้ไปสู่ subagent ขนานหลายตัวในเซสชันเดียว

Subagent ช่วยในการทดสอบ API ได้อย่างไร? กำหนด subagent ที่เขียนและรันการทดสอบ API ของคุณกับ OpenAPI spec มันจะกลายเป็นด่านการตรวจสอบที่ตรวจสอบว่า endpoint ทำงานได้จริงหรือไม่ ไม่ใช่แค่ดูเหมือนจะเสร็จสิ้น การชี้ไปที่แพลตฟอร์มอย่าง Apidog ทำให้ผลตอบรับสามารถตรวจสอบ schema ได้ ดังนั้นทุกการตอบสนองจะได้รับการตรวจสอบตามสัญญา

บทสรุป

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

เริ่มต้นด้วยสองตัว: ผู้รีวิวและผู้ทดสอบ เขียนคำอธิบายที่รัดกุมเพื่อให้ Claude มอบหมายงานเอง ให้แต่ละตัวมีเครื่องมือเท่าที่จำเป็น และทำให้ผู้ทดสอบเป็นด่านตรวจสอบที่แท้จริงโดยชี้ไปยัง API suite ของคุณ สำหรับทุกสิ่งที่เกี่ยวข้องกับ endpoints Apidog ให้ schema เพื่อตรวจสอบ และ ดาวน์โหลด แล้วให้ subagent สำหรับทดสอบพิสูจน์ว่าโค้ดของคุณทำงานได้ก่อนที่คุณจะอ่าน diff เสียอีก