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

การปรับใช้ตัวแทน 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:

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

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

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

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

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

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

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

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

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

1. ผู้ใช้ส่งคำขอที่ซับซ้อนในอินเทอร์เฟซตัวแทนองค์กร
2. ตัวแทนที่จัดคิวใช้ A2A เพื่อมอบหมายภารกิจย่อยให้กับตัวแทนเฉพาะทาง ( เช่น การวิเคราะห์, HR, การเงิน)
3. หนึ่งในตัวแทนเหล่านั้นใช้ MCP ภายในเพื่อเรียกใช้ฟังก์ชันค้นหา ดึงเอกสาร หรือคำนวณบางอย่างโดยใช้โมเดล
4. ผลลัพธ์ถูกส่งกลับมาเป็น 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 ที่มีการเชื่อมต่อกันแบบแมนนวลและไม่ง่าย แบบนี้ช่วยให้เวิร์กโฟลว์เป็นระบบอัตโนมัติ มากขึ้น และ การเชื่อมต่อระหว่างบริการต่าง ๆ เป็นระบบที่คล่องตัวมากขึ้น นี่คือตัวอย่างสองตัวอย่าง:

1. การออกจากเอกสาร

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

2. การวิจัยคู่แข่ง จากต้นจนจบ

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

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

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

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

1. ตัวแทน vs SaaS & WebsiteApp
2. ไคลเอนต์ MCP (ตัวแทน) vs เซิร์ฟเวอร์ MCP
3. ผู้ใช้ vs ตัวแทน
4. ตัวแทน 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 ในวันนี้