MCP (Model Context Protocol) และ A2A (Agent-to-Agent Protocol) คือข้อกำหนดการสื่อสารสำหรับให้ AI Agent ทำงานร่วมกับเครื่องมือและ Agent อื่นๆ

ในระบบ Multi-Agent นั้น Agent หลายตัวจะแบ่งบทบาทกันเพื่อจัดการงานที่ซับซ้อน ด้วยเหตุนี้ "ภาษากลาง" ระหว่าง Agent จึงเป็นสิ่งที่ขาดไม่ได้ อย่างไรก็ตาม แหล่งข้อมูลที่อธิบายกลไกเหล่านี้อย่างเป็นระบบยังมีอยู่น้อย ทำให้วิศวกรจำนวนมากยังคงลังเลในการตัดสินใจในขั้นตอนการออกแบบ

บทความนี้จะจัดระเบียบบทบาท สถาปัตยกรรม และเกณฑ์การเลือกใช้งานของทั้ง MCP และ A2A โดยมุ่งเป้าไปที่วิศวกรที่กำลังพิจารณาออกแบบระบบ Multi-Agent รวมถึงผู้ที่ต้องการทำความเข้าใจพื้นฐานของการเชื่อมต่อ AI Agent พร้อมอธิบายควบคู่กับโครงสร้างที่เป็นรูปธรรม

จากยุคที่ AI Agent ทำงานแบบอิสระเพียงลำพัง ได้เปลี่ยนผ่านสู่ยุคที่รองรับทั้งการเรียกใช้ tool และการมอบหมายงานให้แก่ agent อื่น ๆ "ข้อตกลงร่วม" ที่ทำให้การประสานงานอันซับซ้อนนี้เป็นไปได้ คือ AI Agent Protocol ซึ่งตัวอย่างที่เป็นตัวแทนได้แก่ MCP (Model Context Protocol) และ A2A (Agent-to-Agent Protocol)

ในอดีต กระแสหลักของการใช้งาน AI คือ "การถามตอบกับโมเดลเดียว" แต่เมื่องานมีความซับซ้อนมากขึ้น จึงเกิดความต้องการกระบวนการที่ผสมผสานการอ่านไฟล์ การเรียก external API และการค้นหาข้อมูลอ้างอิงเข้าด้วยกัน

การที่แต่ละเครื่องมือมี interface เป็นของตัวเอง ทำให้เกิดความท้าทายดังต่อไปนี้

• ทุกครั้งที่เชื่อม AI กับระบบภายนอก จำเป็นต้องพัฒนา adapter แยกต่างหาก
• connector ของทีมหนึ่งไม่สามารถนำไปใช้ซ้ำในอีกทีมหนึ่งได้
• การ implement ในลักษณะเดียวกันเกิดการซ้ำซ้อนและแพร่กระจายภายในองค์กร

ยิ่งไปกว่านั้น เมื่อ multi-agent system ที่ AI agent เรียกใช้เครื่องมือหลายอย่างอย่างอิสระ หรือมอบหมาย task ให้ agent อื่น กลายเป็นตัวเลือกที่เป็นจริงได้ในทางปฏิบัติ มิติของปัญหาก็เปลี่ยนไป ไม่ใช่แค่ "ความแตกต่างในวิธีเรียก API" อีกต่อไป แต่กลายเป็นความจำเป็นที่ต้องมีข้อตกลงในระดับที่ลึกกว่านั้น นั่นคือวิธีที่ agent แต่ละตัวจะแบ่งปัน intent และสถานะของ task ระหว่างกัน ด้วยเหตุนี้ การเคลื่อนไหวเพื่อกำหนด specification มาตรฐานกลางจึงเร่งตัวขึ้นทั่วทั้งอุตสาหกรรม

"การเรียกใช้เครื่องมือ (Function Calling)" และ "การสื่อสารระหว่าง Agent" มักถูกสับสนกัน แต่ทั้งสองมีบทบาทที่แตกต่างกันโดยสิ้นเชิง การแบ่งการใช้งานระหว่าง MCP และ A2A มีพื้นฐานมาจากความแตกต่างนี้

การเรียกใช้เครื่องมือ คือการดำเนินการที่ Agent ร้องขอให้ฟังก์ชันภายนอกประมวลผลแทน ตัวอย่างทั่วไป ได้แก่ การค้นหาเว็บ การอ้างอิงฐานข้อมูล และการลงทะเบียนปฏิทิน โดยฝั่งเครื่องมือจะไม่ทำการตัดสินใจใดๆ แต่จะคืนค่าผลลัพธ์ตามกระบวนการที่กำหนดไว้เท่านั้น

การสื่อสารระหว่าง Agent คือการติดต่อกับ Agent อีกฝ่ายที่สามารถใช้เหตุผล ตัดสินใจ และวางแผนได้เช่นกัน โดยจะเกิดการโต้ตอบแบบสองทิศทาง เช่น การมอบหมายงาน การรายงานความคืบหน้า และการให้ Feedback ระหว่างกระบวนการ

ความแตกต่างหลักระหว่างทั้งสองมีดังนี้

• ความเป็นอิสระ: เครื่องมือทำงานแบบ Passive ในขณะที่ Agent ตัดสินใจและดำเนินการด้วยตนเอง
• การรักษาสถานะ: การเรียกใช้เครื่องมือโดยพื้นฐานแล้วเป็น Stateless ในขณะที่การสื่อสารระหว่าง Agent สามารถรักษา Session และบริบทไว้ได้
• ทิศทางการสื่อสาร: เครื่องมือเป็นแบบทิศทางเดียว ในขณะที่การสื่อสารระหว่าง Agent สามารถเป็นแบบ Asynchronous และสองทิศทางได้

ความแตกต่างนี้เชื่อมโยงโดยตรงกับการแบ่งบทบาทระหว่าง MCP และ A2A ซึ่งจะอธิบายในหัวข้อถัดไป

ยิ่งการใช้งาน AI Agent แพร่หลายมากขึ้นเท่าใด ต้นทุนในการออกแบบ "จุดเชื่อมต่อ" ระหว่างเครื่องมือต่างๆ ก็ยิ่งกลายเป็นความท้าทายที่ชัดเจนขึ้นเท่านั้น แม้ว่า Agent แต่ละตัวจะมีประสิทธิภาพสูง แต่หากกลไกการทำงานร่วมกันยังคงแตกต่างและไม่เป็นระบบ ผลิตภาพโดยรวมของระบบก็จะยังคงซบเซาต่อไป นี่คือเหตุผลที่แท้จริงว่าทำไมการสร้างมาตรฐาน (Standardization) จึงได้รับความสนใจอย่างมาก

การนำเครื่องมือ AI หลายตัวมาใช้งานพร้อมกัน จะทำให้ต้องเขียน glue code เฉพาะทางทุกครั้งที่ต้องการเชื่อมต่อกัน สาเหตุมาจากการที่แต่ละเครื่องมือมี API schema, วิธีการยืนยันตัวตน และรูปแบบข้อมูลเป็นของตัวเอง ปรากฏการณ์นี้เรียกว่า "การแยกส่วน (Silo) ของเครื่องมือ AI"

ปัญหาหลักที่เกิดจากการแยกส่วนมี 3 ประการ ได้แก่

• ต้นทุนการ Integration ที่เพิ่มสูงขึ้น: ยิ่งจำนวนเครื่องมือเพิ่มมากขึ้น การผสมผสานแบบ Pairwise Integration ก็ยิ่งเพิ่มขึ้นอย่างรวดเร็ว ปริมาณ connection code ที่ต้องจัดการก็มีแนวโน้มขยายตัวตามสัดส่วน
• การขาดความต่อเนื่องของ Context: เมื่อส่งข้อมูลระหว่าง Agent โดยไม่มีรูปแบบกลาง ข้อผิดพลาดในการแปลงข้อมูลและการสูญหายของข้อมูลมักเกิดขึ้นได้ง่าย ส่งผลให้ Agent ที่ทำงานต่อเนื่องทำงานบนสมมติฐานที่ผิดพลาด และเพิ่มความเสี่ยงที่ข้อผิดพลาดจะลุกลามต่อเนื่อง
• ความยากในการบำรุงรักษาและการ Monitoring: connection code ที่พัฒนาขึ้นเองจะต้องได้รับการแก้ไขทุกครั้งที่เครื่องมือมีการอัปเดตเวอร์ชัน และหากไม่มีรูปแบบ Log ที่เป็นมาตรฐาน การระบุสาเหตุของความผิดพลาดก็เป็นเรื่องยาก

แนวทาง "การจัดการแบบรายกรณี" ที่ยังพอยอมรับได้ในยุคที่ใช้เครื่องมือเพียงตัวเดียว กลับสะสมกลายเป็น Technical Debt ในระบบ Multi-Agent การถกเถียงเรื่องการกำหนดมาตรฐาน Protocol เกิดขึ้นจากความเจ็บปวดในทางปฏิบัติเหล่านี้เป็นฉากหลัง

เมื่อโปรโตคอลมาตรฐานได้รับการจัดทำขึ้นอย่างครบถ้วน ก็จะเกิดประโยชน์ในแง่ที่ว่า "การเชื่อมต่อที่สร้างขึ้นครั้งเดียวสามารถนำไปใช้ซ้ำได้ทุกที่" เช่นเดียวกับที่การรวมมาตรฐาน USB ทำให้เกิดสถานะ "เสียบแล้วใช้งานได้เลย" โลกของ AI Agent ก็กำลังเผชิญกับการเปลี่ยนแปลงในลักษณะเดียวกัน

ประโยชน์หลักมี 3 ประการดังนี้

• ลดต้นทุนการพัฒนา: เมื่อจัดเตรียม Adapter ที่สอดคล้องกับ Interface มาตรฐานไว้ครั้งเดียว ก็สามารถผสานรวมด้วยวิธีการเรียกใช้แบบเดิมได้ แม้จะมีเครื่องมือที่รองรับเพิ่มขึ้น ช่วยลดความยุ่งยากในการเขียน Glue Code แยกกันสำหรับแต่ละรายการ
• การขยายตัวของ Ecosystem: เมื่อข้อกำหนดได้รับการเผยแพร่สู่สาธารณะ ผู้จำหน่ายเครื่องมือและชุมชน OSS จะเริ่มพัฒนาและเผยแพร่ Connector ของตนเอง ตัวอย่างที่ดีคือหลังจากการเผยแพร่ข้อกำหนด MCP การ Implement Server จากบุคคลที่สามหลายรายการก็ปรากฏขึ้นในระยะเวลาอันสั้น
• ความสะดวกในการ Debug และการตรวจสอบ: เมื่อรูปแบบการสื่อสารได้รับการรวมเป็นมาตรฐาน โครงสร้าง Log จะมีความสอดคล้องกัน ทำให้ง่ายต่อการ Trace ว่าเกิดข้อผิดพลาดในการเรียกใช้เครื่องมือใด

อย่างไรก็ตาม การจะได้รับประโยชน์จากการทำงานร่วมกัน (Interoperability) นั้น มีข้อกำหนดเบื้องต้นคือ "ต้องรักษา Implementation ให้สอดคล้องกับโปรโตคอลอย่างต่อเนื่อง" การติดตามการอัปเดตเวอร์ชันของข้อกำหนดและการรับมือด้านความปลอดภัยเป็นสิ่งที่ต้องดำเนินการอย่างต่อเนื่องแม้หลังจากการทำให้เป็นมาตรฐานแล้ว ซึ่งเป็นประเด็นสำคัญที่ควรคำนึงถึง

MCP (Model Context Protocol) คือมาตรฐานการเชื่อมต่อแบบโอเพนซอร์สที่ Anthropic เปิดตัวขึ้น เพื่อเชื่อมโยง AI model เข้ากับเครื่องมือภายนอกและแหล่งข้อมูลต่าง ๆ บทความนี้จะอธิบายตั้งแต่โครงสร้างของ architecture ไปจนถึงตัวอย่างการเชื่อมต่อจริงอย่างเป็นขั้นตอน

MCP ประกอบด้วย 3 ชั้น ได้แก่ "Host" "Client" และ "Server" โดยมีจุดเด่นคือการออกแบบที่แบ่งแยกบทบาทอย่างชัดเจน

• Host: ชั้น Application ที่ผู้ใช้โต้ตอบด้วย ครอบคลุมสภาพแวดล้อมที่ AI Assistant ทำงานอยู่ เช่น Claude Desktop หรือส่วนขยายของ VS Code
• Client: ตัวกลางที่ฝังอยู่ภายใน Host ทำหน้าที่สื่อสารกับ Server ผ่าน JSON-RPC รับผิดชอบการดึงรายการ Tool การเรียกใช้งาน และการรับผลลัพธ์
• Server: ชั้นที่ให้การเข้าถึง Tool และแหล่งข้อมูลจริง ไม่ว่าจะเป็น File System, External API หรือ Database

สิ่งสำคัญคือ Server ไม่จำเป็นต้องรู้ถึงรายละเอียดภายในของ Host ที่เรียกใช้งาน เพียงแค่ส่ง Response ตามข้อกำหนดของ MCP ก็สามารถรองรับการเรียกใช้งานจาก Host ใดก็ได้

ขั้นตอนการสื่อสารดำเนินไปตามลำดับดังนี้ Host รับ Task เข้ามา จากนั้น Client ส่ง Request รายการ Tool ไปยัง Server แล้ว LLM จะพิจารณาว่าจะใช้ Tool ใด Client ส่งคำสั่งเรียกใช้งาน และ Server ส่งผลลัพธ์กลับมา ด้วยการแลกเปลี่ยน Capability ในช่วงเริ่มต้น ทำให้ Host สามารถรับรู้การกำหนดค่า Tool ของปลายทางที่เชื่อมต่ออยู่ได้แบบ Dynamic

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

สิ่งที่ทำได้ด้วย MCP

• การเรียกใช้ Tool (Function Calling): กำหนดการอ่านเขียนไฟล์ การ Query ฐานข้อมูล และการเรียกใช้ External API ในรูปแบบ "Tools Primitive" เพื่อให้ Model สามารถเรียกใช้ได้แบบ Dynamic
• การจัดหา Resource: ส่ง Static Context เช่น ไฟล์หรือเอกสารต่าง ๆ ไปยัง Model ผ่าน "Resources Primitive"
• การจัดการ Prompt Template: บริหารจัดการคำสั่งที่ใช้บ่อยจากฝั่ง Server แบบรวมศูนย์ผ่าน "Prompts Primitive" เพื่อนำกลับมาใช้ซ้ำได้

สิ่งที่ทำไม่ได้ด้วย MCP

MCP เป็น Protocol ที่เชี่ยวชาญด้าน "การสื่อสารในแนวตั้ง" ที่เชื่อมต่อ Model กับ Tool และ Resource โดยเฉพาะ จึงไม่รองรับ "การสื่อสารในแนวนอน" ที่ AI Agent หลายตัวมอบหมายงานให้กันและกัน

การจัดการ Session และการรักษาสถานะของงานระยะยาวก็อยู่นอกเหนือความรับผิดชอบของ MCP เช่นกัน ซึ่งจำเป็นต้องออกแบบเพิ่มเติมในฝั่ง Application การกำหนดตำแหน่งของ MCP ให้เป็น "มาตรฐาน Interface สำหรับการเชื่อมต่อ Tool" จึงเป็นแนวทางที่เหมาะสม

Claude Code คือ AI agent ที่เชี่ยวชาญด้านการเขียนโค้ด พัฒนาโดย Anthropic ด้วยการเชื่อมต่อกับเครื่องมือภายนอกผ่าน MCP จึงสามารถเรียกใช้งานต่างๆ ได้โดยตรงจาก agent เช่น การอ่านและเขียน file system การรันคำสั่ง shell และการจัดการ Git repository

ตัวอย่างการทำงานจริงมีดังนี้

• เมื่อได้รับคำสั่ง "แก้ไขเฉพาะ test ที่ล้มเหลว" ระบบจะประมวลผลโดยอัตโนมัติผ่าน MCP server ตั้งแต่การอ้างอิงไฟล์ → การรัน test → การรับผลลัพธ์ → การแก้ไขโค้ด
• เนื่องจากแต่ละ operation ถูก structure ตาม tool definition จึงสามารถประกาศได้อย่างชัดเจนว่า "จะเรียกใช้อะไรและอย่างไร"

OpenClaw คือหนึ่งใน open source implementation ของ MCP ที่ออกแบบมาเพื่อลดความซับซ้อนในการสร้างและจัดการ MCP server สามารถ wrap API endpoint ที่มีอยู่ให้กลายเป็น MCP tool และแปลงให้อยู่ในรูปแบบที่ client ที่รองรับ อย่างเช่น Claude Code สามารถเรียกใช้ได้

สิ่งสำคัญที่เป็นกุญแจสำคัญในการเชื่อมต่อทั้งสองแบบคือความแม่นยำของ tool definition หาก tool name, parameter และ description ไม่ชัดเจน จะเพิ่มความเสี่ยงที่ agent จะเรียกใช้งานผิดพลาด การเขียน schema อย่างละเอียดรอบคอบคือวิธีที่ตรงที่สุดในการดึงพฤติกรรมที่ต้องการออกมา

MCP เปรียบเสมือน "การเชื่อมต่อแนวตั้ง" ที่เชื่อม AI กับเครื่องมือต่างๆ ในขณะที่ A2A (Agent-to-Agent Protocol) คือ "การเชื่อมต่อแนวนอน" ที่เชื่อม Agent เข้าหากัน ต่อไปนี้จะอธิบายกลไกการมอบหมายงาน การดำเนินการ และการรายงานผลระหว่าง framework ที่แตกต่างกัน

A2A (Agent-to-Agent Protocol) คือข้อกำหนดแบบเปิด (Open Specification) ที่ Google เป็นผู้ริเริ่ม โดยมีแนวคิดพื้นฐานคือ "การสร้างภาษากลางที่ช่วยให้ Agent สามารถสื่อสารกันได้อย่างเท่าเทียม" หาก MCP ทำหน้าที่เชื่อมต่อ AI กับเครื่องมือ A2A จะมีจุดเด่นตรงที่ถือว่า Agent เองคือผู้ดำเนินการสื่อสาร

หัวใจของการออกแบบคือ Metadata ในรูปแบบ JSON ที่เรียกว่า Agent Card ซึ่งประกอบด้วยข้อมูลดังต่อไปนี้

• ประเภทของ Skill ที่รองรับ
• Endpoint ที่รับได้
• วิธีการ Authentication ที่รองรับ

ฝั่งผู้เรียกใช้จะดึง Agent Card มาก่อน จากนั้นตรวจสอบความสามารถของอีกฝ่าย แล้วจึงตัดสินใจมอบหมาย Task ให้ กระบวนการนี้เปรียบได้กับ "การแลกนามบัตรแนะนำตัวก่อน แล้วค่อยมอบหมายงาน"

การมอบหมาย Task เริ่มต้นด้วยการส่ง Task Object ผ่าน HTTP และหากการประมวลผลใช้เวลานาน จะใช้ Server-Sent Events หรือ WebSocket ในการ Streaming นอกจากนี้ยังรองรับ Multipart Message ที่ผสมผสานทั้งข้อความ ไฟล์ และข้อมูลแบบ Structured Data ได้อีกด้วย

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

การออร์เคสเตรชันของเอเจนต์ (Agent Orchestration) คือกลไกที่มอบหมายงานย่อย (subtask) ให้กับ AI เอเจนต์หลายตัว แล้วรวบรวมผลลัพธ์เพื่อบรรลุเป้าหมายโดยรวม A2A ทำหน้าที่กำหนดมาตรฐานให้กับกระบวนการ "มอบหมายและตอบสนอง" นี้

ฟังก์ชันหลักที่ A2A รับผิดชอบในการออร์เคสเตรชันมีดังนี้

• ออร์เคสเตรเตอร์อ้างอิง Agent Card เพื่อเลือกสเปเชียลิสต์เอเจนต์ที่เหมาะสม
• ส่งคำขอโดยระบุเนื้อหาของงานและรูปแบบผลลัพธ์ที่ต้องการ
• ติดตามความคืบหน้าของงานที่ใช้เวลานานผ่านการจัดการสถานะ submitted → working → completed

จุดแข็งที่สำคัญคือเอเจนต์แต่ละตัวไม่จำเป็นต้องรู้การทำงานภายในของกันและกัน จึงสามารถเชื่อมต่อระหว่างเอเจนต์ที่สร้างด้วยเฟรมเวิร์กหรือภาษาที่แตกต่างกันได้

ในทางกลับกัน หากงานย่อยมีขนาดเล็กเกินไป ค่าใช้จ่ายในการมอบหมายงาน (overhead) จะสะสมและทำให้การประมวลผลช้าลง การออกแบบขอบเขตว่าเอเจนต์ตัวเดียวควรรับผิดชอบงานส่วนใด และควรมอบหมายงานส่วนใดต่อไป จะเป็นตัวกำหนดทั้งประสิทธิภาพและความสามารถในการบำรุงรักษาระบบ

MCP และ A2A มีความแตกต่างกันอย่างพื้นฐานในด้าน "ระดับความละเอียดของการสื่อสาร" การตัดสินใจออกแบบว่าจะเรียกใช้ tool หรือจะมอบหมาย task ให้กับ agent นั้น คือจุดแบ่งที่ชี้ขาดว่าควรเลือกใช้ตัวไหน

จุดเริ่มต้นของการตัดสินใจคือ "ผู้ดำเนินการจะเปลี่ยนไปหรือไม่"

กรณีเลือกใช้ MCP:

• แอคชันที่เสร็จสิ้นในขั้นตอนเดียว เช่น การค้นหาฐานข้อมูล การจัดการไฟล์ หรือการเรียก external API
• กรณีที่ agent ไม่ส่งมอบการควบคุม แต่รับผลลัพธ์จากเครื่องมือแล้วตัดสินใจต่อด้วยตนเอง

กรณีเลือกใช้ A2A:

• กรณีที่มอบหมายความเป็นเจ้าของ task ให้กับ agent อื่นทั้งหมด
• กรณีที่อาจเกิดการตัดสินใจเพิ่มเติมระหว่างการดำเนินการ
• กรณีที่ปลายทางที่ถูกเรียกจำเป็นต้องรักษาสถานะ เช่น ประวัติการสนทนาหรือผลลัพธ์ขั้นกลาง

ทั้งสองไม่ได้ขัดแย้งกัน โครงสร้างแบบลำดับชั้นที่ sub-agent ซึ่งได้รับมอบหมายงานผ่าน A2A เรียกใช้เครื่องมือผ่าน MCP เพื่อดำเนินงานของตนเองนั้นเกิดขึ้นได้อย่างเป็นธรรมชาติ แนวคิดที่ว่า "แบ่งบทบาทด้วย A2A และเสริมความสามารถด้วย MCP" จะช่วยให้การออกแบบระบบมีทิศทางที่ชัดเจนยิ่งขึ้น

จัดระเบียบรูปแบบการออกแบบ (Design Pattern) ที่เป็นตัวแทนของระบบ Multi-Agent และความสัมพันธ์ที่สอดคล้องกันระหว่าง MCP และ A2A

รูปแบบ Orchestrator / Worker โครงสร้างที่ Agent กลางทำหน้าที่กระจายงานไปยัง Worker หลายตัว โดยใช้ A2A สำหรับการสั่งการจาก Orchestrator ไปยัง Worker และใช้ MCP เมื่อแต่ละ Worker เข้าถึงเครื่องมือภายนอก ซึ่งโครงสร้างสองชั้นนี้ผสานกันได้อย่างเป็นธรรมชาติ รูปแบบนี้ช่วยให้การแบ่งแยกหน้าที่ (Separation of Concerns) ชัดเจน และมีแนวโน้มที่จะเป็นจุดเริ่มต้นในการนำไปใช้งานได้ง่าย

รูปแบบ Pipeline ใช้ A2A สำหรับการส่งต่อข้อมูลระหว่าง Agent และใช้ MCP เสริมการเข้าถึงข้อมูลภายนอกในแต่ละขั้นตอน หากการประมวลผลเป็นเพียงการแปลงข้อมูล (Data Transformation) แบบง่าย ก็อาจใช้เพียง MCP เพียงอย่างเดียวก็เพียงพอ

รูปแบบ Flat Collaboration เป็นรูปแบบที่มีความสอดคล้องกับแนวคิดการออกแบบของ A2A มากที่สุด Agent ที่มีสถานะเท่าเทียมกันจะอ้างอิง Agent Card เพื่อมอบหมายงานให้กันแบบไดนามิก ในขณะที่ MCP รับผิดชอบการเข้าถึงเครื่องมือของแต่ละตัว อย่างไรก็ตาม แม้จะมีความยืดหยุ่นสูง แต่ต้องระวังในเรื่องที่ว่าการติดตามว่า Agent ตัวใดเป็นผู้ตัดสินใจอะไรนั้นอาจทำได้ยากขึ้น

เมื่อนำ MCP หรือ A2A มาใช้งานจริงในระบบ production การออกแบบด้านความปลอดภัยถือเป็นสิ่งที่ขาดไม่ได้ เช่นเดียวกับการออกแบบฟังก์ชันการทำงาน เนื่องจากเส้นทางการเรียกใช้ external tool และการมอบหมายงานระหว่าง agent อาจกลายเป็น attack surface ได้โดยตรง จึงจำเป็นต้องมีมาตรการรับมือที่เหมาะสม

ในการเชื่อมต่อภายนอกผ่าน MCP หรือ A2A นั้น Prompt Injection ถือเป็นภัยคุกคามที่เกิดขึ้นได้จริง นี่คือเทคนิคการโจมตีที่แทรกข้อความอันตรายเข้าไปในผลลัพธ์ของเครื่องมือเพื่อเขียนทับพฤติกรรมของ LLM และในโครงสร้างแบบ Multi-Agent นั้น จำเป็นต้องระวังเป็นพิเศษว่าผลลัพธ์ที่ปนเปื้อนอาจแพร่กระจายต่อเนื่องไปยัง Agent ถัดไปได้ง่าย

พื้นฐานของมาตรการรับมือคือการออกแบบ AI Guardrails แบบสองชั้นทั้งฝั่งอินพุตและเอาต์พุต

• ฝั่งอินพุต: ปฏิบัติต่อเนื้อหาที่ดึงมาจากภายนอกในฐานะ "ข้อมูลที่ไม่น่าเชื่อถือ" และแยกออกจาก System Prompt อย่างชัดเจน
• ฝั่งเอาต์พุต: ตรวจสอบ Action ที่ Agent กำลังจะดำเนินการกับ Allowlist และบล็อกการดำเนินการที่ไม่อยู่ในรายการโดยอัตโนมัติ

นอกจากนี้ หลักการ Least Privilege ก็มีความสำคัญเช่นกัน การจำกัดความละเอียดของสิทธิ์ตั้งแต่ขั้นตอนการออกแบบ Scope ของ MCP Server และการกำหนด Agent Skills เช่น ไม่มอบสิทธิ์การเขียนให้กับงานที่ต้องการเพียงการอ่านอย่างเดียว จะช่วยเพิ่มประสิทธิผลของ Guardrails ได้

ในสภาพแวดล้อม Multi-Agent มักมีแนวโน้มที่จะเลื่อนการออกแบบระบบ Authentication และ Authorization ออกไปก่อน อย่างไรก็ตาม หากปล่อยให้คำถามที่ว่า "ใครสามารถเข้าถึงทรัพยากรใด ด้วยสิทธิ์อะไร" ยังคลุมเครืออยู่ ก็อาจเกิดความเสี่ยงต่อการยกระดับสิทธิ์ (Privilege Escalation) หรือการเรียกใช้ Tool โดยไม่ได้ตั้งใจได้

ในข้อกำหนด A2A นั้น ได้กำหนดให้ใช้ OIDC Token เป็นกลไกการ Authentication ระหว่าง Agent เมื่อ Orchestrator มอบหมาย Task ให้ Sub-Agent โดยการแนบ Token ที่อิงกับ JWT ไว้ใน Request Header ฝั่งผู้รับก็สามารถตรวจสอบความถูกต้องของผู้เรียกได้ แนวทางเดียวกันนี้ยังมีประสิทธิภาพสำหรับการควบคุมการเข้าถึง MCP Server อีกด้วย

ประเด็นที่มักถูกมองข้ามในขั้นตอนการ Implement มีอยู่ 3 ข้อดังนี้

• การจัดการวันหมดอายุ: ใน Workflow ที่ทำงานต่อเนื่องเป็นเวลานาน อาจเกิดกรณีที่ Token หมดอายุระหว่างที่ Task ยังดำเนินอยู่
• Flow การต่ออายุอัตโนมัติ: ควรฝัง Logic การต่ออายุ Refresh Token เข้าไปใน Lifecycle ของ Agent
• หลักการ Least Privilege: จำกัด Scope ของแต่ละ Agent และไม่มอบสิทธิ์ที่ไม่จำเป็น

หากออกแบบระบบสิทธิ์แบบ Role-Based ให้มั่นคงตั้งแต่ช่วงเริ่มต้น จะช่วยลดการแก้ไขย้อนหลังได้อย่างมากในภายหลัง

ในขณะที่ความสนใจใน MCP และ A2A กำลังเพิ่มสูงขึ้น ในทางปฏิบัติก็ยังพบความเข้าใจผิดที่คลาดเคลื่อนจากความเป็นจริงอยู่บ้าง ในที่นี้จะขอจัดระเบียบความเข้าใจผิด 2 ประการที่มักได้ยินบ่อยครั้ง

MCP ไม่ใช่ "ตัวแทน" ของ REST API หรือ GraphQL แต่มีบทบาทที่แตกต่างกันโดยพื้นฐาน

API ที่มีอยู่เดิมเป็น interface อเนกประสงค์สำหรับการแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชัน ในขณะที่ MCP เชี่ยวชาญในการอธิบายและถ่ายทอดข้อมูลว่า AI agent "ใช้เครื่องมือใดได้บ้าง" และ "เรียกใช้งานอย่างไร" ในรูปแบบที่ LLM สามารถตีความได้

เมื่อจัดระเบียบความสัมพันธ์ในเชิงการ implement จะได้ดังนี้

• คง API endpoint ที่มีอยู่เดิมไว้ตามเดิม
• MCP server ทำหน้าที่เป็น wrapper บางๆ ที่ครอบอยู่เหนือ API
• มาตรฐานเฉพาะจุดเชื่อมต่อกับ agent เท่านั้น

ตัวอย่างเช่น ในกรณีที่ใช้งาน GitHub API แทนที่จะเขียน API ใหม่ทั้งหมด งานหลักคือการเขียนนิยามเครื่องมือ (tool definition) สำหรับการดำเนินการต่างๆ เช่น "ค้นหา repository" หรือ "สร้าง PR" ในรูปแบบที่ agent ตีความได้ง่ายขึ้น

หากปล่อยให้เกิดความเข้าใจผิดนี้ต่อไป มักจะก่อให้เกิดต้นทุนที่สูญเปล่าจากการบริหารจัดการ MCP และ API แบบคู่ขนาน การวาง MCP ในฐานะ adapter layer ที่เสริม API คือแนวทางการนำไปใช้งานจริงที่สมเหตุสมผลที่สุด

«A2A เป็นข้อกำหนดที่ผูกติดกับ LLM หรือ Framework เฉพาะหรือไม่» นี่เป็นหนึ่งในความเข้าใจผิดที่พบได้บ่อย

A2A ใช้การออกแบบที่สื่อสารผ่านข้อความ JSON บน HTTP เป็นหลัก จึงไม่ขึ้นอยู่กับประเภทของ LLM ที่ทำงานอยู่ภายใน ประเด็นสำคัญมีดังนี้

• Agent ที่มี Backend ต่างกัน ไม่ว่าจะเป็น GPT, Gemini, Claude หรือ Open-weight Model ก็สามารถสื่อสารระหว่างกันได้ หากปฏิบัติตามข้อกำหนดของ Agent Card
• ฝั่ง Orchestrator ไม่จำเป็นต้องรับรู้ถึงการ Implement ของ Model ฝั่งตรงข้าม แต่สามารถตัดสินใจมอบหมายงานได้โดยดูเพียง Interface ของ Input/Output ของ Task เท่านั้น
• การออกแบบนี้คำนึงถึงสภาพแวดล้อม Multi-vendor ที่ใช้หลาย Model ผสมกันอย่างชัดเจน เพื่อเลือกใช้ตามมุมมองด้านต้นทุน ความแม่นยำ และ Latency

อย่างไรก็ตาม «ไม่ขึ้นอยู่กับ Model» กับ «ทำงานได้ทันทีในทุกสภาพแวดล้อม» เป็นคนละเรื่องกัน ความสำเร็จหรือล้มเหลวของการมอบหมาย Task ขึ้นอยู่กับความถูกต้องของการบรรยายใน Agent Card และคุณภาพของการ Implement ของแต่ละ Agent Protocol มอบภาษากลางให้ แต่การนำไปใช้อย่างถูกต้องหรือไม่นั้นเป็นความรับผิดชอบของฝั่ง Implement

เมื่อเข้าใจแนวคิดของ MCP แล้ว วิธีที่ดีที่สุดในการเพิ่มความเข้าใจให้ลึกซึ้งยิ่งขึ้นคือการลงมือปฏิบัติจริงด้วยตัวเอง บทความนี้จะอธิบายขั้นตอนการเริ่มต้น Server ในสภาพแวดล้อมภายในเครื่อง (Local Environment) รวมถึงวิธีการกำหนด Agent Skills และการทดสอบตามลำดับ

หากต้องการทดลองใช้ MCP บนเครื่องของคุณ การตั้งค่าขั้นต่ำด้วย Python SDK ถือเป็นจุดเริ่มต้นที่เหมาะสม

ขั้นตอนการเริ่มต้นใช้งาน

• เตรียมสภาพแวดล้อม Python 3.10 ขึ้นไป แล้วติดตั้ง SDK ด้วยคำสั่ง pip install mcp
• กำหนดฟังก์ชันพร้อม decorator @mcp.tool() เพื่อให้ระบบลงทะเบียนเป็น tool โดยอัตโนมัติ
• เริ่มต้น server ด้วยคำสั่ง python server.py โดย transport เริ่มต้นคือ stdio (standard input/output)

เคล็ดลับการตรวจสอบการทำงาน

หลังจากเริ่มต้น server แล้ว แนะนำให้ใช้เครื่องมือ CLI อย่างเป็นทางการอย่าง MCP Inspector ซึ่งช่วยให้คุณดูรายการ tool และเรียกใช้งานด้วยตนเองผ่านเบราว์เซอร์ได้ เครื่องมือนี้มีประโยชน์อย่างมากในการวินิจฉัยปัญหาเบื้องต้น เช่น กรณีที่ "การตั้งค่าดูถูกต้องแล้วแต่ไม่มีการตอบสนอง"

การเชื่อมต่อกับ Host Application

สำหรับการเชื่อมต่อกับ host application อย่าง Claude Desktop เพียงระบุคำสั่งเริ่มต้นและ path ในไฟล์การตั้งค่า ระบบก็จะรู้จัก server ของคุณโดยอัตโนมัติ แนวทางที่ปฏิบัติได้จริงและช่วยให้ระบุปัญหาได้ง่ายคือ ตรวจสอบการเชื่อมต่อด้วย stdio ก่อน แล้วจึงค่อยเปลี่ยนไปใช้วิธี HTTP+SSE ตามความจำเป็น

เมื่อ MCP Server เริ่มทำงานแล้ว ให้ดำเนินการกำหนด Agent Skills ต่อไป Skills คือหน่วยของฟังก์ชันที่ Agent สามารถเรียกใช้จากภายนอกได้ โดยประกอบด้วย 3 องค์ประกอบดังนี้

• ชื่อ (Name): ตัวระบุที่ใช้ในการ routing
• คำอธิบาย (Description): เหตุผลที่ LLM ใช้ตัดสินว่า "ควรใช้เมื่อใด"
• Input/Output Schema: ระบุประเภทข้อมูลอย่างชัดเจนด้วย JSON Schema หรือ Pydantic model

หากคำอธิบายระบุไม่เพียงแค่ "ทำอะไรได้บ้าง" แต่ครอบคลุมถึง "ควรใช้ในสถานการณ์ใด" ด้วย จะช่วยเพิ่มความแม่นยำในการเลือกของ Orchestrator หากคำอธิบายยังคลุมเครือ มีแนวโน้มที่จะนำไปสู่การเลือก Task delegation ที่ผิดพลาดได้

การทดสอบจะจัดการได้ง่ายขึ้นหากแบ่งออกเป็น 2 ขั้นตอน

1. Unit Test: ส่ง request ตรงไปยัง MCP endpoint ด้วย curl หรือ httpx ของ Python เพื่อตรวจสอบประเภทของ response และการจัดการ error
2. Integration Test: ใช้ prompt สำหรับทดสอบ เพื่อตรวจสอบในกระบวนการต่อเนื่องว่า LLM สามารถเลือก Skill ที่ถูกต้อง กรอก parameter และตีความผลลัพธ์ได้อย่างถูกต้องหรือไม่

เมื่อจำนวน Skill เพิ่มมากขึ้น การหมั่นตรวจสอบว่าคำอธิบายแต่ละรายการไม่คล้ายกันเกินไปก็เป็นสิ่งสำคัญเช่นกัน คำอธิบายที่คล้ายกันเป็นต้นเหตุของการเลือกที่ผิดพลาด

ในขณะที่ศึกษา MCP และ A2A คำถามที่ว่า "แตกต่างจากกลไกที่มีอยู่เดิมอย่างไร" ก็เกิดขึ้นได้อย่างเป็นธรรมชาติ ในที่นี้จะจัดระเบียบโดยเน้นไปที่ 2 คำถามที่มักถูกหยิบยกขึ้นมาในการทำงานจริงเป็นพิเศษ

การเรียกใช้เครื่องมือ (Function Calling) คือกลไกที่ LLM ส่งออกความตั้งใจว่า "ต้องการให้รันฟังก์ชันนี้" ในรูปแบบ JSON แล้วให้ฝั่งแอปพลิเคชันเป็นผู้ประมวลผล เนื่องจากแต่ละ LLM provider นำไปใช้งานในแบบของตนเอง สเปกของการนิยาม schema และการจัดการข้อผิดพลาด (error handling) จึงแตกต่างกันไปในแต่ละ provider

ความแตกต่างหลักจาก MCP สรุปได้เป็น 3 ประเด็นดังนี้

• การมีหรือไม่มี independent layer: MCP แยกการนิยามเครื่องมือ การสื่อสาร และการยืนยันตัวตน (authentication) ออกจาก LLM provider และทำให้เป็นมาตรฐาน สามารถเรียกใช้ผ่าน interface เดียวกันจาก host ที่รองรับ ไม่ว่าจะเป็น Claude, GPT หรือ Gemini
• การจัดการ state: Function Calling เป็น stateless ในแต่ละ request แต่ MCP รักษา session ไว้ และได้รับการออกแบบให้รองรับการเก็บสถานะข้ามหลาย turn
• ความสามารถในการนำ schema กลับมาใช้ซ้ำ: Function Calling จำเป็นต้องเขียน schema ใหม่สำหรับแต่ละ provider แต่ MCP มีแนวโน้มที่จะลดความยุ่งยากในส่วนนี้ได้อย่างมาก

ทั้งสองไม่ได้แข่งขันกัน ในหลายกรณี MCP host ใช้ Function Calling ภายในเพื่อสร้างการเรียกไปยัง MCP server ดังนั้นในทางปฏิบัติจึงเป็นความสัมพันธ์แบบเสริมซึ่งกันและกัน จะเข้าใจได้ง่ายขึ้นหากจัดประเภทว่า Function Calling คือ "วิธีที่ LLM บอกว่าจะเรียกอะไร" ส่วน MCP คือ "โครงสร้างพื้นฐานร่วมสำหรับการจัดเตรียมและจัดการเครื่องมือ"

การตัดสินใจที่เหมาะสมควรพิจารณาจาก "สิ่งที่ต้องการให้ทำ" มากกว่าขนาดของทีม A2A จะแสดงศักยภาพที่แท้จริงได้ก็ต่อเมื่ออยู่ในสถานการณ์ที่ Agent ผู้เชี่ยวชาญหลายตัวทำงานแบบขนานหรือเชื่อมต่อกันเป็นลำดับเท่านั้น

กรณีที่ควรพิจารณาใช้ A2A

• ต้องการแบ่งงานให้ Agent แต่ละตัวรับผิดชอบแต่ละขั้นตอน เช่น "ค้นคว้า → สรุป → สร้างรายงาน"
• Agent จำเป็นต้องส่งคำสั่งไปยัง Agent อื่น
• ต้องการส่งต่องานโดยไม่ต้องรอการอนุมัติจากมนุษย์

กรณีที่ MCP เพียงพอ

• Agent ตัวเดียวสามารถเรียกใช้เครื่องมือภายนอกและทำงานได้ครบถ้วนในตัวเอง
• มีทรัพยากรด้านการออกแบบและการดำเนินงานจำกัด

การนำ A2A มาใช้มีแนวโน้มเพิ่มความซับซ้อนในการดำเนินงาน ทั้งในด้านการกำหนด Agent Skills และการจัดการสถานะของ Task มีรายงานว่าในทีมขนาดเล็ก ต้นทุนการบำรุงรักษาอาจไม่คุ้มค่า หากตอบว่า "ใช่" ต่อเกณฑ์การตัดสินใจข้างต้นข้อใดข้อหนึ่ง ก็ควรพิจารณาออกแบบระบบโดยคำนึงถึง A2A แต่หากไม่เป็นเช่นนั้น การให้ความสำคัญกับความเสถียรของสภาพแวดล้อม MCP ก่อน และเก็บ A2A ไว้เป็นตัวเลือกสำหรับการขยายระบบในอนาคต ถือเป็นทางเลือกที่สมเหตุสมผลในทางปฏิบัติ

สรุปเนื้อหาที่ผ่านมาเป็น 3 ประเด็นสำคัญ

ประเด็นที่ 1: MCP คือ "ภาษากลางที่เชื่อม Agent กับ Tool"

สิ่งที่ MCP แก้ไขคือต้นทุนในการเชื่อมต่อเมื่อ AI Agent เรียกใช้ Tool หรือแหล่งข้อมูลภายนอก เมื่อ implement MCP Server เพียงครั้งเดียว Tool นั้นก็สามารถนำกลับมาใช้ซ้ำได้จาก Agent ที่รองรับทุกตัว

ประเด็นที่ 2: A2A คือ "กติกาสำหรับการประสานงานระหว่าง Agent"

หาก MCP รับผิดชอบการเชื่อมต่อในแนวดิ่งสำหรับการเรียกใช้ Tool แล้ว A2A ก็เปิดให้เกิดการเชื่อมต่อในแนวนอนระหว่าง Agent แนวคิดการออกแบบที่ไม่ผูกติดกับ LLM หรือ runtime environment ใดเป็นพิเศษ คือสิ่งที่รองรับการ scale up อย่างยืดหยุ่นของระบบ Multi-Agent

ประเด็นที่ 3: Security และการออกแบบไม่ใช่เรื่องที่ผลัดไว้ทีหลังได้

ยิ่งนำ Protocol มาใช้มากเท่าไร attack surface ของระบบก็ยิ่งขยายกว้างขึ้นเท่านั้น การควบคุมการเข้าถึงด้วย OIDC Token และการตั้งค่า AI Guardrail เป็นเรื่องที่ควรพิจารณาควบคู่หรือก่อนหน้า performance tuning เสียด้วยซ้ำ

ข้อกำหนดต่าง ๆ ยังอยู่ในระหว่างการพัฒนา การลองรัน MCP Server สักหนึ่งตัวในสภาพแวดล้อมภายในเครื่องก่อน คือทางลัดที่จะเปลี่ยนแนวคิดที่เป็นนามธรรมให้กลายเป็นความเข้าใจที่จับต้องได้