บั๊กที่แย่ที่สุดไม่ใช่บั๊กที่ทำให้ระบบล่ม แต่มันคือบั๊กที่เห็นดีเห็นงามไปกับคุณ
ผมเรียนรู้เรื่องนี้ด้วยบทเรียนราคาแพงในขณะที่กำลังสร้าง Suhail ซึ่งเป็น orchestrator ที่ออกแบบมาเพื่อประสานงาน subagent เฉพาะทาง 5 ตัวภายใน Claude Code โดยแต่ละตัวมีบทบาทที่แตกต่างกัน: นักวิจัย (researcher) เพื่อรวบรวมบริบท, นักวางแผน (planner) เพื่อย่อยงาน, นักเขียนโค้ด (coder) เพื่อเขียนการทำงานจริง, ผู้ตรวจสอบ (reviewer) เพื่อตรวจทานผลลัพธ์ และผู้ตรวจสอบความถูกต้อง (auditor) เพื่อเช็คการถดถอย (regressions) แนวคิดนั้นตรงไปตรงมามาก คือ orchestrator จะอ่านคำขอ ตัดสินใจว่าใครต้องทำอะไร จากนั้นจึงกระจายงานแบบขนาน (parallel) แต่สิ่งที่ผมได้รับกลับเป็นเพียงการพูดคนเดียวอย่างสุภาพ หน้าต่างเดียว ตัวแทนเดียว และโมเดลที่ยุ่งอยู่คนเดียว ทำทุกอย่างด้วยตัวเองในขณะที่ยังยืนยันว่าได้กระจายงานไปแล้ว
ไม่มีสัญญาณเตือนภัย ไม่มี error logs การทำงานเสร็จสิ้นอย่างราบรื่น ผมต้องใช้เวลานานกว่าจะยอมรับได้ว่า Suhail ไม่เคยสร้าง subagent ขึ้นมาเลยแม้แต่ตัวเดียว
กับดักโฟลเดอร์ Agents
สาเหตุหลักนั้นเรียบง่ายจนเกือบจะน่าขัน ผมวางไฟล์ orchestrator ไว้ข้างในโฟลเดอร์ agents
ใน Claude Code โฟลเดอร์นั้นไม่ใช่แค่ตู้เก็บเอกสาร แต่มันคือโรงหล่อ (forge) หากคุณวางไฟล์ลงไปในนั้น ระบบจะกำหนดให้ไฟล์นั้นเป็น subagent ซึ่งตัวตนนี้จะมาพร้อมกับสิทธิ์การใช้งานต่างๆ ในขณะนั้น subagent ยังไม่สามารถเรียกใช้เครื่องมือ Agent ได้ พวกเขาเป็นเพียงคนงาน ไม่ใช่หัวหน้างาน และเพราะ Suhail อาศัยอยู่ท่ามกลางคนงาน Claude Code จึงปฏิบัติกับมันเหมือนเป็นคนงานคนหนึ่ง ดังนั้นเมื่อคำสั่งของผมบอกให้ orchestrator "dispatch the researcher" (กระจายงานให้นักวิจัย) มันจึงพยายามเรียกใช้เครื่องมือที่มันไม่มี
ซอฟต์แวร์แบบดั้งเดิมจะแจ้ง exception ทันทีตรงนั้น: เครื่องมือหายไป การเรียกใช้ล้มเหลว แต่นี่ไม่ใช่โลกของ agentic LLMs เมื่อโมเดลหาเครื่องมือที่ถูกต้องไม่เจอ มันจะไม่หยุด แต่มันจะ "ด้นสด" Suhail เห็นคำสั่งให้กระจายงานให้นักวิจัย แต่มันไม่พบเครื่องมือ Agent ในชุดเครื่องมือของมัน มันจึงลงมือทำวิจัยด้วยตัวเองเสียเลย จากนั้นก็ไปวางแผน เขียนโค้ด ตรวจทานโค้ดของตัวเอง และตรวจสอบการตรวจทานของตัวเอง ผลลัพธ์ที่ได้ดูสมเหตุสมผล บันทึกการทำงาน (transcript) อ่านดูเหมือนโปรเจกต์ที่ดำเนินไปอย่างดี แต่สถาปัตยกรรมนั้นเป็นเพียงเรื่องเพ้อฝัน
นี่คือสิ่งที่ทำให้ความล้มเหลวนี้อันตรายมาก การที่ระบบล่มจะส่งสัญญาณบอกคุณ แต่การแทนที่อย่างเงียบเชียบนั้นไม่ โมเดลไม่ได้กำลังหลอกลวง แต่มันกำลังพยายามช่วยเหลือจนเกินเหตุ เมื่อได้รับเป้าหมายและพบช่องว่างในความสามารถ มันจะเติมเต็มช่องว่างนั้นด้วยการใช้เหตุผลของมันเอง ผลลัพธ์คือระบบที่รายงานว่าสำเร็จ ในขณะที่กำลังข้ามขั้นตอนโครงสร้างที่คุณสร้างขึ้นมาอย่างเป็นระบบ
วิธีแก้ไข และทำไมมันถึงได้ผล
การแก้ไขนั้นไม่มีอะไรมากไปกว่าการย้ายไฟล์ orchestrator ออกจากโฟลเดอร์ agents และเปลี่ยนมันให้เป็น slash command
Slash commands ใน Claude Code จะอยู่ในระดับบนสุดของ session พวกมันไม่ใช่ subagent แต่เป็นจุดเข้าใช้งานสำหรับผู้ใช้ จากตำแหน่งนั้น เครื่องมือ Agent จะพร้อมใช้งาน และในที่สุด orchestrator ก็สามารถทำหน้าที่ที่แท้จริงได้เสียที นั่นคือการสร้างคนงาน มอบหมายงาน และรอรับผลลัพธ์จริงที่ส่งกลับมา ผู้เชี่ยวชาญทั้งห้าเริ่มทำงานในบริบทของตัวเอง การทำงานแบบขนานเกิดขึ้นจริง และลำดับขั้น (hierarchy) ก็เริ่มมีความหมายขึ้นมา
แต่ความเปราะบางที่อยู่เบื้องหลังไม่ได้หายไปเพียงเพราะคุณจัดโครงสร้างโฟลเดอร์ถูกต้อง แม้ว่า orchestrator จะอยู่ในตำแหน่งที่ถูกต้องแล้ว แต่ความเสี่ยงเฉพาะ 3 ประการก็ยังสามารถทำให้ทุกอย่างพังลงได้อีกครั้ง
สามความเสี่ยงที่ยังคงแฝงตัวอยู่
รายการเครื่องมือที่ถูกคัดสรรไว้ (Curated tool lists). Claude Code อนุญาตให้คุณกำหนดได้ว่า subagent แต่ละตัวสามารถเข้าถึงเครื่องมือใดได้บ้าง สิ่งนี้มีประโยชน์ในแง่ความปลอดภัยแบบ least-privilege แต่ในขณะเดียวกันมันก็เป็นสิ่งที่อาจสร้างปัญหาให้ตัวเองได้ง่ายๆ หากคุณสร้างรายการเครื่องมือแบบกำหนดเองสำหรับ subagent และลืมใส่เครื่องมือ Agent เข้าไป subagent ตัวนั้นจะกลายเป็นโหนดปลายทาง (leaf node) ที่ไม่สามารถสร้างคนงานเพิ่มได้ หากการออกแบบของคุณคาดหวังให้มันประสานงาน agent ชั้นอื่น การกระจายงานจะล้มเหลวอย่างเงียบเชียบเหมือนที่เกิดขึ้นกับ Suhail โมเดลจะเห็นคำสั่ง เห็นว่าไม่มีเครื่องมือ และจัดการงานนั้นด้วยตัวเอง
ขีดจำกัดความลึก (Depth limits). Claude Code มีการจำกัดการซ้อนกัน (nesting cap) โดย subagent สามารถสร้าง subagent อื่นๆ ต่อลงไปได้ลึกสูงสุด 5 ระดับ หากถึงขีดจำกัดนั้น เครื่องมือ Agent จะหายไป นี่ไม่ใช่บั๊ก แต่มันคือเกราะป้องกัน (guardrail) ไม่ให้เกิดการเรียกซ้ำ (recursion) ที่ควบคุมไม่ได้ แต่หากสถาปัตยกรรมของคุณคาดหวังการมอบหมายงานในระดับที่หก ชั้นนั้นจะสลายตัวไปอย่างเงียบๆ agent ในระดับที่ห้าจะดูดซับงานที่ควรจะเป็นของลูกๆ ของมันเข้ามาทำเอง โครงสร้างแบบต้นไม้ของคุณจะแบนราบกลายเป็นพุ่มไม้ และคุณอาจจะไม่สังเกตเห็นเลยจนกว่าคุณจะตรวจสอบที่มาที่ไป (provenance) ของแต่ละผลลัพธ์
Session tools. Certain tools, like AskUserQuestion, are bound to the top-level session. They do not travel into subagents. If a dispatched worker hits an ambiguity and tries to ask for clarification, it cannot. The tool is missing. Instead of alerting the user, the model will guess. It will infer what you probably meant. Sometimes it guesses well. Sometimes it builds the wrong feature. Either way, you never got the chance to answer.
How to Catch It Before It Costs You
You cannot prevent every misconfiguration, but you can stop trusting the transcript as proof of work.
Reading the conversation is the first line of defense. If the text says "dispatching the researcher" but the actual research content appears inline in the same window, the dispatch never happened. The model narrated an action and then performed the action itself. Claude Code's own panel will corroborate this. Check the descendants count for any agent you expect to have spawned children. If it shows zero, your hierarchy is imaginary.
Those visual checks are useful, but they still rely on human attention. The better approach is to harden the system with artifact verification.
After every dispatch, my system now checks for a specific, expected file. The researcher must produce a research.md. The coder must leave a diff. The reviewer must write a review_notes.json. If the file does not exist, the pipeline stops immediately. No exceptions, no graceful degradation. The orchestrator halts and reports that the dispatch failed. This shifts the burden from the model's narration to concrete deliverables.
Do not encode your constraints and hope the model respects them. Encode checks that prove the constraints were met. A model can ignore a rule in a prompt. It cannot ignore a missing file that the next step depends on.
Build for Disbelief
The lesson of Suhail is not just about Claude Code folder conventions. It is about the broader reality of building with agentic systems. These models are optimizers. When the path you laid out is blocked, they will find another path. Often that path is a shortcut through their own weights. They will do the work themselves, skip the handoff, and deposit a plausible result at your feet.
Your job as the builder is to remain skeptical. Assume the dispatch failed until the artifact proves otherwise. Design your orchestration layer not just to assign tasks, but to verify that the assignment was accepted by the right worker. Structure is cheap. Verification is what keeps the structure honest.
Source: Why Your Claude Code Orchestrator Silently Stops Dispatching Subagents
Join the discussion: GyaanSetu AI Community on Telegram