การเชื่อมต่อเอเจนต์ AI · 2026-10-31
โปรโตคอล A2A คืออะไร? สเปก Agent2Agent และความปลอดภัย (2026)

A2A ทำให้รูปแบบการเชื่อมต่อระหว่างเอเจนต์เป็นมาตรฐานแล้ว แต่คำถามว่า “อีกฝ่ายคือใคร ทำอะไรได้บ้าง และหากเกิดปัญหาใครรับผิดชอบ” ยังคงเป็นหน้าที่ของแต่ละบริษัทที่ต้องจัดการเอง บทความนี้ใช้สเปกต้นฉบับ งานวิจัย และเอกสารภาครัฐ สรุปสถานะ ณ วันที่ 2026-10-31

โปรโตคอล A2A คืออะไร? สเปก Agent2Agent และความปลอดภัย (2026)

A2A (Agent2Agent) คือโปรโตคอลเปิดที่ให้เอเจนต์ AI จากต่างบริษัทและต่างเฟรมเวิร์กค้นพบความสามารถของกันและกัน มอบหมายงาน และแลกเปลี่ยนผลลัพธ์ ณ วันที่ 2026-10-31 เวอร์ชันปัจจุบันคือ v1.0.1 (2026-05-26) โปรโตคอลนี้ทำให้รูปแบบการเชื่อมต่อเป็นมาตรฐาน แต่เรื่องตัวตน การอนุญาตสิทธิ์ และความรับผิดชอบเมื่อเกิดปัญหายังขึ้นอยู่กับการพัฒนาของแต่ละฝ่าย และขณะนี้ยังไม่พบกรณีใช้งานจริงที่ระบุชื่อ ข้ามบริษัท และมีการวัดผล

A2A เปิดตัวโดย Google ในเดือนเมษายน 2025 โอนให้ Linux Foundation ดูแลเมื่อ 2025-06-23 และในเดือนสิงหาคม 2026 ได้เข้าร่วม Agentic AI Foundation (AAIF) ซึ่งเป็นมูลนิธิเดียวกับ MCP ตั้งแต่ v1.0 เป็นต้นมา a2a.proto เป็นแหล่งข้อกำหนดเพียงแหล่งเดียว และรองรับการผูก (binding) สามแบบ ได้แก่ JSON-RPC 2.0, gRPC และ HTTP+JSON/REST ประเด็นเปิดของสเปกได้ย้ายจากเรื่องรูปแบบไปสู่เรื่องความไว้วางใจ ทั้งแปดหัวข้อของ v1.1 ประเด็นตัวตนของเอเจนต์ที่มีความคิดเห็นมากที่สุด (ราว 658 ความคิดเห็น) และ CVE ชุดแรกของ SDK ทางการในเดือนสิงหาคม–ตุลาคม 2026 ล้วนรวมศูนย์อยู่ที่ตัวตน การมอบหมายสิทธิ์ การอนุญาตสิทธิ์ และการแจ้งเตือนแบบพุช สิ่งที่ใช้งานจริงส่วนใหญ่คือการเชื่อมต่อภายในแพลตฟอร์มคลาวด์เดียวกัน (AWS, Microsoft, Google) สำหรับองค์กรทั่วไป รวมถึงผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ แนวทางที่ปลอดภัยกว่าในตอนนี้คือทำข้อมูลมีโครงสร้างบนหน้าเว็บและเครื่องมือ MCP แบบอ่านอย่างเดียวที่ให้ผลแน่นอน (deterministic) ให้ดีก่อน ส่วนการเขียนข้อมูล การสั่งซื้อ และการชำระเงินไม่ควรเปิดให้เอเจนต์ภายนอกจนกว่าจะมีกรอบความรับผิดชอบ

เวอร์ชันปัจจุบัน v1.0.1 TSC 9 ที่นั่ง MCP 40,675 ต่อ A2A 622 repo การ์ดที่ใช้ได้จากการทดสอบจริง 0 ใบ
ผู้เขียนชิง-หงเหวง ปรับปรุงล่าสุด ทบทวนครั้งถัดไป เอกสารอ้างอิง 65

เรียบเรียงโดยทีมวิจัย AI ของ HowBridge อ้างอิงสเปกต้นฉบับ บันทึกบน GitHub งานวิจัยทางวิชาการ และเอกสารภาครัฐ ทุกข้อเท็จจริงแนบแหล่งที่มา จุดที่แหล่งข้อมูลขัดกันระบุไว้คู่กัน และการอนุมานกับคำกล่าวอ้างของผู้ขายติดป้ายแยกไว้ บทความนี้แยกข้อความเป็นสามประเภท: สิ่งที่มีสเปกต้นฉบับ งานวิจัย หรือเอกสารทางการรองรับ เขียนเป็นข้อเท็จจริงพร้อมแหล่งที่มา สิ่งที่มาจากข่าวประชาสัมพันธ์และบล็อกของผู้ขายซึ่งตรวจสอบอย่างอิสระไม่ได้ ติดป้าย “คำกล่าวอ้างของผู้ขาย” และข้อพิจารณาที่ผู้เขียนอนุมานจากหลักฐาน ติดป้าย “การอนุมาน”

ข้อสรุปสำคัญ

  1. เวอร์ชันปัจจุบันของ A2A (Agent2Agent) คือ v1.0.1 (2026-05-26) ตั้งแต่ v1.0 ใช้ a2a.proto เป็นแหล่งข้อกำหนดเพียงแหล่งเดียว รองรับสามการผูก ได้แก่ JSON-RPC 2.0, gRPC, HTTP+JSON/REST
  2. เส้นแบ่งระหว่าง A2A กับ MCP คือใครเป็นเจ้าของลูปการให้เหตุผล: ใน MCP โมเดล LLM ฝั่งผู้เรียกควบคุมเครื่องมือ ส่วนใน A2A อีกฝ่ายคือเอเจนต์ทึบ (opaque) ที่ให้เหตุผลเอง จำนวน repo บน GitHub ของ MCP มากกว่า A2A ราว 65 เท่า (40,675 ต่อ 622)
  3. สเปก A2A มอบเรื่องการอนุญาตสิทธิ์ให้ผู้พัฒนา และลายเซ็นการ์ดเป็นทางเลือก ช่วงสิงหาคม–ตุลาคม 2026 มี CVE ชุดแรกของ SDK ทางการแล้ว โดย a2a-java เคยไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น (CVSS 7.5)
  4. ณ วันที่ 2026-10-31 ไม่พบกรณีใช้งาน A2A จริงที่ระบุชื่อ ข้ามบริษัท และมีการวัดผล สิ่งที่ใช้งานอยู่จริงคือการเชื่อมต่อภายในแพลตฟอร์มคลาวด์เดียวกัน
  5. การชำระเงินของเอเจนต์ AI แบ่งเป็นสามชั้น ได้แก่ การชำระเงินเชกเอาต์ หลักฐานการอนุญาต และการชำระเงินย่อยระหว่างเครื่อง AP2 ไม่กำหนดความรับผิดชอบกรณีข้อพิพาท และจำนวนธุรกรรม x402 ส่วนใหญ่เป็นการปั่นยอด
  6. กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ของไต้หวันมีผลบังคับใช้แล้วแต่ไม่ได้กล่าวถึงเอเจนต์ กรอบความเสี่ยงของกระทรวงกิจการดิจิทัลจัด “พฤติกรรมเกินขอบเขตการอนุญาตของเอเจนต์ AI อัตโนมัติ” เป็นความเสี่ยง B6
  7. ผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ควรทำข้อมูลมีโครงสร้างบนเว็บและเครื่องมือ MCP ที่ให้ผลแน่นอนก่อน และยังไม่ควรเปิดการสั่งซื้อและการชำระเงินให้เอเจนต์ภายนอก

โปรโตคอล A2A คืออะไร? ใครเป็นผู้ดูแล?

โปรโตคอล A2A (Agent2Agent) คือโปรโตคอลเปิดแบบเอเจนต์ต่อเอเจนต์ที่ Google เปิดตัวในเดือนเมษายน 2025 และอยู่ในความดูแลของ Linux Foundation ตั้งแต่ 2025-06-23 ณ วันที่ 2026-10-31 เวอร์ชันปัจจุบันคือ v1.0.1 (2026-05-26) มีไว้ให้เอเจนต์ AI ที่อยู่ต่างองค์กรค้นพบความสามารถของกันและกัน มอบหมายงาน และแลกเปลี่ยนผลลัพธ์

A2A อธิบายการแบ่งบทบาทระหว่างตัวเองกับ MCP อย่างเป็นทางการว่า “MCP เป็นแนวตั้ง ทำให้เอเจนต์ตัวเดียวลึกขึ้น ส่วน A2A เป็นแนวนอน เชื่อมเอเจนต์ข้ามขอบเขต” ใน A2A ฝ่ายที่ถูกเรียกคือเอเจนต์แบบ “ทึบ” (opaque) ที่ให้เหตุผลเองและเก็บสถานะเอง ฝ่ายผู้เรียกมองไม่เห็นว่าภายในใช้โมเดลหรือเครื่องมืออะไร ทั้งสองฝ่ายสื่อสารหลายรอบผ่านวงจรชีวิตของงาน (Task) เท่านั้น เอกสารทางการของไต้หวันก็กล่าวถึง A2A แล้ว โดยคู่มืออ้างอิงการใช้ปัญญาประดิษฐ์ในภาครัฐ V1.0 ของกระทรวงกิจการดิจิทัล (เอกสารระบุวันที่จัดทำ 115-01-28 ตามปฏิทินหมินกั๋ว หรือ 2026-01-28) มีหัวข้อย่อย “A2A: โปรโตคอลการสื่อสารระหว่างเอเจนต์ AI” ในหน้า 14 อธิบายว่าเน้นการสื่อสารแบบ “Client–ระยะไกล”

การกำกับดูแล A2A แบ่งเป็นสามช่วง วันที่ 2025-06-23 Linux Foundation ประกาศรับช่วง สมาชิกผู้ก่อตั้งได้แก่ AWS, Cisco, Google, Microsoft, Salesforce, SAP, ServiceNow วันที่ 2025-08-29 ACP ที่ IBM เป็นผู้นำได้รวมเข้ากับ A2A และหยุดพัฒนา อำนาจตัดสินใจจริงอยู่ที่คณะกรรมการกำกับทิศทางทางเทคนิค (TSC) 9 ที่นั่ง บริษัทละหนึ่งที่นั่ง ได้แก่ Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM, Bloomberg ข้อเสนอจะลงมติด้วย gitvote บน GitHub issue ที่ติดป้าย TSC Review เช่น #1942 ที่รวม 41 ประเด็นเป็นแปดหัวข้อของ v1.1 ผ่านมติเมื่อ 2026-06-25 ด้วยคะแนนเห็นด้วย 5 ไม่เห็นด้วย 0 (เกณฑ์ 51%)

เดือนสิงหาคม 2026 A2A เข้าร่วม Agentic AI Foundation (AAIF) ในฐานะโครงการระดับ Growth Stage อยู่มูลนิธิเดียวกับ MCP วันที่เข้าร่วมไม่ตรงกันในแต่ละแหล่ง บล็อกของ AAIF และ Axios ระบุ 2026-08-17 บล็อกทางการและหน้าสเปกของ A2A ระบุ 2026-08-27 ส่วนรายงานของ Forbes ลงวันที่ 08-19 ความเป็นไปได้หนึ่งคือ 08-17 เป็นวันที่มูลนิธิประกาศต่อสาธารณะ และ 08-27 เป็นวันที่ฝั่งโครงการโพสต์ แต่ไม่มีแหล่งใดยืนยันคำอธิบายนี้ บทความนี้จึงระบุทั้งสองวันคู่กันและไม่เลือกแทนผู้อ่าน Diginomica นับ A2A เป็นโครงการลำดับที่ 5 ที่ AAIF ดูแล โดยสี่โครงการก่อนหน้าคือ MCP, goose, AGENTS.md, agentgateway และมีแหล่งข้อมูลทุติยภูมิที่เน้นว่านี่เป็นเพียงการปรับระดับองค์กร สเปกทั้งสองไม่ได้ถูกรวมกัน

เอกสารการกำกับดูแลของ A2A ระบุว่า “กำหนดองค์ประกอบในระยะเสถียรหลังจัดตั้งครบ 18 เดือน” นับจากเดือนมิถุนายน 2025 จะครบกำหนดราวเดือนธันวาคม 2026 ขณะที่ประกาศของ AAIF ไม่ได้บอกว่าจะปรับโครงสร้าง TSC หรือไม่ — นี่เป็นการอนุมาน หมายความว่าองค์ประกอบของ TSC อาจเปลี่ยนในเร็ว ๆ นี้และควรติดตาม

ศัพท์หลักหกคำของ A2A (สรุปตามสเปก v1.0)
คำศัพท์คืออะไรสิ่งที่ต้องระวังใน v1.0
Agent Card“นามบัตร” สาธารณะของเอเจนต์ ประกาศทักษะ อินเทอร์เฟซ และวิธียืนยันตัวตน ตามธรรมเนียมวางไว้ที่ /.well-known/agent-card.jsonเปลี่ยนมาใช้ supportedInterfaces[] เป็นแกนหลัก ลายเซ็นการ์ดเป็นทางเลือก
Taskหน่วยงานของการทำงานร่วมกันหนึ่งครั้ง มีเครื่องสถานะ (state machine) ของตัวเองtaskId สร้างโดยเซิร์ฟเวอร์เสมอ งานที่เข้าสู่สถานะสิ้นสุดแล้วเริ่มใหม่ไม่ได้
Messageข้อความหนึ่งข้อความที่สองฝ่ายส่งถึงกันเอเจนต์อาจตอบกลับเพียง Message โดยไม่สร้าง Task ฝั่งไคลเอนต์ต้องรองรับได้ทั้งสองแบบ
Partส่วนของเนื้อหาในข้อความหรือผลงานถูกทำให้แบนเป็นหนึ่งในสี่: text, raw, url, data และตัดฟิลด์แยกประเภท kind ออก
Artifactผลงานที่ได้จากงานส่งแบบสตรีมตามความคืบหน้าของงานได้
Extensionเพิ่มฟังก์ชันนอกเหนือแกนหลัก (เช่น การชำระเงิน)ระบุด้วย URI ห้ามแก้โครงสร้างข้อมูลแกนหลักหรือเพิ่มค่า enum

คลังคำตอบ AI ด้านฝากส่งและพิธีการศุลกากร: ถาม-ตอบเพิ่มเติมเรื่อง AI และโลจิสติกส์ข้ามพรมแดน

แหล่งอ้างอิง A2A Specification| A2A and MCP (คำอธิบายทางการของ A2A)| Linux Foundation: ข่าวประชาสัมพันธ์การก่อตั้งโครงการ A2A (2025-06-23)| LF AI & Data: ACP รวมเข้ากับ A2A| A2A GOVERNANCE.md| A2A Issue #1942 (การลงมติหัวข้อ v1.1)| AAIF: A2A joins AAIF| Axios (2026-08-17)| ประกาศทางการของ A2A (เข้าร่วม AAIF วันที่ 2026-08-27)| Forbes (2026-08-19)| Diginomica| กระทรวงกิจการดิจิทัลไต้หวัน: คู่มืออ้างอิงการใช้ปัญญาประดิษฐ์ในภาครัฐ V1.0

A2A v1.0 เปลี่ยนอะไรบ้าง? งาน สตรีม และการแจ้งเตือนแบบพุชทำงานอย่างไร?

A2A v1.0.0 (CHANGELOG ระบุเผยแพร่ 2026-03-12) ใช้ a2a.proto เป็นแหล่งข้อกำหนดเพียงแหล่งเดียว สร้างสามการผูก JSON-RPC 2.0, gRPC, HTTP+JSON/REST จาก proto ชุดเดียวกัน พร้อมเปลี่ยนชื่อเมธอดทั้งหมดและทำให้โครงสร้างข้อมูล Part แบนลง ส่วน v1.0.1 เมื่อ 2026-05-26 เป็นรุ่นแก้ไขที่เข้ากันได้ในระดับสาย (wire-compatible) กับ 1.0.0

เมธอดทั้งหมดของ A2A v1.0 ถูกเปลี่ยนชื่อ: message/send เป็น SendMessage, message/stream เป็น SendStreamingMessage, tasks/resubscribe เป็น SubscribeToTask และเพิ่ม ListTasks เส้นทาง REST เปลี่ยนเป็นสไตล์ AIP เช่น POST /tasks/{id}:cancel และตัดคำนำหน้า /v1 ออก รูปแบบข้อผิดพลาด HTTP เปลี่ยนจาก application/problem+json ของ RFC 9457 เป็น google.rpc.Status โดย reason เขียนด้วยตัวพิมพ์ใหญ่คั่นขีดล่าง (เช่น TASK_NOT_FOUND) และ domain กำหนดตายตัวเป็น "a2a-protocol.org" บันทึกการวิจัยมองว่าการปรับครั้งนี้เท่ากับปรับ A2A ให้เป็นสไตล์แนวทางการออกแบบ API ของ Google ซึ่งเป็นการอนุมาน

การเปลี่ยนแปลงที่ทำลายความเข้ากันได้มากที่สุดของโมเดลข้อมูลคือการทำ Part ให้แบน TextPart, FilePart, DataPart และฟิลด์แยกประเภท kind เดิมถูกตัดออกทั้งหมด เปลี่ยนเป็น Part เดียวที่มีเพียงหนึ่งใน text, raw (bytes), url, data วิธีแยกแยะเปลี่ยนจากอ่าน kind เป็นดูว่ามีฟิลด์ใดอยู่ mimeType เปลี่ยนชื่อเป็น mediaType และ file.fileWithUri เปลี่ยนเป็น url ชุมชนรายงานว่าตัวแยกวิเคราะห์จำนวนมากยังอ่าน part.kind อยู่ ซึ่งเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ 0.3 กับ 1.0 ทำงานร่วมกันไม่ได้ ส่วน Agent Card เปลี่ยนมาใช้ supportedInterfaces[] เป็นแกนหลัก แต่ละอินเทอร์เฟซมี url, protocolBinding, protocolVersion และ tenant ที่เป็นทางเลือก ไคลเอนต์เลือกตามลำดับในอาร์เรย์และ SHOULD ทำ fallback

การต่อรองเวอร์ชันมีค่าเริ่มต้นหนึ่งที่คนไม่ค่อยสังเกต: ถ้าส่วนหัว A2A-Version ว่าง จะถือเป็น 0.3 ไคลเอนต์ส่งเพียง Major.Minor หากเซิร์ฟเวอร์ไม่รองรับจะตอบ −32009 VersionNotSupportedError เอเจนต์ตัวเดียวกันสามารถระบุอินเทอร์เฟซที่มี protocolVersion ต่างกันใน supportedInterfaces เพื่อให้ 0.3 และ 1.0 อยู่ร่วมกันได้ การย้ายระบบอย่างเป็นทางการแบ่งเป็นสามขั้น: เริ่มจากแยกวิเคราะห์ได้ทั้งสองรูปแบบ จากนั้นส่งออกเป็น 1.0 แต่อ่าน 0.3 และสุดท้ายเหลือเพียง 1.0 ทั้ง Atlassian Forge และ MuleSoft ได้เผยแพร่คู่มือย้ายระบบ 0.3→1.0 แล้ว แสดงว่าการเปลี่ยนแปลงที่ทำลายความเข้ากันได้มีคนกำลังจ่ายต้นทุนจริง

ความหมายของงานมีรายละเอียดหลายจุดที่ต้องอ่านสเปกจนจบจึงจะพบ taskId สร้างโดยเซิร์ฟเวอร์เสมอ หาก contextId มาจากไคลเอนต์ เอเจนต์ทำได้เพียงยอมรับหรือปฏิเสธ จะสร้างใหม่เองไม่ได้ และเมื่อ taskId กับ contextId ไม่สอดคล้องกัน เอเจนต์ MUST ปฏิเสธ หากส่งข้อความไปยังงานที่อยู่ในสถานะสิ้นสุดสี่แบบ คือ COMPLETED, FAILED, CANCELED, REJECTED จะได้ UnsupportedOperationError ถ้าต้องการทำต่อให้เปิดงานใหม่ใน context เดียวกัน แล้วใช้ referenceTaskIds เชื่อมกลับไปยังงานเดิม เครื่องสถานะมีสถานะ “หยุดชั่วคราว” สองแบบ คือ TASK_STATE_INPUT_REQUIRED และ TASK_STATE_AUTH_REQUIRED โดย SendMessage แบบบล็อกจะคืนค่าเมื่อพบสถานะหยุดชั่วคราวเช่นกัน

การรับประกันของสตรีมและการแจ้งเตือนแบบพุชอ่อนกว่าที่หลายคนคิด แฟล็ก final ของ TaskStatusUpdateEvent ถูกตัดออกใน 1.0 และใช้ “การปิดการเชื่อมต่อ” แทนเพื่อบอกว่าสตรีมสิ้นสุด ดังนั้นในมุมของไคลเอนต์ งานที่หลุดการเชื่อมต่อกลางคันกับงานที่เสร็จแล้วดูเหมือนกัน ต้องเรียก GetTask หรือ SubscribeToTask อีกครั้งจึงจะแยกออก สเปกยังไม่มีกลไกต่อสตรีมด้วย ID ของเหตุการณ์ ซึ่งถูกจัดเป็นหัวข้อ #1986 ของ v1.1 แล้ว การแจ้งเตือนแบบพุชคือการส่ง StreamResponse ด้วย HTTP POST ไปยัง webhook ของไคลเอนต์ โดย Content-Type เป็น application/a2a+json สเปกกำหนดเพียงให้เอเจนต์พยายามส่งอย่างน้อยหนึ่งครั้ง หมดเวลา SHOULD ราว 10–30 วินาที ฝั่งรับ SHOULD ประมวลผลแบบ idempotent และ MUST ตรวจ taskId กล่าวอีกอย่างคือ การแจ้งเตือนแบบพุชเป็น “อย่างน้อยหนึ่งครั้ง ไม่รับประกันลำดับ และ payload ไม่มีลายเซ็น” ซึ่งเป็นผลการอนุมานจากสเปก ความเป็น idempotent ก็ทำไว้เพียงครึ่งเดียว: SendMessage “อาจ” ใช้ messageId ตัดรายการซ้ำได้ แต่ไม่บังคับ

มีสองจุดที่แหล่งข้อมูลขัดกันเรื่องวันที่และจำนวน วันเผยแพร่ v1.0: CHANGELOG ระบุ 2026-03-12 บทความทบทวนวรรณกรรมหนึ่ง (arXiv:2507.10644 v4) ระบุมกราคม 2026 ส่วนข่าวประชาสัมพันธ์ครบรอบหนึ่งปีของ Linux Foundation บอกเพียงว่า v1.0 เป็นรุ่นเสถียรแรกโดยไม่ระบุวันที่ บทความนี้ใช้ CHANGELOG ซึ่งเป็นแหล่งข้อมูลปฐมภูมิ จำนวน SDK: Linux Foundation ในเดือน 2026-04 ระบุว่ามี 5 ภาษาที่ “production-ready” ขณะที่ประกาศทางการของ A2A ระบุ 6 ภาษา ได้แก่ Python, Go, Java, JS, .NET, Rust แต่ SDK ภาษา Rust ที่ถูกทดสอบอย่างละเอียดเป็นรุ่นของชุมชน

พัฒนาการด้านเวอร์ชันและการกำกับดูแลของ A2A (2025-04 ถึง 2026-10)
วันที่เวอร์ชันหรือเหตุการณ์สาระสำคัญระดับหลักฐาน
2025-04Google เปิดตัว A2Aพันธมิตรกว่า 50 รายแหล่งข้อมูลทุติยภูมิ
2025-05-270.2.1เพิ่ม referenceTaskIds และค่าบูลีนของ extended cardปฐมภูมิ (CHANGELOG)
2025-06-090.2.2ปรับให้ตรงกับ JSON-RPC แบบทำลายความเข้ากันได้; นิยาม gRPC/REST; extensionsปฐมภูมิ (CHANGELOG)
2025-06-23Linux Foundation รับช่วงสมาชิกผู้ก่อตั้ง 7 รายปฐมภูมิ (ข่าวประชาสัมพันธ์ LF)
2025-06-300.2.5Agent Card ต้องมี protocolVersion; แต่ละงานมีการตั้งค่าการแจ้งเตือนแบบพุชได้หลายชุดปฐมภูมิ (CHANGELOG)
2025-07-300.3.0agent.json เปลี่ยนชื่อเป็น agent-card.json (ทำลายความเข้ากันได้); ลายเซ็นการ์ด; mTLS; ความปลอดภัยระดับทักษะปฐมภูมิ (CHANGELOG)
2025-08-29IBM ACP รวมเข้ากับ A2AACP หยุดพัฒนาปฐมภูมิ (LF AI & Data)
2026-03-121.0.0proto เป็นข้อกำหนด, Part แบน, เปลี่ยนชื่อเมธอด, การต่อรองเวอร์ชัน, หลายผู้เช่า (multi-tenant), ListTasksปฐมภูมิ (CHANGELOG); มีงานวิจัยอีกชิ้นระบุมกราคม 2026
2026-05-261.0.1รุ่นแก้ไขที่เข้ากันได้ในระดับสายกับ 1.0.0; แนะนำชนิดสื่อ application/a2a+jsonปฐมภูมิ (CHANGELOG)
2026-08-17 หรือ 08-27เข้าร่วม AAIFมูลนิธิเดียวกับ MCPแหล่งข้อมูลระบุวันที่ขัดกัน
2026-10-01เปิดตัว a2a CLI ทางการเครื่องมือบรรทัดคำสั่งปฐมภูมิ (ประกาศ A2A)

แหล่งอ้างอิง A2A Specification| What's new in A2A v1| A2A CHANGELOG| ประกาศทางการของ A2A| DEV Community: A2A tech update (2026-03-20)| Atlassian Forge: การย้าย A2A 0.3→1.0| MuleSoft: การอัปเกรดและย้าย A2A Connector| Petrova et al., Web of Agents (arXiv:2507.10644 v4)| Linux Foundation: ข่าวประชาสัมพันธ์ครบรอบหนึ่งปีของ A2A| philippdubach: MCP vs A2A in 2026 (ภูมิหลังการเปิดตัว 2025-04)

A2A กับ MCP ต่างกันอย่างไร? ควรใช้ตัวไหน?

เส้นแบ่งที่แท้จริงระหว่าง A2A กับ MCP คือใครเป็นเจ้าของลูปการให้เหตุผล: ใน MCP โมเดล LLM ฝั่งผู้เรียกเป็นผู้ควบคุม อีกฝ่ายเพียงเปิดเครื่องมือที่ schema โปร่งใส ส่วนใน A2A อีกฝ่ายคือเอเจนต์ทึบที่ให้เหตุผลเองและเก็บสถานะเอง ขนาดการใช้งานของทั้งสองต่างกันหนึ่งถึงสองลำดับขนาด โดย repo บน GitHub ที่ติด topic mcp-server มี 40,675 แห่ง และที่ติด a2a-protocol มี 622 แห่ง

ปีที่ผ่านมามักได้ยินว่า “MCP เพิ่ม Tasks แล้ว A2A จึงไม่จำเป็น” แต่ทิศทางจริงของ MCP ฉบับ 2026-07-28 กลับตรงกันข้าม MCP ฉบับ 2025-11-25 เพิ่ม Tasks แบบทดลอง (SEP-1686) จริง เพื่อใช้ติดตามคำขอที่ใช้เวลานาน การโพล และการดึงผลลัพธ์ภายหลัง สถานะของมัน (working, input_required, completed, failed, cancelled) แทบจะตรงกับ A2A แบบหนึ่งต่อหนึ่ง แต่ฉบับ 2026-07-28 ได้ตัด session และการจับมือ initialize ออก ทำให้ MCP เป็นแบบไร้สถานะ (SEP-2567, SEP-2575) ย้าย Tasks ออกจากแกนหลักไปเป็นส่วนขยายทางการ io.modelcontextprotocol/tasks (SEP-2663) ใช้ MRTR (InputRequiredResult คู่กับ inputResponses ที่แนบมาตอนส่งซ้ำ) แทนคำขอที่เซิร์ฟเวอร์เป็นผู้เริ่ม (SEP-2322) และจัด Sampling, Roots, Logging เป็น deprecated (SEP-2577)

ความหมายของการเปลี่ยนแปลงเหล่านี้คือ ผู้ดูแล MCP ตั้งใจละทิ้งเส้นทาง “ทำให้เป็นเอเจนต์” ที่เซิร์ฟเวอร์ย้อนกลับมายืม LLM ของผู้เรียกไปให้เหตุผล ซึ่งเป็นการอนุมาน หากเซิร์ฟเวอร์ MCP ต้องการให้เหตุผลเองก็ต้องมีโมเดลของตัวเอง เมื่อนั้นมันก็คือเอเจนต์ทึบที่ภายนอกยังดูเป็นเครื่องมือ Task ของ MCP จัดการ “การดึงผลภายหลังของการเรียกเครื่องมือที่ใช้เวลานานหนึ่งครั้ง” ส่วน Task ของ A2A จัดการ “การทำงานร่วมกันหลายรอบที่ทั้งสองฝ่ายอาจถามคำถาม” อีกทั้งยังมีการค้นพบผ่าน Agent Card การประกาศทักษะ และการสตรีม artifact ในทางกลับกันก็มีสถานการณ์ที่ล้มเหลว: การสอบถามที่ให้ผลแน่นอนอย่างการเช็กราคาหรืออัตราภาษี หากฝืนใช้วงจรชีวิต Task, Message, Artifact จะเพิ่มทั้งความหน่วงและต้นทุนการพัฒนา และ LLM ฝั่งผู้เรียกก็จะไม่ได้ schema ของเครื่องมือแบบละเอียด ซึ่งก็เป็นการอนุมานเช่นกัน บันทึกการวิจัยไม่พบบันทึกเหตุการณ์จริงที่ “ใช้ MCP ทำงานแบบเอเจนต์ต่อเอเจนต์แล้วล้มเหลว” หรือ “ใช้ A2A ห่อเครื่องมือแล้วล้มเหลว”

ด้านการใช้งาน นอกจากจำนวน topic บน GitHub แล้ว การเปรียบเทียบ PyPI แบบไม่เป็นระบบชิ้นหนึ่งพบว่า SDK ของ A2A มียอดดาวน์โหลดราว 10.9 ล้านครั้ง ส่วน SDK ของ MCP ราว 257 ล้านครั้ง แหล่งข้อมูลทุติยภูมิระบุว่าเอนด์พอยต์ UCP ของ Shopify ใช้ MCP เป็นชั้นขนส่ง กล่าวคือเอเจนต์การค้าหลักที่เชื่อมเข้ามาใช้ MCP ด้านแพลตฟอร์มคลาวด์: AWS AgentCore Runtime สามารถดีพลอยเซิร์ฟเวอร์ A2A ได้ (JSON-RPC, POST /, port 9000, OAuth 2.0 หรือ SigV4) การรองรับ A2A ของ Microsoft Foundry เข้าสู่ public preview ในเดือนมิถุนายน 2026 ส่วน Google Agent Registry อ่านการ์ด well-known ได้ แต่การค้นพบอัตโนมัติจำกัดอยู่ในโปรเจกต์เดียวกันเท่านั้น ในบรรดาผู้พัฒนาโมเดลรายใหญ่ที่บันทึกการวิจัยตรวจสอบ Anthropic ยังไม่รองรับ A2A โดยกำเนิด และ issue #104852 ที่เกี่ยวกับ Claude Code เพิ่งเปิดเมื่อปลายเดือนตุลาคม 2026

วิธีเลือกในทางปฏิบัติง่ายมาก: หากต้องการให้ผู้ช่วย AI เรียกฟังก์ชันที่ให้ผลแน่นอนของคุณ (เสนอราคา เช็กอัตราภาษี ติดตามสถานะพัสดุ) ให้ใช้ MCP หากต้องการให้เอเจนต์สองตัวที่ให้เหตุผลได้เองและอยู่ต่างองค์กรทำงานร่วมกันหลายรอบ จึงจำเป็นต้องใช้ A2A MCP สาธารณะของ HowBridge อยู่ในกลุ่มแรก วิธีเชื่อมต่อดูได้จากบทสอน MCP สำหรับบริการฝากส่งรวมพัสดุในเว็บไซต์

แผนภาพเปรียบเทียบ A2A กับ MCP: ด้านซ้ายคือเอเจนต์หนึ่งตัวที่เรียกเครื่องมือ เช่น ฐานข้อมูล เครื่องคิดเลข เอกสาร และการค้นหา ผ่าน MCP ด้านขวาคือเอเจนต์ของสององค์กร ได้แก่ บ้านพักอาศัยและคลังสินค้าโลจิสติกส์ ที่แลกเปลี่ยนงานกันผ่าน A2A ข้ามขอบเขตองค์กร
ภาพประกอบที่สร้างด้วย AI: MCP คือการเชื่อมต่อแนวตั้งแบบ “เอเจนต์ต่อเครื่องมือ” ส่วน A2A คือการทำงานร่วมกันแนวนอนแบบ “เอเจนต์ต่อเอเจนต์” ที่ข้ามขอบเขตองค์กร
เปรียบเทียบ A2A กับ MCP (ณ วันที่ 2026-10-31)
หัวข้อเปรียบเทียบMCPA2A
สิ่งที่เชื่อมต่อเอเจนต์กับเครื่องมือและทรัพยากรเอเจนต์กับเอเจนต์
ใครควบคุมลูปการให้เหตุผลLLM ฝั่งผู้เรียกเอเจนต์ระยะไกลเอง
ความโปร่งใสของอีกฝ่ายschema ของเครื่องมือโปร่งใสทึบ เห็นเพียงสิ่งที่ประกาศใน Agent Card
สถานะฉบับ 2026-07-28 เปลี่ยนเป็นไร้สถานะ ย้าย Tasks เป็นส่วนขยายทางการวงจรชีวิต Task แบบมีสถานะ รองรับหลายรอบ
กลไกการค้นพบMCP Registry (ยังเป็นพรีวิวตั้งแต่ 2025-09 จนถึงปัจจุบัน)/.well-known/agent-card.json; ไม่มีศูนย์ลงทะเบียนทางการ
สถานการณ์ที่เหมาะการสอบถามที่ให้ผลแน่นอน เช่น เช็กราคา เช็กอัตราภาษีการทำงานร่วมกันข้ามองค์กร หลายรอบ และต้องอาศัยการตัดสินใจของอีกฝ่าย
จำนวน repo บน GitHub40,675 (topic mcp-server)622 (topic a2a-protocol)
มูลนิธิAAIFLinux Foundation ตั้งแต่ 2025-06; เข้าร่วม AAIF ตั้งแต่ 2026-08

บทสอน MCP สำหรับฝากส่งรวมพัสดุ: เชื่อมต่อ HowBridge ในไดเรกทอรีของ Claude ・ แพลตฟอร์มนักพัฒนา HowBridge: คำอธิบาย MCP สาธารณะและ MCP สำหรับสมาชิก

แหล่งอ้างอิง A2A and MCP (คำอธิบายทางการของ A2A)| MCP 2025-11-25 changelog| MCP 2026-07-28 changelog| WorkOS: MCP 2025-11-25 spec update| gravity.fast: MCP adoption statistics| การอภิปรายที่เกี่ยวข้องบน Hacker News (เปรียบเทียบยอดดาวน์โหลด PyPI)| Presta: คู่มือ UCP และเอเจนต์ช้อปปิ้ง AI| AWS: AgentCore Runtime A2A protocol contract| Microsoft 365 Message Center AZ563716| Google Cloud: Agent Registry automatic registration| anthropics/claude-code Issue #104852

A2A ปลอดภัยไหม? มีช่องโหว่และ CVE ที่ทราบแล้วอะไรบ้าง?

สเปก A2A กำหนดเพียงว่าข้อมูลรับรอง “ประกาศอย่างไร ส่งอย่างไร” ส่วนการอนุญาตสิทธิ์มอบให้ผู้พัฒนาแต่ละราย และลายเซ็น Agent Card ก็เป็นทางเลือก ช่วงสิงหาคม–ตุลาคม 2026 มี CVE ชุดแรกของ SDK ทางการแล้ว ในจำนวนนี้ CVE-2026-111764 ของ a2a-java ถูกจัดระดับ High (CVSS 7.5) เพราะไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น

Agent Card ของ A2A ใช้ securitySchemes ประกาศหนึ่งในห้าวิธียืนยันตัวตน ได้แก่ API Key, HTTP Auth, OAuth2, OIDC, mTLS v1.0 ตัด implicit flow และ password flow ของ OAuth ออก เพิ่ม Device Code และแนะนำให้ไคลเอนต์ทุกตัวใช้ PKCE สเปกกำหนดให้เซิร์ฟเวอร์ “MUST authenticate every incoming request” แต่การอนุญาตสิทธิ์เป็นแบบ implementation-specific และการได้มาซึ่งข้อมูลรับรองต้องผ่านช่องทางนอกแบนด์ (out-of-band) เมื่องานเข้าสู่สถานะ AUTH_REQUIRED สเปกเขียนไว้ชัดว่า “Agents MUST NOT treat the state transition alone as authorization” หมวด 13 “ข้อพิจารณาด้านความปลอดภัย” ไม่ได้กล่าวถึง prompt injection การมอบหมายสิทธิ์หรือ token exchange หรือ OpenTelemetry เลย และไม่มีข้อกำหนดเฉพาะเรื่องการแยกผู้เช่า (tenant) บทวิจารณ์ของ Semgrep ในยุค v0.3 ระบุว่า A2A “supports but does not enforce Agent Card signing” อายุและ scope ของโทเค็นไม่ได้ถูกโปรโตคอลจำกัด และงานเดียวกันมีสตรีมคู่ขนานได้หลายสาย session token ที่ถูกขโมยจึงแอบดักฟังสตรีมของเหยื่อได้อย่างเงียบ ๆ

แม้จะลงนาม Agent Card แล้ว ปัจจุบันก็ยังไม่รับประกันว่าจะตรวจสอบข้าม SDK ได้ วิธีของสเปกคือทำการ์ดให้เป็นรูปแบบมาตรฐานตาม RFC 8785 (JCS) ก่อน (ไม่รวมฟิลด์ signatures) แล้วจึงทำ JWS โดย protected header MUST มี alg และ kid Issue #2122 (เปิดเมื่อ 2026-08-10 และ ณ วันที่ 2026-10-31 ยังไม่ปิด) บันทึกความแตกต่างจากการทดสอบจริง: a2a-python 1.1.2 กับ @a2a-js/sdk 1.0.1 ให้ไบต์หลังทำมาตรฐานไม่ตรงกัน Python escape อักขระที่ไม่ใช่ ASCII เป็น \uXXXX เรียงตาม code point แทนหน่วย UTF-16 และพิมพ์ตัวเลขเป็น 1e-06 ขณะที่ ECMAScript พิมพ์ 0.000001 สเปกกำหนดให้ฟิลด์ REQUIRED ต้องปรากฏแม้เป็นค่าเริ่มต้น แต่ proto3 ไม่มีแนวคิด presence ทำให้ description: "" และ skills: [] ถูกทิ้งไป และ typ ก็มีความกำกวม PR #2319 แก้ตัวอย่างในสเปกแล้ว แต่ผลลัพธ์ของ a2a-go ยังต่างอยู่ ข้อจำกัดอีกประการคือ ลายเซ็นที่ตรวจผ่านพิสูจน์ได้เพียงว่าการ์ดไม่ถูกแก้ไข ไม่ได้พิสูจน์ตัวตนของผู้ออกการ์ด ชุมชนยังชี้ว่าข้อกำหนดไม่มีกลไกใดผูกการ์ดเข้ากับสภาพแวดล้อมการทำงานที่ส่งคำขอจริง

มีการโจมตีบางแบบที่ทำได้แม้ปฏิบัติตามสเปกทุกประการ A2ABreak (arXiv:2609.10871, v3 2026-10-24) ใช้ LLM สกัดจากสเปกภาษาธรรมชาติได้ 37 สถานะ 76 การเปลี่ยนสถานะ และ 929 ข้อความเชิงรูปนัย พบช่องโหว่ใหม่ 11 รายการ ซึ่งทั้งหมด “ไม่ต้องอาศัยข้อบกพร่องในการพัฒนาใด ๆ ผู้ไม่หวังดีที่ปฏิบัติตามข้อกำหนดก็ใช้ประโยชน์ได้” เช่น context identifier ที่ไม่มีการป้องกันทำให้เกิดการฉีด context ข้ามไคลเอนต์ ตัวตนสูญหายหลังห่วงโซ่การมอบหมายหลายทอด และเอเจนต์อ้างความสามารถที่ไม่ได้รับการพิสูจน์ งานวิจัยเรื่องชื่อซ้ำ (arXiv:2609.27624) ระบุว่าข้อกำหนดวางตำแหน่ง name เป็น “human-readable metadata, not as a stable identity” และไม่ได้นิยามกฎเมื่อชื่อชนกัน ใน 7 การพัฒนาแบบโอเพนซอร์สที่ผู้เขียนติดตาม มี 6 การผสานรวมฝั่งไคลเอนต์ที่จะส่งคำขอไปยังเอนด์พอยต์ที่ผู้โจมตีควบคุม ผู้เขียนจัดสิ่งนี้เป็นกลุ่มช่องโหว่ในการพัฒนาที่เกิดซ้ำ ไม่ใช่ช่องโหว่ทั่วไปของโปรโตคอล Unit 42 ของ Palo Alto Networks ทำ proof of concept เรื่อง session smuggling ด้วย Google ADK แสดงให้เห็นว่าเอเจนต์ประสงค์ร้ายใช้ “คำถามเพื่อขอความชัดเจน” ล้วงคำสั่งระบบ และหลอกให้ไคลเอนต์เรียก buy_stock ซื้อหุ้น 10 หุ้นโดยไม่ได้รับอนุญาต Unit 42 ระบุชัดว่านี่ไม่ใช่ช่องโหว่ของโปรโตคอล โปรโตคอลหลายรอบแบบมีสถานะใด ๆ ก็อาจได้รับผลกระทบ และยังไม่พบการโจมตีจริง ชุมชนยังรายงานว่าเซิร์ฟเวอร์ประสงค์ร้ายสามารถซ่อนคำสั่งไว้ในฟิลด์ description หรือ skills ของ Agent Card จน LLM ฝั่งโฮสต์นำไปปฏิบัติเหมือนเป็นคำสั่ง

หลักฐานเชิงประจักษ์ทางวิชาการเรื่องการโจมตีข้ามเอเจนต์ก็สนับสนุนว่า “ความไว้วางใจระหว่างเอเจนต์ไม่อาจตั้งเป็นค่าเริ่มต้น” Triedman และคณะ (COLM 2025) พบว่าเนื้อหาเว็บที่เป็นอันตรายสามารถยึดการควบคุมลำดับการทำงานของระบบหลายเอเจนต์ได้ โดยในกรณีของ GPT-4o การรันโค้ดตามอำเภอใจสำเร็จใน 58%–90% ของการทดลอง บทความทบทวนที่ผ่านการพิจารณาโดยผู้ทรงคุณวุฒิของ Ferrag และคณะใน ICT Express (2026) ไล่เรียงตั้งแต่ prompt injection ไปจนถึงการโจมตีระดับโปรโตคอล ครอบคลุมทั้ง MCP และ A2A

หมายเลข CVE ในตารางด้านล่างคัดลอกตามบันทึกการวิจัยทุกตัวอักษร บันทึกการวิจัยเองระบุว่าตัวเลขเหล่านี้ผิดปกติ และบางรายการพบในฐานข้อมูลเดียวเท่านั้น (เช่น CVE-2026-90790 ไม่มี GHSA ที่ตรงกันใน repo a2a-python พบเพียงใน OpenCVE) ผลการค้น repo advisories ของ a2a-js, a2a-go, a2a-dotnet ว่างเปล่า แต่อาจเป็นเพราะสิทธิ์ไม่พอ ไม่ได้แปลว่าไม่มีช่องโหว่แน่นอน จากตารางนี้สรุปบทเรียนได้สามข้อ ซึ่งต่อไปนี้เป็นการอนุมาน: หนึ่ง Agent Card เป็นอินพุตที่ผู้โจมตีควบคุมได้ แม้แต่ชื่อส่วนหัวก็อาจถูกอีกฝ่ายกำหนด สอง ข้อกำหนดเขียนเพียงว่า “SHOULD ตรวจสอบ webhook URL” ส่งผลให้ SDK สองภาษาเกิด SSRF สาม ข้อกำหนดบอกว่า “การอนุญาตสิทธิ์ขึ้นกับการพัฒนา” SDK ภาษา Java ที่นิยมที่สุดจึงไม่ทำการอนุญาตสิทธิ์เป็นค่าเริ่มต้น และแพตช์ยังถูกเลี่ยงได้เพราะความต่างของแพลตฟอร์ม Android

ช่องโหว่ที่เปิดเผยแล้วของ SDK และการพัฒนาที่เกี่ยวกับ A2A (2025–2026 หมายเลขตามบันทึกการวิจัย)
หมายเลขคอมโพเนนต์ปัญหาความรุนแรง
GHSA-qw47-mcm5-934w / CVE-2026-111764a2a-java server-common < 1.3.0.Finalคอนสตรักเตอร์แบบไม่มีพารามิเตอร์ของ InMemoryTaskStore ตั้ง authorizationProvider เป็น null ทำให้ไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น (fail-open)High, CVSS 7.5
GHSA-9rhm-2h4x-jwmx / CVE-2026-111763a2a-java < 1.3.0.FinalAgentCard ประสงค์ร้ายใช้ APIKeySecurityScheme ระบุชื่อส่วนหัวเอง แล้วตอบ redirect ทำให้ API key ถูกส่งต่อให้บุคคลที่สามMedium
GHSA-4fpj-g9jf-9rgg / CVE-2026-111765a2a-java (Android)POST แบบซิงโครนัสบน Android เลี่ยงแพตช์ redirect ของรายการก่อนหน้าHigh
GHSA-q78c-5jjq-57g8 / CVE-2026-111761a2a-javaSSRF ผ่านการแจ้งเตือนแบบพุชMedium
GHSA-x32g-jvvm-4725 / CVE-2026-111762a2a-javaเมื่อแยกวิเคราะห์ protobuf ล้มเหลว ข้อมูลรับรองของการแจ้งเตือนแบบพุชถูกเขียนลง log เป็นข้อความธรรมดาMedium
CVE-2026-90790a2a-python ≤ 1.1.3SSRF ใน _dispatch_notification ผ่าน push_info.url แก้ไขใน 1.1.4; repo ไม่มี GHSA ที่ตรงกัน พบเพียงใน OpenCVECVSS 6.3
CVE-2026-115419 / GHSA-4v6f-7vjh-6x4mเซิร์ฟเวอร์ A2A ของ Strands Agentsผู้เรียกที่มี context_id ต่างกันใช้ประวัติการสนทนาร่วมกัน; ไม่มี workaround ที่สมบูรณ์ แนะนำหนึ่งอินสแตนซ์ต่อหนึ่งผู้เช่าHigh, CVSS 8.1
CVE-2025-6167python-a2a ที่ไม่เป็นทางการ ≤ 0.5.5Path traversal (เป็นแพ็กเกจคนละตัวกับ a2a-sdk ทางการ)ไม่ระบุ

แหล่งอ้างอิง A2A Specification (§4.5, §7, §8.4, §13)| Semgrep: A security engineer's guide to the A2A protocol| A2A Issue #2122 (ความต่างในการทำลายเซ็นให้เป็นมาตรฐาน)| A2A Discussion #1677| levelup: Signed Agent Cards prove integrity, not identity| Lotfi et al., A2ABreak (arXiv:2609.10871)| Arun Kumar, Agent Name Collision Attacks (arXiv:2609.27624)| Unit 42: Agent session smuggling| langgraph-a2a-client Issue #8 (รายงานการฉีดผ่านฟิลด์ของการ์ด)| Triedman et al., Multi-Agent Systems Execute Arbitrary Malicious Code (COLM 2025)| Ferrag et al., ICT Express 12 (2026)| GitHub Advisory GHSA-qw47-mcm5-934w| GitHub Advisory GHSA-9rhm-2h4x-jwmx| a2a-java advisory GHSA-4fpj-g9jf-9rgg| a2a-java advisory GHSA-q78c-5jjq-57g8| a2a-java advisory GHSA-x32g-jvvm-4725| OpenCVE: a2a-python| GitLab Advisory: CVE-2026-115419| Vulners: python-a2a

ตัวตนและสิทธิ์ของเอเจนต์ AI ตรวจสอบอย่างไร?

ณ วันที่ 2026-10-31 ตัวตนและการมอบหมายสิทธิ์ของเอเจนต์ AI ยังไม่มีมาตรฐานร่วมที่สรุปแล้ว ตัวตนของเวิร์กโหลดผลักดันโดยคณะทำงาน IETF WIMSE การมอบหมายสิทธิ์ส่วนใหญ่ใช้ token exchange ตาม RFC 8693 ส่วนตัวตนที่ตรวจสอบได้จากภายนอกมีหลายแนวทางคู่ขนาน เช่น Cloudflare Web Bot Auth และร่าง ANS v2 ขณะที่ A2A เองแตะเพียงลายเซ็น Agent Card ที่เป็นทางเลือก

ปัญหาตัวตนของเอเจนต์กำลังถูกแยกเป็นสามชั้นนอก A2A ชั้นแรกคือตัวตนของเวิร์กโหลด ตอบคำถามว่า “นี่คือโปรแกรมใด” ผู้เขียน draft-klrc-aiagent-auth มาจาก Amazon, Zscaler, Ping Identity, OpenAI และบริษัทอื่น ร่างนี้ได้รับการรับเข้าเป็นร่างของคณะทำงาน IETF WIMSE และถูกแทนที่ด้วย draft-ietf-wimse-aims แนวทางคือใช้ตระกูล WIMSE และ OAuth 2.0 ที่มีอยู่ “ไม่ประดิษฐ์โปรโตคอลใหม่” ชั้นที่สองคือการอนุญาตและการมอบหมายสิทธิ์ ตอบคำถามว่า “ทำในนามใคร ทำอะไรได้บ้าง” ตัวอย่างของ Ping Identity ใช้ act claim ของ token exchange ตาม RFC 8693 บันทึกเส้นทางการมอบหมายทั้งหมด และใช้ may_act จำกัดทอดถัดไป แต่ RFC 8693 เดิมออกแบบมาสำหรับการแลกเปลี่ยนระหว่างเซิร์ฟเวอร์ “หลังจากการยินยอมเกิดขึ้นแล้ว” จึงไม่ครอบคลุมการยินยอมของผู้ใช้ต่อเอเจนต์ตัวใดตัวหนึ่งโดยกำเนิด

ชั้นที่สามคือตัวตนที่ตรวจสอบได้จากภายนอก ตอบคำถามว่า “คนแปลกหน้าจะเชื่อมันได้อย่างไร” Cloudflare Web Bot Auth ใช้ Ed25519 ร่วมกับ RFC 9421 ลงนามคำขอ HTTP แต่ปัจจุบัน Cloudflare ไม่ตรวจ nonce การป้องกันการส่งซ้ำอาศัยอายุสั้นราว 1 นาทีเป็นหลัก ร่าง ANS v2 ใช้ ACME ตรวจสอบโดเมน แบ่งสามระดับ Bronze, Silver (เพิ่ม DANE), Gold (เพิ่มบันทึกความโปร่งใส SCITT) A2A แตะเพียงลายเซ็นการ์ดในชั้นนี้ และลายเซ็นก็เป็นทางเลือก ผลิตภัณฑ์เชิงพาณิชย์ออกมาก่อนแล้ว: Okta Agent SSO เปิดตัวอย่างเป็นทางการเมื่อ 2026-08-24 และใช้ ID-JAG ส่วน Microsoft Entra Agent ID ไม่รองรับ ID-JAG โดยกำเนิด และวันเปิดตัวอย่างเป็นทางการแต่ละแหล่งระบุไม่ตรงกัน (2026-04 หรือ 2026-05) ดังนั้นเมื่อทำ A2A ข้ามบริษัท ทั้งสองฝ่ายส่วนใหญ่ต้องแปลงโทเค็นที่ขอบเขตของตน ซึ่งเป็นการอนุมาน

ภาครัฐก็กำลังเติมช่องว่างนี้ CAISI ของ NIST สหรัฐฯ ประกาศ AI Agent Standards Initiative เมื่อ 2026-02-17 มีสามเสาหลัก ได้แก่ มาตรฐานที่อุตสาหกรรมเป็นผู้นำ โปรโตคอลโอเพนซอร์สที่ชุมชนเป็นผู้นำ และการวิจัยความปลอดภัยและตัวตนของเอเจนต์ แต่หน้าโครงการใช้เพียงคำกว้าง ๆ อย่าง “interoperable agent protocols” ไม่ได้ระบุชื่อ A2A หรือ MCP โครงการ “Software and AI Agent Identity and Authorization” ของ NIST NCCoE เผยแพร่สรุปความคิดเห็นต่อเอกสารแนวคิดเมื่อ 2026-09-29 มีผู้ตอบกลับกว่า 600 หน่วยงานหรือบุคคล บล็อกของ NIST เมื่อ 2026-10-27 เรื่อง “Design Tenets for Agent Identity Management Systems” เสนอหลักการออกแบบ 10 ข้อ เช่น เอเจนต์ต้องมีตัวตนอิสระ ผูกกับผู้ริเริ่มและสิทธิ์แคบลงทีละชั้นเมื่อมอบหมาย สิทธิ์น้อยที่สุด การอนุญาตระยะสั้นและเพิกถอนได้ ให้มนุษย์เข้าแทรกแซงตามระดับความเสี่ยง ใช้ mandate ที่ลงนามกำหนดขอบเขตการกระทำ และเก็บบันทึกที่แก้ไขไม่ได้ ทั้งนี้มีสถานะเป็นบล็อก ไม่ใช่มาตรฐานอย่างเป็นทางการ

ทิศทางงานวิจัยทางวิชาการสอดคล้องกัน South และคณะเสนอให้ขยาย OAuth 2.0/OIDC ด้วยข้อมูลรับรองเฉพาะสำหรับเอเจนต์และสร้างห่วงโซ่การมอบหมายที่ตรวจสอบย้อนได้ ฉบับแสดงจุดยืนของงานเดียวกันได้รับการตีพิมพ์ใน ICML 2025 Position Paper Track ส่วน Chan และคณะที่ FAccT 2024 เสนอมาตรการสามกลุ่ม ได้แก่ ตัวระบุเอเจนต์ การเฝ้าติดตามแบบเรียลไทม์ และบันทึกกิจกรรม เพื่อเพิ่มการมองเห็นเอเจนต์

สถาปัตยกรรมสามชั้นของตัวตนเอเจนต์ AI และสถานะปัจจุบัน (2026-10-31)
ชั้นคำถามที่ตอบแนวทางหลักสถานะ
ตัวตนของเวิร์กโหลดนี่คือโปรแกรมใดIETF WIMSE (draft-ietf-wimse-aims)ร่างของคณะทำงาน ยังไม่เป็น RFC
การอนุญาตและการมอบหมายสิทธิ์ทำในนามใคร ทำอะไรได้บ้างRFC 8693 token exchange (act, may_act)เป็น RFC แล้ว แต่ไม่ครอบคลุมการยินยอมของผู้ใช้ต่อเอเจนต์เฉพาะตัว
ตัวตนที่ตรวจสอบได้จากภายนอกคนแปลกหน้าจะเชื่อมันได้อย่างไรCloudflare Web Bot Auth, ร่าง ANS v2, ลายเซ็น Agent Card ของ A2Aต่างคนต่างใช้ ยังไม่มีมาตรฐานร่วม; ลายเซ็น A2A เป็นทางเลือก
ผลิตภัณฑ์เชิงพาณิชย์องค์กรซื้ออะไรได้บ้างในตอนนี้Okta Agent SSO (เปิดตัว 2026-08-24, ID-JAG), Microsoft Entra Agent IDทำงานร่วมกันได้อย่างจำกัด

แหล่งอ้างอิง IETF Datatracker: draft-klrc-aiagent-auth| Ping Identity: การอนุญาตสิทธิ์ Gemini Agent2Agent ด้วย Ping| Identra: OAuth on-behalf-of| Cloudflare Docs: Web Bot Auth| IETF: draft-narajala-courtney-ansv2-01| Forkast: ผู้ขายหกรายออกผลิตภัณฑ์ตัวตนเอเจนต์| tech-insider: เปรียบเทียบผู้ให้บริการตัวตนสำหรับเอเจนต์ AI| NIST: AI Agent Standards Initiative (2026-02-17)| NIST: สรุปความคิดเห็นต่อเอกสารแนวคิด Software and agentic AI identity (2026-09-29)| NIST: Design Tenets for Agent Identity Management Systems (2026-10-27)| South et al., Authenticated Delegation and Authorized AI Agents (arXiv:2501.09674)| Chan et al., Visibility into AI Agents (FAccT 2024)

เอเจนต์ AI ชำระเงินอย่างไร? AP2, x402 และ A2A เกี่ยวข้องกันอย่างไร?

ปัจจุบันการชำระเงินของเอเจนต์ AI แบ่งเป็นโปรโตคอลสามชั้น ได้แก่ การชำระเงินเชกเอาต์ หลักฐานการอนุญาต และการชำระเงินย่อยระหว่างเครื่อง โดย A2A เป็นเพียงชั้นสื่อสารที่ติดส่วนขยายการชำระเงินได้ ในจำนวนนี้ AP2 v0.2.0 (2026-04-28) เปลี่ยนมาใช้ Checkout Mandate และ Payment Mandate และเมื่อ 2026-04-29 Google ได้มอบให้ FIDO Alliance ดูแล แต่สเปกระบุชัดว่าการจัดการข้อพิพาทอยู่นอกขอบเขตและไม่กำหนดความรับผิดชอบ

AP2 ไม่ใช่เวอร์ชันที่ทุกคนจำได้ในปี 2025 อีกต่อไป v0.2.0 เปลี่ยนกลไกเป็น Checkout Mandate และ Payment Mandate แต่ละตัวแบ่งเป็นสองระยะคือ open และ closed พัฒนาด้วย SD-JWT โดย open mandate ใช้ cnf claim เก็บกุญแจสาธารณะของเอเจนต์ จุดใหม่ที่สำคัญคือขั้นตอน Human-Not-Present: ผู้ใช้ลงนาม open mandate ด้วยกุญแจของตนบนอินเทอร์เฟซที่เชื่อถือได้พร้อมระบุเงื่อนไขจำกัด จากนั้นเอเจนต์จึงลงนาม closed mandate ด้วยกุญแจของเอเจนต์ ทั้งสองส่วนผูกกันด้วย sd_hash ร้านค้าหรือผู้ให้บริการข้อมูลรับรองสามารถตอบกลับ unresolved_constraint เพื่อดึงขั้นตอนกลับไปสู่ “มีคนอยู่” สเปกยังแนะนำให้ร้านค้าใช้ลายเซ็นแบบไม่กำหนดแน่นอน (ECDSA) แทน Ed25519 เมื่อลงนาม Checkout JWT เพื่อป้องกันการโจมตีด้วยตารางเรนโบว์ (rainbow table) ที่สำคัญที่สุดคือ สเปก AP2 จัดให้การจัดการ การเก็บรักษา และการเรียกดูข้อพิพาทอยู่นอกขอบเขต (out of scope) และสัญญาเพียงจะให้ร่องรอยการตรวจสอบเชิงวิทยาการเข้ารหัสที่ปฏิเสธไม่ได้ บันทึกการวิจัยยังสังเกตว่า วิธีขยายที่สเปก AP2 แนะนำคือ extension point ของ UCP ขณะที่ A2A กลับไม่ถูกกล่าวถึงในเนื้อหาหลักของสเปก ตำแหน่งของ AP2 กำลังเคลื่อนจาก “ส่วนขยายของ A2A” ไปเป็น “ชั้นความปลอดภัยในโปรโตคอลการค้า” ซึ่งเป็นการอนุมาน

วิธีติดส่วนขยายการชำระเงินเข้ากับ A2A ก็คือกลไก extension ของ A2A เอง: ประกาศด้วย AgentExtension (uri, description, required, params) ใน AgentCapabilities และไคลเอนต์ขอเปิดใช้ด้วยส่วนหัว A2A-Extensions ส่วนขยายห้ามแก้โครงสร้างข้อมูลแกนหลัก ห้ามเพิ่มค่า enum ทำงานผ่าน metadata ได้เท่านั้น การเปลี่ยนแปลงที่ทำลายความเข้ากันได้ต้องเปลี่ยนไปใช้ URI ใหม่ และหากพบเวอร์ชันที่ไม่รองรับต้อง “MUST NOT fall back” a2a-x402 (spec v0.1) เป็นส่วนขยายลักษณะนี้: ร้านค้าส่ง payment-required ไคลเอนต์ลงนามแล้วตอบ payment-submitted และเมื่อร้านค้าชำระบนเชนเสร็จจะตอบ payment-completed

จำนวนธุรกรรมของ x402 ส่วนใหญ่มาจากการปั่นยอด Chainalysis ระบุว่าธุรกรรม x402 บนเชน Base สะสมถึงไตรมาสแรกปี 2026 เกิน 100 ล้านรายการ แต่การพุ่งขึ้นในไตรมาสสี่ปี 2025 “ส่วนใหญ่ขับเคลื่อนโดย meme coin farming” และอัตราคงอยู่รายสัปดาห์ลดจาก 87% เหลือ 5% Coinbase อ้างเมื่อปลายเดือนเมษายน 2026 ว่ามีราว 165 ล้านรายการ มูลค่าสะสมราว 50 ล้านดอลลาร์สหรัฐ ซึ่งเป็นคำกล่าวอ้างของผู้ขาย ขณะที่ Artemis มองว่ากว่า 95% เป็นสัญญาณของโปรโตคอลหรือการทดสอบ และเว็บติดตามอีกแห่งประเมินว่ามูลค่าการค้าจริงอยู่ที่ราววันละ 28,000 ดอลลาร์สหรัฐ

แนวปฏิบัติจริงของเครือข่ายบัตรและแพลตฟอร์มคือ “รับหลายโปรโตคอล และใช้การยืนยันตัวตนแบบเข้มงวดที่มีคนอยู่เป็นวาล์วนิรภัย” ในเดือนมีนาคม 2026 OpenAI นำ Instant Checkout ใน ChatGPT กลับไปเป็นโมเดล Apps ของร้านค้า โฆษกกล่าวว่า “Instant Checkout is moving to Apps” วันที่ 2026-07-02 Visa ประกาศว่าในยุโรปมีเอเจนต์ทำการซื้อสำเร็จจริงแล้ว ร่วมกับผู้ออกบัตรกว่า 30 ราย และทุกธุรกรรมใช้ Payment Passkeys เพื่อให้สอดคล้องกับการยืนยันตัวตนลูกค้าแบบเข้มงวด (SCA) กรอบความรับผิดชอบยังว่างเปล่า: Chargebacks911 เตือนว่าโครงสร้างพื้นฐานด้านข้อพิพาทและความรับผิดชอบ “largely unaddressed” Taylor Wessing วิเคราะห์ว่าภายใต้กรอบของสหภาพยุโรป การซื้อของเอเจนต์ที่เกินเงื่อนไขที่ลูกค้ากำหนดโดยหลักจะถือเป็นธุรกรรมที่ไม่ได้รับอนุญาต ส่วน Ant International, Visa, Mastercard เพิ่งเริ่มสำรวจกรอบการทำงานร่วมกันแบบ Know-Your-Agent เมื่อ 2026-09-10 PSD3/PSR ของสหภาพยุโรปปัจจุบันเพิ่งถึงขั้นที่คณะมนตรีรับรองจุดยืนวาระแรกเมื่อ 2026-10-29 ยังไม่ได้ลงใน Official Journal และเมื่อค้นด้วยคำสำคัญในบันทึกเหตุผลของ PSR ฝั่งคณะมนตรีไม่พบบทบัญญัติเรื่อง AI หรือเอเจนต์อัตโนมัติ ส่วน CFPB ของสหรัฐฯ ก็ยังไม่มีแนวทางเรื่องการชำระเงินผ่านเอเจนต์

งานวิจัยทางวิชาการชี้จุดบอดอีกจุดหนึ่ง Debi และคณะ (IEEE IMNS 2026) ทดสอบ red team กับเอเจนต์ช้อปปิ้งที่ใช้ AP2 พบว่า prompt injection ทั้งทางอ้อมและทางตรงสามารถบิดการจัดอันดับสินค้าและดึงข้อมูลอ่อนไหวของผู้ใช้ออกมาได้ แสดงว่า mandate ที่ลงนามปกป้องกระบวนการให้เหตุผลก่อนการลงนามไม่ได้ ส่วน Jiang และคณะ (arXiv:2609.00060) ใช้ Tamarin วิเคราะห์เชิงรูปนัยกับ x402, MPP, ACP, AP2 ชี้ให้เห็นการพึ่งพาด้านความปลอดภัยที่เกิดจากเจตนา สิทธิ์ที่มอบหมาย และการชำระเงินกระจายอยู่หลายฝ่าย การนำเอเจนต์มาใช้ในอุตสาหกรรมโลจิสติกส์ตอนนี้ใช้ MCP: เซิร์ฟเวอร์ MCP ของ Flexport ให้ผู้ช่วย AI ของลูกค้าจองระวางขนส่งด้วยอัตราที่ตกลงไว้และรับ booking ID บันทึกการวิจัยไม่พบตัวอย่างการชำระค่าขนส่งด้วย AP2 หรือ x402 เลย

การแบ่งชั้นของโปรโตคอลการชำระเงินสำหรับเอเจนต์ AI (ณ วันที่ 2026-10-31)
ชั้นโปรโตคอลผู้นำสถานะ
ชั้นเชกเอาต์ACPOpenAI + Stripe2026-03 ChatGPT Instant Checkout เปลี่ยนไปใช้ Apps ของร้านค้า ACP ยังคงอยู่
ชั้นเชกเอาต์UCPGoogle + Shopifyแหล่งข้อมูลทุติยภูมิระบุว่าเอนด์พอยต์ UCP ของ Shopify ใช้ MCP เป็นชั้นขนส่ง
ชั้นหลักฐานการอนุญาตAP2 v0.2.0Google ริเริ่ม และมอบให้ FIDO Alliance เมื่อ 2026-04-29การจัดการข้อพิพาทอยู่นอกขอบเขตสเปก
ชั้นหลักฐานการอนุญาตVerifiable IntentMastercardแหล่งข้อมูลทุติยภูมิระบุว่าเปิดซอร์สเมื่อ 2026-03
ชั้นชำระเงินย่อยระหว่างเครื่องx402Coinbase ริเริ่มจำนวนธุรกรรมบนเชนส่วนใหญ่เป็นการปั่นยอด; มูลค่าการค้าจริงประเมินราววันละ 28,000 ดอลลาร์สหรัฐ
ชั้นชำระเงินย่อยระหว่างเครื่องMPPStripe + Tempoแหล่งข้อมูลทุติยภูมิระบุว่าเปิดตัว 2026-03 พร้อมเมนเน็ตของ Tempo

แหล่งอ้างอิง AP2 v0.2 Specification| AP2 Flows| ap2-protocol.org| FIDO Alliance: Google มอบ AP2| A2A Extensions| google-agentic-commerce/a2a-x402| Chainalysis: x402 agentic payments adoption| Forkast: ปริมาณธุรกรรมจริงของ x402| presenc.ai: การติดตามการใช้งาน x402| Digital Commerce 360 (2026-03-06)| ข่าวประชาสัมพันธ์ Visa UK (2026-07-02)| The Paypers: คำเตือนของ Chargebacks911| Taylor Wessing: Agentic AI in payments| TechNode (2026-09-10)| The Paypers: การเปิดตัว MPP| Mastercard Developers: คู่มือธุรกรรม Agentic| คณะมนตรีสหภาพยุโรป: เอกสารลงมติจุดยืนวาระแรกของ PSR ST 15154/26| Debi et al., Whispers of Wealth (IEEE IMNS 2026)| Jiang et al., A Formal Analysis of Agent Payment Protocols (arXiv:2609.00060)| SupplyChain247: ผู้ช่วย AI ของ Flexport จองระวางขนส่ง

ตอนนี้มีใครใช้ A2A จริงไหม? มีกรณีใช้งานจริงหรือไม่?

ณ วันที่ 2026-10-31 บันทึกการวิจัยไม่พบกรณีใช้งาน A2A จริงที่ระบุชื่อ ข้ามบริษัท และมีผลการวัด Linux Foundation อ้างเมื่อ 2026-04-09 ว่ามีองค์กรสนับสนุนกว่า 150 แห่งและมีการใช้งานจริง แต่ไม่ได้ระบุชื่อผู้ใช้ ขณะที่ผู้เขียนรายหนึ่งส่งคำขอ 36 ครั้งไปยัง 18 องค์กรเมื่อ 2026-10-27 และได้ Agent Card ที่ใช้ได้ 0 ใบ

ข่าวประชาสัมพันธ์ครบรอบหนึ่งปีของ Linux Foundation เมื่อ 2026-04-09 ระบุว่า A2A มีองค์กรสนับสนุนกว่า 150 แห่ง และมีการใช้งานจริงในซัพพลายเชน การเงิน ประกันภัย และงานปฏิบัติการไอที ซึ่งเป็นคำกล่าวอ้างของผู้ขาย: ข่าวประชาสัมพันธ์ไม่ได้ระบุชื่อผู้ใช้ใด และไม่มีขั้นตอนหรือตัวชี้วัดผลลัพธ์ ตัวอย่างที่ถูกยกมาบ่อยที่สุด คือบทความ Microsoft Agent Framework .NET และ codelab ผู้ช่วยจัดซื้อของ Google ล้วนเป็นโค้ดตัวอย่าง ไม่ใช่รายงานการใช้งานจริง Tyson Foods มักถูกโปรโมตว่าเป็นกรณี A2A ในซัพพลายเชน แต่ apis.io ให้คะแนน A2A Agent Card ของบริษัท 0/8 และสิ่งที่ให้คู่ค้าใช้ยังคงเป็น EDI และ API

หลักฐานโต้แย้งที่ตรงที่สุดคือการทดสอบจริง ผู้เขียนรายหนึ่งเลือกเอเจนต์ 50 ตัวที่อ้างว่ารองรับ A2A จากศูนย์ลงทะเบียนสาธารณะเมื่อเดือนเมษายน 2026 พบว่ามีเพียงราว 0–2 ตัวที่ให้การ์ดที่ใช้ได้ในเส้นทาง well-known และตอบ task ได้ถูกต้อง 0 ตัว ผู้เขียนคนเดิมส่งคำขอ 24 ครั้งไปยัง 12 องค์กรเมื่อ 2026-09-09 และ 36 ครั้งไปยัง 18 องค์กรเมื่อ 2026-10-27 ได้การ์ด 0 ใบทั้งสองครั้ง กลุ่มตัวอย่างผู้เขียนเลือกเอง ไม่ใช่การสำรวจทั้งหมด แต่ทิศทางสอดคล้องกัน สิ่งที่ใช้งานจริงคือการเชื่อมต่อภายในแพลตฟอร์มคลาวด์เดียวกัน ได้แก่ AWS AgentCore, Microsoft Foundry, Google Agent Registry

หลักฐานเชิงประจักษ์เกี่ยวกับสถาปัตยกรรมหลายเอเจนต์เองก็ไม่เป็นผลดีต่อ A2A ข้ามองค์กร MAST (NeurIPS 2025 Datasets & Benchmarks Track) วิเคราะห์ร่องรอยการทำงาน 1,642 รายการ สรุปรูปแบบความล้มเหลวได้ 14 แบบ แบ่งเป็นสามกลุ่มใหญ่ ได้แก่ การออกแบบระบบ ความไม่สอดคล้องระหว่างเอเจนต์ และการตรวจสอบงาน อัตราความล้มเหลวของระบบหลายเอเจนต์โอเพนซอร์สล้ำสมัย 7 ระบบในงานนี้อยู่ระหว่าง 41%–86.7% (ผู้เขียนเตือนว่าเปรียบเทียบข้ามเบนช์มาร์กโดยตรงไม่ได้) งาน “Towards a Science of Scaling Agent Systems” ของ Google Research, MIT และผู้เขียนอื่น ทดสอบ 180 การตั้งค่าในฉบับ v1/v2 และฉบับบล็อกของ Google: ระบบหลายเอเจนต์แบบอิสระขยายข้อผิดพลาด 17.2 เท่า แบบประสานงานจากศูนย์กลาง 4.4 เท่า และในงานให้เหตุผลแบบลำดับขั้น ทุกรูปแบบของระบบหลายเอเจนต์แย่ลง 39%–70% ฉบับ v3 เมื่อ 2026-04-08 ขยายเป็น 260 การตั้งค่าและ 6 เบนช์มาร์ก แต่ยังคงข้อสรุป 17.2 เท่าและ 4.4 เท่า บล็อกวิศวกรรมของ Anthropic (ไม่ใช่บทความที่ผ่านการพิจารณาโดยผู้ทรงคุณวุฒิ) อธิบายว่าระบบวิจัยแบบหลายเอเจนต์ของบริษัทดีกว่า Claude Opus 4 แบบเอเจนต์เดียว 90.2% แต่ใช้โทเค็นราว 15 เท่าของการสนทนาทั่วไป และระบุว่างานที่ “ต้องให้ทุกเอเจนต์ใช้บริบทเดียวกัน หรือเอเจนต์พึ่งพากันมาก” ไม่เหมาะ A2A ข้ามองค์กรรวมเงื่อนไขที่ไม่เอื้อเหล่านี้ไว้ครบ: สองฝ่ายไม่ได้ใช้บริบทร่วมกัน ไม่มีผู้ตรวจสอบร่วม และกระบวนการทางการค้า (เช็กราคา→สั่งซื้อ→ชำระเงิน→จัดส่ง) ก็เป็นแบบลำดับขั้น ซึ่งเป็นการอนุมาน

ช่องว่างด้านวิศวกรรมมีมากกว่าด้านสเปก เมื่อ A2A มอบหมายงานให้เอเจนต์ถัดไป trace จะขาด: SDK ภาษา Python สร้าง span เฉพาะในเครื่อง ไม่มีวิธีมาตรฐานในการส่ง W3C Trace Context ระหว่างเอเจนต์ (Issue #2103) SDK ภาษา Rust ของชุมชนรายงานความล้มเหลวของ TCK 7 รายการ หลังเทียบแล้วพบว่าเป็นข้อบกพร่องของชุดทดสอบเอง รายงานเดียวกันระบุว่า SDK ภาษา JS, Go, Java ผ่าน 21/21 ในทั้งสองการผูก ทราฟฟิกของเอเจนต์ฝั่งผู้บริโภคก็ยังเล็ก: HUMAN Security ระบุว่าทราฟฟิกเอเจนต์ปี 2025 เพิ่มขึ้น 7,851% เมื่อเทียบปีต่อปี แต่เกิดในหน้าชำระเงินเพียง 2.3% แหล่งข้อมูลทุติยภูมิอ้างข้อมูล Cloudflare Radar เดือนสิงหาคม 2026 ว่าบอต AI คิดเป็นราว 7% ของคำขอ HTML ในจำนวนนี้ “การกระทำแบบเรียลไทม์แทนผู้ใช้” มีเพียง 5.8% คูณกันได้ราว 0.4% ผลคูณนี้เป็นการอนุมานและยังไม่ได้ยืนยันกับข้อมูลต้นฉบับ Akamai เตือนว่าเว็บไซต์อีคอมเมิร์ซเพียงเฝ้าติดตามบอต AI กว่า 90% ขณะที่กิจกรรมของเอเจนต์ฉ้อโกงกำลังเพิ่มขึ้น บันทึกการวิจัยไม่พบหลักฐานว่าเอเจนต์ส่วนตัวอย่าง ChatGPT, Gemini, Claude ใช้ A2A เรียกเอเจนต์ขององค์กรทั่วไป แต่นี่เป็นเพียงการขาดหลักฐานโต้แย้ง ไม่ใช่การยืนยันอย่างเป็นทางการ

การสัมภาษณ์ของภาครัฐและองค์กรระหว่างประเทศแสดงว่าความต้องการมีอยู่จริง OECD Artificial Intelligence Papers No. 65 หน้า 16 บันทึกว่าผู้ปฏิบัติงานที่ให้สัมภาษณ์นิยมโปรโตคอลเปิด และมองว่าโปรโตคอลสื่อสารแบบเอเจนต์ต่อเอเจนต์อย่าง A2A เป็นแรงขับเคลื่อนสำคัญของการประสานงานหลายเอเจนต์ พร้อมกังวลว่าจะถูกผูกติดกับระบบนิเวศของผู้ขายรายเดียว

การใช้งาน A2A จริง: เทียบคำกล่าวอ้างกับหลักฐาน (ณ วันที่ 2026-10-31)
คำกล่าวหรือกรณีหลักฐานที่ตรวจพบจริงการประเมิน
Linux Foundation: กว่า 150 องค์กร ใช้งานจริงหลายอุตสาหกรรมข่าวประชาสัมพันธ์ไม่ระบุชื่อผู้ใช้ ไม่มีตัวชี้วัดผลลัพธ์คำกล่าวอ้างของผู้ขาย
กรณีซัพพลายเชนของ Tyson Foodsapis.io ให้คะแนน A2A Agent Card 0/8; กับคู่ค้ายังใช้ EDI และ APIหลักฐานไม่สนับสนุน
Microsoft Agent Framework, Google codelabโค้ดตัวอย่าง ไม่ใช่รายงานการใช้งานจริงไม่ใช่กรณีใช้งานจริง
เอเจนต์ 50 ตัวที่อ้างว่ารองรับในศูนย์ลงทะเบียนสาธารณะ (2026-04)การ์ดที่ใช้ได้ราว 0–2 ใบ ตอบ task ถูกต้อง 0 ตัวการทดสอบจริงโดยบุคคลที่สาม
18 องค์กร 36 คำขอ (2026-10-27)การ์ด 0 ใบ (กลุ่มตัวอย่างเลือกเอง)การทดสอบจริงโดยบุคคลที่สาม
การเชื่อมต่อภายในแพลตฟอร์มคลาวด์เดียวกันAWS AgentCore, Microsoft Foundry, Google Agent Registry ให้บริการแล้วรูปแบบที่ใช้งานจริงในปัจจุบัน

HowBridge คืออะไร? คำตอบสั้นเรื่องแบรนด์และบริการ

แหล่งอ้างอิง Linux Foundation: ข่าวประชาสัมพันธ์ครบรอบหนึ่งปีของ A2A (2026-04-09)| Microsoft DevBlogs: A2A v1 in Agent Framework for .NET| Google Codelabs: A2A purchasing concierge| apis.io: Tyson Foods| heym.run: ทดสอบจริง A2A vs MCP| Cemri et al., Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025 D&B)| Kim et al., Towards a Science of Scaling Agent Systems (arXiv:2512.08296)| บล็อก Google Research (2026-01-28)| Anthropic Engineering: How we built our multi-agent research system| A2A Issue #2103 (trace ขาดตอน)| a2a-rust PR #180 (ผล TCK)| HUMAN Security: 2026 State of AI Traffic| PaidHosting: AI agent traffic (อ้างอิง Cloudflare Radar)| ข่าวประชาสัมพันธ์ของ Akamai| OECD Artificial Intelligence Papers No. 65

รัฐบาลแต่ละประเทศกำกับดูแลเอเจนต์ AI อย่างไร? มีการกล่าวถึง A2A หรือไม่?

ณ วันที่ 2026-10-31 เอกสารทางการของกระทรวงกิจการดิจิทัลไต้หวัน IMDA สิงคโปร์ และ OECD ได้ระบุชื่อ A2A หรือความเสี่ยงของระบบหลายเอเจนต์โดยตรงแล้ว แต่ยังไม่มีประเทศใดออกกฎหมายเฉพาะสำหรับ A2A กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ของไต้หวันประกาศและมีผลบังคับใช้เมื่อ 115-01-14 (2026-01-14) หน่วยงานรับผิดชอบคือสภาวิทยาศาสตร์และเทคโนโลยีแห่งชาติ (NSTC) ส่วนการแบ่งความรับผิดชอบเมื่อเอเจนต์ทำผิดพลาดต้องรอระเบียบประกอบที่มาตรา 17 มอบอำนาจไว้

ไต้หวัน: กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์มี 20 มาตรา มาตรา 3 นิยามปัญญาประดิษฐ์ว่าเป็น “ระบบที่มีความสามารถทำงานได้เองโดยอัตโนมัติ” ซึ่งครอบคลุมเอเจนต์ AI ได้ แต่ตัวบทไม่มีคำว่า “เอเจนต์” มาตรา 4 กำหนดหลักการใหญ่เจ็ดข้อ รวมถึงความเป็นอิสระและการกำกับดูแลของมนุษย์ ความโปร่งใสและการอธิบายได้ และความรับผิดชอบ มาตรา 16 ให้กระทรวงกิจการดิจิทัลผลักดันกรอบการจำแนกความเสี่ยงที่เชื่อมโยงกับระดับสากล มาตรา 17 กำหนดให้รัฐระบุความรับผิดชอบและเงื่อนไขการกำหนดความรับผิดของ AI ความเสี่ยงสูงให้ชัดเจน พร้อมจัดตั้งกลไกเยียวยา ชดเชย หรือประกันภัย และมาตรา 18 กำหนดให้หน่วยงานต่าง ๆ ปรับกฎระเบียบที่เกี่ยวข้องให้เสร็จภายในสองปีหลังมีผลบังคับใช้ ตามมาตรา 16 กระทรวงกิจการดิจิทัลประกาศกรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์ v1.0 เมื่อ 115-07-07 (ปฏิทินหมินกั๋ว หรือ 2026-07-07) (หนังสือเลขที่ 1150015933 มีผลทันที) ในนั้นความเสี่ยงประเภท B6 “พฤติกรรมเกินขอบเขตการอนุญาตของเอเจนต์ AI อัตโนมัติ” ระบุว่า “ระบบหลายเอเจนต์มีแนวโน้มมากขึ้นที่เอเจนต์จะกระตุ้นซึ่งกันและกัน จนเกิดปฏิกิริยาลูกโซ่ที่ทั้งผู้พัฒนาและผู้ใช้ไม่ได้คาดคิด ทำให้มนุษย์เข้าแทรกแซงแก้ไขได้ไม่ทันท่วงที” ส่วนแนวทางการใช้ AI เชิงสร้างสรรค์ในสถานพยาบาลที่กระทรวงสาธารณสุขและสวัสดิการออกเมื่อ 115-05-29 (2026-05-29) ระบุชัดว่าระบบเอเจนต์ AI “ยังไม่อยู่ในขอบเขตการบังคับใช้ของแนวทางนี้”

กฎหมายที่มีอยู่ของไต้หวันก็ใช้กับสถานการณ์ของเอเจนต์ได้ มาตรา 4 ของกฎหมายคุ้มครองข้อมูลส่วนบุคคลกำหนดว่า ผู้ที่ได้รับมอบหมายให้เก็บรวบรวม ประมวลผล หรือใช้ข้อมูลส่วนบุคคล ภายในขอบเขตของกฎหมายนี้ให้ถือเสมือนเป็นหน่วยงานผู้มอบหมาย ดังนั้นการส่งข้อมูลส่วนบุคคลให้เอเจนต์ประมวลผลจึงไม่พ้นความรับผิดเพียงเพราะ “AI เป็นผู้ทำ” มาตรา 21 กำหนดข้อจำกัดการโอนข้อมูลระหว่างประเทศ ควรทราบว่าบทบัญญัติที่แก้ไขเมื่อ 114-11-11 (2025-11-11) หลายมาตรา (รวมมาตรา 21 ฉบับใหม่และมาตรา 20-1 ที่เพิ่มเข้ามา) ประกาศแล้วแต่ยังไม่มีผลบังคับใช้ วันมีผลบังคับใช้ให้สภาบริหาร (Executive Yuan) เป็นผู้กำหนด กฎหมายลายมือชื่ออิเล็กทรอนิกส์ไม่ได้กล่าวถึง AI หรือเอเจนต์ การที่เอเจนต์ลงนามแทนจะสันนิษฐานได้ว่าเป็นการลงนามของบุคคลนั้นเองหรือไม่ กฎหมายไม่ได้บัญญัติไว้ และบทความนี้ไม่สามารถยืนยันได้

จีน: สำนักงานกำกับดูแลตลาดแห่งชาติและคณะกรรมการบริหารการมาตรฐานแห่งชาติ ออกประกาศมาตรฐานแห่งชาติฉบับที่ 22 ปี 2026 อนุมัติและเผยแพร่ชุดเอกสาร GB/Z 185.1～185.7-2026 “ปัญญาประดิษฐ์ — การเชื่อมต่อระหว่างเอเจนต์” เมื่อ 2026-05-22 รวมเอกสารแนวทางทางเทคนิค 7 ฉบับ (สถาปัตยกรรมโดยรวม รหัสตัวตน การจัดการตัวตน คำอธิบายเอเจนต์ การค้นพบเอเจนต์ การโต้ตอบของเอเจนต์ และการเรียกใช้เครื่องมือของเอเจนต์) แพลตฟอร์มบริการสาธารณะข้อมูลมาตรฐานแห่งชาติระบุสถานะว่า “มีผลใช้อยู่” เปิดเผยฉบับเต็มเมื่อ 2026-06-18 และสำนักงานกำกับดูแลตลาดแห่งชาติยังจัดแถลงข่าวเฉพาะเรื่องเมื่อ 2026-06-26 ชื่อโปรโตคอลที่เอกสารทางการใช้คือ AIP (โปรโตคอลการเชื่อมต่อระหว่างเอเจนต์) หน้าเว็บทางการที่ตรวจพบไม่ได้กล่าวถึง A2A หรือ MCP และยังไม่ได้รับการยืนยันว่าเข้ากันได้หรือไม่ วันที่ 2026-05-08 สำนักงานสารสนเทศไซเบอร์สเปซแห่งชาติ คณะกรรมการพัฒนาและปฏิรูปแห่งชาติ และกระทรวงอุตสาหกรรมและเทคโนโลยีสารสนเทศ ร่วมออกความเห็นการดำเนินการว่าด้วยการใช้เอเจนต์อย่างเป็นมาตรฐานและการพัฒนาเชิงนวัตกรรม ผูกการส่งเสริม AIP แพลตฟอร์มลงทะเบียนเอเจนต์ และตัวตนดิจิทัลของเอเจนต์ไว้เป็นชุดเดียว พร้อมกำหนดว่า “การดำเนินการของเอเจนต์ต้องไม่เกินขอบเขตที่ผู้ใช้อนุญาต” แนวทางนี้ต่างจากชุมชน A2A ที่ “ไม่มีศูนย์ลงทะเบียนทางการ”

สหภาพยุโรป: AI Act (Regulation (EU) 2024/1689) มีผลเมื่อ 2024-08-01 พันธกรณีของโมเดล AI อเนกประสงค์ใช้ตั้งแต่ 2025-08-02 การบังคับใช้ทั่วไปและพันธกรณีด้านความโปร่งใสเริ่ม 2026-08-02 ส่วนพันธกรณีความเสี่ยงสูงถูกเลื่อนโดย Regulation (EU) 2026/1744 (ลงใน Official Journal เมื่อ 2026-07-24) โดยภาคผนวก III เลื่อนเป็น 2027-12-02 และภาคผนวก I เลื่อนเป็น 2028-08-02 ส่วน PSD3 และ PSR นั้นคณะมนตรีเพิ่งรับรองจุดยืนวาระแรกเมื่อ 2026-10-29 ยังรอรัฐสภายุโรปพิจารณาวาระที่สอง และยังไม่ได้ลงใน Official Journal

สหรัฐฯ สิงคโปร์ สหราชอาณาจักร: CISA, NSA และหน่วยงานในกลุ่ม Five Eyes เผยแพร่ “Careful Adoption of Agentic AI Services” เมื่อ 2026-04-30/05-01 แนะนำให้จำกัดสิทธิ์การเข้าถึงและเริ่มจากกรณีใช้งานความเสี่ยงต่ำที่ไม่อ่อนไหว CFPB ของสหรัฐฯ ไม่มีแนวทางเรื่องการชำระเงินผ่านเอเจนต์ และข้อเสนอกฎการตีความที่เกี่ยวข้องในปี 2025 ถูกถอนเมื่อ 2025-05-15 “Model AI Governance Framework for Agentic AI” v1.5 ของ IMDA สิงคโปร์ (เผยแพร่ 2026-05-20 ปรับปรุง 06-05) หมวด 1.1.1 ระบุชื่อ A2A สำหรับการสื่อสารระหว่างเอเจนต์ และ MCP สำหรับการสื่อสารระหว่างเอเจนต์กับเครื่องมือ พร้อมชี้ว่าการมอบหมายแบบเวียนซ้ำและตัวตนข้ามองค์กรเป็นช่องว่างในปัจจุบัน แนวทางของ CMA สหราชอาณาจักรที่เผยแพร่เมื่อ 2026-03-09 (ปรับปรุง 10-30) เขียนว่า “if an AI agent you use does something illegal, you are responsible” กล่าวคือผู้ประกอบการต้องรับผิดชอบต่อการกระทำผิดกฎหมายของเอเจนต์ที่ตนใช้ ส่วนการรับฟังความคิดเห็นสาธารณะเรื่อง AI แบบเอเจนต์ของ ICO สหราชอาณาจักรจะปิดรับในวันที่ 2026-11-20

ความเกี่ยวข้องของเอกสารทางการในแต่ละพื้นที่กับ A2A/เอเจนต์ AI (เฉพาะเอกสารที่ตรวจสอบต้นฉบับแล้ว)
พื้นที่เอกสารวันที่ความเกี่ยวข้องกับ A2A หรือเอเจนต์
ไต้หวันกฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ประกาศและมีผล 115-01-14 (2026-01-14)มาตรา 17 กำหนดให้ระบุความรับผิดชอบของ AI ความเสี่ยงสูง; ไม่ได้กล่าวถึง “เอเจนต์”
ไต้หวันกระทรวงกิจการดิจิทัล: กรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์ v1.0115-07-07 (2026-07-07)ความเสี่ยง B6 “พฤติกรรมเกินขอบเขตการอนุญาตของเอเจนต์ AI อัตโนมัติ”
ไต้หวันกระทรวงกิจการดิจิทัล: คู่มืออ้างอิงการใช้ปัญญาประดิษฐ์ในภาครัฐ V1.0115-01-28 (2026-01-28 ตามที่เอกสารระบุ)หัวข้อย่อย A2A ในหน้า 14
จีนGB/Z 185.1～185.7-2026 “ปัญญาประดิษฐ์ — การเชื่อมต่อระหว่างเอเจนต์”อนุมัติและเผยแพร่ 2026-05-22ชื่อโปรโตคอลทางการคือ AIP; ความเข้ากันได้กับ A2A ยังไม่ได้รับการยืนยัน
สหภาพยุโรปRegulation (EU) 2026/1744ลงประกาศ 2026-07-24พันธกรณีความเสี่ยงสูงของ AI Act เลื่อนเป็น 2027-12-02 / 2028-08-02
สหภาพยุโรปจุดยืนวาระแรกของคณะมนตรีต่อ PSD3/PSR2026-10-29ยังไม่ลง Official Journal; บันทึกเหตุผลของ PSR ไม่พบบทบัญญัติเรื่องเอเจนต์
สหรัฐฯNIST “Design Tenets for Agent Identity Management Systems”2026-10-27หลักการออกแบบตัวตนเอเจนต์ 10 ข้อ (บล็อก)
สิงคโปร์กรอบธรรมาภิบาล AI แบบเอเจนต์ของ IMDA v1.52026-05-20§1.1.1 ระบุชื่อ A2A และ MCP
สหราชอาณาจักรแนวทางของ CMA ว่าด้วยกฎหมายผู้บริโภคและเอเจนต์ AI2026-03-09ผู้ประกอบการรับผิดชอบต่อการกระทำผิดกฎหมายของเอเจนต์ที่ตนใช้
ระหว่างประเทศOECD AI Papers No. 652026-09หน้า 16: ผู้ปฏิบัติงานมอง A2A เป็นแรงขับเคลื่อนการประสานงานหลายเอเจนต์

แหล่งอ้างอิง ฐานข้อมูลกฎหมายแห่งชาติไต้หวัน: กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์| ประกาศกระทรวงกิจการดิจิทัล: กรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์| กระทรวงกิจการดิจิทัล: กรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์ v1.0 (PDF)| กระทรวงกิจการดิจิทัล: คู่มืออ้างอิงการใช้ปัญญาประดิษฐ์ในภาครัฐ (PDF)| กระทรวงสาธารณสุขและสวัสดิการไต้หวัน: แนวทางการใช้ AI เชิงสร้างสรรค์ในสถานพยาบาล| ฐานข้อมูลกฎหมายแห่งชาติไต้หวัน: กฎหมายคุ้มครองข้อมูลส่วนบุคคล| ฐานข้อมูลกฎหมายแห่งชาติไต้หวัน: กฎหมายลายมือชื่ออิเล็กทรอนิกส์| คณะกรรมการบริหารการมาตรฐานแห่งชาติจีน: ประกาศมาตรฐานแห่งชาติฉบับที่ 22 ปี 2026| แพลตฟอร์มบริการสาธารณะข้อมูลมาตรฐานแห่งชาติ: GB/Z 185.1-2026| แพลตฟอร์มบริการสาธารณะข้อมูลมาตรฐานแห่งชาติ: ประกาศเปิดเผยฉบับเต็ม| ศูนย์นวัตกรรมวิทยาศาสตร์และเทคโนโลยีนานาชาติ: งานแถลงข่าวการมาตรฐานการเชื่อมต่อระหว่างเอเจนต์| สำนักงานกำกับดูแลตลาดแห่งชาติจีน: รายงานที่นำมาเผยแพร่ซ้ำ| เว็บไซต์สารสนเทศไซเบอร์สเปซจีน: ความเห็นการดำเนินการว่าด้วยการใช้เอเจนต์อย่างเป็นมาตรฐานและการพัฒนาเชิงนวัตกรรม| European Commission: AI Act regulatory framework| European Parliament: Digital Omnibus on AI| คณะมนตรีสหภาพยุโรป: เอกสารลงมติ PSD3 ST 15152/26| คณะมนตรีสหภาพยุโรป: เอกสารลงมติ PSR ST 15154/26| CISA: Secure adoption of agentic AI| Federal Register 2025-08646 (CFPB ถอนข้อเสนอ)| IMDA: Model AI Governance Framework for Agentic AI v1.5| GOV.UK: CMA complying with consumer law when using AI agents| ICO: Agentic AI call for evidence| OECD Artificial Intelligence Papers No. 65

A2A v1.1 จะเติมอะไรบ้าง? ยังมีคำถามใดที่ไม่มีคำตอบ?

แปดหัวข้อของ A2A v1.1 ผ่านมติของ TSC เมื่อ 2026-06-25 ด้วยคะแนน 5 ต่อ 0 ครอบคลุมการต่อสตรีม ความเป็น idempotent การตั้งค่าการแจ้งเตือนแบบพุช การเลือกทักษะ การค้นพบวิธียืนยันตัวตน ประวัติงาน การโต้ตอบหลายรอบ และการสตรีมสองทาง ณ วันที่ 2026-10-31 ยังไม่มีวันเผยแพร่ และประเด็นที่ถกเถียงกันมากที่สุด เช่น ตัวตนของเอเจนต์ การมอบหมายสิทธิ์ และการคิดค่าบริการ ยังไม่ได้ข้อสรุป

Issue #1942 รวม 41 ประเด็นเป็นแปดหัวข้อของ v1.1 ส่วนความจำของเอเจนต์ข้ามงาน (#893) ไม่อยู่ในขอบเขตการติดตาม สิ่งที่บอกทิศทางได้ชัดกว่ารายการหัวข้อคือประเด็นที่มีความคิดเห็นมากที่สุด ได้แก่ #1672 การยืนยันตัวตนของเอเจนต์สำหรับ Agent Card (ราว 658 ความคิดเห็น), #1829 การลงนามข้อความด้วย Ed25519 ร่วมกับ RFC 9421, #2028 การมอบหมายแบบ actor-chain, #2121 การส่งต่อข้อมูลต้นทุนและงบประมาณ และ #1815 การใช้ HTTP 402 แทน “ต้องชำระเงิน” ทั้งหมดเป็นปัญหาเรื่องความไว้วางใจและการค้า เมื่อรวมกับกระบวนการกำกับดูแล extension ที่ตั้งขึ้นใหม่ บันทึกการวิจัยประเมินว่าสิ่งเหล่านี้น่าจะออกมาในรูปส่วนขยายมากกว่าการแก้สเปกแกนหลัก ซึ่งเป็นการอนุมาน

“เอเจนต์ส่วนตัวจะหาเอเจนต์ของบริษัทเจอได้อย่างไร” ปัจจุบันยังไม่มีคำตอบแบบเปิดที่ใช้งานจริง เอกสารทางการของ A2A ระบุชัดว่าศูนย์ลงทะเบียนแบบคัดสรร (curated) อยู่นอกขอบเขตของ A2A ข้อเสนอ Agent Registry ใน Discussion #741 ยืดเยื้อมานาน ผู้พิจารณาตั้งคำถามกับสมมติฐานว่า “ผู้ให้บริการจัดการรายการลงทะเบียนของตนเอง” สำหรับการค้นหาเอเจนต์จากโดเมน IETF มีร่างส่วนบุคคลสี่ฉบับที่แข่งขันกัน ได้แก่ DNS-AID (ใช้ระเบียน SVCB ชี้ไปที่ /.well-known/agent-card.json), AID (ค้นระเบียน TXT _agent), ADP และ DAN ซึ่งยังไม่มีฉบับใดได้รับการรับเข้าเป็นร่างของคณะทำงาน ร่าง landscape เมื่อเดือนกรกฎาคม 2026 ก็ชี้ว่าเนมสเปซต้องมีการประสานงาน ฝั่ง MCP นั้น MCP Registry ยังเป็นรุ่นพรีวิวตั้งแต่เดือนกันยายน 2025 จนถึงปัจจุบัน

การตรวจสอบและความรับผิดชอบข้ามองค์กรก็ยังไม่มีกรอบเช่นกัน สเปก A2A มีเพียงข้อกำหนดระดับ SHOULD เรื่องการบันทึกการยืนยันตัวตนที่ล้มเหลวและการจำกัดอัตรา ส่วนสถานะความเสถียรของ semantic conventions ของ OpenTelemetry GenAI แต่ละแหล่งก็ระบุขัดกัน ด้วยเครื่องมือที่มีอยู่ หน่วยตรวจสอบขั้นต่ำที่เก็บได้น่าจะเป็น taskId และ contextId ฝั่งตนเอง ลายนิ้วมือของลายเซ็น Agent Card ของอีกฝ่าย และห่วงโซ่การมอบหมาย act ในโทเค็นที่อีกฝ่ายแสดง โดยแต่ละฝ่ายเก็บไว้เองเพื่อกระทบยอดภายหลัง ซึ่งเป็นการอนุมาน บันทึกการวิจัยยังไม่พบงานวิจัยเชิงประจักษ์เรื่อง denial-of-wallet ที่มุ่ง “ใช้งบ LLM ของอีกฝ่ายจนหมด”

  • #1986 การต่อสตรีม: ต่อจากจุดที่ขาดได้หลังการเชื่อมต่อหลุด
  • #1987 ความเป็น idempotent: ส่งคำขอซ้ำแล้วไม่ถูกดำเนินการซ้ำ
  • #1988 การตั้งค่าการแจ้งเตือนแบบพุช: การตั้งค่าและจัดการ webhook
  • #1989 การเลือกทักษะ: ผู้เรียกระบุทักษะที่ต้องการใช้อย่างไร
  • #1990 การค้นพบวิธียืนยันตัวตน: รู้ล่วงหน้าว่าต้องใช้การยืนยันตัวตนแบบใด
  • #1991 ประวัติงาน: สอบถามบันทึกของงานที่ผ่านมา
  • #1992 การโต้ตอบหลายรอบ: ความหมายเมื่อสองฝ่ายถามตอบกลับไปมา
  • #1995 การสตรีมสองทาง: ทั้งสองฝ่ายสตรีมข้อมูลพร้อมกัน

แหล่งอ้างอิง A2A Issue #1942 (หัวข้อ v1.1)| A2A issues (เรียงตามจำนวนความคิดเห็น)| A2A: Agent discovery| A2A Discussion #741| IETF: ร่าง DNS-AID| IETF: ร่าง DAWN discovery landscape| MCP Registry preview (2025-09-08)| A2A Specification §13.4| GreptimeDB: OpenTelemetry GenAI semantic conventions

ตอนนี้องค์กรควรนำ A2A มาใช้หรือไม่?

จากหลักฐาน ณ วันที่ 2026-10-31 องค์กรที่จะนำ A2A มาใช้ควรยึดแนวทาง “อ่านอย่างเดียวก่อน แพลตฟอร์มเดียวกันก่อน และชะลอการเขียนข้อมูลข้ามบริษัท” การเชื่อมเอเจนต์ภายในแพลตฟอร์มคลาวด์เดียวกันลองได้ แต่ A2A ข้ามบริษัทสำหรับการสั่งซื้อและชำระเงินไม่ควรเปิดจนกว่ากรอบเรื่องตัวตน การมอบหมายสิทธิ์ และความรับผิดชอบจะชัดเจน เพราะในงานแบบลำดับขั้น ทุกรูปแบบของระบบหลายเอเจนต์แย่ลง 39%–70% (ข้อมูล arXiv:2512.08296 v1/v2)

สถานะของ A2A ตอนนี้คล้าย HTTP ยุคแรกมาก: รูปแบบเป็นมาตรฐานแล้ว แต่ชั้นความไว้วางใจแต่ละฝ่ายยังต้องเติมเอง ความต่างคือคราวนี้ฝ่ายที่ถูกเรียกให้เหตุผลได้เอง และอาจถูกอีกฝ่ายโน้มน้าวได้ด้วย คอขวดจึงไม่ได้อยู่ที่วิศวกรรม แต่อยู่ที่ “ใครรับผิดชอบต่อพฤติกรรมของเอเจนต์” ซึ่งปัจจุบันกระจายอยู่ในมือ IETF (ตัวตน) FIDO Alliance (เจตนาการชำระเงิน) เครือข่ายบัตร (ข้อพิพาท) และหน่วยงานกำกับดูแลของแต่ละประเทศ ซึ่ง TSC ของ A2A ดูแลไม่ถึง จากนี้อนุมานได้ว่าในอีกไม่กี่ปีข้างหน้า รูปแบบการเชื่อมเอเจนต์ข้ามบริษัทที่น่าจะเกิดขึ้นที่สุดคือ “เปลือก A2A ที่ห่อการเรียกเครื่องมือแบบให้ผลแน่นอน” กล่าวคือฝ่ายที่ถูกเรียกดูภายนอกเป็นเอเจนต์ แต่ภายในคือ API และการให้เหตุผลจริงเกิดขึ้นภายในขอบเขตความไว้วางใจของตนเองเท่านั้น

แนวทางของภาครัฐก็สอดคล้องกัน CISA, NSA และหน่วยงานในกลุ่ม Five Eyes แนะนำให้เริ่มจากกรณีใช้งานความเสี่ยงต่ำที่ไม่อ่อนไหวและจำกัดสิทธิ์การเข้าถึง กรอบของ IMDA สิงคโปร์จัด “ให้มนุษย์รับผิดชอบอย่างแท้จริง” และการควบคุมทางเทคนิคเป็นมิติหลัก กระทรวงกิจการดิจิทัลไต้หวันจัดปฏิกิริยาลูกโซ่จากการที่เอเจนต์กระตุ้นกันเองเป็นความเสี่ยง B6 ส่วน CMA สหราชอาณาจักรระบุตรง ๆ ว่าผู้ประกอบการต้องรับผิดชอบต่อการกระทำผิดกฎหมายของเอเจนต์ที่ตนใช้

ตารางด้านล่างจัดระดับทางเลือกการนำไปใช้สำหรับองค์กรทั่วไปตามความหนักแน่นของหลักฐาน “ทำ” หมายถึงภายใต้หลักฐานที่มี ความเสี่ยงต่ำและผลตอบแทนชัดเจน “ทำได้” หมายถึงต้นทุนต่ำแต่ยังไม่มีกรณีที่วัดผล ส่วน “ชะลอ” และ “ไม่ควรทำ” มีเหตุผลกำกับ และจะประเมินใหม่เมื่อเงื่อนไขกระตุ้นเกิดขึ้น

ระดับคำแนะนำการนำ A2A มาใช้ในองค์กร (2026-10-31)
คำแนะนำการดำเนินการเหตุผล
ทำพัฒนาการอนุญาตสิทธิ์เองและตั้งค่าเริ่มต้นเป็นปฏิเสธ ไม่พึ่งค่าเริ่มต้นของ SDKข้อกำหนดบอกว่าการอนุญาตสิทธิ์ขึ้นกับการพัฒนา; a2a-java เคยไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น (CVE-2026-111764)
ทำถือว่าทุกฟิลด์ของ Agent Card และ URL การแจ้งเตือนแบบพุชเป็นอินพุตที่ไม่น่าเชื่อถือ และปฏิเสธ IP ส่วนตัวใน URL การแจ้งเตือนแบบพุชการ์ดกำหนดชื่อส่วนหัวได้; ทั้ง a2a-java และ a2a-python เคยเกิด SSRF ผ่านการแจ้งเตือนแบบพุช
ทำบันทึก taskId, contextId, ตัวตนของผู้เรียก และ traceparenttrace ข้ามเอเจนต์ขาดตอน (Issue #2103) ภายหลังกระทบยอดได้จากบันทึกของแต่ละฝ่ายเท่านั้น
ทำตรึงเวอร์ชัน SDK และติดตามประกาศด้านความปลอดภัยช่วงสิงหาคม–ตุลาคม 2026 มี CVE ของ SDK ทางการหลายรายการ และแพตช์เคยถูกเลี่ยงเพราะความต่างของแพลตฟอร์ม
ทำได้เชื่อมเอเจนต์ภายในแพลตฟอร์มคลาวด์เดียวกัน (AWS AgentCore, Microsoft Foundry, Google Agent Registry)เป็นรูปแบบที่ใช้งานจริงในปัจจุบัน และทั้งสองฝ่ายมีขอบเขตความไว้วางใจเดียวกัน
ชะลอพึ่งการตรวจลายเซ็น Agent Card ข้าม SDKIssue #2122 การทำให้เป็นมาตรฐานไม่ตรงกัน; ลายเซ็นพิสูจน์ได้เพียงความครบถ้วน ไม่ใช่ตัวตน
ไม่ควรทำให้เอเจนต์ภายนอกสั่งซื้อ แก้ไขข้อมูล หรือชำระเงินแทนลูกค้าAP2 ไม่กำหนดความรับผิดชอบ เครือข่ายบัตรไม่มีกฎข้อพิพาทเฉพาะเอเจนต์ และ PSR ไม่พบบทบัญญัติเรื่องเอเจนต์
ไม่ควรทำสร้างแบ็กเอนด์หลายเอเจนต์ข้ามองค์กรเองเพื่อ A2Aระบบหลายเอเจนต์แบบอิสระขยายข้อผิดพลาด 17.2 เท่า; งานแบบลำดับขั้นแย่ลง 39%–70%

คำตอบ AI เพิ่มเติม: ถาม-ตอบเรื่องฝากส่งรวมพัสดุ พิกัดศุลกากร และอีคอมเมิร์ซข้ามพรมแดน

แหล่งอ้างอิง Kim et al., Towards a Science of Scaling Agent Systems (arXiv:2512.08296)| CISA: Secure adoption of agentic AI| IMDA: Model AI Governance Framework for Agentic AI v1.5| กระทรวงกิจการดิจิทัล: กรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์ v1.0 (PDF)| GOV.UK: CMA complying with consumer law when using AI agents| GitHub Advisory GHSA-qw47-mcm5-934w| A2A Issue #2103| A2A Issue #2122| AP2 v0.2 Specification

ผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ควรเตรียมรับ A2A อย่างไร?

ในปี 2026 สิ่งที่ผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ควรลงทุนที่สุดไม่ใช่เอนด์พอยต์ A2A แต่เป็นข้อมูลมีโครงสร้างบนหน้าเว็บและเครื่องมือ MCP แบบอ่านอย่างเดียวที่ให้ผลแน่นอน แหล่งข้อมูลทุติยภูมิอ้างข้อมูล Cloudflare Radar เดือนสิงหาคม 2026 ว่าบอต AI คิดเป็นราว 7% ของคำขอ HTML ในจำนวนนี้การกระทำแบบเรียลไทม์แทนผู้ใช้มีเพียง 5.8% และการที่ Flexport ให้ผู้ช่วย AI ของลูกค้าจองระวางขนส่งก็ใช้ MCP

คำถามหลักของอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ — ค่าขนส่งเท่าไร ภาษีและค่าธรรมเนียมเท่าไร พิกัดศุลกากรและข้อกำหนดการนำเข้าของสินค้านี้คืออะไร — โดยธรรมชาติเป็นการคำนวณที่ให้ผลแน่นอน ซึ่งเป็นบริการที่เอเจนต์ภายนอกต้องการมากที่สุดและผิดพลาดได้ยากที่สุด ประสบการณ์จากบล็อกวิศวกรรมของ Anthropic คือ แค่เขียนคำอธิบายเครื่องมือใหม่ก็ทำให้เวลาที่เอเจนต์ซึ่งเรียกใช้ในภายหลังใช้ทำงานให้เสร็จลดลง 40% ส่วนประสบการณ์ที่ OpenAI ย้าย Instant Checkout กลับไปเป็น Apps ของร้านค้า แสดงว่าธุรกรรมสุดท้ายแล้วจะกลับไปสู่ขั้นตอนของร้านค้าเอง ลำดับการเตรียมตัวของผู้ประกอบการจึงควรเป็น: ทำให้หน้าเว็บและข้อมูลมีโครงสร้างอ่านได้ก่อน แล้วทำเครื่องมือที่ให้ผลแน่นอนเป็น MCP แนบ URL สำหรับทำต่อในผลตอบกลับของเครื่องมือเพื่อพาธุรกรรมกลับสู่ขั้นตอนของตน และสุดท้ายจึงพิจารณาจองที่ไว้สำหรับ A2A

การ์ดจองที่ A2A หมายถึง การเผยแพร่การ์ดที่ /.well-known/agent-card.json โดย skills สอดคล้องกับเครื่องมือที่ให้ผลแน่นอนซึ่งมีอยู่แล้ว เช่น การเสนอราคา ภาษีและค่าธรรมเนียม และขั้นตอนบริการ เบื้องหลังเรียกโปรแกรมโดยตรงโดยไม่รัน LLM วิธีนี้ต้นทุนต่ำและมี “มูลค่าแบบสิทธิเลือก” แต่ขณะนี้ยังไม่มีกรณีที่วัดผลได้ว่า SME ได้ทราฟฟิกหรือรายได้เพิ่มจากสิ่งนี้ ซึ่งเป็นการอนุมาน หากจะเปิดเอนด์พอยต์ A2A จริง อย่างน้อยต้องทำให้ได้ว่า: เปิดเฉพาะทักษะแบบอ่านอย่างเดียว ไม่เชื่อฟิลด์ใดในการ์ดของอีกฝ่าย ปฏิเสธ IP ส่วนตัวใน URL การแจ้งเตือนแบบพุช และบันทึก taskId, contextId, ตัวตนของผู้เรียก และ traceparent

แนวทางปัจจุบันของ HowBridge (ข้อมูลต่อไปนี้ตรวจสอบได้ในหน้านักพัฒนาของ HowBridge): HowBridge ให้บริการ MCP สาธารณะที่ไม่ต้องใช้คีย์และไม่ต้องใช้ OAuth (https://0523.tw/mcp/public) มีเครื่องมือแบบอ่านอย่างเดียวและ idempotent 8 รายการ ครอบคลุมข้อมูลแบรนด์และบริการของ HowBridge การคำนวณค่าขนส่งฝากส่งรวมพัสดุจีน→ไต้หวัน (Sea Express/ทางอากาศ) การคำนวณภาษีและค่าธรรมเนียมนำเข้าไต้หวัน การค้นหาพิกัดศุลกากร CCC ที่เป็นไปได้จากชื่อสินค้า อัตราภาษีและข้อกำหนดการนำเข้าตามพิกัด CCC ค่าธรรมเนียมพัสดุเกินขนาดสำหรับการจัดส่งช่วงในไต้หวัน รวมถึงขั้นตอนฝากส่งรวมพัสดุและข้อกำหนดการสำแดงแบบย่อ จำกัด 120 ครั้งต่อนาทีต่อ IP และลงทะเบียนใน MCP Registry ทางการแล้ว (ชื่อ tw.0523/lucky-public) ผลตอบกลับของการคำนวณค่าขนส่งมี URL สำหรับทำต่อ (continue_url) ให้ผู้ใช้กลับไปทำต่อบนเว็บไซต์ทางการ ส่วน MCP สำหรับสมาชิก (https://0523.tw/mcp) ใช้การอนุญาต OAuth 2.1 มีเครื่องมือแบบอ่านอย่างเดียว 6 รายการ อ่านได้เฉพาะใบแจ้งหนี้ พัสดุ การแจ้งล่วงหน้า ใบแจ้งภาษี และใบขนสินค้าขาเข้าของสมาชิกที่ให้อนุญาตเท่านั้น ค่าเริ่มต้น 60 ครั้งต่อนาทีและ 5,000 ครั้งต่อวัน ช่องทางที่หน้านักพัฒนาของ HowBridge ระบุในปัจจุบันคือ API ข้อมูลสมาชิก MCP สำหรับสมาชิก และ MCP สาธารณะ ไม่มีเอนด์พอยต์ A2A บทความนี้ไม่ได้หมายความว่า HowBridge รองรับ A2A แล้ว

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

ระดับการเตรียมรับ A2A สำหรับผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ (2026-10-31)
ลำดับความสำคัญการดำเนินการคำแนะนำเหตุผล
1เสริมเนื้อหาหน้าเว็บและข้อมูลมีโครงสร้าง schema.org อย่างต่อเนื่องทำวิธีหลักที่เอเจนต์เข้าถึงเว็บไซต์ยังคงเป็นการเรียกดูและดึงข้อมูล สัดส่วนทราฟฟิกที่เป็นการกระทำแบบเรียลไทม์แทนผู้ใช้ยังน้อยมาก
2ทำฟังก์ชันเสนอราคา ภาษีและค่าธรรมเนียม และพิกัดศุลกากรเป็นเครื่องมือ MCP แบบอ่านอย่างเดียวที่ให้ผลแน่นอน และขัดเกลาคำอธิบายเครื่องมือทำการเขียนคำอธิบายเครื่องมือใหม่ทำให้เวลาทำงานของเอเจนต์ลดลง 40%; เอเจนต์จองระวางในอุตสาหกรรมโลจิสติกส์ใช้ MCP
3แนบ URL สำหรับทำต่อในผลตอบกลับของเครื่องมือ เพื่อพาธุรกรรมกลับสู่ขั้นตอนของตนทำInstant Checkout ย้ายกลับไปเป็น Apps ของร้านค้าแล้ว ธุรกรรมกลับไปที่หน้าของร้านค้าเอง
4อินเทอร์เฟซข้อมูลสมาชิกยังคงใช้ OAuth และเพิ่มการจำกัดอัตราและบันทึกการตรวจสอบสำหรับแต่ละไคลเอนต์ทำข้อกำหนดมอบการอนุญาตสิทธิ์ให้การพัฒนา; Akamai เตือนว่าเอเจนต์ฉ้อโกงเพิ่มขึ้น
5เผยแพร่การ์ดจองที่ /.well-known/agent-card.json เบื้องหลังเชื่อมเฉพาะโปรแกรมที่ให้ผลแน่นอน ไม่รัน LLMทำได้ (ความสำคัญต่ำ)ต้นทุนต่ำ มีมูลค่าแบบสิทธิเลือก; ยังไม่มีกรณีที่วัดผล (การอนุมาน)
6เปิดเอนด์พอยต์ A2Aทำแบบมีเงื่อนไขเปิดเฉพาะอ่านอย่างเดียว; ไม่เชื่อฟิลด์ในการ์ด; ปฏิเสธ IP ส่วนตัวใน URL การแจ้งเตือนแบบพุช; บันทึกครบถ้วน (สอดคล้องกับ CVE แบบ SSRF และ fail-open ที่เปิดเผยแล้ว)
7ลงนาม Agent Cardชะลอ หรือใช้ SDK เพียงตัวเดียวIssue #2122 การทำให้เป็นมาตรฐานข้าม SDK ไม่ตรงกัน
8เปิดให้เอเจนต์ภายนอกสั่งซื้อ เปลี่ยนที่อยู่ หรือชำระเงินไม่ควรทำกรอบความรับผิดชอบยังไม่ชัด; ในงานแบบลำดับขั้น ระบบหลายเอเจนต์แย่ลง 39%–70%
9สร้างแบ็กเอนด์หลายเอเจนต์เองเพื่อ A2A หรือเชื่อม AP2/x402 เพื่อเก็บค่าขนส่งไม่ควรทำปริมาณการค้าจริงของ x402 น้อยมาก; ไม่พบตัวอย่างการชำระค่าขนส่ง

แพลตฟอร์มนักพัฒนา HowBridge: MCP สาธารณะและ MCP สำหรับสมาชิก ・ บทสอน MCP สำหรับฝากส่งรวมพัสดุ: ให้ Claude และ ChatGPT เช็กค่าขนส่งและภาษี ・ เครื่องคำนวณค่าขนส่งฝากส่งรวมพัสดุ: ค่า Sea Express และทางอากาศจากจีนมาไต้หวัน ・ เครื่องคำนวณภาษีนำเข้า: คำนวณอากรขาเข้า ภาษีการค้า และภาษีสินค้า ・ ค้นหาพิกัดศุลกากร: พิมพ์ชื่อสินค้าภาษาจีนเพื่อค้นรหัส CCC และอัตราภาษี

แหล่งอ้างอิง PaidHosting: AI agent traffic (อ้างอิง Cloudflare Radar)| HUMAN Security: 2026 State of AI Traffic| SupplyChain247: ผู้ช่วย AI ของ Flexport จองระวางขนส่ง| Anthropic Engineering: How we built our multi-agent research system| Digital Commerce 360 (2026-03-06)| ข่าวประชาสัมพันธ์ของ Akamai| A2A Specification| แพลตฟอร์มนักพัฒนา HowBridge (คำอธิบาย MCP สาธารณะและ MCP สำหรับสมาชิก)

5 ขั้นตอนสำหรับผู้ประกอบการอีคอมเมิร์ซข้ามพรมแดนและโลจิสติกส์ในการเตรียมรับการเชื่อมต่อเอเจนต์ AI

1ทำให้หน้าเว็บอ่านได้ก่อน

เขียนข้อเท็จจริงสำคัญ เช่น ราคา ระยะเวลา และกฎเกณฑ์ ไว้ใน HTML ที่เซิร์ฟเวอร์ส่งออกโดยตรง และเพิ่มข้อมูลมีโครงสร้าง schema.org เพราะวิธีหลักที่เอเจนต์เข้าถึงเว็บไซต์ยังคงเป็นการเรียกดูและดึงข้อมูล

2ทำฟังก์ชันที่ให้ผลแน่นอนเป็นเครื่องมือ MCP

ทำการสอบถามราคา ภาษีและค่าธรรมเนียม และพิกัดศุลกากรเป็นเครื่องมือ MCP แบบอ่านอย่างเดียวและ idempotent เขียนคำอธิบายเครื่องมือให้ชัดเรื่องหน่วยของอินพุตและข้อจำกัด และแนบ URL สำหรับทำต่อในผลตอบกลับเพื่อพาผู้ใช้กลับสู่ขั้นตอนของตน

3ข้อมูลสมาชิกใช้ OAuth และจำกัดอัตรา

อินเทอร์เฟซที่เกี่ยวข้องกับข้อมูลส่วนบุคคลใช้การอนุญาต OAuth เท่านั้น ส่งคืนเฉพาะข้อมูลของเจ้าของ และเพิ่มการจำกัดอัตราและบันทึกการตรวจสอบสำหรับแต่ละไคลเอนต์

4ประเมินการ์ดจองที่ A2A

หากต้องการลองหยั่งเชิง ให้เผยแพร่การ์ดที่ /.well-known/agent-card.json ซึ่งสอดคล้องเฉพาะเครื่องมือที่ให้ผลแน่นอนและเบื้องหลังไม่รัน LLM ก่อนเปิดใช้ให้ตรวจการตรวจสอบอินพุตของ URL การแจ้งเตือนแบบพุชและฟิลด์ของการ์ด

5ทดสอบซ้ำทุกไตรมาสและรอเงื่อนไขกระตุ้น

ทุกไตรมาสส่งคำขอ well-known ไปยังผู้ประกอบการในธุรกิจเดียวกันหรือแพลตฟอร์ม 10–20 ราย ก่อนที่คู่ค้าที่ระบุชื่อจะร้องขอเป็นลายลักษณ์อักษร v1.1 จะได้ข้อสรุป หรือกรอบความรับผิดชอบจะเกิดขึ้น อย่าเปิดการสั่งซื้อและการชำระเงิน

อภิธานศัพท์

A2A (Agent2Agent)
โปรโตคอลเปิดที่ให้เอเจนต์ AI ซึ่งอยู่ต่างองค์กรและต่างเฟรมเวิร์กค้นพบความสามารถของกันและกัน มอบหมายงาน และแลกเปลี่ยนผลลัพธ์ อยู่ในความดูแลของ Linux Foundation ตั้งแต่ 2025-06
MCP (Model Context Protocol)
โปรโตคอลเปิดที่ให้ผู้ช่วย AI เรียกใช้เครื่องมือและทรัพยากรภายนอก โดย LLM ฝั่งผู้เรียกควบคุมการให้เหตุผล และ schema ของเครื่องมือโปร่งใสต่อผู้เรียก
Agent Card
ไฟล์คำอธิบายสาธารณะของเอเจนต์ A2A ประกาศทักษะ อินเทอร์เฟซ และวิธียืนยันตัวตน ตามธรรมเนียมวางไว้ที่ /.well-known/agent-card.json ลายเซ็นเป็นทางเลือก
Task (งาน)
หน่วยงานของการทำงานร่วมกันหนึ่งครั้งใน A2A โดย taskId สร้างโดยเซิร์ฟเวอร์ และมีสถานะ เช่น ส่งแล้ว กำลังดำเนินการ ต้องการอินพุต ต้องการการอนุญาต เสร็จสิ้น และล้มเหลว
Extension (ส่วนขยาย)
กลไกเพิ่มฟังก์ชันนอกเหนือแกนหลักของ A2A ระบุด้วย URI ไคลเอนต์เปิดใช้ด้วยส่วนหัว A2A-Extensions และห้ามแก้โครงสร้างข้อมูลแกนหลัก
AP2 (Agent Payments Protocol)
โปรโตคอลที่ใช้ mandate แบบ SD-JWT บันทึกการอนุญาตให้เอเจนต์ชำระเงินของผู้ใช้ v0.2.0 เผยแพร่เมื่อ 2026-04-28 และโอนให้ FIDO Alliance เมื่อ 2026-04-29
x402
โปรโตคอลชำระเงินย่อยระหว่างเครื่องที่อิงรหัสสถานะ HTTP 402 “ต้องชำระเงิน” ส่วนใหญ่ชำระบนเชน Base
RFC 8693 token exchange
มาตรฐานการแลกเปลี่ยนโทเค็นของ OAuth 2.0 ใช้ act claim บันทึกเส้นทางการมอบหมาย และใช้ may_act จำกัดทอดถัดไปได้
SSRF (การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์)
ช่องโหว่ที่หลอกให้เซิร์ฟเวอร์ส่งคำขอไปยังที่อยู่ที่ผู้โจมตีกำหนด webhook URL ของการแจ้งเตือนแบบพุชใน A2A เป็นช่องทางที่พบบ่อย
TSC (คณะกรรมการกำกับทิศทางทางเทคนิค)
องค์กรตัดสินใจของ A2A มี 9 ที่นั่ง บริษัทละหนึ่งที่นั่ง ข้อเสนอลงมติด้วย gitvote บน GitHub issue
AIP (โปรโตคอลการเชื่อมต่อระหว่างเอเจนต์)
ชื่อโปรโตคอลเชื่อมต่อเอเจนต์ที่ใช้ในชุดเอกสารมาตรฐานแห่งชาติจีน GB/Z 185-2026 ยังไม่ได้รับการยืนยันว่าเข้ากันได้กับ A2A หรือไม่

คำถามที่พบบ่อย

ใครเป็นผู้พัฒนาโปรโตคอล A2A?

A2A เปิดตัวโดย Google ในเดือนเมษายน 2025 และโอนให้ Linux Foundation ดูแลเมื่อ 2025-06-23 สมาชิกผู้ก่อตั้งมี 7 บริษัท เช่น AWS, Cisco, Microsoft ปัจจุบันตัดสินใจโดยคณะกรรมการกำกับทิศทางทางเทคนิค 9 ที่นั่ง และในเดือนสิงหาคม 2026 ได้เข้าร่วม AAIF ซึ่งเป็นมูลนิธิเดียวกับ MCP

A2A เวอร์ชันล่าสุดคือเวอร์ชันใด?

ณ วันที่ 2026-10-31 เวอร์ชันปัจจุบันของ A2A คือ v1.0.1 เผยแพร่เมื่อ 2026-05-26 และเข้ากันได้ในระดับสายกับ v1.0.0 เมื่อ 2026-03-12 ส่วน v1.1 ผ่านแปดหัวข้อแล้วแต่ยังไม่มีวันเผยแพร่

ใช้ A2A กับ MCP ร่วมกันได้ไหม?

ได้ ตัวอย่างทางการของ A2A คือเอเจนต์ทำงานร่วมกันผ่าน A2A และแต่ละเอเจนต์ใช้ MCP ควบคุมเครื่องมือของตนเอง ทั้งสองดูแลส่วนเอเจนต์ต่อเอเจนต์และเอเจนต์ต่อเครื่องมือตามลำดับ จึงไม่ได้ขัดแย้งกันและใช้ร่วมกันได้

A2A มีช่องโหว่ด้านความปลอดภัยที่ทราบแล้วอะไรบ้าง?

ช่วงสิงหาคม–ตุลาคม 2026 มี CVE ชุดแรกของ SDK ทางการ รวมถึง a2a-java ที่ไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น (CVE-2026-111764, CVSS 7.5) และ SSRF ผ่านการแจ้งเตือนแบบพุชของ a2a-python (CVE-2026-90790) นอกจากนี้งานวิจัยทางวิชาการยังพบช่องโหว่ระดับโปรโตคอล 11 รายการที่ใช้ประโยชน์ได้แม้ปฏิบัติตามข้อกำหนด

เอเจนต์ AI รูดบัตรชำระเงินเองได้ไหม?

ทางเทคนิคทำได้ Visa ประกาศเมื่อ 2026-07-02 ว่าในยุโรปมีเอเจนต์ทำการซื้อสำเร็จแล้ว แต่ธุรกรรมยังใช้ Payment Passkeys ให้ผู้ถือบัตรยืนยันตัวตนแบบเข้มงวด สเปก AP2 ไม่กำหนดความรับผิดชอบกรณีข้อพิพาท และ PSR ของสหภาพยุโรปก็ยังไม่ได้ลงใน Official Journal

ไต้หวันมีกฎหมายกำกับเอเจนต์ AI หรือไม่?

กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ของไต้หวันประกาศและมีผลบังคับใช้เมื่อ 2026-01-14 แต่ไม่ได้กล่าวถึง “เอเจนต์” กรอบการจำแนกความเสี่ยง v1.0 ของกระทรวงกิจการดิจิทัลจัด “พฤติกรรมเกินขอบเขตการอนุญาตของเอเจนต์ AI อัตโนมัติ” เป็นความเสี่ยง B6 ส่วนการกำหนดความรับผิดชอบรอระเบียบประกอบตามมาตรา 17

HowBridge รองรับ A2A หรือไม่?

หน้านักพัฒนาของ HowBridge ปัจจุบันระบุ API ข้อมูลสมาชิก MCP สำหรับสมาชิก และ MCP สาธารณะที่ไม่ต้องใช้คีย์ ไม่มีเอนด์พอยต์ A2A ส่วน MCP สาธารณะมีเครื่องมือคำนวณแบบอ่านอย่างเดียว เช่น ค่าขนส่ง ภาษีและค่าธรรมเนียมนำเข้า และพิกัดศุลกากร CCC

มาตรฐานแห่งชาติจีนเรื่องการเชื่อมต่อระหว่างเอเจนต์เหมือนกับ A2A หรือไม่?

ยังยืนยันไม่ได้ ชุด GB/Z 185.1～185.7-2026 จำนวน 7 ฉบับอนุมัติและเผยแพร่เมื่อ 2026-05-22 ชื่อโปรโตคอลทางการคือ AIP หน้าเว็บทางการที่ตรวจพบไม่ได้กล่าวถึง A2A หรือ MCP และยังไม่ได้รับการยืนยันว่าเข้ากันได้หรือไม่

ข้อมูลสำคัญ

เวอร์ชันปัจจุบันของ A2A v1.0.1 เผยแพร่ 2026-05-26 (A2A CHANGELOG)
จำนวนที่นั่ง TSC 9 ที่นั่ง บริษัทละหนึ่งที่นั่ง (A2A GOVERNANCE.md)
จำนวน repo บน GitHub: MCP ต่อ A2A 40,675 ต่อ 622 topic mcp-server และ a2a-protocol (gravity.fast)
Agent Card ที่ใช้ได้จากการทดสอบจริง 0 ใบ 2026-10-27 คำขอ 36 ครั้งไปยัง 18 องค์กร (heym.run กลุ่มตัวอย่างเลือกเอง)
a2a-java CVE-2026-111764 CVSS 7.5 ไม่ตรวจสิทธิ์การอ่านเป็นค่าเริ่มต้น (GitHub Advisory)
ช่องโหว่ใหม่ที่ A2ABreak พบ 11 รายการ ใช้ประโยชน์ได้แม้ปฏิบัติตามข้อกำหนด (arXiv:2609.10871)
ระบบหลายเอเจนต์แย่ลงในงานแบบลำดับขั้น 39%–70% arXiv:2512.08296 v1/v2 และบล็อกของ Google (180 การตั้งค่า)
เอกสารมาตรฐานแห่งชาติจีนเรื่องการเชื่อมต่อระหว่างเอเจนต์ 7 ฉบับ GB/Z 185.1～185.7-2026 อนุมัติและเผยแพร่ 2026-05-22

เหตุการณ์สำคัญของ A2A

  1. Google เปิดตัว A2A พร้อมพันธมิตรกว่า 50 ราย (แหล่งข้อมูลทุติยภูมิ)
  2. A2A 0.2.2: ปรับให้ตรงกับ JSON-RPC แบบทำลายความเข้ากันได้ และเพิ่ม extensions
  3. Linux Foundation ประกาศรับช่วงโครงการ A2A
  4. A2A 0.3.0: agent.json เปลี่ยนชื่อเป็น agent-card.json เพิ่มลายเซ็นการ์ดและ mTLS
  5. IBM ACP รวมเข้ากับ A2A และ ACP หยุดพัฒนา
  6. กฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ของไต้หวันประกาศและมีผลบังคับใช้
  7. A2A v1.0.0 เผยแพร่ (มีงานวิจัยอีกชิ้นระบุมกราคม 2026)
  8. AP2 v0.2.0 เผยแพร่ วันถัดมา Google มอบ AP2 ให้ FIDO Alliance
  9. จีนอนุมัติและเผยแพร่ชุดการเชื่อมต่อระหว่างเอเจนต์ GB/Z 185.1～185.7-2026 จำนวน 7 ฉบับ
  10. A2A v1.0.1 เผยแพร่
  11. TSC ผ่านแปดหัวข้อของ v1.1 ด้วยคะแนน 5 ต่อ 0
  12. กระทรวงกิจการดิจิทัลไต้หวันประกาศกรอบการจำแนกความเสี่ยงของปัญญาประดิษฐ์ v1.0 และระบุความเสี่ยง B6
  13. MCP ฉบับ 2026-07-28 เปลี่ยนเป็นไร้สถานะ และย้าย Tasks เป็นส่วนขยายทางการ
  14. วันที่ A2A เข้าร่วม AAIF ตามที่ AAIF และ Axios บันทึก
  15. วันที่เข้าร่วม AAIF ตามบล็อกทางการของ A2A (ระบุคู่กับ 08-17)
  16. เปิดตัว a2a CLI ทางการ
  17. NIST เผยแพร่บล็อกหลักการออกแบบ 10 ข้อสำหรับระบบจัดการตัวตนของเอเจนต์
  18. คณะมนตรีสหภาพยุโรปรับรองจุดยืนวาระแรกของ PSD3/PSR (ยังไม่ลง Official Journal)

สัญญาณที่เราติดตามอย่างต่อเนื่อง

  • มีคู่ค้า B2B ที่ระบุชื่อ (แพลตฟอร์มอีคอมเมิร์ซ ผู้ขนส่ง คลังสินค้า หรือผู้ให้บริการด้านพิธีการศุลกากร) ร้องขอการเชื่อมต่อ A2A เป็นลายลักษณ์อักษร ณ วันที่ 2026-10-31 A2A ข้ามองค์กรยังไม่มีกรณีที่ระบุชื่อเลย นี่จึงเป็นสัญญาณที่แข็งแรงที่สุด
  • ChatGPT, Gemini หรือ Claude ประกาศอย่างเป็นทางการว่าใช้ A2A เรียกเอเจนต์ของร้านค้าบุคคลที่สาม ปัจจุบันทั้งสามรายยังไม่ได้ทำเช่นนั้น และ Anthropic ก็ยังไม่รองรับ A2A โดยกำเนิด
  • A2A v1.1 เผยแพร่อย่างเป็นทางการโดยรวมการค้นพบวิธียืนยันตัวตน (#1990) และความเป็น idempotent (#1987) หรือส่วนขยายด้านตัวตนของเอเจนต์และการมอบหมายสิทธิ์ได้ข้อสรุปอย่างเป็นทางการ
  • Issue #2122 ถูกปิด และเวกเตอร์ทดสอบลายเซ็นของ TCK ผ่านใน SDK ทั้งสามภาษา Python, JS, Go
  • เครือข่ายบัตรประกาศรหัสเหตุผล chargeback เฉพาะสำหรับเอเจนต์ หรือ PSD3/PSR ของสหภาพยุโรปผ่านวาระที่สองของรัฐสภายุโรป ลงใน Official Journal และมีบทบัญญัติเรื่องเอเจนต์ (ณ วันที่ 2026-10-31 คณะมนตรีเพิ่งรับรองจุดยืนวาระแรก และบันทึกเหตุผลของ PSR ไม่พบบทบัญญัติเรื่องเอเจนต์)
  • Google Agent Registry, Microsoft Agent 365 หรือ MCP Registry เปิดให้ลงทะเบียนสาธารณะข้ามองค์กร หรือร่างอย่าง DNS-AID ได้รับการรับเข้าเป็นร่างของคณะทำงาน IETF
  • มีการเปิดเผยความเข้ากันได้หรือการพัฒนาระหว่างชุด GB/Z 185 (AIP) ของจีนกับ A2A หรือแพลตฟอร์มลงทะเบียนเอเจนต์เปิดใช้งานและมีคู่ค้าข้ามพรมแดนระหว่างจีนกับไต้หวันเริ่มนำไปใช้
  • ไต้หวันออกระเบียบการกำหนดความรับผิดชอบของ AI ความเสี่ยงสูงตามมาตรา 17 ของกฎหมายพื้นฐานว่าด้วยปัญญาประดิษฐ์ หรือสภาบริหารกำหนดวันมีผลบังคับใช้ของบทบัญญัติที่แก้ไขเมื่อ 114-11-11 (2025-11-11) ของกฎหมายคุ้มครองข้อมูลส่วนบุคคล
  • TSC ของ A2A ปรับองค์ประกอบหลังจัดตั้งครบ 18 เดือน (ราวเดือนธันวาคม 2026) ตามเอกสารการกำกับดูแล
  • ทุกไตรมาสทดสอบซ้ำผู้ประกอบการในธุรกิจเดียวกันหรือแพลตฟอร์ม 10–20 รายด้วยคำขอ well-known ตราบใดที่ Agent Card ที่ใช้ได้ยังเป็น 0 ใบ ก็ไม่มีเหตุผลที่จะลงทุนเพิ่ม

องค์กรและมาตรฐานที่กล่าวถึงในบทความ

เอกสารอ้างอิง

เอกสารภาครัฐและเอกสารทางการ

งานวิจัยทางวิชาการ

สเปกและแหล่งข้อมูลจากอุตสาหกรรม

ปรับปรุงล่าสุด เผยแพร่ครั้งแรก

บทความนี้เป็นการเรียบเรียงงานวิจัยทางเทคนิค ไม่ถือเป็นคำแนะนำด้านกฎหมาย ความปลอดภัยไซเบอร์ หรือการลงทุน สเปกและกฎระเบียบให้ยึดตามประกาศล่าสุดของแต่ละหน่วยงานและโครงการ

พร้อมเริ่มรวมพัสดุหรือยัง?

สมัครสมาชิก HowBridge Logistics ฟรี รับที่อยู่คลังสินค้าต่างประเทศ + บริการ 14 ภาษาทันที

สมัครสมาชิกฟรี

📦 คู่มือเส้นทางยอดนิยม

🛒 คู่มือการซื้อของในตลาด

📋 ศุลกากร / กฎระเบียบ

🏛️ แหล่งที่มาอย่างเป็นทางการ

🔎 อัตราภาษีสินค้ายอดนิยม

🚚 เปรียบเทียบบริการรวมพัสดุและค่าส่ง

🧮 ขั้นตอนพิธีการศุลกากรและคำนวณภาษี

⚠️ ของต้องห้ามและกฎการตรวจสอบ

💳 การชำระเงิน ภาษีธุรกิจ และการสำแดงแบบเป็นทางการ

L
HowBridge Logistics ผู้เชี่ยวชาญด้านศุลกากรและการขนส่ง
HowBridge (好運器資訊有限公司) (เลขทะเบียนนิติบุคคลไต้หวัน 57151105 ก่อตั้งเมื่อเดือนสิงหาคม ค.ศ. 2017) ให้บริการรวมพัสดุขนส่งข้ามพรมแดนจากจีนแผ่นดินใหญ่ไปไต้หวัน การดำเนินการสำแดงศุลกากรทำร่วมกับตัวแทนออกของพันธมิตรที่ได้รับการรับรอง AEO เรามีบริการลูกค้า 14 ภาษา ซิงค์ข้อมูลพิกัดอัตราภาษี CCC ของกรมศุลกากร และช่วยผู้รับยืนยันตัวตนด้วยชื่อจริงกับ EZWay สถิติของเราเอง (2026-08-01 ถึง 2026-09-30): จากใบสำแดงศุลกากรทางเรือ 692 รายการ มี 97.8% ได้รับการปล่อยสินค้าจากศุลกากรภายใน 24 ชั่วโมง ส่วนพัสดุด่วนทางเรือที่ส่งจากจีนและมีการลงนามรับในไต้หวันแล้ว 774 รายการ ค่ามัธยฐานคือ 6 วัน และ 90% ส่งถึงภายใน 9 วัน เนื้อหารวบรวมโดยกองบรรณาธิการจากประกาศของกรมศุลกากร กระทรวงการคลัง และกฎระเบียบปัจจุบัน เกี่ยวกับทีมงาน ->