SubAgents ใน Claude Code คืออะไร? สิ่งที่คุณควรรู้

ตัวแทนย่อย (มักเขียน ตัวแทนย่อย or ตัวแทนย่อย) เป็นหนึ่งในความก้าวหน้าทางปฏิบัติที่ชัดเจนที่สุดในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์: ช่วยให้คุณสามารถจัดตั้งทีมผู้ช่วย AI เฉพาะทางขนาดเล็กภายในได้ รหัสคล็อดโดยแต่ละอันมีบทบาท เครื่องมือ และหน้าต่างบริบทเป็นของตัวเอง แนวคิดนี้เรียบง่ายแต่ทรงพลัง — แทนที่จะขอให้โมเดลทั่วไปแบบเดียวทำทุกอย่าง คุณกำหนดเอเจนต์ที่กะทัดรัดและมีวัตถุประสงค์เดียว ซึ่งผู้ควบคุมหลักมอบหมายงานให้ (ไม่ว่าจะโดยอัตโนมัติหรือเมื่อคุณร้องขออย่างชัดเจน) การเปลี่ยนแปลงนี้จะเปลี่ยนวิธีที่คุณจัดการบริบท เครื่องมือ และการแลกเปลี่ยนระหว่างต้นทุนและเวลาแฝงของเวิร์กโฟลว์ที่ซับซ้อน

ตัวแทนย่อยคืออะไร?

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

คุณสมบัติหลักของตัวแทนย่อย

• วัตถุประสงค์เฉพาะและแจ้งเตือนระบบ คุณอธิบายบทบาท ข้อจำกัด และแนวทางของตัวแทนย่อยในพรอมต์ระบบเพื่อให้มันทำงานตามที่คาดเดาได้สำหรับโดเมนที่แคบของมัน (ตัวอย่างเช่น ผู้ตรวจสอบโค้ด, ดีบัก, นักวิทยาศาสตร์ข้อมูล).
• หน้าต่างบริบทที่แยกออกมา ตัวแทนย่อยแต่ละตัวจะเก็บประวัติการสนทนาและบริบทของตัวเองไว้ ป้องกันไม่ให้บริบทของเธรดหลักถูกแทรกแซงด้วยรายละเอียดระดับต่ำ ซึ่งถือเป็นหัวใจสำคัญของการปรับขนาดเวิร์กโฟลว์ที่มิฉะนั้นบริบทของการสนทนาเดียวจะหมดไป
• การกำหนดขอบเขตเครื่องมือและการอนุญาต คุณสามารถอนุญาตหรือจำกัดเครื่องมือภายในหรือเครื่องมือ Model Context Protocol (MCP) ภายนอกที่เอเจนต์ย่อยอาจใช้ได้ ซึ่งเป็นคุณสมบัติด้านความปลอดภัยและการกำกับดูแลที่สำคัญ
• กำหนดค่าเป็นรหัส ตัวแทนย่อยถูกกำหนดให้เป็นไฟล์ Markdown ที่มีเนื้อหา YAML (ชื่อ คำอธิบาย เครื่องมือ โมเดล) และจัดเก็บไว้ที่ระดับโครงการ (.claude/agents/) หรือระดับผู้ใช้ (~/.claude/agents/). คำจำกัดความของโครงการจะมีความสำคัญเหนือกว่า

การมอบหมายอัตโนมัติและการเรียกใช้แบบชัดเจนคืออะไร

โคลดโค้ดสามารถ อัตโนมัติ มอบหมายงานให้กับตัวแทนย่อยเมื่อคุณได้รับแจ้งหรือตัวแทนย่อย description ตรงกับงาน — หรือคุณสามารถ อย่างชัดเจน ขอตัวแทน (เช่น > Use the code-reviewer subagent to check my recent changes). ทำ description มุ่งเน้นการกระทำ ("Use PROACTIVELY", "MUST BE USED") เพื่อกระตุ้นการมอบหมายอัตโนมัติ มีสองวิธีเสริมในการใช้ตัวแทนย่อยใน Claude Code:

1. การมอบหมายอัตโนมัติ — Claude ตรวจสอบคำขอและมอบหมายงานที่ตรงกันให้กับตัวแทนย่อยโดยตรง
2. การเรียกที่ชัดเจน — คุณเรียกตัวแทนย่อยตามชื่อในคำสั่ง/คำเตือนของคุณ (ตัวอย่างเช่น Use the code-reviewer subagent to check my changes).

ทั้งสองแนวทางมีการแลกเปลี่ยนประสบการณ์ผู้ใช้ (UX) และวิศวกรรมที่แตกต่างกัน ต่อไปนี้ผมจะอธิบายแต่ละแนวทาง

การมอบหมายอัตโนมัติ

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

ทำไมทีมถึงใช้มัน

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

ข้อควรระวัง

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

การเรียกที่ชัดเจน

หน้าตาของผู้ใช้เป็นอย่างไรบ้าง คุณโทรหาตัวแทนย่อยโดยชัดเจน: > Use the test-runner subagent to run the project testsการประสานงานเป็นแบบกำหนดได้: Claude เรียกใช้เอเจนต์ย่อยที่มีชื่อนั้นพร้อมด้วยสิทธิ์และคำเตือนที่กำหนดค่าไว้ล่วงหน้า

ทำไมทีมถึงใช้มัน

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

ข้อควรระวัง

• การพิมพ์และวินัยที่มากขึ้น: นักพัฒนาหรือระบบอัตโนมัติจะต้องทราบชื่อตัวแทนย่อยที่ถูกต้อง
• โอกาสน้อยลง: คุณจะสูญเสียความสะดวกสบายบางอย่างที่ตัวแทนหลักจะตรวจพบตัวแทนย่อยที่ดีโดยอัตโนมัติ

การทำงานของตัวแทนย่อย — ภาพรวมทางเทคนิค

ด้านล่างนี้เป็นแนวทางปฏิบัติที่เน้นการใช้งานจริงเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อคุณสร้างและใช้ตัวแทนย่อย

การกำหนดตัวแทนย่อย (config เป็นโค้ด)

ตัวแทนย่อยคือไฟล์ Markdown ที่มีเนื้อหา YAML ฟิลด์สำคัญประกอบด้วย:

• name — รหัสตัวพิมพ์เล็กที่ไม่ซ้ำกัน (มีขีดกลาง)
• description — คำอธิบายภาษาธรรมชาติที่ใช้สำหรับการจับคู่การมอบหมายอัตโนมัติ
• tools — รายการเครื่องมือที่อนุญาตโดยเครื่องหมายจุลภาค (หรือละเว้นเพื่อสืบทอดเครื่องมือทั้งหมด)
• model — นามแฝงที่เป็นตัวเลือก (sonnet, opus, haiku) หรือ inherit เพื่อใช้รูปแบบการสนทนาหลัก

ตัวอย่างเล็กๆ น้อยๆ (แนวคิด ไม่ใช่คำต่อคำจากเอกสาร):

---
name: code-reviewer
description: Expert code reviewer. Proactively reviews code for quality, security, and maintainability.
tools: Read, Grep, Bash
model: inherit
---
You are a senior code reviewer. Focus on security, correctness, and maintainability.

ไฟล์เหล่านี้อยู่ใน .claude/agents/ (ขอบเขตโครงการ) หรือ ~/.claude/agents/ (ขอบเขตของผู้ใช้) ไฟล์โครงการจะมีความสำคัญเหนือกว่า ซึ่งทำให้การแชร์และการควบคุมเวอร์ชันของตัวแทนย่อยเป็นเรื่องง่าย

การเลือกแบบจำลองและเครื่องมือ

• สนามจำลอง: คุณสามารถเลือกนามแฝงโมเดลเฉพาะสำหรับเอเจนต์ย่อย หรือปล่อยให้เอเจนต์สืบทอดโมเดลของบทสนทนาหลักก็ได้ ซึ่งจะช่วยให้คุณผสมผสานข้อดีข้อเสียระหว่างต้นทุนและคุณภาพได้ (ตัวอย่างเช่น ใช้โมเดลราคาถูกกว่าสำหรับเอเจนต์ย่อยสำหรับการสแกนข้อมูลขนาดใหญ่ และโมเดลคุณภาพสูงกว่าสำหรับการสังเคราะห์ขั้นสุดท้าย)
• การกำหนดขอบเขตเครื่องมือ: การให้ชุดเครื่องมือขั้นต่ำแก่ตัวแทนย่อยแต่ละตัวจะช่วยลดรัศมีการระเบิดและทำให้การคิดวิเคราะห์เกี่ยวกับความปลอดภัยง่ายขึ้น เครื่องมือเหล่านี้ประกอบด้วยไพรมิทีฟมาตรฐานของ Claude Code (Read, Grep, Bash, Edit ฯลฯ) และการผสานรวมที่ MCP จัดเตรียมไว้

การจัดการพฤติกรรมรันไทม์และบริบท

เมื่อ Claude มอบหมายงานให้กับตัวแทนย่อย ตัวแทนย่อยนั้นจะได้รับ:

1. ระบบแจ้งเตือน (เนื้อหา YAML/Markdown)
2. เฉพาะบริบทที่ต้องการ (หน้าต่างบริบทของตัวเอง)
3. การเข้าถึงเครื่องมือตามที่อนุญาตในไฟล์ config

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

รูปแบบสถาปัตยกรรมสำหรับตัวแทนย่อย

สถาปัตยกรรมที่พบมากที่สุดคือ ออเคสตรา (ตัวแทนหลัก) ที่แยกย่อยงานระดับสูง หมุนตัวแทนย่อยหลายตัวขึ้นมา แล้วสังเคราะห์หรือตรวจสอบผลลัพธ์ของตัวแทนเหล่านั้น รูปแบบมาตรฐานสองแบบปรากฏขึ้นในธรรมชาติ:

1) ผู้ประสานงาน + ผู้เชี่ยวชาญ

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

ควรใช้เมื่อใด: งานที่ซับซ้อนที่มีปัญหาอิสระต่อกัน (เช่น "สร้างการทดสอบ" "รันการวิเคราะห์แบบคงที่" "เขียนโมดูลใหม่" จากนั้น "รวมและรันการทดสอบแบบครบวงจร")

การแลกเปลี่ยน: ตรรกะการประสานงานอาจมีความซับซ้อน การเดินทางไปกลับเพิ่มเติมอาจเพิ่มเวลาแฝงเล็กน้อย

2) ผู้เชี่ยวชาญด้านท่อ/โซ่

ตรงนี้ ตัวแทนย่อยจะถูกจัดเรียงตามลำดับ โดยเอาต์พุตของตัวแทนย่อยตัวหนึ่งจะกลายเป็นอินพุตของตัวแทนย่อยตัวถัดไป (เช่น spec → scaffold → implement → test → optimize) โดยพื้นฐานแล้ว นี่คือองค์ประกอบของฟังก์ชันที่แสดงเป็นตัวแทน ซึ่งมีประโยชน์เมื่อคุณต้องการการแปลงแบบขั้นตอนและการรับประกันอย่างเข้มงวดเกี่ยวกับการไหลของข้อมูลระหว่างขั้นตอนต่างๆ ในทางแนวคิดแล้ว วิธีนี้ง่ายกว่าสำหรับเวิร์กโฟลว์เชิงเส้น และบางครั้งอาจแก้ไขจุดบกพร่องได้ง่ายกว่า

ควรใช้เมื่อใด: การแปลงหลายขั้นตอนแบบกำหนดได้ (เช่น การแปลเอกสารการออกแบบเป็นโค้ดแบบมีโครงร่าง จากนั้นทดสอบ แล้วจึงปรับแต่ง)

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

อะไรที่ทำให้ตัวแทนย่อยแตกต่างจากการแจ้งเตือนตามบทบาทเพียงอย่างเดียว?

1) หน้าต่างบริบทแยกกัน

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

2) การแจ้งเตือนระบบและบุคลิก

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

3) การผูกเครื่องมือและการกำหนดขอบเขตการอนุญาต

ความแตกต่างที่สำคัญในทางปฏิบัติ: ตัวแทนย่อยสามารถได้รับหรือปฏิเสธการเข้าถึงเครื่องมือเฉพาะ เช่น ระบบไฟล์ การดำเนินการกระบวนการ API ภายนอก หรือชุดข้อมูลที่มีสิทธิพิเศษ ซึ่งทำให้ตัวแทนย่อยมีประสิทธิภาพสำหรับ สิทธิพิเศษน้อยที่สุด การออกแบบ: ตัวสร้างเอกสารสามารถถูกบล็อกไม่ให้รันคำสั่งใดๆ ได้ ในขณะที่เอเจนต์ย่อย CI จะได้รับแซนด์บ็อกซ์ที่แยกออกมา โพสต์ในชุมชนจำนวนมากสนับสนุนการจับคู่เอเจนต์ย่อยกับ Model Context Protocol (MCP) หรือเซิร์ฟเวอร์ MCP ที่ใช้ hooks เพื่อจัดการการเข้าถึงข้อมูลลับและ I/O อย่างปลอดภัย

4) การเลือกแบบจำลองและการแลกเปลี่ยนต้นทุนและประสิทธิภาพ

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

5) รูปแบบการสื่อสาร

ตัวแทนย่อยจะสื่อสารกับออร์เคสเตรเตอร์ (หรือกันและกัน) ผ่านข้อความหรือไฟล์ที่มีโครงสร้าง รูปแบบทั่วไปมีดังนี้:

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

ประโยชน์ด้านประสิทธิภาพ

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

1) ลดเวลานาฬิกาผ่านการประมวลผลแบบขนาน

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

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

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

2) การใช้บริบทที่ดีขึ้นและการสูญเสียโทเค็นที่น้อยลง

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

3) ปรับปรุงความแม่นยำจากคำแนะนำเฉพาะทาง

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

วิธีที่ทีมใช้ตัวแทนย่อยจริง ๆ — ตัวอย่างเวิร์กโฟลว์

ด้านล่างนี้เป็นตัวอย่างที่เป็นรูปธรรมเพื่อทำให้สิ่งนี้ดูนามธรรมน้อยลง

ตัวอย่าง A — รีแฟกเตอร์ไปป์ไลน์ (ผู้ประสานงาน + ผู้เชี่ยวชาญ)

1. Orchestrator ได้รับคำขอ “refactor component X”
2. ผู้ประสานเสียงเรียก analysis-subagent (ไม่มีสิทธิ์ในการเขียน) เพื่อระบุจุดที่ซับซ้อนและการอ้างอิงที่มีความเสี่ยง
3. ผู้ประสานเสียงเรียก refactor-subagent (เขียนสิทธิ์ให้กับแซนด์บ็อกซ์แบบสาขา) เพื่อสร้างไฟล์ที่ผ่านการรีแฟกเตอร์
4. ผู้ประสานเสียงเรียก test-gen-subagent (อ่านอย่างเดียวบนโค้ด) เพื่อสร้างการทดสอบยูนิต
5. Orchestrator รัน CI ด้วย ci-runner-subagent (การดำเนินการแบบแซนด์บ็อกซ์) และรวบรวมผลลัพธ์สำหรับการตรวจสอบโดยมนุษย์
   รูปแบบนี้แยกแต่ละเฟส มีความเสี่ยง และรักษาบันทึกการตรวจสอบให้เป็นระเบียบ

ตัวอย่าง B — การวิจัย + ต้นแบบ (ท่อส่ง)

1. literature-subagent รวบรวมข้อมูลและสรุปข้อมูลอ้างอิง (ไม่มีการเขียนไฟล์ การเข้าถึงเว็บที่มีการควบคุม)
2. prototype-subagent สร้างโครงร่าง PoC ขั้นต่ำจากบทสรุป
3. benchmark-subagent รันไมโครเบนช์มาร์กในแซนด์บ็อกซ์และรายงานผลลัพธ์
   ห่วงโซ่นี้บังคับใช้ลักษณะลำดับขั้นตอนของงานวิจัยในขณะที่ยังคงรักษาความรับผิดชอบให้ชัดเจน

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

การออกแบบและการกำหนดค่า

• เริ่มต้นด้วยบทบาทที่เล็กและแคบ ให้แต่ละเอเจนต์ย่อยรับผิดชอบงานที่ชัดเจนหนึ่งงาน ความรับผิดชอบที่แคบลงทำให้การดีบักง่ายขึ้นมาก
• การควบคุมเวอร์ชันของคุณ .claude/agents/ โฟลเดอร์ จัดการนิยามของตัวแทนย่อยเหมือนกับโค้ด — ตรวจสอบ ทดสอบ และปักหมุดเวอร์ชัน วิธีนี้ช่วยลดความคลาดเคลื่อนและช่วยให้การตรวจสอบง่ายขึ้น
• ปักหมุดเครื่องมือและโมเดลโดยตั้งใจ ใช้ model: inherit เมื่อคุณต้องการพฤติกรรมที่สอดคล้องกับบทสนทนาหลัก ให้ระบุนามแฝงโมเดลที่มีต้นทุนต่ำกว่าสำหรับการสแกนเบื้องหลัง ล็อกเครื่องมือเพื่อลดพื้นที่การโจมตีให้เหลือน้อยที่สุด

รูปแบบการดำเนินงาน

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

การทดสอบ การติดตาม และการกำกับดูแล

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

เมื่อไม่ควรใช้ตัวแทนย่อย

ตัวแทนย่อยนั้นมีประสิทธิภาพแต่ไม่ใช่เครื่องมือที่ถูกต้องเสมอไป

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

แนะนำให้ใช้ Claude code cli ที่ไหน

เราตื่นเต้นที่จะประกาศว่าตอนนี้ CometAPI รองรับ Claude Code cli อันทรงพลังอย่างเต็มรูปแบบแล้ว คุณเพียงแค่ต้องติดตั้ง Claude Code และพิสูจน์ตัวตนด้วยรหัส API ของ Comet และที่อยู่ฐานที่ได้รับเพื่อใช้โมเดล API ของ Comet บน Claude Code

เหตุใดจึงต้องใช้โค้ดคล็อดผ่าน CometAPI?

คุณสมบัติปัญญาประดิษฐ์ชั้นนำ: สร้าง แก้ไข และเพิ่มประสิทธิภาพโค้ดได้อย่างง่ายดายโดยใช้โมเดลที่สร้างขึ้นโดยเฉพาะสำหรับนักพัฒนา

• การเลือกโมเดลที่ยืดหยุ่น: โมเดลที่หลากหลายของเราช่วยให้คุณพัฒนาได้อย่างราบรื่นยิ่งขึ้น
• การผสานรวมที่ราบรื่น: API พร้อมใช้งานเสมอ ผสานรวม Claude Code เข้ากับเวิร์กโฟลว์ที่มีอยู่ของคุณได้โดยตรงภายในไม่กี่นาที
• การใช้ Claude Code ผ่าน CometAPI จะช่วยประหยัดต้นทุนได้มากขึ้นAPI ของ Claude ที่จัดทำโดย CometAPI ลดราคา 20% จากราคาอย่างเป็นทางการ และได้รับการอัปเดตด้วยรุ่นล่าสุดโดยทางการ

พร้อมที่จะใช้ Claude Code cli แล้วหรือยัง? ปรึกษา คู่มือ API สำหรับคำแนะนำโดยละเอียด

หากคุณต้องการทราบเคล็ดลับ คำแนะนำ และข่าวสารเกี่ยวกับ AI เพิ่มเติม โปรดติดตามเราที่ VK, X และ ไม่ลงรอยกัน!

ดูเพิ่มเติม จะติดตั้งและรัน Claude Code ผ่าน CometAPI ได้อย่างไร?

บทสรุป — เหตุใดตัวแทนย่อยจึงมีความสำคัญในปัจจุบัน

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