Claude Fable 5 เป็นหัว
ที่เหลือเป็นมือ

เช้าวันหนึ่งเราสลับโมเดลหลักใน Claude Code เป็น Claude Fable 5 โมเดลตระกูลใหม่ที่ Anthropic วางไว้เหนือ Opus ฉลาดขึ้นจริง แต่สิ่งที่มาพร้อมกันคือราคาต่อ token ที่สูงกว่า และโควต้าที่หมดไวกว่าเดิมมาก ใช้แบบเดิมที่เคยใช้ Opus ไม่ได้แล้ว ให้มันนั่งไล่หาไฟล์ เขียน boilerplate แก้ typo เหมือนที่เคยทำ เท่ากับเอาสมองที่แพงที่สุดในบ้านไปนั่งเดินเอกสาร

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

บทความนี้เล่าทั้งวิธีตั้งทีม ผลของงานแรก และจุดที่มันพังให้เห็น ตัวเลขทุกตัวมาจาก session จริงวันที่ 3 ก.ค. 2026 ไม่มีตัวไหนแต่งเพิ่ม

ช่วงที่ 1ทำไมโมเดลแพงสุดควรเป็นแค่ "หัว"

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

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

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

ค่าใช้จ่ายก็เป็นเหตุผลเดียวกัน โมเดลระดับ Fable โควต้าหมดไวพอที่จะบังคับให้เลือกว่างานไหนคุ้มกับสมองระดับนั้น (ตัวเลขราคาแต่ละโมเดลเราเคยแจกแจงไว้ในบทความเรื่องราคา Claude Code) พอถูกบังคับให้เลือก ก็พบว่างานส่วนใหญ่ไม่เคยต้องการโมเดลใหญ่เลยต่างหาก

ช่วงที่ 2Claude Code subagents: ตั้งทีมหัวกับมือ

Claude Code มีกลไก subagents ในตัวอยู่แล้ว (เอกสารทางการ) เราแค่สร้างไฟล์ agent สั้นๆ ไว้ที่ .claude/agents/ กำหนดว่าแต่ละตัวชื่ออะไร ใช้โมเดลไหน และรับงานแบบไหน ทีมของเราตอนนี้มีสามตัวบวกเพื่อนต่างค่ายอีกหนึ่ง

รูปแบบนี้ในชุมชน Claude Code เรียกกันว่า claude orchestrator หรือ orchestrator pattern จุดชี้ขาดไม่ได้อยู่ที่จำนวน agents แต่อยู่ที่กติกาที่เขียนกำกับไว้ให้หัวต่างหาก ของเรามีสามข้อ

1. หัวห้ามทำ grunt work เจองานค้นหา งานไล่อ่าน งานกลไกเมื่อไหร่ ให้แตกงานส่งมือทันที ถึงจะ "ทำเองก็ได้" ก็ห้าม เพราะทุก token ที่หัวเผาไปกับงานพวกนี้คือโควต้าที่หายไปจากงานคิด
2. โชว์แผนก่อนลงมือ หัวต้องแตกงานให้เห็นก่อนว่าจะส่งอะไรให้ใคร คนยังได้เห็นและท้วงได้ก่อนเงินไหลออก
3. ห้ามเอาหัวไปฝังใน daemon งานอัตโนมัติที่รันตลอดเวลาใช้โมเดลเล็กหรือกลางพอ โมเดลแพงเอาไว้เรียกเป็นครั้งๆ ตอนต้องคิดจริงเท่านั้น

ไฟล์ agent จริงกับ routing rules ฉบับเต็ม เรากำลังขัดให้เป็นชุดเครื่องมือที่หยิบไปใช้ได้เลย โครงแบบที่เล่าตรงนี้พอให้ประกอบเองได้ทั้งหมด

ก่อนใช้เพื่อนต่างค่าย มีบทเรียนราคาเล็กๆ หนึ่งเรื่อง เราทดสอบว่า Codex ต่อติดไหมด้วยการส่งคำว่า ping ไปให้ตอบ pong กลับมา คำตอบเดียวคำนั้นกินไป 26,800 tokens เพราะ agent ระดับนี้ตื่นมาพร้อม context ของมันทั้งชุด ไม่ใช่แค่คำถามที่เราส่งไป แม้แต่ "การเช็คว่าเครื่องมือใช้ได้" ก็มีราคา ต้องนับรวมในต้นทุนด้วย

ช่วงที่ 3งานจริงงานแรก: ประเมิน migration ด้วย 4 agents

โจทย์ที่เข้ามาคือเครื่องมือ CLI (โปรแกรมที่เรียกใช้ผ่าน command line) ตัวหนึ่งที่ automation ของเราใช้อยู่บนสองเครื่อง มี Rust port ตัวใหม่ออกมา น่าย้ายไหม คำถามแบบนี้ตอบมั่วง่ายมาก เพราะคำตอบที่ฟังดูฉลาด ("Rust เร็วกว่า ย้ายเลย") กับคำตอบที่ถูก อยู่คนละที่กัน

แตกงานเป็นสามมุมมอง ยิงพร้อมกัน

หัวแตกงานสำรวจออกเป็นสามชิ้นที่ไม่ต้องรอกัน แล้ว fan-out ให้มือสามตัววิ่งขนาน

• inventory เครื่องแรก (Haiku) ไล่ว่าเครื่อง Mac ใช้เครื่องมือตัวนี้จากตรงไหนบ้าง คำสั่งไหน service ไหน cron ไหน
• inventory เครื่องที่สอง (Haiku) แบบเดียวกันกับ server อีกตัว
• อ่าน repo ของ Rust port (ตัวใหญ่กว่า) เข้าไปดูว่า port ตัวนี้ครอบคำสั่งที่เราใช้ครบไหม config เข้ากันไหม โปรโตคอลระหว่างเครื่องเข้ากันไหม

ผลที่กลับมาน่าสนใจกว่าที่คิด ส่วนที่เราใช้งานจริงเล็กนิดเดียว มีแค่ 5 จุดเชื่อมกับราวๆ 9 คำสั่ง ทั้งที่ตัวเครื่องมือมีความสามารถมากกว่านั้นมาก ส่วน repo ฝั่ง port ก็มีทั้งข่าวดีและจุดที่น่าห่วง ข่าวดีคือ config ใช้ไฟล์เดิมได้และโปรโตคอลเข้ากันได้แบบพิสูจน์จากไฟล์ทดสอบจริง ไม่ใช่แค่อ่านจากเอกสาร จุดที่น่าห่วงคือ port นี้อายุ 8 วัน มี 470 commits ที่ส่วนใหญ่เป็นโค้ดที่เครื่องเขียน (machine-generated) และ flag ตัวหนึ่งที่ระบบเราพึ่งพาอยู่ทุกวัน หายไปจาก port

หัวสังเคราะห์ แล้วตัดสินใจไม่เชื่อรายงานเปล่าๆ

ถึงตรงนี้รายงานสามฉบับบอกตรงกันว่า "น่าจะย้ายได้แบบมีเงื่อนไข" แต่ทั้งหมดมาจากการอ่าน ยังไม่มีใครแตะ binary จริงเลย หัวเลยสั่งงานชิ้นที่สี่: smoke test กับของจริง แบบที่พังแล้วเสียหายเป็นศูนย์ ติดตั้ง port ตัวใหม่คู่ขนานกับตัวเดิมโดยใช้คนละชื่อ ชี้ config เดียวกัน แล้วรันเฉพาะคำสั่งอ่านอย่างเดียว ระบบจริงไม่โดนแตะแม้แต่จุดเดียว

ผล smoke test คือจุดที่งานนี้คุ้มที่สุด เพราะมันจับสิ่งที่รายงานจากการอ่านทั้งสามฉบับมองไม่เห็น

• คำสั่งกลุ่มที่เราใช้บ่อยที่สุด ใช้ไม่ได้จริง เพราะใน port ใหม่ คำสั่งกลุ่มนั้นเป็น plugin ภาษา JS ที่ port ยังโหลดไม่ได้ ตัวเช็ค (probe) ของระบบตรวจสุขภาพเราพังไป 2 ใน 3 ทันที ที่เจ็บคือตอนอ่าน repo เราเคยสรุปว่า gap เรื่อง plugin "ไม่กระทบเรา" เพราะเช็คแล้วไม่มี plugin ใน config ทั้งสองเครื่อง ความจริงคือคำสั่งพื้นฐานที่ใช้ทุกวันนั่นแหละคือ plugin
• รูปแบบคำสั่งเปลี่ยน ตัวเดิมรับ port เป็นตัวเลขต่อท้าย ตัวใหม่บังคับใส่ flag ทุกจุดที่ automation เรียกด้วยรูปแบบเดิมจะพังเงียบๆ
• การคุยข้ามเวอร์ชันยังสรุปไม่ได้ client ตัวใหม่ยิงไปหา server ตัวเดิมแล้วได้ error ที่แยกไม่ออกว่าผิดที่ลายเซ็นหรือผิดที่รูปแบบ request ต้องทดสอบแบบจับคู่จริงก่อนถึงจะรู้

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

ช่วงที่ 4จุดที่พัง กับจังหวะที่หัวต้องลงมือเอง

test เขียวที่ไม่ได้แปลว่าผ่าน

ก่อน smoke test เรามี test suite ของระบบตรวจสุขภาพอยู่แล้ว รันกับ port ใหม่ได้ 5/5 ผ่านหมด ถ้าหยุดตรงนั้นก็คงสรุปว่าเข้ากันได้ แต่พอ smoke test กับ binary จริง probe พังไป 2 ใน 3 อ้าว ทำไมขัดกัน คำตอบคือ suite นั้น mock ชั้นที่เรียก binary ไว้ มันเลยทดสอบ logic ของตัวเองโดยไม่เคยแตะ binary จริง เขียวทั้งกระดานแต่พิสูจน์อะไรไม่ได้เลย เราเรียกอาการนี้ว่า false-green

วิธีกันที่ใช้ได้จริงคือ positive control: ก่อนเชื่อผลเขียวของ checker ตัวไหน หาเคสที่รู้อยู่แล้วว่าต้องแดง แล้วดูว่ามันแดงจริงไหม ถ้าเคสที่ควรพังยังเขียว แปลว่าสิ่งที่เรากำลังอ่านไม่ใช่ผลทดสอบ แต่เป็นภาพลวง

orchestrator ไม่ใช่คนที่ห้ามแตะทุกอย่าง

กติกา "หัวห้ามทำ grunt work" มีมุมกลับที่ต้องระวัง ระหว่างสังเคราะห์รายงาน หัวเจอช่องว่าง 3 จุดที่รายงานตอบไม่ตรงกัน ทางเลือกคือส่งงานรอบใหม่ให้มือ (รออีกรอบ จ่ายอีกรอบ) หรือ grep เช็คเอง 30 วินาที เราเลือกอย่างหลัง และมันคือการตัดสินใจที่ถูกที่สุดของวัน งานของหัวคือรู้ว่าอะไรควรส่งต่อ และอะไรถูกกว่าถ้าทำเองครึ่งนาที เส้นแบ่งไม่ใช่ "ห้ามแตะ" แต่คือ "อย่าเอาเวลาคิดไปแลกกับงานที่มือทำได้"

กับดักที่เราโดนจับได้สองครั้งในวันเดียว

เรื่องสุดท้ายไม่ใช่เรื่องเทคนิค แต่เป็นพฤติกรรมของ orchestrator เอง พอมีช่องทาง "ส่งต่อ" อยู่ในมือ อะไรๆ ก็ดูควรส่งต่อไปหมด วันนั้นเราโดนจับได้สองครั้ง ครั้งแรกคือ bug ที่แก้เองได้ในสองบรรทัด แต่เรา route ไปเข้าคิวให้คนอื่นทำ ครั้งที่สองคือตั้งเกณฑ์ขึ้นมาเองว่า "ต้องมีตัวอย่างจริง 2-3 งานก่อนถึงจะเขียนบทความนี้ได้" ทั้งที่หลักฐานจาก session เดียวก็พอแล้ว เกณฑ์ที่ตั้งเองกลายเป็นข้ออ้างให้ไม่ต้องลงมือ โดยแต่งตัวมาเป็นความรอบคอบ ถ้ากำลังจะตั้ง orchestrator ของตัวเอง เผื่อใจไว้ว่ากับดักนี้มากับแพ็คเกจด้วย

agent เงียบ ไม่ได้แปลว่าตาย

เกร็ดเล็กแต่ประหยัดเงินจริง: agent ที่รับงานอ่าน repo เงียบไปนานจนใจอยากสั่ง kill แล้วเริ่มใหม่ สัญชาตญาณบอกว่าค้าง แต่ความจริงคืองานมันลึก พอสะกิดถามความคืบหน้าแทนที่จะฆ่าทิ้ง ปรากฏว่างานเดินอยู่และผลที่กลับมาลึกกว่าที่หัวจะทำเองได้ ฆ่า agent ที่กำลังทำงาน = จ่ายเงินซ้ำเพื่อได้ของช้าลง

ช่วงที่ 5เอาไปใช้กับงานของคุณ

เริ่มยังไงดี

1. สร้าง agent สามตัวแรก ไฟล์ละไม่กี่บรรทัดใน .claude/agents/ ตัวคิดลึก ตัวทำงานเร็ว ตัวค้นหา จับคู่โมเดลตามตาราง ช่วงที่ 2
2. เขียนกติกาให้หัว อย่างน้อยข้อเดียว: เจองานค้นหา/งานกลไก ให้แตกงาน ห้ามทำเอง
3. ส่งงานแรกเป็นงานอ่านอย่างเดียว งานประเมิน งานสำรวจ งาน audit พังแล้วเสียหายเป็นศูนย์ เหมาะเป็นสนามซ้อมที่สุด
4. บังคับ smoke test กับของจริงเสมอ รายงานจากการอ่านอย่างเดียวยังไม่ใช่คำตอบ และอย่าเชื่อ test เขียวจนกว่าจะเห็นมันแดงเป็น
5. จดว่าหัวแอบทำงานเองเมื่อไหร่ สัปดาห์แรกจะเจอว่าหัวเผลอทำ grunt work เองบ่อยกว่าที่คิด จดไว้แล้วปรับกติกา

ตอนไหนไม่ต้องใช้

งานเล็ก งานไฟล์เดียว งานที่รู้คำตอบอยู่แล้วครึ่งหนึ่ง เปิดโมเดลกลางตัวเดียวทำตรงๆ ถูกกว่าและเร็วกว่า orchestration มีต้นทุนคงที่ของมันเอง (แผน การส่งงาน การรอผล) จะคุ้มก็ต่อเมื่องานใหญ่พอที่การแบ่งชั้นจะได้กำไรกลับมา เหมือนที่ pong คำเดียวราคา 26,800 tokens สอนไว้

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