Fan out subagent ใน Claude Code แล้วตรวจสิ่งที่ส่งกลับมา

ผู้คนพิมพ์ "claude fan out subagents" ลงใน Google และไม่น้อยที่เติมคำว่า "command" ไว้ท้าย ราวกับว่ามีสวิตช์ให้กด รูปแบบการทำงานแบบนี้มีอยู่จริง และมีคำสั่งด้วย เราตรวจทั้งสองอย่างบน Claude Code 2.1.301 และเทียบกับเอกสารของ Anthropic เมื่อวันที่ 16 ตุลาคม 2026

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

คำตอบสั้นๆ

Fan out คือการที่เซสชันหนึ่งแบ่งงานออกเป็นชิ้นงานที่ไม่ขึ้นต่อกัน มอบแต่ละชิ้นให้ subagent ปล่อยให้พวกมันรันพร้อมกัน แล้วรวมสิ่งที่ส่งกลับมา ใน Claude Code คุณทำได้สามวิธี

ส่วนที่เหลือของหน้านี้จะไล่ดูทีละวิธี แล้วต่อด้วยการตรวจที่เราใช้กับ fan-out ของเราเอง

สิ่งที่ subagent มองเห็นและมองไม่เห็น

ข้อเท็จจริงสามข้อจากเอกสารเป็นตัวกำหนดว่าคุณควรแบ่งงานอย่างไร

Subagent แต่ละตัวเริ่มจากศูนย์ มันรันในหน้าต่างบริบทของตัวเอง มี system prompt เครื่องมือ และสิทธิ์ของตัวเอง มันไม่เห็นบทสนทนาของคุณ ไม่เห็น skill ที่คุณใช้ไปแล้ว และไม่เห็นไฟล์ที่ Claude อ่านไปแล้ว อะไรก็ตามที่มันต้องรู้ต้องอยู่ในบรีฟของมัน

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

มีขีดจำกัด ค่าเริ่มต้นคือรัน subagent ได้พร้อมกัน 20 ตัวในหนึ่งเซสชัน ตัวที่ 21 จะล้มเหลวพร้อม Concurrent subagent limit reached และข้อผิดพลาดนี้บอก Claude ว่าไม่ต้องลองใหม่ คุณปรับขึ้นหรือลงได้ด้วย CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS subagent เริ่ม subagent ของตัวเองได้ ลึกลงไปได้สามชั้นใต้บทสนทนาหลัก และจำนวนรวมตลอดเซสชันไม่มีขีดจำกัด

วิธีที่ 1: ขอด้วยคำพูดธรรมดา

fan-out ที่ง่ายที่สุดคือประโยคเดียว ตัวอย่างในเอกสารของ Anthropic:

Research the authentication, database, and API modules in parallel using separate subagents

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

การใช้คำพูดธรรมดาปล่อยให้ Claude เป็นผู้ตัดสินใจ ถ้าคุณกำหนด subagent แบบกำหนดเองไว้ใน .claude/agents/ การ @-mention ถึงมันจะรับประกันว่ามันจะรันสำหรับงานนั้น หน้าของเราเรื่อง subagent ของ Claude Code อธิบายว่าไฟล์เหล่านั้นทำงานอย่างไร

วิธีที่ 2: /batch สิ่งที่ใกล้เคียงคำสั่ง fan-out ที่สุด

/batch เป็น skill ที่มากับ Claude Code คุณให้คำสั่งงานกับมัน:

/batch migrate src/ from JavaScript to TypeScript

มันสำรวจโค้ดเบส แบ่งงานออกเป็น 5 ถึง 30 หน่วยที่เป็นอิสระต่อกัน และแสดงแผนให้คุณดู เมื่อคุณอนุมัติ มันจะเริ่ม subagent เบื้องหลังหนึ่งตัวต่อหนึ่งหน่วย แต่ละตัวอยู่ใน git worktree ที่แยกขาดจากกัน subagent แต่ละตัวลงมือทำหน่วยของตัวเอง รันเทสต์ และเผยแพร่การเปลี่ยนแปลงของตัวเอง สิ่งที่ต้องมีคือรีโป git หรือ hook WorktreeCreate ที่สร้าง worktree ให้กับระบบควบคุมเวอร์ชันอื่น

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

วิธีที่ 3: ลูปบน claude -p

เมื่องานคือรายการไฟล์ และคุณอยากควบคุมการเรียกทุกครั้ง แนวปฏิบัติที่ดีของ Anthropic อธิบายลูปไว้ ขั้นแรก ให้ Claude เขียนรายการขึ้นมา (list all 2,000 Python files that need migrating and save the list to files.txt) จากนั้น:

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --permission-mode dontAsk
done

รายละเอียดสามข้อในตัวอย่างนี้ควรลอกไปใช้

• คำตอบอ่านได้ด้วยเครื่อง "Return OK or FAIL" หมายความว่าสคริปต์ของคุณนับจำนวนที่ล้มเหลวได้โดยไม่ต้องอ่านข้อความยาวๆ
• สิทธิ์ถูกกำหนดไว้ล่วงหน้า --allowedTools อนุมัติเฉพาะสิ่งที่การ migrate ต้องใช้ และ --permission-mode dontAsk ปฏิเสธทุกอย่างที่เหลือ แทนที่จะรอคนที่ไม่ได้อยู่ตรงนั้น
• คุณเริ่มด้วยไฟล์สองสามไฟล์ เอกสารพูดไว้ตรงๆ ว่า ให้ปรับ prompt จากสิ่งที่ผิดพลาดกับไฟล์แรกๆ แล้วค่อยรันทั้งรายการ

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

สำหรับ CI เอกสารแนะนำให้เพิ่ม --bare ซึ่งข้าม hook, skill, เซิร์ฟเวอร์ MCP และ CLAUDE.md เพื่อให้ทุกเครื่องได้การรันแบบเดียวกัน โหมด bare ไม่ใช้การล็อกอินผ่านแพ็กเกจสมาชิกของคุณ มันต้องใช้ ANTHROPIC_API_KEY

เรา fan out ทุกคืนอย่างไร

นี่คือ fan-out ที่เราใช้งานจริง ทีม SEO กะกลางคืนของเราเขียนบทความใหม่แต่ละบทเป็นภาษาอังกฤษและภาษาฝรั่งเศสด้วยมือ จากนั้นเอเจนต์ตัวที่สองจะแปลบทความเป็นอีกสิบเจ็ดภาษาด้วย subagent ของ Claude Code และสร้างภาษาจีนตัวเต็มจากภาษาจีนตัวย่อด้วยสคริปต์แทนการแปล มีบทความสิบเอ็ดบทผ่านกระบวนการนี้มาตั้งแต่วันที่ 13 กันยายน 2026 แต่ละบทออกมาเป็นยี่สิบไฟล์

ชิ้นงาน

subagent หกตัว ตัวละสามภาษา (ตัวสุดท้ายสองภาษา): สเปน โปรตุเกส และอิตาลี; เยอรมัน ดัตช์ และโปแลนด์; รัสเซีย ยูเครน และตุรกี; ญี่ปุ่น เกาหลี และจีน; ไทย เวียดนาม และอินโดนีเซีย; อาหรับ และฮินดี ไม่มีภาษาไหนขึ้นกับภาษาอื่น และนั่นคือสิ่งที่ทำให้นี่เป็น fan-out ที่สะอาด

บรีฟแต่ละชุดมีห้าอย่างเหมือนกัน เพราะ subagent ไม่เห็นอะไรอื่นเลย:

• ต้นฉบับภาษาอังกฤษ และฉบับภาษาฝรั่งเศสเป็นแบบอ้างอิงสำหรับน้ำเสียงและคำศัพท์ของผลิตภัณฑ์
• สำหรับแต่ละภาษา ข้อความที่เผยแพร่บนเว็บไซต์ในภาษานั้นแล้ว เพื่อให้ subagent ใช้คำที่เว็บไซต์ใช้อยู่แล้วซ้ำ แทนที่จะคิดคำใหม่ขึ้นมา
• กฎเหล็ก: ชื่อแบรนด์และชื่อผลิตภัณฑ์คงไว้ตามเดิม โค้ดต้องเหมือนเดิมทุกไบต์ และห้ามใช้เครื่องหมายขีดยาว (em dash)
• สคริปต์ตรวจสอบ พร้อมคำสั่งให้รันซ้ำจนกว่าจะขึ้นว่า OK
• คำขอให้รายงานทุกอย่างที่น่าสงสัยที่มันเห็น ทั้งในชิ้นงานของตัวเองและนอกชิ้นงาน

การตรวจถูกเขียนไว้ก่อนการปล่อย

การตรวจคือสคริปต์ ไม่ใช่ความเห็นของ subagent สำหรับทุกภาษา มันเทียบไฟล์กับต้นฉบับภาษาอังกฤษ:

• slug และวันที่ตรงกัน ชื่อเรื่องตรงกับ H1
• จำนวนหัวข้อ หัวข้อย่อย รูปภาพ ลิงก์ และแถวในตารางเท่ากัน และจำนวนคำตอบ FAQ ในเนื้อหาเท่ากับจำนวนคำถามในเมทาดาทา
• ลิงก์เหมือนกันทุกไบต์ ส่วนที่เป็นโค้ดเหมือนกันทุกไบต์
• นับชื่อแบรนด์ และต้องไม่น้อยกว่าในภาษาอังกฤษ
• ความยาวอยู่ในขอบเขตที่ปรับเทียบไว้สำหรับแต่ละภาษา เพราะภาษาจีนพูดเรื่องเดียวกันด้วยจำนวนตัวอักษรราว 36 % ของที่ภาษาอังกฤษต้องใช้ และภาษาญี่ปุ่นราวครึ่งหนึ่ง
• มีเครื่องหมายกำกับเสียงในภาษาที่มีเครื่องหมายเหล่านี้ (โปแลนด์ ตุรกี เวียดนาม)

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

สิ่งที่การตรวจส่วนกลางจับได้ แต่รายงานของ subagent เองไม่ได้บอก

โค้ดถูกแปลในตาราง วันที่ 13 กันยายน subagent ราวครึ่งหนึ่งแปลคำที่ตามหลังคำสั่งซึ่งอยู่ใน backtick เดียวกันในตาราง แต่ละตัวทำตามบรีฟตามที่มันเข้าใจ การแก้ไขจึงเข้าไปอยู่ในบรีฟ ไม่ใช่ใน subagent: ส่วนที่เป็นโค้ดเก็บไว้แค่คำสั่ง และคำที่ตามมาอยู่นอก backtick

การตรวจของเราเองผิด วันที่ 6 กันยายน การตรวจความยาวที่ปรับเทียบกับข้อความเก่าที่เรากำลังแทนที่ ติดธง subagent 11 ตัวจาก 17 ตัว ทั้ง 11 ตัวถูกต้อง: ข้อความใหม่ควรจะยาวกว่า เมื่อปรับเทียบกับภาษาฝรั่งเศสที่แก้แล้วแทน มันก็ไม่ติดธงเลยสักตัว การตรวจส่วนกลางก็ผิดได้ และวิธีที่จะเห็นคือรันมันกับงานที่ส่งมาซึ่งคุณรู้อยู่แล้วว่าดีเสียก่อน

ความสอดคล้องข้ามชิ้นงาน วันที่ 15 ตุลาคม บนหน้าฟีเจอร์ใหม่ที่แปลด้วยวิธีเดียวกัน การตรวจตอนรวมงานยืนยันว่ามีเพียงข้อความที่ตั้งใจไว้เท่านั้นที่เปลี่ยนใน 90 ไฟล์ แต่ subagent ภาษาญี่ปุ่น เกาหลี และจีน ต่างเลือกชื่อหัวข้อสำหรับ "You may also like" ที่ไม่ตรงกับชื่อที่ภาษาของตัวเองใช้อยู่แล้วในหน้าข้างเคียง แต่ละตัวเลือกคำแปลที่ถูกต้อง แต่ไม่มีตัวไหนสอดคล้องกับเว็บไซต์ ไม่มี subagent ตัวไหนมองเห็นสิ่งนี้จากในชิ้นงานของตัวเอง มีแต่การตรวจบนผลลัพธ์ที่รวมแล้วเท่านั้นที่เห็น

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

รายงานจากนอกชิ้นงาน วันที่ 15 ตุลาคม subagent ที่ทำภาษาตุรกีรายงานว่าเว็บไซต์เขียนว่า "ajans" ซึ่งแปลว่าเอเจนซี แทนคำว่า "agent" ใน 97 ข้อความที่มีอยู่ มันไม่ได้แตะข้อความเหล่านั้น เพราะบรีฟของมันห้ามไว้ เราเปิดตั๋ว และการแก้ไขก็ออกไปในวันถัดมา การถาม subagent ว่ามันเห็นอะไร ไม่ใช่แค่ว่ามันทำอะไร มีต้นทุนต่ำและคุ้มค่า

การรวมงานเกิดขึ้นในที่เดียว

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

เมื่อไหร่ไม่ควร fan out

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

AgentsRoom อยู่ตรงไหน

subagent อยู่ภายในเซสชัน Claude Code เดียว คุณเห็นผลลัพธ์ของมัน ไม่เห็นการทำงานของมัน และคุณปรับทิศทางตัวใดตัวหนึ่งระหว่างทางไม่ได้ เมื่อคุณอยากให้แต่ละชิ้นงานเป็นเอเจนต์ที่คุณเฝ้าดู ตอบ และรีวิวแยกกันได้ ให้รันเซสชันแยกกันแทน: ตั๋วแต่ละใบใน git worktree ของตัวเอง และ Agent Teams เมื่อชิ้นงานต้องส่งต่องานให้กัน ขั้นตอนของทีมสามารถมีคำสั่งตรวจได้ และ exit code ของคำสั่งนั้น ไม่ใช่คำกล่าวอ้างของเอเจนต์ เป็นตัวตัดสินว่ารันจะไปต่อหรือไม่ นั่นคือกฎเดียวกับข้างบน ที่ตัวรันบังคับใช้ ใช้ได้กับ Claude Code, Codex และ CLI เอเจนต์อื่นๆ ที่ AgentsRoom รองรับ

ถ้าคุณยังตัดสินใจไม่ได้ระหว่าง subagent กับ Agent Teams บทเปรียบเทียบนี้ อธิบายว่าแต่ละอย่างมีไว้ทำอะไร