Agent ตัวเดียวที่เคยตอบได้ครบ พอโจทย์ซับซ้อนขึ้นกลับเริ่มพลาดบ่อยขึ้นเรื่อย ๆ

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

ปฏิกิริยาแรกของทีมคือลองเปลี่ยนไปใช้โมเดลที่แรงขึ้น ซึ่งช่วยได้บ้างแต่ไม่ได้แก้ปัญหาที่ต้นตอ เพราะ Agent ตัวเดียวยังต้องแบกภาระตรวจสอบสามมิติที่ใช้ความเชี่ยวชาญต่างกันไว้ในหัวเดียวพร้อมกัน ต่อให้โมเดลฉลาดขึ้นแค่ไหน การพยายามโฟกัสหลายเรื่องพร้อมกันในการตัดสินใจครั้งเดียวก็ยังมีโอกาสพลาดสูงกว่าการแยกให้แต่ละส่วนโฟกัสเรื่องเดียวอยู่ดี

บทความนี้จะอธิบาย Multi Agent System คืออะไร ต่างจาก Custom Agent หรือ Subagent ที่เคยพูดถึงไปแล้วอย่างไร และเมื่อไรที่การมีหลาย Agent ทำงานร่วมกันจริง ๆ ให้ผลดีกว่าการพึ่งพา Agent ตัวเดียว

Multi Agent System คืออะไร ในภาพที่กว้างกว่า Subagent เดี่ยว ๆ

Multi Agent System คือสถาปัตยกรรมที่ประกอบด้วย Agent หลายตัวซึ่งแต่ละตัวมีบทบาท ความเชี่ยวชาญ หรือมุมมองต่างกัน ทำงานร่วมกันเพื่อบรรลุเป้าหมายเดียวกัน ไม่ได้จำกัดแค่รูปแบบใดรูปแบบหนึ่ง อาจเป็น Agent หลักที่เรียก Subagent ชั่วคราว อาจเป็น Custom Agent หลายตัวที่แต่ละตัวมีอยู่ต่อเนื่อง หรืออาจเป็น Agent หลายตัวที่สื่อสารกันเองแบบไม่มีลำดับชั้นตายตัวก็ได้

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

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

ข้อสังเกตที่ขัดสามัญสำนึก งานยิ่งซับซ้อน Agent เดี่ยวยิ่งพลาดเยอะขึ้นแบบไม่เป็นเส้นตรง

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

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

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

เมื่อไรที่หลาย Agent ให้ผลดีกว่า Agent ตัวเดียวจริง ๆ

• งานมีหลายมิติที่ต้องตรวจสอบพร้อมกัน และแต่ละมิติใช้เกณฑ์หรือความเชี่ยวชาญที่ต่างกันชัดเจน เช่น ด้านกฎหมาย ด้านการเงิน ด้านนโยบายภายใน
• ต้องการการตรวจสอบไขว้กัน (cross-check) เพื่อลดความเสี่ยงที่มุมมองเดียวจะมองข้ามบางอย่างไป เช่น ให้ Agent หนึ่งเสนอคำตอบ อีก Agent ตรวจทานความถูกต้องแยกกัน
• งานมีปริมาณมากพอที่การทำขนานหลาย Agent ประหยัดเวลารวมได้จริง ไม่ใช่แค่งานเดี่ยวชิ้นเล็กที่ Agent ตัวเดียวทำเสร็จเร็วอยู่แล้ว
• ทีมมีความสามารถดูแลระบบที่ซับซ้อนขึ้น ทั้งการดีบัก การตรวจสอบต้นทุน และการออกแบบกลไกรวมผลลัพธ์ระหว่าง Agent

เมื่อไรที่ Agent ตัวเดียวยังเป็นตัวเลือกที่ดีกว่า แม้งานจะดูใหญ่

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

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

ตารางเปรียบเทียบ Agent ตัวเดียว, Subagent และ Multi Agent System เต็มรูปแบบ

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

กลไกประสานงานระหว่าง Agent ในระบบ ออกแบบอย่างไรไม่ให้ชนกันเอง

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

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

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

ต้นทุนและการสังเกตระบบที่เพิ่มขึ้นเมื่อมีหลาย Agent ทำงานพร้อมกัน

ต้นทุนที่มองเห็นชัดที่สุดของ Multi Agent System คือค่าใช้จ่ายด้าน token หรือ compute ที่เพิ่มขึ้นตามจำนวน Agent ที่ทำงานพร้อมกัน เพราะแต่ละตัวมี context และการประมวลผลของตัวเอง ไม่ได้ใช้ทรัพยากรร่วมกันเหมือน Agent ตัวเดียวที่ทำทุกอย่างในรอบเดียว ทีมต้องชั่งน้ำหนักว่าความแม่นยำที่เพิ่มขึ้นคุ้มกับต้นทุนที่เพิ่มขึ้นหรือไม่ในแต่ละกรณีการใช้งาน

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

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่เจอบ่อยตอนออกแบบ Multi Agent System

• แยก Agent ตามความรู้สึกว่าซับซ้อนแล้วดูดี โดยไม่มีมิติงานที่ต่างกันจริงรองรับ — ทำแบบนี้แล้วพัง เพราะเพิ่มต้นทุนและความซับซ้อนโดยไม่ได้ความแม่นยำที่ดีขึ้นคุ้มค่า
• ไม่มีกฎจัดการเมื่อ Agent สองตัวให้ผลขัดแย้งกัน — ทำแบบนี้แล้วพัง เพราะระบบอาจติดค้างหรือเลือกคำตอบแบบสุ่มโดยไม่มีเหตุผลรองรับที่อธิบายได้
• ไม่ลงทุนกับระบบ log และ observability ตั้งแต่แรก — ทำแบบนี้แล้วพัง เพราะเมื่อผลลัพธ์ผิดพลาด จะไม่มีทางไล่ตรวจได้ว่า Agent ตัวไหนในระบบเป็นต้นเหตุ
• ให้ทุก Agent เห็น context และสิทธิ์เท่ากันหมดเพื่อความสะดวก — ทำแบบนี้แล้วพัง เพราะเพิ่มความเสี่ยงข้อมูลรั่วและทำให้แยกความรับผิดชอบของแต่ละ Agent ไม่ชัดเจน
• ใช้ Multi Agent System กับงานที่ปริมาณมากแต่ไม่ซับซ้อนหลายมิติ — ทำแบบนี้แล้วพัง เพราะปัญหาจริงคือปริมาณงาน ไม่ใช่ความซับซ้อนของการตัดสินใจ ควรแก้ด้วยการรัน Agent เดียวหลาย instance แทน

สรุป

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

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

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

คำถามที่พบบ่อย