5 รูปแบบการผสานระบบมัลติเอเจนต์ที่ Google Cloud เสนอ: A2A และ MCP

Google Cloud เปิดเผยโครงสร้างพื้นฐานสำหรับสร้างระบบมัลติเอเจนต์ในระดับองค์กรที่งาน Cloud Next 26 โดยแกนหลักคือสองโปรโตคอล ได้แก่ A2A (Agent-to-Agent) สำหรับการสื่อสารระหว่างเอเจนต์ และ MCP (Model Context Protocol) ที่เอเจนต์ใช้เมื่อต้องเข้าถึงเครื่องมือและข้อมูลภายนอก บทความนี้แนะนำรูปแบบการผสานระบบ 5 แบบที่ผสานสองโปรโตคอลนี้เข้าด้วยกัน

รูปแบบที่ 1: การค้นหาและลงทะเบียนเอเจนต์

• Agent Card — เอเจนต์ทุกตัวที่รองรับ A2A จะเผยแพร่ความสามารถของตนเอง ข้อกำหนดด้านการยืนยันตัวตน ข้อจำกัดในการเรียกใช้ ฯลฯ ในรูปแบบเอกสาร JSON คล้ายกับสเปก OpenAPI แต่เป็นเสมือน "นามบัตร" ที่ออกแบบมาสำหรับปฏิสัมพันธ์ระหว่างเอเจนต์โดยเฉพาะ
• Agent Registry — เมื่อเอเจนต์ภายในองค์กรถูกลงทะเบียนไว้ในทะเบียนกลาง เอเจนต์ตัวอื่นก็สามารถค้นหาความสามารถและเข้าถึงได้แม้ไม่รู้ URL โดยตรง ทำหน้าที่คล้าย service mesh ในสถาปัตยกรรมไมโครเซอร์วิส (ชั้นกลางที่จัดการการสื่อสารระหว่างบริการ)

รูปแบบที่ 2: การมอบหมายงานข้ามทีม

• การทำงานร่วมกันข้ามภาษาและข้ามทีม — เอเจนต์ตัวประสานหนึ่งตัวสามารถมอบหมายงานให้กับเอเจนต์ Go ของทีมความปลอดภัย เอเจนต์ Java ของทีมความเสี่ยง หรือเอเจนต์ TypeScript ของทีมการตลาด เป็นต้น แม้แต่ละทีมจะใช้ภาษาและเฟรมเวิร์กต่างกัน ก็เชื่อมต่อกันได้หากเพียงแค่รองรับโปรโตคอล A2A
• การดีพลอยและการพัฒนาอย่างอิสระ — ตามหลักการเดียวกับที่ทำให้ไมโครเซอร์วิสประสบความสำเร็จ เอเจนต์แต่ละตัวสามารถดีพลอยและอัปเดตได้อย่างอิสระ โดยไม่จำเป็นต้องแก้ไขฝั่งเอเจนต์ตัวประสาน

รูปแบบที่ 3: การเชื่อมต่อเครื่องมือผ่าน MCP (Tool Bridge)

• เชื่อมต่อแหล่งข้อมูลหลากหลายด้วยโปรโตคอลเดียว — หากไม่มี MCP จะต้องสร้างคอนเนกเตอร์แยกสำหรับ REST API ฐานข้อมูล และระบบเลกาซีแต่ละแบบ แต่ MCP รวมสิ่งเหล่านี้ไว้ภายใต้อินเทอร์เฟซมาตรฐานเดียว
• นำธรรมาภิบาล API เดิมกลับมาใช้ได้ — ผ่าน Apigee API Hub สามารถแปลง REST API ที่มีอยู่ให้กลายเป็นเครื่องมือสำหรับเอเจนต์ได้โดยอัตโนมัติ และยังคงใช้ระบบจัดการเดิม เช่น การยืนยันตัวตน การบันทึกล็อก และการควบคุมสิทธิ์การเข้าถึงได้เหมือนเดิม
• เครื่องมือที่สร้างไว้ล่วงหน้ากว่า 60 รายการ — มี MCP integration ที่พร้อมใช้งานทันทีสำหรับ GitHub, Notion, Stripe และอื่น ๆ

รูปแบบที่ 4: การทำงานร่วมกันระหว่างองค์กร

• Agent Gallery — ภายใน Gemini Enterprise สามารถใช้งานเอเจนต์พาร์ตเนอร์ที่ผ่านการตรวจสอบแล้วมากกว่า 100 ตัวจาก Adobe, ServiceNow, Salesforce และรายอื่น ๆ ได้ทันที
• คงไว้ซึ่งธรรมาภิบาลที่เป็นอิสระ — แต่ละองค์กรยังคงรักษาโมเดลความปลอดภัยของตนเองไว้ พร้อมทั้งทำงานร่วมกันผ่าน A2A โดยนโยบายของ Agent Gateway สามารถควบคุมได้อย่างละเอียดว่าจะให้แชร์ข้อมูลใดและอนุญาตพฤติกรรมใดบ้าง

รูปแบบที่ 5: agent mesh แบบอิงเหตุการณ์

• เครือข่ายเอเจนต์ที่ทำงานตลอดเวลา — เอเจนต์ที่เชื่อมต่อกับตาราง BigQuery หรือสตรีม Pub/Sub (บริการสตรีมข้อความแบบเรียลไทม์) จะตรวจจับเหตุการณ์ และตามความจำเป็นจะมอบหมายต่อผ่าน A2A ไปยังเอเจนต์เฉพาะทางหรือยกระดับให้มนุษย์เข้ามาดำเนินการ
• การจัดระเบียบตัวเอง — เมื่อต้องการเพิ่มเอเจนต์เฉพาะทางตัวใหม่ ก็เพียงลงทะเบียนใน Registry และปรับแก้เฉพาะตรรกะการเราต์ โดยไม่จำเป็นต้องออกแบบ mesh ใหม่ทั้งระบบ
• การสังเกตการณ์ได้ — ผ่าน Agent Identity, Agent Gateway และ Agent Observability ทำให้สามารถติดตามกิจกรรมของเอเจนต์ทั้งหมดภายใน mesh ได้

จุดที่แตกต่าง

• ความเปิดกว้างของ A2A — โปรโตคอลนี้ชูแนวคิดการออกแบบแบบเปิดที่ไม่ผูกติดกับเฟรมเวิร์ก ภาษา หรือคลาวด์ใดโดยเฉพาะ และมุ่งเป็นมาตรฐานสำหรับการเชื่อมต่อเอเจนต์ในสภาพแวดล้อมต่างชนิด
• การแยกบทบาทของ A2A + MCP — ด้วยการแยกโปรโตคอลสำหรับการสื่อสารระหว่างเอเจนต์ออกจากการเข้าถึงเครื่องมือ ทำให้แต่ละชั้นสามารถพัฒนาแยกจากกันได้อย่างอิสระ
• ใช้ประโยชน์จากโครงสร้างพื้นฐานเดิม — แนวทางนี้คือวางชั้นเอเจนต์ไว้บนโครงสร้างพื้นฐาน Google Cloud ที่ใช้งานอยู่แล้ว เช่น Apigee และ BigQuery จึงดูเป็นความพยายามที่จะลดภาระในการนำสแต็กใหม่ทั้งหมดเข้ามาใช้

ข้อที่ควรพิจารณา

• ยึดโยงกับระบบนิเวศของ Google Cloud เป็นหลัก — ฟีเจอร์สำคัญอย่าง Agent Gallery และ Gemini Enterprise Agent Platform เชื่อมโยงอย่างใกล้ชิดกับแพลตฟอร์ม Google Cloud จึงยังต้องพิสูจน์ว่าความเปิดกว้างในสภาพแวดล้อมมัลติคลาวด์จะทำได้จริงเพียงใด
• ความซับซ้อนระดับองค์กร — หากนำทั้ง 5 รูปแบบมาผสมกันในการใช้งานจริง ก็อาจต้องเผชิญกับความซับซ้อนเฉพาะของระบบกระจาย เช่น การจัดการการพึ่งพาระหว่างเอเจนต์และการแพร่กระจายของความขัดข้อง

เฟรมเวิร์กที่ Google Cloud นำเสนอครั้งนี้เป็นความพยายามที่จะขยาย AI agent จากเครื่องมือเดี่ยวให้กลายเป็นโครงสร้างพื้นฐานเพื่อการทำงานร่วมกันทั้งองค์กร เช่นเดียวกับที่สถาปัตยกรรมไมโครเซอร์วิสก้าวข้ามข้อจำกัดของแอปพลิเคชันแบบโมโนลิธิก A2A และ MCP ก็มีทิศทางเพื่อแก้ปัญหาความโดดเดี่ยวของเอเจนต์แต่ละตัวเช่นกัน อย่างไรก็ตาม วิสัยทัศน์นี้จะทำงานได้ลื่นไหลในสภาพแวดล้อมองค์กรจริงมากน้อยเพียงใด คงต้องรอให้มีกรณีนำไปใช้สะสมมากขึ้นจึงจะตัดสินได้ ความสมบูรณ์ของโปรโตคอล คุณภาพของเอเจนต์พาร์ตเนอร์ และการประสานธรรมาภิบาลระหว่างองค์กร จะเป็นสามแกนหลักที่กำหนดคุณค่าที่แท้จริงของระบบนิเวศนี้

[bluenyx]

แค่มีคนระดับซีเนียร์ 3-4 คน ก็เริ่มกลายเป็นโครงสร้างที่รองรับงานในระดับที่เดิมต้องใช้คน 3-40 คนได้แล้วนะครับ (ชัดเจนกว่าตอนนี้อีก..)