เมื่อ AI หลายตัวรับงานเดียวกันโดยไม่แบ่งบทบาท งานไม่ได้เร็วขึ้น ปัญหาจะไปอยู่ที่การส่งต่องาน ไม่มีคนรับผิดชอบโจทย์ ไม่มีคนตัดสินใจเมื่อคำตอบขัดกัน และไม่มีจุดตรวจที่ชัดก่อนส่งงานออกไป
โปรเจกต์ Fable Advisor เป็นตัวอย่างหนึ่งของการแก้ปัญหานี้ ผู้พัฒนาวาง Fable ไว้ในบทบาทสถาปนิก รับโจทย์มาแยกเป็นงานย่อย เขียนสเปก แล้วส่งให้โมเดลอื่นลงมือทำ จากนั้นจึงเรียก Fable เข้ามาตรวจงานอีกครั้ง บทความนี้สรุปกลไกดังกล่าว และชวนมองว่าหลักการนี้นำไปใช้กับงาน ERP, AI และการพัฒนาซอฟต์แวร์ในองค์กรได้ตรงไหน
แบ่งบทบาทก่อนแบ่งงาน
Fable Advisor จึงเริ่มจากการกำหนดว่าแต่ละตัวมีหน้าที่อะไร ก่อนเลือกว่าจะใช้โมเดลใด
- Architect รับผิดชอบทำความเข้าใจความต้องการ แยกงาน เขียนสเปก และตรวจหลักฐานก่อนสรุปว่างานเสร็จ
- Producer รับผิดชอบลงมือทำตามสเปก โดยเลือก lane ให้เหมาะกับความซับซ้อนของงาน
- Reviewer อ่านงานในบริบทใหม่ ตรวจเทียบกับโจทย์ และชี้ว่าควรส่งต่อ แก้ก่อน หรือกลับไปทบทวนแนวทาง
การแยกหน้าที่นี้ช่วยลดปัญหาที่คนเดียวเป็นทั้งผู้ตั้งโจทย์ ผู้เขียนโค้ด และผู้ตัดสินผลงานของตัวเอง เพราะแต่ละบทบาทมีคำถามคนละแบบ คนวางระบบถามว่า “เรากำลังแก้ปัญหาถูกเรื่องหรือไม่” คนลงมือถามว่า “จะทำตามข้อกำหนดนี้อย่างไร” ส่วนคนตรวจถามว่า “มีหลักฐานพอหรือยังว่างานตรงตามที่ตกลงกัน”
เลือกคนทำงานตามความยาก ไม่ใช่ตามความเคยชิน
Fable Advisor แบ่งงานเป็นสอง lane หลัก งานที่ข้อกำหนดชัดและทำซ้ำเป็นประจำจะส่งให้ Codex implementer ที่ใช้ GPT-5.6 Luna ส่วนงานที่ต้องใช้ดุลยพินิจ เช่น concurrency, debugging ที่ซับซ้อน, security หรือ refactor กว้าง จะส่งให้ Sol implementer ที่ใช้ GPT-5.6 Sol
จุดสำคัญคือ lane ไม่ได้ถูกเลือกเพราะโมเดลใด “เก่งที่สุด” ในทุกเรื่อง แต่เลือกตามลักษณะของงาน งานที่มีขั้นตอนแน่นควรใช้ lane ที่ทำงานเร็วและทำซ้ำได้ งานที่มีความเสี่ยงหรือมีทางเลือกทางสถาปัตยกรรมควรใช้ผู้ลงมือที่มีเวลาคิดมากขึ้น การกำหนด reasoning effort ต่อโจทย์จึงมีความหมายกว่าการตั้งค่าระดับสูงสุดให้ทุกงาน
ในทีมธุรกิจ หลักการเดียวกันใช้ได้กับการกระจายงานระหว่างคนและ AI เช่น งานแปลงข้อมูลตามกติกาอาจทำเป็นขั้นตอนอัตโนมัติ งานออกแบบข้อมูลลูกค้าหรือสิทธิ์การเข้าถึงควรมีคนตัดสินใจ และงานที่กระทบการเงินหรือข้อมูลส่วนบุคคลควรมีผู้ตรวจที่ระบุชื่อได้
บริหารงบ Token ตามความเสี่ยงของงาน
เวลาพูดถึงงบ Token อย่าดูเฉพาะคำตอบของ agent ตัวสุดท้าย ต้นทุนยังมาจากข้อมูลที่ส่งเข้าไป การส่งบริบทซ้ำระหว่าง handoff จำนวนรอบที่เรียกเครื่องมือ และงานตรวจที่เกิดขึ้นท้ายกระบวนการด้วย งานวิจัยด้าน budget-aware multi-agent systems อย่าง BAMAS จึงตั้งงบไว้ก่อน แล้วเลือกทั้งชุดโมเดลและรูปแบบการทำงานให้ไม่เกินข้อจำกัด งานทดลองของผู้วิจัยรายงานว่าลดต้นทุนได้สูงสุด 86% เมื่อเทียบกับวิธีที่นำมาเปรียบเทียบ แต่ตัวเลขนี้เป็นผลการทดลอง ไม่ใช่คำรับรองสำหรับทุกระบบ
แนวทางที่ใช้ได้กับงานจริงคือประเมินงบทั้งงาน แบ่งส่วนสำหรับการวางแผน การลงมือทำ และการตรวจ แล้วบันทึก Token ที่ใช้จริงแยกตาม task และ handoff ไม่จำเป็นต้องแบ่งให้ทุก agent เท่ากัน
- งานที่ข้อกำหนดชัด ใช้ lane ที่เร็วและงบพอทำงานให้จบในรอบเดียว
- งานที่ยังมีความไม่แน่นอน กันงบไว้สำหรับการวางแผนและการตรวจมากขึ้น
- ถ้าต้องลองซ้ำหลายรอบ ให้หยุดดูสาเหตุก่อนเพิ่ม Token เพราะปัญหาอาจอยู่ที่โจทย์หรือข้อมูลที่ส่งต่อ
- เมื่อข้อมูลเริ่มยาวขึ้น ให้ตัดบริบทที่ไม่เกี่ยวข้องหรือส่งเฉพาะผลลัพธ์ที่จำเป็นต่อขั้นตอนถัดไป แทนการส่งประวัติทั้งหมดให้ทุก agent
สเปกที่ส่งต่อได้ต้องตอบคำถามให้ครบ
เมื่อผู้วางระบบไม่ได้ลงมือทำเอง สเปกต้องละเอียดพอให้คนอีก lane เริ่มงานได้โดยไม่ต้องเดาบริบทใหม่ทุกครั้ง Fable Advisor ใช้กรอบสเปกที่ระบุโจทย์ ขอบเขต ข้อจำกัด เกณฑ์เสร็จ เงื่อนไขที่ต้องส่งต่อให้คนตัดสินใจ และระดับ reasoning ที่เหมาะกับงาน
สำหรับงาน ERP หรือ AI สเปกที่ดีควรระบุอย่างน้อยว่า
- ธุรกิจต้องการเปลี่ยนแปลงขั้นตอนไหน และอะไรอยู่นอกขอบเขต
- ข้อมูลต้นทางคือระบบใด ใครเป็นผู้ดูแล และสิทธิ์ใดที่ต้องรักษาไว้
- ผลลัพธ์ที่ตรวจได้ต้องมีหน้าตาอย่างไร ไม่ใช่เพียง “ทำให้ดีขึ้น”
- กรณีใดให้หยุดถามคน และกรณีใดให้ส่งต่อผู้เชี่ยวชาญ
- จะทดสอบอย่างไร และต้องมีหลักฐานอะไรจึงเรียกว่างานเสร็จ
คำถามเหล่านี้ทำให้การส่งต่องานไม่ใช่การโยน prompt ยาว ๆ ให้ AI ตัวถัดไป แต่เป็นการส่งความรับผิดชอบพร้อมเงื่อนไขตรวจรับ
จุดตรวจต้องอยู่ก่อนการตัดสินใจ ไม่ใช่หลังเกิดปัญหา
Fable Advisor เรียก advisor เข้ามาตรวจเมื่อถึง commitment boundary และตรวจอีกครั้งเมื่อจบงาน ผู้ตรวจอ่าน diff และหลักฐานจากบริบทใหม่ ไม่ได้อาศัยความมั่นใจของคนที่ทำงานมาแล้ว
เมื่อนำแนวคิดนี้มาใช้กับ Odoo หรือระบบธุรกิจ จุดตรวจอาจอยู่ก่อน merge โค้ด ก่อนเปลี่ยนกติกาการคำนวณ ก่อนเปิดสิทธิ์ข้อมูลให้ AI หรือก่อนส่งผลลัพธ์ไปให้ลูกค้า ผู้ตรวจไม่จำเป็นต้องแก้ทุกอย่างเอง แต่ต้องตอบให้ได้ว่าหลักฐานเพียงพอหรือควรหยุดตรงไหน
การตรวจที่ดีจึงไม่ใช่การเพิ่มขั้นตอนเพื่อความปลอดภัยแบบเหมารวม แต่เป็นการวางจุดตัดสินใจในตำแหน่งที่ความผิดพลาดยังแก้ได้ง่ายและต้นทุนยังไม่สูง
หลาย agent ไม่ได้ชนะทุกงาน
งานวิจัย Mixture-of-Agents เสนอการวาง agent เป็นชั้น ๆ โดยให้ชั้นถัดไปใช้คำตอบจากชั้นก่อนหน้า ส่วน งานศึกษาที่ควบคุมงบ reasoning tokens เท่ากัน พบว่า single-agent ทำได้เท่ากันหรือดีกว่า multi-agent ในงาน multi-hop reasoning หลายชุดทดสอบ
ผลสองด้านนี้ไม่ได้ขัดกัน งานที่ต้องการมุมมองหลายแบบหรือแยกเป็นงานย่อยชัดอาจได้ประโยชน์จากหลาย agent แต่งานที่บริบทต่อเนื่องและมีงบจำกัดอาจเหมาะกับ agent เดียวที่ให้เวลาคิดมากขึ้น การเลือกสถาปัตยกรรมจึงควรดูผลทดสอบ ต้นทุน และเวลาตอบ ไม่ควรเพิ่มจำนวน agent ตามกระแส
สิ่งที่ควรระวังเมื่อเอาโมเดลหลายตัวมาทำงานร่วมกัน
หลายโมเดลไม่ได้ทำให้คำตอบถูกขึ้นโดยอัตโนมัติ หาก Architect แบ่งงานผิด Producer ก็จะทำงานได้ดีบนโจทย์ที่ผิด หาก Reviewer เห็นเพียงผลลัพธ์แต่ไม่เห็นเกณฑ์ตรวจ ก็อาจอนุมัติงานที่ดูเรียบร้อยแต่ไม่ตอบความต้องการจริง
อีกเรื่องคือสิทธิ์และข้อมูลที่ส่งต่อกัน ทุก lane ควรรู้ว่ากำลังอ่านข้อมูลชุดใดและข้อมูลใดไม่ควรถูกส่งเข้าโมเดล การใช้ AI กับข้อมูล Odoo จึงต้องเริ่มจากการกำหนดสิทธิ์ แหล่งอ้างอิง และผู้อนุมัติ ไม่ควรเปิดข้อมูลทั้งหมดแล้วค่อยแก้ทีหลัง
แปลงแนวคิดเป็น workflow ของทีม
ก่อนทำระบบหลาย agent ลองหยิบงานหนึ่งประเภทที่ทีมทำซ้ำบ่อย เช่น ตรวจความพร้อมก่อนวาง ERP หรือเตรียมร่างบทความจากข้อมูลผลิตภัณฑ์ แล้วกำหนดเส้นทางให้ชัด
- คนรับโจทย์สรุปผลลัพธ์และขอบเขต
- Architect แยกงานและกำหนดเกณฑ์รับงาน
- Producer ลงมือทำตาม lane ที่เหมาะกับความเสี่ยง
- Reviewer ตรวจผลลัพธ์กับโจทย์และหลักฐาน
- คนรับผิดชอบตัดสินใจว่าจะส่งต่อ แก้ไข หรือหยุด
วิธีนี้ทำให้ AI อยู่ในกระบวนการทำงาน ไม่ใช่กล่องสนทนาที่ใครก็สั่งและทุกคนต้องเชื่อ คำตอบสุดท้ายยังมีเจ้าของ มีเงื่อนไข และมีประวัติให้ย้อนตรวจได้
Fable Advisor เป็นโปรเจกต์โอเพนซอร์สของผู้พัฒนา ไม่ใช่ผลิตภัณฑ์ของ Enersys และบทความนี้ไม่ได้หมายความว่า Enersys ใช้ระบบดังกล่าวในโครงการลูกค้า เรานำแนวคิดเรื่องการแบ่งบทบาท การเลือก lane และการตรวจข้ามบริบทมาเป็นบทเรียนสำหรับการออกแบบงาน ERP และ AI ที่ตรวจสอบได้
อ่าน repository และรายละเอียดการติดตั้ง Fable Advisor
คุยกับทีม Enersys เรื่องการออกแบบ workflow สำหรับ ERP และ AI
