โปรโตคอล Agent2Agent: สถาปัตยกรรม ความปลอดภัย และการเปรียบเทียบกับ MCP

Agent2Agent (A2A) คือโปรโตคอลแบบเปิดที่เปิดตัวโดย Google Cloud ในเดือนเมษายน 2025 และมอบให้ Linux Foundation ช่วยให้เอเจนต์ AI ที่สร้างบนเฟรมเวิร์กและผู้ให้บริการที่แตกต่างกันสามารถสื่อสาร มอบหมายงาน และแลกเปลี่ยนผลลัพธ์ผ่านอินเทอร์เฟซ HTTP/JSON ที่เป็นมาตรฐาน ในขณะที่ MCP แก้ปัญหาการเข้าถึงเครื่องมือ (LLM เรียก API ภายนอก) A2A แก้ปัญหาการประสานงาน: เอเจนต์หนึ่งมอบหมายงานย่อยทั้งหมดให้เอเจนต์เพียร์ผู้เชี่ยวชาญที่มีลูปการใช้เหตุผล หน่วยความจำ และเครื่องมือของตัวเอง GitHub repository a2aproject/A2A มีส่วนร่วมจากองค์กรมากกว่า 50 แห่ง รวมถึง Salesforce, Atlassian และ SAP

Agent2Agent (A2A) คือโปรโตคอล HTTP/JSON แบบเปิดสำหรับการทำงานร่วมกันของเอเจนต์ AI ที่ดูแลโดย Linux Foundation ซึ่งกำหนดมาตรฐานว่าเอเจนต์อิสระจะประกาศความสามารถ มอบหมายงาน และแลกเปลี่ยนผลลัพธ์ข้ามเฟรมเวิร์กและผู้ให้บริการต่างกันได้อย่างไร

โปรโตคอล Agent2Agent (A2A) คืออะไร?

A2A เกิดขึ้นจากช่องว่างในระบบนิเวศของเอเจนต์ AI: การสื่อสารระหว่างโมเดลกับเครื่องมือมีมาตรฐานแล้ว (MCP เปิดตัวในพฤศจิกายน 2024) แต่การสื่อสารระหว่างเอเจนต์กับเอเจนต์ยังไม่มี เมื่อเอเจนต์ออร์เคสเตรเตอร์ต้องส่งงานย่อยให้เพียร์ผู้เชี่ยวชาญ ยังไม่มีรูปแบบสายสัญญาณที่เป็นมาตรฐานสำหรับการมอบหมายนั้น

Google Cloud ประกาศ A2A เมื่อวันที่ 9 เมษายน 2025 พร้อมกลุ่มพันธมิตรด้านเทคโนโลยีเริ่มต้นมากกว่า 50 รายที่มีส่วนร่วมในข้อกำหนด ต่างจากมาตรฐานที่ขับเคลื่อนโดยผู้ขายหลายราย A2A ถูกมอบให้ Linux Foundation เพื่อการกำกับดูแลที่เป็นกลาง

โปรโตคอลนี้มีพื้นฐานเป็น HTTP/JSON เอเจนต์ที่รองรับ A2A เปิดเผยชุดปลายทางขนาดเล็ก: บัตรเอเจนต์ (ไฟล์แสดงความสามารถ) ปลายทางส่งงาน ปลายทางสำรวจสถานะ และปลายทางสตรีม SSE สำหรับงานที่ใช้เวลานาน

สำหรับบริบทเกี่ยวกับปัญหาการประสานงานหลายเอเจนต์ที่ A2A แก้ไข ดู สถาปัตยกรรมระบบหลายเอเจนต์ และ รูปแบบการประสานงานเอเจนต์ AI

สถาปัตยกรรมโปรโตคอล A2A

A2A กำหนดแนวคิดหลักสามประการ: บัตรเอเจนต์ (การค้นพบความสามารถ) วงจรชีวิตงาน (การติดตามการมอบหมายแบบมีสถานะ) และโหมดการส่ง (สตรีม SSE และ webhook push)

บัตรเอเจนต์: การประกาศความสามารถและความเสี่ยงในการระบุ

บัตรเอเจนต์คือเอกสาร JSON ที่ให้บริการที่ URL ที่รู้จัก (/.well-known/agent.json) ซึ่งอธิบายสิ่งที่เอเจนต์สามารถทำได้ บัตรเอเจนต์ขั้นต่ำประกอบด้วย:

{
  "name": "web-research-agent",
  "description": "ค้นคว้าหัวข้อโดยใช้การค้นหาเว็บและส่งคืนสรุปที่มีโครงสร้าง",
  "version": "1.0.0",
  "url": "https://agents.example.com/web-research",
  "skills": [
    {
      "id": "research_topic",
      "name": "ค้นคว้าหัวข้อ",
      "description": "ค้นหาหัวข้อบนเว็บและส่งคืนสรุปที่มีโครงสร้าง",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

บัตรเอเจนต์ช่วยให้ค้นพบความสามารถแบบไดนามิก แต่มีความเสี่ยงด้านความปลอดภัย: ใน A2A base profile บัตรเอเจนต์ไม่ได้รับการตรวจสอบสิทธิ์โดยค่าเริ่มต้น เปิดเผยพื้นที่ทักษะทั้งหมดให้ถูกระบุได้โดยไม่ต้องตรวจสอบสิทธิ์

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

วงจรชีวิตงาน: ห้าสถานะตั้งแต่ส่งจนเสร็จ

A2A กำหนดวงจรชีวิตห้าสถานะ:

1. submitted - เอเจนต์ระยะไกลได้รับงานแล้ว ยังไม่เริ่มประมวลผล
2. working - เอเจนต์ระยะไกลกำลังประมวลผลงานอย่างแข็งขัน (สามารถสตรีมความคืบหน้าผ่าน SSE)
3. input-required - เอเจนต์ระยะไกลต้องการการชี้แจงก่อนดำเนินการต่อ (จุดตรวจสอบของมนุษย์)
4. completed - งานเสร็จสมบูรณ์ สิ่งประดิษฐ์ผลลัพธ์พร้อมให้ดึงข้อมูล
5. failed - งานล้มเหลว รายละเอียดข้อผิดพลาดอยู่ในอ็อบเจ็กต์สถานะงาน

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

การส่งงานแบบ push กับ pull: SSE และ webhook

A2A รองรับสองโหมดการส่งผลลัพธ์งาน:

SSE (Server-Sent Events): เอเจนต์ที่มอบหมายเปิดการเชื่อมต่อถาวรไปยังปลายทางสตรีมของเอเจนต์ผู้รับ SSE คือกลไกหลักสำหรับงานที่ใช้เวลานานซึ่งต้องการความคืบหน้าแบบเพิ่มขึ้น

Webhook push: เอเจนต์ที่มอบหมายให้ callback URL เมื่อส่ง เหมาะสำหรับสภาพแวดล้อมแบบ serverless ที่ไม่สามารถรักษาการเชื่อมต่อ SSE ถาวรได้

A2A กับ MCP: ชั้นต่างกัน ปัญหาต่างกัน

A2A และ MCP เสริมกัน ไม่แข่งขันกัน ทำงานในชั้นต่างกันของสแต็กเอเจนต์และแก้ปัญหาการประสานงานต่างกัน

มิติ	MCP	A2A
วัตถุประสงค์	การเข้าถึงเครื่องมือ - LLM เรียก API ภายนอก	การประสานงานเอเจนต์ - เอเจนต์มอบหมายให้เอเจนต์อื่น
การสื่อสาร	การเรียกเครื่องมือแบบซิงโครนัสภายในรอบการใช้เหตุผลหนึ่งรอบ	การมอบหมายงานแบบอะซิงโครนัส เอเจนต์ผู้รับมีลูปของตัวเอง
การตรวจสอบสิทธิ์ (ค่าเริ่มต้น)	จำเป็น - เซิร์ฟเวอร์ MCP ตรวจสอบสิทธิ์ไคลเอนต์	ไม่บังคับใน base profile - อนุญาตการเข้าถึงแบบไม่ระบุตัวตน
การค้นพบ	ไฟล์แสดง MCP server (รายการเครื่องมือ)	บัตรเอเจนต์ (JSON: ทักษะ + ข้อกำหนดการตรวจสอบสิทธิ์)
สถานะ	ไม่มีสถานะต่อการเรียกเครื่องมือ	มีสถานะ วงจรชีวิต 5 สถานะ
การสตรีม	ไม่มีในข้อกำหนดหลัก	SSE แบบเรียลไทม์ webhook push สำหรับแบบอะซิงโครนัส
ภัยคุกคามหลัก	การวางยาพิษเครื่องมือ (OWASP LLM07:2025)	การฉีด payload งาน การระบุบัตรเอเจนต์

เมื่อเอเจนต์ต้องการเครื่องมือ (MCP)

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

เมื่อเอเจนต์ต้องการเอเจนต์อื่น (A2A)

A2A คือตัวเลือกที่ถูกต้องเมื่องานต้องการความสามารถในการใช้เหตุผลเต็มรูปแบบของเอเจนต์เพียร์ เอเจนต์ผู้รับมีโมเดล หน่วยความจำ การเข้าถึงเครื่องมือ และลูปการใช้เหตุผลหลายขั้นตอนของตัวเอง

ใช้ MCP และ A2A ร่วมกันในระบบเดียวกัน

ระบบหลายเอเจนต์ในสภาพแวดล้อมจริงมักใช้ทั้งสองอย่าง เอเจนต์ออร์เคสเตรเตอร์ใช้ A2A เพื่อมอบหมายให้เอเจนต์ผู้เชี่ยวชาญ ผู้เชี่ยวชาญแต่ละคนใช้ MCP สำหรับการเรียกเครื่องมือ

การตรวจสอบสิทธิ์ A2A และโมเดลความปลอดภัย

โมเดลความปลอดภัยของ A2A มีช่องว่างสำคัญ: base profile ทำให้การตรวจสอบสิทธิ์เป็นทางเลือก การฉีด prompt ผ่าน payload งาน A2A เป็นประเภทการโจมตีที่มีเอกสารสำหรับการใช้งาน A2A ที่ยอมรับงานจากผู้เรียกที่ไม่น่าเชื่อถือ

พื้นที่การโจมตีในระบบ A2A:

1. การฉีด payload งาน: คำอธิบายงานและข้อมูลอินพุตในการส่งงาน A2A อยู่ภายใต้การควบคุมของผู้ใช้

2. การระบุบัตรเอเจนต์: บัตรเอเจนต์ที่ไม่ได้รับการตรวจสอบสิทธิ์เปิดเผยพื้นที่ทักษะทั้งหมด

3. สมมติฐานความไว้วางใจระหว่างเอเจนต์: เอเจนต์มอบหมายที่เชื่อถือผลลัพธ์ของเอเจนต์เพียร์โดยไม่มีการตรวจสอบผลลัพธ์มีความเสี่ยงต่อการฉีดแบบถ่ายทอด

4. การมอบหมายแบบไม่ระบุตัวตน: หากไม่มีการตรวจสอบสิทธิ์ที่บังคับ ผู้เรียกใดก็ตามในเครือข่ายสามารถส่งงานให้เอเจนต์ A2A ได้

ความเห็นของ OpenLegion: A2A คือรูปแบบสาย ไม่ใช่โมเดลความปลอดภัย

A2A ได้รับการออกแบบมาอย่างดีในฐานะรูปแบบสาย โมเดลความปลอดภัยยังไม่เป็นไปตามข้อกำหนดสำหรับการใช้งานจริง

แนวทางของ OpenLegion สำหรับการสื่อสารระหว่างเอเจนต์บังคับใช้สิ่งที่ A2A base profile ปล่อยให้เป็นทางเลือก:

1. การเรียกระหว่างเอเจนต์ทุกครั้งถูกส่งผ่าน credential vault ไม่มีโหมดการมอบหมายแบบไม่ระบุตัวตน

2. การทำความสะอาด payload งานที่จุดคอขวดเครือข่าย 56 จุด เนื้อหาที่ผู้ใช้ควบคุมได้รับการทำความสะอาดจากการโจมตี unicode ก่อนที่จะถึงบริบท LLM

3. สัญญาการส่งงานแบบมีชนิดที่ออร์เคสเตรเตอร์ตรวจสอบ payload การฉีดแบบถ่ายทอดถูกบล็อกที่ขอบเขตการส่งงาน

4. ไฟล์แสดงความสามารถของเอเจนต์ต้องการการตรวจสอบสิทธิ์เพื่อเข้าถึง พื้นที่ทักษะไม่ได้เปิดเผยต่อผู้เรียกที่ไม่ระบุตัวตน

การนำ A2A ไปใช้: คู่มือทางเทคนิค

สคีมาบัตรเอเจนต์

บัตรเอเจนต์สำหรับการใช้งานจริงควรรวมข้อกำหนดการตรวจสอบสิทธิ์อย่างชัดเจน:

{
  "name": "data-analysis-agent",
  "description": "วิเคราะห์ชุดข้อมูลที่มีโครงสร้างและส่งคืนสรุปทางสถิติพร้อมภาพ",
  "version": "1.2.0",
  "url": "https://agents.internal.example.com/data-analysis",
  "skills": [
    {
      "id": "analyze_dataset",
      "name": "วิเคราะห์ชุดข้อมูล",
      "description": "เรียกใช้การวิเคราะห์ทางสถิติบนชุดข้อมูลที่ให้มา",
      "inputModes": ["data"],
      "outputModes": ["text", "data", "file"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"],
    "required": true
  }
}

การส่งงานและการสำรวจสถานะ

การส่งงานคือ POST ไปที่ /tasks/send การสำรวจสถานะใช้ GET /tasks/{task_id} สำรวจด้วย exponential backoff (1s, 2s, 4s, 8s, สูงสุด 30s) งานที่ใช้เวลานาน (>60s) ควรเปลี่ยนไปใช้ SSE

การสตรีมงานที่ใช้เวลานานด้วย SSE

สำหรับงานที่คาดว่าจะใช้เวลามากกว่า 30 วินาที ใช้ SSE ผ่าน POST /tasks/sendSubscribe แฟล็ก "final": true บอกสัญญาณการเสร็จสิ้นงาน นำการเชื่อมต่อ SSE ใหม่กลับมาพร้อมส่วนหัว Last-Event-ID เพื่อดำเนินการต่อหลังการตัดการเชื่อมต่อ

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

โปรโตคอล Agent2Agent (A2A) คืออะไร?

Agent2Agent (A2A) คือโปรโตคอล HTTP/JSON แบบเปิดสำหรับการทำงานร่วมกันของเอเจนต์ AI เปิดตัวโดย Google Cloud ในเดือนเมษายน 2025 และมอบให้ Linux Foundation กำหนดมาตรฐานว่าเอเจนต์อิสระที่สร้างบนเฟรมเวิร์กต่างกันจะประกาศความสามารถ มอบหมายงาน และแลกเปลี่ยนผลลัพธ์ได้อย่างไร องค์กรมากกว่า 50 แห่ง รวมถึง Salesforce, Atlassian และ SAP มีส่วนร่วมตั้งแต่เปิดตัวในเดือนเมษายน 2025

ความแตกต่างระหว่าง A2A และ MCP คืออะไร?

MCP แก้ปัญหาการเข้าถึงเครื่องมือ: เอเจนต์เดียวเรียก API ภายนอกภายในรอบการใช้เหตุผลเดียว A2A แก้ปัญหาการประสานงานเอเจนต์: เอเจนต์มอบหมายงานย่อยทั้งหมดให้เอเจนต์เพียร์ที่มีลูปการใช้เหตุผล หน่วยความจำ และเครื่องมือของตัวเอง MCP ต้องการการตรวจสอบสิทธิ์โดยค่าเริ่มต้น A2A base profile ทำให้เป็นทางเลือก ทั้งสองโปรโตคอลเสริมกัน

บัตรเอเจนต์ A2A คืออะไร?

บัตรเอเจนต์คือเอกสาร JSON ที่ให้บริการที่ /.well-known/agent.json ซึ่งอธิบายความสามารถ โหมดอินพุต/เอาต์พุตที่ยอมรับ และข้อกำหนดการตรวจสอบสิทธิ์ของเอเจนต์ โดยค่าเริ่มต้นใน A2A base profile จะให้บริการโดยไม่มีการตรวจสอบสิทธิ์ การใช้งานจริงควรกำหนดให้มีการตรวจสอบสิทธิ์เพื่อเข้าถึงบัตรเอเจนต์

โปรโตคอล A2A ปลอดภัยหรือไม่?

A2A base profile มีช่องว่างด้านความปลอดภัยที่สำคัญ การตรวจสอบสิทธิ์เป็นทางเลือกโดยค่าเริ่มต้น การฉีด prompt ผ่าน payload งาน A2A เป็นความเสี่ยงจริงในสภาพแวดล้อมจริง การใช้งาน A2A จริงต้องนำ extended authentication profile ไปใช้อย่างชัดเจน และทำความสะอาด payload งานทั้งหมดก่อน LLM

วงจรชีวิตงาน A2A คืออะไร?

A2A กำหนดห้าสถานะงาน: submitted (ได้รับแล้ว ยังไม่ประมวลผล), working (กำลังประมวลผล สามารถสตรีมความคืบหน้า SSE), input-required (เอเจนต์ระยะไกลต้องการการชี้แจงก่อนดำเนินการต่อ - จุดตรวจสอบของมนุษย์), completed (ผลลัพธ์พร้อม) และ failed (งานล้มเหลวพร้อมรายละเอียด) สถานะ input-required คือกลไกของ A2A สำหรับแสดงจุดตรวจสอบที่มีมนุษย์เข้าร่วมในไปป์ไลน์อัตโนมัติ

บริษัทใดบ้างที่สนับสนุน A2A?

A2A เปิดตัวในเดือนเมษายน 2025 พร้อมองค์กรที่มีส่วนร่วมมากกว่า 50 แห่ง รวมถึง Salesforce, Atlassian และ SAP Google Cloud นำข้อกำหนดเริ่มต้นและโอนการกำกับดูแลให้ Linux Foundation โปรโตคอลมุ่งเป้าไปที่แพลตฟอร์ม AI สำหรับองค์กรที่เอเจนต์จากเฟรมเวิร์กต่างกันต้องทำงานร่วมกัน

OpenLegion นำการสื่อสารระหว่างเอเจนต์ไปใช้อย่างไร?

สถาปัตยกรรม mesh ของ OpenLegion นำการประสานงานระหว่างเอเจนต์ไปใช้โดยมีการตรวจสอบสิทธิ์ที่บังคับในทุกการเรียก ไม่มีโหมดการมอบหมายแบบไม่ระบุตัวตน การส่งงานระหว่างเอเจนต์ทุกครั้งถูกส่งผ่าน credential vault เนื้อหา payload งานได้รับการทำความสะอาดที่จุดคอขวดเครือข่าย 56 จุด การควบคุมเหล่านี้ทำงานบนชั้นโครงสร้างพื้นฐาน ไม่ใช่โค้ดเอเจนต์

สร้างระบบหลายเอเจนต์ที่มีการตรวจสอบสิทธิ์ในทุกการเรียก

A2A ให้รูปแบบสายสัญญาณสำหรับการทำงานร่วมกันของเอเจนต์ข้ามเฟรมเวิร์กและผู้ให้บริการ โมเดลความปลอดภัยต้องสร้างไว้ด้านบนหรือบังคับใช้โดยชั้นโครงสร้างพื้นฐาน

ดู ความปลอดภัยเอเจนต์ AI และโมเดลภัยคุกคาม หรือ สถาปัตยกรรมระบบหลายเอเจนต์

เรียกใช้ระบบหลายเอเจนต์ที่การเรียกระหว่างเอเจนต์ทุกครั้งได้รับการตรวจสอบสิทธิ์ บันทึก และแยก credential โดยค่าเริ่มต้น บน OpenLegion