คู่มือนักพัฒนาสำหรับโปรโตคอล AI Agent

• คู่มือที่รวม 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 มาตรฐาน มาใช้ตั้งแต่เนิ่น ๆ จะช่วยให้เข้ากันได้กับระบบนิเวศของเครื่องมือ บริการ และเอเจนต์

[carnoxen]

พอมารวมกันแบบนี้ โปรโตคอลที่เกี่ยวกับ AI มีเยอะมากจริง ๆ นะ