- คู่มือที่รวม 6 โปรโตคอล AI Agent ได้แก่ MCP, A2A, UCP, AP2, A2UI และ AG-UI ไว้ในสถานการณ์ตัวอย่างเดียวของเอเจนต์ซัพพลายเชนร้านอาหาร พร้อมอธิบายทีละขั้นว่าทุกโปรโตคอลแก้ปัญหาอะไร โดยมีโค้ดใช้งานจริงประกอบ
- ใช้ Agent Development Kit (ADK) ของ Google เป็นฐาน เริ่มจาก LLM ว่างเปล่า แล้วค่อย ๆ เพิ่มโปรโตคอลทีละตัวจนทำได้ครบตั้งแต่ตรวจสต็อก ขอใบเสนอราคา สั่งซื้อ ชำระเงิน ไปจนถึงเรนเดอร์แดชบอร์ด
- MCP รับผิดชอบการเชื่อมต่อเครื่องมือ/ข้อมูล, A2A ดูแลการสื่อสารระหว่างเอเจนต์, UCP ทำมาตรฐานงานพาณิชย์, AP2 จัดการการอนุมัติการชำระเงิน, A2UI สร้าง UI, และ AG-UI จัดการการส่งสตรีม
- แต่ละโปรโตคอลใช้แพตเทิร์นร่วมกัน เช่น การค้นพบผ่าน URL ที่รู้จักกันดี, schema แบบระบุชนิด, และ event stream มาตรฐาน เพื่อให้เข้ากันได้ในระบบนิเวศ
- ไม่จำเป็นต้องนำทั้ง 6 ตัวมาใช้ตั้งแต่วันแรก แต่แนะนำแนวทาง ค่อย ๆ เพิ่มตามความจำเป็น
MCP(Model Context Protocol) — การเชื่อมต่อเครื่องมือและข้อมูล
- เป็นโปรโตคอลที่แก้อุปสรรคด่านแรกเมื่อเชื่อมเอเจนต์เข้ากับระบบและข้อมูล โดยช่วย ตัดงานเขียนโค้ด integration แบบ custom สำหรับแต่ละ API ด้วยมือ
- โครงสร้างคือ MCP server ประกาศเครื่องมือของตัวเอง (advertise) แล้วเอเจนต์จะค้นพบได้อัตโนมัติ ทำให้มี รูปแบบการเชื่อมต่อมาตรฐานเดียว สำหรับเซิร์ฟเวอร์นับร้อย
- MCP server ถูกดูแลโดยทีมที่สร้างระบบนั้น ๆ จึงทำให้ฝั่งเอเจนต์ ไม่ต้องเขียนหรืออัปเดตโค้ด integration เอง และได้คำจำกัดความของเครื่องมือที่เป็นปัจจุบันเสมอ
- ใน ADK มีการรองรับระดับ first-class ผ่าน McpToolset และในตัวอย่างได้สาธิตการ query ฐานข้อมูล PostgreSQL (MCP Toolbox for Databases), การดูสูตรผ่าน Notion MCP และการส่งอีเมลถึงซัพพลายเออร์ผ่าน Mailgun MCP
- เชื่อมต่อฐานข้อมูลสต็อกด้วย
ToolboxToolset
- เชื่อมต่อบริการภายนอก เช่น Notion, Mailgun ด้วย
McpToolset
- เป็นแพตเทิร์นที่กระชับ โดยรัน MCP server ด้วยคำสั่ง
npx แล้วเชื่อมเข้ากับเอเจนต์ได้ทันทีโดยแทบไม่ต้องมีโค้ดเพิ่มเติม
A2A(Agent2Agent Protocol) — การสื่อสารระหว่างเอเจนต์
- หลังจาก MCP แก้เรื่องการเข้าถึงข้อมูลแล้ว โปรโตคอลนี้มาจัดการปัญหาเรื่อง ความเชี่ยวชาญ (expertise) โดยให้ วิธีค้นพบและสื่อสารแบบมาตรฐาน ระหว่าง remote agent ที่ทำงานอยู่ต่างทีม ต่างเฟรมเวิร์ก และต่างเซิร์ฟเวอร์
- A2A agent แต่ละตัวจะเผยแพร่ Agent Card ไว้ที่
/.well-known/agent-card.json เพื่อบอกชื่อ ความสามารถ และ endpoint จากนั้นเอเจนต์ผู้จัดการครัวจะดึงข้อมูลนี้มาใช้และ route query ไปยังเอเจนต์ที่เหมาะสมขณะรันจริง
- เมื่อเพิ่ม remote agent ใหม่ ก็แค่ เพิ่ม URL โดยไม่ต้องแก้โค้ดหรือ redeploy แบบ manual
RemoteA2aAgent ใน ADK จะ route ไปยัง remote agent ได้หนึ่งตัวต่อหนึ่ง turn และถ้าต้อง query remote agent หลายตัวพร้อมกัน ต้องใช้ a2a-sdk โดยตรง- ใช้ฟังก์ชัน
to_a2a() เพื่อ แปลง ADK agent ทุกตัวให้เป็น A2A service ได้
- แม้ข้อมูลดิบอย่างราคาปัจจุบัน เกรดคุณภาพ หรือช่วงเวลาจัดส่ง จะไม่ได้ถูกเปิดผ่าน API ก็ยัง เข้าถึงได้ผ่าน agentic interface
UCP(Universal Commerce Protocol) — การทำมาตรฐานงานพาณิชย์
- เป็นโปรโตคอลที่ รวมกระบวนการสั่งซื้อ ซึ่งเดิมแต่ละซัพพลายเออร์มี API ต่างกัน ให้มาอยู่ในมาตรฐานเดียว โดยทำมาตรฐานวงจรการซื้อขายให้เป็นฟังก์ชันแบบโมดูลาร์
- ใช้ schema request/response แบบ strongly typed เพื่อรักษาความสม่ำเสมอ และไม่ว่า transport ชั้นล่างจะเป็น REST, MCP, A2A หรือ EP (browser-based embedded protocol) ก็ทำงานด้วยแพตเทิร์นเดียวกัน
- สามารถค้นพบแค็ตตาล็อกของซัพพลายเออร์ได้ด้วยแพตเทิร์น URL
/.well-known/ucp แบบเดียวกับ A2A
- ไม่ต้องใช้ SDK เฉพาะทางแบบปิด และเชื่อมกับ REST API มาตรฐานได้ทันทีด้วย HTTP client เดิม
- ในตัวอย่างใช้
CheckoutCreateRequest เพื่อสั่งซื้อปลาแซลมอน 10 ปอนด์และน้ำมันมะกอก 3 ขวด และใช้ PaymentCreateRequest เพื่อจัดรูปคำขอชำระเงิน
- ในคลังตัวอย่างของ UCP มีตัวอย่าง ผู้ช่วยช้อปปิ้งที่ขับเคลื่อนด้วย AI ซึ่งรวม ADK และ A2A เข้าด้วยกัน
AP2(Agent Payments Protocol) — การอนุมัติการชำระเงินและ audit trail
- ถ้า UCP จัดการเรื่องจะสั่งซื้ออะไรและจากซัพพลายเออร์รายไหน AP2 จะรับผิดชอบเรื่อง ใครเป็นผู้อนุมัติการซื้อและการติดตามเพื่อตรวจสอบย้อนหลัง
- ใช้ mandate แบบระบุชนิด เพื่อให้มีหลักฐานเจตนาแบบปฏิเสธไม่ได้ (non-repudiatable proof of intent) และใส่ guardrail ที่กำหนดค่าได้ ให้กับทุกธุรกรรม
- ฟลोว์ทั้งหมดคือ
IntentMandate → PaymentMandate (เซ็นแล้ว) → PaymentReceipt
- IntentMandate: ตั้ง guardrail เช่น ร้านค้าที่อนุญาต วงเงินใช้จ่าย อนุมัติอัตโนมัติหรือไม่ ต้องรองรับการคืนเงินหรือไม่ และเวลาหมดอายุ
- PaymentMandate: หนังสือมอบหมายการชำระเงินที่ผูกกับตะกร้าสินค้าและจำนวนเงินที่ระบุชัด ซึ่งจะยังไม่ถูกเซ็นหากยอดเกินวงเงิน จนกว่าผู้จัดการจะอนุมัติอย่างชัดแจ้ง
- PaymentReceipt: ใบเสร็จที่ทำให้ audit trail สมบูรณ์
- ทำงานเป็น extension ของ UCP โดยเพิ่ม หลักฐานการอนุมัติที่เข้ารหัสไว้ เข้าไปใน checkout flow
- ตอนนี้ยังอยู่ในระยะ v0.1 และยังไม่ได้ built-in ใน ADK core แต่มี type ให้ใช้งานผ่านแพ็กเกจแยก
A2UI(Agent-to-User Interface Protocol) — การประกอบ UI แบบไดนามิก
- เป็นโปรโตคอลที่ทำให้เอเจนต์สามารถประกอบ แดชบอร์ด ฟอร์มสั่งซื้อ ตารางเปรียบเทียบซัพพลายเออร์ และ UI อื่น ๆ แบบไดนามิก แทนการตอบเป็นข้อความธรรมดา
- ใช้รูปแบบ JSON แบบประกาศเชิงโครงสร้างเพื่อผสมเลย์เอาต์ใหม่จากแค็ตตาล็อกคงที่ที่มี คอมโพเนนต์ primitive ปลอดภัย 18 แบบ เช่น row, column, text field
- แยก โครงสร้าง UI ออกจาก ข้อมูล ทำให้อัปเดตเฉพาะข้อมูลได้โดยไม่ต้องส่งคอมโพเนนต์ซ้ำ
- คอมโพเนนต์จะถูกส่งเป็น flat list ที่อ้างอิงกันผ่าน ID
- ข้อมูลจะส่งแยกผ่าน
dataModelUpdate
- ฝั่งไคลเอนต์จะมี renderer แปลง JSON เป็น native UI เช่น Lit, Flutter, Angular
- เอเจนต์ตัวเดียวกันสามารถสร้าง อินเทอร์เฟซที่แตกต่างกันโดยสิ้นเชิง เช่น เช็กลิสต์ตรวจสต็อก ฟอร์มสั่งซื้อ หรือหน้าจอเปรียบเทียบซัพพลายเออร์ ได้จาก primitive 18 แบบเดียวกัน
- ในเว็บอินเทอร์เฟซของ ADK (
adk web) สามารถ เรนเดอร์คอมโพเนนต์ A2UI ได้แบบเนทีฟ จึงไม่ต้องสร้าง renderer แยกในช่วงพัฒนา
- สามารถจัดวางเลย์เอาต์แบบอินเทอร์แอ็กทีฟได้ด้วย A2UI Widget Builder
AG-UI(Agent-User Interaction Protocol) — การส่งแบบสตรีม
- เอเจนต์ต่างจาก REST API แบบเดิม เพราะสามารถสตรีมข้อความทีละส่วน เรียกใช้เครื่องมือระหว่างตอบ และหยุดชั่วคราวเพื่อรออินพุตจากมนุษย์ได้ จึงมี แพตเทิร์นปฏิสัมพันธ์ที่ซับซ้อน
- AG-UI ทำงานเป็น middleware ที่แปลง raw event ของแต่ละเฟรมเวิร์กให้เป็น SSE stream มาตรฐาน
- ฝั่งฟรอนต์เอนด์เพียงรับ event แบบระบุชนิด เช่น
TEXT_MESSAGE_CONTENT, TOOL_CALL_START ก็พอ โดยไม่จำเป็นต้องรู้ว่า event นั้นมาจาก agent framework ตัวใด
- ADK มี endpoint
/run_sse แบบเนทีฟอยู่แล้ว แต่มีปัญหาคือโค้ด parse ค่อนข้าง boilerplate และอาจพังเมื่อรูปแบบ event เปลี่ยน ซึ่ง AG-UI เข้ามาแก้ตรงนี้
- แค่ครอบด้วยแพ็กเกจ
ag_ui_adk แล้ว mount เข้ากับแอป FastAPI ก็สร้าง AG-UI streaming endpoint ได้
ลำดับการทำงานแบบบูรณาการทั้งหมด
- เมื่อผู้ใช้ขอว่า “ตรวจสต็อกปลาแซลมอน ดูราคาขายส่งวันนี้และเกรดคุณภาพ แล้วถ้าสต็อกไม่พอให้สั่ง 10 ปอนด์จาก Example Wholesale พร้อมอนุมัติการชำระเงิน” ก็จะเกิดการทำงานของ ทั้ง 6 โปรโตคอลแบบเป็นลำดับขั้น
- ขั้นที่ 1 — รวบรวมข้อมูล: ใช้ MCP query ฐานข้อมูลสต็อก (
check_inventory) → ใช้ A2A query ไปยังเอเจนต์ระยะไกลด้านราคาและคุณภาพ (ask_agent)
- ขั้นที่ 2 — ทำธุรกรรมให้เสร็จ: ใช้ UCP ส่งคำขอ checkout (
place_order) → ใช้ AP2 ขอ payment mandate ภายใต้ guardrail ที่ตั้งไว้ (authorize_payment)
- ขั้นที่ 3 — แสดงผลลัพธ์: ใช้ A2UI สร้างวิดเจ็ตแบบโต้ตอบ → ใช้ AG-UI สตรีมการเรียกเครื่องมือและข้อความตอบกลับแบบเรียลไทม์
เคล็ดลับการใช้โปรโตคอล
- ต้อง เข้าใจให้แม่นว่าแต่ละโปรโตคอลแก้ปัญหาอะไร เพื่อให้สถาปัตยกรรมยังคงสะอาดและเป็นระเบียบ
- ไม่จำเป็นต้องใช้ทั้ง 6 ตัวตั้งแต่แรก โดยส่วนใหญ่ควร เริ่มจาก MCP แล้วค่อยเพิ่มการสื่อสารหลายเอเจนต์ งานพาณิชย์ การชำระเงิน rich UI และการสตรีม ตามความต้องการที่เพิ่มขึ้น
- ก่อนจะลงมือสร้างด้วยโปรโตคอล ควรตรวจสอบ การรวมกับ ADK, SDK ทางการ และโค้ดตัวอย่าง ก่อน เพื่อหลีกเลี่ยงการเขียนซ้ำเองโดยไม่จำเป็น
- แม้โปรโตคอลเหล่านี้ยังอยู่ระหว่างพัฒนาให้สมบูรณ์ แต่การ รับแพตเทิร์นอย่างการค้นพบผ่าน URL ที่รู้จักกันดี, schema แบบระบุชนิด, และ event stream มาตรฐาน มาใช้ตั้งแต่เนิ่น ๆ จะช่วยให้เข้ากันได้กับระบบนิเวศของเครื่องมือ บริการ และเอเจนต์
1 ความคิดเห็น
พอมารวมกันแบบนี้ โปรโตคอลที่เกี่ยวกับ AI มีเยอะมากจริง ๆ นะ