Anthropic เปิดตัวฟีเจอร์ Multi-agent Orchestration ใน Managed Agents API (สถานะ Beta) ช่วยให้นักพัฒนาสามารถตั้งค่า Coordinator Agent เพื่อคอยมอบหมายงาน (Delegate) ให้กับ Sub-agent หลายตัวทำงานร่วมกันภายใน Session เดียว โดยรองรับ Sub-agent ใน Roster ได้สูงสุด 20 ตัว และรัน Concurrent Thread พร้อมกันได้สูงสุด 25 Thread ต่อหนึ่ง Session

สำหรับการเปิดใช้งานช่วง Beta จะต้องส่ง Header managed-agents-2026-04-01 แนบไปกับทุก Request หรือใช้งานผ่าน Official SDK ที่ตั้งค่า Header นี้ให้อัตโนมัติ

Anthropic ระบุว่า สถาปัตยกรรมแบบ Multi-agent เหมาะสำหรับงานที่มีความซับซ้อนสูง ต้องทำงานข้ามหลายระบบ หรือมี Sub-task ย่อยที่แบ่งขอบเขตหน้าที่ได้อย่างชัดเจน เพราะการใช้ Agent เพียงตัวเดียวที่ต้องแบกรับ Tools และ Prompt ทุกอย่างไว้ด้วยกัน มักจะเจอปัญหา Context แน่นเกินไปจนทำให้คุณภาพของ Output ลดลง

สถาปัตยกรรม: Container ร่วมกัน แต่แยก Context ชัดเจน

ในหนึ่ง Session นั้น ทุก Agent จะแชร์ Container และ Filesystem เดียวกัน แต่จะแยก Context ของใครของมันอย่างสิ้นเชิง (Context Isolation) โดยแต่ละ Agent จะทำงานอยู่บน Session Thread ของตัวเองที่มี Conversation History แยกเป็นเอกสิทธิ์

Agent แต่ละตัวสามารถตั้งค่าเฉพาะเจาะจงได้ตั้งแต่ตอนสร้าง ไม่ว่าจะเป็น Model, System Prompt, Tools, MCP Servers ไปจนถึง Skills โดยที่ Tools และ Context จะไม่มีการแชร์ข้าม Agent กันเด็ดขาด

สำหรับ Thread จะมีคุณสมบัติแบบ Persistent ทำให้ Coordinator สามารถส่ง Follow-up กลับไปหา Sub-agent ตัวเดิมที่เคยเรียกใช้ได้เสมอ โดย Sub-agent ตัวนั้นจะยังคงจดจำประวัติจากรอบก่อนหน้าได้ครบถ้วน ในขณะที่ Coordinator จะรายงานความคืบหน้าทั้งหมดผ่าน Primary Thread ซึ่งทำหน้าที่เป็น Event Stream หลักระดับ Session และจะ Spawn Thread ย่อยเพิ่มขึ้นมาก็ต่อเมื่อ Coordinator ตัดสินใจกระจายงาน

3 รูปแบบ Multi-agent Pattern ที่ Anthropic แนะนำ

Anthropic ได้สรุปแนวทางการออกแบบสถาปัตยกรรม Multi-agent ไว้ 3 Pattern หลัก:

• Parallelization (การทำงานคู่ขนาน): กระจาย Sub-task ที่เป็นอิสระต่อกันให้หลาย Agent ทำงานไปพร้อมกัน เช่น ให้ Sub-agent หลายตัวช่วยกันค้นหาข้อมูลจากหลายแหล่ง หรือวิเคราะห์ไฟล์คนละส่วนพร้อมกัน จากนั้น Coordinator จะนำผลลัพธ์ทั้งหมดมาประมวลผลรวมกัน ซึ่งช่วยลดเวลาการทำงานได้อย่างมาก
• Specialization (การแบ่งหน้าที่เฉพาะทาง): ส่งต่องานไปยัง Agent ที่มี System Prompt และ Tools เฉพาะทาง เช่น แบ่งงานให้ Security Agent หรือ Documentation Agent แทนการยัดทุกอย่างไว้ใน Agent ตัวเดียวจน Context ล้น
• Escalation (การยกระดับความสามารถ): Coordinator สามารถเลือกส่งงานย่อยที่ต้องการการคิดวิเคราะห์ขั้นสูงไปให้ Agent หรือ Model ที่มีความสามารถสูงกว่าจัดการ เช่น Coordinator อาจใช้โมเดลรุ่นมาตรฐาน แต่เรียก Sub-agent ที่ใช้โมเดลตัวท็อปเข้ามาช่วยเฉพาะโจทย์ที่ซับซ้อนเป็นพิเศษ

ตัวอย่างการตั้งค่า Config Schema

เราสามารถกำหนดค่า Coordinator ผ่านฟิลด์ multiagent ในตอนสร้าง Agent ตัวใหม่ ตัวอย่างไฟล์ YAML จากเอกสารทางการของ Anthropic:

name: Engineering Lead
model: claude-opus-4-7
system: You coordinate engineering work. Delegate code review to the reviewer agent and test writing to the test agent.
tools:
  - type: agent_toolset_20260401
multiagent:
  type: coordinator
  agents:
    - type: agent
      id: $REVIEWER_AGENT_ID
    - type: agent
      id: $TEST_WRITER_AGENT_ID

เครื่องมือ agent_toolset_20260401 คือชุดคำสั่งที่ Anthropic เตรียมไว้ให้ Coordinator ใช้สั่งการ Sub-agent ใน Roster ส่วนคนที่ใช้งานผ่าน CLI สามารถรันคำสั่ง ant beta:agents create แล้วส่ง YAML config ผ่าน stdin ได้ทันที

ฟิลด์ multiagent.agents รองรับการกำหนดค่า 3 รูปแบบ:

• {type: agent, id}: อ้างอิง Agent ที่มีอยู่แล้ว (ค่าเริ่มต้นจะใช้เวอร์ชันล่าสุด)
• {type: agent, id, version}: ล็อกเวอร์ชันของ Agent ตัวนั้นอย่างเจาะจง
• {type: self}: อนุญาตให้ Coordinator แตกตัว (Spawn) ก๊อบปี้ตัวเองขึ้นมาช่วยทำงานได้

หลังจากสร้าง Coordinator เรียบร้อยแล้ว ขั้นตอนถัดไปคือการสร้าง Session ที่ผูกกับ Coordinator นั้น โดยตัว Coordinator จะตัดสินใจเลือก Delegate งานไปยัง Agent ใน Roster ตามความเหมาะสมในตอนรันไทม์

ข้อจำกัดสำคัญที่ควรรู้ก่อนเริ่มใช้งาน

• ลำดับชั้น (Depth): Coordinator สามารถมอบหมายงานได้ลึกเพียง 1 ระดับเท่านั้น หากระบบพบ Depth มากกว่า 1 ระบบจะไม่ประมวลผล หมายความว่า Sub-agent ที่ได้รับมอบหมายงานไปแล้ว จะไม่สามารถส่งงานต่อให้ Sub-agent ย่อยลงไปอีกชั้นได้
• ขนาด Roster: กำหนดได้สูงสุด 20 Unique Agents ใน multiagent.agents แต่ Coordinator สามารถเรียกก๊อบปี้ของ Agent ตัวเดียวกันขึ้นมาช่วยทำงานหลายตัวพร้อมกันได้ ทำให้มีหลาย Thread ผูกกับ Agent ประเภทเดียวกันได้
• Concurrent Thread: รองรับพร้อมกันสูงสุด 25 Thread ต่อหนึ่ง Session หากต้องการเปิด Thread ใหม่หลังจากแตะขีดจำกัดแล้ว จะต้องทำการ Archive Thread ที่ไม่ได้ใช้งานออกไปก่อน

การบริหารจัดการ Thread: List, Interrupt และ Archive

เราสามารถจัดการ Thread ใน Session ผ่าน REST API Endpoint ได้อย่างยืดหยุ่น:

• List Threads: เรียกดูรายการ Thread ทั้งหมดผ่าน GET /v1/sessions/:id/threads โดย Thread ที่มีค่า parent_thread_id เป็น null คือ Primary Thread ทั้งนี้ สถานะของ Session จะนับเป็นภาพรวม หากมี Thread ใดกำลังทำงานอยู่ Session จะถือว่าอยู่ในสถานะ Running
• Interrupt Thread: สามารถสั่งหยุดการทำงานได้ด้วย Event user.interrupt พร้อมระบุ session_thread_id ที่ต้องการ (หากไม่ระบุ ระบบจะส่งคำสั่งไปที่ Primary Thread เป็นค่าเริ่มต้น) หากสั่งหยุด Child Thread ที่ติดสถานะ requires_action ระบบจะปฏิเสธ (Deny) Pending Tool Calls ทั้งหมด และส่งสถานะ session.thread_status_idle พร้อม stop_reason: end_turn ให้ทันทีโดยไม่ต้องประมวลผลโมเดลซ้ำ แต่หากสั่งหยุด Thread ที่ว่าง (Idle) อยู่แล้ว คำสั่งจะไม่มีผลใดๆ (No-op)
• Archive Thread: ทำได้เฉพาะช่วงที่ Thread อยู่ในสถานะ Idle เท่านั้น หาก Thread กำลังทำงานหรือติด requires_action จะต้องสั่ง Interrupt ก่อนจึงจะ Archive ได้ ซึ่งการ Archive จะช่วยคืนโควตา Thread ให้กลับมาใช้งานต่อได้จากขีดจำกัด 25 Thread

6 Event สำคัญบน Primary Thread

Primary Thread จะส่ง Event หลัก 6 รูปแบบเพื่อให้นักพัฒนาติดตามสถานะของ Multi-agent ได้อย่างละเอียด:

• session.thread_created: แจ้งเมื่อมี Thread ใหม่ถูกสร้างขึ้น พร้อมระบุ session_thread_id และ agent_name
• session.thread_status_running: Thread เริ่มทำงาน
• session.thread_status_idle: Agent ใน Thread นั้นกำลังรอรับ Input พร้อมระบุ stop_reason ที่บอกสาเหตุการหยุด
• session.thread_status_terminated: Thread ถูก Archive หรือเกิดข้อผิดพลาดร้ายแรง (Terminal error)
• agent.thread_message_received: Sub-agent ส่งผลลัพธ์กลับมายัง Coordinator พร้อมระบุ from_session_thread_id, from_agent_name และ content
• agent.thread_message_sent: Coordinator ส่งข้อความ Follow-up ไปยัง Sub-agent พร้อมระบุ to_session_thread_id, to_agent_name และ content

หากต้องการดู Event ในระดับเจาะลึกของ Agent แต่ละตัวโดยเฉพาะ สามารถใช้การสตรีมผ่าน GET /v1/sessions/:id/threads/:thread_id/stream หรือดึงข้อมูลจาก Endpoint /events ของ Thread นั้นได้โดยตรง

การส่งต่อ Tool Permission กลับมาที่ Primary Thread

ในกรณีที่ Sub-agent ต้องการขอสิทธิ์รันเครื่องมือที่เป็นประเภท always_ask หรือต้องการส่งผลลัพธ์ของ Custom Tool ตัว Event เหล่านี้จะถูก Cross-post กลับมาที่ Primary Thread โดยอัตโนมัติ พร้อมแนบ session_thread_id ของ Thread ต้นทาง ทำให้ฝั่งไคลเอนต์ที่ดักฟังเฉพาะ Primary Thread สามารถเห็นคำขออนุมัติการใช้งานเครื่องมือได้ทันที

จากนั้น ผู้ใช้สามารถส่งคำตอบยืนยันกลับไปด้วย user.tool_confirmation (ระบุ tool_use_id) หรือ user.custom_tool_result (ระบุ custom_tool_use_id) ที่ระดับ Session ได้เลย ทางเซิร์ฟเวอร์จะจัดการ Route ข้อมูลกลับไปยัง Thread ต้นทางให้เองโดยที่ฝั่งนักพัฒนาไม่ต้องเขียนโค้ดจัดการ Routing เพิ่มเติม

รองรับทั้ง CLI และ SDK ครบ 9 ภาษา

Anthropic ได้เตรียมตัวอย่างโค้ดไว้รองรับถึง 9 รูปแบบ ได้แก่ cURL (Bash), ant CLI, Python, TypeScript, C#, Go, Java, PHP และ Ruby โดยทุก SDK จะจัดการแนบ Beta Header managed-agents-2026-04-01 ให้อัตโนมัติ ยกเว้นการเรียกผ่าน cURL หรือยิง Raw HTTP ที่ต้องระบุ Header เอง

บทสรุปและทิศทางต่อไป

ฟีเจอร์ Multi-agent ใน Managed Agents API ช่วยให้นักพัฒนาสร้างสถาปัตยกรรมแบบ Coordinator และ Specialized Agent บนโครงสร้างพื้นฐานของ Anthropic ได้โดยตรง ไม่ต้องเสียเวลาจัดการระบบแยก Context หรือคอยดูเรื่อง Thread Routing เองให้ยุ่งยาก

แหล่งข้อมูลอ้างอิง: Anthropic platform docs: Managed Agents Multi-agent