ไทย

A2A กับ MCP: โปรโตคอลเสริมสำหรับระบบตัวแทนใหม่

บทความนี้แนะนำโปรโตคอล A2A และ MCP ซึ่งเป็นโปรโตคอลสำคัญที่กำลังเปลี่ยนอนาคตของระบบตัวแทน AI อธิบายการทำงาน ความแตกต่าง และเหตุผลที่การเข้าใจโครงสร้างนี้สำคัญสำหรับนักพัฒนา นักออกแบบ และผู้สร้างผลิตภัณฑ์ AI

Guamian

Product & Design

4/11/2025

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

เปิดตัวแอปที่ปลอดภัยเร็วขึ้นด้วย Logto ผสานการยืนยันตัวตนผู้ใช้ภายในไม่กี่นาทีและมุ่งเน้นที่ผลิตภัณฑ์หลักของคุณ

เริ่มต้นใช้งาน

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

ในช่วงต้นปี 2025 โปรโตคอลสองตัวได้เกิดขึ้นเพื่อตอบสนองความต้องการนี้ — A2A (Agent-to-Agent) และ MCP (Model Context Protocol) วิธีการที่ง่ายในการเข้าใจบทบาทของพวกเขาคือ:

A2A: ตัวแทนมีปฏิสัมพันธ์กันอย่างไร

MCP: ตัวแทนมีปฏิสัมพันธ์กับเครื่องมือหรือบริบทภายนอกอย่างไร

อ้างอิง: https://google.github.io/A2A/#/topics/a2a_and_mcp

โปรโตคอลทั้งสองนี้แก้ไขความท้าทายหลักของการสร้างระบบที่มี ตัวแทนหลายตัว, LLM หลายชุด, และแหล่งบริบทหลายตัว ซึ่งทั้งหมดจำเป็นต้องทำงานร่วมกัน

หนึ่งวิธีในการอธิบายคือ: “MCP ให้การบูรณาการในแนวตั้ง (จากแอปพลิเคชันไปสู่โมเดล) ในขณะที่ A2A ให้การบูรณาการในแนวนอน (จากตัวแทนถึงตัวแทน)

ไม่ว่าคุณจะเป็นนักพัฒนาหรือไม่ก็ตาม ทุกคนที่สร้างผลิตภัณฑ์ AI หรือระบบตัวแทนควรเข้าใจสถาปัตยกรรมพื้นฐานนี้ — เพราะมันส่งผลต่อวิธีการออกแบบผลิตภัณฑ์ การโต้ตอบกับผู้ใช้ ระบบนิเวศ และการเติบโตในระยะยาว

บทความนี้แนะนำโปรโตคอลทั้งสองในวิธีที่เรียบง่าย เข้าใจง่ายและเน้นประเด็นสำคัญสำหรับนักพัฒนาและผู้สร้างผลิตภัณฑ์ AI

A2A (Agent-to-Agent) คืออะไร

A2A (Agent-to-Agent) เป็นโปรโตคอลเปิดที่พัฒนาโดย Google และพันธมิตรกว่า 50 รายในอุตสาหกรรม จุดประสงค์ของมันคือเพื่อให้เกิด การทำงานร่วมกันระหว่างตัวแทน — ไม่ว่าตัวแทนเหล่านั้นจะสร้างโดยใคร ถูกโฮสต์ที่ไหน หรือใช้เฟรมเวิร์คอะไร

กลไกโปรโตคอล A2A

A2A ใช้ JSON-RPC 2.0 ผ่าน HTTP(S) เป็นกลไกการสื่อสาร, พร้อมกับการรองรับ Server-Sent Events (SSE) เพื่อการสตรีมอัปเดต

แบบจำลองการสื่อสาร A2A

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

สิ่งที่น่าสนใจคือ ตัวแทนจะค้นพบกันและกันอย่างไร แต่ละตัวแทนสามารถเผยแพร่ Agent Card (เอกสาร metadata ในรูปแบบ JSON มักจะโฮสต์ที่ URL มาตรฐาน เช่น /.well-known/agent.json) ที่อธิบายความสามารถ ทักษะ, จุดสิ้นสุด API และข้อกำหนดการรับรอง

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

อ้างอิง: https://google.github.io/A2A/#/

การจัดการภารกิจ

การโต้ตอบทั้งหมดใน A2A มุ่งเน้นที่การทำภารกิจ ภารกิจเป็นวัตถุโครงสร้าง (กำหนดโดยสเกมาของโปรโตคอล) ที่รวมรายละเอียดของคำขอและติดตามสถานะของมัน

ใน A2A แต่ละตัวแทนมีบทบาทหนึ่งในสองบทบาท:

ตัวแทนไคลเอนต์: เริ่มภารกิจ
ตัวแทนระยะไกล: รับและดำเนินการภารกิจ

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

ความร่วมมือและการเจรจาเนื้อหา

A2A รองรับมากกว่าคำขอภารกิจง่าย ๆ — ตัวแทนสามารถแลกเปลี่ยน ข้อความหลายส่วนที่มีความซับซ้อน ซึ่งรวมถึงข้อความ, JSON, รูปภาพ, วิดีโอ หรือเนื้อหาแบบอินเทอร์แอคทีฟ สิ่งนี้ทำให้สามารถ เจรจารูปแบบ ตามสิ่งที่แต่ละตัวแทนสามารถจัดการหรือแสดงผลได้

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

ตัวอย่างกรณีการใช้งาน

นี่คือตัวอย่าง ในโลกจริง ของการใช้ A2A ในสถานการณ์องค์กร:

มีพนักงานใหม่เข้าในบริษัทขนาดใหญ่ ระบบและแผนกหลายแห่งมีส่วนเกี่ยวข้องในการเริ่มงานใหม่:

แผนกทรัพยากรบุคคลต้องสร้างบันทึกและส่งอีเมลต้อนรับ
IT ต้องจัดหาคอมพิวเตอร์แล็ปท็อปและบัญชีในบริษัท
ฝ่ายจัดการสถานที่ต้องเตรียมโต๊ะและบัตรเข้าถึง

ตามปกติแล้ว ขั้นตอนเหล่านี้จะดำเนินการโดยมือหรือผ่านการเชื่อมโยงที่เข้มงวดระหว่างระบบภายใน

แทนที่จะใช้ API แบบกำหนดเองระหว่างทุกระบบ แผนกแต่ละแผนกสามารถเปิดเผยตัวแทนของตัวเองโดยใช้โปรโตคอล A2A:

ตัวแทน	ความรับผิดชอบ
hr-agent.company.com	สร้างบันทึกพนักงาน, ส่งเอกสาร
it-agent.company.com	สร้างบัญชีอีเมล, สั่งซื้อแล็ปท็อป
facilities-agent.company.com	จัดสรรโต๊ะ, พิมพ์บัตรเข้าถึง

ระบบหลายตัวแทน — ให้เรียกว่า OnboardingPro (เช่น onboarding-agent.company.com) — ประสานการทำงานของการเริ่มงานใหม่ทั้งหมด

การค้นพบ: มันอ่าน .well-known/agent.json ของแต่ละตัวแทนเพื่อทำความเข้าใจความสามารถและการรับรอง
การมอบหมายภารกิจ:
- ส่งคำร้อง createEmployee ไปที่ตัวแทน HR
- ส่งคำร้อง setupEmailAccount และ orderHardware ไปยังตัวแทน IT
- ส่งคำร้อง assignDesk และ generateBadge ไปยังตัวแทน Facilities
การอัปเดตแบบสตรีม: ตัวแทนอัปเดตสถานะกลับโดยใช้ Server-Sent Events (เช่น “แล็ปท็อปถูกจัดส่ง”, “โต๊ะถูกจัดสรร”)
การรวบรวม artifact: ผลลัพธ์สุดท้าย (เช่น PDF badge, อีเมลยืนยัน, ข้อมูลรับรองบัญชี) ถูกส่งกลับเป็น artifact ของ A2A
การเสร็จสิ้น: OnboardingPro แจ้งให้ผู้จัดการการจ้างงานทราบเมื่อการเริ่มต้นงานเสร็จสิ้น

MCP (Model Context Protocol) คืออะไร

MCP (Model Context Protocol) พัฒนาโดย Anthropic เป็นโปรโตคอลที่แก้ไขปัญหาที่แตกต่างกัน: วิธีที่แอปพลิเคชันภายนอกสามารถให้บริบทและเครื่องมือที่มีโครงสร้างให้กับเอเจนต์ที่ใช้โมเดลภาษาขนาดใหญ่ในระหว่างการดำเนินการ

แทนที่จะทำให้การสื่อสารระหว่างเอเจนต์ดีขึ้น MCP มุ่งเน้นไปที่ หน้าต่างบริบท — หน่วยความจำการทำงานของโมเดลภาษาขนาดใหญ่ (LLM) วัตถุประสงค์ของมันคือ:

ฉีดเครื่องมือที่เกี่ยวข้อง เอกสาร ฟังก์ชัน API หรือสถานะผู้ใช้เข้าสู่เซสชันการตีความของโมเดลอย่างไดนามิก
ให้โมเดลเรียกฟังก์ชันหรือดึงเอกสารโดยไม่ต้องโค้ดคำเริ่มคำถามหรือโลจิก

สถาปัตยกรรมหลักของ MCP

เพื่อเข้าใจ MCP คุณต้องเข้าใจสถาปัตยกรรมรวม — ว่าส่วนทั้งหมดทำงานร่วมกันอย่างไร

โฮสต์ MCP: “AI ที่คุณคุยด้วย”

คิดว่า โฮสต์ MCP เป็นแอป AI ตัวมันเอง — เช่น Claude Desktop หรือผู้ช่วยการเขียนโค้ดของคุณ

มันคืออินเทอร์เฟซที่คุณใช้ — ที่ที่คุณพิมพ์หรือพูด

มันต้องการ ดึงเครื่องมือและข้อมูล ที่ช่วยให้โมเดลให้คำตอบที่ดีกว่า

ไคลเอนต์ MCP: “ตัวเชื่อมต่อ”

ไคลเอนต์ MCP เป็นซอฟต์แวร์ที่เชื่อมแอป AI ของคุณ (เช่น Claude) กับโลกภายนอก เป็นเหมือนไฟเปลี่ยน – มันจัดการเชื่อมต่อที่ปลอดภัยและแบบตัวต่อตัวกับเซิร์ฟเวอร์ MCP ต่าง ๆ เมื่อ AI ต้องการเข้าถึงบางอย่าง มันผ่านไคลเอนต์

เป็นผลดีที่จะคิดว่าเครื่องมืออย่าง ChatGPT, Claude chat หรือ Cursor IDE เป็น โฮสต์ MCP — มันทำให้อินเทอร์เฟซที่คุณโต้ตอบได้ หลังฉากใช้ ไคลเอนต์ MCP ในการเชื่อมต่อกับเครื่องมือและแหล่งข้อมูลต่าง ๆ ผ่านเซิร์ฟเวอร์ MCP

อ้างอิง: https://modelcontextprotocol.io/introduction

เซิร์ฟเวอร์ MCP: “ผู้ให้บริการเครื่องมือ”

เซิร์ฟเวอร์ MCP เป็นโปรแกรมขนาดเล็ก เน้นเฉพาะงานที่แสดงออกมาเป็นเครื่องมือหรือความสามารถเฉพาะ — เช่น:

ค้นหาไฟล์ในคอมพิวเตอร์ของคุณ
ค้นหาข้อมูลในฐานข้อมูลท้องถิ่น
เรียกใช้งาน API ภายนอก (เช่น สภาพอากาศ การเงิน ปฏิทิน)

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

แหล่งข้อมูลท้องถิ่น: “ไฟล์และบริการของคุณเอง”

เซิร์ฟเวอร์ MCP บางตัวเชื่อมต่อกับสิ่งที่อยู่ในเครื่องของคุณเอง — เช่น:

เอกสารและโฟลเดอร์
โปรเจกต์โค้ด
ฐานข้อมูลหรือแอปท้องถิ่น

ทำให้ AI สามารถค้นหา ดึงข้อมูล หรือคำนวณบางสิ่งได้ โดยไม่ต้องอัปโหลดข้อมูลของคุณไปยังคลาวด์

บริการระยะไกล: “API & เครื่องมือออนไลน์”

เซิร์ฟเวอร์ MCP อื่น ๆ เชื่อมต่อกับอินเทอร์เน็ต — มันพูดคุยกับ:

API (เช่น Stripe, Notion, GitHub)
เครื่องมือ SaaS
ฐานข้อมูลของบริษัทในคลาวด์

ทำให้ AI สามารถบอกได้ว่า: “เรียกเซิร์ฟเวอร์ GitHub และดึงรายการ PR ที่เปิดอยู่”

MCP ในปัจจุบันรองรับการเชื่อมต่อกับ เซิร์ฟเวอร์ MCP ระยะไกล นี้หมายความว่าไคลเอนต์ MCP สามารถได้รับ ความสามารถที่มีประสิทธิภาพมากขึ้น ในทางทฤษฎี

ด้วยการมีเซิร์ฟเวอร์ MCP ที่เหมาะสม ผู้ใช้สามารถเปลี่ยนไคลเอนต์ MCP ทุกตัวเป็น “ทุกอย่างรับรอง”

อ้างอิง: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

การนำทุกอย่างมารวมกัน

ตอนนี้ลองใช้แผนผังเพื่อดูว่าทุกอย่างทำงานร่วมกันอย่างไร

คุณถาม AI บางอย่างที่ซับซ้อน
AI (หรือ โฮสต์) ขอความช่วยเหลือจาก ไคลเอนต์
ไคลเอนต์เรียก เซิร์ฟเวอร์ MCP ที่เหมาะสม — อาจเป็นการตรวจสอบไฟล์หรือเรียก API
เซิร์ฟเวอร์ส่งกลับข้อมูลหรือรันฟังก์ชัน
ผลลัพธ์ไหลกลับไปยังโมเดลเพื่อช่วยให้เสร็จสิ้นภารกิจ

A2A กับ MCP — การเปรียบเทียบ

หมวดหมู่	A2A (Agent-to-Agent)	MCP (Model Context Protocol)
เป้าหมายหลัก	เปิดใช้งานการแลกเปลี่ยนภารกิจระหว่างตัวแทน	เปิดใช้งาน LLM เพื่อเข้าถึงเครื่องมือภายนอกหรือบริบท
ออกแบบสำหรับ	การสื่อสารระหว่างตัวแทนอัตโนมัติ	การเสริมความสามารถของตัวแทนเดี่ยวในระหว่างการตีความ
เน้นที่	กระบวนการทำงานหลายตัวแทน การประสานงาน การมอบหมาย	การใช้งานเครื่องมือแบบไดนามิก การเสริมบริบท
แบบจำลองการดำเนินงาน	ตัวแทนส่ง/รับภารกิจและ artifacts	LLM เลือกและดำเนินการเครื่องมือแบบอินไลน์ระหว่างการคิด
ความปลอดภัย	OAuth 2.0, คีย์ API, ขอบเขตที่กำหนดเอง	จัดการที่เลเยอร์การบูรณาการแอปพลิเคชัน
บทบาทของนักพัฒนา	สร้างตัวแทนที่เปิดเผยภารกิจและ artifacts ผ่านจุดสิ้นสุด	กำหนดเครื่องมือและบริบทที่มีโครงสร้างที่โมเดลสามารถใช้ได้
พันธมิตรระบบนิเวศ	Google, Salesforce, SAP, LangChain, เป็นต้น	Anthropic, พร้อมกับการยอมรับใน UI ที่ใช้งานเครื่องมือ LLM ที่เกิดขึ้นใหม่

วิธีการทำงานร่วมกัน

แทนที่จะเป็นทางเลือก A2A และ MCP เป็นการเสริมกัน ในหลายระบบ ทั้งสองจะถูกใช้ร่วมกัน

ตัวอย่างเวิร์กโฟลว์

ผู้ใช้ส่งคำขอที่ซับซ้อนในอินเทอร์เฟซตัวแทนองค์กร
ตัวแทนที่จัดคิวใช้ A2A เพื่อมอบหมายภารกิจย่อยให้กับตัวแทนเฉพาะทาง ( เช่น การวิเคราะห์, HR, การเงิน)
หนึ่งในตัวแทนเหล่านั้นใช้ MCP ภายในเพื่อเรียกใช้ฟังก์ชันค้นหา ดึงเอกสาร หรือคำนวณบางอย่างโดยใช้โมเดล
ผลลัพธ์ถูกส่งกลับมาเป็น artifact ผ่าน A2A ทำให้เกิดความร่วมมือของตัวแทนจากต้นจนจบด้วยการเข้าถึงเครื่องมือแบบโมดูลาร์

สถาปัตยกรรมนี้แยก การสื่อสารระหว่างตัวแทน (A2A) ออกจาก การเรียกความสามารถภายในตัวแทน (MCP) ทำให้ระบบง่ายต่อการประสาน ขยาย และรักษาความปลอดภัย

สรุป

A2A เกี่ยวกับ ตัวแทนพูดคุยกับตัวแทนอื่นๆ ผ่านเครือข่าย — อย่างปลอดภัย ไม่ตรงกับการใช้งาน และเน้นที่ภารกิจ

MCP เกี่ยวกับ การฉีดความสามารถที่มีโครงสร้างเข้าสู่เซสชันของโมเดล ทำให้ LLM คิดผ่านเครื่องมือและข้อมูลตามบริบท

เมื่อใช้ร่วมกัน พวกเขาสนับสนุน ระบบหลายตัวแทนที่สามารถประกอบกันได้ ซึ่งมีการขยายตัวและทำงานร่วมกันอย่างเข้ากันได้

โครงสร้างพื้นฐาน MCP + A2A อาจเปลี่ยนอนาคตของตลาดผลิตภัณฑ์ตัวแทนอย่างไร

สุดท้ายนี้ ฉันต้องการพูดถึงว่าโครงสร้างทางเทคนิคหลักนี้อาจเปลี่ยนอนาคตของตลาด AI และสิ่งที่มันหมายถึงสำหรับคนที่สร้างผลิตภัณฑ์ AI

การเปลี่ยนแปลงในการโต้ตอบระหว่างมนุษย์กับคอมพิวเตอร์

ตัวอย่างที่ชัดเจนของความเปลี่ยนแปลงนี้สามารถเห็นได้ในเวิร์กโฟลว์ของนักพัฒนาและบริการ ด้วยเซิร์ฟเวอร์ MCP ที่อยู่ใน IDE และเอเยนต์การเขียนโค้ด วิธีที่นักพัฒนาพรเอิงกับเครื่องมือเปลี่ยนไปอย่างสิ้นเชิง

ก่อนหน้านี้ เวิร์กโฟลว์ปกติจะรวมการค้นหาบริการที่เหมาะสม การตั้งค่าโฮสต์ การอ่านเอกสาร การรวม API อย่างมืด แนวการเขียนโค้ดใน IDE และการกำหนดคุณสมบัติผ่านแผงแดชบอร์ดแบ่งเป็นขั้นตอน มันเป็นประสบการณ์ที่กระจัดกระจาย ต้องเปลี่ยนบริบทและมีหนักเกินความจำเป็นในทุกขั้นตอน

ตอนนี้ ด้วยเอเจนต์การเขียนโค้ดที่เชื่อมต่อกับ MCP ความซับซ้อนมากมายของนั้นสามารถถูกแยกออกไป นักพัฒนาสามารถค้นพบและใช้เครื่องมือตามธรรมชาติมากขึ้นผ่านคำสั่งสนทนา การรวม API กำลังกลายเป็นส่วนหนึ่งของกระแสการเขียนโค้ดเอง — โดยไม่ต้องมี UI แยกหรือตั้งค่าแบบมีระบบ (ลองนึกถึงว่าบางครั้งโปรแดชบอร์ดของ AWS หรือ Microsoft จะซับซ้อนเพียงใด). ปฏิสัมพันธ์เปลี่ยนเป็นราบรื่นขึ้น — ส่วนใหญ่เกี่ยวกับการชี้แนะพฤติกรรมมากกว่าการประกอบคุณลักษณะ

ในโมเดลนี้ การสื่อสารกับผู้ใช้หรือนักพัฒนาเปลี่ยนจากการกำหนดคุณลักษณะเป็นการจัดการพฤติกรรม สิ่งนี้เปลี่ยนบทบาทของการออกแบบผลิตภัณฑ์เช่นกัน

แทนที่จะใช้ UI เพื่อ “แก้ไข” ปัญหาทางเทคนิค (เช่น “นี้โค้ดยากเกินไป ลองสร้างแผงกำหนดค่า”), เราต้อง:

คิดถึง ประสบการณ์ทั้งหมดตั้งแต่ต้นจนจบ
ออกแบบว่าและเมื่อใด AI + การโต้ตอบกับผู้ใช้ ควรเกิดขึ้น
ให้ AI จัดการตรรกะ และนำผู้ใช้ผ่านเจตนาและกระแส

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

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

แนวคิดผลิตภัณฑ์ตัวแทนและผลกระทบต่อ SaaS

เราเริ่มเห็นการเกิดขึ้นของ เซิร์ฟเวอร์ MCP มากขึ้นเรื่อยๆ ลองนึกถึง Airbnb เสนอตัวแทน การจองบนเซิร์ฟเวอร์ MCP หรือ Google Maps แสดงตัวแทน แผนที่บนเซิร์ฟเวอร์ MCP หนึ่งตัวแทน (ซึ่งเป็นไคลเอนต์ MCP) สามารถเชื่อมต่อกับเซิร์ฟเวอร์เหล่านี้หลายตัวในเวลาเดียวกัน — ทำให้เปิดใช้งานเวิร์กโฟลว์ที่ต้องการการจัดการแบบกำหนดเองหรือแอปที่ผูกพันกันแน่นอน

เมื่อเทียบกับยุค SaaS ที่มีการเชื่อมต่อกันแบบแมนนวลและไม่ง่าย แบบนี้ช่วยให้เวิร์กโฟลว์เป็นระบบอัตโนมัติ มากขึ้น และ การเชื่อมต่อระหว่างบริการต่าง ๆ เป็นระบบที่คล่องตัวมากขึ้น นี่คือตัวอย่างสองตัวอย่าง:

การออกจากเอกสาร

คุณเขียน PRD ใน Notion หนึ่งตัวแทน Figma อ่านเอกสารและสร้างไวร์เฟรมอัตโนมัติที่จัดวางแนวคิดหลัก — โดยไม่มีการสั่งส่งเกิดขึ้น
การวิจัยคู่แข่ง จากต้นจนจบ

คุณขอการวิเคราะห์คู่แข่ง กลุ่มตัวแทนค้นหาเว็บ ลงทะเบียนกับบริการที่เกี่ยวข้องในนามของคุณ (ด้วยการรับรองที่ปลอดภัย) เก็บรวบรวมผลลัพธ์และส่งกลับมาในรูปแบบ artifact ที่เรียบร้อยแล้วใน Notion ของคุณ

ความท้าทายเกี่ยวกับการยืนยันตัวตนและขอบเขตการอนุญาต

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

จนถึงขณะนี้มีหลายสถานการณ์เฉพาะเกี่ยวกับการเพิ่มขึ้นของจากตัวแทนสู่ตัวแทนและ MCP

ตัวแทน vs SaaS & WebsiteApp
ไคลเอนต์ MCP (ตัวแทน) vs เซิร์ฟเวอร์ MCP
ผู้ใช้ vs ตัวแทน
ตัวแทน vs ตัวแทน

อีกตัวอย่างที่น่าสนใจคือการประสานงานหลายตัวแทน Google (Google) กล่าวถึง:

ตัวอย่างเช่น ผู้ใช้ U กำลังทำงานกับตัวแทน A ซึ่งต้องการรหัสระบุ A-system ถ้าตัวแทน A พึ่งพาเครื่องมือ B หรือ ตัวแทน B ซึ่งต้องการรหัสระบุ B-system ผู้ใช้อาจต้องให้รหัสสำหรับทั้ง A-system และ B-system ในคำขอเดียว (สมมตว่า A-system เป็นรหัสประจำตัว LDAP ขององค์กรและ B-system เป็นรหัสประจำตัวของผู้ให้บริการ SaaS)

Logto เป็นผู้ให้บริการ OIDC และ OAuth ซึ่งเหมาะสำหรับอนาคตของการผสานรวม AI

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

มีคำถามไหม?

ติดต่อเรา — หรือสำรวจว่าสิ่งที่คุณสร้างได้กับ Logto ในวันนี้

ลองใช้ Logto Cloud ฟรี

A2A (Agent-to-Agent) คืออะไร#

กลไกโปรโตคอล A2A#

แบบจำลองการสื่อสาร A2A#

การจัดการภารกิจ#

ความร่วมมือและการเจรจาเนื้อหา#

ตัวอย่างกรณีการใช้งาน#

MCP (Model Context Protocol) คืออะไร#

สถาปัตยกรรมหลักของ MCP#

โฮสต์ MCP: “AI ที่คุณคุยด้วย”#

ไคลเอนต์ MCP: “ตัวเชื่อมต่อ”#

เซิร์ฟเวอร์ MCP: “ผู้ให้บริการเครื่องมือ”#

แหล่งข้อมูลท้องถิ่น: “ไฟล์และบริการของคุณเอง”#

บริการระยะไกล: “API & เครื่องมือออนไลน์”#

การนำทุกอย่างมารวมกัน#

A2A กับ MCP — การเปรียบเทียบ#

วิธีการทำงานร่วมกัน#

ตัวอย่างเวิร์กโฟลว์#

สรุป#

โครงสร้างพื้นฐาน MCP + A2A อาจเปลี่ยนอนาคตของตลาดผลิตภัณฑ์ตัวแทนอย่างไร#

การเปลี่ยนแปลงในการโต้ตอบระหว่างมนุษย์กับคอมพิวเตอร์#

แนวคิดผลิตภัณฑ์ตัวแทนและผลกระทบต่อ SaaS#

ความท้าทายเกี่ยวกับการยืนยันตัวตนและขอบเขตการอนุญาต#