Agent2Agent Debugger (A2A) คืออะไร? ทำไมคุณถึงต้องมี

คุณสร้างเอเจนต์ A2A แล้ว มันเชื่อมต่อได้ ทำงานได้ และบางครั้งก็คืนค่าผิด สิ่งที่ยากคือคุณเปิดคอนโซลแล้วเจอ JSON-RPC envelopes จำนวนมาก โดยฟิลด์สำคัญถูกซ่อนอยู่ลึกหลายชั้น ทำให้แยกไม่ออกว่าปัญหาอยู่ที่ transport, authentication, payload หรือ logic ของเอเจนต์ นี่คือจุดที่ A2A (Agent2Agent) Debugger ช่วยให้การตรวจสอบทำได้ตรงจุดขึ้น

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

บทความนี้อธิบายว่า A2A Debugger คืออะไร ใช้ดีบักการรับส่งข้อมูลระหว่างเอเจนต์อย่างไร ควรตรวจอะไรบ้าง และควรเลือกเครื่องมือแบบไหน หากต้องการพื้นฐานโปรโตคอลก่อน อ่านได้ที่ Agent2Agent (A2A) คืออะไร

A2A Debugger คืออะไร?

A2A Debugger คือเครื่องมือสำหรับเชื่อมต่อกับเอเจนต์ Agent2Agent ส่งข้อความทดสอบ และดู request/response แบบเต็ม โดยไม่ต้องเขียน client เอง

คิดเหมือน REST client สำหรับ API แต่แทนที่จะยิง endpoint ทั่วไป มันเข้าใจโครงสร้างของ A2A เช่น Agent Card, task lifecycle, message parts, artifacts และ JSON-RPC envelope

A2A เป็นโปรโตคอลเปิดสำหรับการสื่อสารระหว่าง AI agents โดยเอเจนต์จะประกาศตัวเองผ่าน Agent Card ระบุความสามารถ ทักษะ รูปแบบอินพุต และเวอร์ชันโปรโตคอล A2A Debugger จึงทำหน้าที่เป็น workbench สำหรับทดสอบสิ่งเหล่านี้ก่อนนำไปใช้ใน workflow จริง

คำถามหลักที่ดีบักเกอร์ควรตอบได้คือ:

เมื่อใช้ Agent Card นี้ เอเจนต์ตอบสนองอย่างไรจริง ๆ เมื่อส่งข้อความนี้เข้าไป?

ทำไมการดีบัก A2A จึงยากหากไม่มี Debugger

การดีบัก A2A ด้วย logs หรือ network tab อย่างเดียวมักไม่พอ เพราะข้อมูลสำคัญกระจายอยู่หลายชั้น

1. Console logs มักไม่ครบ

SDK หรือ runtime ของเอเจนต์มัก log เฉพาะสิ่งที่ผู้เขียนเลือกไว้ เช่น:

task completed

แต่ไม่แสดง payload ที่สำคัญ เช่น:

• task ID
• message parts
• artifacts
• metadata
• raw JSON-RPC response

ผลคือคุณเห็นว่า task สำเร็จ แต่ไม่รู้ว่าเอเจนต์ส่งอะไรกลับมาจริง ๆ

2. Network tab อ่านยาก

A2A payload อยู่ใน JSON-RPC envelope ที่ซ้อนหลายชั้น ตัวอย่างเช่น response อาจมีโครงสร้างประมาณนี้:

{
  "jsonrpc": "2.0",
  "id": "req-1",
  "result": {
    "task": {
      "id": "task-123",
      "status": {
        "state": "completed"
      },
      "artifacts": [
        {
          "parts": [
            {
              "kind": "text",
              "text": "ผลลัพธ์จากเอเจนต์"
            }
          ]
        }
      ]
    }
  }
}

ถ้าใช้ browser network panel คุณต้องเลื่อนหาเองว่า response อยู่ใน result.task.artifacts[].parts[] หรือฟิลด์อื่น

3. Script ทดสอบพังง่าย

หลายทีมเริ่มจาก curl หรือ Python script ชั่วคราว เช่น:

curl -X POST http://localhost:3000/a2a \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":"1","method":"message/send","params":{...}}'

วิธีนี้ใช้ได้ช่วงแรก แต่จะพังง่ายเมื่อ:

• Agent Card เปลี่ยน
• auth scheme เปลี่ยน
• endpoint เปลี่ยน
• message schema เปลี่ยน
• metadata หรือ file attachment ถูกเพิ่มเข้ามา

4. Transport error กับ logic error ดูเหมือนกัน

เมื่อเอเจนต์ตอบผิด สาเหตุอาจเป็นได้หลายอย่าง:

• request format ผิด
• authentication ล้มเหลว
• connection มีปัญหา
• metadata ไม่ถูกส่ง
• prompt หรือ model reasoning ผิด
• agent handler map skill ผิด

ถ้าไม่เห็น request/response แบบเต็ม ทุกอย่างจะถูกสรุปเป็น “เอเจนต์เสีย” ทั้งที่ปัญหาอาจอยู่คนละชั้น

A2A Debugger ช่วยตัดความคลุมเครือนี้โดยให้คุณเห็นว่า “ส่งอะไรไป” และ “ได้อะไรกลับมา” อย่างตรงไปตรงมา

A2A Debugger ควรทำอะไรได้บ้าง

A2A Debugger ที่ใช้งานได้จริงควรครอบคลุม 4 ส่วนหลัก

1. เชื่อมต่อและอ่าน Agent Card

ขั้นตอนแรกคือใส่ URL ของ Agent Card เช่น:

http://localhost:3000/.well-known/agent.json

จากนั้น debugger ควรดึงข้อมูล ตรวจ schema และแสดงข้อมูลสำคัญ เช่น:

• agent name
• description
• capabilities
• declared skills
• supported input/output types
• protocol version
• auth requirements

ถ้า Agent Card ผิดรูปแบบ เครื่องมือควรบอกได้ว่าฟิลด์ไหนขาดหรือผิด ไม่ใช่แค่ขึ้น error กว้าง ๆ

ตัวอย่างสิ่งที่ควรตรวจ:

{
  "name": "Research Agent",
  "description": "Agent สำหรับค้นคว้าและสรุปข้อมูล",
  "version": "1.0.0",
  "skills": [
    {
      "id": "summarize",
      "name": "Summarize text"
    }
  ]
}

ถ้า skill ที่คาดหวังไม่ปรากฏใน debugger ให้เริ่มแก้ที่ Agent Card ก่อน ไม่ใช่ที่ runtime logic

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

Debugger ควรให้คุณสร้าง message ได้โดยไม่ต้องประกอบ JSON-RPC เอง เช่น:

• ข้อความธรรมดา
• file attachment
• metadata แบบ key-value
• custom headers
• auth credentials

ตัวอย่าง workflow ที่ควรใช้:

1. เริ่มจากข้อความสั้นที่สุด
2. ส่งเฉพาะ plain text ก่อน
3. ตรวจ response
4. ค่อยเพิ่ม metadata
5. ค่อยเพิ่มไฟล์แนบ
6. ทดสอบ auth/header แยกต่างหาก

ตัวอย่าง prompt สำหรับทดสอบ:

สรุปข้อความนี้เป็น bullet points 3 ข้อ

ตัวอย่าง metadata:

{
  "tenantId": "dev-team",
  "traceId": "debug-001",
  "language": "th"
}

ข้อดีคือ debugger จะห่อข้อมูลเหล่านี้เป็นโครงสร้าง A2A และ JSON-RPC ที่ถูกต้องให้เอง

3. ตรวจ response หลายมุมมอง

คุณค่าหลักของ A2A Debugger คือการอ่าน response ได้ทั้งแบบ human-readable และ raw payload

A2A response อาจเป็น:

• text
• structured artifact
• file reference
• mixed content
• streaming chunks
• error payload

Debugger ที่ดีควรมีหลายมุมมอง เช่น Apidog A2A Debugger มี:

• Preview: แสดงโครงสร้างแบบ tree อ่านง่าย
• Content: แสดงผลลัพธ์ในรูปแบบที่ผู้ใช้จะเห็น
• Raw Data: แสดง JSON-RPC payload เต็มสำหรับตรวจระดับฟิลด์

ตัวอย่างการวิเคราะห์:

• ถ้า Raw Data มี artifacts แต่ Content ว่าง อาจแปลว่า renderer ไม่รองรับ artifact type นั้น
• ถ้า Raw Data ไม่มี field ที่คาดหวัง ปัญหาอยู่ที่ agent handler
• ถ้า response format ถูก แต่คำตอบผิด ปัญหาอาจอยู่ที่ prompt หรือ model
• ถ้าไม่มี response เลย ให้ตรวจ auth, endpoint, headers และ network

4. จัดการ authentication และ headers

เอเจนต์ที่ใช้งานจริงมักอยู่หลัง auth หรือ gateway ดังนั้น debugger ควรรองรับ:

• Bearer Token
• Basic Auth
• API key
• custom headers
• tenant headers
• gateway headers
• request signatures

ตัวอย่าง headers:

Authorization: Bearer <token>
X-Tenant-ID: dev-team
X-Request-ID: debug-001

จุดที่ต้องแยกให้ชัดคือ:

• HTTP headers ใช้กับ gateway, proxy, auth layer
• A2A metadata ส่งไปถึง agent/task handler

ถ้าคุณใส่คำสั่งเฉพาะ message ไว้ใน HTTP header เอเจนต์อาจไม่มีทางอ่านค่าเหล่านั้นเลย ให้ใส่ข้อมูลที่เกี่ยวกับงานของเอเจนต์ไว้ใน metadata แทน

Apidog A2A Debugger

Apidog มี A2A Debugger อยู่ใน client มาตรฐาน ใช้สำหรับเชื่อมต่อ Agent Card ส่งข้อความ และตรวจ response ได้โดยไม่ต้องเขียน client เอง

ขั้นตอนใช้งานแบบสั้น:

1. เปิดหน้า A2A Debugger
2. วาง URL ของ Agent Card เช่น:

   http://localhost:3000/.well-known/agent.json

1. คลิก Connect
2. ตรวจว่า status เป็น Connected
3. อ่าน metadata, capabilities และ skills ของเอเจนต์
4. เปิดแท็บ Messages
5. พิมพ์ข้อความทดสอบ
6. เพิ่มไฟล์หรือ metadata หากจำเป็น
7. คลิก Send
8. อ่าน response ผ่าน Preview, Content และ Raw Data

Apidog จัดการส่วนต่อไปนี้ให้:

• JSON-RPC envelope
• การส่ง message ตามโครงสร้าง A2A
• การอ่าน response
• server-sent-event streaming เมื่อเอเจนต์รองรับ
• session history สำหรับย้อนดู message ที่เคยส่ง
• headers และ authentication

ประเด็นสำคัญคือ debugger ทำงานเป็น local client โดย traffic ส่งตรงระหว่างเครื่องของคุณกับเอเจนต์ ไม่ได้ส่ง payload ผ่านเซิร์ฟเวอร์ของ Apidog

อ่านคู่มือแบบละเอียดได้ที่ คู่มือ Apidog A2A Debugger และถ้าต้องการ workflow ทดสอบเอเจนต์ที่กว้างขึ้น ดู AI agent debugger

Checklist สำหรับเลือก A2A Debugger

เมื่อต้องเลือกเครื่องมือ ให้ตรวจตามรายการนี้

Agent Card validation

เครื่องมือควรบอกได้ว่า Agent Card ผิดตรงไหน เช่น field ขาด, type ผิด หรือ protocol version ไม่ตรง ไม่ใช่แค่แจ้งว่า connection failed

Response views หลายแบบ

Raw JSON อย่างเดียวไม่พอ ควรมีอย่างน้อย:

• มุมมอง raw payload
• มุมมอง tree/structured
• มุมมอง content ที่ผู้ใช้เห็น

Authentication ครบ

ควรรองรับ Bearer, Basic, API key และ custom headers โดยไม่ต้องเขียน script เพิ่ม

รองรับไฟล์และ metadata

A2A traffic จริงไม่ได้มีแค่ข้อความ plain text เครื่องมือควรรองรับ file attachment และ per-message metadata

รองรับ streaming

ถ้าเอเจนต์ใช้ server-sent events debugger ควร render chunks ได้เมื่อข้อมูลมาถึง และแสดง payload ที่ประกอบเสร็จหลัง stream จบ

มี session history

ระหว่างดีบัก คุณจะส่งข้อความเดิมซ้ำหลายครั้ง การมี history และ replay ช่วยลดเวลาทดสอบมาก

Local-first traffic

ควรเชื่อมต่อจากเครื่องคุณไปยังเอเจนต์โดยตรง ไม่ควรส่ง payload ผ่าน third-party server โดยไม่จำเป็น

แนวคิดนี้เหมือนการทดสอบ API แบบตรวจ transport ก่อน logic ซึ่งอธิบายเพิ่มเติมได้ใน วิธีการทดสอบเอเจนต์ AI ที่เรียกใช้ API ของคุณ และถ้าคุณใช้ MCP ด้วย อ่าน คู่มือ MCP server vs A2A เพื่อแยกบทบาทของ debugger แต่ละโปรโตคอล

วงจรการดีบัก A2A ที่ใช้ได้จริง

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

1. Connect กับ Agent Card

ตรวจว่า debugger อ่าน Agent Card ได้ และ skills ที่แสดงตรงกับสิ่งที่คุณคาดหวัง

1. ส่ง message ที่เล็กที่สุด

เริ่มจากข้อความธรรมดา เช่น:

   ping

หรือ prompt สั้น ๆ ที่ควรกระตุ้น skill นั้นได้

1. ดู Raw Data ก่อน Preview

Raw Data คือสิ่งที่เอเจนต์ส่งออกมาจริง อย่าเริ่มจาก UI preview เพราะอาจซ่อนปัญหาบางส่วน

1. ตรวจ task status

ดูว่า task อยู่ในสถานะที่ถูกต้องหรือไม่ เช่น completed, failed หรือ input-required

1. ตรวจ artifacts และ message parts

ถ้าคาดหวัง text ให้ดูว่ามี part แบบ text หรือไม่ ถ้าคาดหวังไฟล์ ให้ดูว่ามี file reference หรือไม่

1. เพิ่ม metadata ทีละขั้น

อย่าเพิ่มทุกอย่างพร้อมกัน ให้เพิ่มทีละ key แล้วทดสอบซ้ำ

1. แยก transport ออกจาก logic

• ถ้า request ไม่ถึงเอเจนต์: ตรวจ endpoint, auth, headers
• ถ้า response format ผิด: ตรวจ agent implementation
• ถ้า response format ถูกแต่คำตอบผิด: ตรวจ prompt, model หรือ business logic

ลำดับนี้ช่วยให้คุณแยกปัญหาได้เป็นชั้น ๆ แทนที่จะเดาว่าเอเจนต์เสียตรงไหน

ตัวอย่างการดีบักแบบเร็ว

สมมติคุณส่ง metadata แล้วเอเจนต์ไม่ใช้ค่า language

1. ส่ง metadata

{
  "language": "th"
}

2. ตรวจ Raw Data

ดูว่า metadata ถูกส่งอยู่ใน A2A message หรือไม่ ไม่ใช่แค่ HTTP header

3. ถ้า metadata ไม่อยู่ใน message

ปัญหาอยู่ที่ client/debugger configuration หรือวิธี map input

4. ถ้า metadata อยู่ใน message แล้ว

ปัญหาอยู่ที่ agent handler ที่ไม่ได้อ่าน metadata

5. ถ้า handler อ่านแล้วแต่ output ยังผิด

ปัญหาอาจอยู่ที่ prompt หรือ instruction ที่ส่งเข้า model

วิธีนี้ช่วยลดเวลาการไล่ปัญหาจากหลายชั่วโมงเหลือไม่กี่นาที

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

A2A Debugger คืออะไรในหนึ่งประโยค?

A2A Debugger คือเครื่องมือที่เชื่อมต่อกับเอเจนต์ Agent2Agent ส่งข้อความทดสอบ และแสดง request/response แบบเต็ม เพื่อให้ดีบักการรวมเอเจนต์ได้โดยไม่ต้องเขียน client เอง

A2A Debugger แตกต่างจาก API client อย่างไร?

API client ทดสอบ HTTP endpoints ทั่วไป ส่วน A2A Debugger เข้าใจเลเยอร์ A2A เช่น Agent Cards, task lifecycle, message parts และ artifacts จึง parse และแสดงผลข้อมูลเหล่านี้ได้โดยตรง

ถ้ามี logs แล้ว ยังต้องใช้ A2A Debugger หรือไม่?

ควรใช้ Logs แสดงเฉพาะสิ่งที่โค้ดเลือกบันทึก แต่ debugger แสดง traffic ที่ส่งผ่านจริง ทำให้แยก transport error ออกจาก agent logic error ได้ชัดเจนขึ้น อ่านพื้นฐานเพิ่มเติมได้ที่ Agent2Agent (A2A) คืออะไร

Apidog A2A Debugger ฟรีหรือไม่?

ใช่ มันรวมอยู่ใน Apidog client มาตรฐาน คุณสามารถ ดาวน์โหลด Apidog แล้วเปิด A2A Debugger จากแผงด้านข้างในเวอร์ชันล่าสุด

A2A Debugger ทดสอบเอเจนต์จากเฟรมเวิร์กใดก็ได้หรือไม่?

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

A2A Debugger รองรับ streaming response หรือไม่?

Debugger ที่ดีควรรองรับ เมื่อเอเจนต์ใช้ server-sent events เครื่องมือควรอ่าน chunks แบบ real-time และแสดง payload ที่ประกอบเสร็จหลัง stream สิ้นสุด

สรุป

A2A Debugger ทำให้การดีบักเอเจนต์เป็นงานที่ตรวจสอบได้ แทนที่จะเดาจาก logs หรือ JSON ที่ซ้อนหลายชั้น

ขั้นตอนที่ควรใช้คือ:

1. ตรวจ Agent Card
2. ส่งข้อความขั้นต่ำ
3. อ่าน Raw Data
4. ตรวจ artifacts/message parts
5. เพิ่ม metadata หรือไฟล์ทีละขั้น
6. แยก transport error ออกจาก logic error

ถ้าคุณกำลังสร้างหรือ integrate A2A agents เครื่องมือประเภทนี้ควรอยู่ใน workflow ตั้งแต่ development ไปจนถึง production debugging.