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

ฉากนี้คือจุดตั้งต้นของ The Orchestrator's Tax งานเขียนของ Rahul Garg ที่เผยแพร่บน martinfowler.com เมื่อ 16 กรกฎาคม 2026 คำถามแรกที่ดูเข้าท่าคือสี่ตัวพร้อมกันมันเยอะเกินไปหรือเปล่า แต่พอไล่ดูจริงกลับไม่ใช่ ต้นทุนก้อนที่ทำให้สะดุดไม่ได้ไปตกที่ agent ลูกที่วิ่งอยู่เบื้องหลัง แต่มันไปตกอยู่กับตัวคุมงานเอง

ปล่อย subagent สี่ตัวแล้วงานเร็วขึ้นจริง

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

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

ปรากฏว่าต้นทุนก้อนที่ทำให้ตกใจ กลับไม่ได้อยู่ตรงนั้น

เช็กสถานะครั้งเดียว บันทึกดิบไหลกลับเข้าเธรดหลัก

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

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

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

จ่ายค่าโทเคนครั้งเดียวจบ แต่ context ไม่จบ

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

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

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

context window ใหญ่ขึ้นก็ไม่ได้แก้เรื่องนี้

ความเข้าใจผิดถัดมาคือคิดว่านี่เป็นปัญหาเรื่องพื้นที่ไม่พอ แล้วเชื่อว่าพอ context window หรือขนาดความจำสูงสุดของ AI โตขึ้นเรื่อยๆ เดี๋ยวเรื่องนี้ก็หายไปเอง

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

เรื่อง context window ที่กลายเป็นกำแพงจริงของงานขนาดใหญ่ เคยเล่าไว้แล้วในโพสต์ Beyond the Basics กับ Claude Code ที่เทียบให้ดูว่าเครื่องมือแต่ละแบบกินพื้นที่ต่างกันอย่างไร แต่ของที่กินพื้นที่ไม่ได้มีแค่เครื่องมือ ของที่ตัวคุมเผลอรับกลับเข้ามาเองก็กินเหมือนกัน

อีกสองต้นทุนที่โผล่ในเซสชันเดียวกัน

พอเลิกมองเซสชันเป็นค่าใช้จ่ายก้อนเดียว ภาพก็แตกออกเป็นชิ้นที่ไม่ได้อยู่กลุ่มเดียวกันเลย

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

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

cognitive locality จัดกลุ่มงานตามชุดความเข้าใจที่มันต้องใช้

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

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

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

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

กติกาที่ก๊อปไปวางในไฟล์ CLAUDE.md ได้เลย

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

ผู้เขียนแจกไฟล์ตัวจริงไว้บน GitHub Gist ในชื่อ subagent-cost-economy.md กติกาหลักในนั้นมีประมาณนี้

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

ข้อจำนวนต่อรอบคือข้อที่สวนทางกับทิศทางของเครื่องมือยุคนี้ตรงๆ เพราะฝั่งเครื่องมือเองวิ่งไปทางเพิ่มจำนวน อย่างที่เคยเล่าไว้ในโพสต์ Dynamic Workflows ที่ให้สคริปต์สั่ง subagent พร้อมกันได้สูงสุด 1,000 ตัวต่อการรัน ตัวเลขที่เครื่องมือรองรับได้ กับตัวเลขที่ปล่อยแล้วงานยังออกมาดี จึงเป็นคนละตัวกัน

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

เวอร์ชันภาษาไทยที่ย่อจากกติกาชุดนี้หน้าตาประมาณข้างล่าง ก๊อปไปใส่ไฟล์ CLAUDE.md ของโปรเจกต์ได้เลย ถ้าเครื่องมือที่ใช้อ่านไฟล์ AGENTS.md ก็วางไว้ที่ไฟล์นั้นแทน

## กติกาการแจกงานให้ subagent

หลักการ: ปกป้อง context ของเธรดหลัก แจกงานออกไปเพื่อรักษาคุณภาพการคิด ไม่ใช่เพื่อให้ขนานกันได้เยอะที่สุด

- ต้องอ่านเกินสามไฟล์หรือยังไม่คุ้นโซนนั้น ให้ส่ง subagent ไปอ่านพร้อมคำถามที่แคบชัด แล้วรับกลับมาแค่ข้อสรุป
- อ่านตรงในเธรดหลักเฉพาะจุดเล็กที่รู้ตำแหน่งแล้ว ไฟล์ใหญ่ให้ grep หาตำแหน่งก่อน แล้วอ่านด้วย offset/limit
- ก่อนปล่อย agent ระบุให้ชัดว่าตัวไหนถือไฟล์ไหน คนที่เขียนพร้อมกันต้องไม่ถือทับกัน ถ้าเลี่ยงไม่ได้ให้แยก worktree
- จัดกลุ่มงานตามชุดความเข้าใจที่ต้องใช้ ไม่ใช่ตามจำนวนงาน งานที่ใช้ระบบ ไฟล์ หรือธรรมเนียมเดียวกัน ให้ยุบเป็นตัวเดียว
- ระบุสกิลที่ต้องใช้ทุกครั้ง และชี้ไปที่ไฟล์สกิล ห้ามก๊อปเนื้อสกิลทั้งก้อนใส่พรอมต์
- ผลลัพธ์ก้อนใหญ่ให้เขียนลงไฟล์ แล้วส่งกลับมาแค่ที่อยู่ของไฟล์
- ปล่อยรอบละสองถึงสี่ตัว เกินสี่ให้จัดกลุ่มก่อน ห้าตัวขึ้นไปที่ยังไม่จัดกลุ่มคือสัญญาณให้ยุบงาน
- ห้ามใส่คำสั่ง git ระดับทั้งรีโพลงในพรอมต์ของ agent ที่รันพร้อมกัน
- ถ้าถูกถามสถานะของงานเบื้องหลัง ให้ตอบจากสิ่งที่รู้อยู่แล้ว ห้ามดึงบันทึกดิบของ agent กลับเข้าเธรดหลัก

เขียนกติกาให้เป็นข้อเท็จจริง ไม่ใช่ขั้นตอนอนุมัติ

มีอีกตอนหนึ่งที่น่าเก็บไว้ ตอนที่ผู้เขียนเพิ่งรู้ว่า subagent ไม่ได้รับสกิลติดตัวไปเอง ทางแก้แรกที่นึกออกคือบังคับให้ตัวคุมขออนุมัติจากคนก่อนปล่อย agent ทุกรอบ

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

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

ตัวเลขในนี้ไม่ใช่ค่ามาตรฐานของทุกคน

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

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

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

ที่มา:

• บทความ The Orchestrator's Tax จาก martinfowler.com
• ไฟล์ CLAUDE.md · subagent delegation rules บน GitHub Gist