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

ช่วงนี้ผมเห็นคลิป demo เยอะมากที่เอา AI agent หลายตัวมาวางคุยกันเป็นวง แล้วบอกว่า "นี่คืออนาคต ยิ่งเยอะยิ่งฉลาด" มันดูตื่นเต้นดี เหมือนได้ทีมงานมาทั้งทีมในจอเดียว แต่จากการที่ผมรันระบบ agent จริงทุกวัน 24/7 มาหลายเดือน — มีตัวคุมงาน มีตัวลงมือ ส่งงานต่อกันเป็นทอด ๆ — ผมจะบอกตรง ๆ ว่าสิ่งที่เจอบ่อยกว่าคือตรงกันข้าม การสุม agent หลายตัวแล้วปล่อยให้มันคุยกันเอง มักจะเละมากกว่าฉลาด และปัญหาไม่ได้อยู่ที่ "agent โง่" แต่อยู่ที่ "ไม่มีโครงสร้างประสานงาน" ต่างหาก บทความนี้คือสิ่งที่ผมเรียนรู้จากของจริง — ทำไมมันพัง และเทคนิคที่ทำให้มันใช้งานได้

ความเข้าใจผิด: "ยิ่งหลาย agent ยิ่งฉลาด"

ความเชื่อนี้น่าหลงเชื่อเพราะ demo มันดูดี เราเห็น agent หลายตัวโต้กันไปมาแล้วรู้สึกว่า "นี่มันคิดเป็นทีมเลยนะ" แต่พอดูตัวเลขจากคนที่วัดจริง ภาพมันต่างออกไป

Anthropic เจ้าของ Claude เองรายงานว่า ระบบ multi-agent ใช้ token ประมาณ 15 เท่าของการแชตปกติ และที่สำคัญกว่านั้นคือเขาพบว่า "token usage by itself explains 80% of the variance" — แปลว่าผลงานที่ดีขึ้นส่วนใหญ่อธิบายได้ด้วย "จ่าย token มากขึ้น" ไม่ใช่เวทมนตร์จากการที่ agent คุยกัน พูดง่าย ๆ คือถ้าคุณยอมจ่ายแพงขึ้น 15 เท่า คุณก็ควรได้อะไรกลับมาบ้างอยู่แล้ว คำถามคือมันคุ้มกับความเสี่ยงที่เพิ่มขึ้นไหม

และนี่คือประโยคที่ผมว่าคนทำ multi-agent ควรแปะไว้หน้าจอ — Anthropic เขียนเองว่า งานบางประเภท "that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today" และเสริมว่า "LLM agents are not yet great at coordinating and delegating to other agents in real time" นี่คือคนสร้างโมเดลพูดเองว่า การให้ agent ประสานงานกันเองแบบเรียลไทม์ยัง "ไม่เก่ง"

ฝั่งงานวิจัยก็ตรงกัน มีการวิเคราะห์ failure ของระบบ multi-agent จากเทรซจริงกว่า 1,600 รายการบนเฟรมเวิร์กยอดนิยม (AutoGen, CrewAI, LangGraph) แล้วจัดเป็น 14 รูปแบบความล้มเหลว พบว่า กลุ่ม coordination failures — สื่อสารพลาด, state ไม่ตรงกัน, เป้าหมายขัดกัน — กินสัดส่วนถึง 36.94% ของความล้มเหลวทั้งหมด นั่นคือ "การคุยกัน" นั่นแหละที่เป็นสาเหตุพังอันดับต้น ๆ ไม่ใช่ความสามารถของตัวโมเดล

ทำไมมันสำคัญกับเรา: ในมุมคนทำงานจริง การเปิด multi-agent คือการจ่าย token แพงขึ้น ~15 เท่า เพื่อแลกกับความเสี่ยงพังที่สูงขึ้น ถ้าจะทำ ต้องมีเหตุผลที่ดีกว่า "เห็นคนอื่นทำแล้วมันดูเท่"

หลักฐานจากระบบที่ผมรันเอง: ความเลอะที่มองไม่เห็น

ผมไม่ได้พูดลอย ๆ ระบบ runner ที่ผมรันเอง 24/7 คือห้องทดลองของผม และนี่คือเศษซากที่ผมเก็บกวาดมากับมือ เมื่อปล่อยให้งานวิ่งขนานกันโดยไม่มีกลไกคุมที่รัดกุมพอ (ผมเล่าแบบไม่ลงรายละเอียดภายใน แต่ตัวเลขเป็นของจริงจากระบบผม)

• Process ค้างสะสม — ตามดีไซน์ควรมี process ทำงานอยู่ตัวเดียว แต่มีช่วงที่พีคค้างถึง 7–10 ตัวพร้อมกัน นั่งกินทรัพยากรเงียบ ๆ อยู่ 1–3 วันโดยไม่มีใครรู้ สาเหตุคือตอน crash หรือ restart ตัวเก่าไม่ได้ถูกเก็บให้เรียบร้อย มันเลยค้างทับกันไปเรื่อย ๆ
• งานหลุดจากพ่อแม่ (orphan) — แค่ผมเขียนสคริปต์ไล่สแกนรอบแรก ก็เจอ daemon ที่หลุดจาก session เก่าค้างอยู่ 4 ตัวทันที พวกมันคือลูกที่พ่อแม่ตายไปแล้วแต่ตัวเองยังวิ่งอยู่ — มองไม่เห็นจนกว่าจะตั้งใจไปหา
• สัญญาณบอกจบงานรั่ว — มีเคสที่ agent ทำงานเสร็จจริง แต่ดันเขียน "สัญญาณบอกจบ" ผิดชื่อ ตัวคุมงานเลยนั่งรอสัญญาณที่ไม่มีวันมา สรุปคือ งานเสร็จแล้วแต่ระบบเข้าใจว่าพัง สั่งทำซ้ำ แถมทิ้งไฟล์ขยะค้างไว้เกือบ 500 ไฟล์
• ต้นทุนหลอน — มีอยู่ช่วงที่ log จากสองแหล่งปนกัน บวกกับการนับซ้ำของ record เดิม ทำให้ตัวเลขต้นทุนเป่งเป็น 7.7 เท่าของจริง รายงานบอกว่าแพงมหาศาล ทั้งที่ความจริงไม่ได้ขนาดนั้น — ถ้าผมเชื่อเลขนี้แล้วตัดสินใจ ก็พลาดทันที

จุดร่วมของทุกเคสคือ ไม่มีใครสั่งให้ระบบเลอะ มันเลอะ เอง จาก concurrency ที่ไม่มีคนคุม ขยะพวกนี้ไม่ระเบิดวันแรก แต่มันค่อย ๆ ทบไปเงียบ ๆ จนวันหนึ่งคุณเปิดมาเจอกองใหญ่

มุมคนทำ model validation: ในงานความเสี่ยงเราเรียกสิ่งนี้ว่า silent failure — ระบบ "ดูเหมือนทำงาน" ทุกอย่างเขียวหมด แต่ข้างในสะสมความเพี้ยนไว้เรื่อย ๆ multi-agent ที่ปล่อยให้คุยกันเองคือโรงงานผลิต silent failure ชั้นดี เพราะไม่มีใครเป็นคนตรวจว่าผลลัพธ์ระหว่างทางมันยังตรงเป้าอยู่ไหม

ทำไม "ให้ agent คุยกันเอง" ถึงพังบ่อย

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

หนึ่ง — error มันทบต้น agent ตัวแรก hallucinate นิดเดียว ตัวถัดไปรับมาเป็น "ข้อเท็จจริง" แล้วต่อยอดความผิดนั้น พอส่งต่อกันหลายทอด ความผิดเล็ก ๆ ขยายเป็นเรื่องใหญ่ ตัวอย่างคลาสสิกคือ agent ตั้งราคากับ agent คุมสต็อกที่คุยกันเอง ตัวหนึ่งเข้าใจผิดว่าของจะขาด เลยขยับตัวเลข อีกตัวเห็นแล้วตอบสนอง วนกันไปจนสร้างปัญหาจริงจากปัญหาที่ไม่เคยมีอยู่ — และมันจบในไม่กี่วินาทีถ้าไม่มีเบรก

สอง — context ล้นแล้ว drift ยิ่งคุยยิ่งยาว บริบทของแต่ละตัวบวมขึ้นเรื่อย ๆ context window ควรถูกมองเป็นเหมือน cache ที่ต้องล้างเป็นระยะ ถ้าไม่ล้าง agent จะค่อย ๆ ลืมเป้าหมายเดิม แล้วเริ่มตอบเรื่อยเปื่อย นี่แหละที่ตรงกับตัวเลข 36.94% coordination failures ที่ว่า agent "หลุดเป้า" เพราะ output ของเครื่องมือท่วมหน้าจอจนมองไม่เห็นโจทย์เดิม

สาม — ไม่มีใครเป็นเจ้าของการตัดสินใจ พอทุกตัวเท่ากันหมด ไม่มีใครมีอำนาจฟันธง สิ่งที่ได้คือการเกี่ยงกัน รอกัน หรือเถียงวนไม่จบ ผมเองเคยตั้งให้ agent สองตัว "debate" กันก่อนตัดสินใจ แล้วเจอมันวนลูปไม่ยอมสรุป สุดท้ายต้องไปตัดวงจรด้วยมือ

สี่ — debate ไม่ได้ฟรี จากที่ผมลองมา แม้แต่การให้ agent ถกกันแบบที่ออกแบบมาอย่างดี ก็คุ้มเฉพาะกับ "การตัดสินใจสำคัญที่ย้อนกลับไม่ได้" เท่านั้น งานทั่ว ๆ ไปถ้าเอา debate ไปครอบ = เผาเวลากับเงินเปล่า ๆ กฎที่ผมใช้จริงในระบบคือ งานสำคัญ/แตะของที่ย้อนไม่ได้ค่อย debate ส่วนงานปกติ "ไม่ต้อง — เปลืองเวลา"

เส้นที่ห้ามข้าม: อย่าให้ agent คุยกันเพราะ "มันดูฉลาด" ให้คุยเฉพาะตอนที่ output ของแต่ละตัวมีคนรับไปตรวจและตัดสินจริง ๆ การสนทนาที่ไม่มีปลายทางที่ตัดสินได้ คือการเปิดประตูให้ error วิ่งวนทบต้น

เทคนิคที่ทำให้ multi-agent ใช้ได้จริง

หัวใจของเรื่องนี้สั้นมาก — ประสานงาน (coordinate) ไม่ใช่สุมหัว (chatter) เปลี่ยนจากภาพ "ทีมที่คุยกันเองในวง" เป็น "สายพานที่ออกแบบเส้นทางไว้ชัด" นี่คือสิ่งที่ผมใช้แล้วเวิร์กจริง

1. มีหัวเดียวคุมเกม ให้มี orchestrator หนึ่งตัวที่แตกงานลงไปหา specialist แล้วรวบผลกลับ ไม่ใช่ทุกตัวคุยกับทุกตัวแบบ peer-to-peer งานวิจัยชี้ตรงกันว่าการมีตัวประสานกลางช่วยกดการขยายของ error ลงได้มาก เทียบกับสถาปัตยกรรมแบบกระจายที่ทุกตัวเท่ากัน วิธีแตกงานที่ถูกต้องผมเขียนแยกไว้ใน Subagents: แตกงานใหญ่เป็นทีมที่ทำขนานกัน
2. บังคับให้มีตัวเดียวจริง ๆ ในจุดที่ต้องมีตัวเดียว ผมไม่ "หวัง" ว่ามันจะไม่ชนกัน ผมบังคับเป็นสองชั้น — ชั้นแรกตั้งค่าให้รันได้แค่หนึ่ง instance ชั้นสองมี lock ที่ปฏิเสธตัวที่สองทันทีถ้ามีใครพยายามเปิดซ้ำ (และข้อควรรู้: การล็อกไฟล์แบบ flock ข้าม container/network mount ไม่ได้ ต้องใช้ lock จริงที่ใช้ร่วมกันได้)
3. ส่งงานกันด้วย "ซองสรุป" ไม่ใช่บทสนทนายาว แต่ละทอดส่งต่อแค่สิ่งที่จำเป็น — ตั้งใจจะทำอะไร, สรุปสิ่งที่เจอ, ผลลัพธ์, เป้าหมายถัดไป ไม่ใช่ลากประวัติการคุยทั้งหมดไปด้วย วิธีนี้รอดจากการ compaction และไม่พา context ขยะข้ามทอด
4. ทำเป็น pipeline ที่ลำดับชัด มี gate ตรวจ และมีเพดานจำนวนรอบ จัดเป็น DAG ที่รู้ว่าใครก่อนใครหลัง มีจุดตรวจ (critic gate) คอยกรองก่อนไปต่อ และมีเพดานนับรอบกัน loop วิ่งจนเงินหมด ไม่ใช่ลูปเปิดที่ปล่อยให้วิ่งฟรี
5. บังคับ output เป็นโครงสร้างที่ตรวจได้ ให้ agent ตอบกลับเป็น schema ที่กำหนด ไม่ใช่ free text ที่ตัวถัดไปต้องเดาความหมายเอง ลดการสื่อสารพลาดได้เยอะ
6. เช็กว่ามันยังมีชีวิตจริง + จำกัด retry + มีเบรก อย่าเช็กแค่ว่า "process ยังอยู่ไหม" แต่ต้องเช็กว่ามัน "ขยับทำงานจริงไหม" ถ้าค้างให้รีสตาร์ทแบบมีเพดานครั้ง และถ้าเจอลูปผิดปกติให้ตัดทิ้ง (circuit breaker) ก่อนมันลาม
7. เปิด multi-agent เมื่อคุ้มเท่านั้น ในเมื่อมันแพงกว่า ~15 เท่า งานที่ทำคนเดียวจบได้ก็อย่าไปสุม เก็บพลังนี้ไว้กับงานที่กว้างจริง แตกขนานได้จริง และมีมูลค่าพอจะคุ้มค่า token

จะเห็นว่าทุกเทคนิคมีแกนเดียวกัน — เพิ่มโครงสร้าง ลดอิสระในการคุยกันเอง ซึ่งตรงข้ามกับภาพ "ปล่อยให้ agent คุยกันแล้วมันจะฉลาดเอง" โดยสิ้นเชิง อีกเครื่องมือที่ผมชอบใช้แทนการให้ agent เถียงกันมั่ว ๆ คือให้มันโจมตีแผนของตัวเองก่อน commit ซึ่งได้ประโยชน์ของการ "ค้าน" โดยไม่ต้องเปิดวง debate ที่วนไม่จบ

ทำไมมันสำคัญ: สังเกตว่า pattern ที่ใช้ได้จริงทุกอันคือการ "ใส่กรอบ" ให้ agent ไม่ใช่ "ปลดล็อก" ให้มันอิสระ multi-agent ที่ดีหน้าตาเหมือนสายการผลิตที่ออกแบบมาดี ไม่ใช่ห้องประชุมที่ทุกคนพูดพร้อมกัน

ภาพรวม

ถ้าจะสรุปเป็นประโยคเดียว — การสุม agent ไม่ใช่คำตอบ การออกแบบการประสานงานต่างหากที่เป็นคำตอบ จำนวน agent ไม่ได้แปรผันตรงกับความฉลาด แต่แปรผันตรงกับต้นทุนและความเสี่ยงที่จะพังแน่ ๆ

ก่อนจะ "สุม agent" ครั้งหน้า ลองถามตัวเองห้าข้อนี้:

• งานนี้ใหญ่และ แตกเป็นชิ้นอิสระต่อกันได้จริง ไหม หรือมันต้องพึ่งผลของกันและกันเป็นลูกโซ่
• มี หัวเดียวที่รวบและตัดสิน ผลสุดท้ายไหม หรือปล่อยให้ทุกตัวเท่ากัน
• agent ส่งงานกันด้วย สรุปสั้น หรือลากบทสนทนายาวข้ามทอด
• มี gate ตรวจ + เพดานจำนวนรอบ กันลูปวิ่งฟรีไหม
• มันคุ้มกับต้นทุนที่แพงขึ้น ~15 เท่า ไหม

ถ้าตอบไม่ได้สักข้อ ทำคนเดียวหรือแตกแบบมีคนคุมจะปลอดภัยและถูกกว่าเสมอ ผมเก็บโครงสร้าง orchestrator, ซองสรุปสำหรับส่งงาน, และ pipeline ที่ใช้จริงในระบบ 24/7 ของผมไว้ในคอร์ส Claude Code — ก็อป workspace ผมไปปรับใช้กับงานของคุณได้เลย ไม่ต้องไปเจ็บตัวเก็บกวาดเศษซากเองเหมือนที่ผมเคยเจอ

ที่มา

• Anthropic — How we built our multi-agent research system: anthropic.com/engineering/multi-agent-research-system (token usage ~15× ของแชต, อธิบาย variance 80%, และข้อจำกัดของงานที่ agent ต้องพึ่งกันมาก)
• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? (MAST taxonomy, เทรซ 1,600+ รายการ, coordination failures 36.94%): arxiv.org/abs/2604.16339

เนื้อหานี้เพื่อการศึกษาด้านการออกแบบระบบ AI agent ไม่ใช่คำแนะนำการลงทุน ตัวอย่างเรื่องราคา/สต็อกเป็นเพียงภาพประกอบกลไก feedback loop เท่านั้น