Dictionary · Agent · 119 / 321

Agent orchestration

การจัดคิวและลำดับให้ agent หลายตัวทำงานร่วมกันจนจบงานชิ้นเดียว ว่าใครทำก่อน ใครรอใคร ส่งงานต่อกันอย่างไร และใครชี้ขาดเมื่อผลไม่ตรงกัน

Agent orchestration คือการวางลำดับและกติกาให้ agent หลายตัวทำงานร่วมกันจนจบงานชิ้นเดียว โจทย์ของมันคือคำถามชุดเดียวกับที่หัวหน้าทีมต้องตอบทุกวัน ใครลงมือก่อน ใครต้องรอผลของใคร ส่งของกันด้วยอะไร และถ้าผลที่ได้ขัดกันเองใครเป็นคนชี้ขาด เอกสารของ Semantic Kernel ซึ่งเป็น framework ฝั่ง Microsoft เรียกวิธีประสานงานเหล่านี้ว่า orchestration pattern และอธิบายว่าเป็นแนวทางที่ไม่ผูกกับเทคโนโลยีตัวใดตัวหนึ่ง ใช้ประสาน agent หลายตัวให้มุ่งไปที่เป้าหมายเดียวกัน หน้าเดียวกันนี้ขึ้นกล่องเตือนไว้ด้วยว่าฟีเจอร์ agent orchestration ใน Agent Framework ของ Semantic Kernel ยังอยู่ในขั้น experimental กำลังพัฒนาอยู่ และอาจเปลี่ยนไปมากก่อนจะขยับขึ้นเป็นรุ่น preview หรือ release candidate ข้อควรระวังคือหน้านี้ปรับปรุงล่าสุดกลางปี 2025 และหลังจากนั้น Microsoft ประกาศว่า Microsoft Agent Framework คือรุ่นต่อจาก Semantic Kernel และ AutoGen โดยตรง ซึ่งเป็นคนละตัวกับที่กล่องเตือนนี้พูดถึง

ตารางบนหน้า agent orchestration ของ Semantic Kernel แจกแจงรูปแบบที่ SDK รองรับไว้ห้ารูปแบบ Concurrent คือกระจายโจทย์เดียวกันไปให้ agent ทุกตัวแล้วเก็บผลของแต่ละตัวแยกกัน เหมาะกับการวิเคราะห์คู่ขนานหรือการรวมความเห็นหลายทาง Sequential คือส่งผลของตัวหนึ่งเป็นวัตถุดิบให้ตัวถัดไปตามลำดับที่กำหนดไว้ล่วงหน้า Handoff คือโยนสิทธิ์ควบคุมข้ามตัวตามบริบทหรือกติกา โดยเอกสารยกกรณีใช้งานเป็นงานที่เส้นทางไม่ตายตัว การ escalate การหาทางสำรอง และการส่งต่อให้ผู้เชี่ยวชาญ Group Chat คือให้ทุกตัวคุยกันในวงเดียวโดยมี group manager คุมวง และ Magentic เป็นแบบคล้าย group chat ที่ได้แรงบันดาลใจจากงาน MagenticOne ฝั่ง CrewAI ตอนนี้ใช้ได้สองแบบคือ sequential กับ hierarchical โดยเอกสารระบุว่า Process ถูกทำเป็น enum จึงจำกัดค่าไว้เฉพาะแบบที่นิยามไว้เท่านั้น การเปิดโหมด hierarchical นั้นเอกสารกำหนดว่าต้องตั้ง manager language model (manager_llm) หรือ manager agent ที่เขียนเองไว้ใน crew ก่อน โดย manager ตัวนี้จะกระจายงานให้สมาชิกตามความถนัด แล้วตรวจและรับรองว่างานเสร็จจริง ส่วนเอกสาร multi-agent ของ langchain ยกรูปแบบหลักไว้ห้าแบบเช่นกัน ได้แก่ Subagents, Handoffs, Skills, Router และ Custom workflow โดยระบุไว้ด้วยว่าผสมข้ามรูปแบบกันได้ แบบ Subagents ให้ agent หลักเรียก subagent เหมือนเรียก tool และการตัดสินใจว่าจะเรียกตัวไหนเมื่อไหร่วิ่งผ่านตัวหลักตัวเดียว ส่วน Router ใช้ขั้นตอนจัดประเภทคำถามก่อน แล้วส่งต่อไปยัง agent เฉพาะทางหนึ่งตัวหรือมากกว่านั้น จากนั้นสังเคราะห์ผลกลับมาเป็นคำตอบเดียว อีกเส้นแบ่งที่ควรรู้มาจากคู่มือ Agents SDK ของ OpenAI ซึ่งแยกการ orchestrate เป็นสองแนวทางหลัก แนวทางหนึ่งคือปล่อยให้ LLM วางแผนและตัดสินใจเองว่าจะเดินขั้นไหนต่อ อีกแนวทางคือเขียนโค้ดกำหนดเส้นทางการทำงานของ agent เอง โดยหน้านั้นระบุว่าสองแนวทางนี้ผสมกันได้ และแต่ละแบบมีข้อแลกเปลี่ยนของตัวเอง เช่น ถึงการ orchestrate ด้วย LLM จะทรงพลัง แต่การ orchestrate ด้วยโค้ดทำให้งานแน่นอนและคาดเดาได้มากกว่า ทั้งในแง่ความเร็ว ต้นทุน และ performance เทคนิคฝั่งโค้ดที่หน้าเดียวกันยกตัวอย่างไว้ เช่น การใช้ structured output ให้ได้ข้อมูลรูปแบบชัดเจนไว้ตรวจก่อนตัดสินใจขั้นต่อไป การต่อ agent เป็นทอดโดยแปลงผลของตัวก่อนเป็นข้อมูลเข้าของตัวถัดไป และการให้ agent ที่ลงมือทำกับ agent ที่ทำหน้าที่ประเมินสลับกันทำงานเป็นรอบ

คนทำงานมักเจอคำนี้ตอนทีม IT เสนอให้เลิกใช้ agent ตัวเดียวรับทุกเรื่อง แล้วแตกเป็นหลายตัวที่ถนัดคนละอย่าง ก่อนอนุมัติมีสามเรื่องที่ควรถามกลับ เรื่องแรกคือจำเป็นจริงหรือเปล่า เพราะเอกสารของ LangChain เองเขียนกำกับไว้ว่างานที่ซับซ้อนไม่ได้ต้องใช้วิธีนี้ทุกงาน agent ตัวเดียวที่มี tool และ prompt ที่เหมาะสม ซึ่งบางครั้งปรับเปลี่ยนตามสถานการณ์ได้ ก็มักให้ผลใกล้เคียงกัน เรื่องที่สองคือพอมีหลายตัวส่งงานกันเป็นทอด เวลาผลออกมาผิดจะไล่ยากขึ้นว่าพลาดที่ขั้นไหน observability และ failure-attribution จึงควรวางตั้งแต่วันแรก ไม่ใช่ค่อยมาหาทีหลังตอนลูกค้าโวย เรื่องที่สามคือของแบบนี้ทับซ้อนกับ workflow-automation ที่หลายองค์กรมีอยู่แล้ว ต่างกันที่ใครเป็นคนเลือกเส้นทาง และอย่าลืมดูข้อจำกัดตามเครื่องมือที่เลือก เช่น หน้า orchestration ของ Semantic Kernel ระบุว่าความสามารถนี้ยังไม่มีใน Java SDK ส่วนการต่อ agent เข้ากับไฟล์ ฐานข้อมูล หรือแอปที่องค์กรใช้จริง เป็นคนละชั้นกัน มีมาตรฐานอย่าง mcp รับหน้าที่นั้นไป

ตัวอย่างจากบทสนทนาจริง

ผู้จัดการฝ่ายบริการลูกค้า: ทีมเสนอว่าจะทำ agent orchestration ให้ระบบตอบลูกค้า ฟังแล้วเหมือนของเดิมที่มี bot ตัวเดียวก็ตอบได้นะคะ แล้วถ้าสองตัวให้คำตอบไม่ตรงกันจะเชื่อใคร

หัวหน้าทีมพัฒนา: ของเดิมคือตัวเดียวรับทุกเรื่องครับ แบบใหม่แตกเป็นตัวที่ถนัดคนละเรื่อง แล้วเราต้องเลือกด้วยว่าจะจัดคิวแบบไหน งานที่ต้องเรียงขั้นก็ให้ส่งต่อกันเป็นทอด งานที่อยากได้หลายมุมพร้อมกันก็ยิงพร้อมกันแล้วค่อยรวมผล ส่วนคำถามว่าใครชี้ขาด เครื่องมือหลายเจ้าให้ตั้งตัวคุมไว้หนึ่งตัว อย่าง CrewAI ถ้าจะใช้โหมด hierarchical เอกสารบังคับว่าต้องระบุ manager ก่อน แล้ว manager ตัวนั้นเป็นคนกระจายงานและตรวจงานให้

ผู้จัดการฝ่ายบริการลูกค้า: งั้นขอให้ทำสรุปด้วยว่าคำตอบแต่ละครั้งผ่านตัวไหนมาบ้าง เวลาลูกค้าร้องเรียนจะได้ชี้ได้ว่าพลาดตรงขั้นไหน

ระวังสับสนกับ

  • handoff : handoff คือจังหวะเดียวที่โยนสิทธิ์ควบคุมจาก agent ตัวหนึ่งไปยังอีกตัว ซึ่งเอกสารของ Semantic Kernel นับเป็นหนึ่งใน orchestration pattern ส่วน agent orchestration คือภาพรวมของทั้งเส้นทาง มี handoff เป็นข้อต่อหนึ่งในนั้น
  • agent-swarm : คำว่า swarm มักใช้กับภาพฝูงที่สมาชิกส่งงานกันเองแบบไม่มีตัวคุมกลาง ส่วน agent orchestration เป็นคำกลางกว่านั้น ครอบทั้งแบบที่ตั้งตัวคุมไว้อย่าง manager ของ CrewAI และแบบที่โยนสิทธิ์ควบคุมข้ามตัวกันเองตามบริบทอย่าง handoff ของ Semantic Kernel
  • a2a-protocol : A2A เป็นมาตรฐานสำหรับให้ agent ต่างระบบต่างเจ้าคุยกันรู้เรื่อง เป็นคนละคำถามกับ agent orchestration ที่ตอบว่าใครทำอะไรลำดับไหน ซึ่งต้องตอบให้ได้ไม่ว่าเบื้องหลังจะคุยกันด้วยมาตรฐานใด

ดูคำนี้ใน Knowledge Atlas →

■ ไม่อยากพลาดของใหม่

อ่านจบแล้วอยากตามเรื่อง AI แบบนี้ต่อทุกวัน เรามีสรุปข่าวภาษาไทยส่งทาง LINE ทุกเช้า กดเพิ่มเพื่อนไว้ได้เลย ไม่มีค่าใช้จ่าย

เพิ่มเพื่อนใน LINE →
QR เพิ่มเพื่อน LINE ของ TRAINIAC AIคอมพิวเตอร์สแกนด้วยมือถือได้เลย

Agent modeAgent swarm