Agent2Agent (A2A) คืออะไร? โปรโตคอลเปิดสำหรับการสื่อสารเอเจนต์ AI

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

ลองใช้ Apidog วันนี้

คู่มือนี้อธิบายว่า A2A คืออะไร แก้ปัญหาอะไร ทำงานอย่างไร แตกต่างจาก MCP อย่างไร และควรเริ่มทดสอบเอเจนต์ A2A แบบเป็นขั้นตอนอย่างไร หากต้องการลงมือดีบักต่อหลังอ่านจบ ดูได้ที่ คู่มือ Apidog A2A Debugger

Agent2Agent (A2A) คืออะไร?

Agent2Agent (A2A) คือโปรโตคอลแบบเปิดสำหรับการสื่อสารระหว่างเอเจนต์ AI โดยกำหนดมาตรฐานว่า:

• เอเจนต์ประกาศความสามารถของตัวเองอย่างไร
• เอเจนต์อื่นค้นพบและเชื่อมต่อกับมันอย่างไร
• ทั้งสองฝ่ายแลกเปลี่ยนข้อความ ไฟล์ และข้อมูลที่มีโครงสร้างอย่างไร
• สถานะของงานถูกส่งกลับไปยังผู้เรียกอย่างไร

คำสำคัญคือ ระหว่าง เอเจนต์ A2A ไม่ได้ทำให้เอเจนต์หนึ่งมีเครื่องมือมากขึ้น แต่ทำให้เอเจนต์หลายตัวที่อาจสร้างด้วยเฟรมเวิร์กต่างกัน เช่น LangGraph, CrewAI, AutoGen หรือโค้ดที่เขียนเอง สามารถทำงานร่วมกันได้โดยไม่ต้องรู้รายละเอียดภายในของกันและกัน

มองง่ายๆ A2A คล้าย HTTP สำหรับการรับส่งงานระหว่างเอเจนต์ HTTP ทำให้เบราว์เซอร์คุยกับเว็บเซิร์ฟเวอร์ใดก็ได้โดยไม่ต้องรู้ว่าเซิร์ฟเวอร์เขียนด้วยภาษาอะไร A2A ทำให้เอเจนต์หนึ่งส่งงานให้อีกเอเจนต์ได้โดยสนใจแค่สัญญาข้อมูล ไม่ต้องรู้ implementation ภายใน

Google เปิดตัว A2A ในปี 2025 และต่อมาย้ายไปอยู่ภายใต้ Linux Foundation ในฐานะโครงการที่ไม่ขึ้นกับผู้ขายใดๆ ข้อมูลจำเพาะเปิดให้ดูได้ที่ ที่เก็บ A2A GitHub และมีการนำไปใช้งานอ้างอิงที่ เว็บไซต์โครงการ A2A

ปัญหาที่ A2A แก้ไข

ก่อนมี A2A การเชื่อมต่อเอเจนต์สองตัวมักหมายถึงการเขียน integration แบบเฉพาะกิจ เช่น:

1. ตกลง payload กันเอง
2. เขียน client สำหรับเอเจนต์ปลายทาง
3. สร้างระบบ auth เอง
4. กำหนดรูปแบบสถานะงานเอง
5. บำรุงรักษา integration นั้นแยกจาก integration อื่น

พอมีเอเจนต์หลายตัว ปัญหาจะโตเร็วมาก เพราะทุกคู่เชื่อมต่อกลายเป็นงาน custom ใหม่

ปัญหาหลักที่มักเจอคือ:

• ไม่มี discovery มาตรฐาน: เอเจนต์ผู้เรียกไม่รู้ว่าจะถามว่า “คุณทำอะไรได้บ้าง?” อย่างไร
• ไม่มี task model ร่วมกัน: บางเอเจนต์ส่ง string บางตัวส่ง JSON ที่กำหนดเอง บางตัว stream token ทำให้ client ต้องรองรับหลายรูปแบบ
• ไม่มี auth pattern ร่วมกัน: แต่ละ integration ต้องกำหนด header และ credential เอง
• ไม่มี interoperability: เอเจนต์ที่ทำหน้าที่เดียวกันแต่สร้างด้วยเฟรมเวิร์กต่างกันไม่สามารถสลับกันได้ง่าย

A2A แก้ปัญหานี้ด้วยแนวคิดเดียวกับที่ OpenAPI ช่วยให้ REST API ทำงานร่วมกันได้ดีขึ้น: ใช้สัญญาที่ตกลงร่วมกัน เพื่อให้เอเจนต์ที่ทำตามมาตรฐานสามารถคุยกับเอเจนต์อื่นที่ทำตามมาตรฐานเดียวกันได้

A2A ทำงานอย่างไร

A2A มีแนวคิดหลัก 4 ส่วน:

1. Agent Card
2. Tasks
3. Messages และ Artifacts
4. Streaming และ Status Updates

1. Agent Card

Agent Card คือเอกสาร JSON ที่เอเจนต์เผยแพร่เพื่ออธิบายตัวเอง โดยปกติจะอยู่ที่ path ที่รู้จักกันดี เช่น:

https://your-agent.example.com/.well-known/agent.json

Agent Card ใช้บอกข้อมูลสำคัญ เช่น:

• ชื่อเอเจนต์
• คำอธิบาย
• ความสามารถ
• ทักษะที่รองรับ
• ประเภท input/output
• วิธีตรวจสอบสิทธิ์
• เวอร์ชันโปรโตคอล

ตัวอย่างโครงสร้างแบบย่อ:

{
  "name": "Research Agent",
  "description": "ค้นคว้าและสรุปข้อมูลจากแหล่งอ้างอิง",
  "version": "1.0.0",
  "protocolVersion": "0.2.0",
  "capabilities": {
    "streaming": true
  },
  "skills": [
    {
      "id": "research_summary",
      "name": "Research Summary",
      "description": "ค้นคว้าหัวข้อและส่งคืนสรุปแบบมีโครงสร้าง"
    }
  ]
}

ขั้นตอนแรกของเอเจนต์ผู้เรียกจึงมักเป็นการดึง Agent Card ก่อน:

curl https://your-agent.example.com/.well-known/agent.json

จากนั้นจึงอ่านความสามารถและตัดสินใจว่าจะส่งงานรูปแบบใดได้บ้าง

2. งาน หรือ Tasks

Task คือหน่วยงานหนึ่งชิ้นใน A2A เมื่อเอเจนต์ A ขอให้เอเจนต์ B ทำบางอย่าง คำขอนั้นจะกลายเป็น task ที่มี ID เฉพาะและมีสถานะของตัวเอง

สถานะที่พบบ่อย เช่น:

• submitted
• working
• input-required
• completed

ประโยชน์ของ task model คือผู้เรียกสามารถจัดการ lifecycle ของงานได้แบบเดียวกัน ไม่ว่าเอเจนต์ปลายทางจะถูกสร้างด้วยเฟรมเวิร์กใด

ตัวอย่าง flow:

submitted -> working -> completed

หรือถ้าต้องการ input เพิ่ม:

submitted -> working -> input-required -> working -> completed

3. Messages และ Artifacts

Messages คือข้อมูลที่เอเจนต์ส่งหากัน อาจประกอบด้วย:

• ข้อความ
• ไฟล์
• structured data
• metadata
• หลายส่วนรวมกัน

เมื่อเอเจนต์ทำงานเสร็จ จะส่งผลลัพธ์กลับมาเป็น artifacts ซึ่งเป็น output ที่มีโครงสร้าง เช่น:

• รายงาน
• ตารางข้อมูล
• สรุป
• ไฟล์ที่สร้างขึ้น
• reference ไปยังไฟล์หรือ resource อื่น

แนวคิดสำคัญคือ input และ output ถูกห่อในรูปแบบที่สอดคล้องกัน ทำให้ client อ่านและแสดงผลได้ง่ายขึ้น

4. Streaming และ Status Updates

งานบางประเภทใช้เวลานาน เช่น research, code generation, data processing หรือ document generation A2A รองรับ server-sent events เพื่อให้เอเจนต์ปลายทางส่งความคืบหน้ากลับมาได้ระหว่างทำงาน

ตัวอย่างเช่น เอเจนต์วิจัยอาจส่งอัปเดตเป็นลำดับ:

working: เริ่มค้นหาแหล่งข้อมูล
working: พบแหล่งข้อมูล 3 แหล่ง
working: กำลังสรุปผล
completed: ส่งรายงานฉบับสมบูรณ์

ผู้เรียกจึงไม่ต้องรอแบบไม่มีข้อมูล แต่สามารถแสดง progress ใน UI หรือ log ได้

Flow พื้นฐานของ A2A

การเรียกใช้งาน A2A ทั่วไปมีลำดับประมาณนี้:

1. เอเจนต์ A ดึง Agent Card ของเอเจนต์ B
2. เอเจนต์ A อ่าน capabilities และ skills
3. เอเจนต์ A ส่ง message เพื่อสร้าง task
4. เอเจนต์ B ประมวลผลงาน
5. เอเจนต์ B ส่ง status update หรือ stream ความคืบหน้า
6. เอเจนต์ B ส่ง artifacts เมื่อ task เป็น completed
7. เอเจนต์ A อ่าน artifacts และทำขั้นตอนถัดไป

สรุปคือ A2A เป็น JSON ผ่าน HTTP ไม่มี runtime พิเศษที่ต้องผูกกับเฟรมเวิร์กใดเฟรมเวิร์กหนึ่ง

A2A เทียบกับ MCP

A2A และ Model Context Protocol หรือ MCP มักถูกเปรียบเทียบกัน เพราะทั้งสองเกี่ยวข้องกับเอเจนต์และเป็นโปรโตคอลแบบเปิด แต่ทั้งสองแก้ปัญหาคนละชั้น

	A2A	MCP
เชื่อมต่อ	เอเจนต์กับเอเจนต์	เอเจนต์กับเครื่องมือและข้อมูล
คำถามที่ตอบ	“เอเจนต์อื่นสามารถทำขั้นตอนนี้ให้ฉันได้หรือไม่?”	“เอเจนต์นี้สามารถเข้าถึงเครื่องมือและทรัพยากรอะไรได้บ้าง?”
การใช้งานทั่วไป	เวิร์กโฟลว์หลายเอเจนต์ข้ามทีม	เอเจนต์เดียวเรียกฐานข้อมูล ระบบไฟล์ หรือ API
หน่วยการแลกเปลี่ยน	งาน ข้อความ สิ่งประดิษฐ์	การเรียกใช้เครื่องมือ ทรัพยากร ข้อความแจ้ง

วิธีจำแบบสั้น:

• MCP คือวิธีที่เอเจนต์เข้าถึงระบบภายนอก เช่น database, filesystem หรือ API
• A2A คือวิธีที่เอเจนต์ส่งงานให้เอเจนต์อื่น

ระบบ production จำนวนมากอาจใช้ทั้งสองอย่างร่วมกัน เช่น:

1. เอเจนต์หลักรับคำขอจากผู้ใช้
2. ใช้ MCP เพื่อ query ฐานข้อมูล
3. ใช้ A2A เพื่อมอบหมายงานย่อยให้เอเจนต์ผู้เชี่ยวชาญ
4. รวมผลลัพธ์และตอบกลับผู้ใช้

อ่านเพิ่มเติมได้ที่ การเปรียบเทียบระหว่างเซิร์ฟเวอร์ MCP และ A2A และ ตัวดีบักไคลเอ็นต์ MCP ของ Apidog

การทำงานร่วมกันของหลายเอเจนต์ในโลกจริง

A2A เป็นวิธีหนึ่งในการทำให้เอเจนต์ทำงานร่วมกัน แต่ไม่ใช่วิธีเดียว บางระบบใช้การประสานงานโดยตรง โดยให้เอเจนต์หนึ่งทำหน้าที่วางแผนและมอบหมายงานให้เอเจนต์อื่นแบบชัดเจน

ตัวอย่างโอเพนซอร์สคือ Codex-Claude-Collab ซึ่งประสานเวิร์กโฟลว์แบบเรียลไทม์ระหว่าง OpenAI Codex และ Claude Code โดย Codex วางแผนงาน มอบหมาย implementation ให้ Claude Code จากนั้นตรวจ diff และยืนยันผลลัพธ์ก่อนตอบผู้ใช้

รูปแบบนี้คือการประสานงานแบบ hard-wired: ฝ่ายหนึ่งรู้แน่ชัดว่าอีกฝ่ายคือใคร

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

แนวทางเลือกใช้:

• ถ้าคุณควบคุมทั้งสองฝั่งและ integration คงที่: orchestration แบบตรงไปตรงมาอาจพอ
• ถ้าเอเจนต์เป็นของคนละทีม คนละระบบ หรือควรสลับ implementation ได้: ใช้ A2A
• ถ้าระบบเริ่มใหญ่: มักใช้ทั้ง orchestration ภายในทีม และ A2A ข้าม boundary ของทีม

วิธีทดสอบเอเจนต์ A2A

เมื่อสร้างหรือเชื่อมต่อเอเจนต์ A2A สิ่งที่ต้องตรวจสอบไม่ใช่แค่ “เอเจนต์ตอบถูกไหม” แต่ต้องดูด้วยว่า “payload ที่ส่งไปถูกต้องไหม”

สิ่งที่ควรทดสอบขั้นต่ำ:

1. Agent Card เปิดได้จาก URL ที่กำหนด
2. ฟิลด์สำคัญใน Agent Card ถูกต้อง
3. auth ทำงานตามที่ประกาศ
4. ส่งข้อความพื้นฐานได้
5. task status เปลี่ยนตาม lifecycle
6. artifacts ถูกส่งกลับในรูปแบบที่ client อ่านได้
7. streaming หรือ status update ทำงาน หากเปิดใช้

ตัวอย่างการตรวจสอบเบื้องต้นด้วย curl:

curl https://your-agent.example.com/.well-known/agent.json

จากนั้นส่ง message ทดสอบตาม endpoint และรูปแบบที่เอเจนต์รองรับ

อย่างไรก็ตาม เมื่อ payload เริ่มซับซ้อน การดู log อย่างเดียวมักไม่พอ เพราะอาจมองไม่เห็น field ที่หายไป type ที่ผิด หรือ metadata ที่ส่งผิดตำแหน่ง

Apidog มี A2A Debugger ในไคลเอ็นต์มาตรฐาน วิธีใช้งานหลักคือ:

1. วาง URL ของ Agent Card
2. คลิก Connect
3. ตรวจชื่อ ความสามารถ และ skills ของเอเจนต์
4. ส่งข้อความทดสอบ
5. แนบไฟล์หรือ metadata หากต้องการ
6. อ่านผลลัพธ์ในมุมมอง preview, raw content และ JSON-RPC payload

Apidog รองรับ Bearer Token, Basic Auth และ API-key header โดยไม่ต้องเขียน curl เองทุกครั้ง

ประโยชน์หลักคือการแยกปัญหาให้ง่ายขึ้น:

• ถ้า payload ผิด แก้ที่ integration
• ถ้า payload ถูกแต่ผลลัพธ์ผิด แก้ที่ logic ของเอเจนต์
• ถ้า auth ผิด ตรวจ header และ credential
• ถ้า task ค้าง ตรวจ lifecycle และ streaming event

ดูขั้นตอนแบบเต็มได้ที่ คู่มือ Apidog A2A Debugger และอ่านแนวทางกว้างขึ้นใน การทดสอบเอเจนต์ AI ที่เรียกใช้ API ของคุณ

เริ่มต้นใช้งาน A2A แบบเป็นขั้นตอน

ถ้าต้องการเริ่มสร้างหรือเชื่อมต่อเอเจนต์ A2A ให้ทำตามลำดับนี้:

1. อ่านข้อมูลจำเพาะ

เริ่มจาก ข้อมูลจำเพาะ A2A เพื่อทำความเข้าใจ:

• โครงสร้าง Agent Card
• lifecycle ของ task
• รูปแบบ message
• artifacts
• streaming
• auth metadata

2. รันเอเจนต์ตัวอย่าง

ใช้ เอเจนต์ตัวอย่างอ้างอิง เพื่อดู flow จริงก่อนเขียนเอง

เป้าหมายของขั้นนี้คือให้คุณเห็นว่า:

• Agent Card หน้าตาอย่างไร
• endpoint ถูก expose อย่างไร
• task ถูกสร้างและอัปเดตอย่างไร
• output ถูกส่งกลับเป็น artifacts อย่างไร

3. ตรวจ Agent Card

หลังรันตัวอย่าง ให้เปิด Agent Card:

curl http://localhost:PORT/.well-known/agent.json

ตรวจว่าข้อมูลสำคัญครบ เช่น name, description, capabilities และ skills

4. ส่งข้อความทดสอบ

เริ่มจากข้อความสั้นๆ เช่น hello หรือคำสั่งง่ายๆ ที่ skill รองรับ อย่าเริ่มจากไฟล์หรือ payload ซับซ้อนทันที

เป้าหมายคือยืนยันว่า round trip พื้นฐานทำงานได้:

client -> message -> task -> completed -> artifacts

5. สร้างเอเจนต์ของคุณเอง

เมื่อเข้าใจ flow แล้ว ค่อยสร้างเอเจนต์ของคุณเอง โดยเริ่มจาก:

• expose Agent Card ให้ถูกต้อง
• รองรับ message พื้นฐาน
• สร้าง task ID
• อัปเดต status
• ส่ง artifacts กลับมา

6. เพิ่ม feature ทีละส่วน

เมื่อข้อความพื้นฐานทำงานแล้ว ค่อยเพิ่ม:

• authentication
• file attachment
• metadata
• structured data
• streaming
• long-running task handling

อย่าเพิ่มทุกอย่างพร้อมกัน เพราะจะทำให้แยกสาเหตุของ bug ยาก

Checklist สำหรับ implementation

ใช้ checklist นี้ก่อนเชื่อมเอเจนต์เข้า workflow จริง:

• [ ] Agent Card เปิดได้จาก path ที่ตกลงไว้
• [ ] Agent Card ระบุ protocol version ถูกต้อง
• [ ] skills อธิบาย input/output ชัดเจน
• [ ] auth requirement ตรงกับ implementation
• [ ] ส่ง message พื้นฐานได้
• [ ] task มี ID และ status
• [ ] status เปลี่ยนอย่างคาดเดาได้
• [ ] artifacts มีโครงสร้างที่ client ใช้งานต่อได้
• [ ] error response อ่านแล้วเข้าใจได้
• [ ] streaming ทำงาน หากประกาศว่า support
• [ ] ทดสอบด้วย debugger หรือ client แยกจาก production app แล้ว

A2A ยังเป็นโปรโตคอลใหม่ แต่มี backing จากมูลนิธิที่ไม่ขึ้นกับผู้ขาย และออกแบบมาเพื่อให้เอเจนต์จากหลายเฟรมเวิร์กทำงานร่วมกันได้ การมอง traffic ระหว่างเอเจนต์เป็นโปรโตคอลระดับสูงตั้งแต่ตอนนี้จะช่วยลดการเขียน integration เฉพาะกิจในอนาคต

อ่านบริบทเพิ่มเติมได้ที่ เอเจนต์ AI คือผู้บริโภค API รายใหม่ และ การออกแบบ API สำหรับเอเจนต์ AI

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

A2A สร้างโดย Google หรือไม่?

Google เปิดตัว A2A ในปี 2025 จากนั้นบริจาคให้ Linux Foundation ในฐานะโครงการโอเพนซอร์สที่ไม่ขึ้นกับผู้ขาย ข้อมูลจำเพาะพัฒนาแบบเปิด และผู้ขายรายใดก็สามารถนำไปใช้ได้

ฉันจำเป็นต้องใช้ A2A หรือไม่หากมีเอเจนต์เดียว?

ไม่จำเป็น A2A แก้ปัญหาการสื่อสารระหว่างเอเจนต์ ถ้าคุณมีเอเจนต์เดียวที่ต้องเรียกเครื่องมือ ฐานข้อมูล หรือ API ให้พิจารณา MCP แทน คุณจะใช้ A2A เมื่อมีเอเจนต์ตัวที่สองเข้ามาเกี่ยวข้อง

เฟรมเวิร์กใดบ้างที่รองรับ A2A?

A2A ถูกออกแบบให้ไม่ขึ้นกับเฟรมเวิร์ก เอเจนต์ใดๆ ที่เผยแพร่ Agent Card ที่ถูกต้องและพูดโปรโตคอลนี้ได้ก็สามารถเข้าร่วมได้ ไม่ว่าจะสร้างด้วย LangGraph, CrewAI, AutoGen หรือโค้ด custom

A2A เหมือนกับ MCP หรือไม่?

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

ฉันจะดีบักการรวมระบบ A2A ได้อย่างไร?

ใช้ A2A debugger แบบภาพ เช่น Apidog A2A Debugger วาง URL ของ Agent Card ส่งข้อความทดสอบ แล้วตรวจ request และ response ดิบ เพื่อแยกปัญหา payload, auth, task lifecycle และ logic ของเอเจนต์ออกจากกัน

A2A รองรับงานที่ใช้เวลานานหรือไม่?

รองรับ โมเดลงานมีสถานะชัดเจน และโปรโตคอลรองรับ server-sent events สำหรับ stream ผลลัพธ์บางส่วนและอัปเดตความคืบหน้า ทำให้งานที่ใช้เวลานานไม่ต้องบล็อกผู้เรียกแบบเงียบๆ