บทนำ
การนำ AI agent มาใช้งานอย่างรวดเร็วของ Uber ได้เปลี่ยนวิธีที่ทีมต่าง ๆ ทำงานร่วมกับโค้ด ข้อมูล และระบบปฏิบัติการไปอย่างสิ้นเชิง การเชื่อมต่อแบบเฉพาะกิจในช่วงแรกกับ MCP (Model Context Protocol) แสดงให้เห็นถึงคุณค่าที่ชัดเจน: agent มีความสามารถเพิ่มขึ้นอย่างมากเมื่อสามารถเข้าถึงบริบททางธุรกิจแบบเรียลไทม์ ค้นหาข้อมูลจากบริการภายใน และดำเนินการที่มีความหมายในนามของผู้ใช้ได้ ความสำเร็จในช่วงแรกเหล่านี้เป็นการยืนยันว่า MCP เป็น abstraction ที่ทรงพลังสำหรับการสร้างระบบ agentic ภายใน Uber
อย่างไรก็ตาม เมื่อการใช้งานขยายตัวเร็วขึ้น ความท้าทายสำคัญก็เริ่มปรากฏขึ้น แต่ละทีมพัฒนาการเชื่อมต่อขึ้นมาเองอย่างเป็นอิสระ ส่งผลให้เกิดความกระจัดกระจายของเครื่องมือและโครงสร้างพื้นฐานที่ซ้ำซ้อนกัน เครื่องมือ MCP นั้นค้นหาได้ยาก ใช้งานได้เสถียรยาก และผูกติดแน่นกับบริการหรือการนำไปใช้ของ agent บางตัว แม้แนวทางเหล่านี้จะใช้ได้ดีในระดับเล็ก แต่กลับไม่ตอบโจทย์ความต้องการของ Uber เมื่อมีหลายร้อยทีมเริ่มสำรวจ workflow แบบ agentic หากไม่มีสถาปัตยกรรมที่เป็นหนึ่งเดียว การขยายขนาด MCP จะยิ่งเพิ่มความซับซ้อนในการดำเนินงาน ความเสี่ยงด้านความปลอดภัย และอุปสรรคต่อนักพัฒนา ซึ่งท้ายที่สุดจะจำกัดผลกระทบที่จะเกิดขึ้น
เพื่อปลดล็อกศักยภาพสูงสุดของ MCP ในระดับสเกลของ Uber เราต้องการโซลูชันแบบรวมศูนย์ที่ขยายขนาดได้ เพื่อทำให้มาตรฐานการทำงานของ AI agent กับระบบ back-end ที่มีอยู่เป็นไปในทิศทางเดียวกัน ขณะเดียวกันก็ต้องรักษาความยืดหยุ่นให้แต่ละทีมด้วย โซลูชันนี้ต้องทำหน้าที่ abstract ความแตกต่างของโปรโตคอล (HTTP, gRPC™, TChannel) บังคับใช้การรับประกันด้านความปลอดภัยและการทำ observability อย่างสม่ำเสมอ และทำให้เครื่องมือ MCP สร้าง ค้นพบ และนำกลับมาใช้ใหม่ได้ง่ายทั่วทั้งบริษัท
เราจึงสร้าง MCP Gateway ขึ้นมาเพื่อตอบโจทย์นี้ โดยเป็น microservice พื้นฐานที่ขับเคลื่อนการทำงานทั้งหมดของ MCP ที่ Uber ทำหน้าที่เป็นเลเยอร์ orchestration และ routing ระหว่าง AI agent กับบริการ back-end ที่มีอยู่และเซิร์ฟเวอร์ MCP แบบ native การรวมตรรกะของ MCP ไว้ที่ gateway เดียว ทำให้เรามีโมเดลการประมวลผลที่สอดคล้องกันสำหรับการสื่อสารระหว่าง agent กับบริการ พร้อมทั้งลดความจำเป็นที่แต่ละทีมจะต้องสร้างโครงสร้างพื้นฐานหลักขึ้นมาใหม่ API ที่มีอยู่เดิมสามารถเปิดใช้เป็นเครื่องมือ MCP ได้อย่างราบรื่น จัดการและควบคุมได้จากจุดเดียว และถูกเรียกใช้โดย agent หลายตัวในรูปแบบที่เป็นมาตรฐานเดียวกัน MCP Gateway ได้เปิดเส้นทางที่ขยายขนาดได้ รวดเร็ว และสอดคล้องกันสำหรับการสร้าง AI agent ภายใน Uber และปัจจุบันรองรับเซิร์ฟเวอร์ MCP มากกว่า 800 ตัว และเครื่องมือกว่า 5,000 รายการ
รูปที่ 1: MCP Gateway (API ในฐานะเครื่องมือ)
ในบล็อกนี้ เราจะพาไปดูการออกแบบของ MCP Gateway ครอบคลุม Proxy Layer (การแปลง MCP ไปเป็นโปรโตคอลที่มีอยู่และแปลงกลับ), Discovery Layer (MCP Registry และการ crawl API) และ control plane (การสร้างและจัดการ)
Gateway
MCP Gateway ใช้สถาปัตยกรรมแบบ microservice โดยมี gateway ทำหน้าที่เป็นจุดเชื่อมต่อส่วนกลางระหว่างระบบที่ใช้ AI และบริการ back-end ของ Uber แพลตฟอร์มนี้ประกอบด้วยสองส่วนหลัก ได้แก่ MCP Registry ซึ่งทำหน้าที่เป็น control plane และ Proxy Gateway ซึ่งเป็น data plane
MCP Registry เก็บแค็ตตาล็อกของเซิร์ฟเวอร์ MCP หลายร้อยตัวที่ทำงานอยู่บนบริการภายใน พร้อมกับเครื่องมือ MCP อีกนับพันรายการ เครื่องมือเหล่านี้มีตั้งแต่คำนิยามแบบ no-code ที่เปิด API ที่มีอยู่ให้เป็นเครื่องมือ MCP ไปจนถึงการใช้งานแบบ native เต็มรูปแบบที่สร้างขึ้นตามข้อกำหนดของ MCP โดยเฉพาะ registry นี้ทำหน้าที่เป็นแหล่งข้อมูลอ้างอิงเพียงหนึ่งเดียวสำหรับการค้นหา ความเป็นเจ้าของ และการเปิดใช้งานทั่วทั้งระบบนิเวศ
Proxy Gateway มีหน้าที่ประมวลผลคำขอ MCP ในขณะรันไทม์ โดยจะแปลงการเรียกโปรโตคอล MCP ให้เป็นคำขอ HTTP, gRPC หรือ TChannel ส่งต่อไปยังบริการ back-end ที่เหมาะสม และแปลงผลลัพธ์กลับมาให้อยู่ในรูปแบบที่เข้ากันได้กับ MCP เลเยอร์การแปลงนี้ช่วยให้ AI agent สามารถทำงานร่วมกับระบบที่มีอยู่ผ่านอินเทอร์เฟซ MCP ที่เป็นมาตรฐานเดียวกัน โดยไม่ต้องแก้ไขบริการที่อยู่เบื้องหลัง
Control Plane
Uber ใช้สถาปัตยกรรมแบบ microservice และมีบริการภายในหลายพันตัวที่เปิด API ผ่าน HTTP, gRPC และ TChannel API เหล่านี้มอบบริบทที่มีคุณค่าให้กับระบบ AI แต่การขอให้ทีมต่าง ๆ เขียน MCP server ด้วยตนเองนั้นเชื่องช้าและยุ่งยาก เพื่อแก้ปัญหานี้ เราจึงสร้าง AutoCrawler ซึ่งจะสแกน IDL registry ของ Uber เพื่อหา API อย่างต่อเนื่อง แปลงข้อมูล และอัปเดตลงใน registry รวมถึงสอบถามเซิร์ฟเวอร์ MCP แบบ native แล้วเพิ่มเข้าไปใน registry ด้วย
AutoCrawler: เอนจินสำหรับค้นหา
Autocrawler เป็นระบบ distributed workflow ที่ขับเคลื่อนด้วย Cadence โดย subscribe กับ IDL registry และสัญญาณจากบริการภายในของ Uber ตามกำหนดเวลาที่แน่นอน cron job จะทริกเกอร์ Cadence workflow เพื่อสแกนหาบริการ API และการเปลี่ยนแปลง schema ที่เพิ่มเข้ามาใหม่
สำหรับทุก entity ที่ค้นพบ AutoCrawler จะรับผิดชอบงานต่อไปนี้:
- สร้างหรืออัปเดตตัวแทนของเซิร์ฟเวอร์ MCP
- สร้างหรือดึงคำนิยามและ schema ของเครื่องมือ
- ลงทะเบียนเครื่องมือใน MCP Registry ในสถานะปิดใช้งานเป็นค่าเริ่มต้น
รากฐานที่ใช้ร่วมกันนี้ทำให้การค้นหา MCP ขยายขนาดไปยังบริการหลายพันรายการได้ โดยที่ทีมผู้ดูแลบริการไม่ต้องมาเป็นคอขวดในกระบวนการ
รูปที่ 2: Auto Crawler
การค้นหาสำหรับบริการที่ใช้ IDL
สำหรับบริการ back-end แบบดั้งเดิมที่กำหนดผ่าน Protobuf หรือ Thrift IDLs นั้น AutoCrawler จะสร้างเซิร์ฟเวอร์และเครื่องมือ MCP จาก IDL Registry โดยตรง สำหรับแต่ละกลุ่ม API ของบริการ AutoCrawler จะทำตามขั้นตอนดังนี้:
- Upsert เซิร์ฟเวอร์ MCP: สร้างหรืออัปเดตเซิร์ฟเวอร์ MCP เสมือนที่ตรงกับบริการที่ค้นพบ
- แยกวิเคราะห์คำนิยาม IDL: แยกวิเคราะห์ไฟล์ protobuf หรือ Thrift ที่เกี่ยวข้อง เพื่อดึงชื่อเมธอด schema ของคำขอและคำตอบ รวมถึงคอมเมนต์เอกสารประกอบ
- สร้างคำอธิบายเครื่องมือ: ใช้ LLM สร้างคำอธิบายเครื่องมือ MCP ที่สมบูรณ์และเป็นมิตรต่อ agent จาก schema และคอมเมนต์ที่ดึงมา
- การแปลง Schema: แปลง schema ของ protobuf หรือ Thrift ให้เป็น JSON-RPC 2.0 schema ที่เข้ากันได้กับ MCP
- Upsert เครื่องมือ MCP: ลงทะเบียนหรืออัปเดตเครื่องมือ MCP ที่สร้างขึ้นใน MCP Registry ในสถานะปิดใช้งานเป็นค่าเริ่มต้น
การค้นหาสำหรับเซิร์ฟเวอร์แบบ Native
นอกเหนือจากบริการที่ใช้ IDL แล้ว MCP Gateway ยังรองรับเซิร์ฟเวอร์ MCP แบบ native ซึ่งเป็นบริการที่ใช้โปรโตคอล MCP โดยตรงและเปิดเครื่องมือที่ปรับแต่งมาให้เหมาะกับ agent
MCPFx คือเฟรมเวิร์กที่ Uber ใช้สร้างเซิร์ฟเวอร์ MCP แบบ native เซิร์ฟเวอร์ MCP แบบ native แต่ละตัวจะส่ง metric แบบ heartbeat เพื่อแจ้งสถานะการมีอยู่และความพร้อมใช้งาน AutoCrawler จะเฝ้าติดตามสัญญาณ heartbeat เหล่านี้อย่างต่อเนื่องเพื่อค้นหาเซิร์ฟเวอร์ MCP แบบ native ใหม่โดยอัตโนมัติ เมื่อพบเซิร์ฟเวอร์ MCP แบบ native แล้ว AutoCrawler จะใช้เส้นทางการค้นหาที่ต่างออกไป:
- เรียกใช้ listTools ไปยังเซิร์ฟเวอร์ MCP แบบ native เพื่อดึงเครื่องมือที่เปิดเผยไว้โดยเฉพาะ พร้อม schema ของเครื่องมือนั้น ๆ
- สร้างเซิร์ฟเวอร์ MCP proxy เสมือนใน MCP Registry ที่รวบรวมเครื่องมือและ schema ทั้งหมดที่ค้นพบไว้ในสถานะปิดใช้งานเป็นค่าเริ่มต้น
เซิร์ฟเวอร์ MCP ของบุคคลที่สาม
MCP Gateway ทำหน้าที่เป็นเลเยอร์ orchestration ส่วนกลางสำหรับการทำงานทั้งหมดของ MCP ทั่วทั้ง Uber โดยขยายการรองรับอย่างราบรื่นไปยังการเชื่อมต่อกับบุคคลที่สาม เช่น Jira และ Google
การจัดเตรียมเซิร์ฟเวอร์ MCP ของบุคคลที่สามต้องอาศัยการทำงานร่วมกันของสององค์ประกอบหลัก:
- MCP Gateway: ส่งต่อ user token ของผู้เรียกไปยังปลายทางถัดไป พร้อมบังคับใช้ความสามารถหลักของ gateway เช่น การตรวจสอบสิทธิ์ การจำกัดอัตราการใช้งาน และการปกปิดข้อมูลที่ละเอียดอ่อน
- บริการ MCP ของบุคคลที่สาม: แลกเปลี่ยน user token ภายในเป็นโทเค็นการยืนยันตัวตนของบุคคลที่สามที่เกี่ยวข้อง ก่อนส่งคำขอไปยังเซิร์ฟเวอร์ MCP ภายนอก
การสร้างและการเปิดใช้งาน
แม้เราจะสามารถสร้างเซิร์ฟเวอร์ MCP ได้โดยไม่ต้องให้ทีมผู้ดูแลบริการเข้ามามีส่วนร่วม แต่ความเป็นเจ้าของและการควบคุมเซิร์ฟเวอร์ MCP จะต้องอยู่กับทีมผู้ดูแลบริการ หลักการออกแบบสำคัญของ MCP Gateway คือ "การค้นพบไม่ได้หมายความว่าจะต้องเปิดใช้งานเสมอไป" เซิร์ฟเวอร์และเครื่องมือ MCP ทุกตัวจะเริ่มในสถานะปิดใช้งาน และต้องได้รับการตรวจสอบและเปิดใช้งานอย่างชัดเจนโดยทีมเจ้าของ บริการเจ้าของสามารถตรวจสอบและปรับปรุงคำนิยามเครื่องมือที่สร้างขึ้นก่อนเปิดใช้งานได้
การเปลี่ยนแปลงคำอธิบายเครื่องมือทุกครั้งจะทริกเกอร์ config change diff ซึ่งต้องได้รับการอนุมัติจากเจ้าของเซิร์ฟเวอร์ เจ้าของสามารถอนุมัติและ deploy การเปลี่ยนแปลงคอนฟิกได้ และหากจำเป็นก็สามารถ roll back กลับไปยังเวอร์ชันที่รู้จักก่อนหน้าได้
รูปที่ 3: UI ของ MCP Registry
รูปที่ 4: UI ของเครื่องมือ MCP
Data Plane
Data plane ของ MCP Gateway คือบริการรันไทม์หลักที่มีหน้าที่ประมวลผลคำขอ MCP โดยจะรับคอนฟิกของเซิร์ฟเวอร์และเครื่องมือจาก control plane อย่างต่อเนื่อง และรีเฟรชสถานะในหน่วยความจำตามรอบเวลาที่กำหนด ทำให้การเปลี่ยนแปลงคอนฟิก เช่น การอัปเดตเครื่องมือหรือการเปลี่ยนสถานะเปิด/ปิดใช้งาน มีผลทันทีโดยไม่ต้องรีสตาร์ทหรือ deploy บริการใหม่
จากคอนฟิกนี้ data plane จะสร้างเซิร์ฟเวอร์ MCP เสมือนขึ้นมาแบบไดนามิก สำหรับแต่ละเซิร์ฟเวอร์เสมือน Gateway จะเปิด endpoint /<service-name>/mcp เพียงจุดเดียวที่ทำหน้าที่เป็นทางเข้าสำหรับการประมวลผลของ AI agent คำขอที่เข้ามาจะถูกจับคู่ไปยัง handler ของเซิร์ฟเวอร์ที่เกี่ยวข้องผ่าน proxy server ที่ติดตั้งมาในตัว
รูปที่ 5: Data Plane ของ MCP Gateway
การแปลงโปรโตคอลและการประมวลผล
การแปลงโปรโตคอลใน MCP Gateway จัดการโดย server handler ภายใน Proxy Gateway โดย handler แต่ละตัวจะรับรู้ทั้งข้อมูลของเครื่องมือและปลายทางถัดไป ทำให้สามารถ route และประมวลผลคำขอ MCP ได้อย่างถูกต้องในขณะรันไทม์
ความปลอดภัย
MCP Gateway มีการตรวจสอบสิทธิ์และการปกปิดข้อมูลในตัวสำหรับทุกเซิร์ฟเวอร์ในระดับความละเอียดของเครื่องมือ โดยใช้ Access Control System ภายในของ Uber เพื่อใช้นโยบาย charter ที่แตกต่างกันซึ่งตั้งค่าไว้กับผู้เรียกที่ตรวจพบ (มนุษย์ บริการ และ agent) นโยบาย charter จะถูกสร้างขึ้นในระดับเซิร์ฟเวอร์ และสามารถ override ในระดับเครื่องมือได้ตามต้องการ
MCP Gateway ยังมีการปกปิด PII หรือข้อมูลที่ละเอียดอ่อนจากคำตอบของเครื่องมือได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติม
บริการปลายทางที่ใช้ IDL
สำหรับเครื่องมือที่ทำงานบนบริการ back-end ที่มีอยู่แล้ว server handler จะเก็บ mapping ในหน่วยความจำที่อธิบายปลายทางถัดไป เช่น คอนฟิก endpoint ของ HTTP หรือ procedure ของ gRPC/TChannel
เมื่อมีคำขอ MCP เข้ามา handler จะ:
- แปลง payload JSON ที่เข้ามาให้อยู่ในรูปแบบ wire format ที่เหมาะสม
- serialize คำขอให้เป็นไบต์ของ Protobuf หรือ Thrift
- ส่งต่อคำขอไปยังบริการปลายทาง
- แปลงคำตอบที่เป็นไบต์ของ Protobuf หรือ Thrift กลับเป็น JSON ที่เข้ากันได้กับ MCP และส่งคืนไปยัง agent ที่เรียกใช้
คำขอปลายทางจริงจะถูกประมวลผลผ่าน Muttley ซึ่งเป็น service mesh sidecar ของ Uber ที่ทำงานควบคู่ไปกับบริการ back-end ทั้งหมด การมอบหมายการประมวลผลคำขอให้ Muttley ทำให้ MCP Gateway ได้รับประโยชน์จากความสามารถในการ route ระหว่างบริการที่มีอยู่เดิมโดยอัตโนมัติ
เซิร์ฟเวอร์ MCP แบบ Native
เซิร์ฟเวอร์ MCP แบบ native จะถูกลงทะเบียนเป็นเซิร์ฟเวอร์เสมือนใน MCP registry ด้วยเช่นกัน โดยทำหน้าที่เป็น proxy ไปยังเซิร์ฟเวอร์ต้นทาง ในขณะรันไทม์ คำขอ MCP แบบ native จะถูก proxy ไปยังเซิร์ฟเวอร์ปลายทางอย่างโปร่งใส และคำตอบจะถูก proxy กลับมายังผู้เรียก
ข้อดีของ Gateway
ด้วยการสร้าง MCP-Gateway ทำให้ Uber มีแนวทางที่ขยายขนาดได้และเป็นหนึ่งเดียวในการสร้างระบบ agentic โดยข้อดีที่ส่งผลกระทบมากที่สุดมาจาก:
- การค้นหาและติดตั้งที่ง่ายดาย
- แนวทางแบบ no-code สำหรับ API ที่มีอยู่เดิม
- ระบบ observability และความปลอดภัยในตัว
- ความเป็นเจ้าของและการกำกับดูแลแบบรวมศูนย์
การขยายขีดความสามารถของ Gateway
การขยายขนาด MCP Gateway ไปยังเซิร์ฟเวอร์หลายร้อยตัวและเครื่องมือหลายพันรายการเผยให้เห็นปัญหาที่ไม่เคยเกิดในระดับเล็ก ปัญหาเรื่อง Context Bloat และต้นทุนที่สูงเกินไป
Runtime Discovery
MCP ไม่มีแนวคิดเรื่องการค้นหาข้ามเซิร์ฟเวอร์ในตัว agent ต้องรู้ล่วงหน้าว่าจะคุยกับเซิร์ฟเวอร์ใดก่อนที่จะถามว่ามีเครื่องมืออะไรให้ใช้บ้าง การตั้งค่าให้ agent ใช้เซิร์ฟเวอร์ MCP จำเป็นต้องระบุ URL ของเซิร์ฟเวอร์ ข้อมูลรับรอง และรายการเครื่องมืออย่างชัดเจน การทำเช่นนี้กับเซิร์ฟเวอร์หลายร้อยตัวไม่สามารถขยายขนาดได้ เพราะ context ทั้งหมดนี้จะกินโควตา context limit ของโมเดลจนหมด เราแก้ปัญหานี้ด้วยวิธีการต่อไปนี้
- Omni MCP - เซิร์ฟเวอร์ proxy เดียวที่ช่วยให้ไคลเอนต์ MCP เข้าถึงเซิร์ฟเวอร์ใดก็ได้ของ MCP Gateway ด้วยรูปแบบการค้นหาแบบค่อยเป็นค่อยไป ซึ่งช่วยปลดล็อกการปรับแต่ง context/token ให้มีประสิทธิภาพผ่านการค้นหาแบบเพิ่มเติม (incremental discovery) Omni MCP เปิดเครื่องมือเหล่านี้ให้ใช้งาน:
- discover_server - ค้นหาเซิร์ฟเวอร์ MCP ตามเจตนาของ query
- discover_tools - ค้นหาเครื่องมือของเซิร์ฟเวอร์
- get_tool_schema - ดึง json schema ของเครื่องมือ
- invoke_tool - เรียกใช้เครื่องมือ
เครื่องมือเหล่านี้เมื่อทำงานร่วมกันจะช่วยให้ค้นหาและเข้าถึงเซิร์ฟเวอร์ MCP ทั้งหมดได้แบบค่อยเป็นค่อยไป พร้อมระบบควบคุมการเข้าถึงในตัวและฟีเจอร์อื่น ๆ ของ gateway
- Response Projection - MCP Gateway ยังมี Response Projection ซึ่งเป็นรูปแบบการเรียกใช้คล้าย GraphQL สำหรับเครื่องมือ MCP โดยทำงานผ่านการแทรกฟิลด์ใหม่ลงใน schema คำขอของเครื่องมือ เพื่อสั่งให้ gateway ขอเฉพาะฟิลด์ที่จำเป็น ไม่ใช่ทั้งหมด LLM จะอ่านและแทรกฟิลด์ด้วย array ของ nested path เฉพาะฟิลด์ที่ต้องการ จากนั้น Gateway จะตัดคำตอบทิ้งในขณะรันไทม์โดยเก็บไว้เฉพาะฟิลด์ที่ถูก projection วิธีนี้ช่วยให้เราสามารถขยายความเข้ากันได้ของ API schema สำหรับ MCP ในระดับองค์กรได้
- Code Mode - Coding agent มักทำงานในสภาพแวดล้อม shell ที่การเขียนผลลัพธ์ของเครื่องมือลงไฟล์โดยตรงมีประสิทธิภาพมากกว่าการโหลดคำตอบทั้งหมดเข้าไปใน context ของโมเดล Code Mode รองรับรูปแบบนี้ผ่าน aifx ซึ่งเป็น CLI ของ Uber สำหรับงาน agentic โดย route การเรียก MCP ผ่าน gateway โดยไม่ต้องติดตั้งเซิร์ฟเวอร์ MCP ใด ๆ ช่วยให้ผู้แทนค้นหาเครื่องมือ MCP ที่ถูกต้องสำหรับงานได้โดยไม่ต้องมีคำนิยาม MCP อยู่ใน context aifx เปิดคำสั่งสามคำสั่ง:
- aifx mcp list - แสดงรายการเซิร์ฟเวอร์ MCP ที่ใช้งานได้
- aifx mcp search - ค้นหาเครื่องมือข้ามเซิร์ฟเวอร์ MCP ทั้งหมด
- aifx mcp call - เรียกใช้เครื่องมือ MCP ผ่าน MCP Gateway
Agent สามารถเชื่อมโยงคำสั่งเหล่านี้ในคำสั่งเดียวและเขียนผลลัพธ์ลงไฟล์ เพื่อให้ filesystem agent เลือก grep เฉพาะสิ่งที่ต้องการโหลดเข้า context ปัจจุบัน Code Mode กลายเป็นค่าเริ่มต้นของบริษัทสำหรับการใช้เครื่องมือ MCP ใน coding agent แล้ว
บทสรุป
การสร้าง MCP Gateway ได้เปลี่ยนวิธีที่ AI agent ทำงานที่ Uber ไปอย่างสิ้นเชิง สิ่งที่เริ่มต้นจากปัญหาความกระจัดกระจาย ซึ่งมีหลายสิบทีมเชื่อมต่อ MCP ด้วยตัวเองโดยใช้เครื่องมือที่ไม่สอดคล้องกัน ไม่มีการรับประกันความปลอดภัยร่วมกัน และโครงสร้างพื้นฐานที่ซ้ำซ้อน ปัจจุบันได้กลายเป็นแพลตฟอร์มที่เป็นหนึ่งเดียวและขยายขนาดได้ ซึ่งทีมใดก็สามารถเชื่อมต่อได้ภายในไม่กี่นาที
แนวคิดหลักที่ขับเคลื่อนการออกแบบของเราเรียบง่ายมาก: API ที่มีอยู่เดิมคือวิธีที่เร็วที่สุดในการจัดหาเครื่องมือให้ agent แทนที่จะขอให้ทีมต่าง ๆ เขียนบริการของตนใหม่เพื่อโลกแบบ agentic MCP Gateway กลับปรับตัวเข้าหาพวกเขา—แปลงการเรียก HTTP, gRPC และ TChannel ให้เป็นการโต้ตอบที่เข้ากันได้กับ MCP อย่างโปร่งใสผ่าน Muttley โดยไม่ต้องแก้ไขบริการปลายทางเลย
หากคุณกำลังสร้างระบบ agentic ในระดับสเกล ส่วนที่ยากที่สุดไม่ใช่ AI แต่คือการสร้างเนื้อเยื่อเกี่ยวพัน ทั้งการค้นหา ความปลอดภัย และความน่าเชื่อถือ ที่ทำให้ agent น่าเชื่อถือพอที่จะดำเนินการในนามของผู้ใช้จริงในสภาพแวดล้อม production MCP Gateway คือคำตอบของเราต่อความท้าทายนั้น และเราหวังว่าการตัดสินใจด้านการออกแบบที่บันทึกไว้ที่นี่จะเป็นประโยชน์ต่อผู้อื่นที่กำลังเผชิญปัญหาเดียวกัน
กิตติกรรมประกาศ
ที่มาของภาพหน้าปก: สร้างด้วย ChatGPT โดย OpenAI ไม่ได้ใช้รูปภาพ โลโก้ หรือทรัพยากรของบุคคลที่สามจากภายนอก
gRPC เป็นเครื่องหมายการค้าของ The Linux Foundation
ติดตามข่าวสารล่าสุดจาก Uber Engineering ได้ที่ LinkedIn เพื่อรับบทความบล็อกและข้อมูลเชิงลึกใหม่ ๆ ของเรา
