เลิกส่งงานให้ agent อื่นคิด แล้วยื่น "ความสามารถ" ให้ agent เดิมแทน: Microsoft วัดจริงระหว่าง A2A กับ Skills บน MCP — เรียกโมเดลครึ่งเดียว เร็วขึ้น 2.4 เท่า แต่กินโทเคนเพิ่ม 22%

คำถามที่ทีมสร้างระบบ agent เจอซ้ำ ๆ ตั้งแต่ Agent Skills เริ่มแพร่หลายคือ: ถ้าจะให้ระบบทำงานเฉพาะทางได้ ควร ส่งงานต่อให้ agent อีกตัวที่มีลูปคิดของตัวเอง (แบบ A2A) หรือควร ยื่นคำสั่งและเครื่องมือให้ agent ตัวเดิมทำเอง (แบบ Skills)? ส่วนใหญ่คำตอบที่ได้ยินเป็นความเห็นเชิงสถาปัตยกรรม ไม่ค่อยมีใครวัด

วันที่ 16 กันยายน 2026 Tommaso Stocchi, Cloud Solution Architect ของ Microsoft เผยแพร่บทความ “From Specialist Agents to Distributed Skills over MCP” บน Microsoft Agent Framework Blog ที่ทำสิ่งที่หาได้ยาก — เขาย้ายเดโมมัลติเอเจนต์ตัวเดียวกัน (ระบบแนะนำรีสอร์ตสกี) จากสถาปัตยกรรม A2A ไปเป็น distributed skills บน MCP แล้ววัดผลด้วย execution trace จริงจากแอป Aspire ที่รันอยู่

ตัวเลขจาก trace จริง

เทียบพรอมต์เดียวกันสามคู่:

เมตริก	A2A Specialists	Distributed Skills
จำนวนการเรียกโมเดล	6, 6, 7	3, 3, 3
เวลาเฉลี่ย	15.480 วินาที	6.348 วินาที
โทเคนรวม (3 รัน)	11,134	13,533 (+~22%)

ทิศทางชัดเจนและอธิบายได้ด้วยกลไก: A2A สร้าง ลูปการให้เหตุผลซ้อนกัน — ตัว orchestrator ต้องคิดว่าจะส่งให้ใคร แล้ว specialist ก็ต้องคิดซ้ำอีกรอบด้วยโมเดลของตัวเอง ส่วน skills ยุบการให้เหตุผลไว้ที่ตัวแม่ตัวเดียว แล้วปล่อยให้บริการโดเมนยังกระจายอยู่ตามเดิม การเรียกโมเดลจึงหายไปครึ่งหนึ่ง เวลาหายไปมากกว่าครึ่ง

แต่ต้นทุนที่ย้ายที่คือโทเคน: เมื่อเอา SKILL.md และสคีมาของ MCP tool ทั้งชุดเข้ามาอยู่ใน context ของตัวแม่ ทุกเทิร์นต่อจากนั้นต้องแบกมันไว้ — จึงเป็น 13,533 โทเคน แทนที่จะเป็น 11,134

ผู้เขียนเตือนเรื่องความน่าเชื่อถือของตัวเลขเอง และนี่คือส่วนที่ทำให้บทความน่าเชื่อ: การวัดทำใน “reused-process, cache-affected runs” โดยฝั่ง native รายงาน cached token ไว้ 6,144 โทเคน ส่วนฝั่ง A2A รายงานแคชไม่ครบ ทำให้ เทียบต้นทุนจริงเป็นเงินไม่ได้ เพราะ input, cached input และ output คิดราคาคนละอัตรา — แปลว่า “+22% โทเคน” ไม่ได้แปลว่า “+22% ค่าใช้จ่าย” และอาจถูกลงด้วยซ้ำเมื่อสัดส่วนที่แคชได้สูง

ห้าขั้นตอนของการย้าย

บทความไม่ได้หยุดที่ตัวเลข แต่ให้ playbook พร้อมโค้ด C# และ Python:

1. แยก “ความสามารถ” ออกจาก “รันไทม์ของ agent” — ดึงลอจิกโดเมนและคำสั่งออกจาก specialist agent โดยให้บริการทางธุรกิจยังเป็นอิสระเหมือนเดิม
2. เปลี่ยน Agent Card ให้เป็น skill discovery — แทนที่การตั้งค่า endpoint ปลายทางด้วยสรุป skill ที่เสิร์ฟผ่าน skill://index.json ซึ่งอธิบายว่าควรใช้ความสามารถแต่ละตัวเมื่อไหร่
3. ย้าย system prompt ของ specialist ไปเป็น SKILL.md — เปลี่ยนจากพรอมต์ที่เขียนราวกับมีบทสนทนาของตัวเอง ให้กลายเป็น ขั้นตอนที่เรียกชื่อ MCP tool ตรง ๆ และอธิบายวิธีเลือก operation
4. เปิด operation เป็น MCP tool — ห่อฟังก์ชันโดเมนเดิมด้วยนิยาม MCP tool ที่มี type, parameter schema และ validation
5. แทนที่การลงทะเบียน A2A ด้วย skills และ tools — ใช้ SkillsProvider กับ MCPSkillsSource ของ Microsoft Agent Framework ทำ discovery โดยมี middleware เชื่อม skill ที่โหลดสำเร็จเข้ากับ tool catalog ของ provider

ข้อควรระวังที่ควรอ่านก่อนรีบย้าย

ส่วนที่ผมคิดว่ามีค่าที่สุดของบทความคือคำเตือน ไม่ใช่คำแนะนำ:

• ไม่ใช่ทุกส่วนที่ควรย้าย — research agent, workflow ที่รันยาว และงานที่ต้องให้เหตุผลเฉพาะทางจริง ๆ อาจยังควรเป็น agent อิสระที่มีลูปของตัวเอง การยุบทุกอย่างเข้ามาที่ตัวแม่จะทำให้ context บวมและตัวแม่ต้องแบกทุกเรื่อง
• Skills ไม่ได้แทนการกำหนดสิทธิ์หรือการจัดการวงจรชีวิต — กฎทางธุรกิจต้องอยู่ในโค้ด เพราะ คำอธิบาย skill เป็นคำสั่งเชิงแนะนำ ไม่ใช่กลไกบังคับใช้ ใครที่คิดจะเขียน “ห้ามทำ X” ไว้ใน SKILL.md แล้วถือว่าเป็นการควบคุม ควรอ่านบรรทัดนี้สองรอบ
• ผลถูกแคชบัง — ตามที่เล่าไปข้างบน
• มาตรฐาน MCP ยังขยับ — เดโมตรึงไว้ที่ร่างสเปกฉบับ 3 กันยายน 2026 และ protocol method skills/list กับ skills/get ยังอยู่ระหว่างการพิจารณาในตอนที่เขียน ซึ่งสอดคล้องกับสถานะของส่วนขยาย MCP Skills (SEP-2640) ที่เราเล่าไปเมื่อ 16 ก.ย. — สเปกเข้าสถานะ Final แล้ว แต่ SDK อ้างอิงยังตามไม่ครบ

มุมมอง AI Curator

ประโยคที่ควรจำจากบทความนี้คือการแยกแยะที่ผู้เขียนวางไว้เป็นแกน: ความต่างระหว่างสองสถาปัตยกรรมไม่ใช่เรื่องโปรโตคอล แต่คือ “delegating a task to another reasoner versus giving the current reasoner a competence and access to its operations” — ส่งงานให้ “ผู้คิด” อีกคน หรือ ยื่น “ความสามารถ” ให้ผู้คิดคนเดิม เมื่อมองแบบนี้ คำถาม “A2A หรือ MCP ดีกว่า” กลายเป็นคำถามผิด คำถามที่ถูกคือ “งานนี้ต้องการการตัดสินใจอิสระที่เราไม่อยากให้ตัวแม่เห็นรายละเอียด หรือแค่ต้องการวิธีทำที่ตัวแม่ยังไม่รู้”

และเมื่อกรอบคิดเป็นแบบนี้ กฎง่าย ๆ ที่ผมจะใช้กับทีมคือ: ถ้าคำตอบของ specialist เป็นสิ่งที่ตัวแม่ต้องเอาไปคิดต่ออยู่ดี การให้มันคิดแยกคือการจ่ายค่าเรียกโมเดลสองรอบเพื่อผลลัพธ์เดียว — ยุบเป็น skill ไปเลย แต่ถ้า specialist ต้องมีนโยบาย ข้อมูล หรือขอบเขตความปลอดภัยของตัวเองที่ตัวแม่ไม่ควรเห็น การแยกเป็น agent ยังคุ้ม เพราะสิ่งที่คุณซื้อคือ ขอบเขต (boundary) ไม่ใช่ความเร็ว

สำหรับบริบทไทยและอาเซียน ผมคิดว่าตัวเลข “+22% โทเคน แลกกับ -59% เวลา” สำคัญกว่าที่เห็น เพราะทีมในภูมิภาคนี้ส่วนใหญ่เจอข้อจำกัดคนละแบบกับทีมในสหรัฐฯ — งานที่เจอบ่อยคือ chatbot หน้าร้านหรือ internal tool ที่ ผู้ใช้รอไม่ได้เกิน 5-10 วินาที แต่ปริมาณ request ต่อวันไม่ได้มหาศาลจนค่าโทเคนเป็นตัวตัดสิน ในโปรไฟล์นั้นการแลกโทเคนเพิ่ม 22% เพื่อเวลาตอบจาก 15 วินาทีเหลือ 6 วินาที คือดีลที่ควรรับทันที กลับกัน ถ้าคุณรัน batch pipeline หลังบ้านที่ latency ไม่มีความหมาย สมการพลิกทันทีและ A2A อาจยังถูกกว่า — จงเลือกสถาปัตยกรรมจากรูปร่างของภาระงาน ไม่ใช่จากว่าปีนี้คำไหนกำลังฮิต

ข้อสุดท้ายที่อยากฝาก: บทความนี้เป็นตัวอย่างที่ดีของ “เอกสารสถาปัตยกรรมที่เชื่อถือได้” — มีตัวเลข มี trace มีเงื่อนไขการวัด และที่สำคัญคือ ยอมบอกว่าตัวเลขไหนใช้ไม่ได้ (ต้นทุนเป็นเงิน) แทนที่จะปัดตก ถ้าทีมคุณกำลังจะเขียน ADR เรื่องย้ายสถาปัตยกรรม agent ลองใช้โครงเดียวกันนี้ — รันของจริงสามคู่ แปะ trace แล้วบอกให้ชัดว่าอะไรยังพิสูจน์ไม่ได้

แหล่งข่าว

• From Specialist Agents to Distributed Skills over MCP — Microsoft Agent Framework Blog
• Microsoft Agent Framework Blog — หมวด Agent Skills
• โพสต์ของเราเรื่องส่วนขยาย MCP Skills (SEP-2640)