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

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

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

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

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

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

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

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

ความกว้าง—subagent แบบขนาน แชตหลักเปิด subagent อิสระ N ตัวในระดับเดียวกัน แต่ละตัวได้รับงานที่มีขอบเขตแคบ ทำงานในหน้าต่างแยกของตัวเอง และส่งกลับเฉพาะผลลัพธ์ ความกว้างช่วยเพิ่มความเร็ว: subagent 5 ตัวที่ทำงานขนานกันเสร็จในเวลาที่ตัวเดียวใช้ทำงานเดียวกันแบบต่อเนื่อง นี่คือรูปแบบที่ฉันอธิบายไว้ในคู่มือเกี่ยวกับ subagent แบบขนานที่ใช้ worktree

ความยาว—สายงานของ 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 ระดับ” หมายถึงอะไรในทางปฏิบัติ?#

มีประเด็นหนึ่งที่ต้องพูดตามตรง ฉันใช้เวลาครึ่งวันอ่านเอกสารและบทวิเคราะห์ของชุมชนเพื่อค้นพบว่า 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(...))

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

ลองย้อนดูพรอมต์ 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 แบบซ้อนมีประโยชน์จริง?#

สถานการณ์ 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 นาที#

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

claude --version

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

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

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

---
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:

---
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) ก่อนหน้านี้บรรทัดนี้ไม่มีผล—เอกสารยังมีข้อความว่า:

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

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

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

---
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

claude --agent research-orchestrator

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

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

รูปแบบที่ควรหลีกเลี่ยง 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 แบบขนาน

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

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

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

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

หากไม่มี CLAUDE.md หลานระดับห้าก็เหมือนพนักงานที่มาออฟฟิศเป็นครั้งแรกในชีวิตโดยไม่มีการปฐมนิเทศ มันจะทำอะไรบางอย่างเพราะได้รับงาน แต่สิ่งนั้นจะไม่ใช่สิ่งที่โปรเจกต์ต้องการ

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

เปิดบันทึกการเปลี่ยนแปลง 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 มาระยะหนึ่งแล้วก่อนเผยแพร่

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

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

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

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

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

มีเอกสารเพิ่มเติมบน Ailoot.