前言
Uber 快速導入 AI Agent，徹底改變了團隊與程式碼、資料及營運系統的互動方式。早期與 MCP（Model Context Protocol）的臨時整合就展現出明顯價值：當 Agent 能存取即時業務情境、查詢內部服務，並代表使用者執行有意義的操作時，能力便大幅提升。這些早期成果驗證了 MCP 是在 Uber 內部建構 Agentic 系統的強大抽象層。
然而，隨著採用速度加快，重大挑戰也隨之浮現。各團隊各自獨立開發整合方案，導致工具碎片化與基礎設施重複建設。MCP 工具難以被發現、不易穩定運作，且與特定服務或 Agent 實作高度耦合。這些做法在小規模時還行得通，但當數百個團隊開始探索 Agentic 工作流程時，就無法滿足 Uber 的需求。若缺乏統一架構，擴展 MCP 只會增加營運複雜度、安全風險與開發者摩擦，最終限制其影響力。
要在 Uber 的規模下釋放 MCP 的全部潛力，我們需要一個集中式、可擴展的解決方案，來標準化 AI Agent 與現有後端系統的互動方式，同時保留團隊所需的彈性。這個解決方案必須抽象化協定差異（HTTP、gRPC™、TChannel）、強制落實一致的安全性與可觀測性保障，並讓全公司都能輕鬆建立、發現與重複使用 MCP 工具。
為此，我們打造了 MCP Gateway。它是一個基礎微服務，支撐 Uber 所有的 MCP 互動，作為 AI Agent 與現有後端服務及原生 MCP 伺服器之間的協調與路由層。透過將 MCP 邏輯集中到單一閘道，我們為 Agent 與服務的互動提供一致的執行模型，同時免去團隊重複打造核心基礎設施的負擔。現有 API 可以無縫公開為 MCP 工具，在同一處進行治理與營運，並由多個 Agent 以統一方式取用。MCP Gateway 為在 Uber 內部建構 AI Agent 開闢了一條可擴展、快速且一致的路徑，目前託管超過 800 個 MCP 伺服器與 5000 多個工具。
圖 1：MCP Gateway（將 API 作為工具）。
在這篇文章中，我們將回顧 MCP Gateway 的設計，涵蓋 Proxy Layer（代理層，負責 MCP 與現有協定之間的雙向轉譯）、Discovery Layer（發現層，包含 MCP Registry 與 API 爬蟲），以及其控制平面（編寫管理）。
Gateway
MCP Gateway 採用微服務架構，閘道扮演 AI 系統與 Uber 後端服務之間的中央整合點。平台由兩個主要元件組成：作為控制平面的 MCP Registry，以及構成資料平面的 Proxy Gateway。
MCP Registry 維護了一份目錄，收錄數百個由內部服務支援的 MCP 伺服器，以及數千個 MCP 工具。這些工具的範圍很廣，從將現有 API 公開為 MCP 工具的無程式碼定義，到完全依照 MCP 規範打造的原生實作都有。Registry 為整個生態系提供了發現、所有權與啟用的唯一事實來源。
Proxy Gateway 負責在執行階段處理 MCP 請求。它會將 MCP 協定呼叫轉譯為 HTTP、gRPC 或 TChannel 請求，轉發至對應的後端服務，再將回應轉換回 MCP 相容的結果。這個轉譯層讓 AI Agent 能透過一致的 MCP 介面與現有系統互動，而不需修改底層服務。
控制平面
Uber 採用微服務架構，運行著數千個透過 HTTP、gRPC 與 TChannel 公開 API 的內部服務。這些 API 能為 AI 系統提供寶貴的情境資訊，但若要求團隊手動編寫 MCP 伺服器，過程會既緩慢又痛苦。為了解決這個問題，我們打造了 AutoCrawler，它會持續掃描 Uber 的 IDL Registry 尋找 API、進行轉譯，並在 Registry 中更新。它也會查詢原生 MCP 伺服器並將其加入 Registry。
AutoCrawler：發現引擎
AutoCrawler 是一個由 Cadence 驅動的分散式工作流程系統，訂閱了 Uber 的 IDL Registry 與內部服務訊號。系統會依固定排程，透過 cron job 觸發 Cadence 工作流程，掃描新加入的服務、API 與結構描述變更。
對於每個發現到的實體，AutoCrawler 負責：
- 建立或更新 MCP 伺服器的表示
- 產生或取得工具定義與結構描述
- 以預設停用狀態將工具註冊到 MCP Registry
這個共享基礎讓 MCP 的發現機制能擴展至數千個服務，同時避免服務團隊成為關鍵路徑上的瓶頸。
圖 2：Auto Crawler。
IDL 支援服務的發現
對於透過 Protobuf 或 Thrift IDL 定義的傳統後端服務，AutoCrawler 會直接從 IDL Registry 衍生出 MCP 伺服器與工具。針對每個服務：API 群組，AutoCrawler 會執行以下步驟：
- 新增或更新 MCP 伺服器：建立或更新與所發現服務對應的虛擬 MCP 伺服器。
- 剖析 IDL 定義：剖析相關的 protobuf 或 Thrift 檔案，擷取方法名稱、請求與回應結構描述，以及文件註解。
- 產生工具描述：運用 LLM，根據擷取的結構描述與註解，產生更豐富且對 Agent 友善的 MCP 工具描述。
- 結構描述轉譯：將 protobuf 或 Thrift 結構描述轉譯為 MCP 相容的 JSON-RPC 2.0 結構描述。
- 新增或更新 MCP 工具：以預設停用狀態，將產生的 MCP 工具註冊或更新至 MCP Registry。
原生伺服器的發現
除了 IDL 支援的服務外，MCP Gateway 也支援原生 MCP 伺服器——也就是直接實作 MCP 協定並公開 Agent 最佳化工具的服務。
MCPFx 是 Uber 用來建構原生 MCP 伺服器的框架。每個原生 MCP 伺服器都會發出心跳指標，表明自身的存在與就緒狀態。AutoCrawler 會持續監控這些心跳訊號，自動發現新的原生 MCP 伺服器。當發現原生 MCP 伺服器時，AutoCrawler 會走另一條發現路徑：
- 對原生 MCP 伺服器發出 listTools 呼叫，取得它明確公開的工具及其結構描述。
- 在 MCP Registry 中建立一個虛擬代理 MCP 伺服器，以預設停用狀態收錄所有發現到的工具及其結構描述。
第三方 MCP 伺服器
MCP Gateway 是 Uber 所有 MCP 互動的集中協調層，也能無縫支援 Jira 與 Google 等第三方整合。
佈建第三方 MCP 伺服器仰賴兩個關鍵元件的協作：
- MCP Gateway：將呼叫者的使用者權杖往下游傳遞，同時強制執行授權、速率限制與敏感資料遮蔽等核心閘道功能。
- 第三方 MCP 服務：在將請求派發至外部 MCP 伺服器前，先將內部使用者權杖交換為對應的第三方驗證權杖。
編寫與啟用
雖然我們可以在不牽涉服務團隊的情況下建立 MCP 伺服器，但 MCP 伺服器的所有權與控制權仍必須歸屬於服務團隊。MCP Gateway 的一項核心設計原則是：「被發現」不等於「被公開」。每個 MCP 伺服器與工具一開始都處於停用狀態，必須由擁有團隊明確審查並啟用。服務擁有者可以在啟用前，先檢視並調整產生的工具定義。
任何工具描述的變更都會觸發設定變更差異比對，且必須經伺服器擁有者核准。擁有者可以核准並部署設定變更，必要時也能回復到先前已知的版本。
圖 3：MCP Registry UI。
圖 4：MCP 工具 UI。
資料平面
MCP Gateway 資料平面是負責執行 MCP 請求的核心執行階段服務。它會持續從控制平面接收伺服器與工具設定，並以固定頻率重新整理記憶體中的狀態，讓工具更新或啟用狀態變更等設定異動，能在不需重啟或重新部署服務的情況下即時生效。
資料平面會根據這些設定，動態具體化虛擬 MCP 伺服器。針對每個虛擬伺服器，Gateway 會公開單一的 /<service-name>/mcp 端點，作為 AI Agent 執行的進入點。傳入的請求會透過內建的代理伺服器，解析至對應的伺服器處理常式。
圖 5：MCP Gateway 資料平面。
協定轉譯與執行
MCP Gateway 中的協定轉譯由 Proxy Gateway 內的伺服器處理常式負責。每個處理常式都具備工具感知與下游感知能力，因此能在執行階段正確路由並執行 MCP 請求。
安全性
MCP Gateway 為所有伺服器提供內建的授權與遮蔽功能，細緻度達到工具層級。MCP Gateway 使用 Uber 內部的存取控制系統，針對偵測到的呼叫者角色（人員、服務與 Agent）套用不同的 Charter 政策。Charter 政策在伺服器層級建立，必要時也可選擇在工具層級覆寫。
MCP Gateway 也會開箱即用地遮蔽工具回應中的任何 PII 或敏感資料。
IDL 支援的下游服務
對於由現有後端服務支援的工具，伺服器處理常式會在記憶體中維護一份對應關係，描述下游目的地，例如 HTTP 端點設定或 gRPC/TChannel 程序。
當 MCP 請求抵達時，處理常式會：
- 將傳入的 JSON 負載轉譯為適當的線路格式。
- 將請求序列化為 Protobuf 或 Thrift 位元組。
- 將請求轉發至下游服務。
- 將 Protobuf 或 Thrift 位元組回應轉譯回 MCP 相容的 JSON，並回傳給呼叫的 Agent。
實際的下游請求是透過 Muttley 執行的，它是 Uber 的服務網格 sidecar，與所有後端服務一同運行。藉由將請求執行委派給 Muttley，MCP Gateway 能自動享有現有的服務對服務路由能力。
原生 MCP 伺服器
原生 MCP 伺服器同樣會以虛擬伺服器形式註冊於 MCP Registry 中，而 Registry 則扮演通往原始伺服器的代理角色。在執行階段，原生 MCP 請求會透明地代理至下游伺服器，回應也會代理回呼叫者。
Gateway 的優勢
透過打造 MCP Gateway，Uber 實現了可擴展且統一的 Agentic 系統建構方式，其中最具影響力的優勢包括：
- 輕鬆發現與安裝
- 針對現有 API 的無程式碼方案
- 內建的可觀測性與安全性
- 集中的所有權與治理
擴展 Gateway
將 MCP Gateway 擴展至數百個伺服器與數千個工具後，一些在小規模下不會出現的問題也隨之浮現，例如情境膨脹與成本過高。
執行階段發現
MCP 本身沒有跨伺服器搜尋的原生概念。Agent 必須先知道要與哪個伺服器溝通，才能詢問有哪些可用工具。若要設定 Agent 使用某個 MCP 伺服器，就得明確接上伺服器 URL、憑證與工具清單。對數百個伺服器這樣做根本無法擴展，因為所有這些情境資訊會迅速耗盡模型的上下文限制。我們透過以下方式解決了這個問題：
- Omni MCP —— 單一代理伺服器，讓 MCP 客戶端能以漸進式發現模式存取 MCP Gateway 的任何伺服器，同時也透過增量發現實現情境／token 最佳化。Omni MCP 公開了以下工具：
- discover_server —— 根據查詢意圖發現 MCP 伺服器
- discover_tools —— 查詢某伺服器的工具
- get_tool_schema —— 取得某工具的 JSON 結構描述
- invoke_tool —— 呼叫某工具
這些工具共同實現了對所有 MCP 伺服器的增量發現與存取，並內建存取控制及其他閘道功能。
- Response Projection（回應投影） —— MCP Gateway 也提供 Response Projection，一種類似 GraphQL 的 MCP 工具呼叫模式。它的作法是在工具請求結構描述中注入一個新欄位，指示閘道只索取需要的欄位，而非全部。LLM 會讀取並注入僅含必要欄位的巢狀路徑陣列。接著，Gateway 會在執行階段修剪回應，只保留投影出的欄位。這讓我們能在企業層級擴展 MCP 的 API 結構描述相容性。
- Code Mode（程式碼模式） —— 程式設計 Agent 通常在 shell 環境中運作，此時將工具輸出直接寫入檔案，會比把完整回應載入模型情境更有效率。Code Mode 透過 aifx（Uber 用於 Agentic 操作的 CLI）支援這種模式，將 MCP 呼叫經由閘道路由，而不需安裝任何 MCP 伺服器。它能協助 Agent 在情境中沒有 MCP 定義的情況下，找出適合該工作的 MCP 工具。aifx 公開了三個指令：
- aifx mcp list —— 列出可用的 MCP 伺服器
- aifx mcp search —— 在所有 MCP 伺服器中搜尋工具
- aifx mcp call —— 透過 MCP Gateway 呼叫 MCP 工具
Agent 可以在單一指令中串聯這些操作並將輸出寫入檔案，再由檔案系統 Agent 選擇性地 grep，只將需要的內容載入情境。Code Mode 現在已是全公司在程式設計 Agent 中使用 MCP 工具的預設方式。
結語
打造 MCP Gateway 從根本上改變了 AI Agent 在 Uber 的運作方式。起初，這是一個碎片化問題：數十個團隊各自接上 MCP 整合，工具不一致、缺乏共通的安全保障，基礎設施也不斷重複建設；如今，它已成為一個統一且可擴展的平台，任何團隊都能在幾分鐘內接入。
驅動我們設計的核心洞察其實很簡單：現有 API 是為 Agent 提供工具最快的途徑。與其要求團隊為了 Agentic 世界重寫服務，MCP Gateway 選擇順應他們現有的架構——透過 Muttley 透明地將 HTTP、gRPC 與 TChannel 呼叫轉譯為 MCP 相容的互動，且完全不須改動下游服務。
如果你正在大規模建構 Agentic 系統，最難的部分並不是 AI，而是打造那些連結組織——發現機制、安全性、可靠性——讓 Agent 值得信賴到足以在生產環境中代表真實使用者採取行動。MCP Gateway 就是我們對這項挑戰的解答，也希望這裡記錄的設計決策，能對面臨相同問題的人有所幫助。
致謝
封面照片來源：使用 OpenAI 的 ChatGPT 生成；未使用任何外部圖片、標誌或第三方素材。
gRPC 是 The Linux Foundation 的商標。
想掌握 Uber Engineering 的最新動態，歡迎在 LinkedIn 追蹤我們，獲取最新部落格文章與深度見解。
