# วิธีมอบหมายงานขนาดใหญ่ใน Claude Code โดยใช้ subagent แบบซ้อน

> ใน v2.1.172 Anthropic เปิดให้ subagent ของ Claude Code สร้าง subagent ของตัวเองได้ลึกสูงสุด 5 ระดับ พร้อมคำแนะนำในการมอบหมายงานขนาดใหญ่

Source: https://ailoot.ai/blog/th/claude-code-nested-subagents/
Canonical: https://ailoot.ai/blog/th/claude-code-nested-subagents/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-232
Revision: sha256-f8e6782bd5ed0d9b084027735080203038a08fb10992fbf4ed1e8b47c401fec7


<div class="aside" data-semantic="editorial-reference" role="note" aria-label="เอกสารประกอบของ Ailoot">

[เอกสารประกอบของ Ailoot](https://ailoot.ai/docs/) — เอกสารอ้างอิงเกี่ยวกับการใช้บริการ

</div>

## Claude Code v2.1.172 มีการเปลี่ยนแปลงอะไรบ้าง?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

Anthropic ออก Claude Code v2.1.172 และยกเลิกกฎที่มีมานานสองปีด้วยบรรทัดเดียวในบันทึกการเปลี่ยนแปลง ตอนนี้ subagent สร้าง subagent ของตัวเองได้ลึกสูงสุด 5 ระดับ ฟีเจอร์นี้ไม่ได้มีไว้เพื่อเพิ่มความเร็วหรือใช้ CPU ให้มากขึ้น แนวคิดหลักคือกันงานเตรียมการที่มีข้อมูลรบกวนไม่ให้ทำให้ context หลักของคุณรก

</div>

ถ้าคุณอ่านเรื่อง AI agent ใน Claude Code มาบ้างในช่วงไม่กี่เดือนที่ผ่านมา คุณคงเจอประโยคเดิมซ้ำ ๆ อยู่ในเอกสารประกอบอย่างเป็นทางการ ในคู่มือของฉัน[เกี่ยวกับ subagent](https://ailoot.ai/blog/th/claude-code-subagents/) และในการวิเคราะห์ของคู่แข่งทุกราย ประโยคนั้นคือ “subagent ไม่สามารถสร้าง subagent อีกตัวได้” ณ วันที่ 11 มิถุนายน 2026 ข้อความนี้ยังอยู่ในสามตำแหน่งบน `code.claude.com/docs/en/sub-agents` Anthropic ยังไม่ได้อัปเดตข้อมูลนี้

เมื่อวันที่ 10 มิถุนายน เวลา 20:44 UTC Claude Code v2.1.172 ปรากฏบน GitHub Releases รายการหลักในบันทึกการเปลี่ยนแปลงมีเพียงบรรทัดเดียว:

<figure>
<blockquote>
ตอนนี้ subagent สร้าง subagent ของตัวเองได้ ลึกสูงสุด 5 ระดับ
</blockquote>
<figcaption>— Claude Code Changelog, https://github.com/anthropics/claude-code/releases/tag/v2.1.172</figcaption>
</figure>

รุ่นนี้ยังแก้บั๊กที่เกิดได้เฉพาะเมื่อมีการซ้อนด้วย: subagent ที่ทำงานเบื้องหลังจะยังถูกไฮไลต์ว่า active ในแผง agents หลังจากหยุด subagent ที่มันเปิดขึ้นมาแล้ว

นี่เป็นกรณีที่พบไม่บ่อยซึ่งเอกสารประกอบอย่างเป็นทางการยังขัดแย้งกับรุ่นที่เผยแพร่แล้ว ต่อไปฉันจะอธิบายว่าการซ้อนต่างจาก subagent แบบขนานอย่างไร “ความลึก 5” หมายถึงอะไร และมี 3 สถานการณ์ใดบ้างที่ใช้ได้จริงในตอนนี้

## subagent แบบซ้อนต่างจากแบบขนานและแบบลำดับอย่างไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

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

</div>

ฉันลองใช้ทั้งสามวิธีด้วยตัวเองอยู่นาน และนี่คือวิธีที่ฉันมองมัน: การมอบหมายงานมีสามมิติ ได้แก่ ความกว้าง ความยาว และความลึก แต่ละแบบแก้ปัญหาคนละอย่าง

**ความกว้าง—subagent แบบขนาน** แชตหลักเปิด subagent อิสระ N ตัวในระดับเดียวกัน แต่ละตัวได้รับงานที่มีขอบเขตแคบ ทำงานในหน้าต่างแยกของตัวเอง และส่งกลับเฉพาะผลลัพธ์ ความกว้างช่วยเพิ่มความเร็ว: subagent 5 ตัวที่ทำงานขนานกันเสร็จในเวลาที่ตัวเดียวใช้ทำงานเดียวกันแบบต่อเนื่อง นี่คือรูปแบบที่ฉันอธิบายไว้ในคู่มือ[เกี่ยวกับ subagent แบบขนานที่ใช้ worktree](https://ailoot.ai/blog/th/claude-code-parallel-worktree-agents/)

**ความยาว—สายงานของ subagent** A ทำงานแล้วส่งผลให้ B, B ทำงานแล้วส่งผลให้ C แต่ละตัวเห็นข้อมูลจากตัวก่อนหน้า ความยาวกำหนดลำดับ: B เริ่มไม่ได้จนกว่าจะได้รับข้อมูลจาก A ตัวอย่างคลาสสิกคือ subagent วิจัยรวบรวมแหล่งข้อมูลก่อน จากนั้น subagent แก้ไขเขียนบทความโดยอิงจากแหล่งข้อมูลเหล่านั้น แล้ว subagent ตรวจสอบข้อเท็จจริงตรวจบทความ เป็นลำดับแบน ๆ โดยแชตหลักถือเรื่องราวทั้งหมดไว้

**ความลึก—subagent แบบซ้อน** A เปิด B, B เปิด C, C เปิด D ลูกแต่ละตัวทำงานภายในตัวแม่ ในหน้าต่างแยกของตัวเอง และส่งกลับ **เฉพาะผลลัพธ์** ให้ตัวแม่ แชตหลักไม่เห็นสิ่งที่เกิดขึ้นในลูก หลาน และเหลน นี่คือสิ่งใหม่ใน v2.1.172

ความสับสนหลักคือผู้คนคิดว่าความลึก 5 หมายถึง “เปิด subagent ได้ 5 ตัวพร้อมกัน” ซึ่งไม่ใช่แบบนั้น ความลึกคือระดับแนวตั้งในแผนผัง ไม่ใช่จำนวนลูกที่ทำงานพร้อมกัน ในแต่ละระดับอาจมี subagent หนึ่งตัวหรือร้อยตัวก็ได้ ความลึก 5 หมายถึงสายการมอบหมายงานลงไปได้ 5 ขั้น: แชตหลัก → หลาน-1 → หลาน-2 → หลาน-3 → หลาน-4 → หลาน-5 และยังแตกแขนงได้ในทุกระดับ





Version 2.1.172 ยกเลิกข้อจำกัดที่ subagent ไม่สามารถสร้าง subagent อีกตัวได้

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

## “ความลึก 5 ระดับ” หมายถึงอะไรในทางปฏิบัติ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

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

</div>

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

**นี่คือขีดจำกัด ไม่ใช่การตั้งค่า**



ขีดจำกัดนี้ฝังอยู่ในฝั่งเซิร์ฟเวอร์ การทำ reverse engineering ไคลเอนต์ v2.1.172 ไม่พบค่าคงที่ `MAX_DEPTH` นั่นหมายความว่าการตรวจสอบเกิดขึ้นที่ใดสักแห่งใน Anthropic API ไม่ใช่ในเครื่องของคุณ คุณตั้ง `--max-depth 7` เพื่อทำให้แผนผังลึกขึ้นไม่ได้ และตั้ง `--max-depth 2` เพื่อกำหนดขีดจำกัดที่ต่ำกว่าและปลอดภัยกว่าไม่ได้เช่นกัน การควบคุมอย่างเดียวที่คุณมีคือ allowlist `Agent(agent_type)` ใน frontmatter แต่จะจำกัด **ประเภท** ของ agent ลูก ไม่ใช่ความลึก

**Anthropic ยังไม่ได้ให้คำจำกัดความ “5” อย่างแม่นยำ** นี่คือประเด็นสำคัญข้อที่สอง:

แหล่งข้อมูลอย่างเป็นทางการไม่ได้ระบุว่า depth=5 หมายถึงห้าระดับใต้ root หรือมี agent ทั้งหมดห้าตัวโดยนับ root ด้วย

ตอนนี้การผสานระบบจากบุคคลที่สามตีความต่างกัน ADR-147 ในโปรเจกต์ `ruvnet/ruflo` สมมติว่า “มี 5 ระดับลูกใต้ root = 6 agent ในสาย” ฉันใช้แนวทางเดียวกันในการทดลอง: แชตหลักอยู่ระดับ 0 ลูกโดยตรงอยู่ระดับ 1 และไล่ไปจนถึงระดับ 5 แต่แนวทางนี้ไม่ได้ระบุไว้ในเอกสารสาธารณะ

**เปิดใช้ขีดจำกัดนี้แล้วโดยไม่มี flag** คุณไม่ต้องเปิดใช้งานอะไร หลังอัปเดต Claude Code เป็น v2.1.172 คุณเพิ่ม `Agent` ใน `tools` ของ agent ลูก แล้วมันก็จะเปิด subagent อีกตัวได้ สิ่งสำคัญคือ agent ตัวแม่ต้องอนุญาต (`tools: Agent(...)`)

## วันนี้คุณมอบหมายงานแบบไหน: กว้าง ยาว หรือลึก?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

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

</div>

ลองย้อนดูพรอมต์ 5 ครั้งล่าสุดของคุณ คุณทำแบบนี้บ่อยแค่ไหน: เริ่มงานแล้ว Claude เริ่ม grep ไฟล์ ส่งคำขอเว็บ 10 ครั้ง เท log จำนวนมากลงใน context—แล้วอีก 20 นาทีต่อมาก็รู้ว่าหน้าต่างเต็ม คำตอบสุดท้ายต้องทำงานด้วยงบ token ที่เหลือเพียงน้อยนิด เพราะ 70 เปอร์เซ็นต์ของ context ถูกใช้ไปกับข้อมูลระหว่างทาง

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

ก่อนวันที่ 9 มิถุนายน ฉันจำลองวิธีนี้ด้วยมือ ฉันเปิด Claude Code อีกหน้าต่าง คัดลอกพรอมต์ “ค้นคว้าเรื่องนี้” เรียกใช้งาน แล้วโอนผลกลับไปหน้าต่างหลักด้วยตัวเอง ฉันอธิบายการตั้งค่านี้ไว้โดยละเอียดในคู่มือเกี่ยวกับการมอบหมายงานเขียนโค้ดให้ AI agents จำนวนมาก เมื่อใช้ v2.1.172 คุณอธิบายสิ่งนี้ได้โดยตรงใน system prompt ของ orchestrator แล้ว Claude จะสร้างแผนผังขึ้นเอง



## 3 สถานการณ์ใดบ้างที่ subagent แบบซ้อนมีประโยชน์จริง?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

ไม่ใช่ทุกงานจะเหมาะกับมัน ความลึกมีเหตุผลเมื่อการมอบหมายงานหนึ่งมีงานย่อยที่มีข้อมูลรบกวน ซึ่งคุณไม่อยากใส่ไว้ในหน้าต่างหลัก ฉันจะพูดถึง 3 สถานการณ์มาตรฐานที่พบซ้ำในกลุ่ม vibe coder ได้แก่ การวิจัยเชิงลึกพร้อมตรวจสอบข้อเท็จจริง การวิเคราะห์ repository ขนาดใหญ่ และการตรวจสอบ dependency แบบ end-to-end เมื่อมีการเปลี่ยน schema หรือ contract

</div>

### สถานการณ์ 1. วิจัยเชิงลึกพร้อมตรวจสอบข้อเท็จจริง

สมมติว่าคุณกำลังรวบรวมข้อมูลเพื่อเขียนบทความหรือข้อเสนอการขาย ขั้นแรกคุณต้องดึงข้อกล่าวอ้าง 5–10 ข้อจากแหล่งข้อมูลสาธารณะ จากนั้นตรวจสอบแต่ละข้อ—หาแหล่งข้อมูลต้นฉบับ ตรวจว่าคำอ้างตรงกันทุกคำ และคำนวณตัวเลขจริง

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

ในสูตรด้านล่าง แชตหลักมอบให้ `research-orchestrator` ระดับ 1 ซึ่งดึงข้อกล่าวอ้างเอง ส่งแต่ละข้อให้ `fact-verifier` ระดับ 2 และ verifier ส่งการค้นเฉพาะให้ `web-deep-search` ระดับ 3 แชตหลักได้รับผลข้อกล่าวอ้างที่ตรวจพร้อมแหล่ง ขณะที่รายละเอียดทำงานอยู่ในบริบทลูก

### สถานการณ์ 2. วิเคราะห์ repository ขนาดใหญ่

คุณได้รับโปรเจกต์ที่มีไฟล์ 200 ไฟล์ และต้องเข้าใจสถาปัตยกรรม หาโมดูลหลัก และประเมินหนี้ทางเทคนิค ถ้ารัน `Glob` แล้วเรียก `Read` ด้วยมือเป็นสิบครั้ง หน้าต่างจะเต็มภายใน 10 นาที

ความลึกช่วยแก้ปัญหานี้ดังนี้: แชตหลักเปิด subagent “architect” จากนั้น architect เปิดลูกสามตัวภายใน—ตัวแรกตรวจโครงสร้างไดเรกทอรี (รัน `Glob` และสรุป) ตัวที่สองอ่านไฟล์กำหนดค่าหลัก 5 ไฟล์ และตัวที่สาม grep หาแพตเทิร์นหลัก แต่ละตัวส่งสรุปสั้น ๆ ให้ architect แล้ว architect รวบรวมภาพรวมและส่งรายงานฉบับสุดท้ายยาวครึ่งหน้าจอให้แชตหลัก คุณได้แผนที่ของโปรเจกต์โดยไม่ต้องทำให้ context ท่วมด้วยผล `cat` จำนวนมากจากทุกไฟล์

### สถานการณ์ 3. วิเคราะห์ dependency แบบ end-to-end

คุณกำลังเปลี่ยน schema ฐานข้อมูล contract ของ API หรือไฟล์กำหนดค่าที่ใช้ร่วมกัน คุณต้องรู้ว่าผลกระทบจะเกิดขึ้นตรงไหน งานนี้ทำให้ context หมดเร็วที่สุด เพราะมี dependency จำนวนมากและต้องตรวจแต่ละจุดใน source

เมื่อใช้ความลึก แชตหลักเปิด “impact-analyzer” (ระดับ 1) แล้วมันเปิด `dependency-tracer` หนึ่งตัวต่อไฟล์ที่ได้รับผลกระทบ (ระดับ 2) แต่ละ tracer เปิด `consumer-finder` ภายใน (ระดับ 3) เพื่อ grep codebase หา consumer ของ dependency นั้น จากนั้นแต่ละตัวส่งกลับเฉพาะใจความว่า “สามตำแหน่งนี้จะพัง” แชตหลักรวบรวมเป็นตาราง “ไฟล์ที่ได้รับผลกระทบ → ผลกระทบ” โดยไม่เห็นผล grep





## วิธีตั้งค่า subagent แบบซ้อนใน 10 นาที

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

ไม่ต้องใช้ flag และไม่ต้องอัปเดต config เพียงเพิ่ม `Agent` ใน `tools` ของ agent ลูก มันก็เปิด subagent ของตัวเองได้ เพื่อไม่ให้แผนผังกลายเป็นบ่อนพนัน ให้ใช้ allowlist `Agent(name1, name2)` ต่อไปนี้ฉันจะให้เทมเพลตพร้อมใช้สำหรับ orchestrator สามระดับที่คุณคัดลอกไปใช้ได้เลย

</div>

**ขั้นตอนที่ 1 ตรวจสอบว่าคุณใช้ v2.1.172 หรือใหม่กว่า**

```bash
claude --version
```

ถ้าเก่ากว่านั้น ให้อัปเดต ฟีเจอร์หลักของรุ่นนี้อยู่ในบันทึกการเปลี่ยนแปลงเพียงบรรทัดเดียว: “ตอนนี้ subagent สร้าง subagent ของตัวเองได้ ลึกสูงสุด 5 ระดับ” ([ข้อความเต็ม](https://github.com/anthropics/claude-code/releases/tag/v2.1.172))

**ขั้นตอนที่ 2 สร้าง agent ตัวแม่ที่เปิดลูกได้**

ไฟล์ `.claude/agents/research-orchestrator.md`:

```markdown
---
name: research-orchestrator
description: มอบหมายการวิจัยพร้อมตรวจสอบข้อเท็จจริงเชิงลึก
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

คุณคือ orchestrator สำหรับการวิจัย เมื่อได้รับหัวข้อ:
1. อ่านข้อมูลต้นทางที่ให้หรือดึง URL สาธารณะที่ให้
   ดึงข้อกล่าวอ้างรูปธรรมเองไม่เกิน 5 ข้อ แต่ละข้อบันทึกข้อความข้ออ้าง
   URL หรือไฟล์ต้นทาง และข้อความรองรับตรงตัว
   หากไม่มีข้อมูลต้นทาง ให้ขอก่อนมอบหมาย
2. เรียก fact-verifier สำหรับข้อกล่าวอ้างแต่ละข้อ โดย fact-verifier จะสร้าง
   subagent ลูกของตัวเองเพื่อค้นหาและตรวจสอบข้อมูลบนเว็บ
3. fact-verifier จะส่งกลับเฉพาะคำตัดสินสุดท้ายให้คุณ อย่าโหลดข้อมูลระหว่างทางลงใน context ของคุณ

รายงานสุดท้ายให้มีเพียงอาร์เรย์ { claim, sources[], confidence }
```

บรรทัด `tools` ให้เฉพาะชนิดลูก `fact-verifier` การดึงข้อกล่าวอ้างเป็นขั้นแรกของ orchestrator เอง จึงไม่ต้องมีไฟล์ `claim-extractor` ที่ยังไม่ได้นิยาม allowlist ชนิดจำกัดว่าลูกแบบใดเรียกได้ ไม่ได้จำกัดจำนวนครั้งที่เปิดชนิดนั้น ต้องจำกัดสูตรดึงข้ออ้างไม่เกินห้าข้อแยก

**ขั้นตอนที่ 3 สร้าง agent ลูกที่เปิดเหลนได้ด้วยตัวเอง**

ไฟล์ `.claude/agents/fact-verifier.md`:

```markdown
---
name: fact-verifier
description: ตรวจสอบข้อกล่าวอ้างด้วยการค้นหาเว็บผ่าน agent ลูก
tools: Agent(web-deep-search), Read
model: sonnet
---

คุณคือผู้ตรวจสอบข้อเท็จจริง เมื่อได้รับข้อกล่าวอ้าง:
1. เขียนคำค้น 2-3 รายการ
2. เรียก web-deep-search สำหรับแต่ละคำค้น ตัว agent จะทำ
   WebSearch และ WebFetch เอง แล้วส่งตัวอย่างข้อความที่ยืนยันแล้วกลับมา
3. รวมเป็น verdict เดียว: { claim, sources[], confidence }
```

เห็นส่วนสำคัญหรือไม่? `tools` ระบุ `Agent(web-deep-search)` อีกครั้ง นั่นหมายความว่า fact-verifier (ระดับ 2 ในแผนผังของเรา) เปิด subagent อีกตัวได้ด้วยตัวเอง (ระดับ 3) ก่อนหน้านี้บรรทัดนี้ไม่มีผล—เอกสารยังมีข้อความว่า:

<figure>
<blockquote>
subagent ไม่สามารถสร้าง subagent อื่นได้ ดังนั้น Agent(agent_type) จึงใช้ไม่ได้ในคำจำกัดความของ subagent
</blockquote>
<figcaption>— Claude Code Docs, https://code.claude.com/docs/en/sub-agents</figcaption>
</figure>

เมื่อใช้ v2.1.172 ข้อความนั้นล้าสมัยแล้ว รูปแบบคำสั่งเหมือนเดิม แต่ตอนนี้ใช้ได้ในทุกระดับของแผนผัง

**ขั้นตอนที่ 4 สร้าง agent หลาน**

ไฟล์ `.claude/agents/web-deep-search.md`:

```markdown
---
name: web-deep-search
description: ค้นหาเว็บและส่งตัวอย่างข้อความกลับมา
tools: WebSearch, WebFetch
model: haiku
---

คุณได้รับคำค้นมาแล้ว ทำ WebSearch เลือก URL ที่เกี่ยวข้องมากที่สุด 3 รายการ แล้วใช้ WebFetch ดึงข้อความยืนยันข้อกล่าวอ้างแบบคำต่อคำ ส่งกลับเป็นอาร์เรย์ { url, snippet, supports_claim: yes|no }
```

agent หลานไม่มี `Agent` ใน `tools` จึงไม่สร้าง agent ต่อไปในแผนผัง

**ขั้นตอนที่ 5 เรียกใช้ orchestrator**

```bash
claude --agent research-orchestrator
```

จากนั้นให้ข้อความต้นทางหรือ URL สาธารณะในแชตว่า “ดึงและตรวจข้อกล่าวอ้างรูปธรรมจากแหล่งนี้ไม่เกิน 5 ข้อ คืนข้ออ้าง แหล่ง และความมั่นใจ” เมื่อใช้ `--agent research-orchestrator` เซสชันเองเป็น orchestrator ลูก verifier กับ search เพิ่มสองระดับมอบหมายด้านล่าง หากเซสชันหลักปกติมอบให้ orchestrator แทน จะมีสามระดับมอบหมายใต้เซสชันหลักนั้น

## รูปแบบที่ควรหลีกเลี่ยง 5 แบบใดทำให้เปลือง token และตรวจสอบการทำงานไม่ได้?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

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

</div>

**รูปแบบที่ควรหลีกเลี่ยง 1 งานทำได้ในหน้าต่างเดียว**

ถ้า subagent ตัวเดียวจัดการได้โดยไม่มีข้อมูลรบกวน ก็อย่าเพิ่มระดับ: การซ้อนเพิ่มค่าใช้จ่ายและเวลาแฝงโดยเปล่าประโยชน์



**รูปแบบที่ควรหลีกเลี่ยง 2 คุณต้องการความเร็ว ไม่ใช่การแยกงาน**

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

**รูปแบบที่ควรหลีกเลี่ยง 3 งานมีความลึกน้อยโดยธรรมชาติ**

“หาไฟล์นี้แล้วแสดงให้ฉันดู” เป็น **คำขอสองขั้นตอน** ไม่จำเป็นต้องมีโครงสร้างสามระดับ การซ้อนคุ้มค่าเมื่องานมีงานย่อยที่มีข้อมูลรบกวน ถ้าไม่มีข้อมูลรบกวน ก็อย่าเพิ่ม subagent

**รูปแบบที่ควรหลีกเลี่ยง 4 พรอมต์ระดับแรกคลุมเครือ**

นี่เป็นสถานการณ์ที่อันตรายที่สุด ถ้าคุณให้พรอมต์คลุมเครือแก่ orchestrator ระดับ 1 ความคลุมเครือจะทวีคูณ พรอมต์คลุมเครือระดับ 1 หนึ่งรายการกลายเป็นพรอมต์คลุมเครือ 4 รายการในระดับ 2 และ 16 รายการในระดับ 3 เมื่อหลานเริ่มทำงาน พวกเขาก็ไม่รู้ด้วยซ้ำว่ากำลังหาอะไร

**รูปแบบที่ควรหลีกเลี่ยง 5 ค่าใช้จ่ายเติบโตแบบเรขาคณิต**

นี่คือเหตุผลหลักด้านเศรษฐศาสตร์: การซ้อนเพิ่มการใช้ token และการเพิ่มขึ้นทบกันตามความลึก

การซ้อนเพิ่มการใช้ token และการเพิ่มขึ้นทบกันตามความลึก

คำนวณคร่าว ๆ: สายงานความลึก 3 ที่แตกแขนง 3 ตัวในแต่ละระดับหมายถึง subagent 27 ตัว อย่างน้อยก็ใช้ token มากกว่าคำขอธรรมดา 27 เท่า หากใช้แผน Pro ของ Claude การคำนวณนี้ทำให้โควต้ารายวันหมดภายในไม่กี่ชั่วโมง ถ้าใช้แผน Max คุณจะใช้โควต้าหนึ่งสัปดาห์หมดในหนึ่งวัน

**รูปแบบที่ควรหลีกเลี่ยงเพิ่มเติม (จากประสบการณ์ของฉัน): “agent 50 ตัวทำงานไร้จุดหมาย”**

เวลาเห็นโปรเจกต์ของคนอื่น ฉันมักพบแบบนี้: “ฉันมี agent ทำงานอยู่ 50 ตัว” ฉันถามว่าพวกมันทำอะไรอยู่ แล้ว agent 50 ตัวนั้นก็ **ทำงานไร้จุดหมาย** พวกมันสร้างผลลัพธ์ที่ไม่จำเป็นจำนวนมาก สรุปดิบกองโต ข้อมูลซ้ำ และ log ยาวเหยียด แต่ละตัวทำอะไรสักอย่างที่ “มีประโยชน์โดยทั่วไป” แล้วผลลัพธ์ก็คือ context ที่จมอยู่ในข้อมูลและบิล token ระดับบริษัทขนาดเล็ก ความลึก 5 ไม่ได้แก้ปัญหานี้—แต่ **ทำให้แย่ลง** หากระดับ 1 ยังไม่ชัดว่าใครทำอะไร ความลึก 5 ก็หมายถึงความสับสนห้าระดับ

ก่อนเปิด subagent ตัวใด ให้ทดสอบด้วยคำถาม 4 ข้อภายในครึ่งนาที:

- มันทำอะไรอย่างแน่ชัด (หนึ่งประโยค)?
- มันแตะไฟล์ใดบ้าง?
- มันส่งอะไรกลับให้ตัวแม่?
- ใครเป็นคนตรวจสอบมัน?

ถ้าคุณตอบไม่ได้ภายใน 30 วินาที subagent ตัวนี้ก็ไม่ควรมีอยู่ ฉันอธิบายกฎนี้แยกไว้ในคู่มือ[เกี่ยวกับ subagent แบบขนาน](https://ailoot.ai/blog/th/claude-code-parallel-worktree-agents/)

## ทำไมการซ้อนโดยไม่มี context engineering จึงหมายถึงภาพหลอน 5 ระดับ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

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

</div>

ตรงนี้เองที่ผู้คนมักถามว่า: “ฉันอัปเดต Claude Code เพิ่ม Agent ใน tools แล้ว แผนผังกำลังสร้าง แต่คำตอบสุดท้ายยังผิดเพี้ยนอยู่ ทำไม?”

คำตอบง่ายมาก subagent ทุกตัวใน Claude Code เริ่มต้น **จากศูนย์** ตามเอกสารประกอบอย่างเป็นทางการ:

<figure>
<blockquote>
subagent แต่ละตัวเริ่มต้นด้วยหน้าต่างแยกที่สดใหม่ มันมองไม่เห็นประวัติการสนทนา skills ที่คุณเรียกใช้แล้ว หรือไฟล์ที่ Claude อ่านไปแล้ว
</blockquote>
<figcaption>— Claude Code Docs, https://code.claude.com/docs/en/sub-agents</figcaption>
</figure>

ระดับ 1 ยังจัดการได้: orchestrator ส่งคำอธิบายงานสั้น ๆ ให้ลูก แต่ในระดับ 3 หลานได้รับข้อความมอบหมายงานจากตัวแม่ ซึ่งตัวแม่เองก็ได้รับเพียงข้อความมอบหมายงานเช่นกัน แต่ละตัวส่งต่อข้อมูลไปเพียงเล็กน้อย เมื่อถึงระดับ 5 คุณจะมี subagent ที่หน้าต่างมีเพียงวลี “ตรวจสอบข้อกล่าวอ้าง X” และไม่มีอะไรอีก มันไม่รู้ว่ากำลังทำงานในโปรเจกต์ใด กำลังแก้โจทย์อะไร หรือควรเน้นตรงไหน

หากไม่มี [CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) หลานระดับห้าก็เหมือนพนักงานที่มาออฟฟิศเป็นครั้งแรกในชีวิตโดยไม่มีการปฐมนิเทศ มันจะทำอะไรบางอย่างเพราะได้รับงาน แต่สิ่งนั้นจะไม่ใช่สิ่งที่โปรเจกต์ต้องการ



## นอกจากการซ้อนแล้ว v2.1.172 เปลี่ยนอะไรอีก?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

รุ่นนี้เน้นเรื่อง subagent นอกจากฟีเจอร์หลักแล้ว ยังมีการแก้ไขโครงสร้างพื้นฐานสำหรับการมอบหมายงานอีก 4 รายการ หนึ่งในนั้นแก้บั๊กที่เกิดได้เฉพาะเมื่อมีการซ้อน

</div>

เปิดบันทึกการเปลี่ยนแปลง v2.1.172 ฉบับเต็ม แล้วคุณจะเห็นว่ารุ่นนี้เกี่ยวกับ subagent ทั้งหมด

**การแก้ไข 1** subagent เบื้องหลังจะไม่ค้างอยู่ในสถานะ active ในแผง agents อีกต่อไป หลังจากหยุด subagent แบบซ้อนที่มันเปิดขึ้นมา บั๊กนี้เกิดได้เฉพาะเมื่อมีการซ้อน

**การแก้ไข 2** ข้อจำกัด `availableModels` มีผลกับ subagent ด้วย ก่อนหน้านี้ หากคุณจำกัดโมเดลที่ทีมใช้ได้ (เช่น ห้ามใช้ opus เพื่อประหยัดค่าใช้จ่าย) subagent สามารถเลี่ยงกฎได้ด้วยการ override ใน config ของตัวเอง เมื่อใช้ v2.1.172 กฎนี้มีผลทุกที่

**การแก้ไข 3** ปุ่มลูกศรขึ้นในประวัติพรอมต์จะแสดงพรอมต์จากแท็บ **ปัจจุบัน** ของ subagent ไม่ใช่ของ agent หลัก เป็นการปรับปรุงการตรวจสอบการทำงาน

**การแก้ไข 4** ลดการใช้ CPU ขณะว่าง: ตัวบ่งชี้ `/goal` จะไม่วาดเทอร์มินัลใหม่ที่ 5 Hz ขณะว่างอีกต่อไป และ UI จะวาดใหม่ไม่บ่อยเท่าเดิมขณะ subagent ทำงานแบบขนาน

ฉันขอชี้ให้เห็นว่าการแก้ไขทั้งสี่รายการเกี่ยวข้องกับ subagent ทั้งหมด นั่นหมายความว่า Anthropic เผยแพร่โครงสร้างพื้นฐานสำหรับการซ้อนทั้งชุด ไม่ใช่แค่บรรทัดเดียวในบันทึกการเปลี่ยนแปลง มีการใช้การซ้อนภายใน Anthropic มาระยะหนึ่งแล้วก่อนเผยแพร่

## รายการตรวจสอบ: การซ้อนช่วยหรือทำให้แย่ลงเมื่อใด

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญของส่วนนี้">

ประเด็นสำคัญ

ก่อนเปิด subagent ตัวใหม่ ให้ตรวจงานด้วยคำถาม 6 ข้อ หากมีคำตอบ “ใช่ ควรใช้ความลึก” อย่างน้อย 3 ข้อ ก็ใช้ได้ หากน้อยกว่านั้น ให้ใช้การทำงานแบบขนานหรือ subagent ตัวเดียว วิธีนี้จะช่วยประหยัด token ลดความเครียด และประหยัดเวลาสองสามชั่วโมงที่อาจต้องใช้ทำความเข้าใจว่าสายงานการเปิด agent แบบซ้อน 27 ตัวกำลังทำอะไรอยู่

</div>

ใช้การซ้อนเมื่อ:

- งานมีงานย่อยที่ต้องส่งคำขอเว็บ grep หรืออ่านไฟล์จำนวนมาก
- ยอมรับได้หากงานย่อยนั้นหายไป (ถ้าเหลนตอบว่า “ไม่พบอะไรเลย” orchestrator ก็ทำงานต่อได้)
- คุณ **ไม่จำเป็นต้อง** เห็นผลลัพธ์ระหว่างทางในหน้าต่างหลัก
- คุณมี `CLAUDE.md` และบริบทโปรเจกต์ที่รวบรวมไว้ซึ่ง subagent ใช้อ้างอิงได้
- คุณอธิบายได้ชัดว่าแต่ละระดับจะส่งอะไรกลับมา (ข้อมูลนำเข้า ผลลัพธ์ รูปแบบ)
- คุณใช้แผน Max หรือมีโควตาสำรองสำหรับ token ×27

อย่าใช้การซ้อนเมื่อ:

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

<div class="section" role="doc-bibliography" aria-label="แหล่งอ้างอิง">

### แหล่งอ้างอิง

- [Claude Code Release v2.1.172 - GitHub Releases](https://github.com/anthropics/claude-code/releases/tag/v2.1.172)
- [สร้าง subagent แบบกำหนดเอง - Claude Code Docs](https://code.claude.com/docs/en/sub-agents)

</div>





มีเอกสารเพิ่มเติมบน [Ailoot](https://ailoot.ai/).

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

### ต้องสร้าง claim-extractor สำหรับสูตรที่คัดหรือไม่?

ไม่ต้อง research-orchestrator ที่แก้แล้วดึงข้ออ้างไม่เกินห้าจากข้อมูลที่ให้เอง สร้างสามไฟล์ที่แสดงคือ research-orchestrator, fact-verifier และ web-deep-search แล้วให้ข้อความหรือ URL ต้นทาง

### อนุญาตเฉพาะ fact-verifier จำกัดจำนวนเปิดลูกหรือไม่?

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


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ
