Agent Protocol Stack: MCP ต่อเครื่องมือ, A2A ต่อทีม, แล้ว Transport ต่อระบบจริง

หลายคนเริ่มรู้จัก MCP แล้วครับ

MCP หรือ Model Context Protocol มักถูกอธิบายแบบง่าย ๆ ว่าเป็น “USB-C ของ AI” คือทำให้ AI applications หรือ agents ต่อกับเครื่องมือ, data source, database, file, search, workflow และระบบอื่น ๆ ได้ด้วยมาตรฐานเดียวกัน

คำอธิบายนี้ถูก และมีประโยชน์มาก

แต่ปัญหาคือหลายทีมเริ่มกระโดดจากประโยคนี้ไปสรุปว่า

“ถ้าเรามี MCP แปลว่าเรามี AI Agent architecture แล้ว”

ผมว่าอันนี้ยังเร็วไปครับ

บทความล่าสุดของ VentureBeat ตั้งคำถามที่ดีมากว่า ในโลกของ AI Agent ตอนนี้ MCP แก้ tool calling แล้ว A2A แก้ task coordination แล้ว แล้ว transport ล่ะ ใครแก้

ประโยคนี้ฟัง technical แต่จริง ๆ แล้วเป็นคำถามธุรกิจมาก ๆ

เพราะถ้า Agent จะทำงานแทนเราในระบบจริง มันไม่ได้ต้องการแค่ tool แต่มันต้องการเส้นทาง, สิทธิ์, ตัวตน, การเชื่อมต่อ, การยืนยัน, approval และ log ที่คุมได้ด้วย

1) MCP คือชั้นของ tool ไม่ใช่ทั้งบ้าน

จากเอกสาร official ของ MCP ตัว protocol ถูกวางไว้เป็นมาตรฐานสำหรับเชื่อม AI applications กับ external systems เช่น data sources, tools และ workflows

แปลเป็นภาษาธุรกิจคือ MCP ช่วยให้ Agent “มีมือ” ครับ

มือที่หยิบไฟล์ได้ มือที่ query database ได้ มือที่สร้าง ticket ได้ มือที่เรียก API ได้ มือที่ทำงานซ้ำ ๆ แทนคนได้

นี่สำคัญมาก เพราะก่อนมีมาตรฐานแบบนี้ ทุกระบบต้องเขียน connector แยกกันแทบหมด

แต่การมีมือไม่ได้แปลว่าคนคนนั้นควรทำทุกอย่างได้

ถ้าเปรียบเป็นพนักงานใหม่ MCP คือการให้พนักงานมี access ไปยังเครื่องมือทำงาน เช่น CRM, Google Drive, GitHub หรือระบบคลังสินค้า

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

นี่คือเหตุผลที่ MCP เป็นชั้นสำคัญ แต่ยังไม่พอ

2) A2A คือชั้นของการมอบหมายงานระหว่าง Agent

ฝั่ง A2A หรือ Agent2Agent Protocol ถูก Google และ ecosystem อธิบายว่าเป็น protocol สำหรับให้ Agent สื่อสารและทำงานร่วมกัน

A2A ไม่ได้มาแทน MCP เอกสาร A2A พูดชัดว่า MCP กับ A2A ไม่ใช่คู่แข่งกัน แต่แก้คนละปัญหา

MCP คือ agent-to-tool A2A คือ agent-to-agent

ตัวอย่างง่าย ๆ:

• Agent ฝ่ายขายต้องให้ Agent วิเคราะห์ข้อมูลช่วยจัดกลุ่ม lead
• Agent support ต้องส่งเคส technical ไปให้ Agent engineer ตรวจ log
• Agent marketing ต้องขอ Agent finance เช็ก budget ก่อนยิงแคมเปญ
• Agent content ต้องให้ Agent compliance ตรวจคำโฆษณาก่อน publish

ถ้ามีแค่ MCP แต่ไม่มีวิธีคิดเรื่อง agent-to-agent coordination ระบบจะกลายเป็น Agent หลายตัวที่ต่างคนต่างมี tool แต่ไม่มีวิธีส่งต่องานที่ชัด

เหมือนบริษัทที่มีพนักงานเก่งหลายคน แต่ไม่มี process ว่าใครรับไม้ต่อ ใครเป็นเจ้าของผลลัพธ์สุดท้าย และใครต้อง approve ก่อนงานออกนอกบริษัท

3) Transport คือคำถามว่า Agent จะเจอกันและคุยกันได้จริงแค่ไหน

จุดที่ VentureBeat ชี้น่าสนใจคือ แม้ MCP และ A2A จะเริ่มทำให้ชั้น application ชัดขึ้น แต่โลกจริงยังมีคำถามเรื่อง transport และ connection อีกมาก

คำว่า transport ในบริบทนี้อย่าเพิ่งมองแค่ transport ใน spec ว่าใช้ stdio หรือ Streamable HTTP เท่านั้นนะครับ

สำหรับ operator ผมจะมองกว้างกว่า:

• Agent หรือ server อยู่ local, cloud, private network หรือ vendor platform
• ใครเปิด connection ไปหาใคร
• connection นั้นผ่าน authentication แบบไหน
• ถ้า network หลุด task ควรถูก cancel หรือ resume
• agent จะ discover capability ของอีกฝั่งได้อย่างไร
• มี gateway, allowlist, policy และ audit log ตรงกลางไหม

MCP spec เองมีรายละเอียดเรื่อง stdio และ Streamable HTTP รวมถึงข้อควรระวังด้าน security เช่น Origin validation, localhost binding และ authentication

นี่เป็นสัญญาณที่ดีว่า protocol layer เริ่มคิดเรื่องความปลอดภัยจริงจัง

แต่พอระบบเข้าสู่ธุรกิจจริง คำถามจะหนักขึ้นอีกครับ

เพราะธุรกิจไม่ได้ถามแค่ “เรียก tool ได้ไหม” แต่ถามว่า “เรียก tool นี้จาก network นี้ ด้วยตัวตนนี้ ในบริบทนี้ ได้หรือไม่”

4) ทำไมเรื่องนี้สำคัญกับ SME และทีมเล็ก

บางคนอาจคิดว่าเรื่อง protocol stack เป็นเรื่องของ enterprise ใหญ่เท่านั้น

ผมคิดว่าไม่ใช่ครับ

SME และทีมเล็กยิ่งต้องคิดให้ชัด เพราะมักมีคนน้อย ระบบน้อย และการคุมสิทธิ์อาจยังไม่ละเอียด

สมมติธุรกิจหนึ่งอยากทำ AI Agent ช่วยงานหลังบ้าน:

• อ่าน lead จาก Facebook หรือ LINE
• สรุปความต้องการลูกค้า
• เปิด ticket ใน CRM
• ดึงข้อมูล product จาก knowledge base
• ร่างใบเสนอราคา
• แจ้งเตือนเจ้าของก่อนส่งให้ลูกค้า

ถ้ามองแบบ chatbot เราอาจถามแค่ว่า model ไหนตอบดี

แต่ถ้ามองแบบ Agent Protocol Stack เราจะถามลึกขึ้น:

• MCP server ไหนเป็น read-only
• tool ไหนเป็น write action
• action ไหนต้อง human approval
• Agent ฝ่ายขายกับ Agent เอกสารส่งต่องานกันอย่างไร
• ถ้า API ล่มหรือ session ขาด จะ retry อย่างไร
• owner เห็น proof ของงานที่ Agent ทำตรงไหน

นี่แหละครับที่ทำให้ AI Agent จาก demo กลายเป็น workflow ที่ใช้ในธุรกิจได้จริง

5) Framework ที่ผมแนะนำ: 5 ชั้นก่อนปล่อย Agent แตะงานจริง

ถ้าจะเอาเรื่องนี้ไปใช้จริง ผมแนะนำให้เริ่มจาก 5 ชั้นนี้

ชั้นที่ 1: Tool layer

ตอบให้ได้ว่า Agent ต่อ tool อะไรบ้าง

เช่น CRM, email, calendar, GitHub, Google Drive, database, payment, analytics หรือ support inbox

จุดสำคัญคืออย่ารวมทุกอย่างไว้ใน MCP server เดียวแบบเปิดกว้างเกินไป

แยก read tool กับ write tool ให้ชัด และลด scope ให้แคบที่สุดเท่าที่ทำได้

ชั้นที่ 2: Task layer

ตอบให้ได้ว่า Agent ทำงานอะไร และใครรับผิดชอบ output สุดท้าย

ถ้ามีหลาย Agent ให้ระบุ flow ว่าใครเริ่ม ใครช่วย ใครตรวจ ใครส่งต่องาน

อย่าปล่อยให้ Agent หลายตัวคุยกันแบบไม่มี owner เพราะเวลาพลาดจะไม่มีใครรู้ว่าควรแก้ตรงไหน

ชั้นที่ 3: Connection layer

ตอบให้ได้ว่า Agent, tool server และระบบธุรกิจเชื่อมต่อกันผ่านอะไร

local หรือ cloud private หรือ public endpoint ใช้ token, OAuth, service account หรือ gateway มี allowlist หรือไม่ มี timeout, retry, resume หรือ cancel behavior ชัดไหม

สำหรับผม นี่คือชั้นที่หลายทีมข้ามเร็วเกินไป

ชั้นที่ 4: Approval layer

ตอบให้ได้ว่างานไหน AI ทำเองได้ และงานไหนต้องให้คนกดอนุมัติ

ตัวอย่างงานที่ควรมี approval:

• ส่งข้อความหาลูกค้า
• เปลี่ยนราคา
• refund หรือเรียกเก็บเงิน
• ลบข้อมูล
• deploy code
• แก้ข้อมูลสำคัญใน CRM

AI ที่ดีไม่ใช่ AI ที่ทำทุกอย่างเอง แต่คือ AI ที่รู้ว่าอะไรควรหยุดรอคนตัดสินใจ

ชั้นที่ 5: Proof layer

ตอบให้ได้ว่าเราดูย้อนหลังได้ไหมว่า Agent ทำอะไร เพราะอะไร และใช้ข้อมูลจากไหน

Proof layer ควรมีอย่างน้อย:

• input ที่ Agent รับ
• tool ที่ถูกเรียก
• output ที่ได้
• approval decision ถ้ามี
• error หรือ retry
• link ไปยัง artifact เช่น ticket, document, commit หรือ report

ถ้าไม่มี proof layer ธุรกิจจะวัดไม่ได้ว่า Agent ช่วยจริงหรือแค่สร้างความรู้สึกว่าระบบฉลาด

6) ข้อควรระวัง: อย่าใช้คำว่า protocol มาบัง governance

มี protocol ไม่ได้แปลว่ามี governance

มี MCP ไม่ได้แปลว่า tool ปลอดภัย มี A2A ไม่ได้แปลว่า delegation ถูกต้อง มี HTTP endpoint ไม่ได้แปลว่า connection ควรเปิดให้ทุกที่ มี log ไม่ได้แปลว่าคนจะอ่านเข้าใจ

นี่คือจุดที่ operator ต้องเข้ามาออกแบบครับ

ในงานจริง เราต้องแปลง protocol ให้กลายเป็น policy, SOP, permission, approval และ monitoring

ถ้าไม่ทำ ชั้น protocol จะกลายเป็นแค่ศัพท์สวย ๆ ที่ทำให้ระบบดู modern แต่ยังเสี่ยงเหมือนเดิม

7) ธุรกิจควรเริ่มจากตรงไหน

ถ้าทีมคุณเริ่มทำ AI Agent ผมแนะนำให้เริ่มจาก workflow เดียวก่อน

เลือก workflow ที่มี input และ output ชัด เช่น:

• สรุป lead แล้วเปิด CRM task
• อ่าน ticket แล้วเสนอ reply draft
• เช็กเอกสารก่อนส่งให้ลูกค้า
• สรุปประชุมแล้วสร้าง action item
• ตรวจ campaign draft ก่อน publish

จากนั้นเขียน Agent Stack Map แบบสั้น ๆ:

1. Agent รับข้อมูลจากไหน
2. ใช้ MCP tools อะไร
3. ถ้ามี Agent อื่น ใครรับไม้ต่อ
4. connection วิ่งผ่าน endpoint หรือ gateway ไหน
5. action ไหนต้อง approval
6. proof อยู่ที่ไหน

ทำแค่นี้ก่อนก็ช่วยลดความเสี่ยงได้เยอะครับ

เพราะเราจะเริ่มเห็นว่า AI Agent ไม่ใช่แค่ prompt และ model แต่เป็นระบบปฏิบัติการย่อยของ workflow หนึ่ง ๆ

สรุป

ในความเห็นของผม ข่าวนี้สำคัญเพราะมันเตือนว่าโลก AI Agent กำลังแยกชั้นชัดขึ้น

MCP คือชั้นที่ทำให้ Agent ต่อเครื่องมือได้ A2A คือชั้นที่ทำให้ Agent ประสานงานกันได้ แต่ธุรกิจยังต้องออกแบบ connection, identity, permission, approval และ proof เองให้ชัด

ถ้าจะใช้ AI Agent ในงานจริง อย่าถามแค่ว่า “ต่อ tool อะไรได้บ้าง”

ให้ถามว่า “ถ้า Agent ตัวนี้ทำงานพลาด เรารู้ไหมว่ามันเกิดที่ชั้นไหน และหยุดมันได้ตรงไหน”

สุดท้าย AI Agent ที่ดี ไม่ใช่ตัวที่มี tool เยอะที่สุดครับ แต่คือตัวที่วิ่งอยู่บนถนนที่เราคุมได้จริง