บทความ
หยุด Fan-out แบบไม่คิดหน้าคิดหลัง: สถาปัตยกรรม 4 เลเยอร์จัดสรรงานจริงด้วย Claude Haiku 5.5
Claude Haiku 5.5 ทั้งเร็วและราคาถูก แต่การโยนงานทั้งหมดให้มันทำแบบขนานมีแต่จะขยายผลการตัดสินใจผิดพลาด, ความลำเอียงในการรีวิว และความเสี่ยงด้าน Supply Chain บทความนี้ชำแหละสถาปัตยกรรมแบบแบ่งเลเยอร์: Fable ตัดสินใจ, Opus จัดสรร, Sonnet กับ Haiku ลงมือทำ, CI ตรวจสอบ และ Opus ตรวจรับงาน พร้อมเจาะลึกว่างานแบบไหนถึงคุ้มค่ากับการทำ Fan-out
· อ่าน 2 นาที
Claude Haiku 5.5 เปิดตัวเมื่อวันที่ 7 ตุลาคม 2026 เมื่อ prompt ไม่เกิน 100,000 tokens ราคาของมันคิดเป็นเพียง 1 ใน 20 ของ Sonnet 5.5 แถม latency ยังเร็วที่สุดในบรรดาโมเดลตระกูล Claude ยุคปัจจุบัน
ทั้งถูกทั้งเร็วแบบนี้ จึงชวนให้คิดง่ายๆ ว่า: ซอยงาน coding ทั้งหมดแยกออกจากกัน แล้วโยนขนานไปให้ฝูง Haiku จัดการให้เสร็จๆ ไปก็น่าจะพอ
ช่วงทำโปรโตไทป์ วิธีนี้อาจจะพอถูไถไปได้ แต่พอเอามาใช้ในสภาพแวดล้อมวิศวกรรมระดับโปรดักชันจริง คุณจะสะดุดกับ 3 ปัญหานี้ทันที:
- โมเดลขนาดเล็กไม่เหมาะกับการจัดการความคลุมเครือ จุดยืนอย่างเป็นทางการของ Haiku 5.5 คือการจำแนกประเภท, ดึงข้อมูล, ทำเราติ้ง และงานแนว subagent ที่เน้นปริมาณงานสูงและต้องการ latency ต่ำ หาก requirements ยังมีความคลุมเครือทางธุรกิจและจำเป็นต้องเข้าใจบริบทของทั้งระบบ มันมีโอกาสสูงมากที่จะส่งมอบผลลัพธ์ที่ดูเผินๆ เหมือนจะสมบูรณ์ แต่จริงๆ แล้วเดาผิดทิศทางไปคนละเรื่อง
- การให้โมเดลเลือกคำตอบเอง จะเกิดความลำเอียงในการรีวิว ถ้าโยนผลงานหลายสิบชิ้นให้โมเดลใหญ่ช่วยอ่าน มันมักจะเลือกเวอร์ชันที่ "โครงสร้างดูสวยงาม" มากกว่าเวอร์ชันที่ลอจิกและการทำงานถูกต้องจริงๆ
- สิทธิ์การเข้าถึงจะบานปลายตามจำนวน Worker หากอนุญาตให้ subagent ที่ทำงานขนานกันสามารถติดตั้งแพ็กเกจหรือแก้คอนฟิกได้เองโดยอัตโนมัติ การเปิด Worker จำนวน N ตัว ก็เท่ากับเพิ่มช่องทางเสี่ยงนำเข้าแพ็กเกจอันตรายเข้ามาถึง N ช่องทาง
ผมจึงเปลี่ยนมาใช้ การจัดสรรงานแบบแบ่งเลเยอร์ (Hierarchical Orchestration) แทน: โดยให้แต่ละเลเยอร์ทำเฉพาะสิ่งที่ตัวเองถนัด และดึงพลังการทำงานแบบขนานของ Haiku มาใช้เฉพาะในจุดที่จำเป็นจริงๆ เท่านั้น
สรุปหัวใจสำคัญก่อน: Fable มีหน้าที่คิดให้รอบคอบ, Opus รับผิดชอบการแจกจ่ายงานและตรวจรับ, Sonnet จัดการงานอิมพลีเมนต์หลัก, ส่วน Haiku ทำเฉพาะงานรูทีนที่เป็นกลไกซ้ำๆ หรืองานค้นหาที่ตรวจสอบผ่านระบบอัตโนมัติได้ โดยทุกตัวเลือกต้องผ่าน CI ก่อน แล้วค่อยส่งให้โมเดลประเมิน
สถาปัตยกรรม 4 เลเยอร์: ตัดสินใจ, จัดสรร, ตรวจสอบ, ตรวจรับงาน#
รับ Requirements เข้ามา
│
▼
[เลเยอร์ตัดสินใจ] Fable: ตัดสินใจเชิงสถาปัตยกรรม, ซอยย่อยงาน, กำหนด Acceptance Criteria
│
▼
[เลเยอร์จัดสรร] Opus Main Session: แจกจ่ายงานเท่านั้น ไม่ซอยย่อยงานซ้ำ
├─► เส้นทาง A: ซับซ้อนแต่ขอบเขตชัดเจน ──► Sonnet อิมพลีเมนต์
├─► เส้นทาง B: งานรูทีนซ้ำๆ ──► Haiku ตัวเดียว
├─► เส้นทาง C: งานค้นหา มีวิธีแก้หลายแบบ ──► Haiku หลายตัว แยกกันทำบน Git Worktree ละตัว
│
▼
[เลเยอร์ตรวจสอบ] Build, Type Check, Test, Benchmark (เส้นทาง C คัดเหลือเฉพาะอันดับท็อป 2–3 ตัว)
│
▼
[เลเยอร์ตรวจรับงาน] Opus สรุปผลลัพธ์ตาม Acceptance Criteria
หากล้มเหลวให้ส่งต่อตาม Escalation Path: Haiku แก้ไข 2 ครั้งแล้วยังไม่ผ่าน ➔ Sonnet ➔ ส่งกลับ Opus
การจัดวางว่าโมเดลไหนควรอยู่เลเยอร์ใด พิจารณาจากจุดยืนอย่างเป็นทางการและราคาเป็นหลัก ด้านล่างนี้คือตัวเลขจากเอกสารทางการของ Anthropic ณ วันที่ 8 ตุลาคม 2026 โดยมีหน่วยราคาเป็นดอลลาร์สหรัฐต่อ 1 ล้าน tokens:
| โมเดล |
จุดยืนอย่างเป็นทางการ |
Latency |
ราคา Input / Output |
| Claude Fable 5.1 |
งานที่ต้องใช้การให้เหตุผลขั้นสูงและงาน agentic ที่ใช้เวลานาน |
ค่อนข้างช้า |
$10 / $50 |
| Claude Opus 5.5 |
งาน agentic coding และงานด้านความรู้ที่ใช้เวลานาน |
ปานกลาง |
$4 / $20 |
| Claude Sonnet 5.5 |
การผสมผสานที่ลงตัวที่สุดระหว่างความเร็วและความสามารถ |
เร็ว |
$2 / $10 |
| Claude Haiku 5.5 |
งานจำแนกประเภท, ดึงข้อมูล, เราติ้ง และ subagent ที่เน้นปริมาณงานสูงและต้องการ latency ต่ำ |
เร็วที่สุด |
เริ่มต้น $0.10 / $0.50 |
โครงสร้างราคาของ Haiku 5.5 แบ่งออกเป็น 2 ระดับ: หาก prompt เกิน 100,000 tokens ราคาจะปรับขึ้นเป็น $0.50 / $2.50
เลเยอร์ตัดสินใจ: Fable รับผิดชอบการตัดสินใจเชิงสถาปัตยกรรมและกำหนดเกณฑ์ตรวจรับงาน#
ไม่ใช่ว่าทุกงานจะต้องใช้ Fable เพราะนี่คือเลเยอร์ที่แพงและช้าที่สุด ผมจะเลือกใช้ก็ต่อเมื่อ requirements มีความคลุมเครือ, ต้องเชื่อมต่อข้ามหลายระบบ หรือจำเป็นต้องตัดสินใจเรื่องสถาปัตยกรรมหลักของระบบเท่านั้น
ผลลัพธ์ 3 อย่างที่ Fable ต้องส่งมอบ ได้แก่:
- การออกแบบโซลูชัน
- การซอยย่อยงานออกเป็นส่วนๆ
- เกณฑ์การตรวจรับงาน (Acceptance Criteria) สำหรับแต่ละงานย่อยที่สามารถตรวจสอบผ่านเทสต์ได้
กระบวนการให้เหตุผลและการซอยย่อยงานต้องทำจบในเลเยอร์เดียวกัน เพราะเลเยอร์ที่มองเห็นจุดบอดของระบบได้ทะลุปรุโปร่งเท่านั้น ถึงจะแบ่งขอบเขตของงานย่อยออกมาได้คมกริบและไม่ทับซ้อนกัน หากให้โมเดล A ออกแบบสถาปัตยกรรม แล้วให้โมเดล B ซอยย่อยงาน คำนิยามของอินเทอร์เฟซมักจะคลุมเครือและไม่ชัดเจน
แต่งานด้านความปลอดภัยถือเป็นข้อยกเว้น โมเดล Claude ยุคปัจจุบันมีตัวจำแนกความปลอดภัย (safety classifier) ติดตั้งอยู่ หากคำขอถูกบล็อก ระบบจะส่งค่า stop_reason: "refusal" กลับมา ซึ่งงานความปลอดภัยที่ถูกกฎหมายก็อาจโดนบล็อกแบบผิดพลาดได้เช่นกัน ตัวจำแนกของ Fable 5.1 นั้นครอบคลุมเนื้อหาความปลอดภัยเกือบทั้งหมด และเอกสารทางการระบุชัดเจนว่าไม่ได้ออกแบบมาสำหรับงาน cybersecurity โดยเฉพาะ ในขณะที่ Opus 5.5 อนุญาตให้ค้นหาช่องโหว่ในซอร์สโค้ดได้ ดังนั้น งานประเภทการแก้ไขช่องโหว่ความปลอดภัย ผมจะส่งให้ Opus ทำหน้าที่วิเคราะห์ส่วนหน้าไปเลยโดยตรง
เลเยอร์จัดสรร: Opus ทำหน้าที่แจกจ่ายงานเท่านั้น ไม่ซอยย่อยงานซ้ำ#
Opus รับบทเป็น Main Session มีหน้าที่ดูแลการทำเราติ้งและจ่ายงาน เลเยอร์นี้จะไม่รื้อสถาปัตยกรรมใหม่ และไม่นำงานมาซอยย่อยซ้ำรอบสอง
- เส้นทาง A, ซับซ้อนแต่ขอบเขตชัดเจน: งานที่มีลอจิกซับซ้อน แต่กำหนดขอบเขตของอินเทอร์เฟซไว้ชัดเจนแล้ว จะส่งให้ Sonnet จัดการ ซึ่งถือเป็นกำลังหลักในฝั่งอิมพลีเมนต์
- เส้นทาง B, งานรูทีนซ้ำๆ แบบตรงไปตรงมา: การเขียนโค้ด Boilerplate, การเปลี่ยนชื่อตัวแปร, การเขียนยูนิตเทสต์แบบพื้นฐาน, การอัปเดตเอกสาร จะส่งให้ Haiku ตัวเดียวจัดการ
- เส้นทาง C, งานค้นหาและงาน Optimize: การจูนประสิทธิภาพ, การเขียน SQL หรือ Regex ที่ซับซ้อนได้หลายรูปแบบ, การไล่เช็ก Flaky Test กรณีเหล่านี้ถึงจะเปิดใช้งาน Fan-out: โดยส่ง Haiku หลายตัวแยกกันไปลองหาทางแก้ปัญหาใน Git Worktree อิสระของแต่ละตัว
ไม่ว่าจะเลือกเดินผ่านเส้นทางไหน โค้ดที่ได้จะต้องถูกส่งเข้าเลเยอร์ตรวจสอบเสมอ
เลเยอร์ตรวจสอบ: ตรวจด้วยเครื่องจักรก่อน ค่อยให้โมเดลดู#
วิธีที่คนมักทำกันบ่อยๆ คือการนำโค้ดที่รันคู่ขนานกันทั้งหมดส่งไปให้ Opus หรือ Sonnet ตรวจสอบด้วย prompt ทันที
ปัญหาคือ เวลาโมเดลอ่านโค้ด มันมักจะถูกดึงดูดด้วยคำตอบที่จัดหน้าเรียบร้อยและประกาศ Type ไว้อย่างครบถ้วน แต่นั่นไม่ได้แปลว่ามันผ่านการทดสอบกรณีขอบเขต (edge cases) ต่างๆ จริง ดังนั้น โค้ดที่ส่งเข้าประกวดต้องผ่านด่านเครื่องจักรเหล่านี้ให้ได้ก่อน:
- Build และ Type Check: ต้องคอมไพล์ผ่าน และ Type ถูกต้อง
- Unit / Integration Tests: ต้องผ่านทั้งยูนิตเทสต์และอินทิเกรชันเทสต์
- Benchmark / Profiling: วัดผลประสิทธิภาพและการใช้หน่วยความจำจริง
โค้ดที่ไม่ผ่านการทดสอบอัตโนมัติจะถูกคัดทิ้งทันที สำหรับตัวเลือกจากเส้นทาง C นั้น Opus จะเปิดอ่านเฉพาะ 2–3 อันดับแรกที่ผ่านการทดสอบและได้คะแนนตัวชี้วัดดีที่สุดเท่านั้น ซึ่งช่วยประหยัดทั้ง context window และ token ไปได้มหาศาล
เลเยอร์ตรวจรับงาน: Opus สรุปผลลัพธ์ หากล้มเหลวให้ยกระดับขึ้นไป#
ขั้นตอนสุดท้าย Opus จะรวบรวมและสรุปผลลัพธ์ตาม Acceptance Criteria ที่เลเยอร์ตัดสินใจกำหนดไว้ หาก Worker เกิดติดขัด ให้ยกระดับขึ้นไปตามลำดับ (Escalation Path):
- หาก Haiku ล้มเหลวและพยายามแก้ไขอัตโนมัติครบ 2 ครั้งแล้วยังไม่ผ่าน ให้หยุดลองซ้ำทันที
- ส่งต่อให้ Sonnet มารับช่วงต่อเพื่อแก้ไข
- หาก Sonnet ยังไม่สามารถผ่านการตรวจรับได้ มักสะท้อนว่าการซอยย่อยงานหรือสมมติฐานเริ่มต้นมีจุดขัดแย้ง งานจะถูกตีกลับไปที่ Opus เพื่อให้ Opus พิจารณาว่าจะส่งกลับไปให้ Fable ซอยย่อยงานใหม่หรือไม่
กฎ 3 ข้อก่อนนำไปขึ้นโปรดักชันจริง#
อย่าทำ Fan-out แบบไม่ลืมหูลืมตา#
งานง่ายๆ ไม่จำเป็นต้องใช้ Worker หลายตัว ส่วนงานที่ความคลุมเครือสูง โมเดลเล็กก็แก้ไม่ตกอยู่ดี จะมีก็แต่งานค้นหาที่มี "ขอบเขตวิธีแก้ปัญหากว้าง" และ "สามารถตรวจสอบผลได้รวดเร็วผ่านการทดสอบอัตโนมัติ" เท่านั้น ที่คุ้มค่ากับการสั่งให้ Haiku หลายตัวทำงานแบบขนานกัน
แยกสภาพแวดล้อมให้ขาด และล็อก Lockfile ให้แน่น#
Git Worktree ช่วยแยกเฉพาะการเปลี่ยนแปลงของโค้ด เพื่อไม่ให้ Worker ที่รันขนานกันเขียนไฟล์ทับกันเอง แต่มันไม่ได้จำกัดการเข้าถึงเครือข่าย หรือจำกัดสิทธิ์ที่โปรแกรมสามารถเข้าถึงได้เลย การป้องกัน Supply Chain Attack จึงจำเป็นต้องรันใน sandbox และสั่งห้ามไม่ให้ Worker แอบติดตั้งแพ็กเกจที่ไม่ผ่านการตรวจสอบหรือแก้ไข Lockfile เองโดยเด็ดขาด การปล่อยสิทธิ์การติดตั้งไว้อย่างหละหลวม ก็เท่ากับเปิดทางให้ Agent ลากแพ็กเกจและสคริปต์ที่ไม่รู้ที่มาที่ไปเข้ามาสู่โค้ดเบสของคุณ
ตรวจรับงานด้วยตัวเลขที่วัดผลได้จริง ไม่ใช่พึ่งพาคอมเมนต์จากโมเดล#
ผลการรันเทสต์, โค้ด coverage, ปริมาณการใช้หน่วยความจำ และ latency คือหลักฐานที่สามารถทำซ้ำและเปรียบเทียบกันได้จริง ความคิดเห็นเป็นตัวหนังสือของโมเดลเอาไว้ใช้อ้างอิงได้ แต่ห้ามนำมาใช้เป็นเกณฑ์ตัดสินตรวจรับคุณภาพของโค้ด
โมเดลราคาถูก ต้องหยิบมาใช้ให้ถูกที่#
Haiku 5.5 ทำให้การรันแบบขนานมีราคาถูกลงมาก แต่การรันขนานด้วยตัวมันเองไม่ได้ช่วยให้ผลลัพธ์ถูกต้องขึ้น การแยกหน้าที่ระหว่างการตัดสินใจ, การแจกจ่ายงาน, การตรวจสอบ และการตรวจรับงานออกจากกันให้ชัดเจนตั้งแต่แรกต่างหาก ที่จะเปลี่ยนความถูกและความเร็วให้กลายเป็นความได้เปรียบที่แท้จริง
การแบ่งเลเยอร์แบบนี้ แท้จริงแล้วก็คือ Graph ในแบบที่ผมเคยเล่าไว้ในบทความ AI Agent ก็คือทีม Agile ดีๆ นี่เอง: ใครเริ่มทำก่อน ทำเสร็จแล้วส่งต่อให้ใคร และเมื่อเกิดปัญหาต้องส่งต่อให้ใครรับผิดชอบ