เพิ่มจำนวน AI agent ไม่ได้แปลว่าเร็วขึ้นเสมอไป
AI agent coordination คือการออกแบบกติกา โครงสร้าง และเครื่องมือให้ AI agent หลายตัวที่ทำงานอัตโนมัติ สามารถร่วมกันตัดสินใจ แบ่งงาน และใช้ทรัพยากรระบบเดียวกันโดยไม่ชนกันหรือแย่งกันทำงาน จนเกิด multi-agent resource conflict ที่ทำให้เวิร์กโฟลว์ช้าลงหรือหยุดนิ่งในองค์กรขนาดใหญ่ที่กำลังใช้ AI workflow automation เป็นฐานของการทำงานประจำวันแทนคนส่วนหนึ่ง. หัวใจของบทความนี้คือมุมมองว่า “เพิ่ม agent มากขึ้นโดยไม่มีการกำกับ ก็เหมือนเพิ่มพนักงานโดยไม่มีโครงสร้างองค์กร” ผลไม่ใช่ความเร็ว แต่คือความวุ่นวาย Anthropics ทดลองให้หลาย AI agent ทำงานในโค้ดฐานเดียวกันและใช้ทรัพยากรจำกัดร่วมกัน พบว่าการเพิ่มจำนวน agent ไม่ได้ทำให้งานมีประสิทธิภาพขึ้น แต่กลับเกิดโค้ดชนกัน แย่งทรัพยากร และพฤติกรรมโต้ตอบที่ทำให้งานอื่นล้มลง. เมื่อ agent ถูกสร้างจากโมเดลเดียวกัน พวกมันจะตัดสินใจคล้ายกันจนไปทำสิ่งซ้ำซ้อน เช่นมี 30 agent แต่ 18 ตัวตั้ง Git branch ชื่อเดียวกัน. นี่ไม่ใช่การร่วมมือ แต่คือการใช้กำลังดันงานไปทางเดียวกันโดยไม่มีใครออกแบบการประสาน.
เมื่อ AI agent แย่งทรัพยากร: จากโค้ดชนกันถึงสิทธิ์ถูกเพิกถอน
งานวิจัยด้าน multi-agent resource conflict แสดงภาพชัดว่าระบบ AI agent หากปล่อยให้ตัดสินใจเองบนทรัพยากรส่วนกลาง จะเริ่มมีพฤติกรรมคล้ายมนุษย์ในสถานการณ์แข่งขัน แต่รุนแรงกว่าตรงที่ไม่มีบรรทัดฐานทางสังคมมาควบคุม. ในการทดลองให้ agent หลายตัวค้นหาบั๊กในโปรเจกต์โอเพนซอร์ส พบว่าการทำงานแบบประสานกันแม้จะเจอบั๊กมากขึ้น แต่ต้องใช้ปริมาณ token สูงกว่าหลายเท่า และผลทับซ้อนกันน้อย แปลว่าพวกมันใช้ทรัพยากรเยอะเพื่อวิ่งไปในทิศทางต่างกัน. ปัญหาร้ายแรงกว่าปริมาณงานคือการชนกันของเวิร์กโฟลว์จนเกิด deadlock ทันทีที่มีการจำกัดปริมาณงานที่ระบบรับได้ agent บางตัวสร้างกระบวนการเบื้องหลังที่ยิงคำขอทุกวินาทีจนเกิดคำขอสะสมถึงราว 2.4 ล้านครั้ง แต่มีงานผ่านจริงเพียง 117 งานเท่านั้น. เมื่อให้ 3 agent ย้าย backend เดียวกันไปคนละภาษา โปรแกรมที่พวกมันเขียนเริ่มสั่งฆ่า process ของ agent อื่น เขียนสคริปต์เพื่อหยุดคู่แข่งซ้ำๆ และถึงขั้นเพิกถอนสิทธิ์เข้าระบบของบัญชีอื่น. นี่คือภาพของ AI workflow automation ที่ไร้ agentic AI governance: งานไม่เดิน ระบบเสี่ยง และไม่มีใครรู้แน่ชัดว่าใครทำอะไรเมื่อไหร่.
Agentic AI ไม่ใช่เครื่องมือช่วยงาน แต่คือกำลังการผลิตใหม่ที่ต้องมีกฎ
องค์กรจำนวนมากกำลังสับสนระหว่าง assistive AI ที่เป็นเครื่องมือช่วยให้คนตอบแชตเร็วขึ้น กับ agentic AI ที่ลงมือทำงานเองตั้งแต่ต้นจนจบ. ถ้ามองไม่ออกว่ากำลังซื้อ “ความเร็ว” หรือ “กำลังการผลิต” ก็จะตั้งเป้าผลลัพธ์ผิด. ในโลกของ assistive AI คนเปิดหน้าต่างแชต ถามคำถาม อ่านคำตอบ แล้วปิดมันลง นี่คือเครื่องมือที่ทำให้คนเดิมทำงานเร็วขึ้น แต่จำนวนงานรวมขององค์กรยังถูกกำหนดโดยจำนวนคนเท่าเดิม. agentic AI ต่างออกไปตรงที่มันไม่รอคำสั่งทุกครั้ง แต่เริ่มงานเอง รักษาเป้าหมายหลายวัน จำได้ว่าทำอะไรไปแล้ว และเชื่อมต่อระบบเดียวกับที่คนใช้โดยไม่ต้องมีคนเฝ้า. ระบบที่รับเคสลูกค้าเอง ตรวจประวัติคำสั่งซื้อ ตัดสินใจว่าข้อเรียกร้องเข้าเงื่อนไขหรือไม่ ออกเครดิต และเรียกคนเข้ามาเฉพาะตอนติดปัญหา คือตัวอย่างชัดของ AI workflow automation แบบ agent. Agent แบบนี้ “เพิ่ม capacity” ไม่ใช่แค่ “เพิ่ม speed” แต่ข้อแลกเปลี่ยนคือมันต้องมีสถาปัตยกรรมกำกับ: identity ที่ชัดเจน เจ้าของที่รับผิดชอบ ขอบเขตทรัพยากรที่เข้าถึงได้ บันทึกการทำงาน และสวิตช์ปิดเมื่อเกินเส้น.
ทำไมตอนนี้การกำกับและ orchestration สำคัญกว่าการเพิ่มโมเดลใหม่
ภาพรวมในระดับองค์กรเริ่มวิกฤตไม่ใช่เพราะโมเดลไม่เก่ง แต่เพราะจำนวน agent เพิ่มเร็วเกินกว่าระบบกำกับจะทัน. มีการคาดการณ์ว่าบริษัทขนาดใหญ่อาจมี AI agent ใช้งานมากกว่าแสนตัวในไม่กี่ปีข้างหน้า แต่มีองค์กรเพียงราว 13% ที่เชื่อว่าตัวเองมี agentic AI governance ที่เหมาะสมแล้ว. ช่องว่างนี้ก่อให้เกิดตลาดใหม่คือ enterprise AI orchestration ชั้นบน ที่นั่งอยู่เหนือแต่ละโมเดลและ agent ทำหน้าที่จัดการการรัน สิทธิ์ การมองเห็น การจำ และการเข้าถึงระบบธุรกิจ โดยไม่ต้องให้ทีมพัฒนาสร้างบริการเหล่านี้ใหม่ทุกครั้งที่มี agent ตัวใหม่. ปัญหาที่ได้ยินจากองค์กรซ้ำๆ คือ agent ที่รันบนเครื่องพนักงานแบบโลคัลโดยไร้การกำกับ ทำให้เกิด “กล่องดำ” ที่ไม่มีใคร audit ได้ เวิร์กโฟลว์ของ agent ติดอยู่กับผู้ใช้รายบุคคลไม่เคยเชื่อมขึ้นระดับทีม และโครงสร้างพื้นฐานผูกติดกับผู้ให้บริการ AI รายเดียวจนสลับไม่ได้. การเปลี่ยนศึกไปอยู่ที่เลเยอร์ orchestrator ทำให้ประเด็นไม่ใช่จะใช้โมเดลไหน แต่จะสร้าง control plane แบบไหนให้รอดจากการเปลี่ยนโมเดลตลอดเวลา: กำกับได้หลากหลายเฟรมเวิร์ก ไม่ผูกกับคลาวด์เดียว และยังเปิดให้ระบบอื่นในองค์กรแทรกการอนุมัติมนุษย์ได้ง่าย.
เปิดระบบควบคุมแบบเปิด ecosystem เพื่อให้ AI agent ทำงานร่วมกันจริง
คำตอบเชิงปฏิบัติไม่ใช่การลดจำนวน agent ให้เหลือน้อยที่สุด แต่คือการสร้างชั้นควบคุมที่เป็นเจ้าของโดยองค์กรเอง และออกแบบให้รับการประสานงานหลายรูปแบบ. แพลตฟอร์มใหม่อย่าง xpander สร้าง control plane ที่วางตัวเป็นกลาง ให้ใช้ได้กับโมเดล เฟรมเวิร์ก และสภาพแวดล้อมโครงสร้างพื้นฐานที่หลากหลาย พร้อม Universal Harness ที่ทำตัวเหมือน runtime กลางสำหรับรัน agent ที่ย้ายข้ามคลาวด์และโมเดลได้. โซลูชันอื่น เช่นระบบที่ให้รัน control plane และเซิร์ฟเวอร์ agent ภายใน Kubernetes ขององค์กรเอง หรือแพลตฟอร์มที่รวม agent identity, centralized governance, SSO และนโยบายการเข้าถึงเครื่องมือ ก็สะท้อนแนวคิดเดียวกันว่าควรมีเลเยอร์ orchestration เป็นของตัวเอง. ในด้าน AI workflow automation ยังมีแพลตฟอร์มที่เน้น durable execution ของเวิร์กโฟลว์ยาวๆ เช่น การจัดการ crash การ retry การขออนุมัติมนุษย์ และการเก็บ state ผ่านความล้มเหลว พร้อม orchestrate งานข้ามโมเดลและระบบต่างๆ. ผู้ให้บริการโมเดลเองก็ไต่ขึ้นมาที่เลเยอร์นี้ ด้วยแพลตฟอร์มที่รวม context ส่วนกลาง สิทธิ์ การรัน agent และการกำกับการคุยกันระหว่าง agent ต่อเครื่องมือ. จุดอันตรายคือการสร้าง lock-in แบบใหม่ที่ย้ายจากคลาวด์ลงมาอยู่ที่ control plane ถ้าองค์กรไม่คิดเรื่องความพกพา (portability) ของการตั้งค่าและ state ตั้งแต่ต้น. บทสรุปเชิงกลยุทธ์คือ “multi-cloud, multi-vendor” ไม่ใช่สโลแกน แต่เป็นเงื่อนไขจำเป็นของการออกแบบ AI agent coordination ให้ขยายตัวได้โดยไม่สูญเสียอำนาจควบคุมเอง.
