A2A protocol

A2A protocol ย่อมาจาก Agent2Agent เป็นมาตรฐานเปิดที่กำหนดวิธีให้ agent AI ตัวหนึ่งส่งงานไปให้ agent อีกตัวทำต่อ แม้ agent สองตัวนั้นจะสร้างด้วยเฟรมเวิร์กคนละแบบ อยู่คนละบริษัท และรันอยู่คนละคลาวด์ เว็บทางการนิยามไว้ว่าเป็นมาตรฐานเปิดสำหรับ "communication and collaboration between AI agents" จุดที่ทำให้คนทำงานควรรู้จักคำนี้คือมันตอบคำถามที่องค์กรเจอทันทีที่มี agent มากกว่าหนึ่งตัว นั่นคือถ้าฝ่ายจัดซื้อใช้ agent เจ้าหนึ่ง ฝ่ายบัญชีใช้อีกเจ้าหนึ่ง แล้วสองงานนี้ต้องต่อกัน จะให้มันคุยกันยังไงโดยไม่ต้องจ้างเขียนตัวเชื่อมใหม่ทุกคู่ที่เพิ่มเข้ามา ความสับสนที่พบบ่อยที่สุดคือการเอาไปปนกับ mcp ซึ่งเป็นคนละชั้นกัน MCP ทำหน้าที่ต่อ agent เข้ากับเครื่องมือและแหล่งข้อมูล ส่วน A2A ทำหน้าที่ต่อ agent เข้ากับ agent เอกสารทางการของ A2A ระบุชัดว่าสองมาตรฐานนี้เสริมกัน ไม่ได้แข่งกัน

กลไกจริงเรียบง่ายกว่าที่ชื่อฟังดู หัวใจอยู่ที่ Agent Card ซึ่งเป็นไฟล์ JSON ทำหน้าที่เหมือนนามบัตรของ agent บอกว่าตัวเองคือใคร ปลายทางอยู่ที่ URL ไหน รองรับความสามารถอะไร ต้องยืนยันตัวตนแบบไหน และมีทักษะอะไรให้เรียกใช้บ้าง เอกสารกำหนด path มาตรฐานไว้ที่ https://{agent-server-domain}/.well-known/agent-card.json ตามหลัก RFC 8615 และระบุวิธีค้นหา agent ไว้สามทาง คือดึงจาก path มาตรฐานนั้นตรงๆ ค้นจาก registry ที่มีคนคัดรวมไว้ หรือตั้งค่าปลายทางเองในระบบปิด เมื่อเชื่อมกันแล้ว งานจะเดินในรูปของ Task ซึ่งเป็นหน่วยของงานที่มีสถานะ มี id และมีวงจรชีวิตของตัวเอง โดยแลกเปลี่ยนกันเป็น Message ทีละเทิร์น และส่งผลลัพธ์กลับมาเป็น Artifact ทั้งหมดวิ่งบน HTTP(S) หน้า specification ระบุ Latest Released Version ไว้ที่ 1.0.0 ขณะที่ repository ของโครงการออก patch 1.0.1 ตามมาแล้วเมื่อ 28 พฤษภาคม 2026 ตัวสเปกนิยาม binding ไว้สามแบบคือ JSON-RPC, gRPC และ HTTP+JSON/REST เรื่องความปลอดภัย มาตรฐานเลือกพิงแนวปฏิบัติเว็บเดิมแทนที่จะคิดใหม่ คือประกาศเงื่อนไขการยืนยันตัวตนไว้ใน Agent Card แล้วบังคับให้ส่ง credential ผ่าน HTTP header มาตรฐาน แยกจากตัวข้อความ A2A

ฝั่งการกำกับดูแล Google ประกาศ A2A เมื่อ 9 เมษายน 2025 แล้วโอนให้ Linux Foundation ดูแลต่อในเดือนมิถุนายน 2025 ปัจจุบันมี Technical Steering Committee ที่มีตัวแทนจาก AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP และ ServiceNow ส่วนภาพการยอมรับในวงกว้าง แถลงข่าวของ Linux Foundation วันที่ 9 เมษายน 2026 ระบุว่ามีองค์กรสนับสนุนเกิน 150 ราย มีดาวบน GitHub เกิน 22,000 และมี SDK ระดับพร้อมใช้งานจริง 5 ภาษา พร้อมบอกว่า Microsoft ผนวก A2A เข้า Azure AI Foundry และ copilot-studio ส่วน AWS รองรับผ่าน amazon-bedrock AgentCore Runtime ในทางปฏิบัติหน้าคู่มือของ Copilot Studio อธิบายขั้นตอนไว้ตรงไปตรงมา คือใส่ endpoint URL ของ agent ปลายทาง (ย้ำว่าเป็น endpoint ไม่ใช่ URL ของ agent card) ถ้า agent นั้นมี agent card วางไว้ที่ path ที่ Copilot Studio คาดหวัง ระบบจะดึงชื่อและคำอธิบายมาเติมให้เอง โดยคู่มือของ Microsoft แนะนำไว้ในหมายเหตุว่าถ้าอยากเปิดดู agent card ในเบราว์เซอร์ ให้ลองที่ endpoint ของ agent ต่อท้ายด้วย /.well-known/agent.json ซึ่งเป็นชื่อไฟล์รุ่นเก่า คนละชื่อกับ agent-card.json ที่เอกสาร A2A ปัจจุบันกำหนด ถ้าชื่อกับคำอธิบายไม่ขึ้นมาเอง กรอกเองได้ จากนั้นเลือกวิธียืนยันตัวตนระหว่างไม่ใช้เลย ใช้ API key หรือ OAuth 2.0

ข้อควรระวังมีสามชั้น ชั้นแรกคือมาตรฐานบอกแค่ "คุยกันยังไง" ไม่ได้รับประกันว่า agent ปลายทางน่าเชื่อถือ Microsoft เขียนกำกับไว้ในคู่มือเลยว่าผู้ใช้เป็นคนรับผิดชอบตรวจสอบเองว่าการไหลของข้อมูลระหว่าง agent เหมาะสมกับ use case และกฎหมายที่เกี่ยวข้องหรือไม่ รวมถึงต้องจัดสิทธิ์ ขอบเขต การเฝ้าดู ตัวตนที่ตรวจสอบย้อนได้ และการมีคนกำกับให้ครบด้วยตัวเอง ชั้นที่สองคือตัวเลข 150 องค์กรเป็นจำนวนที่ประกาศสนับสนุนมาตรฐาน ไม่ได้แปลว่าทุกรายรันจริงบน production แล้ว ชั้นที่สามคือเรื่องเวอร์ชัน ประกาศ v1.0 ของโครงการเองระบุว่ามี breaking change ในระดับ protocol การโยกจาก v0.3 มา v1.0 จึงไม่ใช่การอัปเวอร์ชันเฉยๆ ข้อผ่อนปรนที่มีคือ AgentCard ถูกออกแบบให้ประกาศรองรับทั้ง v0.3 และ v1.0 พร้อมกันได้ เพื่อให้ทยอยย้ายทีละส่วน ใครที่กำลังวางแผนต่อ agent ข้ามระบบควรถามคู่ค้าตรงๆ ว่ารองรับเวอร์ชันไหน ก่อนจะเซ็นสัญญา

ตัวอย่างจากบทสนทนาจริง

ผู้จัดการฝ่ายปฏิบัติการ: "ตอนนี้เรามี agent ที่ทีมเราสร้างไว้บน Copilot Studio ฝั่งออฟฟิศ แล้วเวนเดอร์โลจิสติกส์เขาก็มี agent ของเขาเอง จะให้สองตัวนี้ส่งงานกันได้ต้องเขียนระบบใหม่ไหม"

IT: "ถ้าทั้งสองฝั่งรองรับ A2A ก็ไม่ต้องเขียนตัวเชื่อมใหม่ครับ ฝั่งเขาเปิด endpoint แล้ววาง agent card บอกว่าทำอะไรได้บ้าง ฝั่งเราชี้ไปที่ endpoint นั้นแล้วเลือกวิธียืนยันตัวตน จบ แต่ผมขอเช็คก่อนว่าเขาอยู่เวอร์ชันไหน เพราะ v1.0 มี breaking change จากรุ่นก่อน"

ฝ่ายจัดซื้อ: "แล้วมันต่างจาก MCP ที่ทีม dev พูดถึงเมื่อเดือนก่อนยังไง เราต้องเลือกอย่างใดอย่างหนึ่งหรือเปล่า"

IT: "ไม่ต้องเลือกครับ ใช้คู่กันได้ MCP เอาไว้ให้ agent ของเราหยิบเครื่องมือกับข้อมูล เช่นดึงยอดสต๊อกจากระบบหลังบ้าน ส่วน A2A เอาไว้ให้ agent ของเราส่งงานให้ agent ของคนอื่นทำต่อ คนละชั้นกันเลย"

ระวังสับสนกับ

• mcp : MCP เชื่อม agent เข้ากับเครื่องมือและแหล่งข้อมูล ส่วน A2A เชื่อม agent เข้ากับ agent อีกตัวที่คิดเองตัดสินใจเองได้ เอกสารทางการของ A2A ระบุว่าสองมาตรฐานนี้ออกแบบมาให้ทำงานร่วมกัน
• connector : connector คือตัวต่อกับ API หรือบริการที่พฤติกรรมตายตัว คู่มือ Copilot Studio มีตารางเทียบไว้เองว่า A2A ออกแบบมาสำหรับ agent workflow รองรับการคุยหลายเทิร์น และให้ metadata เชิงบริบทที่ละเอียดกว่า ขณะที่ HTTP connector ไม่รองรับการคุยหลายเทิร์นและให้ข้อมูลบริบทได้จำกัด
• handoff : handoff คือรูปแบบการส่งไม้ต่อของงาน ส่วน A2A คือมาตรฐานทางเทคนิคที่ทำให้การส่งไม้ข้ามระบบเกิดขึ้นได้จริง พูดง่ายๆ คืออันหนึ่งเป็นแนวคิด อีกอันเป็นท่อ
• agent-identity : A2A แตะเรื่องตัวตนแค่ระดับประกาศเงื่อนไขยืนยันตัวตนไว้ใน Agent Card และมี Signed Agent Card ซึ่งมีมาตั้งแต่ v0.3.0 โดย v1.0 มาทำให้การตรวจลายเซ็นชัดเจนขึ้นด้วยการกำหนดวิธี canonicalize ตาม RFC 8785 ส่วนการจัดการตัวตนของ agent ทั้งวงจรในองค์กรเป็นคนละเรื่อง มักต้องพึ่งระบบอย่าง entra-agent-id
• agent-swarm : agent swarm พูดถึงรูปแบบการทำงานที่มี agent หลายตัวช่วยกัน ซึ่งอาจอยู่ในระบบเดียวกันทั้งหมดก็ได้ ส่วน A2A เจาะจงที่การข้ามขอบเขตองค์กรและข้ามเฟรมเวิร์กเป็นหลัก