AI 模型與平台更新代理程式基礎架構編輯推薦

Uber 的 MCP Gateway：擴展代理程式對數千個內部 API 的存取

Uber 建置了 MCP Gateway，讓 AI 代理程式能存取數千個內部 API，而不必要求每個團隊都撰寫 MCP 伺服器。本文將說明 AutoCrawler、集中式探索、協定轉換、政策控管與營運模式，以及為什麼 Gateway 層正逐漸成為企業代理程式不可或缺的基礎架構。

NexusAI Editorial Desk2026年10月6日1.7K 次閱讀8 分鐘閱讀

AI 簡報

Uber 的 MCP Gateway 解決了大型企業部署代理程式時都會面臨的擴展問題：如何讓自主系統使用數千個既有 API，同時不要求工程團隊改寫服務或打造專用 MCP 伺服器。本文剖析 Gateway 的雙平面設計、AutoCrawler 探索流程、執行階段協定轉換，以及政策與遮蔽控管；並介紹 Omni MCP、Response Projection、Code Mode 等可降低權杖與成本負擔的營運模式，同時說明採用 Gateway 優先的代理程式基礎架構方案時，企業應留意的風險、所有權模式與實務步驟。

企業 AI 代理程式唯有取得可靠、最新的業務脈絡並能據此採取行動，才能真正發揮作用。Uber 的 MCP Gateway 回應了一個具體卻無可避免的問題：如何讓代理程式在受控且可探索的情況下存取數千個既有 API，同時不必要求每個服務團隊都實作 MCP 伺服器？Gateway 集中處理探索、轉換與政策執行，讓服務團隊不必成為關鍵路徑的一環——他們不需要改寫端點，服務負責人也能保有審核與啟用的控制權。這種取捨可減少重複建置基礎架構、統一治理方式，同時維持各團隊的營運自主性。

在架構上，Gateway 分為控制平面（MCP Registry 與 AutoCrawler）和資料平面（Proxy Gateway）。Registry 是虛擬伺服器與工具的唯一真實來源；AutoCrawler 則持續根據 IDL 與原生 MCP 伺服器產生工具定義，讓目錄自動擴展。Proxy Gateway 會在執行階段具現化虛擬 MCP 伺服器，將 MCP 呼叫轉換為 HTTP/gRPC/TChannel，交由服務網格 sidecar（Muttley）執行，再傳回符合 MCP 格式的結果。這種分離方式讓系統得以快速迭代、即時更新設定，並為各式代理程式用戶端提供一致的執行模式。

AutoCrawler 是讓整套系統得以運作的關鍵營運槓桿。Uber 不依賴人工撰寫，而是採用由 Cadence 驅動的工作流程，掃描 IDL Registry、監控原生 MCP 心跳、解析 protobuf/Thrift 定義，並產生初始工具清單。這些自動產生的工具預設為停用，是否擁有及啟用工具仍由服務團隊決定。AutoCrawler 也會運用 LLM 強化結構描述與說明，產生更適合代理程式使用的文件——這是一種務實的折衷，在機器化擴展、人為審核與安全把關之間取得平衡。

安全性、政策與營運安全直接內建於 Gateway 層，而非分散到各團隊各自處理。此平台透過 Uber 內部的存取控制系統，執行工具層級與伺服器層級的 charter 政策、在回應中遮蔽個人識別資訊（PII），並統一套用速率限制與稽核。即使支援第三方 MCP 整合，也不會因此放寬政策：Gateway 會轉送內部權杖，再由第三方服務將其交換為外部憑證，確保中央控管依然有效。這種模式在彈性與企業治理之間提供了務實的折衷方案。

在成本與效能方面，Gateway 解決了代理式工作流程擴展時的兩大瓶頸：脈絡膨脹與權杖成本。Omni MCP 提供增量式探索功能——用來尋找伺服器、列出工具、取得結構描述及呼叫工具——因此代理程式不必預先載入數百份工具定義。Response Projection 會在執行階段僅保留所需欄位，精簡回應；Code Mode（透過 aifx）則讓以 CLI 為基礎的程式設計代理程式將輸出寫入磁碟，而非全部載入模型脈絡。這些模式結合起來，可在企業規模下減少不必要的模型脈絡、延遲與 API 支出。

核心要點

集中探索，保留責任歸屬

透過自動化爬取建立可搜尋的工具目錄，但在對外開放前，務必由服務負責人審核並啟用。如此既能降低使用阻力，也能維持問責與安全性。

在 Gateway 層最佳化脈絡與成本

採用增量式探索（Omni MCP）、欄位層級的回應投影，以及以 CLI 為基礎的 Code Mode，降低代理程式工作流程的模型脈絡、延遲與 API 支出。

將 Gateway 視為關鍵基礎架構，並落實安全控管

在 Gateway 統一套用存取政策、PII 遮蔽、速率限制與可觀測性；搭配分階段發布與金絲雀部署，降低設定錯誤造成的影響範圍。

設計與架構：雙平面、單一目錄

MCP Gateway 的雙平面設計，決定了它如何擴展以及團隊如何與之互動。控制平面（MCP Registry）保存虛擬 MCP 伺服器與工具清單的標準目錄；資料平面（Proxy Gateway）則負責執行請求，並在記憶體中具現化已啟用的伺服器。這種分工可在不重新部署的情況下即時發布設定，也讓探索流程自動化，同時將執行政策與所有權留在人員手中。對營運人員而言，它將重複建置的 MCP 基礎架構整合為一項受管理服務，並可與既有服務網格溝通，進而降低維護負擔。

AutoCrawler：大規模探索，不增加團隊負擔

AutoCrawler 是探索引擎，可避免工具撰寫工作呈組合式膨脹。它會持續掃描 IDL Registry 與原生 MCP 心跳、解析 protobuf/Thrift 檔案、產生相容於 JSON-RPC 的結構描述，並建立預設停用的虛擬 MCP 伺服器項目。重要的是，AutoCrawler 會利用 LLM 產生摘要來補強工具說明，並讓服務團隊不必成為關鍵路徑的一環：服務負責人可在準備就緒時審核並啟用產出內容。實際上，企業可以快速建立代理程式工具目錄，同時保留審核關卡與所有權控管。

安全性、政策與遮蔽：一次控管，全面套用

將授權與遮蔽集中在 Gateway，可簡化風險管理。Uber 會套用伺服器層級的 charter 政策，並可選擇設定個別工具的覆寫規則；再使用內部存取控制系統評估呼叫者身分（人員、服務或代理程式），並遮蔽回傳資料中的個人識別資訊（PII）。對於第三方整合，Gateway 會轉送使用者權杖，由外部服務進行權杖交換，維持可追蹤性。這種做法可降低各團隊安全措施的落差，提供一致的稽核軌跡，並讓控管緊貼執行階段。

營運模式：Omni MCP、Response Projection 與 Code Mode

Uber 新增的營運功能，旨在降低探索與模型脈絡方面的阻礙。Omni MCP 提供探索基本功能（discover_server、discover_tools、get_tool_schema、invoke_tool），讓代理程式能逐步探索並呼叫工具。Response Projection 讓 LLM 提示詞只指定所需欄位，由 Gateway 精簡回應，降低權杖用量。透過 aifx CLI 提供的 Code Mode，則可讓程式設計代理程式依序執行列出、搜尋與呼叫指令，並將輸出寫入磁碟；後續的檔案系統代理程式只需載入必要資料。這些模式是降低正式環境代理程式工作流程成本、提升可靠性的實用手段。

風險、限制與責任歸屬

Gateway 優先的做法能減少重複工作，但也會帶來營運風險集中：Gateway 設定錯誤或發生程式缺陷，可能影響許多工具。因此，明確劃分責任至關重要——探索流程應自動化，但啟用權必須由服務團隊保留。其他限制包括以 IDL 為基礎的服務可能出現結構描述漂移、協定轉換的邊緣案例，以及投影欄位不吻合所造成的剩餘成本。企業應搭配健全的 CI、核准工作流程、金絲雀發布與可觀測性，降低系統性故障的風險。