Giới thiệu
Việc Uber nhanh chóng ứng dụng các AI agent đã thay đổi hoàn toàn cách các nhóm làm việc tương tác với mã nguồn, dữ liệu và hệ thống vận hành. Những tích hợp ban đầu mang tính tự phát với MCP (Model Context Protocol) đã cho thấy giá trị rõ rệt: các agent trở nên mạnh mẽ hơn hẳn khi có thể truy cập ngữ cảnh nghiệp vụ theo thời gian thực, truy vấn dịch vụ nội bộ và thay mặt người dùng thực hiện các hành động thiết thực. Những thành công bước đầu này đã khẳng định MCP là một lớp trừu tượng mạnh mẽ để xây dựng các hệ thống agentic bên trong Uber.
Tuy nhiên, khi mức độ ứng dụng tăng tốc, nhiều thách thức lớn cũng xuất hiện. Các nhóm tự xây dựng tích hợp một cách độc lập, dẫn đến sự phân mảnh về công cụ và trùng lặp hạ tầng. Các công cụ MCP rất khó tìm kiếm, khó vận hành ổn định và bị gắn chặt vào những dịch vụ hoặc cách triển khai agent cụ thể. Dù những cách tiếp cận này hoạt động tốt ở quy mô nhỏ, chúng không đáp ứng được nhu cầu của Uber khi hàng trăm nhóm bắt đầu khám phá các luồng công việc agentic. Nếu thiếu một kiến trúc thống nhất, việc mở rộng MCP sẽ làm tăng độ phức tạp vận hành, rủi ro bảo mật và rào cản đối với lập trình viên, cuối cùng giới hạn mức độ ảnh hưởng của nó.
Để khai thác trọn vẹn tiềm năng của MCP ở quy mô của Uber, chúng tôi cần một giải pháp tập trung, có khả năng mở rộng nhằm chuẩn hóa cách các AI agent tương tác với hệ thống back-end hiện tại, đồng thời vẫn giữ được sự linh hoạt cho từng nhóm. Giải pháp này phải trừu tượng hóa được sự khác biệt giữa các giao thức (HTTP, gRPC™, TChannel), đảm bảo các cam kết nhất quán về bảo mật và khả năng quan sát (observability), đồng thời giúp việc tạo, tìm kiếm và tái sử dụng công cụ MCP trên toàn công ty trở nên dễ dàng.
Chúng tôi đã xây dựng MCP Gateway để giải quyết nhu cầu đó. Đây là một microservice nền tảng xử lý mọi tương tác MCP tại Uber, đóng vai trò là lớp điều phối và định tuyến giữa các AI agent với dịch vụ back-end hiện có cùng các máy chủ MCP native. Bằng cách tập trung logic MCP vào một gateway duy nhất, chúng tôi cung cấp một mô hình thực thi nhất quán cho các tương tác giữa agent và dịch vụ, đồng thời loại bỏ việc các nhóm phải tự xây dựng lại hạ tầng cốt lõi. Các API hiện có có thể được chuyển đổi liền mạch thành công cụ MCP, được quản lý và vận hành tại một nơi duy nhất, và được nhiều agent sử dụng theo một cách thống nhất. MCP Gateway đã mở ra con đường mở rộng, nhanh chóng và nhất quán để xây dựng AI agent trong nội bộ Uber, hiện đang vận hành hơn 800 máy chủ MCP và hơn 5000 công cụ.
Hình 1: MCP Gateway (API dưới dạng công cụ).
Trong bài viết này, chúng tôi sẽ điểm qua thiết kế của MCP Gateway, bao gồm Proxy Layer (lớp chuyển đổi từ MCP sang các giao thức hiện có và ngược lại), Discovery Layer (MCP Registry và cơ chế quét API), cùng control plane (phần biên soạn cấu hình).
Gateway
MCP Gateway tuân theo kiến trúc dựa trên microservice, trong đó gateway đóng vai trò là điểm tích hợp trung tâm giữa các hệ thống hỗ trợ AI và dịch vụ back-end của Uber. Nền tảng này gồm hai thành phần chính: MCP Registry đóng vai trò control plane, và Proxy Gateway tạo thành data plane.
MCP Registry duy trì danh mục hàng trăm máy chủ MCP được hỗ trợ bởi các dịch vụ nội bộ, cùng hàng ngàn công cụ MCP. Các công cụ này trải dài từ những định nghĩa no-code (biến API hiện có thành công cụ MCP) cho đến các bản triển khai native hoàn toàn được xây dựng chuyên biệt theo đặc tả MCP. Registry cung cấp một nguồn dữ liệu duy nhất đáng tin cậy cho việc khám phá, xác định quyền sở hữu và kích hoạt trên toàn hệ sinh thái.
Proxy Gateway chịu trách nhiệm thực thi các yêu cầu MCP tại runtime. Nó chuyển đổi lời gọi giao thức MCP thành yêu cầu HTTP, gRPC hoặc TChannel, chuyển tiếp chúng đến dịch vụ back-end phù hợp, rồi chuyển đổi phản hồi ngược lại thành kết quả tương thích MCP. Lớp chuyển đổi này cho phép AI agent tương tác với hệ thống hiện có thông qua một giao diện MCP nhất quán mà không cần thay đổi dịch vụ nền tảng bên dưới.
Control Plane
Uber sử dụng kiến trúc microservice và vận hành hàng ngàn dịch vụ nội bộ cung cấp API qua HTTP, gRPC và TChannel. Các API này mang lại ngữ cảnh giá trị cho hệ thống AI, nhưng nếu yêu cầu các nhóm tự tay biên soạn máy chủ MCP thì quá trình sẽ rất chậm chạp và vất vả. Để giải quyết vấn đề này, chúng tôi xây dựng AutoCrawler — công cụ liên tục quét IDL registry của Uber để tìm API, chuyển đổi và cập nhật chúng vào registry. Nó cũng truy vấn các máy chủ MCP native và thêm chúng vào registry.
AutoCrawler: Công cụ khám phá
AutoCrawler là một hệ thống workflow phân tán chạy trên Cadence, được đăng ký theo dõi IDL registry và các tín hiệu dịch vụ nội bộ của Uber. Theo lịch cố định, một cron job sẽ kích hoạt workflow Cadence để quét các dịch vụ, API và thay đổi schema mới được thêm vào.
Với mỗi thực thể được phát hiện, AutoCrawler chịu trách nhiệm:
- Tạo hoặc cập nhật biểu diễn của máy chủ MCP
- Tạo hoặc lấy định nghĩa và schema của công cụ
- Đăng ký công cụ vào MCP Registry ở trạng thái mặc định tắt
Nền tảng dùng chung này giúp việc khám phá MCP có thể mở rộng tới hàng ngàn dịch vụ mà không đặt các nhóm dịch vụ vào vị trí nút thắt cổ chai.
Hình 2: Auto Crawler.
Khám phá các dịch vụ dựa trên IDL
Đối với các dịch vụ back-end truyền thống được định nghĩa qua Protobuf hoặc Thrift IDL, AutoCrawler suy ra máy chủ và công cụ MCP trực tiếp từ IDL Registry. Với mỗi nhóm API của dịch vụ, AutoCrawler thực hiện các bước sau:
- Upsert máy chủ MCP: Tạo hoặc cập nhật một máy chủ MCP ảo tương ứng với dịch vụ vừa phát hiện.
- Phân tích định nghĩa IDL: Phân tích các tệp protobuf hoặc Thrift liên quan để trích xuất tên phương thức, schema request/response và comment tài liệu.
- Tạo mô tả công cụ: Sử dụng LLM để tạo các mô tả công cụ MCP chi tiết, thân thiện với agent dựa trên schema và comment đã trích xuất.
- Chuyển đổi schema: Chuyển đổi schema protobuf hoặc Thrift thành schema JSON-RPC 2.0 tương thích MCP.
- Upsert công cụ MCP: Đăng ký hoặc cập nhật các công cụ MCP vừa tạo vào MCP Registry ở trạng thái mặc định tắt.
Khám phá máy chủ Native
Bên cạnh các dịch vụ dựa trên IDL, MCP Gateway còn hỗ trợ máy chủ MCP native — những dịch vụ triển khai trực tiếp giao thức MCP và cung cấp các công cụ được tối ưu cho agent.
MCPFx là framework mà Uber sử dụng để xây dựng máy chủ MCP native. Mỗi máy chủ MCP native phát ra một metric heartbeat báo hiệu sự hiện diện và trạng thái sẵn sàng. AutoCrawler liên tục giám sát các tín hiệu heartbeat này để tự động phát hiện máy chủ MCP native mới. Khi phát hiện một máy chủ MCP native, AutoCrawler sẽ đi theo một luồng khám phá khác:
- Nó gọi listTools tới máy chủ MCP native để lấy danh sách công cụ mà máy chủ này chủ động cung cấp, kèm theo schema tương ứng.
- Nó tạo một máy chủ MCP proxy ảo trong MCP Registry chứa toàn bộ công cụ và schema vừa phát hiện, ở trạng thái mặc định tắt.
Máy chủ MCP của bên thứ ba (3P)
MCP Gateway đóng vai trò là lớp điều phối tập trung cho mọi tương tác MCP trên toàn Uber, mở rộng hỗ trợ liền mạch cho các tích hợp bên thứ ba như Jira và Google.
Việc cấp phát máy chủ MCP của bên thứ ba phụ thuộc vào sự phối hợp của hai thành phần chính:
- MCP Gateway: Chuyển tiếp user token của người gọi xuống hạ nguồn, đồng thời thực thi các năng lực thiết yếu của gateway như xác thực quyền, giới hạn tốc độ (rate limiting) và che giấu dữ liệu nhạy cảm.
- Dịch vụ MCP bên thứ ba: Đổi token người dùng nội bộ lấy token xác thực tương ứng của bên thứ ba trước khi gửi yêu cầu đến máy chủ MCP bên ngoài.
Biên soạn và Kích hoạt
Dù chúng tôi có thể tạo máy chủ MCP mà không cần sự tham gia của nhóm dịch vụ, quyền sở hữu và kiểm soát máy chủ MCP đó vẫn phải thuộc về nhóm dịch vụ. Một nguyên tắc thiết kế cốt lõi của MCP Gateway là: việc phát hiện không đồng nghĩa với việc công khai. Mọi máy chủ và công cụ MCP đều bắt đầu ở trạng thái tắt, và phải được nhóm sở hữu xem xét, bật lên một cách rõ ràng. Chủ sở hữu dịch vụ có thể xem xét và tinh chỉnh định nghĩa công cụ được tạo ra trước khi kích hoạt chúng.
Mọi thay đổi trong mô tả công cụ đều tạo ra một bản diff cấu hình, và bản này phải được chủ sở hữu máy chủ phê duyệt. Chủ sở hữu có thể phê duyệt, triển khai thay đổi cấu hình, và nếu cần, quay về phiên bản ổn định trước đó.
Hình 3: Giao diện MCP Registry.
Hình 4: Giao diện công cụ MCP.
Data Plane
Data plane của MCP Gateway là dịch vụ runtime cốt lõi chịu trách nhiệm thực thi các yêu cầu MCP. Nó liên tục tiêu thụ cấu hình máy chủ và công cụ từ control plane, đồng thời làm mới trạng thái trong bộ nhớ theo chu kỳ cố định. Nhờ vậy, các thay đổi cấu hình như cập nhật công cụ hay thay đổi trạng thái kích hoạt đều có hiệu lực ngay lập tức mà không cần khởi động lại hay triển khai lại dịch vụ.
Dựa trên cấu hình này, data plane sẽ vật chất hóa (materialize) các máy chủ MCP ảo một cách động. Với mỗi máy chủ ảo, Gateway cung cấp một endpoint duy nhất /<service-name>/mcp làm điểm vào cho việc thực thi của AI agent. Các yêu cầu đến được phân giải tới handler máy chủ tương ứng thông qua một proxy server tích hợp sẵn.
Hình 5: Data Plane của MCP Gateway.
Chuyển đổi giao thức và Thực thi
Việc chuyển đổi giao thức trong MCP Gateway được xử lý bởi các server handler bên trong Proxy Gateway. Mỗi server handler đều nhận biết được công cụ và dịch vụ hạ nguồn, cho phép nó định tuyến và thực thi chính xác các yêu cầu MCP tại runtime.
Bảo mật
MCP Gateway cung cấp sẵn cơ chế xác thực quyền và che giấu dữ liệu cho tất cả máy chủ ở mức độ chi tiết từng công cụ. MCP Gateway sử dụng Hệ thống Kiểm soát Truy cập nội bộ của Uber để áp dụng các chính sách charter khác nhau, được cấu hình dựa trên actor gọi đến (con người, dịch vụ và agent). Chính sách charter được tạo ở cấp máy chủ, kèm tùy chọn ghi đè ở cấp công cụ nếu cần.
MCP Gateway cũng tự động che giấu mọi dữ liệu PII hoặc dữ liệu nhạy cảm trong phản hồi của công cụ ngay từ đầu.
Dịch vụ hạ nguồn dựa trên IDL
Đối với các công cụ được hỗ trợ bởi dịch vụ back-end hiện có, server handler duy trì một bảng ánh xạ trong bộ nhớ mô tả đích đến hạ nguồn, chẳng hạn như cấu hình endpoint HTTP hoặc procedure gRPC/TChannel.
Khi một yêu cầu MCP đến, handler sẽ:
- Chuyển đổi payload JSON đầu vào sang định dạng truyền tải (wire format) phù hợp.
- Tuần tự hóa yêu cầu thành byte Protobuf hoặc Thrift.
- Chuyển tiếp yêu cầu đến dịch vụ hạ nguồn.
- Chuyển đổi phản hồi dạng byte Protobuf hoặc Thrift ngược lại thành JSON tương thích MCP và trả về cho agent gọi.
Yêu cầu hạ nguồn thực tế được thực thi qua Muttley — service mesh sidecar của Uber chạy song song với mọi dịch vụ back-end. Bằng cách ủy thác việc thực thi yêu cầu cho Muttley, MCP Gateway tự động tận dụng được các năng lực định tuyến dịch vụ-đến-dịch vụ sẵn có.
Máy chủ MCP Native
Các máy chủ MCP native cũng được đăng ký dưới dạng máy chủ ảo trong MCP registry, và registry này đóng vai trò proxy tới máy chủ gốc. Tại runtime, các yêu cầu MCP native được proxy một cách trong suốt tới máy chủ hạ nguồn, và phản hồi được proxy ngược lại cho người gọi.
Lợi ích của Gateway
Nhờ xây dựng MCP-Gateway, Uber đã đạt được cách tiếp cận thống nhất và có khả năng mở rộng để phát triển các hệ thống agentic, với những lợi ích nổi bật nhất đến từ:
- Dễ dàng khám phá và cài đặt
- Cách tiếp cận no-code đối với các API hiện có
- Khả năng quan sát và bảo mật tích hợp sẵn
- Quyền sở hữu và quản trị tập trung
Mở rộng Gateway
Việc mở rộng MCP Gateway lên hàng trăm máy chủ và hàng ngàn công cụ đã bộc lộ những vấn đề không tồn tại ở quy mô nhỏ. Phình to ngữ cảnh và Chi phí quá mức
Khám phá tại Runtime
MCP không có khái niệm native về tìm kiếm liên máy chủ. Một agent phải biết trước cần nói chuyện với máy chủ nào thì mới hỏi được có những công cụ gì. Việc cấu hình một agent sử dụng máy chủ MCP đòi hỏi phải nối dây tường minh URL máy chủ, thông tin xác thực và danh sách công cụ. Làm điều này với hàng trăm máy chủ là bất khả thi khi mở rộng, vì toàn bộ ngữ cảnh đó sẽ ngốn hết giới hạn context của model. Chúng tôi giải quyết vấn đề này bằng cách sau:
- Omni MCP - Một proxy server duy nhất cho phép client MCP truy cập bất kỳ máy chủ nào của MCP Gateway theo mô hình khám phá dần dần, đồng thời mở ra khả năng tối ưu context/token nhờ khám phá tăng dần. Omni MCP cung cấp các công cụ sau:
- discover_server - khám phá máy chủ MCP dựa trên ý định của truy vấn
- discover_tools - tra cứu công cụ của một máy chủ
- get_tool_schema - lấy json schema của một công cụ
- invoke_tool - gọi một công cụ
Kết hợp lại, các công cụ này cho phép khám phá và truy cập tăng dần tới mọi máy chủ MCP, đi kèm kiểm soát truy cập tích hợp sẵn cùng toàn bộ tính năng khác của gateway.
- Response Projection - MCP Gateway cũng cung cấp Response Projection, một mẫu gọi kiểu GraphQL dành cho công cụ MCP. Cơ chế này hoạt động bằng cách chèn thêm một trường mới vào schema request của công cụ, chỉ thị cho gateway chỉ yêu cầu những trường cần thiết chứ không lấy tất cả. LLM sẽ đọc và chèn vào một mảng các đường dẫn lồng nhau chỉ chứa những trường bắt buộc. Sau đó, Gateway cắt bớt phản hồi tại runtime bằng cách chỉ giữ lại các trường được chiếu (projected). Điều này giúp chúng tôi mở rộng khả năng tương thích schema API cho MCP ở cấp độ doanh nghiệp.
- Code Mode - Các coding agent thường hoạt động trong môi trường shell, nơi việc ghi trực tiếp output của công cụ ra tệp sẽ hiệu quả hơn so với nạp toàn bộ phản hồi vào context của model. Code Mode phục vụ mô hình này thông qua aifx — CLI của Uber dành cho các thao tác agentic, định tuyến lời gọi MCP qua gateway mà không cần cài đặt bất kỳ máy chủ MCP nào. Nó giúp agent tìm ra đúng công cụ MCP cho công việc mà không cần định nghĩa MCP hiện diện trong context. aifx cung cấp ba lệnh:
- aifx mcp list - liệt kê các máy chủ MCP khả dụng
- aifx mcp search - tìm kiếm công cụ trên tất cả máy chủ MCP
- aifx mcp call - gọi một công cụ MCP thông qua MCP Gateway
Các agent có thể xâu chuỗi những lệnh này trong một câu lệnh duy nhất và ghi output ra tệp, sau đó agent thao tác với hệ thống tệp sẽ grep chọn lọc, chỉ nạp vào context những gì chúng cần. Code Mode hiện là lựa chọn mặc định của toàn công ty cho việc sử dụng công cụ MCP trong các coding agent.
Kết luận
Việc xây dựng MCP Gateway đã thay đổi căn bản cách các AI agent hoạt động tại Uber. Từ một bài toán phân mảnh — khi hàng chục nhóm tự nối dây tích hợp MCP một cách độc lập với công cụ thiếu nhất quán, không chia sẻ cam kết bảo mật và trùng lặp hạ tầng — nay đã trở thành một nền tảng thống nhất, có khả năng mở rộng mà bất kỳ nhóm nào cũng có thể kết nối chỉ trong vài phút.
Nguyên lý cốt lõi dẫn dắt thiết kế của chúng tôi rất đơn giản: các API hiện có là con đường nhanh nhất để cung cấp công cụ cho agent. Thay vì yêu cầu các nhóm viết lại dịch vụ của họ cho thế giới agentic, MCP Gateway đồng hành cùng họ ngay tại vị trí hiện tại — chuyển đổi các lời gọi HTTP, gRPC và TChannel thành tương tác tương thích MCP một cách trong suốt thông qua Muttley, mà không cần thay đổi gì ở dịch vụ hạ nguồn.
Nếu bạn đang xây dựng hệ thống agentic ở quy mô lớn, phần khó nhất không nằm ở AI. Phần khó nhất là xây dựng "mô liên kết" — khả năng khám phá, bảo mật, độ tin cậy — giúp agent đủ đáng tin để hành động thay mặt người dùng thật trong môi trường production. MCP Gateway là câu trả lời của chúng tôi cho thách thức đó, và chúng tôi hy vọng những quyết định thiết kế được ghi lại ở đây sẽ hữu ích cho những ai đang đối mặt với cùng bài toán.
Lời cảm ơn
Nguồn ảnh bìa: Được tạo bằng ChatGPT của OpenAI; không sử dụng hình ảnh, logo hay tài sản bên thứ ba nào từ bên ngoài.
gRPC là thương hiệu của The Linux Foundation.
Cập nhật những tin tức mới nhất từ Uber Engineering — hãy theo dõi chúng tôi trên LinkedIn để đọc các bài viết và góc nhìn mới nhất.
